System and method for providing secure management and testing of validity of stateful hash-based keys.

Abstract

Embodiments of present disclosure provide system (200) and method (300) for providing secure management of hash-based keys. System comprises computing devices (204, 212, 214). Hash-based key (202) comprises state function component (208) and private key component (210) and are for use in cryptographic application. Key generation computing devices (204) are arranged to form hash-based key. First computing device (212) arranged for storing state function component (208). Second computing devices (214) are arranged for creating multiple copies of the private key component (210). Each copy of private key component (210) is in locked state and is used for signing data. Signatory device (216) arranged for: sending request to first computing device for obtaining state function component (208), receiving the state function component (208) for request, unlocking copy of private key component (210), signing data based on the unlocking and updating the state function component (208) to updated state function component (220).

Description

[0001] System and method for providing secure management and testing of validity of stateful hash-based keys.

[0002] TECHNICAL FIELD

[0003] The present disclosure relates generally to a field of cybersecurity. More particularly, it relates to systems and methods providing secure management and testing validity of hash-based keys.

[0004] BACKGROUND

[0005] Hash-based cryptographic schemes primarily rely on security properties of cryptographic hash functions. By relying on the cryptographic hash functions, the hash-based cryptographic schemes may reduce risk of unforeseen cyber-attack and may be valuable in light of threat posed by quantum computers to certain cryptographic algorithms. Further, the cryptographic hash functions are needed in all signature generation, independent of key creation algorithm, as input data seldom exactly matches exact data length required by a signature scheme.

[0006] The hash-based cryptography schemes cannot be used for key exchange, for which other cryptography schemes must be used for the key exchange. Further, the hash-based cryptography schemes rely on a finite set of secret key components and each secret component can only be used once for secure signing and reusing of any secret component compromises the overall security of the scheme.

[0007] Leighton-Micali Signatures, LMS and extended Merkle Signature Scheme, XMSS are two standardized hash-based signature schemes that are considered to be resistant to attacks from quantum computers. THE LMS and XMSS are included in Commercial National Security Algorithm Suite, CNSA 2.0 cryptographic suite.

[0008] SUMMARY

[0009] One of the key features of the LMS and XMSS is that they have stateful keys, which means that signing necessitates an update of the keys. Signing with stateful hash-based signature techniques necessitates keeping track of the utilized one-time keys and ensuring that they are never repeated, in other words, "state" of the key must be maintained in the stateful keys.

[0010] The concerns about the statefulness of keys in XMSS and LMS are valid and have been discussed by various cryptographic community. There are indeed practical challenges associated with management of the stateful keys. One of the primary concerns is the potential for key unavailability if a Hardware Security Module, HSM, malfunctions or goes out of vendor support. Since stateful keys are tightly coupled to the HSMs, recovery of the keys may become significantly challenging.

[0011] Further, LMS uses a 'randomizer C' component for signing which must be taken into account in order to ensure a deterministic key validity testing implementation.

[0012] Another concern is the potential for key exhaustion. The stateful keys are typically derived from a large pool of one-time keys. If the keys are exhausted prematurely, the HSM may become unusable for signing purposes which may be problematic for long-lived devices, such as firmware or hardware components, that require long term cryptographic security.

[0013] Thus, there is a need for an improved method and system for providing secure management of one or more hash-based keys created through one or more computing devices, which alleviates at least some of the above-cited problems.

[0014] It is therefore an object of the present disclosure to provide a system and a method for providing secure management of one or more hash-based keys created through one or more computing devices from a plurality of computing devices to mitigate, alleviate, or eliminate all or at least some of the above-discussed drawbacks of presently known solutions.

[0015] It is therefore another object of the present disclosure to provide a system and a method for testing validity of one or more hash-based keys to mitigate, alleviate, or eliminate a requirement of regular key liveliness checking.

[0016] This and other objects are achieved by means of a system, and a method defined in the appended claims. The term exemplary is in the present context to be understood as serving as an instance, example or illustration. According to a first aspect of the present disclosure, a system for providing secure management of one or more hash-based keys is provided. The system comprises a plurality of computing devices. The at least one hash-based key from the one or more hash-based keys comprises a state function component and a private key component. The one or more hashbased keys are for use in a cryptographic application. The system further comprises one or more key generation computing devices from the plurality of computing devices, arranged to form the at least one hash-based key. The system further comprises at least one first computing device from the plurality of computing devices, arranged for storing the state function component. A plurality of second computing devices from the plurality of computing devices are arranged for creating multiple copies of the private key component, wherein each copy of the multiple copies of the private key component is in a locked state and is used for signing data. The system further comprises at least one signatory device, arranged for: sending at least one request to the at least one first computing device, for obtaining the state function component. The state function component is for use in unlocking a copy of the private component from the multiple copies of the private key component. The at least one signatory device is further arranged for receiving the state function component for the at least one request from the at least one first computing device, unlocking the copy of the private key component through the state function component. The at least one signatory device is further arranged for signing the data through the copy of the private key component based on the unlocking and updating, after each signing of the data, the state function component to an updated state function component.

[0017] Optionally, the system comprises a separation module, arranged for separating each of: the state function component and the private key component from the hash-based key of the one or more hash-based keys.

[0018] Optionally, each copy of the private key component comprises a plurality of hash based functions.

[0019] Optionally, the at least one signatory device is arranged for selecting a new hash based function from a the plurality of hash based functions and signing each new data in response to each new request from the plurality of requests by using the new hash based function. Optionally, the state function component comprises at least one audit log data providing information about previous signing of the data through the copy of the private key component.

[0020] Optionally, the at least one audit log data comprises a numberof signatures executed through a number of copy of the private key component from the one or more copies of the private key components, an indicator associated with each copy of the private key component from the number of copies of the private key components, and a date and time stamp associated with each signature from the number of signatures.

