Stateful hash-based signatures with a single public key and multiple independent signers

Abstract

This document describes techniques and apparatus directed to stateful hash-based signatures with a single public key and multiple independent signers. Immediately after obtaining (502) the Leighton-Micali signature (LMS) randomization parameters, a provisioning server may share (504) the LMS randomization parameters among the multiple signers. The provisioning server may then associate (506) a unique starting leaf index number with each signer and notify (508) each of the signers. The signers may then create random seeds for Leighton-Micali one-time signature (LM-OTS) signatures and generate local LM-OTS and LMS public keys. After generating the local public keys, the signers may share the local LMS public keys with the provisioning server. Upon receiving (510) the local LMS public keys, the provisioning server may then order (512) the local LMS public keys and generate (514) a common LMS public key. The provisioning server may then provision (516) the ordered list, the common LMS public key, and the Merkle tree path for each of the signers.

Description

[Background technology]

[0001] background Internet of Things (IoT) devices make significant contributions to modern society, such as in the areas of security, transportation, communication, and manufacturing. One aspect that makes IoT devices so useful is their ability to be periodically updated, thereby modifying or enhancing certain software features. However, if a bad actor manages to deliver malware to an IoT device disguised as a firmware update, the device may malfunction, expose sensitive data, or operate insecurely. To thwart such cyber attacks, numerous security measures are implemented on computing devices to prevent unauthorized access to and manipulation of device data and communications. These security measures may include utilizing digital signature schemes based on asymmetric encryption algorithms, including Rivest-Shamir-Adelman (RSA) and Elliptic Curve Digital Signature Algorithm (ECDSA). Such digital signature schemes are mathematical schemes used to validate the authenticity and integrity of messages, software, or digital documents. These digital signature schemes give the recipient of a message confidence that the message was generated by a known sender and that the message was not manipulated at any time during transmission.

[0002] The security of many of these asymmetric encryption algorithms depends on the difficulty of solving integer factorization problems, general discrete logarithm problems, and elliptic curve discrete logarithm problems using classical computing techniques. This assumption, specifically the use of only classical computing techniques, can no longer be relied upon due to developments in quantum computing. For example, quantum computing algorithms such as Shor's algorithm may provide a quadratic speedup for brute-force searches that weaken the security behind solving integer factorization problems, general discrete logarithm problems, and elliptic curve discrete logarithm problems. As a result, a bad actor with the aid of a quantum computer may be able to decrypt messages or even forge digital signatures on any message, and potentially inject malware into IoT devices.

[0003] In response, hash-based signature schemes that are believed to be secure against cyber-attacks performed by quantum computers are being standardized. As an illustration, the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-208 provides a Recommendation for Stateful Hash-Based Signature Schemes that are theorized to be highly resistant to quantum computer cyber-attacks. The security of these stateful hash-based signature schemes depends on the security of the underlying cryptographic hash functions.

[0004] Current technology allows for efficient implementation of hash-based signature schemes on a single signing service, such as a modern server that owns all private keys. In such implementations, the signing service may own the computational capacity required to perform key generation and key signing. Yet such implementations may be ineffective when accessing the signing service proves difficult or unreliable, such as when firewalls are present. For example, development teams in different countries may not have the ability to access the server due to firewalls, and as a result may not be able to sign firmware updates. Summary of the Invention

[0005] overview This document describes techniques and apparatus directed to stateful hash-based signatures with a single public key and multiple independent signers. Immediately after obtaining a Leighton-Micali signature (LMS) randomized parameter, a provisioning server may share the LMS randomized parameter among the multiple signers. The provisioning server may then associate with each signer a unique starting leaf index number and notify each of the signers. The signers may then create random seeds for Leighton-Micali one-time signature (LM-OTS) signatures and generate local LM-OTS and LMS public keys. After generating the local public key, the signer may share the local LMS public key with the provisioning server. Upon receiving the local LMS public keys, the provisioning server may then order the local LMS public keys and generate a common LMS public key. The provisioning server may then provision the ordered list, the common LMS public key, and the Merkle tree path to each of the signers.

[0006] This Summary is provided to introduce simplified concepts of stateful hash-based signatures with a single public key and multiple independent signers, as further described below in the Detailed Description and illustrated in the Figures. This Summary is not intended to identify essential features of the claimed subject matter, nor is this Summary intended for use in determining the scope of the claimed subject matter.

