Trusted hardware equipment supporting lattice algorithm and use method thereof
By introducing the anti-quantum digital signature algorithm DILITHIUM and PTP protocols based on grid theory in trusted hardware devices, the security problem of traditional cryptographic algorithms under quantum computer attacks is solved, and effective resistance to quantum attacks and data security is achieved. .
Patent Information
- Application Number
- CN202411643198.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-18
- Publication Date
- 2025-02-25
AI Technical Summary
Traditional cryptographic algorithms are difficult to maintain their security under the attack of quantum computers and cannot be simply replaced with post-quantum cryptographic algorithms. Especially in TPM, a new method that can resist quantum attacks is needed.
DILITHIUM, a lattice theory-resistant quantum digital signature algorithm, is introduced into trusted hardware devices, and the PTP protocol is used as a communication and transmission protocol between application software and trusted platforms to ensure that the device has the ability to resist quantum attacks.
By introducing the DILITHIUM algorithm and PTP protocol, it can effectively protect the integrity of digital identity and data, ensure the security of communications and transactions, and maintain the security performance of TPM without being significantly affected by quantum computers.
Smart Images
Figure CN119519961A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of information security technology, and in particular to a design method for a TPM resistant to quantum cryptographic algorithms. Background Art
[0002] With the rapid development of quantum computing technology, the security of traditional cryptographic algorithms is facing severe challenges. Quantum computers are a new computing paradigm that performs calculations based on the characteristics of quantum states. Due to their significantly improved computing power, quantum algorithms can greatly reduce the computational complexity of cracking traditional cryptographic algorithms, especially in cracking public key cryptographic algorithms based on large number factorization and discrete logarithm problems. Quantum computing has shown great potential. In addition, quantum algorithms can also reduce the computational overhead of cracking symmetric cryptographic algorithms and hash algorithms to half of the original time. Given that TPM widely uses public key cryptographic algorithms such as RSA and ECC to ensure data security, under the impact of quantum computing, these protected data are very likely to face the risk of leakage, which in turn poses a major threat to the security of trusted computing.
[0003] In order to ensure that TPM can still maintain its basic security functions under the attack of quantum computers, it is necessary to introduce post-quantum cryptographic algorithms into TPM. However, due to the significant differences between traditional cryptographic algorithms and post-quantum cryptographic algorithms in terms of parameter scale, computational efficiency and algorithm mechanism, it is impossible to simply replace traditional cryptographic algorithms with post-quantum cryptographic algorithms. Taking traditional public key cryptographic algorithms as an example, such as the SM2 algorithm, it can provide encryption and decryption, signature verification and key negotiation functions. Its public key length is 64 bytes, the private key length is 32 bytes, and the encrypted data length can be any bytes. Post-quantum cryptographic algorithms are mainly divided into two categories: one is the key encapsulation algorithm, such as Kyber768, which provides encryption, decryption and key encapsulation functions. The length of its public key and private key are 1184 bytes and 2400 bytes respectively. The length of the original data in the key encapsulation function is 32 bytes, and the length of the ciphertext after encapsulation is 1088 bytes; the other is the key signature algorithm, such as Dilithium3, which specializes in providing signature and verification functions. The length of its public key and private key are 1952 bytes and 4000 bytes respectively, and the signature length is 3293 bytes.
[0004] By implementing a quantum-resistant key signature algorithm on the TPM chip, the integrity of digital identities and data can be effectively protected, ensuring the security of communications and transactions. Even under the challenge of quantum computers, the security performance of TPM can be maintained without being significantly affected. Summary of the invention
[0005] A trusted hardware device supporting a lattice algorithm and a method for using the same relate to the field of information security. The present invention expands the algorithm library on the existing trusted platform architecture, introduces the quantum-resistant digital signature algorithm DILITHIUM based on the lattice theory, and adopts the PTP protocol as the communication transmission protocol between the application software and the trusted platform. The present invention refers to a solution that provides a lattice algorithm in a trusted hardware device when the trusted hardware device cannot meet the requirements of resisting quantum attacks. According to the trusted hardware device key generation method, the trusted hardware device key loading method, the trusted hardware device signature method and the trusted hardware device signature verification method, it is ensured that the trusted hardware has the ability to resist quantum attacks.
[0006] A trusted cryptographic module supporting a lattice algorithm, characterized in that it includes an input-output unit, a read-only memory, an execution controller, a cryptographic algorithm engine, a random number generator, a volatile memory, a non-volatile memory, a communication bus, and a lattice cryptographic algorithm module;
[0007] The execution controller is respectively connected with the read-only memory, the communication bus, and the input and output unit;
[0008] The execution controller is connected to the cryptographic algorithm engine, the random number generator, the non-volatile memory, the volatile memory and the lattice cryptographic algorithm module through a communication bus;
[0009] The input and output unit contains registers such as hardware status register, password register, data register, etc.
[0010] The lattice cryptographic algorithm module includes a lattice-based quantum-resistant cryptographic algorithm for generating keys and signing and verifying data;
[0011] The read-only memory contains the program code required by the trusted hardware device, including: the trusted hardware initialization code, the trusted hardware device key generation code, the trusted hardware device key loading method, the trusted hardware device signature code and the trusted hardware device signature verification code.
[0012] The method for using the trusted hardware device is characterized by comprising:
[0013] Trusted hardware device key generation method, trusted hardware device key loading method, trusted hardware device signature method and trusted hardware device signature verification method;
[0014] The specific steps are as follows:
[0015] 2.1 Trusted hardware device key generation method:
[0016] 2.1.1 The application software calls the interface of the key generation method, encodes the interface parameters into a request data message, and sends the data to the trusted hardware device through the communication protocol. At the same time, the trusted hardware state is changed from the ready state to the command execution state and blocked;
[0017] 2.1.2 The execution controller in the trusted hardware device decodes the request message, calls the random number generator to generate a random number and checks the random number. If it does not conform to the rules, it will be regenerated. If it conforms to the rules, the random number will be transmitted to the lattice cryptographic algorithm module through the communication bus. The lattice cryptographic algorithm module selects the lattice cryptographic algorithm according to the parameters to generate the corresponding public key and private key, and encrypts the public and private keys into ciphertext using symmetric encryption and returns it;
[0018] 2.1.3 The execution controller in the trusted hardware device encodes the generated public and private keys and other parameters into a response message, returns the response message through the communication protocol, and the trusted hardware state is transformed from the command execution state to the command completion state;
[0019] 2.1.4 The application software obtains the ciphertext of the generated public and private keys and saves them in a local file. After the key generation command is fully executed, the trusted hardware state will be converted back to the ready state to facilitate the execution of subsequent commands;
[0020] 2.2 Trusted hardware device key loading method:
[0021] 2.2.1 The application software calls the interface of the key loading method, encodes the interface parameters such as the ciphertext of the public key and the private key into a request data message, and sends the data to the trusted hardware device through the communication protocol. At the same time, the trusted hardware state is changed from the ready state to the command execution state and blocked;
[0022] 2.2.2 The execution controller in the trusted hardware device decodes the request message and calls the lattice cryptographic algorithm module, decrypts the public key and private key using the symmetric key and temporarily stores them in the volatile memory;
[0023] 2.2.3 The execution controller in the trusted hardware device returns a response message of successful key loading to the application software through the communication protocol, and the trusted hardware state is transformed from the command execution state to the command completion state;
[0024] 2.2.4 The application software obtains the information that the key is loaded successfully, and the trusted hardware state will be converted back to the ready state to facilitate the execution of subsequent commands;
[0025] 2.3 Trusted hardware device signature method:
[0026] 2.3.1 The application software calls the interface of the signature method, encodes the interface parameters such as the hash value of the signature data into a request data message, and sends the data to the trusted hardware device through the communication protocol. At the same time, the trusted hardware state is changed from the ready state to the command execution state and blocked;
[0027] 2.3.2 The execution controller in the trusted hardware device decodes the request message and calls the lattice cryptographic algorithm module, and reads the key from the volatile memory and transmits it to the lattice cryptographic algorithm module. The lattice cryptographic algorithm module uses the lattice cryptographic signature algorithm to sign the data based on the obtained public key and private key, and returns the result;
[0028] 2.3.3 The execution controller in the trusted hardware device encodes the response result into a response message and returns it to the application software through the communication protocol. In the input and output unit, the response message will be additionally processed. If it is determined that the message is a response message with a grid password signature, the part of the response message that belongs to the signature data will be stored in the grid password register in the input and output unit and the remaining data will be returned. The grid password register is designed to be large enough to accommodate the signature data. If it is not a response message with a grid password signature message, it returns normally. The trusted hardware state is transformed from the command execution state to the command completion state;
[0029] 2.3.4 The application software obtains the signature success information, and the signature data is saved in the register of the input and output unit. The trusted hardware state will be converted back to the ready state to facilitate the subsequent command execution;
[0030] 2.4 Trusted hardware device signature verification method:
[0031] 2.4.1 The application software calls the interface of the signature verification method, encodes the interface parameters such as the hash value of the signature data into a request data message, and sends the data to the trusted hardware device through the communication protocol. The input and output unit of the trusted hardware device will determine whether the current request message is a grid password verification message. If it is, it will read the signature result from the grid password register and connect it to the end of the request message and then forward it to the execution controller. If it is not a grid password verification request message, it will be sent directly to the execution controller. At the same time, the trusted hardware state is changed from the ready state to the command execution state and blocked;
[0032] 2.4.2 The execution controller in the trusted hardware device decodes the request message, transmits the signature result and signature data to the lattice cryptographic algorithm module, and reads the key from the volatile memory and transmits it to the lattice cryptographic algorithm module, which verifies the signature using the lattice cryptographic signature algorithm based on the obtained public key and private key, and returns the verification result;
[0033] 2.4.3 The execution controller in the trusted hardware device returns the response message encoded with the response result of the password verification to the application software through the communication protocol, and the trusted hardware status is transformed from the command execution state to the command completion state;
[0034] 2.4.4 The application software obtains the data information returned by the key verification, and the trusted hardware state will be converted back to the ready state to facilitate the execution of subsequent commands. BRIEF DESCRIPTION OF THE DRAWINGS
[0035] Figure 1 The overall architecture diagram of the trusted hardware device that supports the lattice algorithm
[0036] Figure 2 Data transmission flow chart based on PTP protocol
[0037] Figure 3 State transition diagram for the PTP protocol
[0038] Figure 4 Flowchart of signature request for DILITHIUM
[0039] Figure 5 Flowchart of the DILITHIUM signature verification request DETAILED DESCRIPTION
[0040] The present invention expands the algorithm library on the original trusted platform framework, adds the lattice-based quantum-resistant digital signature algorithm DILITHIUM algorithm, and adopts the PTP protocol as the transmission protocol between the application software and the trusted platform. It is specifically divided into four parts, according to the trusted hardware device key generation method, the trusted hardware device key loading method, the trusted hardware device signature method and the trusted hardware device signature verification method, to ensure that the trusted hardware has the ability to resist quantum attacks.
[0041] The specific implementation process is as follows:
[0042] Process 1: Initialization.
[0043] After the trusted hardware is started, the relevant registers will be initialized, the relevant bits of the status register will be set to 1, the PTP protocol module will be in the ready state, and the data register, password register, etc. will be cleared to 0. After this process, the trusted hardware can receive command requests from the application software.
[0044] Process 2: Key generation.
[0045] The application software calls the interface of the key generation method, encodes the interface parameters into a request data message, and sends the data to the trusted hardware device through the communication protocol. At the same time, the trusted hardware state is changed from the ready state to the command execution state and blocked;
[0046] The execution controller in the trusted hardware device decodes the request message, calls the random number generator to generate random numbers and checks the random numbers. If they do not conform to the rules, they will be regenerated. If they conform to the rules, the random numbers will be transmitted to the lattice cryptographic algorithm module through the communication bus. The lattice cryptographic algorithm module selects the lattice cryptographic algorithm according to the parameters to generate the corresponding public key and private key, and encrypts the public and private keys into ciphertext using symmetric encryption and returns them.
[0047] The execution controller in the trusted hardware device encodes the generated public and private keys and other parameters into a response message, returns the response message through the communication protocol, and the trusted hardware state is transformed from the command execution state to the command completion state;
[0048] The application software obtains the ciphertext of the generated public and private keys and saves them in a local file. After the key generation command is fully executed, the trusted hardware state will be converted back to the ready state to facilitate the execution of subsequent commands;
[0049] Step 3: Key loading.
[0050] The application software calls the interface of the key loading method, encodes the interface parameters such as the ciphertext of the public key and the private key into a request data message, and sends the data to the trusted hardware device through the communication protocol. At the same time, the trusted hardware state is changed from the ready state to the command execution state and blocked;
[0051] The execution controller in the trusted hardware device decodes the request message and calls the lattice cryptographic algorithm module, decrypts the public key and the private key using the symmetric key and temporarily stores them in the volatile memory;
[0052] The execution controller in the trusted hardware device returns a response message of successful key loading to the application software through the communication protocol, and the trusted hardware state is transformed from the command execution state to the command completion state;
[0053] The application software obtains the information that the key is loaded successfully, and the trusted hardware state will be converted back to the ready state to facilitate the execution of subsequent commands;
[0054] Process 4: Lattice cryptographic signature.
[0055] (1) Command interface request.
[0056] The present invention sets the command code of the DILITHIUM algorithm signature to 0x0000019B, and the parameters that need to be input are shown in Table 1:
[0057] Table 1. DILITHIUM signature interface input parameters
[0058]
[0059] After the application software enters the corresponding parameter data, the TSS_File_ReadBinaryFile function is first called to read the data file to be signed, and then the file data is hashed through the TSS_Hash_Generate function to generate the summary value to be signed. All parameter data are passed into the Dilithium_In structure, which is used to save all request parameters required by the DILITHIUM signature algorithm. Next, the signature command is executed by calling the TSS_EXCUTE function, with Dilithium_In as input, and the signature result is filled in Dilithium_Out. After that, the TSS_Marshal function is called to combine the parameter data into a request message, and the PTP_TSS_Trans function is used to transmit the message to the TPM through the PTP protocol for processing.
[0060] (2)PTP protocol transmission request message.
[0061] At this stage, the PTP protocol transmits the request message according to the SPI Bit Protocol specification. The protocol stipulates that the upper limit of the amount of data transmitted each time is 64 bytes. During the data transmission process, the data is divided into 64-byte segments and transmitted to the TPM through the data register, just like the transmission process of other commands. After receiving all the data, the TPM assembles it into a complete request message.
[0062] (3) TPM processes the request data.
[0063] After receiving the complete request message, TPM first determines the legitimacy of the command based on the command code. Subsequently, TPM uses the _rpc__Send_Command function for processing, which receives a request message of type _IN_BUFFER and a response message of type _OUT_BUFFER. In the following ExecuteCommand function, TPM gradually parses the request code, message length, session information and other parameters in the request message, and finally performs the corresponding operation according to the command code. For the DILITHIUM signature command, TPM will digitally sign the request data and return the result to the application software. The data parameters returned by the DILITHIUM algorithm are shown in Table 2.
[0064] Table 2. DILITHIUM signature interface output parameters
[0065]
[0066] (4)PTP protocol transmission response message.
[0067] In the response message processing of the DILITHIUM signature, unlike the response messages of other commands, the DILITHIUM signature will not return the message directly in 64-byte fragments. When the response message is passed to the PTP_TPM_Trans function, the function calls the TPM_CC_Unmarshal function to determine whether the current command is a DILITHIUM signature command. If the judgment result is a DILITHIUM signature command, the PTP_Dilithium function is further called to store the signature data in the DILITHIUM register with an address space of 00C0H_0EFFH. Subsequently, the data and length of the response message are modified, and the message returned to the application software will only contain the key information shown in Table 3.
[0068] It should be noted that the response message in the PTP protocol is not actively transmitted to the application software. Instead, the application software determines whether it has entered the response message transmission phase by monitoring the status of the status register, and actively reads the data register to obtain the response data. Therefore, the process is: TPM writes the data fragment to the data register, and then the application software actively reads the data from the register. Similarly, the application software can also actively request to read the DILITHIUM register to obtain the signature result.
[0069] Table 3. Actual parameters of DILITHIUM signature interface
[0070]
[0071] (5) Command interface response.
[0072] This process decodes the response message data returned by the PTP protocol into the Dilithium_Out structure according to Table 3.
[0073] Step 5: Grid password verification.
[0074] (1) Command interface request.
[0075] The command code of the DILITHIUM algorithm signature verification is set to 0x0000019C in the present invention, and the parameters to be input are shown in Table 4:
[0076] Table 4. DILITHIUM signature interface input parameters
[0077]
[0078]
[0079] In the signature verification process of the DILITHIUM digital signature algorithm, the signature verification operation can omit the step of transferring the signature data, because the signature data has been pre-stored in the DILITHIUM register. Therefore, during the signing and verification process, if no new signature operation is performed, there is no need to transmit the signature data again. The signature verification process is basically consistent with the processing process of the DILITHIUM signature algorithm, which simplifies data transmission and optimizes the operating efficiency of the system.
[0080] (2) Protocol transmission request message.
[0081] In the PTP_TPM_Receive function, the received message will be parsed and judged by the TPM_CC_Unmarshal function. If the current command code is 0x0000019C, the length of the request message is checked first. If the request message does not contain the signature result, the system will read the signature data from the DILITHIUM register and append it to the end of the request message, and update the signature length. Therefore, the signature verification request message received by the TPM will contain the complete signature data to ensure the correct execution of the signature verification operation.
[0082] (3) TPM processes the request data.
[0083] The TPM's processing logic for signature verification is consistent with that for signature. It decodes the request message, calls the corresponding function according to the command code, and returns the processing result. The return parameters of signature verification are shown in Table 5.
[0084] Table 5. DILITHIUM signature verification interface output parameters
[0085]
[0086]
[0087] (4)PTP protocol transmission response message.
[0088] Normally, the response data is transmitted to the application software through the data register of the PTP protocol.
[0089] (5) Command interface response.
Claims
1. A trusted cryptographic module supporting a lattice algorithm, characterized in that: It includes an input and output unit, a read-only memory, an execution controller, a cryptographic algorithm engine, a random number generator, a volatile memory, a non-volatile memory, a communication bus and a lattice cryptographic algorithm module; The execution controller is respectively connected with the read-only memory, the communication bus, and the input and output unit; The execution controller is connected to the cryptographic algorithm engine, the random number generator, the non-volatile memory, the volatile memory and the lattice cryptographic algorithm module through a communication bus; The input and output unit contains registers such as hardware status register, password register, data register, etc. The lattice cryptographic algorithm module includes a lattice-based quantum-resistant cryptographic algorithm for generating keys and signing and verifying data; The read-only memory contains the program code required by the trusted hardware device, including: the trusted hardware initialization code, the trusted hardware device key generation code, the trusted hardware device key loading method, the trusted hardware device signature code and the trusted hardware device signature verification code.
2. A method for using a trusted hardware device as claimed in claim 1, characterized in that it comprises: a trusted hardware device key generation method, a trusted hardware device key loading method, a trusted hardware device signature method and a trusted hardware device signature verification method: The specific steps are as follows: 2.1 Trusted hardware device key generation method: 2.1.1 The application software calls the interface of the key generation method, encodes the interface parameters into a request data message, and sends the data to the trusted hardware device through the communication protocol. At the same time, the trusted hardware state is changed from the ready state to the command execution state and blocked; 2.1.2 The execution controller in the trusted hardware device decodes the request message, calls the random number generator to generate a random number and checks the random number. If it does not conform to the rules, it will be regenerated. If it conforms to the rules, the random number will be transmitted to the lattice cryptographic algorithm module through the communication bus. The lattice cryptographic algorithm module selects the lattice cryptographic algorithm according to the parameters to generate the corresponding public key and private key, and encrypts the public and private keys into ciphertext using symmetric encryption and returns it; 2.1.3 The execution controller in the trusted hardware device encodes the generated public and private keys into a response message, returns the response message through the communication protocol, and the trusted hardware state is transformed from the command execution state to the command completion state; 2.1.4 The application software obtains the ciphertext of the generated public and private keys and saves them in a local file; the key generation command is fully executed and the trusted hardware state is converted back to the ready state to facilitate the execution of subsequent commands; 2.2 Trusted hardware device key loading method: 2.2.1 The application software calls the interface of the key loading method, encodes the interface parameters such as the ciphertext of the public key and the private key into a request data message, and sends the data to the trusted hardware device through the communication protocol. At the same time, the trusted hardware state is changed from the ready state to the command execution state and blocked; 2.2.2 The execution controller in the trusted hardware device decodes the request message and calls the lattice cryptographic algorithm module, decrypts the public key and private key using the symmetric key and temporarily stores them in the volatile memory; 2.2.3 The execution controller in the trusted hardware device returns a response message of successful key loading to the application software through the communication protocol, and the trusted hardware state changes from the command execution state to the command completion state; 2.2.4 The application software obtains the information that the key is loaded successfully, and the trusted hardware state will be converted back to the ready state to facilitate the execution of subsequent commands; 2.3 Trusted hardware device signature method: 2.3.1 The application software calls the interface of the signature method, encodes the interface parameters such as the hash value of the signature data into a request data message, and sends the data to the trusted hardware device through the communication protocol. At the same time, the trusted hardware state is changed from the ready state to the command execution state and blocked; 2.3.2 The execution controller in the trusted hardware device decodes the request message and calls the lattice cryptographic algorithm module, and reads the key from the volatile memory and transmits it to the lattice cryptographic algorithm module. The lattice cryptographic algorithm module uses the lattice cryptographic signature algorithm to sign the data based on the obtained public key and private key, and returns the result; 2.3.3 The execution controller in the trusted hardware device encodes the response result into a response message and returns it to the application software through the communication protocol; in the input and output unit, the response message will be additionally processed. If it is determined that the message is a response message with a grid password signature, the part of the response message that belongs to the signature data will be stored in the grid password register in the input and output unit and the remaining data will be returned. The grid password register is designed to be large enough to accommodate the signature data; If it is not a response message of a lattice password signature message, it returns normally; The trusted hardware state changes from the command execution state to the command completion state; 2.3.4 The application software obtains the signature success information, and the signature data is saved in the register of the input and output unit. The trusted hardware state will be converted back to the ready state to facilitate the subsequent command execution; 2.4 Trusted hardware device signature verification method: 2.4.1 The application software calls the interface of the signature verification method, encodes the interface parameters such as the hash value of the signature data into a request data message, and sends the data to the trusted hardware device through the communication protocol. The input and output unit of the trusted hardware device will determine whether the current request message is a grid password verification message. If it is, it will read the signature result from the grid password register and connect it to the end of the request message and then forward it to the execution controller. If it is not a grid password verification request message, it will be sent directly to the execution controller. At the same time, the trusted hardware state is changed from the ready state to the command execution state and blocked; 2.4.2 The execution controller in the trusted hardware device decodes the request message, transmits the signature result and signature data to the lattice cryptographic algorithm module, and reads the key from the volatile memory and transmits it to the lattice cryptographic algorithm module, which verifies the signature using the lattice cryptographic signature algorithm based on the obtained public key and private key, and returns the verification result; 2.4.3 The execution controller in the trusted hardware device returns the response message encoded with the response result of the password verification to the application software through the communication protocol, and the trusted hardware status is transformed from the command execution state to the command completion state; 2.4.4 The application software obtains the data information returned by the key verification, and the trusted hardware state will be converted back to the ready state to facilitate the execution of subsequent commands.