[0021] Optionally, the at least first computing device is arranged for receiving, the plurality of requests from the plurality of signatory devices from a plurality of locations and broadcasting, to the plurality of signatory devices the state function component at the plurality of locations.

[0022] Optionally, the at least one first computing device is further arranged for storing the updated state function component and transmitting the updated state function component to unlock a new copy of the private component from the multiple copies of the private component in response to a new request from the plurality of requests.

[0023] Optionally, the at least one first computing device is arranged for generating, a asymmetric key for the state function component, wherein the state function is used by entering the asymmetric key by the at least one signatory device.

[0024] According to a second aspect of the present disclosure, a method performed through a system for providing secure management of one or more hash-based keys is provided. The method comprises creating, through the plurality of second computing devices of the plurality of computing devices, multiple copies of the private key component. Each copy of the multiple copies of the private key component is in the locked state and is used for signing the data. The method further comprises sending, by the at least one signatory device, to the at least one first computing device, the at least one request for obtaining the state function component, to unlock the copy of the private component, from the multiple copies of the private key component. The method further comprises receiving the state function component for the at least one request, by the at least one signatory device, from the at least one first computing device. The method further comprises unlocking the copy of the private key component through the at least one signatory device, by using the state function component. The method further comprises signing the data through the copy of the private key component based on the unlocking, through the at least one signatory device. The method further comprises updating the state function component to an updated state function component after each signing of the data, through the at least one signatory device. The updated state function component is transmitted through the at least one first computing device to unlock a new copy of the private component from the multiple copies of the private key component in response to the new request.

[0025] According to a third aspect of the present disclosure, there is provided a system for testing validity of one or more hash-based keys. The hash-based key from the one or more hashbased keys comprises a state function component and a private key component The one or more hash-based keys are for use in a cryptographic application and one or more key generation computing devices from the plurality of computing devices is arranged to form the at least one hash-based key. The system comprises at least one signatory device. The at least one signatory device is arranged for sending at least one request to at least one first computing device from the one or more computing devices, for obtaining a state function component. The state function component is associated with the at least one hash-based key of the one or more hash-based keys. The state function component is used for use in unlocking a dedicated copy of the private component from the multiple copies of the private key component. The at least one signatory device is further arranged for unlocking the dedicated copy of the private key component from the multiple copies of the private key component, through the state function component. The at least one signatory device is further arranged for signing a test data through the dedicated copy of the private key component based on the unlocking, for first time of one or more times. The dedicated copy of the private key component is used for signing the test data for the one or more times. The at least one signatory device is further arranged for checking a validity of the multiple copies of the private key based on successful signing of the data each time of the one or more times and updating the state function component to an updated state function component after the first time signing of the test data.

[0026] Optionally, the test data comprises a bitwise identical data to be signed each time of the one or more times. Optionally, the updated state function data comprises at least one of an indicator of the dedicated key, and bit string details of the test data.

[0027] According to a fourth aspect of the present disclosure, there is provided a method for testing validity of one or more hash-based keys through a system. The hash-based key from the one or more hash-based keys comprises a state function component and a private key component. The one or more hash-based keys are for use in a cryptographic application and one or more key generation computing devices from the plurality of computing devices is arranged to form the at least one hash-based key. The method comprises sending the at least one request to the at least one first computing device from the one or more computing devices, through the at least one signatory device, for obtaining the state function component. The state function component is associated with the at least one hash-based key of the one or more hash-based keys. The state function component is used for use in unlocking a dedicated copy of the private component from the multiple copies of the private key component. The method further comprises unlocking, through the at least one signatory device, the dedicated copy of the private key component from the multiple copies of the private key component, through the state function component. The method further comprises, through the at least one signatory device, signing the test data through the dedicated copy of the private key component based on the unlocking, for first time of one or more times. The dedicated copy of the private key component is used for signing the test data for the one or more times. The method further comprises checking a validity of the multiple copies of the private key based on successful signing of the data each time of the one or more times and updating the state function component to an updated state function component after the first time signing of the test data through the at least one signatory device.

[0028] According to a fifth 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.

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

[0030] - Enhancing usability of the hash-based keys by ensuring their longevity and accessibility. - Storing private key component of the hash-based keys to facilitate backup of the hashbased keys.

[0031] - Providing distributed key management solutions by separating a state function component and a private key component from the hash-based key and storing the private key component in multiple computing devices.

[0032] - Handling the state function component of the hash-based key in a way that allows confidentiality, integrity and availability of the private key component to be protected against both attacks and natural processes, such as wear and tear of the storage hardware security module.

[0033] - Providing secure and reliable backup mechanisms for the hash-based keys to ensure their availability in case of hardware failure.

[0034] - Providing method for testing validity of the hash-based keys, used in a cryptographic application.

[0035] 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.

[0036] BRIEF DESCRIPTION OF THE DRAWINGS

[0037] 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.

[0038] FIG. 1 discloses a wireless communication system according to some examples;

[0039] FIG. 2 is a schematic block diagram illustrating an example system for providing secure management of one or more hash-based keys, used in a cryptographic application;

[0040] FIG. 3 is a flowchart illustrating example steps for a method for providing secure management of one or more hash-based keys in a system;

[0041] FIG. 4 is a schematic block diagram illustrating an example system for testing validity of one or more hash-based keys created through one or more computing devices; FIG. 5 is a flowchart illustrating example steps for a method for testing validity of the one or more hash-based keys created through one or more computing devices in a system; and

[0042] FIG. 6 discloses an example computing environment according to some embodiments.

[0043] DETAILED DESCRIPTION

[0044] Aspects of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. The systems 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.

[0045] 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.

[0046] 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.

[0047] It will be appreciated that when the present disclosure is described in terms of a system 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.

[0048] FIG. 1 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 related to a wireless communication system / wireless network, such as the example wireless communication system 100 described in FIG. 1.

