Patent Application
20230353383
Various exemplary embodiments disclosed herein relate generally to a method and system for partial key storage of binary-tree (e.g., Merkle-tree) based cryptography.
Digital signatures are of vital importance to the cryptographic infrastructure. For example, they underpin the authentication infrastructure in the form of digital certificates on the internet, which is shifting more and more to resource-constrained devices in the Internet of Things (IoT). In order to make digital signatures accessible to such small devices, it is important to minimize the resource requirements and optimize the efficiency of the involved algorithms (e.g., key generation, signing and verification).
A summary of various exemplary embodiments is presented below. Some simplifications and omissions may be made in the following summary, which is intended to highlight and introduce some aspects of the various exemplary embodiments, but not to limit the scope of the invention. Detailed descriptions of an exemplary embodiment adequate to allow those of ordinary skill in the art to make and use the inventive concepts will follow in later sections.
Various embodiments are described, data processing system including instructions embodied in a non-transitory computer readable medium, the instructions for signing messages using a plurality of one-time signing (OTS) keys and a binary-hash-tree structure having a height h and a plurality of nodes configured to provide a public key having, including: generating and storing an authentication path A[d:h−1] for a first 2d signatures corresponding to the first 2d OTS keys of the plurality of OTS keys, where d is the height of a sub-tree associated with first 2d OTS keys; initiating a signature counter; signing a first message using the first OTS key of the plurality of OTS keys; incrementing the signature counter; determining if 2d messages have been signed; signing a second message and incrementing the signature counter when 2d messages have not been signed; and updating authentication path A[d:h−1] for a second 2d signatures corresponding to the second 2d OTS keys of the plurality of OTS keys when 2d messages have been signed.
Various embodiments are described, including: updating a total OTS key counter when 2d messages have been signed; determining if the total OTS key counter indicates that 2h messages have been signed; and ceasing signing messages when 2h messages have been signed.
Various embodiments are described, further including a secure element wherein the authentication path A[d:h−1] is stored on the secure element.
Various embodiments are described, further including an external memory wherein the authentication path A[d:h−1] is stored on the external memory.
Various embodiments are described, further including an external memory wherein the plurality of nodes of the binary-hash-tree structure are stored on the external memory.
Further various embodiments relate to a data processing system including instructions embodied in a non-transitory computer readable medium, the instructions for signing messages using a plurality of one-time signing (OTS) keys and a binary-hash-tree structure having a height h and a plurality of nodes configured to provide a public key, including: generating and storing an authentication path A[d:h−1] for a first 2d signatures corresponding to the first 2d OTS keys of the plurality of OTS keys, where d is the height of a sub-tree associated with first 2d OTS keys; initiating a signature counter; signing a first message using the first OTS key of the plurality of OTS keys; incrementing the signature counter; determining if 2d−cntr<δ and if Time<T, where δ indicates the number of unused OTS keys of the first 2d OTS keys and T is an update time period; signing a second message and incrementing the signature counter when either 2d−cntr<δ and Time<T are not true; and updating authentication path A[d:h−1] for a second 2d signatures corresponding to the second 2d OTS keys of the plurality of OTS keys when both 2d−cntr<8 and Time<T are true.
Various embodiments are described, including: updating a total OTS key counter when both 2d−cntr<8 and Time<T are true; determining if the total OTS key counter indicates that 2h OTS key pairs have been used or skipped; and ceasing signing messages when 2h OTS key pairs have been used or skipped.
Various embodiments are described, further including a secure element wherein the authentication path A[d:h−1] is stored on the secure element.
Various embodiments are described, further including an external memory wherein the authentication path A[d:h−1] is stored on the external memory.
Various embodiments are described, further including an external memory wherein the plurality of nodes of the binary-hash-tree structure are stored on the external memory.
Further various embodiments relate to a method for signing messages using a plurality of one-time signing (OTS) keys and a binary-hash-tree structure having a height h and a plurality of nodes configured to provide a public key having, including: generating and storing an authentication path A[d:h−1] for a first 2d signatures corresponding to the first 2d OTS keys of the plurality of OTS keys, where d is the height of a sub-tree associated with first 2d OTS keys; initiating a signature counter; signing a first message using the first OTS key of the plurality of OTS keys; incrementing the signature counter; determining if 2d messages have been signed; signing a second message and incrementing the signature counter when 2d messages have not been signed; and updating authentication path A[d:h−1] for a second 2d signatures corresponding to the second 2d OTS keys of the plurality of OTS keys when 2d messages have been signed.
Various embodiments are described, including: updating a total OTS key counter when 2d messages have been signed; determining if the total OTS key counter indicates that 2h messages have been signed; and ceasing signing messages when 2h messages have been signed.
Various embodiments are described, wherein the authentication path A[d:h−1] is stored on a secure element.
Various embodiments are described, wherein the authentication path A[d:h−1] is stored on an external memory.
Various embodiments are described, wherein the plurality of nodes of the binary-hash-tree structure are stored on an external memory.
Further various embodiments relate to a method for signing messages using a plurality of one-time signing (OTS) keys and a binary-hash-tree structure having a height h and a plurality of nodes configured to provide a public key having, including: generating and storing an authentication path A[d:h−1] for a first 2d signatures corresponding to the first 2d OTS keys of the plurality of OTS keys, where d is the height of a sub-tree associated with first 2d OTS keys; initiating a signature counter; signing a first message using the first OTS key of the plurality of OTS keys; incrementing the signature counter; determining if 2d−cntr<δ and if Time<T, where δ indicates the number of unused OTS keys of the first 2d OTS keys and T is an update time period; signing a second message and incrementing the signature counter when either 2d−cntr<δ and Time<T are not true; and updating authentication path A[d:h−1] for a second 2d signatures corresponding to the second 2d OTS keys of the plurality of OTS keys when both 2d−cntr<δ and Time<T are true.
Various embodiments are described, including: updating a total OTS key counter when both 2d−cntr<δ and Time<T are true; determining if the total OTS key counter indicates that 2h OTS key pairs have been used or skipped; and ceasing signing messages when 2h OTS key pairs have been used or skipped.
Various embodiments are described, further wherein the authentication path A[d:h−1] is stored on a secure element.
Various embodiments are described, wherein the authentication path A[d:h−1] is stored on an external memory.
Various embodiments are described, further including an external memory wherein the plurality of nodes of the binary-hash-tree structure are stored on an external memory.
In order to better understand various exemplary embodiments, reference is made to the accompanying drawings, wherein:
To facilitate understanding, identical reference numerals have been used to designate elements having substantially the same or similar structure and/or substantially the same or similar function.
The description and drawings illustrate the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its scope. Furthermore, all examples recited herein are principally intended expressly to be for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) to furthering the art and are to be construed as being without limitation to such specifically recited examples and conditions. Additionally, the term, “or,” as used herein, refers to a non-exclusive or (i.e., and/or), unless otherwise indicated (e.g., “or else” or “or in the alternative”). Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.
Digital signatures are of vital importance to the cryptographic infrastructure. New standards related to post-quantum secure digital signatures are under development and evaluation, but one standard which relates to stateful hash-based signatures has already been published by NIST. (See https://csrc.nist.gov/publications/detail/sp/800-208/final). Embodiments will be described herein that speed-up the signing method for embedded devices for common use cases. While previous methods focus was on constant-time signatures, the embodiments described herein focus on the embedded case where signing is preferred to be very fast, but intermittently more computation time is available and allowed. The disclosed embodiments achieve this by devising a way to store enough auxiliary data locally so the signatures in the next time-frame are guaranteed to be very fast, and replacing this auxiliary data when more computation time is allowed.
The most commonly used signature schemes are Rivest-Shamir-Adleman (RSA) and variants of (Elliptic Curve) Digital Signature Algorithm ((EC)DSA). However, with the possibility of a quantum computer being realized, the security of RSA and (EC)DSA is threatened. The idea of hash-based signatures dates back to a proposal by Ralph Merkle from the late 1970s. The security of this approach relies on the cryptographic strength of the used hash function and the pseudo-random function family: cryptographic primitives which are well-studied, understood, and not known to be broken by quantum computers.
Extended Merkle Signature Scheme (XMSS) is one such hash-based scheme, resulting in the scheme described in RFC 8391. It uses Winternitz One-Time Signature+(WOTS+) as a One-Time Signature (OTS). Another often-used hash-based scheme is Leighton-Micali Signatures (LMS), which is described in RFC 8554.
At the core of both these schemes lies a binary-hash-tree structure in which leaf-nodes (the lowermost layer) correspond to public keys of OTS schemes, which are in turn constructed using hash functions.
When signing a message, the signer signs with a (previously unused) OTS keypair 105, and sends the OTS signature of their message, along with the corresponding authentication path to the verifier. This authentication path allows a verifier to verify an OTS signature against the public key of the Merkle-tree-based scheme instead of against the OTS public key.
For the signer, computing the authentication path is a computation-intensive task. If they start from just their OTS secret keys (often stored in the form of a SEED), then they have to recompute most Merkle tree leaf nodes (the most expensive part) to be able to compute the authentication path. Alternatively they could store the entire Merkle tree in memory, but for parameter sets of interest (h=10, 15 or even 20) this means storing more than 50 kB, or even MBs.
To solve this issue the academic literature proposes the following solutions:
The embodiments disclosed herein present a solution for the embedded use case that does not have any of these restrictions and speeds up signing time with increasing signature size where the use case permits it. Embodiments of a method are disclosed that determine what auxiliary information to store such that the signing time is reduced compared to existing techniques for stateful hash-based signature schemes. Existing techniques have the downsides of having to update the key when all states have been used, induce longer signatures, or focus on minimizing asymptotic cost across all signatures in the tree. These are all downsides that are not desirable for practical embedded use cases.
The embodiment described herein enable using a large tree (h≥20) which should be sufficient for many use-cases because this allows for 220≈106 signatures. For example, this would allow one to perform 1000 signatures a day for a period of 1000 days. Moreover, the disclosed method focuses on minimizing the signing time for every X−1 (say X<1024) signatures, with a longer signing time for every X-th signature, which only rarely occurs. This additional work every X-th signature may be pre-empted and run overnight, without running the risk of running out of signatures, and without making sacrifices in signature size.
First, some notation will be defined. Let h be the height of a tree 100 as illustrated in
A Merkle-tree-based many-signature scheme signature includes three elements: [q, σ, A], where q is the index of the tree leaf whose corresponding OTS 105x was used to construct signature σ, and A is the authentication path corresponding to that leaf as illustrated also in
A use-case where the signing keys of a device may never be updated will be assumed. To ensure usability in long-term use-cases, the Merkle tree height in LMS or XMSS has to use a large value of h (e.g., h≥25 which allows for a signature every half a minute for 30 years).
Now let d be a second parameter such that in likely scenarios of the use case, it will not be required to sign more than 2d messages in its life time, or more realistically that the device does not sign more than that many before a time T occurs where the device is allotted more signing time (e.g., at night-time when there are no other running processes and processing resources are readily available and not be utilized, etc.).
We observe that for the first 2d signatures, the top h−d authentication nodes A[d:h−1] do not change. Then for the (2d+1)th signature, a node changes in the top h−d authentication nodes to create A′[d:h−1], which then again stays the same for the subsequent 2d−1 signatures. This means that for a given d, the top h−d authentication nodes A[d:h−1] may be stored and for each signature only compute the lower d authentication nodes.
Next, the method works by storing no auxiliary information to compute the authentication nodes for the next 2d signatures A′[d:h−1], and instead focusing all optimization on the 2d subtree that is involved in computing the first 2d signatures. The observation is then that, except for (h−d)·n bytes of storage, that as long as the number of signatures does not surpass 2d, the storage and signing time can be reduced to the case of a height d scheme. Because even using the mentioned asymptotically optimal algorithms, storage and signing time scale with h2 and reducing these to d2 may make a large difference for certain parameters.
In the case of storing the whole tree, this reduces storage from 2h+1−1 nodes to 2d+1−1+(h−d). In the case of using key scheduling algorithms, this means moving from height h trees to height d trees and their associated trade-offs.
To illustrate this, in the small example of
Generally for larger values of d, it may be seen that the first 2d signatures corresponds to a height d subtree, and the stored authentication path is a node of each level of a height h−d subtree.
When the number of signatures carried out surpasses 2d, the authentication path A[d:h−1] needs to be updated.
Now another use case will be described. Suppose the use case dictates that an update cycle of the authentication path can occur every T time (e.g., every night), and that in T time a device (almost) never signs more than 8 signatures. In this case, signature method is adapted as illustrated in
Updating the authentication path will now be described. The most straightforward way of updating the top h−d authentication nodes would be to simply determine which nodes of A′[d:h−1] need updating, compute them from the secret key and update the path. This is a quite computation-intensive operation, but this is exactly the goal of the embodiments described herein; there are use cases where it is acceptable that if most signatures are fast, some computation time can be allotted in between to do more calculations for the slow signatures.
An alternative is to do store additional information for the computation of these nodes in external non-volatile memory (NVM). For example, if there is space in an external flash memory, then even the whole Merkle tree can be stored there, and nodes can be refreshed from this memory when an update is required. This will replace the computation time with memory operations. A trade-off can be made here as well; using a key scheduling algorithm like BDS or tree traversal can reduce the storage in the external flash memory and requires a bit of computation at update time. Note that inner nodes (height h>0) of the tree may be stored off of the secure module, because they do not contain information on the secret key.
As an example of the potential gains of using the signing methods described herein, let h=20. In this case a device is expected to produce no more than a million signatures in its life-time, but possibly not to produce more than a thousand signatures in a time T.
Using known techniques (setting common parameters) it would either:
If signing method described herein are used, and let d=10, what results instead is:
Another example is the much smaller case, like access control, where a device would do only a few signatures per day at most. In the same h=20 setting as above, if signing methods used herein are used, and let d=5, what instead results is:
The storage requirements of the data will now be described. As noted before the nodes to be stored in the from the Merkle tree do not contain secret key values. Although they should be protected in some manner, attacking them might lead to a Distributed Denial of Service (DDoS) attack because changing Merkle tree values will invalidate signatures, and leakage of the values does not allow an attacker to forge signatures.
This enables the user of signing methods disclosed herein to store the auxiliary data in external flash memory without too many protections. This gives even greater flexibility (because a secure element usually does not have a lot of storage), while keeping the re-computation time low. Also note that this does not only hold for the Merkle tree information that can speed up the update of the path A[d:h−1] every 2d signatures, but even the bytes of the current path A[d:h−1] and current storage to quickly compute A [0:d−1] may be stored off of the secure element. The choice on whether to do so will differ per use case and depend on the available storage on the used secure element/execution environment, as well as the transfer speed between it and the off secure element flash or NVM.
There are even trade-offs to be made here to store the nodes that require many hash computations to be stored in external flash memory and to recompute all other nodes as needed. There are many methods to do this, but this is out of scope of this disclosure.
The processor 820 may be any hardware device capable of executing instructions stored in memory 830 or storage 860 or otherwise processing data. As such, the processor may include a microprocessor, microcontroller, graphics processing unit (GPU), field programmable gate array (FPGA), application-specific integrated circuit (ASIC), or other similar devices. The processor may be implemented as a secure processor or may include both a secure processor and unsecure processor.
The memory 830 may include various memories such as, for example L1, L2, or L3 cache or system memory. As such, the memory 830 may include static random-access memory (SRAM), dynamic RAM (DRAM), flash memory, read only memory (ROM), or other similar memory devices.
The user interface 840 may include one or more devices for enabling communication with a user as needed. For example, the user interface 840 may include a display, a touch interface, a mouse, and/or a keyboard for receiving user commands. In some embodiments, the user interface 840 may include a command line interface or graphical user interface that may be presented to a remote terminal via the network interface 850.
The network interface 850 may include one or more devices for enabling communication with other hardware devices. For example, the network interface 850 may include a network interface card (NIC) configured to communicate according to the Ethernet protocol or other communications protocols, including wireless protocols. Additionally, the network interface 850 may implement a TCP/IP stack for communication according to the TCP/IP protocols. Various alternative or additional hardware or configurations for the network interface 850 will be apparent.
The storage 860 may include one or more machine-readable storage media such as read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, or similar storage media. In various embodiments, the storage 860 may store instructions for execution by the processor 820 or data upon with the processor 820 may operate. For example, the storage 860 may store a base operating system 861 for controlling various basic operations of the hardware 800. The storage 862 may include instructions for implementing the signing methods described herein.
It will be apparent that various information described as stored in the storage 860 may be additionally or alternatively stored in the memory 830. In this respect, the memory 830 may also be considered to constitute a “storage device” and the storage 860 may be considered a “memory.” Various other arrangements will be apparent. Further, the memory 830 and storage 860 may both be considered to be “non-transitory computer or machine readable media.” As used herein, the term “non-transitory” will be understood to exclude transitory signals but to include all forms of storage, including both volatile and non-volatile memories.
While the host device 800 is shown as including one of each described component, the various components may be duplicated in various embodiments. For example, the processor 820 may include multiple microprocessors that are configured to independently execute the methods described herein or are configured to perform steps or subroutines of the methods described herein such that the multiple processors cooperate to achieve the functionality described herein. Further, where the device 800 is implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, the processor 820 may include a first processor in a first server and a second processor in a second server.
As used herein, the term “non-transitory computer or machine readable storage medium” will be understood to exclude a transitory propagation signal but to include all forms of volatile and non-volatile memory. When software is implemented on a processor, the combination of software and processor becomes a single specific machine. Although the various embodiments have been described in detail, it should be understood that the invention is capable of other embodiments and its details are capable of modifications in various obvious respects.
Because the data processing implementing the embodiments disclosed herein is, for the most part, composed of electronic components and circuits known to those skilled in the art, circuit details will not be explained in any greater extent than that considered necessary as illustrated above, for the understanding and appreciation of the underlying concepts of the invention and in order not to obfuscate or distract from the teachings of the invention.
Although the invention is described herein with reference to specific embodiments, various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the invention. Any benefits, advantages, or solutions to problems that are described herein with regard to specific embodiments are not intended to be construed as a critical, required, or essential feature or element of any or all the claims.
Furthermore, the terms “a” or “an,” as used herein, are defined as one or more than one. Also, the use of introductory phrases such as “at least one” and “one or more” in the claims should not be construed to imply that the introduction of another claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an.” The same holds true for the use of definite articles.
Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements.
Any combination of specific software running on a processor to implement the embodiments of the invention, constitute a specific dedicated machine.
It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the invention.
