Device and method for obtaining signing keys for use in HASH-based signature schemes

Abstract

Embodiments of present disclosure provide electronic device (200) and method (300) for obtaining signing keys for use in stateful S-HBS schemes. The method (300) creates signing key associated to first point in time given in a time reference of clock known to the electronic device (200). The signing key comprises plurality of signing keys. The method (300) assigns unique time window to each signing key. The unique time window for each signing key relates to the first point in time. Further, each signing key is active for signing data item within a time frame given by the time window corresponding to that signing key.

Description

[0001] DEVICE AND METHOD FOR OBTAINING SIGNING KEYS FOR USE IN HASH-BASED SIGNATURE SCHEMES

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to device, method and computer program product for obtaining signing keys for use in the Hash-Based Signature, HBS schemes.

[0004] BACKGROUND

[0005] In cryptography, a digital signature is a mechanism used to verify authenticity of data, for example data in messages or documents. The digital signature may also be referred to as a cryptographic digital signature. The cryptographic digital signature is generally used in modern security protocols such as Secure Shell, SSH, Internet Protocol Security, IPsec, Transport Layer Security, TLS, Secure Multipurpose Internet Mail Extension, S / MIME and so on, to ensure authenticity of communicating parties during communication. The authentication of the communicating parties is performed for different purposes such as for identity binding, for providing integrity protection of a software module such as an application, program etc., for integrity protection of firmware, for integrity protection of microcode, for software authenticity, and for providing digitally signed contracts.

[0006] For example, the identity binding is a process that associates credentials related to an entity such as one of the communicating parties.

[0007] For example, software authenticity and integrity protection involve signatures of software, including the firmware. The firmware is a form of microcode or program that is embedded into hardware devices to operate effectively. Thus, software authenticity and integrity protection ensure that unauthorized parties cannot modify the firmware.

[0008] Similarly, software authenticity and integrity protection ensure that unauthorized parties cannot modify the microcode of a microprocessor, wherein the microcode may be referred to as microinstructions, especially of a micro-process.

[0009] Thus, the cryptographic digital signatures used in the modern security protocols verify authenticity of the data and the communicating parties. At present, most widely used cryptographic digital signatures for performing are based on integer factorization. Examples of such algorithms are RSA also known as Rivest Shamir Adleman algorithm, ECDSA also known as Elliptic Curve Digital Signature algorithm, and EdDSA also known as Edwards-Curve Digital Signature algorithm.

[0010] Quantum computing is a rapidly emerging technology that harnesses laws of quantum mechanics to solve problems that are complex for classical computers. Currently, quantum computing is used for research and demonstrations. However, if a cryptographically relevant quantum computer, CRQC, would be developed, it would pose a threat to the commonly used cryptographic digital signature schemes that were mentioned above. For example, Shor's algorithm is quantum algorithm that may be used to break security of the cryptographic digital signature schemes / algorithms when the cryptographically relevant quantum computers become available in the future. Though the availability of the CRQC is projected to be decades in the future, in many cases signatures created to authenticate contracts or data today need to be verified in the future, and verification keys created today need to verify signatures in the future. This may be relevant especially in sectors such as banking, security organizations, mobile networks, internet, etc. Similarly, data needs to be protected in sectors such as telecommunications industry for long time to align with evolving standards of the telecommunication and life cycles of hardware. The life cycle of the hardware generally includes ideation, design, manufacture, testing, distribution, usage etc. An important use case for signatures in the telecommunications industry is for firmware update, software update, and secure boot.

[0011] Post-Quantum Cryptography, PQC, consists of cryptographic algorithms that provide security against a cryptanalytic attack performed by the quantum computer / CRQC. PQC schemes are also referred to as quantum-proof, quantum-safe, or quantum-resistant cryptographic algorithms. Currently, a set of new PQC algorithms are being standardized by the National Institute of Standards and Technology, NIST and the schemes are also propagated to different Internet EngineeringTask Force, IETF and 3rdGeneration Partnership Project, 3GPP, standards to standardize quantum resistant cryptographic primitives and their use. For example, the NIST has currently published a draft standard for a key encapsulation method such as Module- Lattice-based Key-Encapsulation Mechanism, ML-KEM and two different signature schemes such as Module-Lattice-based Digital Signature Algorithm, ML-DSA and Stateless Hash-based Digital signature Algorithm, SLH-DSA. Additionally, before the aforementioned standard drafts, there existed a published standardization that focused on existing stateful hash-based schemes such as extended Merkle Signature Scheme, XMSS and Leighton Micali Signatures, LMS. In addition, the NIST provided instructions on how to handle the XMSS and LMS. The XMSS and LMS are based on Merkle trees and one-time signature schemes, OTS. Furthermore, the standards include multi-tree variant of both XMSS and LMS called XMSSAMT and HSS respectively.

[0012] When it comes to a PQC signature schemes, the PQC signature scheme may be classified into being either a stateless or a stateful signature scheme. The stateless signature schemes are quite similar to existing signature schemes that are based on the RSA and elliptic curves. In the stateless signature schemes, the cryptographic digital signatures may be generated repeatedly using the same key for signing the data. For example, the ML-DSA and the SLH- DSA are stateless signature schemes.

[0013] However, on the other hand, the stateful signature scheme such as stateful hash-based signatures, S-HBS, are secure only if sub-keys / subsets of the keys are never re-used during signing / signature generation. In the S-HBS, signing a data item with a key that was previously used may either seriously weaken, or completely break the security of the signing keys. Therefore, using the S-HBS scheme requires a signer to remember which portion of the whole key, i.e., the sub-keys, have been used and which sub-keys remain unused. The portion that the signer should remember is a state of the key. This state of the key must be maintained with an S-HBS key at the time of signing. For instance, in the XMSS the state is an index, i.e., an integer, which is pointing to a next unused leaf, i.e., a one-time-signature, in a tree. Further, the XMSS and LMS are examples of the stateful signature schemes.

[0014] Module-Lattice-Based Digital Signature Standard, NIST, FIPS 204 (Draft) (Gina M. Raimondo, Laurie E. Locascio, Published August 24, 2023) is a standard which specifies that digital signatures are used to detect unauthorized modifications to data and to authenticate the identity of the signatory. In addition, the recipient of signed data can use a digital signature as evidence in demonstrating to a third party that the signature was, in fact, generated by the claimed signatory. The ML-DSA is an algorithm that can be used to generate and verify digital signatures. The ML-DSA is believed to be secure even against adversaries in possession of a large-scale quantum computer. Stateless Hash-Based Digital Signature Standard, NIST, FIPS 205 (Draft) (Gina M. Raimondo, Laurie E. Locascio, Published August 24, 2023) is a standard which specifies the stateless hash-based digital signature algorithm, SLH-DSA. Digital signatures are used to detect unauthorized modifications to data and to authenticate the identity of the signatory. The SLH-DSA is based on practical stateless hash-based signatures schemes, SPHINCS+, which was selected for standardization as part of the NIST Post-Quantum Cryptography Standardization process.

[0015] Recommendation for Stateful Hash-Based Signature Schemes, NIST, SP 800-208 (David A. Cooper, Daniel C. Apon, Quynh H. Dang, Michael S. Davidson, Morris J. Dworkin, Carl A. Miller, Published October 2020) is a document which specifies practices related to two algorithms that can be used to generate a digital signature, both of which are stateful hash-based signature schemes: the Leighton-Micali Signature, LMS, system and the extended Merkle Signature Scheme, XMSS, along with their multi-tree variants, the Hierarchical Signature System, HSS and multi-tree XMSS, XMSSAMT. Further, the ML-DSA and the SLH-DSA are stateless hash-based digital signature algorithms, while the LMS and the XMSS are stateful hash-based digital signature algorithms. The stateful hash-based digital signature algorithms, i.e., the LMS and the XMSS are used to generate the digital signatures.

[0016] SUMMARY

[0017] It is an object of the present disclosure to provide an electronic device and a method for obtaining signing keys for use in stateful hash-based signature, S-HBS, schemes specifically to mitigate, alleviate, or eliminate all or at least some of the above-discussed drawbacks of presently known solutions.

[0018] This and other objects are achieved by means of an electronic device, and a method defined in the appended claims.