[0049] 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 are 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.

[0050] For simplicity, as depicted in FIG. 1, the wireless communication system 100 comprises a system 200, 400 a network node 104, and a network 106. The system 200, 400 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 (forexample, wireless devices and network node).

[0051] In an example, the network node 104 refer to equipment capable, configured, arranged, and / or operable to communicate directly or indirectly with the container-based computer system 200, 400 and / or with other network nodes or equipment in the wireless communication system 100 to enable and / or provide wireless access to the system 200, 400 and / or to perform other functions (for example, administration) in the wireless communication system 100. Examples of the network node 104 may 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.

[0052] The system 200, 400 refers to a device capable, configured, arranged and / or operable to communicate wirelessly with the network node 104 and / or other wireless devices.

[0053] In some examples, the system 200, 400 may include one or more of: computing devices, wireless devices, ultra-low power wireless devices, Internet of Things, loT, devices, and so on.

[0054] 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.

[0055] It should be understood that the system 200, 400 may not be limited to the above-described wireless devices. The system 200, 400 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.

[0056] In the wireless communication system 100, the network node 104 and the system 200, 400 are connected through 3GPP 5G core network where specific network services and operations are provided through software components called network functions (NFs). The wireless communication system 100 hosts large scale applications.

[0057] One of the concerns about statefulness of keys in extended Merkle Signature Scheme, XMSS and Leighton-Micali Signatures, LMS are valid and have been discussed by various cryptographic community. There are indeed practical challenges associated with management of the stateful keys such as: how to handle key backups, secure storage in Hardware Security Modules, HSMs, and testing of key liveness. One of the primary concerns is the potential for key unavailability if the HSM malfunctions or goes out of vendor support. Since stateful keys are tightly coupled to the HSMs, recovery of the keys may become significantly challenging, which may lead to sensitive assets being exposed to attacks if the keys are compromised.

[0058] Another concern is the potential for key exhaustion. The stateful keys are typically derived from a large pool of one-time keys. If the keys are exhausted prematurely, the HSM may become unusable for signing purposes which may be problematic for long-lived devices, such as firmware or hardware components, that require long term cryptographic security. Even once stateless algorithms are standardized, there may be a need to deploy or at least to maintain stateful hash-based schemes in a secure manner.

[0059] Using a hash-based key as a "break-glass" backup trust anchor for long-term security is a promising use case that leverages strengths of hash-based cryptography to achieve long-term security in scenarios where quantum-resistance and resilience against algorithmic failure are paramount.

[0060] In an example, cars or ships manufactured today may have been designed years ago and may stay in use for well over a decade. Particularly, in secure boot type use cases and other hardware based asymmetric roots of trust, hashes of trusted public keys, for example, updating software on an equipment, are physically fused into hardware, and new keys may not be added in the field. Hence, the choice of algorithm for such a trust anchor must be made and remains fixed years before the key is in fact ever expected to be used. In a situation with new, unproven algorithms in which new algorithms are in the initial process of being standardized and weaknesses are still being discovered in many of them, this kind of use case demands a reasonably conservative choice of key material.

[0061] As the standardized hash-based keys are stateful, there are problems in secure management that has not been considered in the prior arts. Current Federal Information Processing Standard, FIPS certification for hardware security modules has solved the problem of stateful key backup by forbidding it altogether, however it is not a viable solution for long-lived trust anchors.

[0062] Additional problems may include capability to ensure safe storage of the key in a Hardware Security Module, HSM and interfacing of it from certificate management or software signing tools, where one of the standard functions necessary for testing key liveness is typically the capability to sign something with it.

[0063] The existing solution to address backup of the hash-based key, in Java cryptographic library BouncyCastle, a functionality is provided to 'shard' the hash-based key into multiple sub-keys. This allows multiple copies of the key to exist simultaneously, and as long as the division is done carefully and each copy only uses up hashes from its assigned 'shard', there is no risk of colliding signatures compromising the key. The existing solution resembles that of assigning subordinate Certification Authorities, CA to different disconnected sites to ensure that certificate serial numbers will not collide, and keeping a common root. However, from a backup point of view, the existing solution requires care, for example, the shards may be created at time of creation of the hash-based key, so when the hash-based keys are stored on a HSM, they cannot leave that individual HSM, and if shards would be 'left over' or saved for later, they must still be stored on some kind of device, and may never leave the device. In essence, it may possible to build an indefinite hierarchy of backups where each copy is granted access to half of the remaining shard of the original copy. Thus, the existing solution essentially restricts how often backups can be made or refreshed to new hardware in order to not exhaust the key components.

[0064] Thus, the present disclosure enables the wireless communication network 100, the network node 104, the system 200 to provide secure management of one or more hash-based keys and the system 400 and for testing validity of the one or more hash-based keys while allowing confidentiality, integrity and availability of a private key component of the hash-based key to be protected against both attacks and natural processes, such as wear and tear of the HSM.

[0065] FIG. 2 is a schematic block diagram illustrating an example system 200 for providing secure management of one or more hash-based keys 202. At least one hash-based key 202 from the one or more hash-based keys 202 comprises a state function component 208 and a private component 210. The one or more hash-based keys 202 are for use in a cryptographic application. The at least one hash-based key 202 is created through one or more key generation computing devices 204 from a plurality of computing devices 204, 212, 214.

[0066] The at least one first computing device 212 from the plurality of computing devices 204, 212, 214 is arranged for storing the state function component 208. A plurality of second computing devices 214 of the plurality of computing devices 204, 212, 214 are arranged for creating multiple copies of the private key component 210. Each copy of the multiple copies of the private key component 210 is in a locked state and may be used for signing data 118.

