Method and device for secure communications over a network using a hardware security engine

Method and device for secure communication using hardware security engine on network

METHOD AND DEVICE FOR SECURE COMMUNICATIONS OVER A NETWORK USING A HARDWARE SECURITY ENGINE

The present invention relates to a method and device for secure communication using a hardware security engine on the network.

Background of the invention

The cryptographic communication protocol is used to establish a secure communication dialogue between computing devices on untrusted networks or communication links. A commonly used cryptographic communication protocol is the Secure Sockets Layer (SSL) protocol. The SSL protocol and related Transport Layer Security (TLS) protocols are used for many different types of secure communication conversations, including, for example, secure web browsing, e-commerce, security updates, and two computing devices on untrusted networks such as the Internet Other secure communication conversations between. Other communication protocols can use the SSL/TLS protocol to provide underlying security. For example, the Secure Hypertext Transfer Protocol (HTTPS) uses SSL/TLS to encrypt messages between devices. Usually, the cryptographic security provided by the SSL/TLS protocol is completed in-band and executed at the software application level.

Some computing and electronic devices use system-on-chip (SOC) design due to the relatively small footprint of the system-on-chip (SOC). The SOC device is an integrated circuit that incorporates electronic systems other than the processing core on a single die The various components. For example, the SOC may include a processor core, a memory controller, a video component, an audio component, and/or a communication component on a single chip.

According to an embodiment of the present invention, a system-on-chip device is specifically proposed, which includes: a system-on-chip, the system-on-chip includes a security engine, and the security engine has a secure memory that can only be accessed by the security engine , The security engine is used to: generate a random temporary number, the random temporary number is used to initiate a request for a secure communication dialogue with a server on the network using the temporary number; execute a cryptographic key with the server Exchange to generate a symmetrical session key during the secure communication session to encrypt the message sent to the server and decrypt the message received from the server; store the session key in the secure memory, and the system single The chip uses the session key to establish the secure communication session with the server on the network.

<p>100System</p><p>102Client Device</p><p>104Server</p><p>106Internet</p><p>110Safety engine</p><p>112SOC</p><p>114Security memory</p><p>116Memory Controller</p><p>118Processor core</p><p>120Link</p><p>130Hardware peripheral</p><p>132Demultiplexer</p><p>134Video Processing Unit</p><p>136Audio processing components</p><p>150Security Key</p><p>160System memory</p><p>162Data Storage</p><p>164Communication output</p><p>166I/O device</p><p>180Processor</p><p>182Memory</p><p>184Communication circuit</p><p>200Descriptive preservation plan</p><p>300Communication sequence</p><p>302Security engine driver</p><p>304Client Secure Communication Application</p><p>306Server Secure Communication Application</p><p>310~352, 402~428Block</p><p>400Method</p>

The invention described herein is illustrated in the drawings by way of example rather than limitation. For simplicity and clarity of illustration, the elements shown in the drawings do not have to be drawn to scale. For example, for clarity, the size of some components may be exaggerated relative to other components. In addition, where considered appropriate, reference signs have been repeatedly used in each figure to indicate corresponding or similar elements.

Figure 1 is a simplified block diagram of at least one embodiment of a system for establishing a secure communication dialog between a client device and a server with a system-on-chip (SOC) on the network; Figure 2 is Figure 1 The block of at least one embodiment of the system security solution Figure; Figure 3 is a simplified sequence diagram of at least one embodiment of the communication sequence of the client device and the server to establish a secure communication session in Figure 1; and Figure 4 is a simplified flowchart of at least one embodiment of a method, the method used To establish a secure communication session executed by the client device in FIG. 1.

Detailed description of the preferred embodiment

Although the concept of the present disclosure allows various modifications and alternative forms, specific exemplary embodiments of the present disclosure have been shown as examples in the drawings and will be described in detail in the text. However, it should be understood that it is not intended to limit the concept of the present disclosure to the specific form disclosed, on the contrary, it is intended to cover all modifications, equivalents, and alternatives consistent with the scope of the present disclosure and additional patent applications.

In the following description, many specific details are shown, such as logic implementation plan, operation code, means of specifying operands, resource separation/sharing/copy implementation plan, type and relationship of system components, and logic partition/integration options to provide Thorough understanding of the contents of this disclosure. However, it should be understood that those skilled in the art can practice the embodiments of the present disclosure without these specific details. In other examples, the control structure, gate circuit and all software command sequences are not shown in detail so as not to obscure the present invention. With the included description, the average artisan will be able to implement suitable functions without undue experimentation.

