Method and apparatus for security over multiple interfaces

Method and device for realizing safety through multiple interfaces

The present invention relates to a secure digital system/device, and more specifically, the present invention relates to an integrated circuit chip protected from the hardware level.

The development of distributed computer networks has put forward higher requirements for the security of information transmission between networks. Moreover, with the higher integration of electronic circuits on smaller integrated circuits (ICs), electronic devices are increasingly able to process more complex data and perform more functions. Sensitive data with higher security requirements will be transmitted between ICs in the same digital system (such as personal computers, set-top boxes, or mobile phones). In addition, these ICs are gradually being used to store, process and transmit sensitive information. Therefore, the security of the data stored and transmitted by these ICs needs to be guaranteed.

Information transmission in the data network can use many existing encryption technologies to provide security. For example, the Secure Sockets Layer (SSL) protocol and its subsequent Transport Layer Security Protocol (TLS) provide a mechanism for sending data securely between the server and the client. Simply put, SSL provides a protocol for authenticating the identity of the server and the client, and generating an asymmetric (private-public) key pair. The authentication process provides a certain level of assurance for the client and server to ensure that they are communicating with the desired object. The key generation process securely provides a unique encryption key for the client and the server, so that both (but not the other parties) can use the key to encrypt or decrypt the data sent to each other over the network . SSL includes a number of basic stages: negotiated supported algorithms with peers, key exchange based on public key encryption and certificate-based authentication, and communication encryption based on symmetric keys.

Figure 1 briefly shows several levels in the security system 102. The objects in the system can securely transmit data by encrypting data 104 before sending. If another object wants to decrypt the received data, it must first obtain the correct key. Therefore, data encryption relies on the security method of key agreement 106 between objects. If the key agreement is not secure (for example, the key can be stolen by unauthorized individuals), then the encrypted data will be leaked. Similarly, the prerequisite for ensuring the security of key agreement is to authenticate both parties participating in the key exchange 108. In other words, each object must ensure that its negotiated object is not a pretender of the desired object (man-in-the-middle attack). The authentication process ultimately needs to rely on the root key 110 to uniquely and reliably authenticate a specific object. Therefore, the root key is often referred to as the encrypted identity of the object.

In practice, the role of the root key is to generate other keys, which will then be used to generate lower-level keys. Generally speaking, these lower-level keys have a relatively short lifespan. For example, lower-level keys such as SSL session keys are only valid in one session. Therefore, the possible damage caused by the leakage of the session key is much smaller than that of the advanced key leakage. For example, in the case of a security breach, the entire system will not be destroyed, and the key will expire soon.

In contrast, if a high-level key is compromised, all secondary (for example, lower-level) keys will be compromised. In addition, the use period of the advanced key is relatively long, so the possible damage will be greater. Therefore, the protection of advanced keys is the primary goal of any cryptographic security system.

For example, in a typical e-commerce transaction, each session will generate a unique set of SSL keys. For example, when a user uses a page browser to safely access a bank's financial site, a set of session keys will be generated for this session. These session keys are used to encrypt and decrypt data transferred between the server (for example, a bank's server) and the client (for example, a browser). To prevent these keys from being intercepted by unauthorized individuals, advanced keys (for example, a private-public key pair negotiated between the bank server and the client) will be used to encrypt and decrypt these session-level keys. However, as mentioned above, the protection of this high-level key will be crucial.

As shown in FIG. 2, in a typical PC-based application, the client device stores its private key (Ka-priv) 214 in the system memory 206 of the computer 200. When the session is started, the server encrypts the session key (Ks) 228 using the public key (Ka-pub) of the client, and then sends the encrypted session key [Ks] Ka-pub 222 to the client. As shown by the connections 216 and 224, the client then calls its private key (Ka-priv) and the encrypted session key 222 from the system memory through the PCI bus 208, and then loads them into the accelerator module. The public key accelerator 210 in the group or accelerator card 202. As shown in connection 226, the public key accelerator uses the loaded private key 220 to decrypt the session key, and then loads the session key (Ks) 228 in plain text into the system memory.