[0067] The system 200 further comprises the at least one signatory device 216. The at least one signatory device 216 is arranged for sending at least one request to the at least one first computing device 212 for obtaining the state function component 208. The state function component 208 is used for unlocking a copy of the private key component 210 from the multiple copies of the private key component 210. The at least one signatory device 216 is further arranged for receiving the state function component 208 for the at least one request from the at least one first computing device 112. After receiving the state function component 208, the at least one signatory device 216 unlocks the copy of the private key component 210 through the state function component 208. The at least one signatory device 216 then sign the data 218 through the copy of the private key component 210 based on the unlocking and updates the state function component 208 to an updated state function component 220 after each signing of the data 218. Optionally, the system 200 comprises a separation module 206. The separation module 206 is arranged for separating each of the state function component 208 and the private key component 210 from the hash-based key 202 of the one or more hash-based keys 202.

[0068] Optionally, each copy of the private key component 210 comprises a plurality of hash based functions.

[0069] Optionally, the at least one signatory device 216 is arranged for selecting a new hash based function from a the plurality of hash based functions and signing each new data in response to each new request from the plurality of requests by using the new hash based function.

[0070] Optionally, the state function component 208 comprises at least one audit log data providing information about previous signing of the data through the copy of the private key component 210.

[0071] Optionally, the at least one audit log data comprises a numberof signatures executed through a number of copy of the private key component 210 from the one or more copies of the private key components 210, an indicator associated with each copy of the private key component 210 from the number of copies of the private key components 210, and a date and time stamp associated with each signature from the number of signatures.

[0072] In an example, the indicator may comprise a running number identifying different private key components 210, or in the case of schemes where usage of the hash-based key 202 is not randomized, the indicator may comprise a data string (also may refer hash) which would use that particular private key component 210 for signing, or equivalent information about which segment of a hash tree the private key component 210 is chosen from.

[0073] Optionally, the at least first computing device 212 is arranged for receiving, the plurality of requests from the plurality of signatory devices 216 from a plurality of locations and broadcasting, to the plurality of signatory devices 216, the state function component 208 at the plurality of locations.

[0074] Optionally, the at least one first computing device 212 is further arranged for storing the updated state function component 220 and transmitting the updated state function component 220 to unlock a new copy of the private key component 210 from the multiple copies of the private key component 210 in response to a new request from the plurality of requests.

[0075] Optionally, the at least one first computing device212 is arranged for generating, an asymmetric key for the state function component 208, wherein the state function component 208 is used by entering the asymmetric key by the at least one signatory device 216.

[0076] In an example, the plurality of computing devices 204, 212, 214 is selected from a group comprising at least one of: 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.

[0077] In an example, the first signatory device 216 is selected from a group comprising at least one of: Hardware Security Module, HSM, cloud-based HSM, a physically controlled HSM, such as a USB HSM or a network HSM appliance or other physical security device. In an example, the system 200 for providing secure backup strategy for the hash-based keys is now discussed. The hash-based key 202 is in use for signing software or firmware or for validating a signed software package or key. The at least one signatory device 216, herein referred as the HSM plays a critical role in security infrastructure, especially for storing and managing the hash-based keys 202. However, a long-lived 'backup' trust anchor may be able to outlive an average HSM, which has a lifespan of approximately 5 years as generic computers would.. The HSM may suffer for example backup battery or disk failure, and it may also be possible to lose an individual HSM device to another disastrous failure, including a site fire, due to which the limitation of storing the hash-based key 202 in a single device, for example, the HSM device, for its entire lifespan is unviable. The primary reason why backup may be dangerous for hash-based keys is that the state of the different copies of the hashbased keys 202 may go out of sync and may potentially compromise security. Considering an example scenario where hash-based key A 202 may go through the following life cycle pattern:

[0078] 1. A Hash-based Key A 202 is created

[0079] 2. The Hash-based key A 202 is backed up

[0080] 3. The Hash-based key A 202 uses up a private key component A-l (signs data with one state function component 208, also may be referred as hash)

[0081] 4. The Hash-based Key A 202 is restored from the backup HSM in step 2

[0082] After this, the restored backup of the hash-based key 202 would still consider the private key component A-l as unused, and the risk of using the private key component A-l to sign a different data and compromising the entire hask-based key would be high.

[0083] Thus, the proposed system 200 leads to an enhancement of usability of the hash-based key 202 by ensuring their longevity and accessibility to address the above problem of backup of the hash-based keys 202 and secure restoration of the hash-based keys 202. The private key component 210 of the hash-based key 202 is confidentiality protected. The state function component 208 may be public but must be integrity protected, and it is possible to protect the state function component 208 and the private key component 210 separately. Thus, the system 200 provides protection by making the presumed rare action of signing more demanding and allowing backup of the hash-based keys 202 to take place routinely.

[0084] In an example, it may not always possible to fully control for in a technical system such as a network of Hardware Security Modules and their often offline backups, however, it may be possible to control at the level of the organization owning the hash-based key 202, by essentially requiring that usage of the hash-based key 202 requires a kind of process semaphore that may only be granted to one team at a time and may only be released once the state function component is 208 is updated to the updated state function component 220 and been propagated to all the one or more computing devices where the hash-based key 202 may be used.

[0085] The at least one audit log data of the hash-based key 202 is integrity protected but may be public, i.e. it at least one audit log data may be safely shared, stored and distributed outside the first signatory device 216 without compromising the key.

[0086] In an example scenario of three physical locations having a copy of the private component 210, for example, referred as a private key component A, if no data is signed with the private key component A 210, any copy may be used. Once some data is signed with the private key component A 210 , all copies that should be able to sign with the private key component A may need an up-to-date copy of the audit log, may be referred as updated state function component 220 before signing with the private key component A 210, to ensure that the private key component will not reuse an already used private key component, also referred as hash.