References in the specification to "one embodiment", "an embodiment", "exemplary embodiment", etc. indicate that the described embodiment may include specific features and results. Structures or characteristics, but each embodiment may not necessarily include specific characteristics, structures or characteristics. In addition, these phrases do not necessarily refer to the same embodiment. In addition, when describing a specific feature, structure, or characteristic associated with an embodiment, it is proposed that regardless of whether the feature, structure, or characteristic associated with other embodiments is explicitly described, the feature, structure, or characteristic system associated with other embodiments is realized. Within the knowledge of those who are familiar with this technology.

The embodiments of the present invention can be implemented in software, hardware or firmware or any combination of the foregoing. Embodiments of the present invention implemented in a computer system may include one or more bus-based interconnections between components and/or one or more point-to-point interconnections between components. The embodiments of the present invention can also be implemented as instructions carried by or stored on a machine-readable medium, and these instructions can be read and executed by one or more processors. A machine-readable medium can be implemented as any device, mechanism, or physical structure for storing or transmitting information in a form readable by a machine (eg, a computing device). For example, machine-readable media can be implemented as read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; mini or micro SD cards, memory sticks , Electrical signals and others.

In the drawings, schematic elements, such as the specific arrangement or sequence of elements representing devices, modules, command blocks, and data elements, may be displayed for ease of description. However, those familiar with the art should understand that the specific order or arrangement of the schematic elements in the drawings is not intended to imply that a specific order or sequence of processing or separation of processes is necessary. In addition, the inclusion of a schematic element in the drawings is not intended to imply that this element is necessary in all embodiments, or that the features represented by this element may not be included or combined with other elements in some embodiments.

Generally speaking, the illustrative elements used to represent instruction blocks can be implemented using any suitable form of machine-readable instructions, such as software or firmware applications, programs, functions, modules, and routines. , Processes, procedures, plug-ins, small applications, interface tool sets (widgets), code snippets and/or others, and each of these commands can use any suitable programming language, library, application programming interface (API) and / Or other software development tools to implement. For example, some embodiments may be implemented using Java, C++, and/or other programming languages. Similarly, the schematic elements used to represent data or information can be implemented using any suitable electronic arrangement or structure, such as registers, data storage, tables, records, arrays, indexes, hashes, and pairs. Maps, trees, lists, graphics, files (any file type), folders, directories, databases, and/or others.

In addition, in the drawings, connecting elements, such as solid or dashed lines or arrows, are used to show the connection, relationship or association between two or more other schematic elements. The lack of any such connecting elements is not intended to Imply that there can be no connection, relationship or association. In other words, some connections, relationships, or associations between elements may not be shown in the diagram to avoid vaguely revealing the content. In addition, for ease of description, a single connection element may be used to represent multiple connections, relationships, or associations between elements. For example, those familiar with the technology should understand that where the connection element represents the communication of signals, data, or instructions, this element can represent one or more signal paths (such as a bus) to achieve communication when needed.

Referring now to FIG. 1, a system 100 for establishing a secure communication session includes a client device 102, a server 104 and a network 106. In operation, the client device 102 initiates a secure communication with the server 104 on the network 106 The request of words. To establish a secure communication session, the client device 102 and the server 104 perform a cryptographic key exchange, such as Diffie-Hellman or Rivest-Shamir-Adleman (RSA) key exchange, to generate a secret symmetric session key. The secret symmetric session key can then be used to encrypt and decrypt messages between the client device 102 and the server 104. To ensure a secure communication session, various keys and other cryptographic functions generated by the client device 102 are completed in a security engine 110 of a system-on-chip (SOC) 112 of the client device 102. The client device 102 secretly keeps the key in the secure memory 114 of the security engine 110. For example, as discussed below, the security engine 110 may include a security key 150 for signing and/or encrypting other keys and messages. In this way, the client device 102 and the server 104 can use the out-of-band (ie, non-application level) hardware security features of the client device 102 to establish a secure communication session across the network 106. In the illustrative embodiment described herein, the secure communication dialog is a secure socket layer (SSL) communication dialog, but the system 100 and features described herein can be used to establish other types of secure communication dialogs in other embodiments.