[0007] Details of one or more aspects of stateful hash-based signatures with a single public key and multiple independent signers are described herein with reference to the figures that follow. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 illustrates an example operating environment including an example computing device. [Diagram 2] FIG. 1 illustrates an example operating environment including an example portable signature device capable of performing the cryptographic techniques and other security functions described herein. [Diagram 3] FIG. 1 illustrates an example operating environment, including an example provisioning server. [Figure 4] FIG. 1 illustrates an example operating environment including a computing device operably coupled to a plurality of signing devices and linked to a provisioning server. [Diagram 5] FIG. 1 illustrates an example technique for key generation. [Figure 6] FIG. 1 illustrates an example operating environment including an example portable signature device operably coupled to an example computing device. [Figure 7] FIG. 1 illustrates an example technique for key signing.

[0009] The use of the same numbers in different instances may indicate similar features or components. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Detailed Description Overview Advances in the fields of cryptanalysis and quantum computing may weaken the security of many digital signature schemes. When large-scale quantum computers are developed, it is expected that these computers may have the ability to perform attacks based on algorithms such as Shor's algorithm to defeat most of the public key cryptosystems currently in use. The goal of post-quantum cryptography is to anticipate future cryptographic operating contexts in which quantum computers may exist, and to develop cryptosystems that are highly resistant to potential future attacks from these quantum computers. As a result, post-quantum cryptosystems (e.g., systems that are secure against quantum computers with many qubits) are being standardized. For standardized and soon-to-be-specified post-quantum cryptosystems, many techniques have been outlined in the context of a single signature service that owns all private keys and implements a stateful hash-based signature scheme. Many such implementations of post-quantum cryptosystems may be undesirable in some instances, for example when a signature service with all private keys may be difficult or impossible in some instances, such as when firewalls are present.

[0011] In contrast, this document describes techniques and apparatus directed to stateful hash-based signatures with a single public key and multiple independent signers that allow multiple offline signers to implement a stateful hash-based signature scheme in a secure but low-performance network that allows the signers to independently sign a single-level Merkle tree.

[0012] Hash-based signature scheme The hash-based signature (HBS) scheme combines the one-time signature (OTS) scheme with a Merkle tree structure. The OTS scheme is a digital signature scheme that uses a one-way function (e.g., a function whose computational result is inverse or whose computational result is virtually infeasible to reverse) to securely sign one message per key pair. The OTS scheme should only be used to sign a single message because the system can be less secure if two or more messages are signed using the same public and private key pair. If two or more messages are signed using the same public and private key pair, it becomes mathematically feasible for an attacker to forge digital signatures. Because an OTS scheme key should only securely sign a single message, it is practical to combine many such keys in a single, larger structure (e.g., a Merkle tree).

[0013] To avoid re-use of OTS keys, the state of the private key may be updated each time a signature is generated. The HBS scheme of implementing OTS keys and updating the private key may therefore be described as stateful (e.g., a process driven by the context of previous transactions). For example, if the private key is stored in non-volatile memory, the state of the key may be updated in the non-volatile memory to mark the OTS key as unavailable before the corresponding signature generated using the OTS key is exported.

[0014] A stateful HBS scheme is only as secure as the level of security provided by the underlying one-way function of the OTS scheme. For example, a stateful OTS scheme is secure to the extent that it is infeasible to find a preimage or a second preimage of a digest computed by the one-way function. Exemplary one-way functions include hash functions. OTS schemes that use hash functions to compute one-time signatures are believed to be large-scale quantum-computer proof. Hash functions may illustratively include Secure Hashing Algorithms (SHA) (e.g., SHA-256, SHA-256 / 192, SHAKE256 / 256, SHAKE256 / 192). These hash functions may input any of a variety of computer-interpretable objects and output a fixed-size string (e.g., hexadecimal digits). Hash functions generally have useful cryptographic properties, such as preimage resistance (e.g., irreversibility) and collision resistance.