[0087] Backups of the private key component A 210 may be created as often as needed, but the organization that owns the hash-based key 202 may decide when and where a signing ceremony to be performed. Not all backups necessarily have to have this capability and some of the copies of the private key component 210 may reside on passive devices that are only used to restore the hash-based key 202 to a new blank signatory device to take it into use. Once the private key component A 210 is used to sign some data, the organization must have the latest copy of the audit log L.

[0088] Once a first signature is made, the private key component key A 210 and backups of the private key component A 210 may still remain identical and may not need synchronization, but the audit log L must be updated to a new state L', to indicate that a one-time usable component of the hash-based key A 202, let us denote it with A-l, has been used and shall therefore not be used again.

[0089] This audit log must now be propagated to the plurality of second computing devices, at similar or different locations where the hash-based key A 202 might need to be used. It may also be backed up as many times as necessary and may be transmitted over the internet as long as it is integrity protected. If the audit log is modified, or its delivery is interrupted, a site could try to sign with the hash-based key 202 in a way that would re-use the key component A-l and essentially compromise the hash-based key 202.

[0090] Optionally, in addition to the hash-based functions, a list of identifiers (not shown in Figures) for each private key component 210 are stored with the hash-based key 202. The list of identifiers uniquely identifies the private key component 210 without revealing content of the private key component 210.

[0091] FIG. 3 is an exemplary flowchart illustrating example steps for a method 300 implemented in the system 200 providing secure management of the one or more hash-based keys 202. The at least one hash-based key 202 from the one or more hash-based keys 202 comprises the state function component 208 and the private component 210. The least one hash-based key 202 is created through one or more key generation computing devices 204 from a plurality of computing devices 204, 212, 214.

[0092] The order in which the method 300 is described is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement the method 300 or alternate methods. Additionally, individual blocks may be deleted from the method 300 without departing from the spirit and scope of the embodiments described herein.

[0093] At step 302, the method 300 comprises creating multiple copies of the private key component 210 in which each copy of the multiple copies of the private key component 210 is in a locked state and is used for signing the data. The creating is performed through the plurality of second computing devices 214 of the plurality of computing devices 210, 212, 214. At step 304, the method 300 comprises sending the at least one request for obtaining the state function component 208 to unlock a copy of the private component 210 from the multiple copies of the private key component 210. The at least one request is sent by the at least one signatory device 216 to the at least one first computing device 212.

[0094] At step 306, the method 300 comprises receiving the state function component 208 for the at least one request, from the at least one first computing device 212. The state function component 208 is received by the at least one signatory device 216.

[0095] At step 308, the method 300 comprises unlocking the copy of the private key component 210 by using the state function component 208. The unlocking is performed through the at least one signatory device 216. In an example, the unlocking is performed through one signatory device 216 that unlocks and signs the data.

[0096] At step 310, the method 300 comprises signing the data through the copy of the private key component 210 based on the unlocking. The signing is performed through the at least one signatory device 216.

[0097] At step 312, the method 300 comprises updating the state function component 208 to the updated state function component 220 after each signing of the data 218. The signing is performed through the at least one signatory device 216. The updated state function component 220 is transmitted through the at least one first computing device 212 to unlock the new copy of the private key component 210 from the multiple copies of the private component in response to a new request from the plurality of requests.

[0098] FIG. 4 is a schematic block diagram illustrating an example system 400 for testing validity of one or more hash-based keys 402. At least one hash-based key 402 from the one or more hash-based keys 402 comprises a state function component 408 and a private component 410 and the least one hash-based key 402 is created through one or more key generation computing devices 404 from a plurality of computing devices 404, 412, 414.

[0099] The system 400 comprises at least one signatory device 416. The at least one signatory device 416 is arranged for sending at least one request to at least one first computing device 412 from the one or more computing devices 404, 412, 414, for obtaining a state function component 408. The state function component 408 is associated with at least one hash-based key 402 of the one or more hash-based keys 402 and the state function component 408 is used for unlocking a dedicated copy of the private key component 410 from the multiple copies of the private key component 410.

[0100] The at least one signatory device 416 is further arranged for receiving, the state function component 408 from the at least one first computing device 412, for the at least one request. After receiving the state function component 408, the at least one signatory device 416 unlocks the dedicated copy of the private key component 410 from the multiple copies of the private key component 410 through the state function component 408. The at least one signatory device 416 then signs a test data 418 through the dedicated copy of the private key component 408 based on the unlocking. The test data 418 comprises bitwise identical 'standard' test data that is signed with a given private key component 410 repeatedly. In an example, the state function component 408 may comprise an audit log data that specifies what the test data 418 is supposed to be and send the test data 418 always to the same private key component 410 for signing the test data 418 identically every time. The dedicated copy of the private key component 408 is used for signing the test data 418 for the one or more times. After signing the test data 218, the at least one signatory device 416 then check a validity of the multiple copies of the private key component 408 based on successful signing of the test data 418 each time of the one or more times. The at least one signatory device 416 further arranged for updating, the state function component to an updated state function component 408 after the first time signing of the test data 418.

[0101] Optionally, the test data 418 comprises a bitwise identical data to be signed each time of the one or more times.

[0102] Optionally, the updated state function data 420 comprises at least one of an indicator of a dedicated hash-based key from the one or more hash-based keys 402, and bit string details of the test data 418.

[0103] In an example, the indicator may comprise a running number identifying different private key components 410, or in the case of schemes where usage of the hash-based key 402 is not randomized, the indicator may comprise a data string (also may refer hash) which would use that particular private key component 410 for signing, or equivalent information about which segment of a hash tree the private key component 410 is chosen from.

[0104] Optionally, the system 400 comprises a separation module 406. The separation module 406 is arranged for separating each of the state function component 408 and the private key component 410 from the hash-based key 402 of the one or more hash-based keys 402.