During the session, when the server needs to send sensitive data to the client, the server uses the session key (Ks) to encrypt the data, and then loads the encrypted data [data]Ks 204 into the system memory middle. When the client application needs to access normal form (unencrypted) data, it loads the session key 228 and the encrypted data 204 into the symmetric algorithm engine (for example, 3DES, AES, etc.) 212, respectively, such as connection 230 and 234 are shown. The symmetric algorithm engine uses the loaded session key 232 to decrypt the encrypted data, and as shown by the connection 236, loads the normal form data 238 into the system memory. At this point, the client application can use the data.

When the client and server are both secure, the SSL protocol and other protocols can provide relatively high security for data transmission through computer networks. However, for more experienced hackers and computer virus developers, these devices can also be breached. For example, a virus running on a computer may be able to access data stored in the data memory of the computer. In addition, the virus can also send this information to a third party.

As shown in Figure 2, the private key (Ka-priv) of the user side can be stored in the system memory in plain text (for example, unencrypted), and transmitted in plain text through the PCI bus. In addition, the operating system call will be used to provide data transfer with the encryption accelerator. The above-mentioned features of the system provide convenience for hackers, viruses or other means of intrusion. If in the SSL transmission process, the client's private key is essentially a certificate that identifies the server's identity (so it essentially includes the server's private key), the existing structure cannot provide enough for most applications safety.

Certain components, such as hardware security modules (HSM), are generally multi-chip boards that can be used to provide a higher level of security for more security-sensitive applications. Generally speaking, hardware security modules provide security key management to generate encryption keys, limit the utility and security of keys, implement key backup and recovery, prepare keys for storage, and perform key recovery And destroyed.

However, these hardware modules or devices themselves do not accept certification. Generally, applications running on these devices are certified to ensure the security of data between different applications that exchange data. In addition, even the most sophisticated data security solutions have security vulnerabilities at the component level. For example, the system may be intercepted at the component level (ie, the printed circuit board "PCB" level) to obtain the root (private) key. Once the private key is stolen, access to encrypted information becomes very easy. In some systems, these components are physically encapsulated and made in an inaccessible form, for example, covered with a thick layer of plastic material. This method can prevent unauthorized access to the component by listening to the component's pins or printed circuit (for example, using a logic analyzer). However, this method adds unnecessary difficulties to PCB testing, debugging and maintenance.

Therefore, it is necessary to improve the security at the electronic component level in the digital system/device so that it does not require any external or remote servers/objects to ensure the security of data transmission in the digital system/device.

The invention relates to a verification method and system. In one embodiment, the present invention provides a secure digital system including multiple integrated circuits (ICs) that exchange data with each other. Each of the ICs includes a key generator for generating an encryption key; memory, which stores the generated encryption key securely; a verification module, which verifies the adjacent ICs of the IC; an encryption module, for slave The data sent by the IC to the adjacent IC is encrypted; the decryption module decrypts the data received from the adjacent IC.

In one embodiment, the present invention provides a secure IC, which includes multiple input interfaces to receive data from other ICs; multiple output interfaces to transmit data to other ICs; an encryption module to perform data transmission to other ICs. Encryption; decryption module, decrypt the data received from other ICs.

In one embodiment, the present invention provides a method for safely processing data in a digital system including multiple ICs. The method includes: generating a unique encryption key for each of the plurality of ICs; storing each of the generated encryption keys securely in each IC; verifying the neighboring ICs of each IC; Encrypt the data transmitted from each IC to its neighboring IC.

In one embodiment, the encryption key is a public/private key pair, and the memory is a one-time programmable memory in which the private key is stored. In one embodiment, data transmission between two ICs is recorded, and each data transmission is time stamped. The time-stamped data transmission records between each IC are stored in the battery-powered memory of the relevant IC.

In one embodiment, each IC is assigned a unique chip identification number, and the unique chip identification number is used to encrypt the public key. The wafer identification number is permanently assigned to an IC during manufacturing. In addition, the chip identification number can also be encrypted.

According to one aspect of the present invention, there is provided a secure digital system, including: a plurality of integrated circuits (ICs) for exchanging data with each other, wherein each IC includes: a key generator for generating an encryption key; a memory, Safely store the generated encryption key; a verification module, which verifies the neighboring ICs of each IC; an encryption module, which encrypts the data sent from each IC to the neighboring IC; a decryption module, for The data received from the adjacent IC is decrypted.

Preferably, the encryption key is a public/private key pair.

Preferably, the memory is a one-time programmable memory, and the private key is stored therein.

Preferably, the public key is generated through negotiation with the neighboring IC.

Preferably, the public key is issued to the neighboring IC.

Preferably, each IC further includes a unique chip identification number, wherein, before transmitting the public key to the adjacent IC, the encryption module uses the unique chip identification number to perform the verification on the public key. encryption.

Preferably, the wafer identification number is permanently assigned to each IC during manufacturing.

Preferably, the chip identification number has been encrypted.

Preferably, the key generator is a random number generator.

Preferably, the random number generator is a free-running oscillator, capturing thermal noise as a source of randomness.

Preferably, each IC further includes a data transmission counter for storing historical records of data transmission between each IC and each of its neighboring ICs.

Preferably, each IC also includes a timer for marking a time stamp for each data transmission.

Preferably, each IC further includes a battery-powered memory for storing data transmission records marked with a time stamp between each IC and each adjacent IC.

According to one aspect of the present invention, there is provided a secure integrated circuit chip (IC), including: a plurality of input interfaces for receiving data from other ICs; a plurality of output interfaces for transmitting data to the other IC; an encryption module The group encrypts the data sent to the other IC; the decryption module decrypts the data received from the other IC.

Preferably, the security IC further includes a verification module for verifying certain other ICs.

Preferably, the security IC further includes a key generator for generating an encryption key.

Preferably, the encryption key is a public/private key pair.

Preferably, the security IC further includes a unique chip identification number, wherein the encryption module uses the unique chip identification number to encrypt the public key.

Preferably, the chip identification number is permanently assigned to the security IC during manufacture.

Preferably, the chip identification number is encrypted.

Preferably, the secure IC further includes a data transmission counter for storing the historical record of data transmission between each adjacent IC.

Preferably, the security IC further includes a timer for marking a time stamp for each data transmission.

Preferably, the security IC further includes a battery-powered memory for storing data transmission records marked with a time stamp between each adjacent IC.

According to one aspect of the present invention, there is provided a method for safely processing data in a digital system having a plurality of integrated circuits, the method comprising: generating a unique encryption key for each of the plurality of ICs; The generated encryption key is securely stored in each corresponding IC; the adjacent IC of each IC is verified; the data sent from each IC to the adjacent IC is encrypted.

Preferably, the encryption key is a public/private key pair.

Preferably, the method includes negotiating the public key with the neighboring IC.

Preferably, the method includes assigning a unique chip identification number to each IC, and encrypting the public key of each IC using the respective unique chip identification number.

Preferably, the wafer identification number is permanently assigned to each IC during manufacturing.

Preferably, the method includes saving a record of data transmission between each IC and each of its neighboring ICs.

Preferably, the method includes stamping a time stamp for each data transmission.

Preferably, the method includes storing a data transmission record marked with a time stamp between each IC and each adjacent IC.

In one embodiment, the present invention relates to a method and system for verifying adjacent data processing ICs in a digital system/device and encrypting data transmitted with the adjacent data processing ICs. The verification and encryption process is performed in each data processing IC. Each data processing IC verifies its neighboring data processing IC, and then encrypts the data transmitted between the two. In this way, the verification and data encryption between the data processing ICs are completed in the hardware of the physical layer. This method can also ensure that the software application runs on trusted hardware without having to have another application to ensure its own security boundary.

Figure 3 is a block diagram of a typical digital system/device. The digital system/device may be a PC, a set-top box, a mobile phone box, and similar devices. The data processing IC can be mounted on one or more PCBs and/or multi-chip modules. Upon power-up, each data processing IC (for example, the CPU 302) verifies its neighboring data processing ICs, such as the memory controller 304, the baseband controller 306, and the media processor 308. The memory controller 304 sequentially verifies the data processing ICs adjacent to it, such as the I/O controller 310 and the memory 312. In one embodiment, the disk controller 320 encrypts the command to be written to the hard disk. It should be noted that the data to be written to the hard disk has been encrypted by the CPU 302. Non-data processing ICs, such as "glue logic" ICs 314, 316, and 318, do not require verification because these ICs do not perform data processing functions and therefore do not transmit data. Similarly, the data entering and leaving these ICs are encrypted by the data processing IC.

Each data processing IC includes a security module (described below) for generating an encryption key, for example, a unique public/private key pair corresponding to a specific data processing IC. Subsequently, the private key is stored in the corresponding IC as permanent confidential information, and the public key will be sent to (negotiated with) the adjacent data processing IC. The public key may be transmitted in an unencrypted form (ordinary form), or may be transmitted after being encrypted using a unique chip ID. Then, each data processing IC uses its public/private key pair to verify its neighboring data processing ICs, and then encrypts/decrypts the data sent to/received from other data processing ICs. In this way, safety is achieved within the silicon-based hardware, that is, within the IC. In addition, all data transmitted between the data processing ICs (which have been verified) are encrypted. For example, by encrypting the data, the security of all the data/command paths from 330 to 352 shown in FIG. 3 are guaranteed.

Fig. 4 is a flowchart of processing for data security at the component level in a digital system according to an embodiment of the present invention. As shown in step 402, upon power-up, each data processing IC (for example, the media processor 308 in FIG. 3) generates a public/private key pair. This can be achieved by using a random number generator. Next, the generated private key is permanently stored in the media processor 308 in a secure manner, as shown in step 404. In one embodiment, the private key is stored in a one-time programmable memory. Subsequently, in order to store the private key securely, the memory is set as a read-only memory. In step 406, the public key is sent along with the chip ID to neighboring ICs for negotiation, so as to verify the neighboring ICs. The chip ID can be burned into the IC during manufacturing. In one embodiment, the chip ID is encrypted. In one embodiment, each data processing IC stores a data table containing all valid chip IDs.

In one embodiment, each data processing IC includes a time stamp circuit for marking a time stamp for each data transmission between it and each adjacent data processing IC. In addition, each pair of adjacent data processing ICs saves historical records of data transmission between each other. This time-stamped transmission record is combined with each data transmission between adjacent ICs. In this way, the security of the system is protected from damage, such as a replay attack.

In one embodiment, the transmission record is generated by using a transmission counter, and is stored in a battery-powered memory (for example, NVM). Therefore, each data processing IC has a state shared with each data processing IC adjacent to it. The shared status includes, for example, how many data transmissions have been made between the two ICs within a specified time. Because only these two adjacent ICs know the state they share, a potential intruder cannot imitate or reproduce the transmission between the two ICs.

As shown in FIG. 4, in step 408, once the adjacent data processing IC is verified, the public/private key is used to encrypt any data transmitted between the two chips. From this point on, all transmissions between the two chips are within the hardware-level security encryption boundary.

Fig. 5 is a block diagram of a security module included in each data processing IC of a data system. The data system may be a PC, a set-top box, a mobile phone, a DVD reader and similar devices. The security module 500 uses a symmetric key to provide functions such as data encryption and decryption. In one embodiment, this configuration is applied in every data processing IC to minimize the impact on the cost and size of the IC.

In a typical application, the embodiment shown in Figure 5 can be used to safely transmit data to adjacent receiving ICs that use these data, and can also receive from adjacent data processing ICs that provide security (encrypted )material. This process includes encrypting the data so that it does not appear in a normal form, and/or signing the data to prove its identity to the receiving IC, that is, the data originates from a specific originating IC.

For example, the security module can be integrated into a media processor chip (for example, the media processor 308 in the other data processing IC in FIG. 3). Here, the security module may sign and/or encrypt the information generated by the media processor. Subsequently, the security module can safely send information to the receiving IC (for example, the CPU 302 in FIG. 3) that uses the information. In this case, the receiving IC uses its own public/private key to decrypt the received information and further process the decrypted information. Then, the receiving end data processing IC encrypts the processed data, and then sends it to the adjacent IC (for example, the memory controller 304 in FIG. 3) for further processing.

The above-mentioned key (especially the private key) is stored in a non-volatile memory ("NVM") 510. The NVM 510 includes one-time programmable ("OTP") memory or battery-powered memory (BBMEM). In some embodiments, it is better to use OTP memory, because the content in the OTP memory does not need to be transferred to the outside of the chip. The structure and implementation of OTP memory are described in U.S. Patent Nos. 6,525,955, 6,700,176, and 6,704,236, and U.S. Patent Application No. 10/041,296 dated January 8, 2002, and this application is hereby cited The contents of all the above documents.

In the case of using OTP, the OTP is programmed by the main controller 506 through the programming interface using the external programming signal VPP. By reading and writing the long-term key cache address array to it before programming, the main controller can ensure that the OTP510 is completely emptied. If the array is empty, then program one security bit before programming any other bits.

After programming the OTP, read the device's key cache address, and verify the device's long-term keys to ensure that they are correct. Once the verification is passed, the main controller 506 will program the second security bit to complete the initialization process. NVM will not mark the long-term key as valid until both security bits have been programmed.

Unless both security bits are cleared after reset, the OTP control logic will lock the programming logic. This can prevent the partially programmed bit array from being programmed again. This method helps to ensure that the long-term keys, authorizations, and configuration data of the device can be programmed once and only once. After performing an external reset and before the security module is released from the reset, the security bit is read by the hardware. The random number generator 516 generates a random number, and the random number is used to generate one or more of the symmetric keys.

In some embodiments, the value generated by the random number generator 516 is not used directly. For example, before being used internally and before being transmitted to the outside of the security module as a random value, the value is post-processed by the main controller 506 using the SHA-1 module 504. The main controller stores the post-processed random bits (used to generate keys and signatures) in the cache memory in the data buffer 518. The random number generator 516 may be a true source of randomness. For example, the random number generator 516 can use a free-running oscillator to capture thermal noise as a source of randomness.

As shown in FIG. 5, the security module includes a main controller 506 and an external interface 512 to implement the asymmetric key operation when a security link is established with an adjacent IC. Therefore, the controller 506 includes a circuit for generating and verifying the validity of its key. In some embodiments, the main controller 506 includes a RISC processor, which contains ROM code, and can execute various commands necessary for the operation of the stateless module. The master controller module also includes an address decoder that performs address decoding for each slave module on the internal bus. The RISC engine uses the protected part of the data buffer as temporary stacking and temporary data space. The protected data area is not allowed to overlap with any space allocated to the external memory interface.

In some embodiments, data is always kept within a secure boundary. First, after the security module is embedded in each of the data processing ICs, the information will be encrypted before it leaves the hardware security boundary of the IC. Secondly, the security module establishes a secure channel with the receiving end IC through symmetric key exchange. In this way, the information will be safely sent to each receiving end data processing IC.

For example, the data processing IC at the receiving end includes a security module as shown in FIG. 5. In this case, the receiving IC can use other keys to safely send the information to the adjacent IC. In other embodiments, it is only necessary to ensure that the data originates from a specific IC. For example, the system can make other provisions to ensure that the data flow is not replayed slightly. In this case, there is no need to encrypt the information, and the only requirement is to ensure that the information is sent by a specific (and/or authorized) IC. In this case, the sender IC can provide sufficient security by simply signing the data. This method can provide a cost-effective solution for a variety of data equipment.

As shown in FIG. 5, the security module includes an encryption module 528 for executing encryption algorithms, such as DH, DSA, 3DES, AES, etc. In one embodiment, the application code of the encryption algorithm (for example, DH, DSA, 3DES, AES) is stored in the ROM 508. In the embodiment shown in FIG. 5, the SHA-1 algorithm is used for signature to provide security for the input data flow (DI). Therefore, to perform this operation, a separate processing module 504 can be used. The output data flow (DO) signed by the processing module will be sent to the receiving end IC through the data interface in the IC. In one embodiment, the data flow is also encrypted, for example, the dedicated processing module 528 executes a symmetric encryption algorithm.

In one embodiment, the security module includes several encryption processing modules. For example, each processing module is combined to execute the HMAC-SHA-1 message authentication code algorithm. The security module can also use some processing modules to execute confidentiality symmetric algorithms, such as 3DES and AES. The public key algorithms supported by the encryption processing module include Diffie-Hellman, Digital Signature Algorithm ("DSA"), RSA, and so on. The encryption processing module also supports the Discrete Logarithm Integration Encryption Standard ("DLIES") algorithm. According to different system performance requirements, these encryption processing modules can be implemented by hardware, and/or implemented by the main controller 506 executing firmware stored in the ROM.

In one embodiment, the security module includes a public key acceleration engine ("PKE") (not shown in the figure). The PKE can provide acceleration for encryption algorithms, such as the Diffie-Hellman algorithm, the RSA algorithm, and/or the Digital Signature Standard ("DSA") algorithm. The Diffie-Hellman public key algorithm can be used for key negotiation of a variety of protocols (such as IKE, SSL, and TLS). The RSA public key algorithm can be used for digital signature verification and key exchange in IKE, SSL and TLS. The DSA algorithm can be used to sign and verify data. It is also widely used in a variety of other applications, such as public key infrastructure ("PKI") products.

PKE can accelerate the algorithm required for key negotiation during the establishment of a key session. In some embodiments, the security module requires all "secret" key information used in PKE messages to be loaded from the KEK cache for use in internal key operations. PKE can also use the key in the key cache to encrypt, decrypt, sign and verify the data process.

The verification core 504 provides a basic SHA-1 algorithm implementation. The result of the specified operation is a 160-bit digest. The initial value of the SHA-1 algorithm status register can be programmed into the digest register as the starting point for verification.

In one embodiment, the security module includes a time stamp circuit to mark each transmission with each adjacent data processing IC. In addition, the transmission counter generates a transmission record for each data transmission of each adjacent IC. Subsequently, the transmission record marked with a time stamp is stored in the NVM 510. Therefore, each data processing IC maintains a shared state together with each adjacent data processing IC through the security module.

In one embodiment, the encryption core 528 is implemented using the 3DES minimum gate count. The encryption core 528 uses a single cycle per round implementation to minimize the number of gates. The input data is buffered twice, so that the data can be loaded while operating on the previously loaded value. The output data is realized in the same way, so that the main controller 506 can load the next value and transmit the previous value while processing the current value.

The single-loop implementation can simultaneously realize the encryption and decryption of CBC and ECB 3DES algorithms. The key used is written by the main controller through the key register (write only). Before data manipulation, the key value can be obtained from the application key cache, the KEK key cache, or a shared key source. The 3DES module 528 provides protection for data operations, so that the main controller cannot change the key during module encryption or decryption.

Optionally, the security module further includes a guarantee logic 520 to protect the security module from system security attacks. To this end, several system monitors are connected with other components in the security module and/or other components of the IC where the stateless module is located.

In some embodiments, when an attack is detected, the protection circuit triggers the stateless module to reset. The reset will clear all transient information in the stateless module. For example, all key cache addresses will be cleared. The trigger can be realized by providing an interrupt carrying relevant information to the local host.

Fig. 6 is a processing flowchart of a security module according to an embodiment of the present invention. As shown in steps 602 to 610, the security module generates a public-private key pair, then stores the private (identity) key in the non-volatile memory within the security boundary, and issues the public key , Establish a secure communication channel with the adjacent data processing IC.

As shown in step 610, the neighboring IC can send its own public key and/or chip ID to the security module through the secure communication channel. For example, the adjacent IC may send its own public key and chip ID to encrypt and/or sign the data received by the security module from the adjacent IC. As shown in step 612, if the public key and/or chip ID of the adjacent IC are encrypted, then the security module encrypts the received within the security boundary associated with the security module The public key and/or chip ID are decrypted. In one embodiment, the chip ID is injected into the security module during manufacturing (for example, chip testing). In one embodiment, the chip ID is encrypted before being burned into the IC.

In one embodiment, when the IC with the security module is initialized for the first time after manufacturing (for example, during a test process), the circuit in the security module can use a random number generator to generate the aforementioned public -Private key pair. The security module stores the private (identity) key in a non-volatile memory or a one-time programmable memory. The wafer ID will also be generated during this process. Subsequently, the security module issues the chip ID, and the manufacturer sends the chip ID together with a certificate to a public server, which can then be accessed safely.

As shown in step 614, the security module receives the encrypted data to be decrypted from the adjacent IC, and uses the symmetric key to decrypt the data within the security boundary for further processing. After the data is processed, as shown in step 616, the security module uses the symmetric key to encrypt the processed data within the security boundary. Subsequently, as shown in step 618, the security module sends the encrypted data to the next adjacent IC.

In some embodiments, the symmetric key and chip ID may be injected into the stateless module during manufacturing. In this case, the external interface 512, RNG 516, and asymmetric key processing circuit may not be needed. Therefore, as shown in FIG. 7, the security module 700 can be simplified to include a relatively small main controller 706 for injecting a symmetric key and performing other basic operations. The security module 700 also includes a non-volatile memory 708, a data buffer memory 710, and an encryption processor 704 for symmetric key operations. Optionally, the security module 700 may also include guaranteed logic 712.

Those of ordinary skill in the art will know that various modifications can be made to the above-mentioned embodiments of the present invention without departing from the scope of the present invention. Therefore, it can be understood that the present invention is not limited to the specific embodiments or solutions disclosed in this application, and the present invention covers any replacement, alteration or modification falling within the scope and spirit defined by the claims of the present invention.

<p>Security system. . . 102</p><p>material. . . 104</p><p>Key agreement. . . 106</p><p>Certification. . . 108</p><p>Root key. . . 110</p><p>computer. . . 200</p><p>Accelerator module or accelerator card. . . 202</p><p>Encrypted data [data]Ks. . . 204</p><p>System memory. . . 206</p><p>Private key PCI bus. . . 208</p><p>Public key accelerator. . . 210</p><p>Symmetric algorithm engine. . . 212</p><p>(Ka-priv). . . 214</p><p>Connect. . . 216, 224</p><p>Encrypted session key [Ks]Ka-pub. . . 222</p><p>Session key (Ks). . . 228</p><p>Connect. . . 230, 234</p><p>The loaded session key. . . 232</p><p>Connect. . . 236</p><p>Common form data. . . 238</p><p>CPU. . . 302</p><p>Memory controller. . . 304</p><p>Baseband controller. . . 306</p><p>Media processor. . . 308</p><p>I/O controller. . . 310</p><p>Memory. . . 312</p><p>Disk controller. . . 320</p><p>"Glue logic" IC. . . 314, 316, 318</p><p>Security module. . . 500</p><p>SHA-1 module. . . 504</p><p>main controller. . . 506</p><p>ROM. . . 508</p><p>Non-volatile memory ("NVM"). . . 510</p><p>External interface. . . 512</p><p>Overall. . . 514</p><p>Random number generator. . . 516</p><p>Data buffer. . . 518</p><p>Guarantee logic. . . 520</p><p>Encryption module. . . 528</p><p>Security module. . . 700</p><p>Encryption processor. . . 704</p><p>main controller. . . 706</p><p>Non-volatile memory. . . 708</p><p>Data buffer memory. . . 710</p><p>Guarantee logic. . . 712</p>

Fig. 1 is a schematic diagram of each layer in the security system; Fig. 2 is a schematic diagram of the security processing process in a computing system; Fig. 3 is a block diagram of a digital system/device according to an embodiment of the present invention; Figure 5 is a block diagram of a hardware security module according to an embodiment of the present invention; Figure 6 is a processing flow diagram of a hardware security module according to an embodiment of the present invention Flow chart; Figure 7 is a block diagram of a hardware security module according to an embodiment of the present invention.