Digital signature generation method, secret key generation method and digital signature generation system

Abstract

The invention provides a digital signature generation method, a key generation method and a digital signature generation system, which are applied to a first device, and the method comprises the following steps: obtaining a key generation result in the first device; the key generation result comprises a main private key seed and a plurality of pre-stored hash values; determining a signature value corresponding to the to-be-signed data based on the to-be-signed data and the main private key seed; under the condition that the plurality of pre-stored hash values are a plurality of second hash values and do not include the plurality of first hash values, determining a first authentication path based on the main private key seed, and obtaining a second authentication path from the plurality of second hash values; determining a target authentication path corresponding to the target hash value based on the first authentication path and the second authentication path; the target hash value is a hash value which is not used in the historical digital signature generation process in the plurality of first hash values; and based on the signature value and the target authentication path, determining a signature result corresponding to the to-be-signed data. According to the invention, the digital signature efficiency can be improved.

Description

Technical Field

[0001] This application relates to digital signature technology, and more particularly to a digital signature generation method, a key generation method, and a digital signature generation system. Background Technology

[0002] With the rapid development of quantum computing, traditional digital signature algorithms based on large number factorization and the discrete logarithm problem face the threat of being broken by quantum computers. Therefore, post-quantum cryptography algorithms have become a key area of ​​research and application in cryptography. Among them, the hash-based stateful digital signature algorithm (Leighton-Micali Signature, LMS) is one such post-quantum signature algorithm, possessing advantages such as high security, algorithmic simplicity, and ease of implementation.

[0003] The LMS algorithm is implemented based on a Merkle tree structure. The Merkle tree contains multiple leaf nodes, each corresponding to a key pair. This key pair is a one-time signature key pair generated using the Leighton-Micali One-Time Signature (LM-OTS) scheme within the LMS algorithm. During key generation, LM-OTS key pairs for all leaf nodes need to be generated, and the hash values ​​of all nodes in the entire Merkle tree are calculated from the bottom up, ultimately obtaining the hash value of the root node as the root public key. Similarly, during the signing process, the entire Merkle tree needs to be traversed to generate the authentication path corresponding to the specified leaf node.

[0004] However, because the standard LMS algorithm uses real-time computation, the computing device needs to regenerate the hash value of each leaf node (i.e., the key pair corresponding to each leaf node) and calculate the authentication path corresponding to the specified leaf node every time a signature is made. In other words, the computing device needs to traverse and calculate the hash values ​​of a large number of leaf nodes every time a signature is made, resulting in the repeated calculation of the hash values ​​of the same nodes, thus generating serious computational redundancy and reducing the efficiency of digital signatures. Summary of the Invention

[0005] This application provides a digital signature generation method, a key generation method, and a digital signature generation system, which can improve the efficiency of digital signature generation.

[0006] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide a digital signature generation method applied to a first device. The method includes: obtaining a key generation result in the storage area of ​​the first device; the key generation result includes a master private key seed and multiple pre-stored hash values; the key generation result is obtained by processing the master private key seed based on a key generation algorithm; obtaining data to be signed, and determining a signature value corresponding to the data to be signed based on the data to be signed and the master private key seed; in the case where multiple pre-stored hash values ​​are multiple second hash values ​​and do not include multiple first hash values, determining a first authentication path corresponding to a target hash value based on the master private key seed, and obtaining a second authentication path corresponding to the target hash value from among the multiple second hash values; the target hash value is a hash value among the multiple first hash values ​​that has not been used in the historical digital signature generation process; determining a target authentication path corresponding to the target hash value based on the first authentication path and the second authentication path; and determining a signature result corresponding to the data to be signed based on the signature value and the target authentication path.

[0007] In this embodiment of the application, when the first device performs digital signature, if it pre-stores the second hash value corresponding to all internal nodes, the first device only needs to calculate the hash value of a leaf node based on the master private key seed as the first authentication path in the target authentication path. The other authentication paths (i.e. the second authentication paths) in the target authentication path only need to be read from the storage area, so that the required storage space is small while the computational overhead can be greatly reduced compared with the standard LMS scheme.

[0008] In some implementations, before determining the signature result corresponding to the data to be signed based on the signature value and the target authentication path, the method further includes: in the case that multiple pre-stored hash values ​​are multiple first hash values ​​and do not include multiple second hash values, obtaining the target hash value from the multiple first hash values ​​in the storage area; and determining the target authentication path corresponding to the target hash value based on the multiple first hash values.

[0009] In this embodiment of the application, when the first device performs digital signature, if it only pre-stores the first hash value corresponding to all leaf nodes, the first device can read the first hash value corresponding to all pre-stored leaf nodes and calculate the corresponding target authentication path based on the first hash value corresponding to the leaf node. There is no need to regenerate the first hash value of the leaf node, but only to perform hash merging calculation of the internal nodes. The computational overhead is greatly reduced compared with the standard LMS scheme.

[0010] In some implementations, before determining the signature result corresponding to the data to be signed based on the signature value and the target authentication path, the method further includes: in the case of multiple pre-stored hash values ​​being multiple first hash values ​​and multiple second hash values, obtaining a target hash value from multiple first hash values ​​in the storage area; and obtaining a target authentication path from multiple first hash values ​​and multiple second hash values ​​in the storage area based on the target hash value.

[0011] In this embodiment of the application, if the storage device pre-stores the first hash value corresponding to all leaf nodes and the second hash value corresponding to all internal nodes, the first device can directly read the internal nodes required by the target authentication path without any additional hash calculation, thereby completely avoiding the repeated calculation of the hash value of other leaf nodes when performing different digital signatures.

[0012] In some implementations, multiple first hash values ​​are hash values ​​corresponding to multiple leaf nodes, multiple second hash values ​​are hash values ​​corresponding to multiple internal nodes, and the multiple leaf nodes and multiple internal nodes are nodes in a binary tree. The binary tree includes multiple levels, with the multiple leaf nodes located at the first level and the multiple internal nodes located at the second level above the first level. The process involves determining the first authentication path corresponding to the target hash value based on the master private key seed, and obtaining the second authentication path corresponding to the target hash value from among the multiple second hash values. This includes: when the current traversal level is less than the highest level of the binary tree, determining the level of the current sibling node in the binary tree based on the current node; the current node includes the target... Leaf nodes, the hash value corresponding to the target leaf node is the target hash value. Nodes in the binary tree include the current leaf node and the current sibling node. If the current sibling node is at the first level in the binary tree, the first hash value corresponding to the current sibling node is determined based on the master private key seed, and the first hash value corresponding to the current sibling node is determined as the first authentication path. If the current sibling node is at the second level in the binary tree, the second hash value corresponding to the current sibling node is obtained from the storage area, and the second hash value corresponding to the current sibling node is determined as the second authentication path. The current traversal level is updated according to the preset step, and the parent node corresponding to the current node is determined so that the parent node is determined as the updated current node.

[0013] In this embodiment, if the second hash value corresponding to all internal nodes is pre-stored, then only the hash value of a leaf node needs to be calculated based on the master private key seed as the first authentication path in the target authentication path. The other authentication paths in the target authentication path (i.e. the second authentication path) only need to be read from the storage area. Thus, while requiring less storage space, the computational overhead can be significantly reduced compared to the standard LMS scheme. Moreover, this storage method is the best solution to achieve a balance between storage space and performance, and is especially suitable for large tree height scenarios with H≥15 and limited storage.

[0014] In some implementations, multiple first hash values ​​are hash values ​​corresponding to multiple leaf nodes, multiple second hash values ​​are hash values ​​corresponding to multiple internal nodes, the multiple leaf nodes and multiple internal nodes are nodes in a binary tree, the binary tree includes multiple levels, the multiple leaf nodes are located at the first level, and the multiple internal nodes are located at the second level above the first level; determining the target authentication path corresponding to the target hash value based on the multiple first hash values ​​includes: if the traversal of multiple leaf nodes is not completed, determining whether the current traversal level is less than the highest level of the binary tree; if the current traversal level is less than the highest level of the binary tree, and if the current leaf node is a sibling node of the current target node, then writing the first hash value of the current leaf node into the target authentication path; the current target node includes a target leaf node, and the hash value corresponding to the target leaf node is the target hash value. The multiple leaf nodes include the target leaf node and its sibling nodes; if the current leaf node is a left node, the hash value of the current leaf node is stored in the computation stack, and the next leaf node of the current leaf node is traversed; if the current leaf node is a right node, the hash value of the sibling node corresponding to the current leaf node is obtained from the computation stack; and, based on the hash value of the current leaf node and the hash value of the sibling node corresponding to the current leaf node, a second hash value of the parent node corresponding to the current leaf node is generated, and the current traversal level is updated according to a preset step; the multiple internal nodes include parent nodes; and, the parent node corresponding to the current target node is determined so as to determine the parent node corresponding to the current target node as the updated current target node; and, the parent node corresponding to the current leaf node is determined so as to determine the parent node corresponding to the current leaf node as the updated current target node.

[0015] In this embodiment, if only the first hash values ​​corresponding to all leaf nodes are pre-stored, the first device can read the first hash values ​​of all pre-stored leaf nodes and dynamically calculate the corresponding target authentication path through bottom-up hash merging. Since the first hash values ​​of the leaf nodes have been pre-calculated by the second device, the first device does not need to regenerate the hash values ​​of the leaf nodes, nor does it need to traverse the entire Merkle tree again. It only needs to perform hash merging calculations of the internal nodes, which significantly reduces the computational overhead compared to the standard LMS scheme, thereby improving the digital signature performance of the first device by several orders of magnitude. In addition, the Merkle tree traversal calculation only needs to be performed once on the second device, and the first device does not need to bear this computational burden.

[0016] In some implementations, multiple first hash values ​​are hash values ​​corresponding to multiple leaf nodes, and multiple second hash values ​​are hash values ​​corresponding to multiple internal nodes. The multiple leaf nodes and multiple internal nodes are nodes in a binary tree, which includes multiple levels. The multiple leaf nodes are located at the first level, and the multiple internal nodes are located at the second level above the first level. Obtaining the target authentication path from the multiple first hash values ​​and multiple second hash values ​​in the storage area based on the target hash value includes: when the current traversal level is less than the highest level of the binary tree, determining the level of the current sibling node in the binary tree based on the current node; the current node includes the target... Leaf nodes, the hash value corresponding to the target leaf node is the target hash value. Nodes in the binary tree include the current leaf node and the current sibling node. If the current sibling node is at the first level in the binary tree, then the first hash value corresponding to the current sibling node is obtained from the storage area. If the current sibling node is at the second level in the binary tree, then the second hash value corresponding to the current sibling node is obtained from the storage area. The first hash value or the second hash value corresponding to the current sibling node is written into the target authentication path. The current traversal level is updated according to the preset step, and the parent node corresponding to the current node is determined so that the parent node is determined as the updated current node.

[0017] In this embodiment, if the first hash value corresponding to all leaf nodes and the second hash value corresponding to all internal nodes are pre-stored, the first device can directly read the internal nodes required for the target authentication path without any additional hash calculations or re-traversing the entire Merkle tree. This completely avoids the repeated calculation of hash values ​​for other leaf nodes when performing different digital signatures, thereby improving the digital signature performance of the first device by several orders of magnitude. Furthermore, the Merkle tree traversal calculation only needs to be performed once on the second device, eliminating the computational burden on the first device.

[0018] In some implementations, the key generation result also includes a count value, which indicates the number of times multiple first hash values ​​have been used in the historical digital signature generation process; determining the signature value corresponding to the data to be signed based on the data to be signed and the master private key seed, including: determining the signature value corresponding to the data to be signed based on the data to be signed and the master private key seed when the count value is less than the total number of multiple first hash values; determining the signature result corresponding to the data to be signed based on the signature value and the target authentication path, including: determining the signature result corresponding to the data to be signed based on the count value, the signature value, and the target authentication path; incrementing the count value according to a preset step to obtain an updated count value, and writing the updated count value into the key generation result.

[0019] In this embodiment of the application, updating the signature count value ensures that the hash value of each leaf node is used only once, thereby avoiding the risk of reusing one-time signature keys and ensuring data security.

[0020] In some implementations, the key generation result further includes preset parameters, including iteration parameters corresponding to the target hash value and a preset number of hash chains; determining the signature value corresponding to the data to be signed based on the data to be signed and the master private key seed includes: determining the digest value corresponding to the data to be signed based on a hash algorithm; determining the iteration number of each hash chain in the multiple hash chains based on the digest value and iteration parameters; performing iterative hashing on the master private key seed based on the iteration number of each hash chain to obtain the signature component corresponding to each hash chain; and concatenating the signature components corresponding to each hash chain to obtain the signature value corresponding to the data to be signed.

[0021] In this embodiment, all LMS parameter sets (H5 / H10 / H15 / H20 / H25) and all LM-OTS parameter sets (W1 / W2 / W4 / W8) defined in RFC8554 can be supported, and the optimal parameter combination can be selected according to the specific application scenario (signature count requirements, storage capacity, real-time requirements) to avoid resource waste.

[0022] In some implementations, obtaining the key generation result in the storage area of ​​the first device includes: encrypting the key generation result based on a one-time programmable key to obtain an encrypted key generation result; storing the encrypted key generation result in the storage area in a preset storage format; in response to a digital signature request, obtaining the encrypted key generation result in the storage area based on the preset storage format; and decrypting the encrypted key generation result based on the one-time programmable key to obtain a decrypted key generation result.

[0023] In this embodiment of the application, by encrypting the pre-computed data using the device's unique OTP key before storing it, it can be ensured that even if the storage device is physically read, attackers cannot obtain the plaintext key data, thereby improving the security of the key.

[0024] On the other hand, embodiments of this application provide a key generation method applied to a second device. The method includes: obtaining key generation parameters and a master private key seed; generating multiple first hash values ​​based on the key generation parameters and the master private key seed; the key generation parameters are used to determine the number of multiple first hash values; performing bottom-up, layer-by-layer hash merging calculation on the multiple first hash values ​​to obtain multiple second hash values; transmitting the key generation result to a first device; the key generation result includes the master private key seed and multiple pre-stored hash values; the multiple pre-stored hash values ​​include multiple first hash values, or include multiple first hash values ​​and multiple second hash values.

[0025] In this embodiment, a second device with strong computing power performs the complete key generation process, including traversing all leaf nodes to generate keys and calculating the node hash values ​​required for all authentication paths. The pre-computed data is stored in a first device with weak computing power (such as an embedded device), thereby improving the efficiency of the first device when performing digital signature calculations.

[0026] In some implementations, multiple first hash values ​​are hash values ​​corresponding to multiple leaf nodes; generating multiple first hash values ​​based on key generation parameters and master private key seed includes: determining the number of multiple leaf nodes based on key generation parameters; determining the first hash value corresponding to the current leaf node among multiple leaf nodes when the number of the current leaf node is less than or equal to the number of multiple leaf nodes; writing the first hash value corresponding to the current leaf node into the memory buffer of the second device to determine the current leaf node as the current traversal node; transmitting the key generation result to the first device includes: transmitting the first hash value corresponding to the current traversal node stored in the memory buffer to the first device.

[0027] In this embodiment, while the second device is calculating the hash value of the leaf node, it writes the pre-calculated hash value data of the leaf node to the first device. This eliminates the need to store the hash values ​​of all nodes in the entire Merkle tree in the memory module of the second device, thereby greatly reducing the memory consumption of the second computing device.

[0028] In some implementations, a bottom-up, layer-by-layer hash merging calculation is performed on multiple first hash values ​​to obtain multiple second hash values, including: if the currently traversed node is a left node, then the first hash value corresponding to the currently traversed node is written into the calculation stack; if the currently traversed node is a right node, then the first hash value of the sibling node corresponding to the currently traversed node is obtained from the calculation stack; based on the first hash value corresponding to the sibling node and the first hash value corresponding to the currently traversed node stored in the memory buffer, the second hash value of the parent node corresponding to the currently traversed node is determined; the second hash value of the parent node is written into the memory buffer to determine the parent node as the currently traversed node; the second hash value corresponding to the currently traversed node is written into the calculation stack; the method further includes: transmitting the second hash value corresponding to the currently traversed node to a first device.

[0029] In this embodiment, while the Merkle tree is dynamically constructed by the second device, the hash values ​​of the pre-computed internal nodes are written to the first device. This eliminates the need to store the hash values ​​of the internal nodes in the memory module of the second device, thereby greatly reducing the memory consumption of the second computing device.