[0019] According to a first aspect of the present disclosure, a method performed in an electronic device for obtaining signing keys for use in stateful hash-based signature, S-HBS, schemes is provided. The method comprises creating a key sequence associated to a first point in time given in a time reference of a clock known to the electronic device. The signing key comprises a plurality of signing keys. The method comprises assigning a unique time window to each signing key. The unique time window for each signing key relates to the first point in time. Each signing key is active for signing data item within a time frame given by the time window corresponding to that signing key.

[0020] Optionally, the plurality of signing keys in the key sequence are created in a sequence, wherein each signing key has a key index number, wherein the key index number is increased for each signing key, wherein each signing key is of use for one time signing of the data item.

[0021] Optionally, the assigning comprises computing the key index number for each signing key of the plurality of signing keys for signing data item.

[0022] Optionally, the method comprises selecting at least one of the signing keys from the plurality of signing keys for signing the data item at a second point in time given in the time reference of the clock. The selection comprises finding the at least one signing key which corresponds to a time window comprising the second point in time.

[0023] Optionally, the at least one signing key is selected according to a key counter value used to identify whether the at least one selected signing key is an active signing key corresponding to the time window comprising the second point in time.

[0024] Optionally, the key counter value is determined from at least one of the first point in time, a time quanta length of the unique time window(s) and / or the second point in time given in the time reference of the clock.

[0025] Optionally, the method comprises comparing the key counter value with a maximum used key index value, wherein the maximum used key index value provides the index of a previously used signing key. The method comprises identifying the at least selected one signing key as an active signing key when the key counter value is greater than the maximum used key index value.

[0026] Optionally, the method comprises comparing the key counter value with a maximum used key index value, wherein the maximum used key index value provides an index of a previously used signing key. The method comprises identifying the at least one selected signing key as an inactive signing key when the key counter value is smaller than the maximum used key index value. The method comprises disabling signing of data item using said at least one selected signing key identified as inactive, wherein said at least one inactive signing key comprises a previously used signing key used for signing data item and / or an expired signing key unused within the unique time window and / or a damaged signing key.

[0027] In an example, when there is more than one selected signing key, the plurality of selected signing keys may be used at different locations.

[0028] Optionally, the method comprises generating a signature for the at least one selected signing key when the at least one selected signing key is identified as the active signing key. The data item is signed via the at least one selected signing key. The method comprises updating the maximum used key index value with each selection of a next signing key from the plurality of signing keys to be used for signing the data item.

[0029] Optionally, the method comprises updating the maximum used key index value after an expiry of the time quanta length of the unique time window assigned to at least one selected signing key. The at least one selected signing key remains unused during the unique time window, wherein the unused at least one selected signing key is the inactive key.

[0030] Optionally, the unique time window comprises a time quanta length defining a time-period for signing the data item via the at least one signing key.

[0031] Optionally, the first point in time given in the time reference of the clock is different from the second point in time given in the time reference of the clock, wherein the second point in time given in the time reference of the clock comprises a monotonic time value.

[0032] Optionally, the creating comprises creating all signing keys at the first point in time given in the time reference of the clock.

[0033] Optionally, the creating comprises creating the signing keys at different points in time after the generation of key sequence created at the first point in time given in the time reference of the clock.

[0034] Optionally, the at least one key sequence comprises a stateful hash-based key.

[0035] According to a second aspect of the present disclosure, an electronic device for obtaining signing keys for use in stateful hash-based signature, S-HBS, schemes is provided. The electronic device comprises a processing circuitry for creating a key sequence associated to a first point in time given in a time reference of a clock known to the electronic device. The key sequence comprises a plurality of signing keys. The electronic device comprises the processing circuitry for assigning a unique time window to each signing key. The unique time window for each signing key relates to the first point in time. Each signing key is active for signing data item within a time frame given by the time window corresponding to that signing key.

[0036] According to a third aspect of the present disclosure, there is provided a computer program product comprising a non-transitory computer readable medium, having thereon a computer program comprising program instructions. The computer program is loadable into a data processing unit and configured to cause execution of the method according to the first and second aspects when the computer program is run by the data processing unit.

[0037] With the solution as defined herein a mechanism is provided ensuring that a key which was previously used will not be reused again for signing the data. Further, backing up the states of the keys to perform the signing can be avoided. Furthermore, it is desirable for a key to degrade predictably rather than having several backups or experiencing unexpected loss of usable key parts due to repeated hardware failures.

[0038] Some embodiments disclosed herein have one or more of the following advantages:

[0039] The proposed method avoids the need to back up the S-HBS state. Further, since there is no state in the backups, there is no risk of accidentally using the wrong backup. When using the proposed method, a back-up is only made for the keys, creation time of the keys i.e. to, and time quanta length 6t, which is also referred to as unique time window. This information does not change over time. The proposed method also simplifies the process of making and restoring backups after use of the keys to avoid reuse of the keys, as backup is done for the key and not the states of the keys.

[0040] The proposed method allows the stateful hash-based schemes and other stateful keys to be backed up safely without any risk of key compromise due to restoration of the backup.

[0041] The proposed method enables the usability of the stateful hash-based keys without the need for a standardization of different scheme for signing data without reusing / repeating the keys. The proposed method mitigates the significant risk of losing the ability to use the key prematurely, safeguarding against potential challenges posed by the development of cryptographically relevant quantum computers. During normal operations, the proposed method allows either a single key ktto be used at most once or not be used at all.

[0042] During recovery, the proposed method allows for performing external verification. This allows for ensuring correct synchronization with the wall clock time. Waiting until next time quanta length ensures that any previously used key will remain unused.

[0043] The proposed method ensures that a malfunctioning requester of a high number of signatures can only use up a part of the key reserved for a time quantum, but not the entire key.

[0044] The proposed method provides a mechanism ensuring that a key which was previously used will not be reused again for signing the data. Further, the proposed method limits the requirement for consensus formation, and eliminates the necessity for backing up or synchronizing the states of the keys to perform the signing. This is because, the signing operation becomes a bottleneck for performance and availability.

[0045] The proposed method provides signing keys that degrade predictably rather than having several backups or experiencing unexpected loss of usable key parts due to repeated hardware failures.

[0046] Other advantages may be readily apparent to one having skill in the art. Certain embodiments may have none, some, or all of the recited advantages.

[0047] BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The foregoing will be apparent from the following more particular description of the example embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the example embodiments.

[0049] FIG. 1 illustrates a stateful hash-based scheme;

[0050] FIG. 2A discloses an example of a wireless communication system;

[0051] FIG. 2B discloses a block diagram of an example electronic device for obtaining signing keys for use in hash-based signature schemes;

[0052] FIGs. 3a-3i illustrate flowcharts showing example steps for a method for obtaining signing keys for use in stateful hash-based signature schemes; FIG. 4 discloses a schematic diagram for obtaining signing keys for use in stateful hash-based signature schemes; and

[0053] FIG. 5 discloses an example computing environment.

[0054] DETAILED DESCRIPTION

[0055] Aspects of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. The apparatus and methods disclosed herein can, however, be realized in many different forms and should not be construed as being limited to the aspects set forth herein. Like numbers in the drawings refer to like elements throughout.

[0056] The terminology used herein is for the purpose of describing particular aspects of the disclosure only and is not intended to limit the invention. It should be emphasized that the term "comprises / comprising" when used in this specification is taken to specify the presence of stated features, integers, steps, or components, but does not preclude the presence or addition of one or more other features, integers, steps, components, or groups thereof. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0057] Embodiments of the present disclosure will be described and exemplified more fully hereinafter with reference to the accompanying drawings. The solutions disclosed herein can, however, be realized in many different forms and should not be construed as being limited to the embodiments set forth herein.

[0058] It will be appreciated that when the present disclosure is described in terms of an electronic device and a method, it may also be embodied in one or more processors and one or more memories coupled to the one or more processors, wherein the one or more memories store one or more programs that perform the steps, services and functions disclosed herein when executed by the one or more processors.