[0015] The Layton-Micali signature (LMS) scheme is an example stateful HBS scheme that may implement a hash function and an OTS scheme. For example, an LMS scheme may implement a Layton-Micali one-time signature (LM-OTS) scheme as its OTS scheme. The LM-OTS signature may be used to validate the authenticity of a message by associating a secret private key with a shared public key. In an LMS scheme, the private key may include a large set (e.g., an array) of LM-OTS private keys. When generating key pairs for an LMS instance, each LM-OTS key in the system may use the same set of parameters as outlined in Section 4 of NIST SP800-208. The LM-OTS public key may be generated from the private key by repeatedly applying a hashing function and then hashing the resulting value. The hash function used for the LMS scheme may be the same as the function used in the LM-OTS key. The format of the LM-OTS private key may be of any configuration as dictated by the system implementation. For example, the private key may include a type code indicating a particular LM-OTS algorithm, an array containing an n-byte string (e.g., the value of n is determined by the hash function selected for use as part of the LM-OTS algorithm), a parameter (e.g., a 16-byte string parameter indicating which Merkle tree LM-OTS is to be used with), and a 4-byte parameter (e.g., a 32-bit integer parameter indicating the leaf of the Merkle tree in which the OTS public key appears).

[0016] The LMS scheme may combine the LM-OTS scheme with a Merkle tree structure. For example, each LMS public and private key pair may be associated with a full binary Merkle tree. A Merkle tree is a non-linear binary data structure having a leaf node, a set of intermediate nodes, and a root node. The leaf nodes may contain a hash value of a data element. Each intermediate node of the Merkle tree may be computed by applying a hash function to the concatenation of the values ​​of its two corresponding child nodes. The root node may be the single final node of the Merkle tree. The use of a Merkle tree may enable a system to identify and / or verify individual data elements without having to access the entire data set.

[0017] Furthermore, Merkle trees can provide an efficient way to link together a large number of OTS instances under a single public key. For example, a Merkle tree can be created with a 2 n OTS instances may be used, and the public keys of those OTS instances may be hashed together with a binary Merkle tree to generate a single public key. In doing so, a single public key may bind all of the OTS instances together, which may result in two-way verification from a single public key. n signatures. Each leaf of the Merkle tree may encapsulate the public key value of an LM-OTS public and private key pair. The value encapsulated by the root of the Merkle tree may be an LMS public key (e.g., a recursive hash of the OTS public key). The private key of the Merkle tree may be a collection of all OTS private keys together with an index of the next OTS private key with which to sign the next message.

[0018] A hierarchical signature scheme (HSS) may be built on top of the LMS scheme, which allows efficient scaling to a larger number of signatures. A sequence of Merkle trees may be included in an HSS system. For example, a Merkle tree may be subdivided into a number of smaller trees. Only the bottom-most Merkle tree may be used to sign a message, while upper Merkle trees, or parts of larger Merkle trees, may be used to sign the public keys of their children.

[0019] In this document, techniques are described that are implementations that can coexist with one-tier HSS systems while meeting NIST standards for key generation and maintenance. Each signer may independently generate its own portion of the Merkle tree. The discussion that follows describes the operating environment, techniques that may be used in the operating environment, and example methods. In the context of this disclosure, reference is made to the operating environment as merely an example.

[0020] Operating environment The discussion that follows describes the operating environment, technologies that may be used in the operating environment, and various devices or systems in which components of the operating environment may be embodied. In the context of this disclosure, reference is made to the operating environment merely by way of example.

[0021] Figure 1 illustrates an example operating environment 100, including an example computing device 102. As illustrated in Figure 1, the computing device 102 is a desktop computer. In other implementations, the computing device 102 may be a laptop, tablet, or the like. The computing device 102 may provide other functionality or include components or interfaces that are omitted from Figure 1 for clarity or visual brevity.

[0022] Computing device 102 includes a printed circuit board assembly 104 (PCBA 104) on which the components and interconnects of the computing device are embodied. Alternatively, or in addition, the components of computing device 102 may be embodied on other substrates such as flexible circuit material or other insulating materials. Although not shown, computing device 102 may further include a housing, various human input devices, a display, a battery pack, an antenna, and the like. Generally, the electrical and electromechanical components of computing device 102 are assembled onto a printed circuit board (PCB) to form the PCBA 104. The various components of the PCBA 104 (e.g., processor and memory) are then programmed and tested to verify the correct functioning of the PCBA 104. The PCBA 104 is connected to or assembled with the other parts of computing device 102 within the housing.