[0030] On the other hand, embodiments of this application provide a digital signature generation system, which includes a first device and a second device; wherein the first device is used to implement a digital signature generation method, and the second device is used to implement a key generation method.

[0031] On the other hand, embodiments of this application provide a digital signature generation apparatus, which includes: a first acquisition module, a first determination module, a second determination module, a third determination module, and a fourth determination module. The first acquisition module is configured to acquire a key generation result from the storage area of ​​a first device; wherein the key generation result includes a master private key seed and multiple pre-stored hash values; the multiple pre-stored hash values ​​include multiple first hash values ​​and / or multiple second hash values; the multiple second hash values ​​are determined based on the multiple first hash values; the key generation result is obtained by the second device processing the master private key seed based on a key generation algorithm; the first determination module is configured to acquire data to be signed and determine the key generation result based on the data to be signed and the master private key seed. The key seed determines the signature value corresponding to the data to be signed; the second determining module is configured to determine the first authentication path corresponding to the target hash value based on the master private key seed, and obtain the second authentication path corresponding to the target hash value from among the multiple second hash values, where the target hash value is a hash value among the multiple first hash values ​​that was not used in the historical digital signature generation process; the third determining module is configured to determine the target authentication path corresponding to the target hash value based on the first authentication path and the second authentication path; the fourth determining module is configured to determine the signature result corresponding to the data to be signed based on the signature value and the target authentication path.

[0032] On the other hand, embodiments of this application provide a key generation device, which includes: a second acquisition module, a seventh determination module, an eighth determination module, and a writing module. The second acquisition module is configured to acquire key generation parameters and a master private key seed. The seventh determination module is configured to generate multiple first hash values ​​based on the key generation parameters and the master private key seed. The key generation parameters are used to determine the number of the multiple first hash values. The eighth determination module is configured to perform bottom-up, layer-by-layer hash merging calculations on the multiple first hash values ​​to obtain multiple second hash values. The writing module is configured to write the key generation result to a first device. The key generation result includes the master private key seed and multiple pre-stored hash values. The multiple pre-stored hash values ​​include multiple first hash values, or include multiple first hash values ​​and multiple second hash values.

[0033] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a data caching circuit, implements some or all of the steps in the above-described digital signature generation method or key generation method.

[0034] On the other hand, embodiments of this application provide a program product that includes a computer program or instructions, which, when executed by a data caching circuit, implement some or all of the steps in the digital signature generation method or key generation method described above.

[0035] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of a digital signature generation system provided in an embodiment of this application; Figure 2 A schematic diagram illustrating an LMS digital signature productization scheme provided in an embodiment of this application; Figure 3 A schematic diagram of a Merkle tree provided for an embodiment of this application; Figure 4 A schematic diagram illustrating the implementation flow of a digital signature generation method provided in an embodiment of this application; Figure 5 A schematic diagram illustrating the implementation flow of a key generation method provided in an embodiment of this application; Figure 6 This is a schematic diagram of the composition structure of a digital signature generation device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the composition structure of a key generation device provided in an embodiment of this application.

[0037] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0039] In the following description, references to "some embodiments" are made, which describe a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict. The terms "first / second / third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0040] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0041] The following explains the relevant terms used in this application: LMS algorithm: A hash-based stateful digital signature algorithm defined in the RFC 8554 standard.

[0042] LM-OTS: The one-time signature scheme used in the LMS algorithm. Each leaf node corresponds to an LM-OTS key pair (public key and private key).

[0043] Merkle tree: A Merkle tree (or hash tree) is a complete binary tree structure and the core data structure of the LMS algorithm. Each leaf node of the tree corresponds to an LM-OTS public key, and the hash value of an internal node is determined based on the hash values ​​of its child nodes.

[0044] LM-OTS Public Key: A 32-byte hash value obtained by aggregating and hashing the endpoint values ​​of the p hash chains corresponding to the leaf nodes.

[0045] RFC 8554 standard: A standard document published by the Internet Engineering Task Force (IETF) that defines the complete specifications for the LMS and LM-OTS algorithms.

[0046] H5: The parameter set (LMS_SHA256_M32_H5) with a tree height of 5 in the LMS algorithm, corresponding to 2^5=32 leaf nodes, which can support a maximum of 32 signatures.

[0047] H10: The parameter set (LMS_SHA256_M32_H10) with a tree height of 10 in the LMS algorithm, corresponding to 2^10 = 1,024 leaf nodes, which can support a maximum of 1,024 signatures.

[0048] H15: The parameter set (LMS_SHA256_M32_H15) with a tree height of 15 in the LMS algorithm, corresponding to 2^15=32,768 leaf nodes, which can support a maximum of 32,768 signatures.

[0049] H20: The parameter set (LMS_SHA256_M32_H20) with a tree height of 20 in the LMS algorithm, corresponding to 2^20 = 1,048,576 leaf nodes, which can support a maximum of 1,048,576 signatures.

[0050] H25: The parameter set (LMS_SHA256_M32_H25) with a tree height of 25 in the LMS algorithm, corresponding to 2^25=33,554,432 leaf nodes, which can support a maximum of 33,554,432 signatures.

[0051] w: The Winderitz parameter controls the balance between signature size and computational complexity in the LM-OTS algorithm, with values ​​ranging from 1, 2, 4, to 8. The maximum number of iterations per hash chain is 2^w - 1. A larger w results in a shorter signature but a higher computational cost.

[0052] W1: The parameter set (LMOTS_SHA256_N32_W1) in the LM-OTS algorithm where the Winternitz parameter is 1. It contains 265 hash chains, each iterating once (2^1-1). Generating a single LM-OTS public key requires 265 hash calculations. It has the largest signature but is the fastest to compute.

[0053] W2: The parameter set (LMOTS_SHA256_N32_W2) in the LM-OTS algorithm with a Winderitz parameter of 2, contains 133 hash chains, each iterating 3 times (2^2-1). Generating a single LM-OTS public key requires 399 hash calculations. This achieves a balance between signature size and computational cost.

[0054] W4: The parameter set (LMOTS_SHA256_N32_W4) with a Winternitz parameter of 4 in the LM-OTS algorithm. It contains 67 hash chains, each iterating 15 times (2^4-1). Generating a single LM-OTS public key requires 1,005 hash calculations. A commonly used compromise configuration.

[0055] W8: The parameter set (LMOTS_SHA256_N32_W8) with a Winternitz parameter of 8 in the LM-OTS algorithm. It contains 34 hash chains, each iterating 255 times (2^8-1). Generating a single LM-OTS public key requires 8,670 hash calculations. It has the smallest signature but the largest computational cost.

[0056] p: Number of Hash Chains in LM-OTS, determined by the Winternitz parameter w. RFC8554 defines p as follows: p=265 for W1, p=133 for W2, p=67 for W4, and p=34 for W8. A larger p value results in a longer signature but fewer iterations per chain.

[0057] `ls`: Checksum Left Shift, a parameter used in the LM-OTS algorithm to calculate the checksum and align it to the w-bit boundary. RFC8554 defines the following values: `ls=7` for W1, `ls=6` for W2, `ls=4` for W4, and `ls=0` for W8.

[0058] Authentication Path: In a Merkle tree, it is a sequence of hash values ​​of all sibling nodes (including the sibling nodes of the leaf node, the sibling nodes corresponding to the parent node of the leaf node, etc.) on the path from one of the leaf nodes to the root node. It is used to reconstruct the hash value of the root node (i.e., the root public key) during signature verification.

[0059] Signature count value: ranges from [0, 2^h-1], indicating which leaf node (i.e. which LM-OTS key pair) in the Merkle tree is currently being used for signing.

[0060] coef(S,i,w): Coefficient Extraction Function, defined in RFC8554, is used to extract the i-th w-bit coefficient from the byte string S. The return value is an integer between 0 and 2^w-1, representing the number of iterations required for the i-th hash chain.

[0061] Post-quantum cryptography: cryptographic algorithms that can resist attacks from quantum computers. LMS is one of the post-quantum signature algorithms recommended by NIST.

[0062] Hash function: A one-way function that maps input data of arbitrary length to a fixed-length output (hash value / digest).

[0063] RSA: A digital signature or encryption / decryption algorithm based on the large number factorization problem.

[0064] ECDSA: A digital signature algorithm based on the elliptic curve discrete logarithm problem.

[0065] SM2: China's digital signature algorithm based on the elliptic curve discrete logarithm problem, is a type of commercial cryptographic algorithm.

[0066] ||: Cascade operation.

[0067] In related technologies, because computing devices need to re-traverse the leaf nodes of the Merkle tree and calculate a large number of hash values ​​each time they perform digital signatures based on the LMS algorithm, the signature performance of the computing device deteriorates exponentially as the height of the Merkle tree increases. Taking W8 as an example, 99% of the hash calculations occur during the hash chain iteration process of the LMS OTS signature. There are 34 hash chain iterations, and each hash chain requires 255 hash calculations. 1. When the Merkle tree height is 5, H5 needs to traverse 2^5=32 leaf nodes. Signing a leaf node requires approximately 8670 (34×255) hash calculations. When calculating the authentication path, the hash values ​​of other nodes also need to be calculated. Therefore, a single LMS signature requires approximately 277,000 (34×255×32) hash calculations in total. 2. When the Merkle tree height is 10, H10 needs to traverse 2^10 = 1,024 leaf nodes. Signing a leaf node requires approximately 8,670 (34 × 255) hash calculations. When calculating the authentication path, the hash values ​​of other nodes also need to be calculated. Therefore, a single LMS signature requires approximately 8.88 million (34 × 255 × 1024) hash calculations in total. 3. When the Merkle tree height is 15, H15 requires traversing 2^15 = 32,768 leaf nodes. Signing a leaf node requires approximately 8,670 (34 × 255) hash calculations. When calculating the authentication path, the hash values ​​of other nodes also need to be calculated. Therefore, a single LMS signature requires approximately 284 million (34 × 255 × 32,768) hash calculations in total.

[0068] For large parameter sets (H20, H25), the performance problem is even more severe: 1. When the Merkle tree height is 20, H20 needs to traverse 2^20 = 1,048,576 leaf nodes. Signing a leaf node requires approximately 8,670 (34 × 255) hash calculations. When calculating the authentication path, the hash values ​​of other nodes also need to be calculated. Therefore, a single LMS signature requires approximately 9.1 billion (34 × 255 × 1,048,576) hash calculations in total. 2. When the Merkle tree height is 25, H25 requires traversing 2^25 = 33,554,432 leaf nodes. Signing a leaf node requires approximately 8,670 (34 × 255) hash calculations. When calculating the authentication path, the hash values ​​of other nodes also need to be calculated. Therefore, a single LMS signature requires approximately 290.9 billion (34 × 255 × 33554432) hash calculations in total.

[0069] Because embedded devices typically operate at frequencies ranging from tens to hundreds of MHz, their computing power is limited. Therefore, even with small parameter sets like H10 and H15, embedded devices require millions to hundreds of millions of hash calculations for signing, making it difficult to meet the real-time requirements of scenarios such as firmware signing and secure boot, device authentication, secure communication handshakes, and data integrity protection. Large parameter sets like H20 and H25 require hundreds of millions to tens of billions of hash calculations; this order-of-magnitude computational burden makes the standard LMS algorithm virtually impossible to implement on embedded devices with limited hash performance. The fundamental reason is that when using the same LMS key pair to perform different signatures, each signature requires calculating the authentication path, and this calculation depends on the public keys of other leaf nodes in the Merkle tree. Since the standard algorithm uses real-time computation, each signature requires re-traversing and calculating a large number of leaf nodes, resulting in repeated calculations of the same LM-OTS public key, leading to severe computational redundancy. In other words, in the existing digital signature process, different signatures require a lot of repeated calculations on the authentication path. Especially when the Merkle tree is higher, the resource consumption is large (for example, the calculation of H20 / H25 may require up to several gigabytes of memory space). Therefore, it is not easy to port to low-cost, resource-constrained embedded devices, which greatly limits the promotion and popularization of the LMS algorithm.

[0070] Based on the above-mentioned technical problems, this application provides a digital signature generation method, a key generation method, and a digital signature generation system, enabling embedded devices with limited hash calculation performance to achieve efficient digital signature calculation.

[0071] Figure 1 This is a schematic diagram of a digital signature generation system provided in an embodiment of this application, such as... Figure 1 As shown, the digital signature generation system 100 includes a first device 110 and a second device 120, and the first device 110 includes a storage device 130.

[0072] The second device 120 can be a device with strong computing power, such as a server or computer, used to perform the pre-computation process for key generation. The first device 110 can be a device with similar computing power to the second device 120, or it can be a device with limited computing power and storage resources, such as an embedded device. Embedded devices may include microcontroller units (MCUs), security chips, Internet of Things (IoT) modules, etc. The storage device 130 can be a non-volatile storage medium, such as flash memory, used to store the pre-computation data generated by the second device 120.

[0073] refer to Figure 2The diagram shown illustrates a productized LMS digital signature solution. Figure 2 As shown, the second device (or host) 120 may be equipped with pre-computation tool software to perform the pre-computation process for key generation, such as traversing the Merkle tree to generate keys and calculate authentication paths, and generating a mirror file of the pre-computation data; wherein, the mirror file output by the second device 120 may be a binary file.

[0074] In some implementations, the first device 110 may include an ARM Cortex-M series MCU or a dedicated security chip as the main control chip, and may be equipped with an SHA256 hardware accelerator to accelerate hash calculation. The first device 110 may have built-in FLASH memory with a storage space of 1.5KB-64KB (suitable for H5 / H10 parameter sets); or, the first device 110 may have external NOR Flash memory with a storage space of 1MB (suitable for H15 parameter sets); or, the first device 110 may have external NAND Flash, embedded Multi-Media Card (eMMC), or other memory with a storage space of 32MB-2GB (suitable for H20 / H25 parameter sets or optimized storage solutions).

[0075] The first device 110 may be equipped with an access-based signature device module for generating digital signatures. For example, the access-based signature device module in the first device 110 may include an LMS signature library and a Flash driver, wherein the LMS signature library is used as an application programming interface (API) to call the digital signature algorithm; and the Flash driver is used to read pre-computed data stored in the Flash memory.

[0076] For example, to protect the security of pre-computed data in storage device 130, the first device 110 can implement a data protection mechanism for storage device 130. For instance, Read Protection (RDP) can be enabled on storage device 130 to prevent the pre-computed data in storage device 130 from being read. The RDP level can be Level 1 or Level 2. RDP Level 1 indicates protection enabled, prohibiting reading Flash via the debug interface, and attempts to downgrade to Level 0 (no protection, allowing direct reading of the memory content via debug interfaces (such as SWD / JTAG)) will trigger a full erase. RDP Level 2 indicates the highest level of protection, permanently disabling the debug interface irreversibly. Alternatively, the pre-computed data (such as the master private key seed) in storage device 130 can be protected by the Memory Protection Unit (MPU) in the ARM processor. Alternatively, the pre-computed data (such as the master private key seed) can be isolated in a security world using TrustZone hardware in the ARM processor. Alternatively, the pre-computed data (such as the master private key seed) in storage device 130 can be hardware isolated with the highest level of security through a secure element (SE).

[0077] In the production line programming / deployment scheme, pre-computed data generated by the second device 120 can be programmed into the first device 110 in different ways. For example, during batch programming on the production line, the second device 120 can generate different pre-computed data for each first device 110, and write the image file (such as a FLASH image) of the pre-computed data into the storage device 130 of the first device 110 via a JTAG / SWD interface or a serial port programmer. The first device 110 can enable read protection for the pre-computed data in the storage device 130 to prevent the pre-computed data from being leaked. Furthermore, the second device 120 can store the mapping relationship between the device serial number of each first device 110 and the corresponding root public key in a database.

[0078] Alternatively, pre-computed data can be burned during the initial deployment and configuration of the first device 110. A blank FLASH area can be reserved at the factory for the first device 110. When the user uses the first device 110 for the first time, they can connect the first device 110 to the second device 120 via USB or Bluetooth, allowing the second device 120 to generate pre-computed data and transmit it to the first device 110. The first device 110 can lock the storage area of ​​the pre-computed data to prevent subsequent modifications.