[0105] Considering an example scenario why testing validity of the hash-based key through the system 400, also referred as liveness check of the hash-based key is important is described now. The hardware and software stack of a HSM, its drivers and key management software generally have many interfaces that can fail in different ways. This is why the tool chains typically include functionality to test validity of the hash-based keys by e.g. signing some test data with them and discarding the result after the test data has been validated.

[0106] In case of hash-based keys 402, functionality such as periodic liveness checking must be handled in a way that does not break the security of the hash-based key but provides sufficient support for detecting that the hash-based key is still available, and its integrity is maintained.

[0107] In an example, testing validity of one or more hash-based keys 402 in which the data is signed are discussed now. In a scenario as shown below,

[0108] 1. The private key component 402, herein referred as private key component A is 'locked' by default, which means nothing can be signed with it.

[0109] 2. In order to 'unlock' the private key component A 402, in addition to the usual access control, the at least one signatory device 416 must be presented with the updated state function component 420 with latest audit log.

[0110] 3. To complete the signature, the audit log L is first updated to L' to indicate that a private key component (A-l) 410 was used to sign data whose hash-based functions, may also refer as hash was D-l, and any other information may be needed to reproduce the exact same result together with the private key component.

[0111] 4. Finally, the data D-l can be signed and signature S-l of the data D-l is returned. To generalize this into testing validity of one or more hash-based keys 402 or a key liveness check that can be repeated on data D-T and key component A-T multiple times.

[0112] In an example, for the first time the test data 418 is signed, a regular signature audit log entry may be performed, as discussed in the example above or may be done as a part of an initial key ceremony, as the test data 418 will be known to a key management software that is used to check the key liveness afterwards.

[0113] After the first signature has been done, and the first signature appears on the updated state component 420 available to the first signatory device 416, the same data may be repeatedly signed without updating the state component 408. The algorithm that may be used in such scenario is described as below:

[0114] 1. When the test data 418 is submitted for signing, it is first hashed to the appropriate length to fit a signature scheme and the hash-based functions, also referred as hash is denoted as D- T.

[0115] 2. When requested to the sign data (its hash) D-T, the first signatory device 416 may check an audit log L for whether the data has been previously signed and if so, by which private key component410 of the hash-based key 402. It may in this case discoverthat D-T was previously signed by private key component A-T, dedicated for this purpose.

[0116] 3. Given that the match exists, the first signatory device 416 may re-sign the data D-T with private key component 210 (hash) A-T and gains the same result S-T as in the previous time it was signed.

[0117] 4. The audit log remains unchanged. Any re-signature of data can be safely performed with the private key component 210 that has signed it in the past.

[0118] Due to the way hash signatures work, signing the exact same data with the same hash (key component) repeatedly will not compromise the hash-based key 402, any more than with ECC repetition of the random component is not problematic for the exact same key and message, only when the message changes.

[0119] It may not be necessary as such to mark the private key components 210 as dedicated for the testing the validity, although it may clarify the audit log for human users to make some distinction between them. It may also be noted that even if a single private key component 210 would be marked as 'test key', signing two different messages with it would be disastrous for the entire hash-based key.

[0120] In an example, if the hash-based key 402 is migrated to different management software or the first signatory device 416, the State Function component 408 must obviously be converted to a format relevant for that first signatory device 416, but any new test data 418 can be signed in a signature ceremony which may be combined with a key transfer ceremony.

[0121] In an example, it may be noted that this kind of testing validity of the one or more hash-based keys 402 may make the signature step have complexity 0(1) where I is the length of the audit log L, rather than fully constant. In other words, once the audit log grows, the re-signing process eventually slows down.

[0122] The proposed system 400 provides improvements to the current unviable situation that National Institute of Standards and Technology, NIST Federal Information Processing Standard, FIPS certification of a Hardware Security Module, HSM requires complete blocking of key backups for stateful hash-based keys and allow for limited liveness checking of the stored hash-based key 402, by signing the same test data repeatedly with the same private key component 210, 410.

[0123] Optionally, additional details of the system 400 are similar to the details of the system 200 and hence are not repeated for the sake of brevity.

[0124] Fig. 5 is an exemplary flowchart illustrating example steps for a method 500 implemented in the system 400 for testing validity of the one or more hash-based keys 402. The at least one hash-based key 402 from the one or more hash-based keys 402 comprises the state function component 408 and the private component 410 and the least one hash-based key 402 created through the one or more key generation computing devices 404 from the plurality of computing devices 404, 412, 414.

[0125] The order in which the method 500 is described is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement the method 500 or alternate methods. Additionally, individual blocks may be deleted from the method 500 without departing from the spirit and scope of the embodiments described herein. At step 502, the method 500 comprises sending the at least one request to at least one first computing device 412 from the one or more computing devices, for obtaining the state function component 408. The state function component 408 is associated with the at least one hash-based key 402 of the one or more hash-based keys 402. The state function is used for unlocking the dedicated copy of the private key component 410 from the multiple copies of the private key component 410.

[0126] At step 504, the method 500 comprises receiving the state function component 408 for the at least one request from the at least one first computing device 412. The state function component 408 is received by the at least one signatory device 416.

[0127] At step 506, the method 500 comprises unlocking the dedicated copy of the private key component 410 from the multiple copies of the private key component 410. The unlocking is performed through the at least one signatory device 416.

[0128] At step 508, the method 500 comprises signing the test data 418 through the dedicated copy of the private key component 410 based on the unlocking. The dedicated copy of the private key component 410 is used for signing the test data for the one or more times and the signing is performed through the at least one signatory device 416.

[0129] At step 510, the method 500 comprises checking the validity of the multiple copies of the private key component 410 based on successful signing of the data each time of the one or more times. The checking is performed through the at least one signatory device 416.

[0130] At step 512, the method 500 comprises updating, the state function component 408 to the updated state function component 420 after the first time signing of the test data 418. The updating is performed through the at least one signatory device 416.