The client device 102 can be implemented as any type of computing device that can communicate with the server 104 on the network 106. For example, the client device 102 can be implemented as a set-top box, a digital TV, a smart phone, a tablet computer, a laptop computer, a mobile Internet device (MID), a desktop computer, or other devices that can communicate with the server 104 Device.

As discussed above, the client device 102 includes the SOC 112, which can be implemented as any type of system-on-chip device having various components and structures. In the illustrative embodiment of FIG. 1, SOC 112 includes a security reference The engine 110, the memory controller 116, the processor core 118, and a plurality of hardware peripherals 130 are communicatively coupled to each other via a link 120. The link 120 may be implemented as any type of interconnection, such as a bus, point-to-point, or other interconnection that can facilitate communication between various components of the SOC 112. Depending on the desired function of the SOC 112, the hardware peripheral 130 may include any type of hardware peripheral components. For example, in the illustrative embodiment, the hardware peripheral 130 includes: a demultiplexer 132, which separates audio and video content streams; a video processing component 134, which processes video content; and an audio processing component 136, which processes audio content . Of course, it should be understood that the hardware periphery 130 of the SOC 112 has been simplified in the illustrative embodiment of FIG. 1, and the SOC 112 may include additional, different, and/or more detailed hardware periphery 130, for clarity of the disclosure. For the sake of this, they are not shown in Figure 1.

The security engine 110 may be implemented as a security coprocessor or processing circuit independent of the processor core 118. The security engine 110 includes a security key 150 and a secure memory 114 that can only be accessed by the security engine 110. The security engine 110 stores the security key 150 and other cryptographic keys discussed below in the secure memory 114. In an illustrative embodiment, the security key 150 is provided during the manufacture of the SOC 112, but in other embodiments may be generated by the SOC 112 during operation. For example, in some embodiments, the security key 150 is based on a blown fuse in the security engine 110 itself. Additionally or alternatively, the security engine 110 may include a key-generating module, such as a trusted platform module (TPM), to generate the security key 150. During use, the security engine 110 can use any number of security keys 150, and the security keys may be the same or different from each other.

In some embodiments, depending on the type and intended use of the client device 102, the client device 102 may include additional Components and structure. For example, in the illustrative embodiment of FIG. 1, the client device 102 includes a system memory 160, a data storage 162, a communication output 164, and one or more input/output devices 166. The system memory 160 can be implemented as any type of main memory or data storage location including, for example, dynamic random access memory device (DRAM), synchronous dynamic random access memory device (SDRAM), double data rate synchronous dynamic Random access memory devices (DDR SDRAM), shielded read-only memory (ROM) devices, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) devices, flash memory devices, and /Or other electrical and/or non-dependent memory devices.

The data storage body 162 can be implemented as any type of device configured for short-term or long-term data storage, such as a memory device and circuit, a memory card, a hard disk drive, a solid state drive, or other data storage devices. The communication output 164 can be implemented as a simplified output or as various circuits and/or devices to facilitate, for example, communication with the server 104. For example, the communication output 164 (and/or the communication circuit in the SOC 112) can use any suitable communication protocol, such as Ethernet (ie, IEEE 802.3 standard) or Wi-Fi^®(Ie, IEEE 802.11 standard) and/or other communication protocols or standards. In addition, the input/output device 166 can be implemented as any type of I/O device for interacting with the client device 102. For example, the I/O device 166 may include an output device, such as a display for displaying data on the client device 102, a speaker for generating audio, and/or an input device, such as a remote control receiver, a keyboard, and a mouse.

The server 104 can be implemented as any type of data server capable of establishing a secure communication session with the client device 102. Therefore, the server 104 may include various hardware and software components, which are usually used in the network Found on the server that communicates, maintains, and transfers data. For example, the illustrative server 104 includes a processor 180, a memory 182, and a communication circuit 184, which may be similar to these components found in other data servers. For example, the processor 180 may be implemented as any type of processor capable of executing software/firmware, such as a microprocessor, a digital signal processor, a microcontroller, or the like, and may include one or more processing cores. The system memory 182 can be implemented as any memory type memory or data storage location including, for example, dynamic random access memory device (DRAM), synchronous dynamic random access memory device (SDRAM), double data rate synchronous dynamic Random access memory devices (DDR SDRAM), shielded read-only memory (ROM) devices, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) devices, flash memory devices, and /Or other electrical and/or non-dependent memory devices. The communication circuit 184 can implement any type of circuit and/or device to facilitate, for example, communication with the client device 102. For example, the communication circuit 184 may support communication protocols, such as Ethernet (ie, IEEE 802.3 standard) and/or Wi-Fi^®(Ie, IEEE 802.11 standard) and/or other communication protocols or standards.