[0079] Alternatively, pre-computed data can be remotely deployed and burned using Over-The-Air (OTA) technology. This method is suitable for IoT devices that are online for extended periods and support secure OTA. The second device 120 can store the generated pre-computed data in the cloud. The first device 110 does not have an LMS key pre-installed at the factory and downloads the pre-computed data generated by the second device 120 from the cloud via OTA upon its first network connection; or, when the LMS key stored in the first device 110 is about to run out, it downloads new pre-computed data generated by the second device 120 from the cloud via OTA. The pre-computed data in the cloud can be transmitted to the first device 110 via a secure channel (such as TLS).

[0080] For example, practical application scenarios for the LMS digital signature product solution can include firmware signing, device authentication, data signing, secure communication, local command authorization, and access control. For instance, in a firmware signing scenario, an edge gateway device locally signs firmware update packages for lower-level sub-devices; or, a master node in a distributed system signs configuration update data; or, in offline scenarios, local device signing is required for firmware transfer between devices.

[0081] In device authentication (or device identity authentication and two-way authentication) scenarios, when an IoT device connects to a cloud platform, it needs to sign the challenge value using its own stored private key to prove the legitimacy of the device's identity; or, when a smart door lock, smart camera, and mobile application are paired, the device needs to sign the authentication data; or, when an industrial device authorizes access to a control system, it needs to sign the authorization request locally; or, when an in-vehicle remote terminal (TelematicsBOX, T-Box) establishes a connection with a Telematics Service Provider (TSP) platform, the vehicle-side device needs to sign the identity credential.

[0082] In data signature (or data source authentication and tamper protection) scenarios, sensor nodes sign the collected data to ensure that the data has not been tampered with during transmission; or, smart meters sign electricity consumption data to ensure the authenticity and non-repudiation of metering data; or, dashcams sign video data to ensure the legal validity of accident evidence; or, medical devices sign monitoring data to ensure the integrity of medical data.

[0083] In secure communication (or secure communication protocol) scenarios, during the handshake phase of Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS), the device, acting as the server, needs to sign the ServerKeyExchange message; or, when establishing point-to-point encrypted communication between devices, both parties need to sign and exchange keys; or, in the security extensions of IoT protocols such as Message Queuing Telemetry Transport (MQTT) and Constrained Application Protocol (CoAP), the device needs to perform signature authentication.

[0084] In local command authorization and access control scenarios, industrial programmable logic controllers (PLCs) need to issue authorization tokens for control instructions to allow specific operations to be executed within a specified time; alternatively, smart home gateways sign device configuration commands to ensure the authenticity of the configuration commands; or edge computing nodes sign task allocation commands to ensure the security of the distributed system.

[0085] In some implementations, the second device 120 is used to execute the complete key generation algorithm and can write the key generation result to the storage device 130 according to a preset storage format. For example, when executing the key generation algorithm, the second device 120 can obtain key generation parameters and the master private key seed. The key generation parameters may include an LMS parameter type identifier (lms_type) and an LM-OTS parameter type identifier (lm_ots_type). The second device 120 can parse the Merkle tree height h based on lms_type. The height h is used to determine the number of leaf nodes in the Merkle tree, and the number of leaf nodes is 2^h. If lms_type is invalid, the execution flow of the key generation algorithm is terminated with an error. Furthermore, the second device 120 can parse the Winternitz parameter w and the number of hash chains p based on lm_ots_type. If lm_ots_type is invalid, the execution flow is terminated with an error.

[0086] refer to Figure 3 The diagram shown is a schematic of a Merkle tree, as follows: Figure 3As shown, a Merkle tree is a complete binary tree with multiple levels. Taking a Merkle tree with a height h=3 as an example, the Merkle tree includes multiple leaf nodes (such as leaf node A, leaf node B, leaf node C, and leaf node D). The level of a leaf node can be called the leaf node level (i.e., the first level), which can be set to 0. Leaf node A and leaf node B are sibling nodes, and leaf node C and leaf node D are sibling nodes.

[0087] A Merkle tree also includes multiple internal nodes (such as internal nodes E and F). Internal node E is the parent node of leaf nodes A and B, and internal node F is the parent node of leaf nodes C and D. In other words, leaf node A is the left child of internal node E, and leaf node B is the right child of internal node E; leaf node C is the left child of internal node F, and leaf node D is the right child of internal node F. Furthermore, internal nodes E and F are siblings. The level at which these internal nodes reside can be called the internal node level (the second level above the first level), and this level can be set to 1. Additionally, the Merkle tree includes a root node G, which is at the top level of the Merkle tree, such as height=2. Internal nodes E and F are children of the root node G, meaning the root node G is the parent node of both internal nodes E and F.

[0088] Then, the second device 120 can generate hash values ​​(hereinafter referred to as first hash values) corresponding to multiple leaf nodes based on the key generation parameters and the master private key seed. These first hash values ​​can be hash values ​​obtained by hashing the LM-OTS public key. Next, the second device 120 can perform bottom-up, layer-by-layer hash merging calculations on the first hash values ​​corresponding to the multiple leaf nodes to obtain hash values ​​corresponding to multiple internal nodes (hereinafter referred to as second hash values), and the hash value corresponding to the root node of the Merkle tree, which is the LMS root public key.

[0089] Next, the second device 120 can write the key generation result to the storage device 130 based on a preset storage format. The key generation result may include a master private key seed and multiple pre-stored hash values; the multiple pre-stored hash values ​​may include the first hash values ​​corresponding to the aforementioned multiple leaf nodes, or may include the first hash values ​​corresponding to multiple leaf nodes and the second hash values ​​corresponding to multiple internal nodes. The key generation result can be a FLASH image file.

[0090] In this embodiment, a second device with strong computing power performs the complete key generation process, including traversing all leaf nodes to generate the LM-OTS key and calculating the node hash values ​​required for all authentication paths. The pre-computed data is stored in a first device with weak computing power (such as an embedded device), thereby improving the efficiency of the first device when performing digital signature calculations.

[0091] In some implementations, the key generation result may further include key generation parameters, the LMS root public key (i.e., the hash value of the Merkle tree root node), and a signature count value. For example, the key generation result can be stored in storage device 130 according to the following preset storage format: LMS parameter area || Root public key area || Signature count area || Private key data area.

[0092] For example, the LMS parameter area can be used to store key generation parameters, namely the LMS parameter type identifier lms_type (e.g., LMS_SHA256_M32_H20) and the LM-OTS parameter type identifier lm_ots_type (e.g., LMOTS_SHA256_N32_W8). Both lms_type and lm_ots_type can be 4 bytes, meaning the LMS parameter area size is 8 bytes.

[0093] The root public key area can be used to store the LMS root public key (i.e., the hash value of the Merkle tree root node) and the LMS key identifier I. The LMS root public key can be 32 bytes, and the LMS key identifier I can be 16 bytes, meaning the size of the public key area can be 48 bytes.

[0094] The signature count area can be used to store a 32-bit unsigned integer (i.e., the signature count value), which indicates the leaf node number to be used in the next signature. The initial value of the signature count value can be 0, and it can be incremented by 1 after each successful signature, with a value range of [0, 2^h-1]. When the signature count value reaches 2^h, it means that the hash values ​​of all leaf nodes have been used up. The size of the signature count area can be 4 bytes, and 4 bytes of storage space can satisfy the largest leaf node number value of H25, 2^(25)-1.

[0095] When multiple pre-stored hash values ​​only include the first hash values ​​corresponding to multiple leaf nodes, the private key data area can be used to store the master private key seed and the first hash values ​​corresponding to all leaf nodes in the Merkle tree. The master private key seed can be 32 bytes, and the first hash value corresponding to each leaf node can occupy 32 bytes, meaning the first hash values ​​corresponding to all leaf nodes can occupy a total of 2^(h) * 32 bytes of space. In this case, the total storage size occupied by the key generation result is 8 + 48 + 4 + 32 + (2^(h) × 32) bytes.

[0096] With multiple pre-stored hash values, including the first hash values ​​corresponding to multiple leaf nodes and the second hash values ​​corresponding to multiple internal nodes (i.e., the entire Merkle tree is pre-stored), the private key data area can be used to store the master private key seed, the first hash values ​​corresponding to all leaf nodes in the Merkle tree, and the second hash values ​​corresponding to all internal nodes. Each second hash value corresponding to an internal node can occupy 32 bytes, meaning the total second hash values ​​corresponding to all internal nodes can occupy (2^h-2)×32 bytes. The total number of leaf nodes and internal nodes is 2^h + 2^h-2 = 2^(h+1)-2. In this case, the total storage size occupied by the key generation result is 8 + 48 + 4 + 32 + ((2^(h+1)-2)×32) bytes.

[0097] When multiple pre-stored hash values ​​only include the second hash values ​​corresponding to multiple internal nodes, the private key data area can be used to store the master private key seed and the hash data of all internal nodes in the Merkle tree (excluding the root node). In this case, the total storage size occupied by the key generation result is: 8 + 48 + 4 + 32 + ((2^h-2)*32) bytes.

[0098] It should be noted that the above-mentioned preset storage format is only an example, and this application does not limit the cascading method of each storage area or the space size of each storage area.

[0099] For example, if the preset storage format corresponding to the key generation result is: LMS parameter area 8B + public key area 48B + signature count value area 4B + master private key seed 32B + all leaf nodes 2^(h)×32B (hereinafter referred to as storage scheme one), then the storage space occupied by the leaf nodes and the key generation result under different tree heights can be referred to Table 1 as follows: Table 1

[0100] If the preset storage format corresponding to the key generation result is: LMS parameter area 8B + public key area 48B + signature count value area 4B + master private key seed 32B + all leaf nodes 2^(h)*32B + all internal nodes (2^(h)-2)*32B (hereinafter referred to as storage scheme two), then the storage space occupied by the leaf nodes and the key generation result under different tree heights can be referred to Table 2 as follows: Table 2

[0101] If the preset storage format corresponding to the key generation result is: LMS parameter area 8B + public key area 48B + signature count value area 4B + master private key seed 32B + all internal nodes (2^h-2)*32B (hereinafter referred to as storage scheme three), then the storage space occupied by the leaf nodes and the key generation result under different tree heights can be referred to Table 3 as follows: Table 3

[0102] As can be seen, when storing all leaf nodes and internal nodes in the Merkle tree using the complete pre-storage method (i.e., storage scheme two), the storage requirements are approximately 2KB for H5, 64KB for H10, 2MB for H15, 64MB for H20, and 2GB for H25. When storing all leaf nodes without storing internal nodes (i.e., storage scheme one), the storage space can be reduced by approximately 50% (approximately 1KB for H5, 32KB for H10, 1MB for H15, 32MB for H20, and 1GB for H25), with minimal impact on H5 / H10 / H15 signature performance. When storing all internal nodes without storing leaf nodes (i.e., storage scheme three), the required storage space is almost the same as storage scheme one (only 64 bytes less), and approximately 50% of scheme two. Therefore, technicians can flexibly choose the pre-storage method based on the storage device capacity to achieve the optimal balance between storage space and signature performance. Furthermore, the two efficient data storage formats provided in this application embodiment, through a fixed offset storage parameter area and a linear arrangement of Merkle tree nodes, enable the first device to calculate the data required for location (including the hash value of the leaf node and the hash value of the authentication path node) based on the node number in the tree, thereby eliminating the need for extensive traversal calculations and achieving fast signing.

[0103] In some implementations, taking storage device 130 as a Flash memory as an example, the input data of the second device 120 may include: key generation parameters (lms_type and lm_ots_type), LMS key identifier I (e.g., 16 bytes), master private key seed (e.g., 32 bytes), and Flash write interface function (flash_write). The execution process of the key generation algorithm of the second device 120 is described in detail below (wherein, the write operation of the leaf node hash value in step 4.3 is performed when the preset storage format is storage scheme one and storage scheme two, and the write operation of the internal node hash value in step 4.4.2 is performed only when the preset storage format is storage scheme two and storage scheme three): The flash memory layout can be found in Table 4 (in address order): Table 4

[0104] For storage scheme one, the total Flash size required is 92 + 2^h × 32 bytes; for storage scheme two, the total Flash size required is 92 + (2^(h+1)-2) × 32 bytes; and for storage scheme three, the total Flash size required is 92 + (2^h-2) × 32 bytes.

[0105] 1) Parse and validate parameters: 1.1) Determine the number of leaf nodes based on lms_type in the key generation parameters: parse the Merkle tree height h according to lms_type; where the number of leaf nodes in the Merkle tree is 2^h. If lms_type is invalid, report an error and exit.

[0106] 1.2) Parse the Winternitz parameter w and the number of hash chains p based on lm_ots_type. If lm_ots_type is invalid, exit with an error.

[0107] 2) Initialize the working buffer: 2.1) Allocate the computation stack space lms_tree_stack[] for the Merkle tree. This computation stack lms_tree_stack[] is a First In Last Out (FILO) stack of depth h, used to temporarily store the hash values ​​of left child nodes that have not yet found a right sibling for merging. The stack top pointer is top. The size of this computation stack lms_tree_stack[] can be h × 32 bytes (e.g., only 800 bytes are needed for the H25 parameter set), and the stack top pointer top can be initialized to -1, i.e., lms_tree_stack[top] = -1.

[0108] 2.2) The second device 120 includes a memory module. For example, when executing the key generation algorithm, the second device 120 can adopt a write-as-you-go strategy, that is, after generating the hash value corresponding to a node, the hash value corresponding to that node can be immediately written to Flash, thereby reducing the occupation of the memory module of the second device 120. Furthermore, multiple working buffers of fixed size (hereinafter referred to as memory buffers) can be allocated to the memory module of the second device 120 for caching the generated data; the multiple memory buffers may include a first buffer, a second buffer, a third buffer, and a fourth buffer: First buffer (lm_ots_pubkey

[32] ): used to store the LM-OTS public key corresponding to the current leaf node; The second buffer (current_hash

[32] ): is used to store the hash value corresponding to the current node; The third buffer (leaf_hash_buffer

[54] ): leaf node hash input buffer, used to cache the first hash value corresponding to the leaf node (size = I(16B) + r(4B) + D_LEAF(2B) + public key hash(32B) = 54 bytes); Fourth buffer (intr_hash_buffer

[86] ): Internal node hash input buffer, used to cache the second hash value corresponding to the internal node (size = I(16B) + r(4B) + D_INTR(2B) + left child node(32B) + right child node(32B) = 86 bytes).

[0109] 2.3) Static portion of the pre-filled hash input buffer (including the third and fourth buffers): Copy the key identifier I to the first 16 bytes (offset 0-15) of the third buffer leaf_hash_buffer and the fourth buffer intr_hash_buffer. Write the field separator D_LEAF (0x8282) of the leaf node to offset 20 bytes in the third buffer leaf_hash_buffer (i.e. I(16B)+r(4B)=20B), and write the field separator D_INTR (0x8383) of the internal node to offset 20 bytes in intr_hash_buffer.

[0110] 3) Write Flash header information based on the preset storage format: 3.1) Write lms_type (e.g., 4 bytes) at offset address 0 bytes.

[0111] 3.2) Write lm_ots_type (e.g., 4 bytes) at the offset address of 4 bytes.

[0112] 3.3) Reserve 32 bytes of space at offset address 8-39 for backfilling the LMS root public key.

[0113] 3.4) Write the key identifier I (e.g., 16 bytes) at offset address 40 bytes.

[0114] 3.5) Write the initial value of the signature count to 0 (or 4 bytes) at offset address 56 bytes.

[0115] 3.6) Write the master private key seed (e.g., 32 bytes) at offset address 60 bytes.

[0116] 4) Calculate and write the first hash value corresponding to the leaf node while constructing the Merkle tree: Taking the starting address of the storage of the first hash value corresponding to the leaf node as leaf_base=92 as an example, perform the following operations on each leaf node q (the value of q is in the range of [0, 2^h-1]): 4.1) Generate the q-th LM-OTS public key (i.e., the LM-OTS public key corresponding to the current leaf node q): 4.1.1) Obtain the key identifier I, the leaf node identifier q, the master private key seed, the Winternitz parameter w, and the number of hash chains p.

[0117] 4.1.2) Traverse all leaf nodes. For each leaf node q, execute steps 4.1.2.1 to 4.1.2.3: 4.1.2.1) Generate the q-th LM-OTS private key: For each hash chain i corresponding to the current leaf node q (where i ranges from [0, p-1]), calculate the private key component x[i] corresponding to each hash chain i using a hash function based on the master private key seed and key identifier I. For example, x[i] = H(I||u32str(q)||u16str(i)||u8str(0xff)||SEED), where u32str, u16str, and u8str represent converting the integer to 4-byte, 2-byte, and 1-byte big-endian representations, respectively.