[0131] Optionally, additional details of the method 500 are similar to the details of the method 300 and hence are not repeated for the sake of brevity.

[0132] FIG. 6 illustrates an example-computing environment 600 implementing a system 200 and a method 300 as shown in FIGS. 2, and 3 for providing secure management of the one or more hash-based keys 202. The example-computing environment 600 further implementing a system 400, and a method 500 as shown in FIGS. 4, and 5 for testing validity of the one or more hash-based keys 402. As depicted in FIG. 6, the computing environment 600 comprises at least one data processing module 606 that is equipped with a control module 602 and an Arithmetic Logic Unit (ALU) 604, a plurality of networking devices 608 and a plurality Input output, I / O devices 610, a memory 612, a storage 614. The data processing module 606 may be responsible for implementing the system and method described in FIGS. 2, 4 and 3, 5 respectively. For example, the data processing module 606 in some embodiments be equivalent to the controlling circuitry of the platform described above in conjunction with FIGS. 2 and 3. For another example, the data processing module 606 in some embodiments be equivalent to the controlling circuitry of the platform described above in conjunction with FIGS. 4 and 5. The data processing module 606 is capable of executing software instructions stored in memory 612. The data processing module 606 receives commands from the control module 602 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 604.

[0133] The computer program is loadable into the data processing module 606, which may, for example, be comprised in an electronic apparatus (such as the platform). When loaded into the data processing module 606, the computer program may be stored in the memory 612 associated with or comprised in the data processing module 606. According to some embodiments, the computer program may, when loaded into and run by the data processing module 606, cause execution of method steps according to, for example, any of the methods illustrated in FIGS. 2 and 3, or FIGS. 4 and 5, or otherwise described herein.

[0134] The overall computing environment 600 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 606 may be located on a single chip or over multiple chips.

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

[0136] In case of any hardware implementations various networking devices 608 or external I / O devices 610 may be connected to the computing environment to support the implementation through the networking devices 608 and the I / O devices 610. 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. 6 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

Claims

CLAIMS1. A system (200) for providing secure management of one or more hash-based keys (202), said system comprising a plurality of computing devices (204, 212, 214) wherein at least one hash-based key from the one or more hash-based keys comprises a state function component (208) and a private key component (210), wherein the one or more hash-based keys (202) are for use in a cryptographic application, wherein one or more key generation computing devices (204) from the plurality of computing devices (204, 212, 214) is arranged to form the at least one hash-based key, the system (200) comprising: at least one first computing device (212) from the plurality of computing devices (204, 212, 214) is arranged for storing the state function component (208); a plurality of second computing devices (214) from the plurality of computing devices (204, 212, 214) are arranged for: creating multiple copies of the private key component (210), wherein each copy of the multiple copies of the private key component (210) is in a locked state and is used for signing data; and at least one signatory device (216), arranged for: sending to the at least one first computing device (212), at least one request, for obtaining the state function component (208), wherein the state function component (208) is for use in unlocking a copy of the private component (210) from the multiple copies of the private key component (210); receiving from the at least one first computing device (212), the state function component (208) for the at least one request; unlocking, through the state function component (208), the copy of the private key component (210); signing the data (218) through the copy of the private key component (210) based on the unlocking; and updating, after each signing of the data (218), the state function component (208) to an updated state function component (220).

2. The system (200) according to claim 1, comprising:a separation module (206) arranged for separating each of: the state function component (208) and the private key component (210) from the hash-based key (202) of the one or more hash-based keys.

3. The system (200) according to any of the preceding claims, wherein each copy of the private key component (210) comprises a plurality of hash based functions.

4. The system (200) according to any of the preceding claims, wherein the at least one signatory device (216) is arranged for: selecting a new hash based function from a the plurality of hash based functions; and signing each new data in response to each new request from the plurality of requests by using the new hash based function.

5. The system (200) according to any of the preceding claims, wherein the state function component (208) comprises at least one audit log data providing information about previous signing of the data through the copy of the private key component (210).

6. The system (200) according to any of the preceding claims, wherein the at least one audit log data comprises a number of signatures executed through a number of copy of the private key component (210) from the one or more copies of the private key components (210), an indicator associated with each copy of the private key component (210) from the numberof copies of the private key components (210), and a date and time stamp associated with each signature from the number of signatures.

7. The system (200) according to any of the preceding claims, wherein the at least first computing device (200) is arranged for: receiving, the plurality of requests from the plurality of signatory devices (216) from a plurality of locations; and broadcasting, to the plurality of signatory devices (216) the state function component (208) at the plurality of locations.

8. The system (200) according to any of the preceding claims, wherein the at least one first computing device (212) is further arranged for: storing the updated state function component (220); and transmitting the updated state function component (220) to unlock a new copy of the private key component (210) from the multiple copies of the private key component (210) in response to a new request from the plurality of requests.

9. The system (200) according to any of the preceding claims, wherein the at least one first computing device (212) is arranged for: generating, an asymmetric key for the state function component (208), wherein the state function is used by entering the asymmetric key by the at least one signatory device(216).

10. A method (300) for providing secure management of one or more hash-based keys (202), wherein at least one hash-based key (202) from the one or more hash-based keys (202) comprises a state function component (208) and a private key component (210), wherein the one or more hash-based keys (202) are for use in a cryptographic application, wherein one or more key generation computing devices (204) from a plurality of computing devices (204, 212, 214) is arranged to form the at least one hash-based key (202), the method comprising: creating, through a plurality of second computing devices (214) of the plurality of computing devices (204, 212, 214), multiple copies of the private key component (210), wherein each copy of the multiple copies of the private key component (210), is in a locked state and is used for signing data; sending, by at least one signatory device (216), to the at least one first computing device (212), at least one request for obtaining the state function component (208), to unlock a copy of the private component (210), from the multiple copies of the private key component (210); receiving, by the at least one signatory device (216), the state function component (208), for the at least one request, from the at least one first computing device (212); unlocking, through the at least one signatory device (216), the copy of the private key component (210) by using the state function component (208); signing, through the at least one signatory device (216), the data through the copy of the private key component (210) based on the unlocking; and updating, through the at least one signatory device (216), the state function component to an updated state function component (220) after each signing of the data (218); wherein the updated state function component (220) is transmitted through the at least one first computing device (212) to unlock a new copy of the privatecomponent (210) from the multiple copies of the private key component (210) in response to a new request.