[0059] Stateful Hash-Based Signature, S-HBS schemes by definition use cryptographic hashes that involve multiple keys organized into a tree-like structure of sub-keys. In this tree-like structure, a single key or subset of keys that are participating in the generation of the signature should not be re-used. In order to ensure this, states of the keys or sub-keys needs to be stored. Further, the stateful hash-based algorithms are structured collections of "one-time signatures." For example, original private keys for individual signatures consist of a large collection of sub-keys with only a portion being utilized while all of the sub-keys must be generated in any case. In contrast, public keys and signatures consist of a considerably smaller set of hashes as well as other information. To maintain the security of the stateful hash-based algorithm, it is crucial to monitor the state of the key, i.e., which parts of the key have already been used, since any repetition of the signing key intended for single use compromises security. For example, these one-time signing keys may be organized into a Merkle tree, which may be observed to have a certain inherent structure, as illustrated in FIG. la. The one-time signing keys may also be organised in a multitree comprising several Merkle trees.

[0060] Further, in order to prevent the reuse of the key components / parts, it is essential to possess both the private key itself and current information / data on the previously utilized parts of the private key before signing. However, for any long-lived key that may be hard to replace, a backup of the key should be maintained to enable retrieval of the long-lived key in case it is lost due to hardware or software failure. In such cases, it is crucial to have the correct state information or an up-to-date state information to avoid reusing of any parts of the key that have already been used after making the backup.

[0061] For example, consider a simplified scenario where all individual one-time-signing keys may be represented using integers {1,2, 3, 4, 5, 6...}. In this context, occurrence of the following type of pattern A-E as shown below should be avoided during signing:

[0062] A) Sign with one-time key 1.

[0063] B) Back up the key and its states to another device.

[0064] C) Sign with one-time key 2.

[0065] D) Restore backup from another device due to break down of original device.

[0066] E) Sign a data item again with the one-time key 2 as the restored backup does not have the information of step (C) which has already been performed.

[0067] This pattern should be avoided in order to not reuse a key that has already been used for signing data. For example, as shown in the pattern, the one-time key 2 is used to sign the data, and after assigning there is a breakdown of the original device. Further, after the occurrence of the breakdown, a backup of the keys is restored to another device. However, the backup does not contain information that key 2 has already been used to sign the data. Thus, this pattern causes the reuse of the key 2 which may break the security of the signing keys.

[0068] A trivial way to avoid the risk of accidentally recovering a key with incorrect state is to prevent the key from being backed up at all. If it cannot be backed up, then it cannot be recovered, therefore its state cannot be in inconsistent state. However, this solution is unsatisfactory, as it is unacceptable in many scenarios to not be able to back up the keys. Further, dividing / splitting the one key into one or more parts and assigning the one or more part of the key to multiple devices and / or transferring the key 1-to-l to other devices may not be preferred as it does not protect against a sudden loss of the storage device. Individual Hardware Security Modules, HSM, could have shorter lifespan compared to, for example, public keys, i.e., signature verification keys used in hardware that is designed to endure in the field for decades. Further, for long-term key management, equipment failures are rare but are expected to occur. For example, the equipment referred here is HSM equipment such as a physical computing device.

[0069] Further, being able to ensure the ongoing availability of the signing key despite equipment malfunctions, site fires, or discontinued availability of an HSM vendor, is a crucial aspect of maintaining and providing a reliable root of trust to any public key infrastructure.

[0070] The S-HBS schemes require the states of the key to be stored for avoiding use of the same keys for generating signatures. In existing solutions upon creation of the key, the key would be backed up and stored securely until it would be needed for recovery in case of hardware or software failure. However, for the S-HBS, a single backup of the key is not sufficient. This is because, upon performing the recovery after hardware or software failure, it would lack necessary information, i.e., the state, of any keys that may have been used since the backup. Thus, the S-HBS backup should also include the key state along with the keys.

[0071] The S-HBS backup does create an additional challenge, since along with the backup of the key, the state of the key needs to be backed up after each signing operation.

[0072] In an example, several approaches are performed in existing solution to address the risk of key-reuse with the S-HBS schemes: - A first approach involves prohibiting backups or export of the S-HBS keys. By prohibiting the backups or the export of the S-HBS key, the key would never leave a protected environment, and thus, the key cannot be re-installed either. However, this does not address the problem of actual backup and recovery of the keys.

[0073] - A second approach is to distribute the S-HBS keys over multiple different devices so that each one of the devices only uses a dedicated portion of the whole key space. Further, by distributing the original key after the creation of the key, across multiple different devices, complete loss of signing capability is avoided if there is a loss of one device. However, this would still not solve the problem of the backup and recovery of the keys.

[0074] - Consider a case where anticipated loss of the key involves accidental deletion of keys caused by human error or software error, while the original hardware / hardware counters remain operational / intact. In such a case, a third approach involves incorporating a monotonic counter in the hardware to ensure that even after the key recovery, the key will not be reused. This approach, however, would work only in cases where the original hardware remains operational.

[0075] - In accordance with a fourth approach some of the key space is reserved in advance for backup. If recovery of the keys is necessary in a later stage, the already-reserved key space will not be reused. However, this approach requires coordination to ensure that only the most recent backup is recovered.

[0076] - Further, an example of ow-frequency signing use cases is provided, wherein it is suggested that external, i.e., manual controls could be employed for writing down the key index after a signing operation and, conversely, prior to the signing operation, comparing the device state to the previous known state for verification. The manual control may include human operators.

[0077] - In accordance with a fifth approach, multiple devices have the capabilities to synchronize their current state either among themselves and / or with a centralized coordinator and / or between the HSMs. However, this would still not solve the problem of the backup and recovery of the keys. The fifth approach reduces the chance of loss of the state of the keys across the multiple devices but does not completely eliminate the need for disaster recovery scenario, in which case backup and recovery of the key is needed. - A sixth approach involves use of multiparty threshold schemes, where a signature requires collaboration across multiple separate entities. This could provide a way to recover from a failure of one or more devices. In such case, as long as at least one node retains the correct state history, key reuse may be prevented. However, in case all the nodes are lost for a reason, then backup and recovery of the keys is required.

[0078] - A seventh approach involves use of one of a scheme, i.e., Key management for stateful hashbased cryptography for managing the state of S-HBS during backup and recovery of the keys.

[0079] The above-mentioned proposals / approaches performed in the existing solutions may have one or more limitations as described below:

[0080] Firstly, not allowing the key to be backed up or exported is infeasible for long-term continuity of the signing entity across potential software and hardware failures. Further, hardware monotonic counters may protect against loss of keys within a specific hardware but would not allow recovery of the keys after complete hardware failure or destruction.

[0081] Secondly, reserving keys for future use during a periodic backup requires the reservation to be sufficiently large to meet needs until the next backup and also need to ensure that only latest the backup is loaded during recovery of the keys.

[0082] Thirdly, distributing keys across the multiple devices will cause loss of the sub-partition of the signing keys if there is a loss of a device. Further, there is risk of losing all copies of the key within a short time period if there is a malfunctioning across all the devices. This can occur due to correlated failures such as software bugs.

[0083] Fourthly, distributing the states of the keys increases the overall system complexity, as the states of the keys need to be synchronized across the distributed devices. Thus, if there is a failure during synchronization, it would imply potential re-use of the key if operations are continued. This situation requires pausing signature generation during a communication failure and imposes a restriction on the maximum rate at which signatures can be generated.

[0084] FIG. 2a discloses an example wireless communication system 100. Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the examples disclosed herein are described in relation to a wireless communication system / wireless network, such as the example wireless communication system 100 described in FIG. 2a.

[0085] The wireless communication system 100 may comprise and / or interface with any type of communication, telecommunication, data, cellular, and / or radio network or other similar type of system. The wireless communication system 100 may be configured to operate according to specific standards or other types of predefined rules of procedures. Thus, the wireless communication system 100 may implement communication standards, such as, but not limited to, global system for mobile communications, GSM, universal mobile telecommunications system, UMTS, long term evolution, LTE, and / or other suitable 2G, 3G, 4G, or 5G standards, wireless local area network, WLAN, standards such as, IEEE 802.11 standards, and / or any other appropriate wireless communication standards, such as, worldwide interoperability for microwave access, WiMax, Bluetooth, Z-Wave and / or ZigBee standards.