[0118] 4.1.2.2) Calculate the q-th LM-OTS public key: For each hash chain i corresponding to the current leaf node q, the private key component x[i] corresponding to each hash chain i can be iteratively hashed 2^w-1 times using a hash function. For example, during the iteration process, the current iteration value tmp[i] is determined based on the key identifier I and the previously generated iteration value tmp[i-1] = H(I||u32str(q)||u16str(i)||u8str(j)||tmp[i-1]); where the value of j ranges from [0, 2^w-2]. After the iteration is completed, the last obtained tmp[i] is the public key component of the i-th hash chain corresponding to the current leaf node q.

[0119] 4.1.2.3) Aggregate the hash chains i corresponding to the current leaf node q to generate the LM-OTS public key corresponding to the current leaf node q: Concatenate the public key components of the p hash chains corresponding to the current leaf node q, and perform hash calculation on the concatenated data corresponding to the current leaf node q to obtain the LM-OTS public key ots_pub_hash[q] corresponding to the current leaf node q, and store it in the first buffer lm_ots_pubkey. Wherein, ots_pub_hash[q]=H(I||u32str(q)||u16str(D_PBLC)||tmp[0]||tmp[1]||...||tmp[p-1]); D_PBLC=0x8080 is the domain separator for public key aggregation.

[0120] 4.2) Calculate the first hash value corresponding to the current leaf node q: 4.2.1) Calculate the number of the current leaf node q in the entire Merkle tree: r = q + 2^h.

[0121] 4.2.2) Convert r to big-endian (e.g., 4 bytes) and fill it into offset address 16 in the third buffer leaf_hash_buffer.

[0122] 4.2.3) Copy the LM-OTS public key corresponding to the current leaf node q in the first buffer lm_ots_pubkey to offset address 22 in the third buffer leaf_hash_buffer.

[0123] 4.2.4) Perform a SHA256 hash on the LM-OTS public key corresponding to the current leaf node q in the third buffer leaf_hash_buffer to obtain the first hash value corresponding to the current leaf node q, and write it into the second buffer current_hash to determine the current leaf node q as the currently traversed node (i.e., the currently traversed node). That is, at this time current_hash = SHA256(I||u32str(r)||D_LEAF||lm_ots_pubkey).

[0124] 4.3) When the preset storage format is storage scheme one and storage scheme two, the first hash value corresponding to the current leaf node q is written into the Flash: for example, the first hash value corresponding to the current leaf node q stored in the second buffer current_hash is written into the Flash address (leaf_base+i×32), so that the entire leaf array does not need to be temporarily stored in the memory module.

[0125] 4.4) Perform Merkle tree stack-style merging. Calculate the second hash value corresponding to the internal node from bottom to top, that is, calculate layer by layer from the (h-1)th level of the Merkle tree. The second hash value corresponding to each internal node is obtained by merging the first hash values ​​corresponding to its left and right child nodes: 4.4.1) Set a temporary variable j=q.

[0126] 4.4.2) When j is even (i.e. (j&1)==0), it means that in the current tree level, the current leaf node q is the left child of its parent node, and the first hash value of its right sibling node has not yet been calculated. Therefore, the merging is paused, the first hash value of the current leaf node q is pushed onto the computation stack lms_tree_stack, and the process waits for the subsequent leaf node (i.e. its right sibling) to calculate the parent node. At this time, the process returns to step 4.1.

[0127] When j is odd (i.e., (j&1) == 1), it means that in the current tree level, the current leaf node q is the right child of its parent node. Therefore, it must have a left sibling node, and the first hash value of this left sibling node has been pushed onto the computation stack lms_tree_stack, waiting to be merged with it. Therefore, when j is odd, the following merge operation is performed in a loop: a) Calculate the index r' of the parent node corresponding to the current leaf node q: r' = (r-1) >> 1, that is, the parent node index r' is (r-1) / 2, where ">>1" means shifting one position to the right, which is equivalent to dividing by 2. And update the temporary variable j to update j to the index position of the level where the parent node is located, that is, update j = (j-1) >> 1.

[0128] b) Read the first hash value corresponding to the left sibling node from the top of the Merkle tree computation stack lms_tree_stack: left_child=lms_tree_stack[top].

[0129] c) The number r' of the parent node corresponding to the current leaf node q can be converted to big-endian and the converted number r' can be filled into offset address 16 in the fourth buffer intr_hash_buffer.

[0130] d) Copy the first hash value left_child of the left sibling node corresponding to the current leaf node q to offset address 22 in the fourth buffer intr_hash_buffer.

[0131] e) Copy the first hash value corresponding to the current leaf node q in the second buffer current_hash to offset address 54 in the fourth buffer intr_hash_buffer.

[0132] f) Thus, based on the first hash value corresponding to the current leaf node q and the first hash value corresponding to its left sibling node, the second hash value corresponding to its parent node can be determined as: SHA256(I||u32str(r)||D_INTR||left_child||current_hash), and the second hash value corresponding to the parent node can be written into the second buffer current_hash.

[0133] g) Calculate the top of the stack lms_tree_stack minus 1 (pop the top element of the stack to prepare for the next merge).

[0134] h) For example, if a storage method that only pre-stores the hash values ​​of all leaf nodes is adopted (i.e., storage scheme one), then the second hash value corresponding to the parent node does not need to be written to Flash.

[0135] For example, if a storage method that pre-stores the hash values ​​of all leaf nodes and all internal nodes (i.e., storage scheme two) or a storage method that pre-stores the hash values ​​of all internal nodes (i.e., storage scheme three) is adopted, the second hash value corresponding to the parent node can be written to Flash. For storage scheme two, the offset address when writing the second hash value corresponding to the parent node to Flash can be: 92 + 2^h × 32 + (r' - 2) × 32; for storage scheme three, the offset address when writing the second hash value corresponding to the parent node to Flash can be: 92 + (r' - 2) × 32. Here, 92B = 8 + 48 + 4 + 32 is the fixed length of the Flash header (LMS parameters + public key + I + counter + master private key seed = 92 bytes); (2^h × 32) is the total space occupied by all leaf node hash values; (r' - 2) × 32 represents the position of the internal node r' in the internal node hash value array.

[0136] i) If j is still odd, return to step a) to continue merging; if j is even or j is 0, exit the loop.

[0137] 4.4.3) Push the second hash value corresponding to the parent node in the second buffer current_hash onto the computation stack lms_tree_stack, that is, increment top by 1, and copy the second hash value corresponding to the parent node into the computation stack lms_tree_stack[top] as the new left child to be merged, and wait for its right sibling to be merged later.

[0138] 4.5) After the Merkle tree traversal is completed, the top element of the stack, lms_tree_stack[top], is the hash value of the root node, which is the LMS root public key.

[0139] 5) Backfill public key: Write the LMS root public key (e.g., 32 bytes) to offset address 8 in storage device 130 to fill the space reserved in step 3.3.

[0140] 6) The Flash image (i.e. the key generation result) has been generated and a success status is returned.

[0141] It should be noted that the space size and offset address involved in the above steps are merely examples, and are not limited in this embodiment. Furthermore, the node numbering method in the Merkle tree can be adjusted according to actual applications; when the node numbering method in the Merkle tree changes, the judgment conditions in the above steps (such as the parity judgment of the temporary variable j) can be adaptively adjusted, and are not limited in this embodiment.

[0142] In this embodiment, the key generation algorithm is applicable to the three storage schemes mentioned above. The difference lies in that the first storage scheme only executes the writing of the hash value of the leaf node, without storing the hash value of the internal node; the second storage scheme additionally writes the hash value of the internal node to the storage device during the stack merging process; and the third storage scheme does not store the leaf node, but only writes the internal node to the storage device 130 during the stack merging process. Moreover, by writing pre-computed data to the first device while the second device calculates the hash value of the leaf node and dynamically constructs the Merkle tree, it is not necessary to store the hash value of each node in the entire Merkle tree in the memory module of the second device (for H25, the complete Merkle tree requires about 2GB of memory), thereby greatly reducing the memory consumption of the second computing device. Furthermore, after writing the header information (such as lms_type, lm_ots_type, key identifier I, the initial value of the signature count value and the master private key seed) to the first device in advance based on the preset storage format, only the root public key needs to be filled back, without any additional operations.

[0143] In some implementations, after the second device 120 completes the key generation process and writes the key generation result to the storage device 130 of the first device 110 according to a preset storage format, the first device 110 can read the key generation result from the storage device 130 to dynamically generate a digital signature and calculate the authentication path based on the key generation result during signing, thereby avoiding repeated calculation of the hash value of the leaf node.

[0144] For example, after receiving the key generation result, the first device 110 can encrypt the key generation result to obtain an encrypted key generation result. For instance, the first device 110 can encrypt the key generation result based on a One-Time Programmable (OTP) key. The OTP key is a one-time password, which can improve the security of the key generation result. The encrypted key generation result is still stored in a preset storage format in the storage area of ​​the storage device 130.

[0145] In some implementations, the first device 110 may, in response to a signature request, retrieve the key generation result from its storage area (i.e., storage device 130). The key generation result may include a master private key seed and multiple pre-stored hash values; the multiple pre-stored hash values ​​may include first hash values ​​corresponding to multiple leaf nodes and / or second hash values ​​corresponding to multiple internal nodes. The key generation result is obtained by the second device 120 processing the master private key seed based on a key generation algorithm. The method by which the second device 120 executes the key generation algorithm can be referred to the description in the above embodiments, and will not be repeated here.

[0146] For example, if the first device 110 encrypts the key generation result, the encrypted key generation result can be retrieved from the storage area based on a preset storage format, and then decrypted to obtain the decrypted key generation result. For instance, the encrypted key generation result can be decrypted based on an OTP key to obtain the decrypted key generation result. It should be noted that the above-described encryption and decryption method based on an OTP key is merely an example, and the encryption and decryption method for the key generation result is not limited in this embodiment.

[0147] In some implementations, the first device 110 may, in response to a signature request, acquire data to be signed and determine the signature value corresponding to the data to be signed based on the data to be signed and the master private key seed. Exemplarily, the key generation result further includes preset parameters, including iteration parameters corresponding to the target hash value and a preset number of multiple hash chains. The target hash value is the hash value corresponding to a leaf node (hereinafter referred to as the target leaf node) among the first hash values ​​corresponding to multiple leaf nodes that has not been used in historical digital signature generation. The first device 110 may determine the digest value (or message digest) corresponding to the data to be signed based on a hash algorithm. Then, based on the digest value and iteration parameters, it determines the iteration number of each hash chain in the multiple hash chains corresponding to the target leaf node, and performs iterative hashing on the master private key seed based on the iteration number of each hash chain corresponding to the target leaf node to obtain the signature components of each hash chain corresponding to the target leaf node. Next, the first device 110 may concatenate the signature components of each hash chain corresponding to the target leaf node to obtain the signature value corresponding to the data to be signed.

[0148] In some implementations, if the preset storage format is storage scheme three (i.e., multiple pre-stored hash values ​​include second hash values ​​corresponding to multiple internal nodes but do not include first hash values ​​corresponding to multiple leaf nodes), then the first device 110 can determine the first authentication path corresponding to the target hash value based on the master private key seed, and obtain the second authentication path corresponding to the target hash value from the multiple pre-stored second hash values; then, it determines the target authentication path corresponding to the target hash value based on the first authentication path and the second authentication path. The target authentication path corresponding to the target leaf node includes the sibling nodes corresponding to the target leaf node in the Merkle tree, and the sibling nodes of the parent node corresponding to the target leaf node, etc.; and the target authentication path does not include the root node. For example, if the target leaf node is... Figure 3 The leaf node A shown here corresponds to a target authentication path that includes leaf node B (i.e., the first authentication path) and internal node F (i.e., the second authentication path).

[0149] For example, in this case, the first device 110 can traverse the nodes in the Merkle tree to calculate the hash value of the sibling leaf node corresponding to the target leaf node based on the hash value of the leaf node, thereby determining the first authentication path in the target authentication path; other nodes in the target authentication path (i.e., the second authentication path) can be directly read from the second hash values ​​corresponding to multiple internal nodes pre-stored in the storage device 130. Therefore, the signing time based on storage scheme three is independent of the height h of the Merkle tree.

[0150] In some implementations, if the preset storage format is storage scheme one (i.e., the storage device 130 stores the first hash value corresponding to multiple leaf nodes and does not store the second hash value corresponding to multiple internal nodes), the first device 110 can obtain the target hash value corresponding to the target leaf node from the first hash values ​​corresponding to multiple leaf nodes in the storage area, and determine the target authentication path corresponding to the target hash value based on the multiple first hash values.

[0151] For example, in this case, the first device 110 can dynamically calculate the authentication path by traversing all leaf nodes using a stacked Merkle tree merging algorithm. For instance, the first device 110 can first determine the sibling node corresponding to the target leaf node, then obtain the first hash value corresponding to the sibling node from multiple first hash values ​​corresponding to the leaf nodes, and merge the target hash value and the first hash value of the sibling node to generate the second hash value of the parent node corresponding to the target leaf node. Next, based on multiple first hash values, the second hash value of the sibling node corresponding to the parent node is determined... and so on, until the top of the Merkle tree is reached, thus determining the target authentication path corresponding to the target leaf node based on the hash values ​​of all sibling nodes.

[0152] In some implementations, if the preset storage format is storage scheme two (i.e., storage device 130 stores multiple leaf nodes corresponding to first hash values ​​and multiple internal nodes corresponding to second hash values), then the target hash value corresponding to the target leaf node is obtained from the multiple leaf nodes corresponding to the first hash values ​​in the storage area, and the target authentication path is obtained from the multiple first hash values ​​and multiple second hash values ​​in the storage area based on the target hash value. That is, the first device 110 can directly read the pre-stored authentication path nodes from storage device 130 without hash calculation, thus the signature duration is independent of the Merkle tree height h. For example, in this case, the first device 110 can determine the storage address of the second hash value corresponding to each internal node in storage device 130 based on the index value of the target leaf node, and then read the second hash value corresponding to each internal node from storage device 130 based on the storage address of the second hash value corresponding to each internal node to determine the target authentication path corresponding to the target leaf node. Therefore, the first device 110 does not need to calculate the authentication path.

[0153] In some implementations, after determining the signature value and the target authentication path, the signature result corresponding to the data to be signed can be obtained by cascading the signature value and the target authentication path.

[0154] The following describes in detail the execution process of the digital signature generation algorithm of the first device 110, taking storage device 130 as a Flash memory as an example: For example, the address constants of Flash can be defined as follows: ADDR_LMS_TYPE = 0 / / LMS parameter (4 bytes); ADDR_LMOTS_TYPE = 4 / / LM-OTS parameter (4 bytes); ADDR_PUBLIC_KEY = 8 / / Root public key (32 bytes); ADDR_I = 40 / / Key identifier I (16 bytes); ADDR_COUNTER = 56 / / Signature count value (4 bytes); ADDR_SEED = 60 / / Master private key seed (32 bytes); ADDR_LEAF_BASE = 92 / / Starting address of the hash array corresponding to the leaf node; ADDR_INTERNAL_BASE=92+2^h×32 / / The starting address of the hash array corresponding to the internal node (only used in storage scheme 2).

[0155] 1) Read and verify Flash parameters: 1.1) Read the key generation result from Flash. For example, the encrypted key generation result in Flash can be decrypted using an OTP key, and the following data can be read based on a preset storage format: The lms_type (4 bytes) is obtained by reading and decrypting based on ADDR_LMS_TYPE. The lm_ots_type (4 bytes) is obtained by reading and decrypting based on ADDR_LMOTS_TYPE. The key identifier I (16 bytes) is obtained by reading and decrypting based on ADDR_I. The signature count value c (4-byte unsigned integer) is obtained by reading and decrypting based on ADDR_COUNTER. The master private key seed (32 bytes) is obtained by reading and decrypting based on ADDR_SEED.

[0156] 1.2) Parse the height h of the Merkle tree based on lms_type. If parsing fails, return an error. Also, parse the Winteritz parameter w, the number of hash chains p, and the checksum offset ls based on lm_ots_type. If parsing fails, return an error.

[0157] 1.3) Check the validity of the signature count. If the signature count is greater than or equal to 2^h, it means that all leaf nodes in the Merkle tree have been used up, and an error message such as "signature count exhausted" can be returned.