[0023] As illustrated, the PCBA 104 includes one or more processors 106 and a computer-readable medium 108. The processor 106 may be any suitable single-core or multi-core processor (e.g., an application processor (AP), a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU)). The processor 106 may be configured to execute instructions or commands stored in the computer-readable storage medium 110 to execute an operating system 112 and a software development environment module 114 stored in the computer-readable storage medium 110. The computer-readable storage medium 110 may include one or more non-transitory storage devices, such as random access memory (RAM, dynamic RAM (DRAM), non-volatile RAM (NVRAM), or static RAM (SRAM)), read-only memory (ROM), or flash memory), hard drives, SSDs, or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus. The term "coupled" can refer to two or more elements that are in direct contact (physically, electrically, magnetically, optically, etc.) or to two or more elements that are not in direct contact with each other, but that still cooperate and / or interact with each other.

[0024] The PCBA 104 may further include I / O ports 116 and a communication system 118. The I / O ports 116 enable the computing device 102 to interact with other devices or users through peripheral devices. The I / O ports 116 may include any combination of local or external ports, such as Universal Serial Bus (USB) ports, audio ports, Serial ATA (SATA) ports, PCI-express based ports or card slots, Secure Digital Input / Output (SDIO) slots, and / or other legacy ports. Various peripherals, such as human input devices (HIDs), external computer-readable storage media, or other peripherals, may be operatively coupled to the I / O ports 116.

[0025] The communication system 118 may enable the communication of device data, such as data received, data transmitted, or other information as described herein, and may provide connectivity to one or more networks and other devices connected to those networks. Example communication systems include NFC transceivers, WPAN radios conforming to various IEEE 802.15 (Bluetooth®) standards, WLAN radios conforming to any of the various IEEE 802.11 (WiFi®) standards, WWAN (3GPP® compliant) radios for cellular telephone communications, Wireless Metropolitan Area Network (WMAN) radios conforming to various IEEE 802.16 (WiMAX®) standards, infrared (IR) transceivers conforming to the Infrared Data Association (IrDA) protocol, and wired local area network (LAN) Ethernet transceivers. Device data communicated by the communication system 118 may be packetized or framed depending on the communication protocol or standard by which the computing device 102 is communicating. The communication system 118 may include a wired interface, such as an Ethernet or fiber optic interface, for communication over a local network, a private network, an intranet, or the Internet. Alternatively, or in addition, the communication system 118 may include a wireless interface to facilitate communication over a wireless network, such as a wireless LAN, a cellular network, or a WPAN.

[0026] Although not shown, the computing device 102 may further include a system bus, interconnect, crossbar, or data transfer system coupling various components within the device. The system bus or interconnect may include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus utilizing any of a variety of bus architectures.

[0027] 2 illustrates an example operating environment 200 that includes an example portable signature device 202 capable of performing cryptographic techniques and other security functions. As illustrated in FIG. 2, the portable signature device 202 is a USB flash drive. In other implementations, the portable signature device 202 may be an external drive or other external hardware security device. The portable signature device 202 may provide other functionality or include components or interfaces omitted from FIG. 2 for clarity or visual brevity.

[0028] The portable signature device 202 may include a security-hardened integrated circuit 204 on which the portable signature device components and interconnects are embodied, and to which an input / output (I / O) port 206 is coupled. The I / O port 206 may be a standard USB plug that forms a physical connection with a host (e.g., computing device 102). When the portable signature device 202 is coupled to a host, it may receive power and perform the cryptographic techniques described herein. In this state, particularly when operably coupled to a host, the portable signature device 202 receives power and performs cryptographic techniques, the portable signature device 202 is referred to herein as a signer.

[0029] The portable signature device 202 includes one or more microcontrollers 208 and a computer readable medium 214. The microcontroller 208 may enable file transfer between the computing device 102 and the portable signature device 202. The microcontroller 208 may include a processor 210 configured to execute instructions or commands stored in a computer readable storage medium 216 to execute a signer module 218. The computer readable storage medium 210 may further store a private key 220. The computer readable storage medium 216 may include one or more non-transitory storage devices, such as RAM, ROM, or flash memory, hard drives, SSDs, or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus.