[0086] For simplicity, as depicted in FIG. 2a, the wireless communication system 100 comprises an electronic device 200, a network node 104, and a network 106. The electronic device 200 and the network node 104 operate together in order to provide wireless connections in the wireless communication system 100. The network 106 may comprise one or more backhaul networks, core networks, IP networks, public switched telephone networks, PSTNs, packet data networks, optical networks, wide-area networks, WANs, local area networks, LANs, wireless local area networks, WLANs, wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices (for example, wireless devices and a network node).

[0087] The network node 104 may refer to equipment capable, configured, arranged, and / or operable to and / or with other network nodes or equipment in the wireless communication system 100 to enable and / or provide wireless access and / or to perform other functions (for example, administration) in the wireless communication system 100. Examples of the network node 104 include, but are not limited to, access points, APs (for example, radio access points), base stations, BSs (for example, radio base stations, nodeBs, evolved NodeBs, eNBs, new radio, NR, nodes (gNBs), or the like). The BSs may be categorized based on an amount of coverage the BSs provide (or, stated different, their transmit power level) and may then also be referred to as femto BSs, pico BSs, micro-BSs, macro-BSs. The BS may be a relay node or a relay donor node controlling a relay.

[0088] The electronic device 200 may refer to a device capable, configured, arranged and / or operable to communicate wirelessly with the network node 104 and / or other wireless devices.

[0089] In some examples, the wireless devices may include one or more of: computing devices, ultralow power wireless devices, Internet of Things, loT, devices, and so on.

[0090] Examples of the computing devices may include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over Internet Protocol, IP, VoIP, phone, a wireless local loop phone, a desktop computer, a personal digital assistant, PDA, a wireless camera, a gaming console or device, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment, LEE, a laptop-mounted equipment, LME, a smart device, a wireless customer-premise equipment, CPE, a vehicle- mounted wireless terminal device, and so on.

[0091] It should be understood that the electronic device 200 may not be limited to the abovedescribed wireless devices. The electronic device 200 may be extended to other wireless devices of different classes or categories providing different services while supporting, for example, Enhanced Mobile Broadband, eMBB, massive Machine-Type Communication, MTC, Ultra-Reliable Low Latency Communication, URLLC, Time Sensitive Networking, TSN, or the like.

[0092] In the wireless communication system 100, the network node 104 and the electronic device 200 may be connected to 3GPP 5G core network, where specific network services and operations are provided through software components called network functions, NFs. The wireless communication system 100 may host large scale applications.

[0093] The present disclosure presents a wireless communication network 100, a network node 104 and the electronic device 200, wherein the electronic device 200 is adapted for obtaining signing keys for use in stateful hash-based signatures, S-HBS, schemes without any backup of the key states. FIG. 2b discloses a schematic diagram of the electronic device 200 for obtaining signing keys for use in S-HBS schemes according to some embodiments.

[0094] In FIG. 2b, the example electronic device 200 may be implemented in a user equipment. The electronic device 200 is illustrated comprising one or more modules. The one or more modules may comprise a memory 1004, a processor 1006, a controlling circuitry 1008, and a driver 1010. The controlling circuitry 1008 also referred as processing circuitry 1008, may be adapted to control the other modules. In an example, the controlling circuitry 1008 may be alternatively referred as processing circuitry 1008.

[0095] The memory 1004, the processor 1006 and the driver 1010 as well as the processing circuitry 1008, may be operatively connected to each other.

[0096] The memory 1004 may be adapted to store the key sequence comprising the plurality of signing keys relating to a communication attempt from the electronic device 200.

[0097] The processing circuitry 1008 may be adapted to control the steps as executed by the electronic device 200. For example, the processing circuitry 1008 may be adapted to create the key sequence associated to the first point in time given in the time reference of the clock known to the electronic device 200. The key sequence comprises the plurality of signing keys. The processing circuitry 1008 may be adapted to assign the unique time window to each signing key. The unique time window for each signing key relates to the first point in time. Each signing key is active for signing data item within the time frame given by the time window corresponding to that signing key.

[0098] In an example, the unique time window is a non-overlapping time window. That is, the unique time window that is assigned to each signing key, do not overlap with other time windows.

[0099] Optionally, the plurality of signing keys in the key sequence are created in a sequence, wherein each signing key has the key index number, wherein the key index number is increased for each signing key, wherein each signing key is of use for one time signing of the data item.

[0100] Optionally, the processing circuitry 1008 may be adapted to compute the key index number for each signing key of the plurality of signing keys for signing data item. Optionally, the processing circuitry 1008 may be adapted to select at least one of the signing keys from the plurality of signing keys for signing the data item at the second point in time given in the time reference of the clock. The selection comprises finding the at least one signing key corresponding to the time window comprising the second point in time.

[0101] Optionally, the at least one signing key is selected according to the key counter value used to identify whether the at least one selected signing key is an active signing key which corresponds to the time window comprising the second point in time.

[0102] Optionally, the key counter value is determined from at least one of the first point in time, a time quanta length of the unique time window(s) and / or the second point in time given in the time reference of the clock.

[0103] Optionally, the processing circuitry 1008 may be adapted to compare the key counter value with the maximum used key index value, wherein the maximum used key index value provides the index of the previously used signing key. The processing circuitry 1008 may be adapted to identify the at least selected one signing key as an active signing key when the key counter value is greater than the maximum used key index value.

[0104] Optionally, the processing circuitry 1008 may be adapted to compare the key counter value with the maximum used key index value, wherein the maximum used key index value provides an index of the previously used signing key. The processing circuitry 1008 may be adapted to identify the at least one selected signing key as an inactive signing key when the key counter value is smaller than the maximum used key index value. The processing circuitry 1008 may be adapted to disable signing of data item using said at least one selected signing key identified as inactive, wherein said at least one inactive signing key comprises the previously used signing key used for signing data item and / or an expired sub-key unused within the unique time window and / or a damaged signing key.

[0105] Optionally, the processing circuitry 1008 may be adapted to generate the signature for the at least one selected signing key when the at least one selected signing key is identified as the active signing key. The data item is signed via the at least one selected signing key. The processing circuitry 1008 may be adapted to update the maximum used key index value with each selection of the next signing key from the plurality of signing keys to be used for signing the data item. Optionally, the processing circuitry 1008 may be adapted to update the maximum used key index value after an expiry of the time quanta length of the unique time window assigned to the selected at least one signing key. The at least one selected signing key remains unused during the unique time window, wherein the unused at least one selected signing key is the inactive key.

[0106] Optionally, the unique time window comprises the time quanta length defining the timeperiod for signing the data item via the at least one signing key.

[0107] Optionally, the first point in time given in the time reference of the clock is different from the second point in time given in the time reference of the clock, wherein the second point in time given in the time reference of the clock comprises the monotonic time value.

[0108] Optionally, the processing circuitry 1008 may be adapted to create all signing keys at the first point in time given in the time reference of the clock.

[0109] Optionally, the processing circuitry 1008 may be adapted to create the signing keys at different points in time after the generation of the key sequence created at the first point in time given in the time reference of the clock.

[0110] Optionally, the key sequence comprises the stateful hash-based key.

[0111] FIG. 3a is a flowchart illustrating example steps for a method 300 implemented in the electronic device 200 for obtaining signing keys for use in S-HBS schemes. For example, the method 300 is performed in the electronic device 200 for obtaining the signing keys for use in the S-HBS schemes.

[0112] At step 302 of FIG. 3a, the method 300 comprises creating the key sequence associated to the first point in time given in the time reference of the clock known to the electronic device 200. The key sequence comprises the plurality of signing keys.

[0113] At step 304 of FIG. 3a, the method 300 comprises assigning the unique time window to each signing key. The unique time window for each signing key relates to the first point in time. Each signing key is active for signing data item within the time frame given by the time window corresponding to that signing key. Optionally, the plurality of signing keys in the key sequence are created in a sequence, wherein each signing key has a key index number, wherein the key index number is increased for each signing key, wherein each signing key is of use for one time signing of the data item.

[0114] Optionally, in step 328 of FIG. 3b, the method 300 provides computing the key index number for each signing key of the plurality of signing keys for signing data item.