[0158] 2) Initialize the signature buffer: 2.1) The following example uses the format of the final output signature result as: q(4B)||lmots_signature||lms_type(4B)||path[0]||...||path[h-1], and the format of the signature value lmots_signature is: lm_ots_type(4B)||C(32B)||y[0]||...||y[p-1](p×32B), where C is a 32-byte random number.

[0159] If the signature count value c is less than 2^h, it means that there are still unused leaf nodes in the Merkle tree. In this case, the current signature count value can be written into the signature result, such as the first 4 bytes of the signature result. The first hash value corresponding to the q-th leaf node in the Merkle tree is the target hash value that was not used in the historical digital signature generation process, and the q-th leaf node is the target leaf node.

[0160] 2.2) Next, the offset position of lms_type in the signature result signature can be determined as (4+(4+32+p×32)), and lms_type is written into the first 4 bytes of the signature result signature[lms_type_offset] according to this offset position.

[0161] 3) Determine the hash value (i.e., message digest) Q of the message to be signed, and generate an LM-OTS signature: 3.1) Determine the message digest Q corresponding to the message to be signed: The message digest Q can be calculated using segmented hashing, and the message digest Q can be of arbitrary length. Wherein, Q=H(I||u32str(q)||u16str(D_MESG)||C||message), and D_MESG=0x8181 is the field separator of the message digest Q.

[0162] 3.2) Generate an LM-OTS signature (i.e., the signature value corresponding to the data to be signed): 3.2.1) Call the LM-OTS signature generation function. Its input parameters may include lm_ots_type, LMS key pair identifier I, leaf node number to be signed q, master private key seed seed, random number C, message digest Q, Winternitz parameter w, number of hash chains p, and checksum offset ls.

[0163] 3.2.2) Next, the Winternitz checksum Cksm(Q) corresponding to the message digest Q can be calculated, and the message digest Q and the checksum Cksm(Q) can be concatenated to determine the number of iterations of each hash chain corresponding to the current leaf node q to be signed (i.e. the q-th leaf node) based on the concatenated data Q||Cksm(Q) in the subsequent step (step 3.2.3.2).

[0164] 3.2.3) Generate LM-OTS signature components: For each hash chain i corresponding to the q-th leaf node (where i ranges from [0, p-1]), perform the following operations: 3.2.3.1) Derive the private key of the i-th hash chain corresponding to the q-th leaf node based on the master private key seed: tmp=H(I||u32str(q)||u16str(i)||u8str(0xff)||SEED).

[0165] 3.2.3.2) Determine the iteration count of the i-th hash chain based on the message digest Q, and iteratively hash the private key of the i-th hash chain according to the iteration count of the i-th hash chain. The iteration count of the i-th hash chain is: coef(Q||Cksm(Q),i,w) times, where the coef() function represents extracting the i-th w-bit coefficient from Q||Cksm(Q) as the iteration count of the i-th hash chain. The i-th w-bit coefficient represents the number of bits occupied by the i-th hash chain.

[0166] For example, the iteration value obtained by performing the j-th iteration on the i-th hash chain is: tmp=H(I||u32str(q)||u16str(i)||u8str(j)||tmp'). Here, the value of j is in the range of [0,coef(Q||Cksm(Q),i,w)–1], and tmp' is the iteration value obtained when performing the (j-1)-th iteration.

[0167] 3.2.3.3) The iteration result tmp obtained at the last iteration of the i-th hash chain can be determined as the signature component of the i-th hash chain, and the iteration result can be stored in the signature component array, i.e.: y[i]=tmp.

[0168] 3.2.4) Assemble the LM-OTS signature to obtain the signature value corresponding to the data to be signed. For example, the LM-OTS type lm_ots_type, the random number C, and the signature components of all hash chains corresponding to the q-th leaf node can be concatenated to obtain the signature value lmots_signature corresponding to the q-th leaf node, i.e., u32str(lm_ots_type)||C||y[0]||y[1]||...||y[p-1].

[0169] 4) Determine the target authentication path corresponding to the q-th leaf node.

[0170] For example, if storage scheme one is adopted, that is, the Flash stores the first hash value corresponding to all leaf nodes, but not the second hash value corresponding to the internal nodes, then the target authentication path corresponding to the q-th leaf node needs to be calculated: 4.1) In some examples, the starting offset address of the target authentication path in the signature result can be determined as: auth_path_offset = lms_type_offset + 4. Furthermore, the computation stack of the Merkle tree can be allocated as: lms_sign_stack[h×32]. Also, the domain separator of the internal nodes can be set to D_INTR as 0x8383, and the index of the largest leaf node, max_leaf, can be set to 2^h-1.

[0171] 4.2) Traverse all leaf nodes to determine the target authentication path: For each leaf node i (where i ranges from [0, max_leaf]), perform the following operations: 4.2.1) If i equals q, then the public key corresponding to the q-th leaf node obtained in step 3 can be retrieved, and a hash can be calculated on the public key corresponding to the q-th leaf node to obtain the first hash value corresponding to the q-th leaf node. Then, the first hash value corresponding to the q-th leaf node is stored in the second buffer current_hash; If i is not equal to q, the first hash value corresponding to the i-th leaf node can be read from the storage area of ​​the first device 110 based on the Flash address (ADDR_LEAF_BASE+i×32), so that the first device 110 does not need to recalculate the first hash value corresponding to the i-th leaf node. Then, the first hash value corresponding to the i-th leaf node is written into the second buffer current_hash to determine the target authentication path based on the second buffer current_hash.

[0172] 4.2.2) Merkle tree stack-based merging: It can initialize the current leaf node's index among all leaf nodes as internal_idx=i, and can initialize the current leaf node i's index r in the entire Merkle tree as r=i+2^h, and initialize the current traversal level height=0, and the current target node's index as internal_leaf=q.

[0173] If the height of the current traversal level is less than the highest level h of the Merkle tree, perform the following operations for each level height in the Merkle tree (height values ​​range from [0, h]) until the process pauses or reaches the top of the tree (i.e., height = h): 4.2.2.1) If the traversal of multiple leaf nodes has not been completed, determine whether the current traversal level is less than the highest level h of the Merkle tree, that is, determine whether the current traversal level is the last level of the Merkle tree (i.e., whether the top of the tree has been reached). If the current traversal level is the last level of the Merkle tree (i.e., height == h), it means that the last leaf has been processed and merged into the root node. At this time, the signature is completed, and step 5 is executed.

[0174] 4.2.2.2) Determine whether the current leaf node `internal_idx` is a sibling node of the current target node `internal_leaf`. If the current leaf node `internal_idx` is a sibling node of the current target node `internal_leaf`, i.e., (internal_idx XOR internal_leaf) == 1, then write the first hash value of the current leaf node `internal_idx` into the target authentication path, that is, copy the first hash value corresponding to the q-th leaf node in `current_hash` to the location of the authentication path in the signature result `signature` (`auth_path_offset + height × 32`).

[0175] 4.2.2.3) If the current leaf node (i.e., the i-th leaf node) is a left node, meaning the index value of the i-th leaf node, internal_idx, is even, i.e., the i-th leaf node is the left child of its parent node, and i is less than the index of the largest leaf node, max_leaf, then step 4.2.3 can be continued to store the hash value of the current leaf node's internal_idx into the computation stack, and the next leaf node corresponding to the current leaf node's internal_idx can continue to be traversed. If the current leaf node is a right node, meaning the index value of the i-th leaf node, internal_idx, is odd, i.e., the i-th leaf node is the right child of its parent node, then step 4.2.2.4 can be continued to retrieve the hash value of the sibling node corresponding to the current leaf node's internal_idx from the computation stack.

[0176] 4.2.2.4) Perform node merging. For example, the first hash value corresponding to the left sibling (i.e., the i-th leaf node) can be retrieved from the computation stack lms_sign_stack, i.e., left_child = lms_sign_stack[height × 32]. Then, based on the tree height h and the current traversal level height, the parent node numbers corresponding to the i-th and (i+1)-th leaf nodes are calculated as: parent_r = (internal_idx + 2^(h - height)) / 2.

[0177] Next, based on the hash value of the current leaf node and the hash value of its corresponding sibling node, a second hash value for the parent node of the current leaf node can be generated. That is, based on the first hash values ​​of the i-th leaf node and the (i+1)-th leaf node, the second hash value corresponding to its parent node is determined as: current_hash = H(I||u32str(parent_r)||u16str(D_INTR)||left_child||current_hash). Then, the index values ​​internal_idx and internal_leaf can be updated to determine the parent node corresponding to the current target node internal_leaf, and the parent node corresponding to the current target node internal_leaf is determined as the updated current target node; and the parent node corresponding to the current leaf node internal_idx is determined, so that the parent node corresponding to the current leaf node internal_idx is determined as the updated current target node. If internal_idx can be shifted right by one bit (i.e., internal_idx divided by 2), and internal_leaf can be shifted right by one bit (i.e., internal_leaf divided by 2), and the current traversal level can be updated according to the preset step (e.g., the current traversal level height is increased by 1), and then return to step 4.2.2.1 to continue merging upwards.

[0178] 4.2.3) The second hash value current_hash corresponding to the parent node can be copied to lms_sign_stack[height×32], and then the next leaf node corresponding to the current leaf node internal_idx can be processed.

[0179] For example, if storage scheme one is adopted, that is, the Flash stores the first hash value corresponding to all leaf nodes and the second hash value corresponding to all internal nodes, then the corresponding target authentication path can be read directly based on the target leaf node q: 4.1) Initialize the index value r of the current node in the entire Merkle tree based on the target leaf node q: r = q + 2^h, and initialize the Flash address ADDR_LEAF_BASE = 92 and ADDR_INTERNAL_BASE = 92 + 2^h × 32. Then, read the first hash value corresponding to the pre-stored target leaf node q from the Flash.

[0180] 4.2) Loop through h authentication path nodes (where i ranges from [0, h-1]): 4.2.1) The least significant bit of the current node's index r in the entire Merkle tree can be inverted to obtain the index r_brother of the first sibling node corresponding to the target leaf node q, i.e., r_brother = r XOR 1.

[0181] 4.2.2) When the current traversal level i is less than the highest level h of the Merkle tree, determine the level of the current sibling node r_brother in the Merkle tree based on the current node r. Then, determine from which area of ​​Flash to read the hash value of the current sibling node r_brother based on its index value r_brother. For example: If r_brother is greater than or equal to 2^h, it means that the current sibling node is at the leaf node level (that is, the current sibling node is at the first level in the Merkle tree). Then the storage path of the first hash value of the current sibling node in Flash is: path[i]=FLASH[ADDR_LEAF_BASE+(r_brother-2^h)×32], so as to obtain the first hash value corresponding to the current sibling node from the Flash storage area based on the storage path.

[0182] If r_brother is less than 2^h, it means the first sibling node is at the internal node level (i.e., the current sibling node is at the second level in the Merkle tree). Therefore, the storage path of the second hash value of the current sibling node in Flash is: path[i] = FLASH[ADDR_INTERNAL_BASE + (r_brother - 2) × 32], to retrieve the second hash value corresponding to the current sibling node from the Flash storage area based on this storage path.

[0183] 4.2.3) Write the first hash value or the second hash value path[i] corresponding to the current sibling node r_brother into the target authentication path position in the signature result signature.

[0184] 4.2.4) Determine the parent node corresponding to the current node r, so that the parent node is determined as the updated current node, such as r = r / 2; and update the current traversal level according to the preset step (such as increasing i by 1); then return to execute step 4.2.1 to continue to obtain the authentication path of the next level until i = h and the loop terminates (that is, until h internal nodes are obtained). The determined path[0]||path[1]||path[2]...||path[h-1] is the target authentication path.

[0185] For example, if storage scheme three is adopted, that is, the Flash stores the second hash values ​​corresponding to all internal nodes, then the first authentication path in the target authentication path is calculated, and the second hash values ​​corresponding to other authentication path nodes (i.e., the second authentication path) are read from the Flash: 4.1) Based on the target leaf node q, initialize the index value r of the current node in the whole Merkle tree as: r = q + 2^h; and initialize the Flash address ADDR_INTERNAL_BASE = 92.

[0186] 4.2) If the current traversal level i is less than the highest level h of the Merkle tree, iterate through h authentication path nodes (where i ranges from [0, h-1]): 4.2.1) Determine the sibling node number corresponding to the current node r as: r_brother=r XOR 1.

[0187] 4.2.2) Determine the level of the current sibling node in the Merkle tree based on the current node. Then, determine the node type and obtain the hash value based on the index value r_brother of the current sibling node. If r_brother >= 2^h, it means that the current sibling node r_brother is at the first level in the Merkle tree (i.e., the current sibling node is at the leaf node level). Then, the first hash value corresponding to the current sibling node r_brother can be determined based on the master private key seed. At this point, the index value of the current sibling node r_brother at the leaf node level can be calculated as: leaf_idx = r_brother - 2^h. Based on the master private key seed and the index value leaf_idx of the current sibling node at the leaf node level, the first hash value corresponding to the current sibling node is generated (i.e., derive the leaf_idx-th LM-OTS private key, calculate the complete LM-OTS public key, and then calculate the first hash value of the current sibling node) as: path[i] = H(I||u32str(r_brother)||D_LEAF||OTS_PK[leaf_idx]). The method for generating the first hash value corresponding to the current sibling node can be referenced from the key generation algorithm executed on the second device, and will not be elaborated here.

[0188] If r_brother < 2^h, it means that the current sibling node r_brother is at the second level in the Merkle tree (i.e., the current sibling node is at the internal node level), and the second hash value corresponding to the current sibling node can be obtained directly from the Flash storage area: path[i] = FLASH[ADDR_INTERNAL_BASE + (r_brother - 2) × 32].

[0189] 4.2.3) Then, the first hash value or the second hash value path[i] corresponding to the current sibling node r_brother can be written to the target authentication path location.

[0190] 4.2.4) Update the current traversal level i according to the preset step size, such as incrementing i by 1 (i.e., i = i + 1); and determine the parent node corresponding to the current node r, so that the parent node is determined as the updated current node, that is, update the index value of the current node r = r / 2. Return to execute step 4.2.1 to continue to obtain the authentication path node in the next level, until the current traversal level i is equal to the highest level h of the Merkle tree, at which point the loop terminates.

[0191] 5) Calculate the length of the signature result: The length of the complete signature result is calculated according to the parameters as follows: signature_len=4+(4+32+p×32)+4+h×32=44+p×32+h×32 bytes.

[0192] 6) Update the signature count value: Increment the current signature count value c to obtain the updated signature count value c_new = c + 1. Furthermore, the first device 110 can encrypt the updated signature count value c_new based on the OTP key, and then atomically write the encrypted signature count value c_new into the Flash memory based on the Flash address ADDR_COUNTER to ensure power-off safety.

[0193] 7) Returns the signature result (signature) corresponding to the data to be signed, and returns the signature buffer and the length of the signature result (signature_len), thus completing the digital signature process.

[0194] The standard LMS signature process suffers from the following serious computational bottlenecks: (1) The problem of repetitive authentication path calculation: In the standard process, the authentication path needs to be recalculated for each signature. The calculation of the authentication path requires obtaining the hash values ​​of h sibling nodes, and obtaining each sibling node requires traversing the entire Merkle tree from the leaf node upwards. More seriously, the LM-OTS public key of all leaf nodes visited needs to be calculated during the traversal. (2) The exponential growth of computation: Taking H20 as an example, obtaining an authentication path requires traversing about 2^20 = 1 million leaf nodes, and the calculation of the LM-OTS public key of each leaf node requires p × (2^w-1) hash iterations (8670 hashes for W8 parameters). Therefore, a signature of H20 / W8 requires about 9.1 billion hash calculations. With a 100MHz embedded MCU, even with a SHA256 hardware accelerator, a single signature takes several hours; for H25 / W8, it requires about 291 billion hashes, which can take several days. (3) The root cause of redundant calculation: The standard process uses a real-time calculation method, which requires re-traversing and calculating the LM-OTS public key hash of a large number of leaf nodes for each signature. However, the hash values ​​of these leaf nodes are fixed throughout the key's lifetime. When using the same LMS key pair for different signatures, the same LM-OTS public key hash will be calculated repeatedly, resulting in serious computational redundancy.