The network 106 can be implemented as any number of various wired and/or wireless networks. For example, the network 106 may be implemented as or may include a local area network (LAN), a wide area network (WAN), and/or a publicly accessible global network, such as the Internet. In addition, the network 106 may include any number of additional devices to facilitate communication between the client device 102 and the server 104. As discussed above, in the illustrative embodiment, the client device 102 and the server 104 establish an SSL communication session on the network 106. However, other types of secure communication sessions can be established in other embodiments.

Referring now to FIG. 2, as discussed in more detail below, using the security engine 110 of the client device 102 to execute cryptographic functions and store cryptographic data associated with secure communication sessions allows the system 100 to provide several different levels of security. The specific level of security used in the system 100 may depend on various criteria, such as the nature of the network 106, the importance of the data transferred between the client device 102 and the server 104, and so on. For example, an illustrative security plan 200 includes three different levels of security as shown in FIG. 2. At level 0 security, the client device 102 is configured to protect the client private device key (ie, the security key 150), which is used for the encryption, signature, and verification functions discussed in more detail below.

In level 1 security, the client device 102 is configured to protect the session key and the related key used for data encryption. For example, if an RSA key exchange is performed, the previous master key and the master key (ie, the session key) can be stored in the secure memory 114 of the security engine 110 of the SOC 112. In addition, in some embodiments discussed below, the master key can be stored in encrypted or packaged form (eg, encrypted with the security key 150). In an embodiment using Diffie-Hellman key exchange, the private Diffie-Hellman client key and/or shared secret key (ie, conversation key) can be stored in the secure memory 114 of the security engine 110 of the SOC 112 . Similarly, in some embodiments, the private Diffie-Hellman client key and/or session key can be stored in an encrypted or packaged form (eg, encrypted with the security key 150).

In addition, in level 2 security, the client device 102 can be configured to protect the data of the host application. For example, if the host application is used to perform e-commerce transactions, the bank account information used in this transaction can be used The security key 150 is encrypted and stored in the secure memory 114. In this way, bank account information is not used by the host application. Of course, it should be understood that in other embodiments, security solutions with more or less security levels may be used.

3, in operation, the client device 102 and the server 104 use the security engine 110 of the client device 102 to establish a secure communication session to execute various cryptographic functions and store cryptographic data therein. To do so, the client device 102 and the server 104 can perform a handshake dialogue as shown in the communication sequence 300 of FIG. 3. To establish a secure communication session, the security engine driver 302 of the security engine 110 communicates with the firmware of the security engine 110 and the client secure communication application 304 running on the client device 102. The client secure communication application 304 also communicates with the corresponding server secure communication application 306 running on the server 104.

The communication sequence 300 starts with block 310, where the client secure communication application 304 sends a ClientHello message to the server secure communication application 306 to request to initiate a secure communication session. As discussed above, the secure communication dialog is an SSL dialog in the illustrative embodiment. To facilitate, at block 312, the security engine driver 302 communicates with the security engine 110 of the SOC 112 to request a random temporary number from the security engine 110. At block 312, the security engine 110 may use any suitable random number generation algorithm to generate random temporary numbers. The temporary number is implemented as a random or pseudo-random number, which is intended to be used only once in a cryptographic function to defeat, for example, a replay attack. In an illustrative embodiment, the random temporary number includes a 32-bit timestamp and a 28-byte random number. Of course, in other embodiments, the random temporary number can be Use other number formats. In any case, it should be understood that because random temporary numbers are generated in the security engine 110, the generation and storage of random temporary numbers are protected compared to, for example, the generation of application-level temporary numbers.

The random temporary number generated in block 312 is included in the client hello message, and the client hello message is sent to the server secure communication application 306 in block 310. In addition, the client hello message can include a list of cipher suites, compression methods, and other cryptographic protocols or algorithms, from which the server 104 can choose to establish a secure communication session. In response to the secure communication dialog request, the server secure communication application 306 sends a server hello (ServerHello) message at block 314. The server hello message can be substantially similar to the client hello message. For example, in an illustrative embodiment, the server hello message includes a server random temporary number generated by the server 104. Self-contained In addition, the server's hello message includes a selection of a password protocol and/or other options, and these choices are made by the server 104 from a list that is self-contained in the client's hello message. The Hello server message completes the dialogue initiation phase (phase 1) of the descriptive handshake dialogue.