[0115] Optionally, in step 306 of FIG. 3c, the method 300 provides selecting at least one of the signing keys from the plurality of signing keys for signing the data item at a second point in time given in the time reference of the clock, wherein the selection comprises finding the at least one signing key which corresponds to a time window comprising the second point in time.

[0116] Optionally, the at least one signing key is selected according to a key counter value used to identify whether the at least one selected signing key is an active signing key corresponding to the time window comprising the second point in time.

[0117] Optionally, the key counter value is determined from at least one of the first point in time, a time quanta length of the unique time window(s) and / or the second point in time given in the time reference of the clock.

[0118] Optionally, at step 308 of FIG. 3d, the method 300 provides comparing the key counter value with a maximum used key index value, wherein the maximum used key index value provides the index of a previously used signing key; and at step 310, the method 300 provides identifying the at least selected one signing key as an active signing key when the key counter value is greater than the maximum used key index value.

[0119] In an example, the maximum used key index value would as default be zero initially when comparing with the key counter value. That is when a sub-key is selected for the first time for signing data, the maximum used key index value is zero. In another example, the maximum used key index value is zero when the sub-key is selected for the first time for signing data if the electronic device 200 generates the signing keys by itself. In an example, the key counter value is calculated using equation 1 as shown below. The key counter value i may be determined at any moment in time by using a current time t, key creation time / first point in time t0and the time quanta length 6tas shown in the equation 1. Further, the equation 1 is rounded to an upper value, thus the equation 1 would most likely provide i = 1 as first value, and if that is stored as iused, first key of the plurality of signing keys will never be used. Further, iused= 0 at initialization indicates key k can be used for the time window associated with i = 1.

[0120] Optionally, at step 312 of FIG. 3e, the method 300 provides comparing the key counter value with a maximum used key index value, wherein the maximum used key index value provides an index of a previously used signing key; and at step 314, the method 300 provides identifying the at least one selected signing key as an inactive signing key when the key counter value is smaller than the maximum used key index value.

[0121] At step 316, the method 300 provides disabling signing of data item using said at least one selected signing key identified as inactive, wherein said at least one inactive signing key comprises a previously used signing key used for signing data item and / or an expired signing key unused within the unique time window and / or a damaged signing key.

[0122] Optionally, at step 318 of FIG. 3f, the method 300 provides generating a signature for the at least one selected signing key when the at least one selected signing key is identified as the active signing key, wherein the data item is signed via the at least one selected signing key; and at step 320, the method 300 provides updating the maximum used key index value with each selection of a next signing key from the plurality of signing keys to be used for signing the data item.

[0123] Optionally, at step 322 of FIG. 3g, the method 300 provides updating the maximum used key index value after an expiry of the time quanta length of the unique time window assigned to the at selected at least one signing key.

[0124] Optionally, the at least one selected signing key remains unused during the unique time window, wherein the unused at least one selected signing key is the inactive key.

[0125] Optionally, the unique time window comprises a time quanta length defining a time-period for signing the data item via the at least one signing key.

[0126] Optionally, the first point in time given in the time reference of the clock is different from the second point in time given in the time reference of the clock, wherein the second point in time given in the time reference of the clock comprises a monotonic time value. Optionally, at step 324 of FIG. 3h, the method 300 provides creating all signing keys at the first point in time given in the time reference of the clock.

[0127] Optionally, at step 326 of FIG. 3i, the method 300 provides creating the signing keys at different points in time after the generation of the key sequence created at the first point in time given in the time reference of the clock.

[0128] Optionally, the at least one key sequence comprises a stateful hash-based key.

[0129] In an example, the proposed electronic device 200 and method 300 identify the signing key by using a wall clock which is the clock known to the electronic device 200 and the time quanta. In another example, the wall clock is a global time which is obtained via direct Global Positioning System, GPS-backed clock hardware or via network time protocol. The signing key may be referred to as the signing key, while the time quanta may be referred to as time quanta length or the unique time window. Further, the proposed electronic device 200 and method 300 assigns the signing key, i.e., a single key, to each time quanta that passes. The signing key that is assigned to each time quanta may be used within that unique time window corresponding to the time quanta. However, if no signing operation is performed during the unique time window corresponding to the time quanta, then the particular signing key is left unused permanently. In another case, if the signing operation is performed during the unique time window corresponding to the time quanta, then a signer must wait until the next time quanta length to perform another signing operation. Further, since the wall clock time is easily verified during recovery of the signing key, this ensures that internal state, i.e., state of the signing key does not have to be separately backed up.

[0130] For example, monotonic counters are typically addressed within hardware context, and with a potential to use manual, i.e., human, controls. In an example, the monotonic counters represent hardware counters that exist on the electronic device 200. However, integration of externally verifiable monotonic counters with the wall clock time has not been fully explored. Further, many use cases requiring the cryptographic digital signatures may rely on access to an accurate time, thus making a clock source essential rather than an extra burden for the use cases.

[0131] In an example, consider that the Stateful Hash-based Signature, S-HBS, key K is represented as a sequence of individual signing keys K = {kltk2, k3, k4... , kn}. In an example, the key sequence may comprise the plurality of signing keys, i.e., K = {kltk2, k3, k4... , kn} as shown in FIG. 4, where n is a maximum number of signing keys that may be used securely for communication. Further, upon creation of the signing key K, at least two parameters may be added and stored with the signing key K. The at least two parameters may include the first point in time, i.e., t0, when the signing key K was created and the unique time window / time quanta length 6t, i.e., the unit of time that advances a virtual monotonic counter i. In an example, the monotonic counter i may also be referred as key counter value alternatively. Further, FIG. 4 shows the key sequence / C,the plurality of signing keys {kltk2, k3, k4... , kn} along with the first point in time t0, which represents when the key sequence K was created. FIG. 4 also shows the unique time window / time quanta length, 6t, that is assigned to each of the plurality of signing keys. The time quanta length represents the unique time window that is assigned to each of the plurality of signing keys, for signing data item. In an example, the first point in time, i.e., t0may be a time that is set into future, i.e., it may be the first time when the signing key K is used for generating signatures.

[0132] In an example, the unique time window / time quanta length 6tmay also be defined as a timeperiod for signing data via the key sequence K. Further, the monotonic counter i may be determined at any moment in time by using a current time t, key creation time / first point in time t0and the time quanta length 6tas shown in equation (1):

[0133] The monotonic counter value i, also referred as the key counter value is used to select at least one of the signing keys from the plurality of signing keys for signing kt. In an example, this signing key selection mechanism may have implications on signing behaviour, signing throughput, and recovery processes of the signing key:

[0134] In an example, the current time t, needs to be monotonic such as e.g., Universal Time Coordinated, UTC or International Atomic Time, TAI, time. The current time t should not be a non-monotonic time which switches, for example, between winter and summer time. In an example, the current time t may also be referred as the second point in time in the time reference of the clock. In an example, only a single signature / signing of data may be generated per unique time window / time quanta length 6t, implying that maximum throughput, i.e., signatures per second, is

[0135] In an example, the maximum used key index value iusedmust be stored but does not need to be backed up. For instance, if a signature is requested, and current virtual key counter is i > iused, then a signature may be generated, and the maximum used key index value iusedis updated to i.

[0136] In an example, if the signer's perceived time ever drifts backward, then the key counter value i will be decreased, but the maximum used key index value iusedwill prevent the re-use of any signing keys prior to the time drift.

[0137] In an example, the maximum used key index value iuseddoes not have to be backed up, if any future key counter value i is greater than the maximum used key index value, i.e., i > iused.

[0138] In an example, the signing keys K are "used" at a constant rate thus implying that the signing key K is unusable after tmax= t0+ n8t.

[0139] For example, during recovery of the plurality of signing keys, at an arbitrary point of time, the electronic device 200 presents its current view of time for external verifiers to verify if the electronic device 200 is showing incorrect wall clock time or not. If the electronic device 200 shows an incorrect time with respect to the wall clock time, then the external verifiers must not continue with the key recovery. The external verifier may include but is not limited to humans. In an example, after the time of the electronic device 200 is verified at t', which corresponds to the key counter value i', the electronic device 200 may set iusedto i', i.e., the electronic device 200 may resume signing of data only after i > i', after at least one unique time window / time quanta length 6ttime.