[0030] The microcontroller 208 may further include a crypto engine 212. In various implementations, the crypto engine 212 is a secure root of trust (RoT) component that includes a cryptographic coprocessor or processor. The crypto engine 212 possesses the computational capacity to perform the calculations required to perform the key generation and key signing steps. The crypto engine 212 may be communicatively coupled to a secure non-volatile computer-readable storage medium 216 by a private interface.

[0031] 3 illustrates an example operating environment 300, including an example provisioning server 302. The provisioning server 302 may include a processor 304, a computer-readable medium 306, an I / O port 314, and a communication system 316. Among other things, the computer-readable storage medium 308 may include a cryptographic module 310 and a key provisioner 312. The cryptographic module 310 may be configured to perform a hash operation to calculate the LM-OTS public key.

[0032] FIG. 4 illustrates an example operating environment 400 including a computing device 102-1 operably coupled to a plurality of portable signature devices 202 (e.g., portable signature device 202-1, portable signature device 202-2, portable signature device 202-3, portable signature device 202-4, portable signature device 202-5) and linked 402 to a provisioning server 302. The operating environment 400 may include any of the previous operating environments disclosed herein (e.g., operating environment 100, operating environment 200, operating environment 300). The operating environment 400 may be an air-gapped network (e.g., a network used on one or more computing devices to ensure that a secured computer network is physically isolated from an unsecured network) that defines a secure system. As illustrated, the computing device 102-1 is operably coupled to two or more portable signature devices 202 via a USB hub 404. In this example, five portable signing devices 202 are powered, perform cryptographic techniques, and are considered to be five signers. In other implementations, many more signers may be operatively coupled to computing device 102-1 (e.g., 32 signers).

[0033] The computing device 102-1 may be linked 402 to the provisioning server 302. The link 402 may be performed wirelessly by a communication system of both devices. The link 402 enables data transfer between the provisioning server 302 and the signer. In some implementations, the signer is operably coupled directly to the provisioning server 302 via a USB hub 404.

[0034] Key generation technology This section describes techniques for key generation. In some portions of the discussion that follows, reference will be made to the operating environment 400 of FIG. 4 by way of example. Such reference should not be construed as limiting the described aspects to the operating environment 400, but rather as illustrative of one of various examples. Additionally, aspects of the techniques described herein may be reordered, removed, and / or run in parallel with one another.

[0035] FIG. 5 illustrates an example technique 500 for key generation. In an embodiment, the techniques and apparatus described herein for key generation adhere to NIST SP800-208, Random Number Generation for Keys and Signatures. In a first embodiment, the LMS randomization parameters of the LMS scheme are generated using an approved random bit generator, and the instantiation of the random bit generator supports at least 128 bits of security strength. A signer (e.g., a portable signing device 202-1 operably coupled to the computing device 102-1) or a provisioning server (e.g., the provisioning server 302) may generate the LMS randomization parameters. In a second embodiment, the provisioning server obtains 502 the LMS randomization parameters. The provisioning server may then share 504 the LMS randomization parameters among each of the signers (e.g., portable signature device 202-1, portable signature device 202-2, portable signature device 202-3, portable signature device 202-4, portable signature device 202-5). The signers may use the LMS randomization parameters to "walk up" the Merkle tree. In an implementation, a portion of the Merkle tree may be calculated independently by each of the signers.

[0036] In a third embodiment, the provisioning server provides each signer with a S)-1. In some implementations, the provisioning server associates a unique range of leaf indexes.

[0037] In a fourth aspect, the provisioning server may notify 508 each of the signers. Notifying 508 each of the signers may include sending each of the signers a unique starting leaf index number with which each signer is associated, a range of leaf indexes, and a target height of the Merkle tree. The provisioning server, which may notify 508 each of the signers by sending the range of leaf indexes, may configure each of the signers to compute a portion of the Merkle tree having a predetermined height. The data sent during the signer notification may aid in maintaining the proper leaf index during the computation of the Merkle tree.

[0038] Each signer may then create its own random seed for the LM-OTS signature and generate local LM-OTS and LMS public keys. The random seed may be a byte string value generated using an approved random bit generator, where the instantiation of the random bit generator supports a predetermined security strength. The seed may be a secret random value used for pseudo-random key generation that is not disclosed outside each respective portable signature device. The same seed value may be used to generate all covert elements in a single LMS instance. In some implementations, each signer uses its own random seed for its own portion (e.g., sector, partition) of the Merkle tree.