At block 316, the server secure communication application 306 sends the server certificate to the client secure communication application 304. The server certificate, similar to the client certificate discussed below, is usually generated by a certificate authority, and the certificate serves as a third-party verifier authenticated by the server 104. The server certificate may include a unique identifier or number, which is assigned to the server 104 by a certificate authority to verify the server 104 of other devices on the network 106. Therefore, at block 318, the client device 102 may verify the server certificate. In some embodiments, the client device 102 uses a certificate issued by a certificate authority The public certificate key to verify the server certificate. In this embodiment, the security engine 110 can store the public certificate key in the secure memory 114 in an unencrypted or encrypted state (for example, by using the security key 150).

To establish a secure communication session, the client device 102 and the server 104 perform a key exchange to establish a shared secret key (ie, a master key or a session key) in each of the client device 102 and the server 104. The client device 102 and the server 104 can use any suitable key exchange algorithm to realize the establishment of a shared secret. In an illustrative embodiment, the key exchange may be implemented as RSA key exchange or Diffie-Hellman key exchange. In an embodiment using RSA key exchange, at block 320, the server secure communication application 306 performs the server RSA key exchange. In these embodiments, at block 320, the server 104 may generate a temporary RSA public/private key pair and send the RSA public key to the client device 102. This message can be signed by the server 104 and can be verified by the client device 102 using a public server key, which can be stored in the secure memory 114 as discussed above.

Alternatively, at block 320, the server secure communication application 306 can perform the server Diffie-Hellman key exchange. In these embodiments, in block 320, the server 104 selects or generates Diffie-Hellman global values (eg, prime numbers and prime roots), generates private and public Diffie-Hellman server keys, and transfers the Diffie-Hellman global values The value and the public Diffie-Hellman server key are sent to the client device 102. Likewise, this message can be signed by the server 104 and verified by the client device 102 using the public server key.

In some embodiments, at block 322, the server securely communicates The application 306 can send a client certificate request. If so, the request may specify the type of certificate accepted by the server 104 (for example, the public key algorithm used), the acceptable certificate authority, and/or other certificate parameters. Subsequently, at block 324, the server secure communication application 306 sends the server completion information ("Server Hello Complete" message) to the client secure communication application 304 to indicate that the server 104 has completed this handshake session. In an illustrative embodiment, parameters or other data are not necessary for the server completion information. Hello, server. Complete the message to complete the server authentication and key exchange phase (phase 2) of the descriptive handshake dialog.

In block 326, after receiving the server's completion information, the client secure communication application 304 initiates the client authentication and key exchange phase of the handshake session (stage 3) by sending the client certificate. As discussed above, the client certificate is usually generated by a certificate authority and may contain unique identifiers or numbers. The unique identifiers or numbers are assigned by the certificate authority to the client device 102 to verify the status of other devices on the network 106. Client device 102. In some embodiments, the client certificate may be stored in the secure memory 114 of the security engine 110 of the SOC 112 in an unencrypted or encrypted state. In addition, the client device 102 can use a private device key, which is issued by a certificate authority to sign the certificate before sending it to the server 104.

At block 328, the client secure communication application 304 performs a client key exchange. Likewise, the client device 102 and the server 104 can use any suitable key exchange algorithm to achieve the establishment of a shared secret as discussed above. In an embodiment using RSA key exchange, at block 330, The security engine 110 of the SOC 112 of the client device 102 generates a random pre-master key. Illustratively, the front master key is implemented as a 48-byte random number, but other digital formats can be used in other embodiments. In block 332, the master key is encrypted or wrapped with the server public key before being generated in block 330, and the server public key is provided by the server in the server authentication and key exchange phase (phase 2). In block 328, the encrypted previous master key may be stored in the secure memory 114 of the security engine 110 of the SOC 112 and sent to the server 104.