[0140] In an example, the proposed electronic device 200 and method 300 assumes that the S-HBS key is stored within a single electronic device 200 and there is only one entity generating signatures for signing the data. In another example, the S-HBS key may be stored within multiple electronic devices 200 and signers. In an example, the signing key could be generated for multiparty threshold scheme, with an additional requirement. That is either all the parties or required minimum subset of parties agree on the wall clock time and the signing key ktto be used for signing the data.

[0141] In an example, each electronic device 200 could be allocated a portion of the whole signing key space. Each of the electronic device 200 would use the allocated portion independently of other electronic devices. One example of such a scheme is that for I number of electronic devices, the key index number for the electronic device is provided as signing key K e [0, 1 — 1] is it,k That is the key index number jumps forward by I during each unique time window / time quanta length, with each of the signing keys allocated to a specific electronic device 200. In an example, each of the signing keys are associated with the key index number.

[0142] In an example, if the expected signature operations are occurring at short intervals, e.g., a large amount of signature requests may be occurring in an hour, but other times of the day there may be no signature requests, a pre-allocation of the signing key range may be used. In this scheme, a unique time window / time quanta length could be relatively long, but for each time quanta length m signing keys would be reserved, i.e., the key index number would jump by ik= m [^7^], but each time quanta length would have m signing keys available ([ik, ik+1, ... , ifc+jji-i]). Further, the maximum throughput, i.e., signatures per second, may be mS1. Further, each time a signature is requested, the maximum used signing key index value iused is updated to iused+ 1.

[0143] These examples may help in generalizing the overall time quanta length-based solution to cover the different types of use cases that likely are present in the concrete use cases for the S-HBS.

[0144] In an example, the proposed electronic device 200 and method 300 require access to a reasonably accurate clock which is known to the electronic device 200. Further, in an example, to generate X.509 or similar certificates from the signing keys like the S-HBS, root of trust keys, a certification authority or another Public Key Infrastructure, PKI, entity, addresses factors like certificate expiration, revocation details, and validation statements. In an example, the X.509 certificates may be digital documents that are used to verify identity of individuals such the communicating parties, organizations or devices over internet. In an example, the X.509 certificate is a datum / data item to be signed in a PKI setting. Further, signing a data item is used to demonstrate ownership of a private key in authentication protocols such as when identifying a server in Transport Layer Security, TLS or both client and server in mutual TLS, mTLS.

[0145] In an example, since the PKI system by default requires access to reliable and secure wallclock time, which is synchronized to global time via direct Global Positioning System GPS- backed clock hardware, or via network time protocol, the access to the wall-clock time is not an additional burden for many use cases of the electronic device 200 and the method 300.

[0146] In an example, one or more use cases of the proposed electronic device 200 and the method 300 for obtaining the signing keys for use in the S-HBS schemes is discussed below:

[0147] In an example, the proposed electronic device 200 and method 300 may be utilized in one or more real-world use cases. For instance, certificate authority preparing for quantum resistance is one such use case.

[0148] In an example, a realistic real world use case would be a Certification Authority, CA, issuing certificates for many actors, a distributed platform, or a set of platforms such as CA / Browser Forum, commercial certification authorities, who wishes to ensure its PKI hierarchy is quantum resistant. Further, the cost of trust anchor updates is very high and takes a long time for this kind of actor, thus, preparation must be done in advance. In an example, the actors may be an individual or group of individuals.

[0149] In an example, a trust anchor or Root CA certificate in X.509 format using the S-HBS scheme could be incorporated into a trust store of any information system that is expected to be long- lived and must validate signatures after a cryptographically relevant quantum computer, CRQC, is created. The holder of the trust store attempts to validate signatures that are either made or derived through a chain of certificates. Further, the holder of the certificate, the validator, and the relying party, are generally separate from each other. In an example, the validator and the relying party may be a same entity. For example, a browser will both validate a server certificate, and rely on the result of that validation to establish whether the connection is secure or not. In an example, the root CA certificate may either sign other certificates that are following the same S-HBS scheme, or it could be used to sign certificates that are from another scheme. Further, in the event of quantum computer emergence, the root CA certificate could revoke the certificates with its signature, typically by signing a Certificate Revocation List and start signing new certificates with a future quantum resistant scheme. The Certificate Revocation List is a signed statement indicating that previously issued certificates should no longer be trusted. Further, in this case, the trust anchors are not required to be updated in the relying parties, as issuing new certificates to users, when they are expiring, would eliminate old, vulnerable algorithms from use.

[0150] For example, in the event of the Root CA certificate following the S-HBS scheme, new signatures would be needed for revocation, and for a new intermediate CA. The intermediate CA could be more than months apart, or for multiple events, the intermediate CA could be close to each other but more than years apart. In an example, the intermediate CA / CAs have their certificates issued by the root CA and are used to sign end-user and server certificates. In an example, time interval between issuances of the intermediate CAs may be either after months (i.e., months apart) or years (i.e., years apart). Thus, using the S-HBS scheme may be a feasible option for the Root CA, since the total number of signatures needed throughout the lifetime of the Root CA is limited, and the expected average rate of issuance is also low. Further, it may be feasible to configure a small set of signatures for use over an extended time quanta length, with consideration that the time taken to restore the backup successfully and to be able to use it should not be prolonged.

[0151] In an example, if active certificate authority, "issuing CA", would issue the S-HBS based certificates rather than using stateless schema, then the issuing CA would need more scalable number of certificates for issuing during a given time. For example, an issuing CA of a large actor is needed to make hundreds, thousands or millions of signatures on a daily basis depending on the use cases. However, the issuing CA could be built to be able to handle a high number of signatures in a day, and predictably replaced over time with another issuing CA before it runs out of usable issuance capacity. Therefore, a high but predictable issuance rate does not prevent from using the scheme, as the "runout" of useable sub-keys for any given issuing CA can be extrapolated in advance, and a replacement issuing CA can be created by the Root CA. In an example, the issuing CA generally retain the capability to sign certificate revocation list, CRL, updates until the certificates it has issued have expired. Typically, the CRL updates are predictable. Also, any schedules planned ahead of time, and the relying parties may not seek out the CRL update more often than the agreed-on schedule, in which case signing the CRL more often does not improve their security.

[0152] For example, in case of a validation authority responding to online validity requests over the Online Certificate Status Protocol, OCSP, the response must be signed with a signing key that is authorized by the CA for which the OCSP responder handles revocations. In many cases, this may be seen as the issuing CA key, but may also be separated from it and focusing only on signing OCSP responses. Further, the unpredictability of the OCSP query schedule may be a threat to a validation authority's stateful key if it had generated a new OCSP response for every request and signed the OCSP response. Further, for stateful schemes, it is also possible to mitigate this issue by defining the OCSP responses to be valid for a given time period, and to generate, sign and cache new responses only for each time period, not on every new query. Further, the OCSP responders will need particular care if used together with stateful schemes to not allow a denial-of-service attack to be made on the CA by using up the active and authorized OCSP signing key ahead of time or exhausting all of its signatures for a given time quanta length.

[0153] In an example, overall, issuance of end entity certificates is more difficult to scale up than protecting a few layers of the CA hierarchy with the S-HBS and using the stateless scheme for end entity certificate issuance. Further, the lifespan of the individual S-HBS issuing CA does not necessarily have to exceed the validity period of the certificates it issues. However, replacements between issuing CAs should be seamless for end users, especially compared to the longer-lived issuing CA. Further, using the S-HBS scheme for high-volume issuing CAs is feasible, particularly when there is a predictable demand for issuance, with advance planning.

[0154] In an example, the proposed electronic device 200 and method 300 may be utilized in one or more real-world use cases. For instance, software or firmware signing for long-lived equipment is another such use case.

[0155] For example, in the use case of software signing, the main concern is for protecting the long- lived recipients of signed software, i.e., systems that cannot have trust anchors and validation mechanisms easily updated over the air either due to security or accessibility reasons. Therefore, these systems must have the backup trust anchor and algorithm in place during manufacturing or during design phase of the hardware to be manufactured and rely on what is currently standardized. For example, a large sea-faring ship or an outbound satellite might need to have reliable firmware and software protection mechanisms in place for decades.