[0039] Local LM-OTS and LMS keys may be generated such that the resulting Merkle tree is a reduced Merkle tree. For example, 20The size of the HBS scheme is simply 2 for 32 signers. 15 In one implementation, key generation may be performed completely independently by the signers. For example, each signer may generate local LM-OTS and LMS keys using common LMS randomization parameters and a secret random seed to independently build a portion of a Merkle tree (e.g., a Merkle tree for the HBS scheme). Key generation may take hours to perform due to the low performance capabilities of the portable signing device.

[0040] In some implementations, the security-hardened portable signing device may not be well suited for LM-OTS key generation. As a result, the signers may share a first hash of each local LM-OTS private key with the provisioning server, and the provisioning server may continue the hashing operation to calculate the LM-OTS public key. In such implementations, the provisioning server may include a cryptographic module (e.g., cryptographic module 310) and discard the seed after the calculation. In other implementations, the provisioning server may generate a complete Merkle tree and provision back to each signer over a secure link (e.g., link 402) the seed to be used and at least a portion of the Merkle tree.

[0041] Once a signer generates its local public key, the signer may share its local LMS public key (e.g., root key) with the provisioning server. In a fifth aspect, the provisioning server may receive 510 the local LMS public key from each of the signers over a secure link. Immediately after or in parallel with receiving 510 the local LMS public key from each of the signers, the provisioning server may perform the steps of a key provisioner (e.g., key provisioner 312). In a sixth aspect, the key provisioner may order 512 the received local LMS public keys. Ordering 512 the local LMS public keys may include the key provisioner generating an ordered list.

[0042] In a seventh aspect, the provisioning server may generate 514 a common LMS public key. For example, the provisioning server may hash the local LMS public keys through a Merkle tree to generate a single common LMS public key. In an eighth aspect, the key provisioner may provision 516 an ordered list, a common LMS public key, and / or a Merkle tree path for each of the signers. Provisioning a Merkle tree path for each signer by the provisioning server's key provisioner allows the signers to store the path to the top of the Merkle tree without revealing the data or paths of other signers. For example, a signer receives a unique Merkle tree path that includes the path of its local LMS public key (e.g., a leaf) to the common LMS public key (e.g., the root).

[0043] Once the signers obtain 516 the same common LMS public key, the portable signing devices (e.g., portable signing device 202-1, portable signing device 202-2, portable signing device 202-3, portable signing device 202-4, portable signing device 202-5) may be physically distributed. For example, portable signing device 202-1 may be distributed to a development team.

[0044] 6 illustrates an example operating environment 600 including an example portable signature device 202-1 operably coupled to an example computing device 102-2. The computing device 102-2 may include a software development environment module 114. The software development environment module 114 may be a module configured to provide an environment for developing software for a firmware update. The software developed on the computing device 102-2 may be only a portion of a larger firmware update.

[0045] Key signing techniques This section describes techniques for key generation. In some portions of the discussion that follows, reference will be made to operating environment 600 of Figure 6 by way of example. Such reference should not be construed as limiting the described aspects to operating environment 600, but rather as being illustrative of one of various examples.

[0046] FIG. 7 illustrates an example technique 700 for key signing. In one aspect, a signer (e.g., portable signing device 202-1 operably coupled to computing device 102-2) may receive 702 a message to sign. The signer may then perform the steps of signer module 218. Signer module 218 may operate completely independently on a security-hardened integrated circuit (e.g., security-hardened integrated circuit 204) of the portable signing device. In a first step, signer module 218 may verify that the Merkle tree being used has not been exhausted by checking 704 a monotonic leaf counter. The leaf counter is in a provisioned range from 0 to 2 n It may count down to -1 and increment after each OTS is generated. The leaf counter count can be referred to as the state of the hash-based signature, and management of the leaf counter count is critical to ensuring security.