[0195] Moreover, the standard process also suffers from a serious bottleneck in terms of memory: (1) Memory requirement analysis: Based on a 32-byte hash value, the memory requirements for different parameter sets are as follows: H5 requires approximately 2KB of memory (2^6-1 nodes × 32 bytes), H10 requires approximately 64KB of memory (2^11-1 nodes × 32 bytes), H15 requires approximately 2MB of memory (2^16-1 nodes × 32 bytes), H20 requires approximately 64MB of memory (2^21-1 nodes × 32 bytes), and H25 requires approximately 2GB of memory (2^26-1 nodes × 32 bytes). (2) For resource-constrained computing devices (typically with only tens to hundreds of KB of RAM), the memory requirements of parameter sets H15 and above completely exceed the device's capabilities. Even the 64KB memory requirement of the H10 parameter set is difficult to meet for low-cost MCUs (such as the Cortex-M0 / M0+ series, where RAM is typically only 8-32KB). This memory bottleneck makes it almost impossible to implement the standard LMS algorithm on embedded devices.

[0196] In this embodiment, when the first device performs digital signature, if the storage device only pre-stores the hash values ​​corresponding to all leaf nodes, the first device reads the hash values ​​of all pre-stored leaf nodes and dynamically calculates the corresponding target authentication path using a bottom-up stack-based merging algorithm. Since the hash values ​​of the leaf nodes have been pre-calculated by the second device, the first device does not need to regenerate the hash values ​​of the leaf nodes, but only needs to perform hash merging calculations of internal nodes (a total of 2^hh-1 hash calculations), significantly reducing computational overhead compared to the standard LMS scheme. Furthermore, when constructing the Merkle tree, the standard LMS scheme requires O(2^h) memory space to store the hash values ​​of all nodes, while in this embodiment, only h×32 bytes of stack space in memory is needed. For example, the H25 parameter set only requires 800 bytes of stack space to complete the construction of the entire Merkle tree, thereby greatly reducing memory usage requirements. If the storage device pre-stores the hash values ​​corresponding to all leaf nodes and all internal nodes, the first device can directly read the internal nodes required for the target authentication path from the storage device based on the signature count value, without any additional hash calculations. This completely avoids the repeated calculation of hash values ​​for other leaf nodes when performing different digital signatures. Furthermore, neither storage method requires re-traversing the entire Merkle tree, thus improving the digital signature performance of the first device by several orders of magnitude. The two schemes also offer a flexible trade-off between storage space and signature performance. Additionally, the Merkle tree traversal calculation only needs to be performed once on the second device, eliminating this computational burden on the first device. Moreover, by pre-storing the authentication path corresponding to each leaf node based on a preset storage format, the address of the authentication path corresponding to each leaf node in the storage device can be directly calculated using a formula, without traversing the Merkle tree or calculating other leaf nodes, thereby improving signature performance by orders of magnitude. If the storage device only pre-stores the hash values ​​corresponding to all internal nodes, the first device can calculate the hash value of the sibling leaf node corresponding to the target leaf node based on the hash value of the leaf node, thereby determining the first authentication path in the target authentication path; the second authentication path in the target authentication path can be directly read from the second hash values ​​corresponding to the pre-stored multiple internal nodes. The signing time based on storage scheme three is independent of the height h of the Merkle tree, so that while requiring less storage space, the computational overhead can be significantly reduced compared to the standard LMS scheme.

[0197] In other words, the pre-computation storage method proposed in this application fundamentally solves the following problems: (1) Eliminating the problem of duplicate calculation In this embodiment, the LM-OTS public key hashes of all leaf nodes are pre-calculated once on a second device (such as a host) and stored in a first device (such as an embedded device). Therefore, during signing, the pre-stored data can be read directly, thus avoiding the problem of repeatedly calculating the leaf node hashes for each signing. Taking H20 / W8 as an example, the standard LMS process requires approximately 9.1 billion hash calculations, while the storage scheme one provided in this embodiment requires only approximately 1.05 million hash calculations (a reduction of 8600 times), and the storage scheme two requires only approximately 8672 hash calculations (a reduction of approximately 1.05 million times).

[0198] (2) Overcoming memory bottleneck This application employs a stack-based algorithm with O(h) space complexity. Neither the pre-computation on the second device nor the signing on the first device requires storing the complete Merkle tree in memory. Taking the H.25 parameter set as an example, the standard LMS process requires approximately 2GB of memory, while this application only requires 25 × 32 = 800 bytes of stack space, reducing memory requirements by approximately 2.5 million times. This allows various types of first devices to support LMS signing.

[0199] (3) Shift the computational burden from the embedded end to the host end. This application embodiment transfers the computationally intensive Merkle tree traversal and leaf node hash calculation to a second device with strong computing power (executed only once during key generation). The first device only needs to bear the computational load of a single LM-OTS signature (comparable to signature verification), achieving the optimization effect of "pre-computation once, permanent reuse".

[0200] (4) Decouple signature time from tree height. For storage scheme two (pre-stored leaf nodes + authentication path), the signature time depends only on the computational cost of a single LM-OTS signature and is independent of the Merkle tree height h. Whether H5 or H25, the signature time remains in the millisecond range.

[0201] (5) Enables large parameter sets on embedded devices Large parameter sets such as H20 and H25 can support approximately 1 million to 33 million signatures, making them the most valuable parameter choices in practical applications. These parameter sets are completely unavailable on embedded devices under the standard LMS process (signatures take hours to days). The embodiments in this application reduce the signature time to the millisecond level, truly unlocking the application potential of the LMS algorithm in embedded scenarios.

[0202] In the above storage method, if only the hash values ​​corresponding to all leaf nodes are pre-stored, the total computational cost of the target authentication path is: Therefore, the computational overhead of the target authentication path is almost negligible compared to the hash chain iteration computation saved by pre-storing the hash values ​​corresponding to all leaf nodes, resulting in a significant optimization effect. If it is necessary to further avoid the computation of the target authentication path, the complete Merkle tree can be pre-stored (i.e., pre-store the hash values ​​corresponding to all leaf nodes and the hash values ​​of all internal nodes), thereby exchanging an additional 50% of storage space for directly reading the target authentication path to achieve zero-hash computation.

[0203] As shown in Tables 5 to 8, taking the worst-case hash count of 2^w-1 times for a single signature, the total number of hashes required by the standard LMS scheme is: leaf × (p × iter + 1 + 1) + path_std. Here, leaf is the total number of leaf nodes (i.e., 2^h), p is the parameter value specified by the lm_ots type, iter is the number of hash chain iterations (i.e., 2^w-1), and path_std is the number of times the standard LMS scheme calculates the hash value of the internal node (i.e., 2^h-2). If storage scheme one (i.e., pre-storing the hash values ​​of all leaf nodes of the Merkle tree) is used, the total number of hashes is: (p × iter + 1 + 1) + path_opt, where path_opt is the number of hashes required to calculate the authentication path in this embodiment (i.e., 2^hh-1). Compared to the standard LMS scheme, the performance improvement of storage scheme one is: standard hash count / hash count of storage scheme one - 1. Table 5

[0204] Table 6

[0205] Table 7

[0206] Table 8

[0207] As shown in Tables 9 to 12, the total number of hashes required by the standard LMS scheme is: leaf × (p × iter + 1 + 1) + path_std. If storage scheme two (i.e., pre-storing the hash values ​​of all leaf nodes and all internal nodes of the Merkle tree) is used, the total number of hashes is: p × iter + 1 + 1, eliminating the need to calculate the authentication path. Compared to the standard LMS scheme, the performance improvement of storage scheme two is: standard hash count / hash count of storage scheme two - 1. Table 9

[0208] Table 10

[0209] Table 11

[0210] Table 12

[0211] As shown in Tables 13 to 16, the total number of hashes required by the standard LMS scheme is: leaf × (p × iter + 1 + 1) + path_std. If storage scheme three (i.e., pre-storing the hash values ​​of all internal nodes of the Merkle tree) is used, the total number of hashes is: 2 × (p × iter + 1 + 1), meaning that the LM-OTS signature corresponding to the target leaf node and the LM-OTS public key of the sibling leaf nodes are calculated, without needing to calculate the internal nodes. Compared to the standard LMS scheme, the performance improvement of storage scheme three is: standard hash count / hash count of storage scheme three - 1. Table 13

[0212] Table 14

[0213] Table 15

[0214] Table 16

[0215] (1) Performance comparison of the three storage solutions: With storage scheme one (pre-storing only the hash values ​​of leaf nodes), the signature performance of the first device can be improved by 28-8670 times, and the number of hashes increases with the height h of the Merkle tree. With storage scheme two (pre-storing the hash values ​​of all leaf nodes and all internal nodes), the signature performance of the first device is improved by 31-33,554,431 times, and the number of hashes is fixed at the computational cost required for a single LM-OTS signature, independent of the tree height h. With storage scheme three (pre-storing only the hash values ​​of internal nodes), the required storage space is the same as storage scheme one (and about 50% of storage scheme two). Signing requires calculating the hash value of a sibling leaf node, thus it is twice as slow as storage scheme two. However, it does not require stacked Merkle merging as in storage scheme one, and it is faster than storage scheme one when H≥15. Furthermore, the signature duration is independent of the height h of the Merkle tree. Therefore, storage scheme three is the optimal storage scheme that balances storage space and computational performance.

[0216] Taking H20 / W8 as an example, a comparison summary of the three storage solutions can be found in Table 17: Table 17

[0217] (2) Analysis of the influence of the Winternitz parameter w: With storage scheme one (pre-storing only the hash values ​​of leaf nodes), the performance improvement for W1 is 28-267 times, for W2 it's 29-401 times, for W4 it's 30-1007 times, and for W8 it's 31-8670 times. With storage scheme two (pre-storing the hash values ​​of all leaf nodes and all internal nodes), the performance improvement for W1 / W2 / W4 / W8 is 31-33554431 times. In this case, the performance improvement is independent of the w parameter and only depends on the tree height h, because the hash calculation of the authentication path has been completely eliminated, and the improvement factor depends only on the number of avoided leaf node traversals (i.e., 2^h). When using storage scheme three (pre-storing only internal nodes), the signature process requires calculating the hash value of a sibling leaf node. The number of hashes is 2 × (p × iter + 2), which is related to w. Specifically, W1 requires approximately 534 hashes, W2 approximately 802 hashes, W4 approximately 2014 hashes, and W8 approximately 17344 hashes. Although the computational overhead of storage scheme three is related to the w parameter, it is far less than the overhead of storage scheme one, which requires traversing multiple leaf nodes.

[0218] (3) Analysis of the influence of tree height h: With storage scheme one (pre-storing only the hash values ​​of leaf nodes), the larger the tree height h, the more significant the performance improvement. However, the improvement is limited by the dynamic computation overhead of the authentication path. With storage scheme two (pre-storing the hash values ​​of all leaf nodes and all internal nodes), the performance improvement is proportional to 2^h (H5 improves by 31 times, H10 by 1023 times, H15 by 32767 times, H20 by approximately 1.05 million times, and H25 by approximately 33.55 million times). With storage scheme three (pre-storing only internal nodes), the signature duration is independent of the tree height h (only requiring the computation of one more sibling leaf node), but because the avoided authentication path traversal overhead is proportional to 2^h, the performance improvement factor increases with the increase of the tree height h.

[0219] (4) Storage solution selection recommendations: If the H5 / H10 parameter set is selected, storage scheme one can be used, which not only has small storage requirements (1KB-32KB), but also has negligible computational overhead for the target authentication path, and its performance is better than storage scheme three.

[0220] If the H15 parameter set is selected, storage scheme three can be used. The required storage space is the same as storage scheme one, but the signing speed can be 2-4 times faster.

[0221] If the H20 / H25 parameter set is selected, and if there is sufficient storage space, storage scheme two can be used, with a signature duration equivalent to one LM-OTS signature; if storage space is limited, storage scheme three can be used, which can achieve performance close to storage scheme two at the storage cost of storage scheme one (signature speed will be 2 times slower).

[0222] (5) The three pre-computation storage schemes provided in the embodiments of this application enable the performance bottleneck of the LMS signature algorithm on embedded devices to change from "computation-intensive" to "storage-intensive", achieving an order-of-magnitude improvement in computational performance by exchanging reasonable storage space. For large parameter sets such as H20 / H25, storage scheme two achieves a leapfrog performance improvement from "hours / days" to "milliseconds"; storage scheme three, in storage-constrained scenarios, achieves performance close to that of storage scheme two at the storage cost of storage scheme one, providing a flexible storage-performance trade-off for resource-constrained devices. The combination of the three storage schemes enables the LMS algorithm to have practical value on embedded devices with different resource constraints.

[0223] In some implementations, the leaf nodes pre-stored in the storage device can be all leaf nodes in the Merkle tree, or only some key intermediate nodes. For example, all nodes at certain levels of the Merkle tree can be stored, and the signing process can start from the nearest pre-stored node, thereby further reducing storage space (e.g., storing only level 10 reduces storage requirements from 672MB to a few MB). In this case, the signing computation latency may take several seconds to tens of seconds. This approach is suitable for scenarios where storage space is limited but second-level signing latency is acceptable.

[0224] In some implementations, LMS-specific hardware accelerators can be additionally configured in the first device 110 and the second device 120. These accelerators can compute multiple hash chains in parallel via dedicated circuitry, thereby accelerating the key generation and digital signature computation processes of LM-OTS and potentially improving key generation and signature performance by 10 to 100 times. This approach is suitable for dedicated cryptographic chips and scenarios requiring high computational performance and where hardware costs are affordable.

[0225] In some implementations, besides performing signature calculations through the first device 110, the signature calculation process can be transferred to a third device (such as the cloud or a trusted server). For example, the first device 110 can send a signature request to the third device, and the third device can generate a complete signature result and return it to the first device 110. Therefore, the first device 110 does not need to store the master private key seed and pre-calculated data. This approach is suitable for IoT devices that are constantly online and can withstand the risks associated with cloud-hosted private keys.

[0226] In some implementations, a limited number of signatures can be pre-generated during the production of the first device 110 using a device-specific pre-provisioning scheme. For example, a fixed number (e.g., 1000) of pre-signatures can be generated for each first device 110 on the production line and stored in the first device 110. Thus, the first device 110 does not need to perform signature calculations at runtime and can directly use the pre-signatures, thereby further improving signature performance (microsecond level). This scheme is suitable for scenarios where the signature message format is fixed and the number of signatures is limited, such as authentication tokens.

[0227] The pre-computation and pre-storage schemes in this application achieve a balance between performance, cost, security, and practicality, making them particularly suitable for mainstream embedded device applications. Depending on the specific application scenario, these alternative schemes can be combined for optimization and expansion to further enhance the system's applicability.

[0228] Based on the foregoing embodiments, this application provides a digital signature generation method, which can be executed by the first device shown in the above embodiments. Figure 4 This is a schematic diagram illustrating the implementation flow of a digital signature generation method provided in an embodiment of this application, as shown below. Figure 4 As shown, the method includes S401 to S404: S401: Obtain the key generation result in the storage area of ​​the first device.

[0229] The key generation result includes the master private key seed and multiple pre-stored hash values; the key generation result is obtained by the second device processing the master private key seed based on the key generation algorithm.

[0230] S402: Obtain the data to be signed, and determine the signature value corresponding to the data to be signed based on the data to be signed and the master private key seed.

[0231] S403: In the case of multiple pre-stored hash values ​​being multiple second hash values ​​and not including multiple first hash values, determine the first authentication path corresponding to the target hash value based on the master private key seed, and obtain the second authentication path corresponding to the target hash value from among the multiple second hash values.

[0232] The target hash value is a hash value that was not used in the historical digital signature generation process among multiple first hash values.

[0233] S404: Determine the target authentication path corresponding to the target hash value based on the first authentication path and the second authentication path.

[0234] S405: Based on the signature value and the target authentication path, determine the signature result corresponding to the data to be signed.

[0235] It is understood that the specific implementation methods of S401 to S404 can be referred to the description of the above embodiments, and will not be repeated here.

[0236] In this embodiment of the application, when the first device performs digital signature, if the key generation result only pre-stores the second hash value corresponding to all internal nodes, then the first device only needs to calculate the hash value of a leaf node based on the master private key seed as the first authentication path in the target authentication path. The other authentication paths (i.e. the second authentication path) in the target authentication path only need to be read from the storage area, so that the required storage space is small while the computational overhead can be greatly reduced compared with the standard LMS scheme.

[0237] Based on the foregoing embodiments, this application provides a key generation method, which can be executed by the second device shown in the above embodiments. Figure 5 This is a schematic diagram illustrating the implementation flow of a key generation method provided in an embodiment of this application, as shown below. Figure 5 As shown, the method includes S501 to S504: S501: Obtain key generation parameters and master private key seed.