[0156] In an example, similar to the above-mentioned CA use case, it is possible to separate between the algorithms that are used for the trust anchor and the intermediate keys and make the stateful signatures even more rare.

[0157] In an example, depending on life cycle of software models for the electronic devices 200, the rate of signatures generated may not be very high. The generation of the signatures may be done whenever software changes need to be released, which may be done as a monthly cycle or a daily event. Further, if the signing key is used more often, it may 'wear out' its pool of available signatures faster but is also very quick to replace from backup in case of key loss.

[0158] For example, in the CA use case, the root CA, i.e., the trust anchor, has the signing keys that are less frequently used as a subCA signing keys. The signing keys do not generally need any capability to sign revocation information of individual image signatures, so their pool of available signatures may be used up. Further, the issuing CA of the signature certificate may need to sign certificate revocation lists and online validity response queries, depending on the implementation of the signature validation. Further, similar caveats are applied with the CA use case.

[0159] In an example, a software signature mechanism may depend on an additional timestamping PKI. The timestamping PKI is like a software signing PKI and it specializes on signing submitted hashes together with a timestamp, which acts as evidence that the hash was presented to the timestamping PKI at a given time. Further, the purpose of the timestamping is to sign software with a short-lived signature certificate which is renewed e.g., once a year. Further, the validator, instead of checking whether the signing certificate is still valid at the time of signature validation, checks whether the signing certificate was still valid at the time of signature creation, and that the extended and specialized timestamp PKI is still valid at the time of signature validation. In an example, for commercial software signing, a certificate authority that grants signature certificates may also run a timestamping service. The timestamping service allows the certificate authority to delegate the capability to generate software signatures for a platform which acts on behalf of its customers for a brief period, such as one year, at a time. The platform may include but is not limited to Microsoft® Windows®. Further, timestamping certificates are issued to a smaller number of actors, and they cannot generate a trusted signature by themselves. Instead, the small number of actors may generate only a statement indicating what time it was when a given hash digest is provided and then the hash digest is used in a trusted software signature. In an example, the actors may be an individual or group of individuals. In an example, a cryptographic hash function takes an arbitrary block of data and calculates a fixed-size bit string called a hash digest.

[0160] In an example, timestamping requests are generally not authenticated and all of them may be expected to be unique and require a signature. In such a case, a S-HBS based time stamper may have to be careful to ensure that it cannot be targeted by a denial-of-service attack that exhausts either the number of signatures available for its signing key, or the number of signatures available in a time quanta length.

[0161] In an example, the timestamping PKIs are long-lived. In such a case, it may be difficult to revoke a timestamping signature or issuing certificate at a later stage, instead the entire timestamping PKI may be required to be replaced. Therefore, using the available stateless PKI for issuing the actual timestamp signatures does not seem to be a safe option similarly to how it appears reasonable for the general CA use case. Further, the most viable choice for a timestamping PKI aiming for quantum resistance with a stateful PKI scheme might involve authenticating timestamp requests.

[0162] For example, in completely private PKIs, where the validity of the signature may be tied to certificate validity instead of an indirect timestamp validity, the issues related to the timestamping PKI may be avoided by opting not to implement one.

[0163] In an example, consider a special case of software signing, which is a low-level firmware signing where the platform validating the signature is not assumed to have access to reliable time when it validates the signature. In such cases, certificates do not expire over time, but can only be revoked. This eliminates the need to sign regular revocation information updates, OCSP responses and timestamps. However, it allows to sign a piece of revocation information in case a signing key is compromised. This may be considered a reasonably rare occurrence, compared to timestamps, OCSP responses, and regular revocation information updates which happen at the rate of response time desirable for a revocation event.

[0164] In an example, when the validating platform, and relying party, in firmware signing do not have any sense of time, the system that is signing the files needs to take care of time quanta length of the S-HBS keys. Further, the system is typically located in a data center and may be expected to have access to a reliable clock, for the sake of producing accurate timings for its signature audit logs.

[0165] In an example, the proposed electronic device 200 and method 300 may monitor signing times from signatures and monitor the clock known to the electronic device 200 to detect clock drift.

[0166] In an example, the proposed electronic device 200 and method 300 may wait at least At' time until starting the recovery procedure of the signing keys, if the At' = - 1 difference is bounded.

[0167] In an example, the proposed electronic device 200 may have an internal, high accuracy realtime clock for protecting the key sequence, limiting changes to time and clock rate, and requiring manual verification for any large changes. For example, regarding the use of the stateful key protection in hardware security module, HSM, vendors, the National Institute of Standards and Technology, NIST's current recommendation prohibits the key backup for the stateful hash-based algorithms to ensure security. However, in order to embody time quanta as an accepted standard mechanism in the HSMs, NIST would have to amend their current recommendations, as there is a requirement for the HSM vendors to allow this stateful key protection mechanism to meet specific customer requirements for long-term key availability. Further, if the NIST amends its recommendation to provide the stateful key protection for the HSM vendors, it may impact Federal Information Processing Standard, FIPS certification. Further, implementing the time quanta length of the proposed electronic device 200 and the method 300 would require customers to run their HSM in non-certified mode, to use stateful hash-based keys. In an example, the HSM may be a physical device that provides extra security for sensitive data. In another example, if a HSM user needs to run their HSM in non-FIPS compliant mode in order to be able to fulfil ultimate security requirements such as ensuring the availability of signing keys over a long period of time, then this additional feature, i.e., the time quanta length for signing data, could be implemented by the HSM vendors independently. Therefore, in view of this challenge, the proposed electronic device 200 and the method 300 are able to use the time quanta length in order to provide the stateful key protection to the HSM vendors.

[0168] In an example, exporting and importing the stateful keys from one HSM to another HSM of a different brand or version, is a challenging use case for the stateful keys. One approach to address this challenge is that the time quanta information needs to be included in a standardized manner during the export and import of the stateful keys. In an example, another approach is to define that the stateful hash-based keys cannot be exported and imported between HSMs if they are not following a compatible specification. Further, another approach is to define that the stateful hash-based keys may let go of the time-based protection during migration and may use some other protection process as part of the key import procedure. This could be particularly useful for legacy keys that need to be moved to another HSM but might not be in active use. Therefore, in view of the challenge, the proposed electronic device 200 and the method 300 are able to export and import the stateful keys between different HSM by using the time quanta length in a standardized manner.

[0169] FIG. 5 illustrates an example computing environment 500 implementing the electronic device 200 and a method 300 as shown in FIGS. 2b, and 3a-3i for obtaining signing keys for use in stateful hash-based signature, S-HBS, schemes. As depicted in FIG. 5, the computing environment 500 comprises at least one data processing module 506 that is equipped with a control module 502 and an Arithmetic Logic Unit, ALU 504, a plurality of networking devices 508 and a plurality Input output, I / O devices 510, a memory 512, a storage 514. The data processing module 506 may be responsible for implementing the electronic device 200and method described in FIGS. 2b and 3a-3i respectively. For example, the data processing module 506 in some embodiments is equivalent to the controlling circuitry of the electronic device 200described above in conjunction with FIGS. 2b and 3a-3i. The data processing module 506 is capable of executing software instructions stored in memory 512. The data processing module 506 receives commands from the control module 502 in order to perform its processing. Further, any logical and arithmetic operations involved in the execution of the instructions are computed with the help of the ALU 504.

[0170] The computer program is loadable into the data processing module 506, which may, for example, be comprised in an electronic apparatus, such as the electronic device 200. When loaded into the data processing module 506, the computer program may be stored in the memory 512 associated with or comprised in the data processing module 506. According to some embodiments, the computer program may, when loaded into and run by the data processing module 506, cause execution of method steps according to, for example, any of the methods illustrated in FIGS. 2b and 3a-3i, or otherwise described herein.

[0171] The overall computing environment 500 may be composed of multiple homogeneous and / or heterogeneous cores, multiple CPUs of different kinds, special media and other accelerators. Further, the plurality of data processing modules 506 may be located on a single chip or over multiple chips.