11. The method (300) according to claim 10, comprising: separating, through a separation module (206), each of: the state function component (208) and the private key component (210) from the hash-based key (202) of the one or more hash-based keys.

12. The method (300) according to any of the claims 10-11, wherein each copy of the private key component (210) comprises a plurality of hash-based functions.

13. The method (300) according to any of the claims 10-12, wherein the signing comprising: selecting, a new hash-based function from a plurality of hash-based functions; and signing, each new data in response to each new request from the plurality of requests by using the new hash-based function.

14. The method (300) according to any of the claims 10-13, wherein the state function component (208) comprises at least one audit log data providing information about previous signing of the data through the copy of the private key component (210).

15. The method (300) according to any of the claims 10-14, wherein the at least one audit log data comprises a number of signatures executed through a number of copy of the private key component from the one or more copies of the private key components, an indicator associated with each copy of the private key component from the number of copies of the private key components, and a date and time stamp associated with each signature from the number of signatures.

16. The method (300) according to any of the claims 10-15, wherein the transmitting comprising: receiving, the plurality of requests from the plurality of signatory devices (216) from a plurality of locations; and broadcasting, to a plurality of locations, the state function component when the plurality of requests are received from the plurality of locations.

17. The method (300) according to any of the claims 10-16, comprising: storing the updated state function component (220); andtransmitting the updated state function component (220) to unlock a new copy of the private key component (210) from the multiple copies of the private key component (210) in response to a new request from the plurality of requests.

18. The method (300) according to any of the claims 10-17, comprising: generating, an asymmetric key for the state function component (208), wherein the state function is used by entering the asymmetric key by the at least one signatory device (216).

19. A system (400) for testing validity of one or more hash-based keys (402) said system comprising a plurality of computing devices (404, 412, 414), wherein at least one hashbased key (402) from the one or more hash-based keys (402) comprises a state function component (408) and a private key component (410) , wherein the one or more hash-based keys (402) are for use in a cryptographic application, wherein one or more key generation computing devices (404) from the plurality of computing devices (404, 412, 414) is arranged to form the at least one hash-based key (402), the system (400) comprising: at least one signatory device (416), arranged for: sending, to at least one first computing device (412) from the one or more computing devices (404, 412, 414), at least one request, for obtaining a state function component (408), wherein the state function component (408) is associated with at least one hash-based key (402) of the one or more hashbased keys (402), wherein the state function component (408) is used for use in unlocking a dedicated copy of the private component (410) from the multiple copies of the private key component (410); receiving, from the at least one first computing device (412), the state function component (408) for the at least one request; unlocking, through the state function component (408), the dedicated copy of the private key component (410) from the multiple copies of the private key component (410); signing, for first time of one or more times, a test data (418) through the dedicated copy of the private key component (410) based on the unlocking, wherein the dedicated copy of the private key component (410) is used for signing the test data (418) for the one or more times;checking a validity of the multiple copies of the private key based on successful signing of the data each time of the one or more times; and updating, after the first time signing of the test data (418), the state function component (408) to an updated state function component (420).

20. The system (400) according to claim 19, wherein the test data (418) comprises a bitwise identical data to be signed each time of the one or more times.

21. The system (400) according to any of the claims 19-20, wherein the updated state function data comprises at least one of an indicator of the dedicated key, and bit string details of the test data (418).

22. A method (500) for testing validity of one or more hash-based keys (402), wherein at least one hash-based key (402) from the one or more hash-based keys (402) comprises a state function component (408) and a private key component (410), wherein the one or more hash-based keys (402) are for use in a cryptographic application, wherein one or more key generation computing devices (404) from a plurality of computing devices (404, 412, 414) is arranged to form the at least one hash-based key (402), the method (500) comprising: sending, through at least one signatory device (416), to at least one first computing device (412) from the one or more computing devices (404, 412, 414), at least one request, for obtaining a state function component (408), wherein the state function component (408) is associated with at least one hash-based key (402) of the one or more hash-based keys (402), wherein the state function component (408) is used for use in unlocking a dedicated copy of the private component (410) from the multiple copies of the private key component (410); receiving, through at least one signatory device (416), from the at least one first computing device (412), the state function component (408) for the at least one request; unlocking, through at least one signatory device (416), by the state function component (408), the dedicated copy of the private key component (410) from the multiple copies of the private key component (410); signing, through at least one signatory device (416), for first time of one or more times, a test data (418) through the dedicated copy of the private keycomponent (410) based on the unlocking, wherein the dedicated copy of the private key component (410) is used for signing the test data (418) for the one or more times; checking, through at least one signatory device (416), a validity of the multiple copies of the private key based on successful signing of the data each time of the one or more times; and updating, through at least one signatory device (416), after the first time signing of the test data (418), the state function component (408) to an updated state function component (420).

23. The method (500) according to claim 22, wherein the test data (418) comprises a bitwise identical data to be signed each time of the one or more times.

24. The method (500) according to any of the claims 22-23, wherein the updated state function data comprises at least one of an indicator of the dedicated key, and bit string details of the test data (418).

25. 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 10 through 18 and 22 through 24 when the computer program is run by the data processing unit.

Images