[0238] S502: Generate multiple first hash values ​​based on key generation parameters and master private key seed.

[0239] The key generation parameter is used to determine the number of first hash values.

[0240] S503: Perform bottom-up, layer-by-layer hash merging calculations on multiple first hash values ​​to obtain multiple second hash values.

[0241] S504: Transmit the key generation result to the first device.

[0242] The key generation result includes a master private key seed and multiple pre-stored hash values; the multiple pre-stored hash values ​​include multiple first hash values, or multiple first hash values ​​and multiple second hash values.

[0243] It is understood that the specific implementation methods of S501 to S504 can be referred to the description of the above embodiments, and will not be repeated here.

[0244] In this embodiment, a second device with strong computing power performs the complete key generation process, including traversing all leaf nodes to generate LM-OTS keys and calculating the hash values ​​of all authentication paths. The pre-computed data is stored in a first device with weak computing power (such as an embedded device), thereby improving the efficiency of the first device in performing digital signature calculations.

[0245] The "pre-computation + on-demand access" scheme provided in this application embodiment can avoid the problem of repeated calculations during the signature process: (1) One-time pre-computation, permanent reuse: During the key generation phase, a host device with strong computing power (such as the second device) traverses the entire Merkle tree once to pre-compute the hash data of all 2^h leaf nodes (i.e., the hash value of the LM OTS public key), and stores this data in a fixed format in the FLASH of the embedded device (such as the first device). In this way, the tree traversal calculation is only performed once on the host side, and the embedded device does not need to bear this computational burden.

[0246] (2) O(1) direct access, eliminating traversal: An efficient FLASH storage structure was designed, supporting three storage schemes. Storage scheme one pre-stores the hashes of all leaf nodes, and dynamically calculates the authentication path through a stack-based merging algorithm during signing; storage scheme two additionally pre-stores internal nodes, and the FLASH address of each node can be directly calculated through a formula, improving signature performance by orders of magnitude. Storage scheme three pre-stores internal nodes, calculates the hash of a sibling leaf node during signing, and has the same storage space as storage scheme one but a constant signature time.

[0247] (3) Zero redundant computation, performance improvement of several orders of magnitude: Each signature only requires calculating the LM-OTS signature of the target leaf node and reading the pre-stored internal node (storage scheme 2), or each signature only requires calculating the LM-OTS signature of the target leaf node and merging a small number of internal node hashes (storage scheme 1), or calculating the LM-OTS signature of the target leaf node and the hash value of a sibling leaf node (storage scheme 3), thus completely avoiding redundant computation of other leaf nodes under different signatures.

[0248] (4) Flexible storage strategy to adapt to different resource constraints: Three storage schemes are provided for different FLASH capacities. Storage Scheme 2 (Complete Pre-storage) stores the entire Merkle tree (including all leaf nodes and internal nodes), supports O(h) direct reading of the authentication path, and the storage requirements are approximately 2KB for H5, 65KB for H10, 2MB for H15, 64MB for H20, and 2GB for H25. Storage Scheme 1 (Store Leaf Nodes Only) stores the hash values ​​of leaf nodes, and dynamically calculates the hashes of internal nodes during signing (requiring 2^hh-1 hash merges), which can reduce the storage space by about 50% (approximately 1KB for H5, 33KB for H10, 1MB for H15, 32MB for H20, and 1GB for H25). Storage Scheme 3 (Store Internal Nodes Only) stores internal nodes, and calculates the hash of an additional sibling leaf node during signing. The storage space is the same as Storage Scheme 1, but the signing time is independent of the tree height h, which is the best solution to balance storage space and performance. Developers can flexibly choose based on the device's FLASH capacity to achieve the optimal balance between storage space and signature performance.

[0249] (5) Strong versatility and full parameter set support: The embodiments of this application are applicable to all LMS parameter sets (H5 / H10 / H15 / H20 / H25) and all LM-OTS parameter sets (W1 / W2 / W4 / W8). Developers can flexibly select parameter combinations according to actual application needs (signature count, FLASH capacity, performance requirements), which greatly improves the applicability and promotion value of the LMS algorithm.

[0250] Through the above-described scheme, the embodiments of this application enable the LMS post-quantum signature algorithm to achieve high-performance and highly versatile practical deployment on resource-constrained embedded devices, making full use of the device's capabilities and facilitating the implementation and popularization of the post-quantum algorithm.

[0251] In summary, the embodiments of this application, through pre-computation and pre-storage optimization, enable the implementation of a high-performance LMS signature algorithm on resource-constrained computing devices (such as embedded devices), achieving the following technical effects: 1. Significant performance improvement Taking the first device 110 as an example, which is an ARM Cortex-M3 MCU with a main frequency of 100MHz and equipped with a SHA256 hardware accelerator, the signature calculation time can be referred to in Table 18: Table 18

[0252] As can be seen, the higher the Merkle tree, the more significant the performance improvement. For practical parameter sets such as H20 and H25, the performance improvement can reach thousands to tens of millions of times.

[0253] Based on the data shown in Table 11, the following conclusions can be drawn: (1) The standard solution takes more than minutes to sign when using parameter sets H15 and above, and even hours or days for H20 / H25, making it completely unusable in embedded real-time systems; (2) In this embodiment of the application, the H15 signature duration can be reduced from minutes to hundreds of milliseconds and the H20 signature duration can be reduced from hours to seconds when only the leaf node hash value is pre-stored, thereby greatly improving the signature efficiency; (3) In the case of pre-stored leaf node hash values ​​and authentication paths, the signature duration of all types of parameter sets can be uniformly reduced to the millisecond level (e.g., 1ms-19ms), which is basically unrelated to the tree height h; (4) Although the W8 parameter set has the largest amount of computation for a single LM-OTS signature, it can still be completed within 19ms with pre-stored leaf node hash values ​​and authentication paths, thus fully meeting the real-time requirements.

[0254] (5) In the case of pre-storing only the hash value of the internal node, although the signing time is twice that of storage scheme two, the storage space is the same as that of storage scheme one (which can save 50%). It is the best solution to achieve a balance between storage space and performance, and is especially suitable for large tree height scenarios with H≥15 and limited storage.

[0255] 2. Storage space requirements are reasonable and flexible. Storage requirements for pre-stored leaf node hashes and authentication paths (i.e., the complete Merkle tree): H5: 2.1KB (for testing and demonstration purposes); H10: 65.5KB (suitable for low-cost MCUs); H15: 2MB (suitable for mid-range MCUs); H20: 64MB (suitable for high-end MCUs or systems with external FLASH); H25: 2GB (can be optimized by pre-storing leaf node hash values).

[0256] Storage usage of pre-stored leaf node hash values: H5: Approximately 1.2KB (43% saving compared to a full Merkle tree); H10: Approximately 33KB (50% saving compared to a complete Merkle tree); H15: Approximately 1MB (50% saving compared to a complete Merkle tree); H20: Approximately 32MB (50% saving compared to a complete Merkle tree); H25: Approximately 1GB (50% saving compared to a complete Merkle tree).

[0257] For the H5 / 10 / 15 parameter set, even with only the leaf node hash values ​​pre-stored, only 2^hh-1 internal nodes need to be temporarily calculated during signing, which has a relatively small impact on the device's signing performance.

[0258] Therefore, in this application embodiment, the parameter set can be selected according to the actual number of signatures required (to avoid over-configuration), and a suitable pre-storage method can be selected according to the capacity of the storage device.

[0259] 3. Real-time performance meets application requirements. Signature time has been reduced from minutes / hours to milliseconds, fully meeting the requirements of various real-time systems. (1) Secure firmware boot: Signature verification has almost no perceptible delay during the boot process and will not affect the user experience; (2) Secure communication handshake: The signing operation in the TLS / DTLS handshake phase can be completed within the protocol timeout period to ensure successful connection establishment; (3) Industrial control system: The control instruction signature delay is in the millisecond range, which meets the strict timing requirements of industrial real-time control; (4) Vehicle-to-Everything (V2X) communication: The secure message signing between vehicles can be completed within a 100ms window, meeting the requirements of the Dedicated Short Range Communication (DSRC) / Cellular V2X (C-V2X) protocol; (5) IoT data reporting: Sensor data signature does not affect the acquisition cycle and supports high-frequency data acquisition scenarios.

[0260] 4. Energy consumption is significantly reduced. The number of signature calculations can be reduced from hundreds of millions of hashes to thousands of hashes, with a corresponding reduction in energy consumption of 4-6 orders of magnitude. (1) Taking H20 / W8 as an example: the standard LMS scheme requires about 9.1 billion hashes, while the scheme in this application only requires about 8,672 hashes, reducing the computational load by about 1.05 million times; (2) Taking H25 / W8 as an example: the standard LMS scheme requires about 291 billion hashes, while the scheme in this application embodiment only requires about 8672 hashes, reducing the computational load by about 33.55 million times; (3) For battery-powered IoT devices, the energy consumption of a single signature in this application embodiment can be reduced from the milliampere-hour level to the microampere-hour level, so that the device can support tens of thousands of signatures without significantly affecting battery life. (4) In low-power scenarios (such as low-power local area network wireless standard (Long Range, LoRa) nodes, Bluetooth beacons), the embodiments of this application can make LMS signatures completely feasible instead of unacceptable.

[0261] 5. Security Protection Measures To ensure safe use, the embodiments of this application support the following security protection mechanisms. (1) Key storage security: When the pre-computed data is encrypted with the device’s unique OTP key and stored in the storage device, even if the storage device is physically read, the attacker cannot obtain the plaintext key data; (2) Anti-replay attack: The signature count value adopts an atomic increment mechanism, which can ensure that each LM-OTS key pair is used only once, fundamentally eliminating the risk of reusing one-time signature keys; (3) Power-off security: The signature count value update adopts an atomic write strategy, so even if the power is interrupted during the signing process, it will not lead to inconsistent key status or key reuse; (4) Fully compatible with standards: The generated signature results conform to the RFC8554 specification and can be correctly verified by any standard LMS signature verification, ensuring interoperability.

[0262] 6. Promote the popularization of post-quantum cryptography The embodiments of this application enable the LMS algorithm to truly have practical value on resource-constrained devices, significantly lowering the application threshold of post-quantum cryptography: (1) Upgrading existing equipment: Existing embedded products can directly support LMS signing through OTA firmware upgrades without hardware modification; (2) New product design: The new product can directly use LMS to implement quantum secure signatures, preparing for future quantum computing threats; (3) Reduced migration costs: The technical threshold and implementation costs of migrating from traditional signature algorithms (RSA / ECDSA / SM2) to post-quantum signature algorithms have been significantly reduced; (4) Ecosystem promotion: The open design of the embodiments of this application helps to promote the LMS algorithm to form an application ecosystem in the fields of Internet of Things, Internet of Vehicles, and industrial control.

[0263] 7. Flexibility and scalability (1) Full parameter set support: Fully supports all LMS parameter sets (H5 / H10 / H15 / H20 / H25) and all LM-OTS parameter sets (W1 / W2 / W4 / W8) defined in RFC8554, with a total of 20 parameter combinations to choose from; (2) Storage options: Three storage methods are provided: pre-store only the hash value of leaf nodes, pre-store the hash values ​​of leaf nodes and internal nodes, and pre-store only internal nodes. Developers can flexibly choose the appropriate storage method according to the capacity of the storage device and the signature performance requirements. (3) Parameter combination optimization: The optimal parameter combination can be selected according to the specific application scenario (signature count requirement, storage capacity, real-time requirements) to avoid resource waste; (4) Platform independence: The embodiments of this application do not depend on a specific hardware platform and can be ported to any embedded system that supports SHA256 calculation; (5) Standard compatibility: The generated signature results fully comply with the RFC8554 standard and can be interoperated with any standard.

[0264] 8. Summary of Overall Results The embodiments of this application, through a pre-computation + device storage architecture, can achieve the following comprehensive technical effects: (1) Performance dimension: The signature duration has been reduced from hours / days to milliseconds, an improvement of millions of times; (2) Storage dimension: Storage requirements are controllable (1KB-2GB), which is in line with the current Flash cost trend; (3) Energy consumption: The computational load can be reduced by 4 to 6 orders of magnitude, enabling battery-powered computing devices to operate for extended periods; (4) Security dimension: multiple protections including encrypted key storage, anti-reuse mechanism, and power failure security; (5) Compatibility: Fully compliant with RFC8554 standard, with no interoperability issues; (6) General dimension: Full parameter set support, applicable to various devices from low-end MCUs to high-end embedded systems.

[0265] In summary, the embodiments of this application can effectively solve the practical deployment problem of LMS post-quantum signature algorithm on resource-constrained embedded devices, and lay a solid technical foundation for the widespread application of post-quantum cryptography in the fields of Internet of Things, Internet of Vehicles, industrial control, and smart home.

[0266] Based on the foregoing embodiments, this application provides a request information processing device, which includes various units and modules included in each unit, and can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0267] Figure 6 This is a schematic diagram of the composition structure of a digital signature generation device provided in an embodiment of this application, as shown below. Figure 6 As shown, the digital signature generation device 600 can be configured in the first device 110. The digital signature generation device 600 includes: a first acquisition module 610, a first determination module 620, a second determination module 630, a third determination module 640, and a fourth determination module 650, wherein: The first acquisition module 610 is configured to acquire the key generation result in the storage area of ​​the first device.

[0268] The key generation result includes the master private key seed and multiple pre-stored hash values; the key generation result is obtained by the second device processing the master private key seed based on the key generation algorithm.

[0269] The first determining module 620 is configured to obtain the data to be signed and determine the signature value corresponding to the data to be signed based on the data to be signed and the master private key seed.

[0270] The second determining module 630 is configured to determine the first authentication path corresponding to the target hash value based on the master private key seed when multiple pre-stored hash values ​​are multiple second hash values ​​and not including multiple first hash values, and to obtain the second authentication path corresponding to the target hash value from multiple second hash values.

[0271] The target hash value is a hash value that was not used in the historical digital signature generation process among multiple first hash values.

[0272] The third determining module 640 is configured to determine the target authentication path corresponding to the target hash value based on the first authentication path and the second authentication path.

[0273] The fourth determination module 650 is configured to determine the signature result corresponding to the data to be signed based on the signature value and the target authentication path.

[0274] like Figure 6As shown, the digital signature generation device 600 also includes a fifth determining module 660.

[0275] In some implementations, the fifth determining module 660 is configured to: obtain a target hash value from the multiple first hash values ​​in the case of multiple pre-stored hash values ​​but not multiple second hash values; and determine the target authentication path corresponding to the target hash value based on the multiple first hash values.

[0276] like Figure 6 As shown, the digital signature generation device 600 also includes a sixth determining module 670.

[0277] In some implementations, the sixth determining module 670 is configured to: in the case of multiple pre-stored hash values ​​being multiple first hash values ​​and multiple second hash values, obtain a target hash value from the multiple first hash values ​​in the storage area; and obtain a target authentication path from the multiple first hash values ​​and multiple second hash values ​​in the storage area based on the target hash value.

[0278] In some implementations, multiple first hash values ​​are hash values ​​corresponding to multiple leaf nodes, multiple second hash values ​​are hash values ​​corresponding to multiple internal nodes, the multiple leaf nodes and multiple internal nodes are nodes in a binary tree, the binary tree includes multiple levels, the multiple leaf nodes are located at the first level, and the multiple internal nodes are located at the second level above the first level; the second determining module 630 is specifically configured to: when the current traversal level is less than the highest level of the binary tree, determine the level of the current sibling node corresponding to the current node in the binary tree based on the current node; the current node includes the target leaf node, the target leaf node corresponds to The hash value is the target hash value. The nodes in the binary tree include the current leaf node and the current sibling node. If the current sibling node is at the first level in the binary tree, the first hash value corresponding to the current sibling node is determined based on the master private key seed. If the current sibling node is at the second level in the binary tree, the second hash value corresponding to the current sibling node is obtained from the storage area. The first hash value or the second hash value corresponding to the current sibling node is written into the target authentication path. The current traversal level is updated according to the preset step, and the parent node corresponding to the current node is determined so that the parent node is determined as the updated current node.