[0172] The algorithm comprising of instructions and codes required for the implementation are stored in either the memory 512 or the storage 514 or both. At the time of execution, the instructions may be fetched from the corresponding memory 512 and / or storage 514 and executed by the data processing module 506.

[0173] In case of any hardware implementations various networking devices 508 or external I / O devices 510 may be connected to the computing environment to support the implementation through the networking devices 508 and the I / O devices 510.

[0174] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements shown in FIG. 5 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

Claims

CLAIMS1. A method (300) performed in an electronic device (200) for obtaining signing keys for use in stateful hash-based signature, S-HBS, schemes, the method (300) comprising: creating (302) a key sequence associated to a first point in time given in a time reference of a clock known to the electronic device (200), wherein the key sequence comprises a plurality of signing keys; and assigning (304) a unique time window to each signing key, wherein the unique time window for each signing key relates to the first point in time, wherein each signing key is active for signing data item within a time frame given by the time window corresponding to that signing key.

2. The method (300) according to claim 1, wherein the plurality of signing keys in the key sequence are created in a sequence, wherein each signing key has a key index number, wherein the key index number is increased for each signing key, wherein each signing key is of use for one time signing of the data item.

3. The method (300) according to any of the preceding claims, wherein the assigning (304) comprises: computing (328) a key index number for each signing key of the plurality of signing keys for signing data item.

4. The method (300) according to any of the preceding claims, comprising: selecting (306) at least one of the signing keys from the plurality of signing keys for signing the data item at a second point in time given in the time reference of the clock, wherein the selection comprises finding the at least one signing key which corresponds to a time window comprising the second point in time.

5. The method (300) according to claim 4, wherein the at least one signing key is selected according to a key counter value used to identify whether the at least one selected signing key is an active signing key corresponding to the time window comprising the second point in time.

6. The method (300) according to claim 5, wherein the key counter value is determined from at least one of the first point in time, a time quanta length of the unique time window(s) and / or the second point in time given in the time reference of the clock.

7. The method (300) according to any of the claims 5-6, comprising: comparing (308) the key counter value with a maximum used key index value, wherein the maximum used key index value provides the index of a previously used signing key; and identifying (310) the at least selected one signing key as an active signing key when the key counter value is greater than the maximum used key index value.

8. The method (300) according to any of the claims 5-6, comprising: comparing (312) the key counter value with a maximum used key index value, wherein the maximum used key index value provides an index of a previously used signing key; identifying (314) the at least one selected signing key as an inactive signing key when the key counter value is smaller than the maximum used key index value; and disabling (316) signing of data item using said at least one selected signing key identified as inactive, wherein said at least one inactive signing key comprises a previously used signing key used for signing data item and / or an expired signing key unused within the unique time window and / or a damaged signing key.

9. The method (300) according to any of the claims 4-7, comprising: generating (318) a signature for the at least one selected signing key when the at least one selected signing key is identified as the active signing key, wherein the data item is signed via the at least one selected signing key; and updating (320) the maximum used key index value with each selection of a next signing key from the plurality of signing keys to be used for signing the data item.

10. The method (300) according to any of the preceding claims, comprising: updating (322) the maximum used key index after an expiry of the time quanta length of the unique time window assigned to the at selected at least one signing key.

11. The method (300) according to any of the preceding claims, wherein the at least one selected signing key remains unused during the unique time window, wherein the unused at least one selected signing key is the inactive key.

12. The method (300) according to any of the preceding claims, wherein the unique time window comprises a time quanta length defining a time-period for signing the data item via the at least one signing key.

13. The method (300) according to any of the preceding claims, wherein the first point in time given in the time reference of the clock is different from the second point in time given in the time reference of the clock, wherein the second point in time given in the time reference of the clock comprises a monotonic time value.

14. The method (300) according to any of the preceding claims, wherein the creating (302) comprises: creating (324) all signing keys at the first point in time given in the time reference of the clock.

15. The method (300) according to any of the preceding claims, wherein the creating (302) comprises: creating (326) the signing keys at different points in time after the creation of the key sequence at the first point in time given in the time reference of the clock.

16. The method (300) according to any of the preceding claims, wherein the key sequence comprises a stateful hash-based key.

17. An electronic device (200) for obtaining signing keys for use in stateful hash-based signature, S-HBS, schemes, the electronic device (200) comprising: a processing circuitry (1008) arranged to: create a key sequence associated to a first point in time given in a time reference of a clock known to the electronic device (200), wherein the key sequence comprises a plurality of signing keys; andassign a unique time window to each signing key, wherein the unique time window for each signing key relates to the first point in time, wherein each signing key is active for signing data item within a time frame given by the time window corresponding to that signing key.

18. The electronic device (200) according to claim 17, wherein the plurality of signing keys in the key sequence are created in a sequence, wherein each signing key has a key index number, wherein the key index number is increased for each signing key, wherein each signing key is of use for one time signing of the data item.

19. The electronic device (200) according to any of the claims 17-18, wherein the assigning comprises: computing the key index number for each signing key of the plurality of signing keys for signing data item.

20. The electronic device (200) according to any of the claims 17-19, wherein the processing circuitry (1008) is arranged to: select at least one of the signing keys from the plurality of sub-keys for signing the data item at a second point in time given in the time reference of the clock, wherein the selection comprises finding the at least one signing key which corresponds to a time window comprising the second point in time.

21. The electronic device (200) according to any of the claims 17-20, wherein the at least one signing key is selected according to a key counter value used to identify whether the at least one selected signing key is an active signing key corresponding to the time window comprising the second point in time.

22. The electronic device (200) according to claim 21, wherein the key counter value is determined from at least one of the first point in time, a time quanta length of the unique time window(s) and / or the second point in time given in the time reference of the clock.

23. The electronic device (200) according to any of the claims 21-22, wherein the processing circuitry (1008) is arranged to:compare the key counter value with a maximum used key index value, wherein the maximum used key index value provides the index of a previously used signing key; and identify the at least one selected signing key as an active signing key when the key counter value is greater than the maximum used key index value.

24. The electronic device (200) according to any of the claims 21-22, wherein the processing circuitry (1008) is arranged to: compare the key counter value with a maximum used key index value, wherein the maximum used key index value provides an index of a previously used signing key; identify the at least one selected signing key as an inactive signing key when the key counter value is smaller than the maximum used key index value; and disable signing of data item using said at least one selected signing key identified as inactive, wherein said at least one inactive signing key comprises a previously used signing key used for signing data item and / or an expired signing key unused within the unique time window and / or a damaged signing key.

25. The electronic device (200) according to any of the claims 20-23, wherein the processing circuitry (1008) is arranged to: generate a signature for the at least one selected signing key when the at least one selected signing key is identified as the active signing key, wherein the data item is signed via the at least one selected signing key; and update the maximum used key index value with each selection of a next signing key from the plurality of signing keys to be used for signing the data item.

26. The electronic device (200) according to any of the claims 17-24, wherein the processing circuitry (1008) is arranged to: update the maximum used key index value after an expiry of the time quanta length of the unique time window assigned to the at selected at least one signing key.T1. The electronic device (200) according to any of the claims 17-26, wherein the at least one selected signing key remains unused during the unique time window, wherein the unused at least one selected signing key is the inactive key.

28. The electronic device (200) according to any of the claims 17-27, wherein the unique time window comprises a time quanta length defining a time-period for signing the data item via the at least one signing key.

29. The electronic device (200) according to any of the claims 17-28, wherein the first point in time given in the time reference of the clock is different from the second point in time given in the time reference of the clock, wherein the second point in time given in the time reference of the clock comprises a monotonic time value.

30. The electronic device (200) according to any of the claims 17-29, wherein the creating comprises: creating all signing keys at the first point in time given in the time reference of the clock.

31. The electronic device (200) according to any of the claims 17-30, wherein the creating comprises: creating the signing keys at different points in time after the creation of key sequence at the first point in time given in the time reference of the clock.

32. The electronic device (200) according to any of the claims 17-32, wherein the key sequence comprises a stateful hash-based key.

33. A computer program product comprising a non-transitory computer readable medium, having thereon a computer program comprising program instructions, the computer program is loadable into a data processing unit and configured to cause execution of the method according to any of claims 1 through 16 when the computer program is run by the data processing unit.

Images