[0047] In a second step, the signer module 218 may sign 706 the message, either using its own Merkle tree of reduced height, or using its own portion of a larger Merkle tree. The signer module 218 may continue 708 the signature using a provisioned ordered list with the other signers' local LMS public keys up to the common LMS public key. Each signer may append its respective Merkle tree path to its signature such that the signature is verifiable by the common LMS public key. The signer module 218 may then share 710 the signature. For example, the signer module 218 may share 710 the signature with computing device 102-2. In such a manner, the signers may perform key signing independently and maintain their own state. In addition, a signer may sign a message using its own seed, which becomes the signer's root key, and append the path to the top of the Merkle tree required for signature verification. In doing so, the size of the resulting signature may be smaller than that of a comparable HSS scheme. Furthermore, the signing process may be computed more quickly than conventional techniques, since each signer may operate on a smaller tree. Additionally, because a single-level Merkle tree is produced and small signatures may be achieved, the amount of storage space occupied on a portable signing device may be minimized.

[0048] To still further accelerate the signing process, the signer may store a cache of the local LM-OTS public key, or at least a portion of the Merkle tree, to avoid the computationally expensive operation of computing the local LM-OTS public key. The stored cache may reside entirely within the computer-readable medium (e.g., computer-readable medium 214) of the portable signing device. Depending on the storage space available in the portable signing device and the performance vs. space tradeoff, all or some portion of the Merkle tree may be stored.

[0049] The techniques described herein alleviate the need for a centralized signer to maintain state in the HBS scheme. Instead, each signer may sign independently without needing to access a signing service. Immediately after generating the signature, the signer may validate the computed signature with a common public key. In another implementation, if the provisioning server is secured and accessible by the signers, the provisioning server may generate the complete Merkle tree and use an offline channel to provision back the seeds used and / or provision at least a portion of the Merkle tree to each of the signers. In addition to the above, each of the signers may maintain state within its respective security-hardened integrated circuitry. In addition, the techniques described herein are fully compatible with the standards outlined in NIST SP800-208.

[0050] example In the sections that follow, examples are provided.

[0051] Example 1 A computer-implemented method includes obtaining a Leighton-Micali Signature (LMS) randomization parameter, sharing the LMS randomization parameter among one or more signers, associating a unique starting leaf index number with each of the signers, and informing each of the signers. The informing includes sending to each of the signers a unique starting leaf index number with which each signer is associated, a range of leaf indices, and a target height of the Merkle tree. The computer-implemented method further includes receiving a local LMS public key from each of the signers and ordering the received local LMS public keys. The ordering results in an ordered list of the received local LMS public keys. The computer-implemented method further includes generating a common LMS public key and provisioning for each of the signers. The provisioning includes sending the ordered list, the common LMS public key, and the Merkle tree path to each of the signers. The computer-implemented method further includes verifying each of the signers. To verify, one obtains the common LMS public key.

[0052] EXAMPLE 2 The computer implemented method of Example 1, wherein the LMS randomization parameter is an LMS key pair identifier.

[0053] EXAMPLE 3 The computer-implemented method of Example 1, wherein the signer is a portable signing device operably coupled to the host, the portable signing device having security-hardened integrated circuitry.

[0054] EXAMPLE 4 The computer implemented method of Example 1, wherein the computer implemented method is performed on a provisioning server.

[0055] Example 5 The computer-implemented method of Example 4, wherein obtaining the LMS randomization parameter includes receiving the LMS randomization parameter at the provisioning server from one of the signers.

[0056] Example 6 The computer-implemented method of example 4, wherein obtaining the LMS randomization parameter includes generating the LMS randomization parameter at a provisioning server.

[0057] Example 7 The computer-implemented method of Example 4, further comprising: executing, in a cryptographic module of the provisioning server, a stateful hash-based signature (HBS) scheme that combines a one-time signature (OTS) scheme with a Merkle tree structure.

[0058] Example 8 The computer-implemented method of example 7, wherein the stateful HBS scheme is an LMS scheme configured to implement SHA-256.

[0059] EXAMPLE 9 The computer-implemented method of Example 4, wherein providing the ordered list to the signers enables each of the signers to generate a portion of a Merkle tree, a Merkle tree associated with each respective signer.

[0060] Example 10. The computer-implemented method of Example 4, further comprising computing the Merkle tree and causing each of the signers to cache a portion of the Merkle tree to accelerate signing on lower performance hardware.

[0061] Example 11. The computer implemented method of Example 4, further comprising provisioning a local LMS public key to each of the signers, effectively causing each of the signers to operate independently after provisioning.