[0279] In some implementations, multiple first hash values ​​are hash values ​​corresponding to multiple leaf nodes, multiple second hash values ​​are hash values ​​corresponding to multiple internal nodes, and the multiple leaf nodes and multiple internal nodes are nodes in a binary tree. The binary tree includes multiple levels, the multiple leaf nodes are located at the first level, and the multiple internal nodes are located at the second level above the first level. The fifth determining module 660 is specifically configured to: determine whether the current traversal level is less than the highest level of the binary tree if the traversal of multiple leaf nodes is not completed; if the current traversal level is less than the highest level of the binary tree, and if the current leaf node is a sibling node of the current target node, then write the first hash value of the current leaf node into the target authentication path; the current target node includes a target leaf node, the hash value corresponding to the target leaf node is the target hash value, and the multiple leaf nodes... This includes the target leaf node and its sibling nodes; if the current leaf node is a left node, its hash value is stored in the computation stack, and the next leaf node is traversed; if the current leaf node is a right node, the hash value of its corresponding sibling node is retrieved from the computation stack; and, based on the hash value of the current leaf node and the hash value of its corresponding sibling node, a second hash value of the parent node corresponding to the current leaf node is generated, and the current traversal level is updated according to a preset step; multiple internal nodes include parent nodes; and, the parent node corresponding to the current target node is determined to be the updated current target node; and, the parent node corresponding to the current leaf node is determined to be the updated current target node.

[0280] In some implementations, multiple first hash values ​​are hash values ​​corresponding to multiple leaf nodes, multiple second hash values ​​are hash values ​​corresponding to multiple internal nodes, the multiple leaf nodes and multiple internal nodes are nodes in a binary tree, the binary tree includes multiple levels, the multiple leaf nodes are located at the first level, and the multiple internal nodes are located at the second level above the first level; the sixth determining module 670 is specifically configured to: when the current traversal level is less than the highest level of the binary tree, determine the level of the current sibling node corresponding to the current node in the binary tree based on the current node; the current node includes the target leaf node, the target leaf node corresponds to The hash value is the target hash value. The nodes in the binary tree include the current leaf node and the current sibling node. If the current sibling node is at the first level in the binary tree, the first hash value corresponding to the current sibling node is obtained from the storage area. If the current sibling node is at the second level in the binary tree, the second hash value corresponding to the current sibling node is obtained from the storage area. The first hash value or the second hash value corresponding to the current sibling node is written into the target authentication path. The current traversal level is updated according to the preset step, and the parent node corresponding to the current node is determined so that the parent node is determined as the updated current node.

[0281] In some implementations, the key generation result also includes a count value, which indicates the number of times multiple first hash values ​​have been used in the historical digital signature generation process; the second determining module 630 is specifically configured to: determine the signature value corresponding to the data to be signed based on the data to be signed and the master private key seed when the count value is less than the total number of multiple first hash values; the third determining module 640 is specifically configured to: determine the signature result corresponding to the data to be signed based on the count value, the signature value and the target authentication path; increment the count value according to a preset step to obtain an updated count value, and write the updated count value into the key generation result.

[0282] In some implementations, the key generation result also includes preset parameters, which include iteration parameters corresponding to the target hash value and a preset number of hash chains; the first determining module 620 is specifically configured to: determine the digest value corresponding to the data to be signed based on the hash algorithm; determine the iteration number of each hash chain in the multiple hash chains based on the digest value and the iteration parameters; perform iterative hashing on the master private key seed based on the iteration number of each hash chain to obtain the signature component corresponding to each hash chain; and concatenate the signature components corresponding to each hash chain to obtain the signature value corresponding to the data to be signed.

[0283] In some implementations, the first acquisition module 610 is specifically configured to: encrypt the key generation result based on a one-time programmable key to obtain an encrypted key generation result; store the encrypted key generation result in a storage area in a preset storage format; in response to a digital signature request, acquire the encrypted key generation result in the storage area based on the preset storage format; and decrypt the encrypted key generation result based on the one-time programmable key to obtain a decrypted key generation result.

[0284] Based on the foregoing embodiments, this application provides a key generation device, which includes various units and modules included in each unit. It can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits. In the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0285] Figure 7 This is a schematic diagram of the composition structure of a key generation device provided in an embodiment of this application, as shown below. Figure 7 As shown, the key generation device 700 can be configured in the second device 120. The key generation device 700 includes: a second acquisition module 710, a seventh determination module 720, an eighth determination module 730, and a writing module 740. Wherein: The second acquisition module 710 is configured to acquire key generation parameters and master private key seed.

[0286] The seventh determining module 720 is configured to generate multiple first hash values ​​based on the key generation parameters and the master private key seed.

[0287] The key generation parameter is used to determine the number of first hash values.

[0288] The eighth determining module 730 is configured to perform bottom-up, layer-by-layer hash merging calculations on multiple first hash values ​​to obtain multiple second hash values; The write module 740 is configured to transmit the key generation result to the first device.

[0289] The key generation result includes a master private key seed and multiple pre-stored hash values; the multiple pre-stored hash values ​​include multiple first hash values, or multiple first hash values ​​and multiple second hash values.

[0290] In some implementations, multiple first hash values ​​are hash values ​​corresponding to multiple leaf nodes; the seventh determining module 720 is specifically configured to: determine the number of multiple leaf nodes based on key generation parameters; if the number of the current leaf node is less than or equal to the number of multiple leaf nodes, determine the first hash value corresponding to the current leaf node among the multiple leaf nodes; write the first hash value corresponding to the current leaf node into the memory buffer of the second device to determine the current leaf node as the current traversal node; the writing module 740 is specifically configured to: transmit the first hash value corresponding to the current traversal node stored in the memory buffer to the first device.

[0291] In some implementations, the eighth determining module 730 is specifically configured to: if the currently traversed node is a left node, write the first hash value corresponding to the currently traversed node into the computation stack; if the currently traversed node is a right node, obtain the first hash value of the sibling node corresponding to the currently traversed node from the computation stack; determine the second hash value of the parent node corresponding to the currently traversed node based on the first hash value corresponding to the sibling node and the first hash value corresponding to the currently traversed node stored in the memory buffer; write the second hash value of the parent node into the memory buffer to determine the parent node as the currently traversed node; write the second hash value corresponding to the currently traversed node into the computation stack; the writing module 740 is further configured to: transmit the second hash value corresponding to the currently traversed node to the first device.

[0292] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this application can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0293] It should be noted that, in the embodiments of this application, if the above-described digital signature generation method or key generation method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0294] This application provides a computer-readable storage medium storing a computer program thereon. When executed by a processor in a first or second device, the computer program implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0295] This application provides a computer program including computer-readable code, wherein when the computer-readable code is run in a first device or a second device, a processor executes some or all of the steps in the above-described method.

[0296] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a first device or a second device, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0297] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0298] This application provides a computer storage medium that stores one or more programs that can be executed by a processor to implement the steps of the digital signature generation method or key generation method described above.

[0299] It should be noted that the descriptions of the storage medium and device embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0300] The aforementioned computer storage media / memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM), etc.; or it can be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0301] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for generating a digital signature, characterized in that, Applied to a first device, the method includes: The key generation result is obtained from the storage area of ​​the first device; the key generation result includes a master private key seed and multiple pre-stored hash values; the key generation result is obtained by processing the master private key seed based on a key generation algorithm. Obtain the data to be signed, and determine the signature value corresponding to the data to be signed based on the data to be signed and the master private key seed; In the case where the multiple pre-stored hash values ​​are multiple second hash values ​​and do not include multiple first hash values, a first authentication path corresponding to the target hash value is determined based on the master private key seed, and a second authentication path corresponding to the target hash value is obtained from the multiple second hash values; the target hash value is a hash value among the multiple first hash values ​​that was not used in the historical digital signature generation process; The target authentication path corresponding to the target hash value is determined based on the first authentication path and the second authentication path; Based on the signature value and the target authentication path, the signature result corresponding to the data to be signed is determined.

2. The method according to claim 1, characterized in that, Before determining the signature result corresponding to the data to be signed based on the signature value and the target authentication path, the method further includes: In the case where the plurality of pre-stored hash values ​​are a plurality of first hash values ​​and do not include a plurality of second hash values, the target hash value is obtained from the plurality of first hash values ​​in the storage area; The target authentication path corresponding to the target hash value is determined based on multiple first hash values.

3. The method according to claim 1, characterized in that, Before determining the signature result corresponding to the data to be signed based on the signature value and the target authentication path, the method further includes: In the case where the plurality of pre-stored hash values ​​are a plurality of first hash values ​​and a plurality of second hash values, the target hash value is obtained from the plurality of first hash values ​​in the storage area; The target authentication path is obtained from a plurality of first hash values ​​and a plurality of second hash values ​​in the storage area based on the target hash value.

4. The method according to claim 1, characterized in that, The multiple first hash values ​​are hash values ​​corresponding to multiple leaf nodes, the multiple second hash values ​​are hash values ​​corresponding to multiple internal nodes, the multiple leaf nodes and the multiple internal nodes are nodes in a binary tree, the binary tree includes multiple levels, the multiple leaf nodes are located at the first level of the multiple levels, and the multiple internal nodes are located at the second level above the first level; Based on the master private key seed, a first authentication path corresponding to the target hash value is determined, and a second authentication path corresponding to the target hash value is obtained from multiple second hash values, including: When the current traversal level is less than the highest level of the binary tree, the level of the current sibling node in the binary tree is determined based on the current node; the current node includes the target leaf node, the hash value corresponding to the target leaf node is the target hash value, and the nodes in the binary tree include the current leaf node and the current sibling node; If the current sibling node is at the first level in the binary tree, then the first hash value corresponding to the current sibling node is determined based on the master private key seed, and the first hash value corresponding to the current sibling node is determined as the first authentication path; If the current sibling node is at the second level in the binary tree, then the second hash value corresponding to the current sibling node is obtained from the storage area, and the second hash value corresponding to the current sibling node is determined as the second authentication path; The current traversal level is updated according to a preset step, and the parent node corresponding to the current node is determined so that the parent node is determined as the updated current node.

5. The method according to claim 2, characterized in that, The multiple first hash values ​​are hash values ​​corresponding to multiple leaf nodes, the multiple second hash values ​​are hash values ​​corresponding to multiple internal nodes, the multiple leaf nodes and the multiple internal nodes are nodes in a binary tree, the binary tree includes multiple levels, the multiple leaf nodes are located at the first level of the multiple levels, and the multiple internal nodes are located at the second level above the first level; Determining the target authentication path corresponding to the target hash value based on multiple first hash values ​​includes: If the traversal of multiple leaf nodes has not been completed, determine whether the current traversal level is less than the highest level of the binary tree; If the current traversal level is less than the highest level of the binary tree, and if the current leaf node is a sibling node of the current target node, then the first hash value of the current leaf node is written into the target authentication path; the current target node includes the target leaf node, the hash value corresponding to the target leaf node is the target hash value, and the multiple leaf nodes include the target leaf node and the sibling node of the target leaf node; If the current leaf node is a left node, then the hash value of the current leaf node is stored in the calculation stack, and the next leaf node of the current leaf node is traversed. If the current leaf node is a right node, then the hash value of the sibling node corresponding to the current leaf node is obtained from the computation stack; and, based on the hash value of the current leaf node and the hash value of the sibling node corresponding to the current leaf node, a second hash value of the parent node corresponding to the current leaf node is generated, and the current traversal level is updated according to a preset step; the multiple internal nodes include the parent node; and, Determine the parent node corresponding to the current target node, so as to determine the parent node corresponding to the current target node as the updated current target node; and determine the parent node corresponding to the current leaf node, so as to determine the parent node corresponding to the current leaf node as the updated current target node.

6. The method according to claim 3, characterized in that, The multiple first hash values ​​are hash values ​​corresponding to multiple leaf nodes, the multiple second hash values ​​are hash values ​​corresponding to multiple internal nodes, the multiple leaf nodes and the multiple internal nodes are nodes in a binary tree, the binary tree includes multiple levels, the multiple leaf nodes are located at the first level of the multiple levels, and the multiple internal nodes are located at the second level above the first level; Obtaining the target authentication path from multiple first hash values ​​and multiple second hash values ​​in the storage area based on the target hash value includes: When the current traversal level is less than the highest level of the binary tree, the level of the current sibling node in the binary tree is determined based on the current node; the current node includes the target leaf node, the hash value corresponding to the target leaf node is the target hash value, and the nodes in the binary tree include the current leaf node and the current sibling node; If the current sibling node is at the first level in the binary tree, then the first hash value corresponding to the current sibling node is obtained from the storage area; If the current sibling node is at the second level in the binary tree, then the second hash value corresponding to the current sibling node is obtained from the storage area; Write the first hash value or the second hash value corresponding to the current sibling node into the target authentication path; The current traversal level is updated according to a preset step, and the parent node corresponding to the current node is determined so that the parent node is determined as the updated current node.

7. The method according to any one of claims 1-6, characterized in that, The key generation result also includes a count value, which is used to indicate the number of times the multiple first hash values ​​have been used in the historical digital signature generation process; Determining the signature value corresponding to the data to be signed based on the data to be signed and the master private key seed includes: If the count value is less than the total number of multiple first hash values, the signature value corresponding to the data to be signed is determined based on the data to be signed and the master private key seed; Based on the signature value and the target authentication path, the signature result corresponding to the data to be signed is determined, including: Based on the count value, the signature value, and the target authentication path, the signature result corresponding to the data to be signed is determined; The count value is incremented according to a preset step to obtain an updated count value, and the updated count value is written into the key generation result.

8. The method according to any one of claims 1-6, characterized in that, The key generation result also includes preset parameters, which include the iteration parameters corresponding to the target hash value and the preset number of multiple hash chains; Determining the signature value corresponding to the data to be signed based on the data to be signed and the master private key seed includes: The digest value corresponding to the data to be signed is determined based on a hash algorithm; Based on the digest value and the iteration parameters, the number of iterations for each of the multiple hash chains is determined; The master private key seed is iteratively hashed based on the number of iterations of each hash chain to obtain the signature component corresponding to each hash chain; The signature components corresponding to each hash chain are concatenated to obtain the signature value corresponding to the data to be signed.

9. The method according to any one of claims 1-6, characterized in that, Obtain the key generation result in the storage area of ​​the first device, including: The key generation result is encrypted using a one-time programmable key to obtain an encrypted key generation result; the encrypted key generation result is stored in the storage area in a preset storage format. In response to a digital signature request, the encrypted key generation result is obtained from the storage area based on the preset storage format; The encrypted key generation result is decrypted based on the one-time programmable key to obtain the decrypted key generation result.

10. A key generation method, characterized in that, Applied to a second device, the method includes: Obtain the key generation parameters and master private key seed; Multiple first hash values ​​are generated based on the key generation parameters and the master private key seed; the key generation parameters are used to determine the number of the multiple first hash values. Multiple first hash values ​​are merged from bottom to top to obtain multiple second hash values; The key generation result is transmitted to the first device; the key generation result includes a master private key seed and multiple pre-stored hash values; the multiple pre-stored hash values ​​include multiple first hash values, or multiple first hash values ​​and multiple second hash values.

11. The method according to claim 10, characterized in that, The first hash value is the hash value corresponding to the multiple leaf nodes; Multiple first hash values ​​are generated based on the key generation parameters and the master private key seed, including: The number of leaf nodes is determined based on the key generation parameters; Determine the first hash value corresponding to the current leaf node among the plurality of leaf nodes; If the number of the current leaf node is less than or equal to the number of multiple leaf nodes, the first hash value corresponding to the current leaf node is written into the memory buffer of the second device to determine the current leaf node as the current traversal node; The step of transmitting the key generation result to the first device includes: The first hash value corresponding to the currently traversed node stored in the memory buffer is transmitted to the first device.

12. The method according to claim 11, characterized in that, The step of performing a bottom-up, layer-by-layer hash merging calculation on multiple first hash values ​​to obtain multiple second hash values ​​includes: If the currently traversed node is a left node, then the first hash value corresponding to the currently traversed node is written into the calculation stack; If the currently traversed node is the right node, then the first hash value of the sibling node corresponding to the currently traversed node is obtained from the computation stack; Based on the first hash value corresponding to the sibling node and the first hash value corresponding to the currently traversed node stored in the memory buffer, the second hash value of the parent node corresponding to the currently traversed node is determined. Write the second hash value of the parent node into the memory buffer to identify the parent node as the currently traversed node; Write the second hash value corresponding to the currently traversed node into the computation stack; The method further includes: The second hash value corresponding to the currently traversed node is transmitted to the first device.

13. A digital signature generation system, characterized in that, The system includes a first device and a second device; wherein the first device is used to execute the digital signature generation method according to any one of claims 1-9; and the second device is used to execute the key generation method according to any one of claims 10-12.

Images