Alternatively, in an embodiment using Diffie-Hellman key exchange, in block 334, the security engine 110 uses the Diffie-Hellman global value received from the server 104 in block 320 to generate a private Diffie-Hellman client key and public Diffie -Hellman client key. The private Diffie-Hellman client key can be implemented as a random value generated by the security engine 110, and the public Diffie-Hellman client key is generated by the security engine 110 using the Diffie-Hellman global value received from the server 104. The private Diffie-Hellman client key can be stored in the secure memory 114 of the security engine 110. Of course, in some embodiments, at block 334, the client device 102 may generate the Diffie-Hellman global value and send the global value to the server 104 at block 328 to allow the server 104 to generate a public Diffie-Hellman based on the global value. Hellman server key. In any case, at block 336, SOC The security engine 110 of 112 uses the security key 150 or other private client keys of the security engine 110 to sign the public Diffie-Hellman client key at block 336 (and if generated by the client device 102, sign the Diffie-Hellman global value ). In block 328, the signed Diffie-Hellman parameters can be further encrypted using the public server key and sent to the server 104.

In some embodiments, at block 338, the client secure communication application 304 may send the client certificate verification message to the server secure communication application 306. To do so, at block 340, the security engine 110 generates a hash code based on the aforementioned information and uses the security key 150 of the security engine 110 to sign the hash code. At block 338, the client device 102 sends the hash code of the signature to the server 104 as verification of the aforementioned message. It should be understood that these client certificate verification messages can be used after any message is sent from the client device 102 to the server 104 to provide an increased level of security and verification of secure communication sessions. At block 338, the client certificate verification message completes the client authentication and key exchange phase of the descriptive handshake dialog (phase 3).

At block 342, the client secure communication application 304 sends a password change description message to the server secure communication application 306 to notify the server 104 that the agreed password (eg, the generated session key) will be used for subsequent communications. At block 344, the security engine 110 of the client device 102 generates a session key (ie, the "master" key). In the embodiment using RSA key exchange, the security engine 110 generates the session key according to the function of the previous master key generated in block 330. To do so, the security engine 110 calculates a hash function of the previous master key, the client random temporary number generated in block 312, and the server random temporary number received in block 314. Alternatively, in an embodiment using Diffie-Hellman key exchange, the security engine 110 generates the conversation key according to the functions of the Diffie-Hellman global value, the public Diffie-Hellman server key, and the private Diffie-Hellman client key . As discussed above, the conversation key is stored in the secure memory 114 of the security engine 110.

At block 346, the security engine 110 generates a hash of the conversation key The code depends on the type of hash function used, and the hash code may contain additional padding values. At block 348, the hash code of the session key is sent to the server 104 for the client to complete the verification in the message. The hash code of the conversation key can be encrypted by the security engine 110 using the public server key discussed above.

In block 350, in response to the client completion message, the server 104 sends a password change description message confirming the use of the agreed password (eg, conversation key). At block 352, the server 104 also sends a server completion message, which includes a hash code for the similar session key to be verified by the client device 102. Assuming that the client device 102 and the server 104 verify the hash code of the session key, the handshake session is completed and each of the client device 102 and the server 104 has a shared secret session key for encrypting and decrypting subsequent messages. Similarly, it should be understood that the security engine 110 of the SOC 112 of the client device 102 is used for all cryptographic functions and storage of sensitive cryptographic data to provide hardware-based cryptographic key and certificate key protection during the communication sequence 300.

Referring now to FIG. 4, in use, the client device 102 can execute a method 400 to establish a secure communication session with the server 104. The method 400 starts at block 402, where the security engine 110 of the SOC 112 of the client device 102 is provided. To do so, in one embodiment, the security engine 110 receives the client device certificate, the private client device key, and the public certificate key. The client device certificate, private client device key, and public certificate key are usually generated by a certificate authority organization, and they serve as third-party certifiers for the authentication of the client device 102 discussed above. The client device certificate may include a unique device identifier or number, which is assigned to the client device 102 by a certificate authority organization to verify the clients of other devices on the network 106 Device102. Device 102. As discussed in more detail below, the private client device key can be used by the client device 102 to sign the client device certificate to authenticate the client device 102 of other devices. Conversely, the public certificate key can be used by the client device 102 to verify the certificates issued by the certificate authority of other devices on the network 106.

The security engine 110 uses the security key 150 to encrypt the private client device key and stores the encrypted private client device key in the secure memory 114. The security engine 110 can also store the client device certificate and/or the public certificate key in the secure memory 114. In addition, in some embodiments, the security engine 110 may use the security key 150 stored in the security engine 110 to encrypt the client device certificate and/or the public certificate key.