[0062] Example 12 The computer implemented method of example 4, further comprising computing a local Layton-Micali one-time signature (LM-OTS) public key at the provisioning server.

[0063] Example 13. The computer-implemented method of example 4, further comprising verifying that each of the signers independently signs with a common LMS public key.

[0064] Example 14 The computer-implemented method of Example 4, further comprising generating the complete Merkle tree at a secured and accessible provisioning server and provisioning back to each of the signers using an offline channel the seeds to be used and at least a portion of the Merkle tree.

[0065] Example 15. A provisioning server comprising at least one processor and at least one computer-readable storage medium comprising instructions that, when executed by the at least one processor, cause the processor to perform a method according to any preceding claim.

[0066] conclusion Although techniques for stateful hash-based signatures with a single public key and multiple independent signers, and implementations of apparatus enabling the stateful hash-based signatures, have been described in feature and / or method specific language, it should be understood that the subject matter of the appended claims is not necessarily limited to the particular features or methods described. Rather, the specific features and methods are disclosed as example implementations enabling the implementation of stateful hash-based signatures with a single public key and multiple independent signers.

Claims

1. 1. A computer-implemented method comprising: Obtaining Layton-Micali Signature (LMS) randomization parameters; sharing the LMS randomization parameters among one or more signers; associating with each of said signers a unique starting leaf index number; and informing each of the signers, said informing including sending to each of the signers the unique starting leaf index number, a range of leaf indices, and a target height of the Merkle tree with which each signer is associated; The computer-implemented method comprises: receiving a local LMS public key from each of the signers; and ordering the received local LMS public keys, said ordering resulting in an ordered list of received local LMS public keys; The computer-implemented method comprises: generating a common LMS public key; and provisioning each of the signers, the provisioning including transmitting the ordered list, the common LMS public key, and a Merkle tree path to each of the signers; The computer-implemented method comprises: The computer-implemented method further comprising verifying each of the signers, wherein the verifying is to obtain the common LMS public key.

2. The computer-implemented method of claim 1 , wherein the LMS randomization parameter is an LMS key pair identifier.

3. 3. The computer-implemented method of claim 1, wherein the signer is a portable signature device operably coupled to a host, the portable signature device having security-hardened integrated circuitry.

4. The computer implemented method of any one of claims 1 to 3, wherein the computer implemented method is executed on a provisioning server.

5. 5. The computer-implemented method of claim 4, wherein obtaining the LMS randomization parameters comprises receiving the LMS randomization parameters at the provisioning server from one of the signers.

6. The computer-implemented method of claim 4 , wherein obtaining the LMS randomization parameter comprises generating the LMS randomization parameter at the provisioning server.

7. 7. The computer implemented method of claim 4, further comprising: implementing in the provisioning server cryptographic module a stateful hash-based signature (HBS) scheme that combines a one-time signature (OTS) scheme with a Merkle tree structure.

8. 8. The computer-implemented method of claim 7, wherein the stateful HBS scheme is an LMS scheme configured to implement SHA-256.

9. 9. The computer-implemented method of claim 4, wherein providing the ordered list to the signers enables each of the signers to generate a portion of a Merkle tree, the Merkle tree being associated with each respective signer.

10. 9. The computer-implemented method of claim 4, further comprising: computing a Merkle tree and causing each of the signers to cache a portion of the Merkle tree to accelerate signing on lower performance hardware.

11. 11. The computer implemented method of claim 4, further comprising provisioning each of said signers with a local LMS public key, effectively causing each of said signers to operate independently after said provisioning.

12. The computer implemented method of any one of claims 4 to 11, further comprising: computing at the provisioning server a Layton-Micali One-Time Signature (LM-OTS) public key.

13. The computer implemented method of any one of claims 4 to 12, further comprising verifying that each of the signers independently signs with a common LMS public key.

14. generating a complete Merkle tree at the secured and accessible provisioning server and provisioning back to each of the signers using an offline channel the seed to be used and at least a portion of the Merkle tree; The computer implemented method of any one of claims 4 to 8, further comprising:

15. At least one processor; At least one computer readable storage medium comprising instructions that, when executed by said at least one processor, cause said at least one processor to perform a computer implemented method according to any one of claims 1 to 14; Provisioning server, including

16. A program causing at least one processor to execute a computer-implemented method according to any one of claims 1 to 14.

Images