After the security engine 110 has been provided in block 402, in block 404, the client device 102 determines whether to establish a secure communication session (eg, SSL session) with the server 104. If so, then at block 406, the security engine 110 generates a random temporary value. As discussed above, the security engine 110 can use any suitable random number generation algorithm to generate random temporary numbers. In block 408, the client device 102 sends a request (client hello message) to initiate a secure communication session to the server 104. The request includes the random temporary number generated in block 406 and a list of password protocols, compression methods, and/or other password choices, from which the server 104 can select.

At block 410, the client device 102 completes server authentication and server key exchange. When doing so, the client device 102 can receive the corresponding server hello message, the server hello message includes the server's random temporary number, the server 104 public key and the server 104 pair are provided in the client hello message Choice of password selection. As discussed above, the server random temporary number and the client random temporary number are used to generate the conversation key. Therefore, the security engine 110 can store the server's random temporary number in the secure memory 114. In addition, in some embodiments, the security engine 110 may store the server certificate and/or other cryptographic data in the secure memory 114. For example, in an embodiment using RSA key exchange, the security engine 110 can store the public RSA key received from the server in the secure memory 114. Alternatively, in an embodiment using Diffie-Hellman key exchange, the security engine 110 may store the Diffie-Hellman global value and/or the public Diffie-Hellman server key in the secure memory 114.

At block 414, the client 104 determines whether the server 104 is successfully authenticated. If not, the method 400 loops back to block 404, where the client device 102 may try to establish a secure communication session with the server 104 again. However, if the server 104 is successfully authenticated, the method 400 proceeds to block 416, where the client device 102 sends the server 104 client certificate. If the client certificate is encrypted (for example, using the security key 150), the security engine 110 decrypts the client certificate and signs the client certificate with the private client device key.

In block 418, the client 104 uses the security engine 110 to complete the client key exchange to maintain the security of the key function. For example, if the RSA key exchange is selected, the security engine 110 generates the front master key before sending the encrypted front master key to the server 104 in block 420 and encrypts the front master key using the server public key received in block 410 The previous master key. Or, if Diffie-Hellman key exchange is selected, the security engine 110 uses the box 410 The Diffie-Hellman global value received from the server 104 is used to generate public and private Diffie-Hellman client keys. The security engine 110 can use the security key 150 provided in block 402 or the public client device key to sign the public Diffie-Hellman client key. At block 422, the client device 102 sends the signed public Diffie-Hellman client key to the server 104. The key and related cryptographic data generated during the client key exchange can be stored in the secure memory 114 in an encrypted state (by using the security key 150) or in an unencrypted state.

At block 424, the client device 102 determines whether the client device 102 has been successfully authenticated by the server 104. If not, the method 400 loops back to block 404, where the client device 102 may try to establish a secure communication session with the server 104 again. However, if the client device 102 is successfully authenticated, the method 400 proceeds to block 426, where the client device 102 confirms the cipher suite with the server 104 by notifying the server 104 that subsequent messages will use the negotiated cryptographic protocol. In doing so, the security engine 110 can generate a master key or a conversation key. To do so, in an embodiment using RSA key exchange, the security engine 110 calculates a hash function of the previous master key, the client random nonce generated in block 406, and the server nonce nonce received in block 410. Alternatively, in an embodiment using Diffie-Hellman key exchange, the security engine 110 generates the conversation key according to the functions of the Diffie-Hellman global value, the public Diffie-Hellman server key, and the private Diffie-Hellman client key . Once generated, the security engine 110 of the SOC 112 can store the session key in the secure memory 114 of the security engine 110. In some embodiments, the conversation key can be stored in the secure memory 114 by using a security deposit. The key 150 is encrypted.

At block 428, the security engine 110 generates a hash function of the session key, and the hash function is sent to the server 104 for the client to complete the verification in the message. Similarly, the hash code of the conversation key can be encrypted by the security engine 110 using the public server key discussed above. In response, the server 104 verifies the cipher suite with the client device 102 to confirm the agreed password (eg, session key). The server 104 also sends a server completion message, which includes a hash code of a similar session key for verification by the client device 102. Assuming that the client device 102 and the server 104 verify the hash code of the session key, the handshake session is completed and each of the client device 102 and the server 104 has a shared secret session key for encrypting and decrypting subsequent messages.

Although the disclosure has been shown and described in detail in the drawings and the foregoing description, this description and description must be considered as exemplary rather than limiting the features. It should be understood that only illustrative embodiments have been shown and described, and All changes and modifications with consistent disclosure content and the scope of patent applications listed are expected to be protected.