Transfer payload information including key information

Abstract

In particular, a method, - The process of obtaining key information from secure electronic memory, where the key information represents one or more keys. - Determining an encryption key based at least partially on multiple session parameters and a master key, wherein the multiple session parameters include a session identifier, a sender identifier, and a receiver identifier. - Encrypting key information based at least partially on the determined encryption key, - To provide payload information, wherein the payload information includes at least encrypted key information and a sender identifier. A method including the following is disclosed.

Description

[Technical Field]

[0001] Various embodiments of the present disclosure relate to transferring key information representing an electronic key (e.g., a one-time signature (OTS) key) between a source device and a destination device (e.g., between two hardware security modules (HSMs)). Specifically, various embodiments of the present disclosure relate to determining a key for encrypting and authenticating key information based on a plurality of session parameters, in order to generate payload information including encrypted key information. It should be understood that the various exemplary embodiments presented below are provided by way of example only and should not be construed as limiting the scope of the present disclosure. [Background Art]

[0002] OTS keys are primarily used in situations where integrity and non-repudiation are important, such as for secure communication protocols (e.g., secure email or instant messaging), authentication and authorization purposes (e.g., electronic voting systems), or digital timestamps (e.g., for signing timestamps with an OTS key to prevent the possibility of tampering or retroactive modification). For example, after an OTS key has been used to sign a message, the key should not be reused, since reusing the key may compromise security. Therefore, careful key management and secure key generation mechanisms are important for effective deployment of OTS. In the management and transfer of OTS keys, repeated use of the keys must be prevented for security reasons, while at the same time, high availability of the keys should be ensured without restricting the import or export of keys. [Summary of the Invention]

[0003] Various exemplary embodiments according to the present disclosure may have the effect of transferring key information representing one or more keys between a source device and a destination device in a manner that guarantees the confidentiality, authenticity and freshness (i.e., one-time use) of the one or more keys.

[0004] According to a first aspect of this disclosure, a method, - The process of obtaining key information from secure electronic memory, where the key information represents one or more keys. - Determining an encryption key based at least partially on multiple session parameters and a master key, wherein the multiple session parameters include a session identifier, a sender identifier, and a receiver identifier. - Encrypting key information based at least partially on the determined encryption key, - To provide payload information, wherein the payload information includes at least encrypted key information and a sender identifier. A method including the above is disclosed.

[0005] According to a second aspect of this disclosure, a method, - To obtain payload information, which includes a sender identifier and encrypted key information, and the key information represents one or more keys. - Determining a decryption key based at least partially on a master key and multiple session parameters, wherein the multiple session parameters include a sender identifier, a receiver identifier, and a session identifier. - Decrypting key information based at least partially on the determined decryption key, - Storing key information in secure electronic memory, A method including the above is disclosed.

[0006] According to a third aspect of this disclosure, a method, - Receiving payload information from a source device, wherein the payload information includes at least encrypted key information representing one or more keys, and a sender identifier identifying the source device, the encrypted key information being encrypted at least in part based on an encryption key, the encryption key being determined at least in part based on a plurality of session parameters, the plurality of session parameters including a sender identifier, a receiver identifier identifying the destination device, and a session identifier identifying the transfer session between the source device and the destination device. - Providing payload information to the destination device, A method including the above is disclosed.

[0007] Furthermore, according to the first, second, and third embodiments, each apparatus is disclosed, which is configured to perform and / or control the respective methods according to the first, second, or third embodiment, or comprises means (e.g., computer means) for performing and / or controlling the respective methods according to the first, second, or third embodiment. Such means of the apparatus can be implemented, for example, in hardware and / or software. They may include, for example, at least one processor for executing computer program code to perform the required functions, at least one memory for storing the program code, or both. Alternatively or additionally, they may comprise circuits designed to implement the required functions, such as being implemented on a chipset or chip, such as an integrated circuit. Generally, the means may comprise, for example, one or more processing means or processors.

[0008] Furthermore, according to the first, second, and third embodiments, each device is disclosed comprising at least one processor and at least one memory containing computer program code, wherein the at least one memory and the computer program code are configured to cause the device to at least execute and / or control the respective methods according to the first, second, or third embodiment using at least one processor.

[0009] The apparatus according to the first or second embodiment may be, for example, each hardware security module (HSM) or each unit of the HSM (e.g., control unit). The HSM may be understood as, for example, a device that protects and manages and / or generates electronic keys and performs encryption and decryption, authentication and other cryptographic functions. For example, the HSM may include tamper-resistant and tamper-evident hardware components such as secure chips and sensors to prevent unauthorized access, hacking or physical attacks. In particular, the HSM may include, for example, a secure cryptographic processor configured to provide cryptographic functions and secure key management. The HSM may further include, for example, secure electronic memory for storing cryptographic keys and other sensitive data. Such electronic memory may be protected by physical security means and may include tamper-resistant features to prevent unauthorized access. To give some non-limiting examples, these physical security means may be tamper-proof seals, intrusion detection sensors or self-destruct mechanisms to prevent physical attacks and tampering. The HSM may further include, for example, one or more secure communication interfaces that can enable secure data transfer. To give some non-exclusive examples, these secure communication interfaces may be USB®, Ethernet®, or similar communication interfaces that support secure transmission protocols. The HSM can be operated by specific management software that enables configuration, monitoring of usage, and management of keys or security policies.

[0010] The device according to the third embodiment may be, for example, a network device (e.g., a network server) that can be configured to manage network resources (e.g., network traffic) within a network (e.g., a local area network, a wide area network, or a cellular network). In this case, the network (e.g., a computer network) may be understood as a group of interconnected devices (e.g., computers, servers, printers, and other hardware) that can be connected via communication channels (e.g., wires, optical fibers, or wireless connections) to facilitate communication and resource sharing. For example, the network device according to the third embodiment may be part of a network that includes one or more devices (e.g., one or more HSMs) according to the first or second embodiment.

[0011] Furthermore, according to the first, second, and third embodiments, a computer program is disclosed which, when executed by the processor of the apparatus, causes the apparatus to perform the respective method according to the first, second, or third embodiment.

[0012] Computer programs can be stored on computer-readable storage media, particularly tangible and / or non-temporary media. Computer-readable storage media may include, for example, disks or memory. Computer programs can be stored on computer-readable storage media in the form of instructions that encode the computer-readable storage media. Computer-readable storage media may be intended to be involved in the operation of internal or external memory, such as computer read-only memory (ROM) or hard disks, or they may be intended for program distribution, such as optical discs.

[0013] According to a fourth aspect of this disclosure, a system, - Apparatus according to the first embodiment, - Apparatus according to a second embodiment, A system comprising the above is disclosed.

[0014] For example, the system may comprise at least one source device (e.g., an HSM) according to a first embodiment and at least one destination device (e.g., an HSM) according to a second embodiment. Furthermore, the system may comprise at least one further destination device (e.g., in another HSM). Furthermore, the system may comprise an application which can be understood as a device according to a third embodiment, which may be a network server as part of a network (e.g., a local area network, a wide area network, or a cellular network) which can be used for key transfer, comprising at least one source device and at least one destination device. In another example, the application may be understood as a portable data storage device (e.g., a USB flash drive) on which payload information is temporarily stored and transferred from at least one source device to at least one destination device.

[0015] For example, one or more keys may be understood as an electronic key, digital key, or cryptographic key, which may be a single piece of digital information used cryptographically to protect electronic information. For example, one or more keys may be given by a secret parameter or value known and used by an authorized party to securely perform an encryption operation. In particular, a key may be a binary sequence or string, which may be represented in various formats including hexadecimal, binary, or alphanumeric characters. To give some non-limiting examples, one or more keys may be an encryption key or decryption key (e.g., used in symmetric or asymmetric encryption algorithms), a digital signature key (e.g., a private key for generating a digital signature and a public key for verifying the authenticity of the signature), or an authentication key (e.g., used in an encryption algorithm such as HMAC (Hash-Based Message Authentication Code) to ensure secure authentication and prevent unauthorized access).

[0016] In another example, one or more keys may be OTS keys, which may be understood as a type of cryptographic key used for digital signatures. Unlike traditional digital signature schemes that use a single key pair for multiple signatures, for example, an OTS key is used only once for a single signature. For example, once an OTS key has been used, it becomes unusable and cannot be reused for other signatures. The state information of an OTS key may indicate, for example, the state of the OTS key, which is whether or not the OTS key has already been used.

[0017] Key information representing one or more keys can be understood, for example, as one or more actual keys. For example, assuming that a key can be a binary sequence or string, the key information representing a key may be the binary sequence or string that is the key represented by the key information.

[0018] In another example, key information for one or more keys may be understood not as one or more actual keys, but as information that indicates one or more keys. In such cases, the key information representing a key may be underlying information (e.g., an indicator, index, value, or identifier) ​​that makes it possible to retrieve (e.g., search, determine, or uniquely identify) the actual key represented by the key information. For example, the key information for a key may be able to uniquely identify or locate a key within multiple keys (e.g., within a key structure such as a key tree structure, or within a key database or storage system) by a numerical or textual value.

[0019] For example, considering key transfer between a source device and a destination device, the actual key may be transferred as part of the payload information. In another example, key information identifying the key, rather than the actual key, may be transferred as part of the payload information.

[0020] Obtaining key information from a secure electronic memory can be understood to mean, for example, that the source device retrieves the key information from the secure electronic memory of the source device (for purposes such as transferring the key information to a destination device). Alternatively or additionally, obtaining key information may include determining the key information based at least in part on further information retrieved from the secure electronic memory. Furthermore, storing key information in a secure electronic memory can be understood to mean that the destination device is capable of storing the key information in the secure electronic memory of the destination device (e.g., after receiving the key information from the source device). For example, the destination may store one or more keys represented by the key information, which may include determining the one or more keys based on the key information.

[0021] For example, obtaining key information representing one or more keys may be performed after receiving a request indicating that the one or more keys are to be transferred to the destination device. This may include, for example, verifying the received request to determine whether the requested one or more keys are available and unused in the source device.

[0022] The plurality of session parameters may include, for example, a sender identifier, a recipient identifier, and a session identifier. For example, considering that payload information is transferred from a source device to a destination device, the sender identifier identifies the source device, the recipient identifier identifies the destination device, and the session identifier identifies a transfer session between the source device and the destination device for transferring the payload information.

[0023] The master key can be used for both the method according to the first aspect and the method according to the second aspect, and thus may be available, for example, in both the device according to the first aspect (e.g., the source device) and the device according to the second aspect (e.g., the destination device). For example, the master key is stored in both the source device and the destination device (e.g., in the respective secure electronic memories of these devices).

[0024] The master key may be understood as, for example, an electronic key, a digital key, or a cryptographic key used in symmetric encryption algorithms. In particular, the master key may be a binary string or a character string that may be represented in various formats including hexadecimal, binary, or alphanumeric. For example, considering key transfer between a source device and a destination device, the master key is available at both the source device and the destination device. For example, the master key may be stored in secure electronic memory of the source device and secure electronic memory of the destination device. In this case, the master key can be understood as a shared symmetric key: at the source device, the master key is used to determine an encryption key for encrypting key information, and at the destination device, the master key is used to determine a decryption key for decrypting the encrypted key information.

[0025] Determining an encryption key and a decryption key based at least in part on a plurality of session parameters and the master key may be understood to mean that, for example, the encryption key and the decryption key are determined (e.g., derived or generated) according to a respective cryptographic function (e.g., a key derivation function) that uses at least the plurality of session parameters and the master key as inputs. This may include, for example, converting the plurality of session parameters and the master key into the encryption key or the decryption key according to a cryptographic function, and the cryptographic function may use various cryptographic protocols having specific properties such as, for example, randomness or uniqueness of the resulting key.

[0026] For example, considering key transfer between a source device and a destination device, the encryption key may be determined by the source device to encrypt the key information, and the decryption key may be determined by the destination device to decrypt the encrypted key information. In such an example, the source and destination devices can use their respective cryptographic functions to determine the encryption and decryption keys, respectively. For example, the determined encryption and decryption keys may be equal to or different from each other. Advantageously, the source and destination devices can independently determine the encryption and decryption keys, respectively, based on a master key already shared between the source and destination devices. Furthermore, by relying on multiple session parameters, the encryption and decryption keys are determined individually for each specific key transfer session and specific division of roles between the source and destination devices.

[0027] When multiple session parameters are used as input to determine encryption and decryption keys, it will be understood that the order of the session parameters can affect the determined encryption and decryption keys. Therefore, the role of the device as sender or receiver may be considered when determining the encryption and decryption keys. For example, considering key transfer between a source device and a destination device, the session parameters may be given by the sender identifier of the source device, the receiver identifier of the destination device, and the session identifier. If the roles of sender and receiver of the source and destination devices are reversed, the multiple session parameters will be the same, but the determined encryption and decryption keys will be different because the order of the sender identifier and receiver identifier is changed.

[0028] Encrypting key information based at least partially on a determined encryption key and decrypting key information based at least partially on a determined decryption key can be understood as meaning, for example, that key information is transferred from its original form to an encoded form and vice versa. For example, encryption may be the process of converting key information plaintext into ciphertext using an encryption algorithm and encryption key, and decryption is the process of converting encrypted key information back from ciphertext to the original plaintext using a decryption algorithm and corresponding decryption key. For example, various symmetric key algorithms (e.g., Advanced Encryption Standard (AES), Data Encryption Standard (DES), or Rivest-Shamir-Adleman (RSA)) can be used to encrypt and decrypt key information.

[0029] After encrypting the key information, payload information is generated based on the encrypted key information and several session parameters. Specifically, the payload information includes at least the encrypted key information and a sender identifier, and may further include a receiver identifier and a session identifier. Generating payload information may also include authenticating the encrypted key information, as further illustrated in the following example.

[0030] For example, generating payload information based on encrypted key information and multiple session parameters can be understood as including collecting, formatting, encoding, compressing, and / or packaging the key information and multiple session parameters. For example, generating payload information may include formatting the encrypted key information and multiple session parameters in a standard format (e.g., a publicly available format that can be adapted by various vendors).

[0031] After generating payload information, the payload information may be provided, for example, by a source device and subsequently retrieved by a destination device. This may be understood as meaning that the payload information can be transmitted over a communication channel (e.g., a secure communication channel) between the source and destination devices. In some examples, the source and destination devices may be part of a communication network (e.g., a local area network, wide area network, or cellular network) that can be used to transmit the payload information. In other examples, the payload information may be transferred from the source device to the destination device by an application as an additional instance between the source and destination devices. In this case, the application may be understood as a network server, for example, as part of a network (e.g., a local area network, wide area network, or cellular network) that includes the source and destination devices and can be used for key transfer. In yet another example, the application may be understood as a portable data storage device (e.g., a USB flash drive) where the payload information is temporarily stored and transferred from the source device to the destination device. It will be understood that any period of time may elapse between the time the source device provides the payload information (for example, by storing the payload information in a portable data storage device) and the time the destination device retrieves the payload information (for example, by retrieving the payload information from the portable data storage device).

[0032] Further exemplary features and exemplary embodiments of different aspects of this disclosure will be described in more detail below.

[0033] According to exemplary embodiments of the first aspect of this disclosure, the provided payload information further includes a session identifier and a recipient identifier.

[0034] According to exemplary embodiments of a second aspect of this disclosure, the acquired payload information further includes a session identifier and a recipient identifier.

[0035] As described above, several session parameters, including the sender identifier, receiver identifier, and session identifier, are used to determine the encryption and decryption keys. For example, it may not be necessary to include all of these session parameters in the payload information. In cases where the sender identifier, receiver identifier, and session identifier are included in the payload by the source device when generating the payload information, the destination device can use, for example, the sender identifier, receiver identifier, and session identifier included in the payload information when determining the decryption key. This can improve the security of key transfer by allowing the destination device to verify, for example, the receiver identifier or session identifier included in the payload information before extracting the payload information. In other cases where the payload information does not include the receiver identifier and / or session identifier, the destination device can assume its own identifier available to the destination device as the receiver identifier, and further derive the session identifier from a previous session identifier available to the destination device. Such options can be advantageous because they can reduce the amount of information that needs to be transferred between the source and destination devices.

[0036] According to an exemplary embodiment of the first aspect of this disclosure, the method according to the first aspect is: - Determining authentication information based at least in part on an authentication key, key information, and multiple session parameters, wherein the provided payload information further includes the determined authentication information. It also includes.

[0037] For example, determining authentication information at least in part on an authentication key, key information, and multiple session parameters (i.e., including a recipient identifier, a sender identifier, and a session identifier) ​​can be understood as authenticating the key information and the multiple session parameters. In particular, the authentication information may be determined on key information, which may or may not be encrypted.

[0038] For example, the source device may determine a message authentication code (MAC) as authentication information based on key information, session parameters (i.e., including a recipient identifier, a sender identifier, and a session identifier), and an authentication key K_mac. The provided payload information further includes, in addition to the encrypted key information, a MAC that authenticates the key information and session parameters. For encryption and authentication of the key information, the source device may use a method that implements authenticated encryption, such as authenticated encryption with associated data (e.g., AES-GCM).

[0039] Advantageously, authenticating key information and session parameters enhances the security of key transfers, particularly by providing authenticity for the transferred key information and session parameters. Authenticity of key information, combined with the authenticity of session parameters, can guarantee the freshness of the key information and enable the detection of replay attacks.

[0040] According to an exemplary embodiment of the first aspect of this disclosure, the method according to the first aspect is: - Determining the authentication key based at least partially on multiple session parameters and the master key. It also includes.

[0041] For example, an authentication key may be determined (e.g., derived or generated) by the source device based on the sender identifier, receiver identifier, and session identifier as session parameters, and the master key stored in the source device, according to a cryptographic function (e.g., a key derivation function) that uses at least several session parameters and a master key as input. Advantageously, the source device can determine the authentication key independently of the destination device based on a master key already shared between the source and destination devices. Furthermore, by relying on multiple session parameters, the authentication key is determined individually for each specific key transfer session and specific division of roles between the source and destination devices.

[0042] According to an exemplary embodiment of the first aspect of this disclosure, the method according to the first aspect is: - Receiving request information indicating one or more keys, - Determine whether one or more keys indicated by the request information are available and unused, It also includes.

[0043] For example, a source device performing the method according to the first embodiment may receive request information from a device according to the third embodiment (e.g., an application which may be a network server), the request information indicating that the source device is requested to send one or more keys to a destination device identified by a corresponding recipient identifier. The request information may, for example, indicate one or more specific keys to be sent to the destination device, or, in another example, indicate that a certain number of keys should be sent rather than specifying specific keys.

[0044] The source device may then, for example, verify the request information, which may include determining whether one or more keys indicated by the request information are available in the source device (for example, in the source device's secure electronic memory). If available, the source device may further determine, based on the status information, whether the corresponding key is unused. If the corresponding key is not available in the source device, for example, or is available but has already been used, the method does not need to continue.

[0045] According to an exemplary embodiment of the first aspect of this disclosure, the method according to the first aspect is: - Determine the updated status of one or more keys. It also includes.

[0046] For example, after providing payload information, the source device may determine the updated status of one or more keys represented by the key information contained in the payload information. This may include updating the status information stored in the source device to indicate that one or more keys have been used.

[0047] According to an exemplary embodiment of the first aspect of this disclosure, the method according to the first aspect is: - Provide instructions for one or more keys represented by key information. It also includes.

[0048] For example, after receiving request information indicating one or more keys, and after determining that the one or more keys indicated by the request information are available and unused, the source device may provide (e.g., send) instructions for one or more keys represented by the key information contained in the payload information to the application (e.g., a network server). Advantageously, such instructions may be used by the application to collect confirmation information from at least one further destination device indicating whether or not the one or more keys have been used before.

[0049] According to an exemplary embodiment of a second aspect of this disclosure, the method according to the second aspect is: - Verify the recipient identifier included in the payload information before determining the decryption key. It also includes.

[0050] For example, after the destination device has acquired the payload information and before determining the decryption key, the destination device can verify that the transferred payload information is intended for the destination device by checking whether the recipient identifier contained in the payload information matches an identifier that can be stored in the destination device to identify the destination device.

[0051] According to an exemplary embodiment of a second aspect of this disclosure, the method according to the second aspect is: - Verify key information and multiple session parameters based at least partially on authentication information and verification keys. It also includes.

[0052] For example, verifying key information and multiple session parameters based at least partially on authentication information and verification keys can be understood as checking the authenticity of key information and multiple session parameters. In particular, key information can be verified in encrypted or decrypted form.

[0053] For example, the destination device may determine a message authentication code (MAC) based on key information, session parameters included in the payload information obtained by the destination device (i.e., including the recipient identifier, sender identifier, and session identifier), and a verification key. To verify the key information and session parameters, the MAC determined by the destination device may be compared with the MAC included in the payload information and determined by the source device before the key information was forwarded to the destination device. If the MAC determined by the destination device matches the MAC included in the payload information, the key information and session parameters included in the payload information are verified.

[0054] Advantageously, verifying key information and / or session parameters enhances the security of key transfers, particularly by providing authenticity for the transferred key information and session parameters. Authenticity of key information, combined with the authenticity of session parameters, can guarantee the freshness of the key information and enable the detection of replay attacks.

[0055] According to an exemplary embodiment of a second aspect of this disclosure, the method according to the second aspect is: - Determine the verification key based at least partially on multiple session parameters and the master key. It also includes.

[0056] For example, the verification key may be determined (e.g., derived or generated) by the destination device based on the sender identifier, receiver identifier, and session identifier as session parameters, and the master key stored in the destination device, according to a cryptographic function (e.g., a key derivation function) that uses at least several session parameters and a master key as input. Advantageously, the destination device can determine the verification key independently of the source device based on a master key already shared between the source and destination devices. Furthermore, by relying on multiple session parameters, the verification key is determined individually for each specific key transfer session and specific division of roles between the source and destination devices.

[0057] According to an exemplary embodiment of a second aspect of this disclosure, the method according to the second aspect is: - Provide status information indicating one or more keys. It also includes.

[0058] For example, the receiving device can confirm to the application that obtained the payload information that one or more keys, represented by the key information contained in the payload information, have been received by the receiving device, for example, by providing the application with corresponding status information indicating one or more keys.

[0059] According to an exemplary embodiment of a second aspect of this disclosure, the method according to the second aspect is: - Determine the state of one or more keys. It also includes.

[0060] For example, after decrypting the key information contained in the acquired payload information, and before or after storing the key information in the secure electronic memory of the destination device, the destination device can determine the state of one or more keys represented by the key information, and the destination device can determine the state information of one or more keys indicating that these one or more keys are unused and therefore available for subsequent use in the destination device.

[0061] According to an exemplary embodiment of a second aspect of this disclosure, the method according to the second aspect is: - Obtaining confirmation information indicating whether one or more keys represented by key information are unused, wherein the key information is stored in secure electronic memory if the confirmation information indicates that one or more keys are unused. It also includes.

[0062] For example, the destination device may obtain confirmation from the application (e.g., a network server) that one or more keys represented by the key information are unused. Advantageously, such confirmation may be provided by the application after the application has collected confirmation from at least one further destination device that one or more keys have never been used before.

[0063] For example, the receiving device may use (e.g., decrypt, verify, or store) one or more keys represented by the transferred key information only if the confirmation information indicates that one or more keys have not been used before. Otherwise, the receiving device may discard the transferred one or more keys.

[0064] According to exemplary embodiments of various aspects of this disclosure, payload information is transferred from a source device to a destination device. - The sender identifier identifies the source device, - The recipient identifier identifies the destination device, - The session identifier identifies the transfer session between the source and destination devices for transferring payload information.

[0065] According to exemplary embodiments of various aspects of the present disclosure, one or more keys are OTS keys and / or one or more keys represent key slices.

[0066] For example, an OTS key can be understood as a type of cryptographic key used in digital signatures, used only once for a single signature. For instance, once an OTS key has been used, it becomes unusable and cannot be reused for other signatures. OTS key status information can indicate, for example, the state of the OTS key, which is whether or not the OTS key has already been used. Advantageously, various methods provide a secure technique for transferring such OTS keys between a source and destination device while ensuring the freshness of the transferred OTS key.

[0067] For example, one or more keys may represent a key slice, so that a key slice can refer to a group or subset containing one or more keys from a group of keys. In other words, a key slice can be understood as part of or a divided portion of a larger set of cryptographic keys. For example, in some cryptographic systems or key management schemes, a set of keys may be divided or segmented into smaller groups for various purposes (e.g., distribution, access control, or scalability), and each of these smaller groups of keys may be called a key slice. For example, in a multi-layer cryptographic system, different key slices may be used at different levels of the system's architecture. Key slicing can be used, for example, in a scenario where a cryptographic system generates a master key and then divides it into multiple key slices to be distributed to different entities or individuals. The master key can only be reconstructed when all key slices are combined, ensuring that no single entity has full access to the entire key.

[0068] According to an exemplary embodiment of a third aspect of this disclosure, the method according to the third aspect is: - Obtaining instructions for one or more keys represented by key information from the source device, - Send a request to at least one further destination device asking it to indicate whether one or more keys are unused, - In response to the request, receive confirmation information from at least one further destination device indicating whether one or more keys are unused, - Providing confirmation information to the destination device, It also includes.

[0069] As described above, payload information may be transferred from the source device to the destination device by the application as an additional instance between the source and destination devices. In this case, the application may be understood (as an example of a device in the third embodiment) as a network server as part of a network (e.g., a local area network, a wide area network, or a cellular network) that includes the source and destination devices and can be used for key transfer. For example, this network may further comprise at least one further destination device.

[0070] An application may receive from a source device instructions for one or more keys represented by payload information transferred from the source device to a destination device. The application may then send a request to at least one further destination device asking it to indicate whether the one or more keys indicated by the source device are unused. The at least one further destination device may then check whether any information (e.g., status information) regarding one or more keys that could indicate, for example, that one or more OTSs have been used before or have been transferred to the at least one further destination device before (e.g., in a previous transfer session between the source device and at least one further destination device) is available to the at least one further destination device. In response to a request from the application, the at least one further destination device may then send confirmation information indicating whether the one or more keys are unused. This may be understood to mean that the confirmation information can at least indicate that one or more keys have never been used by or transferred to at least one further destination device, while it is still possible that they have been used by or transferred to another further destination device.

[0071] In another example involving multiple further destination devices, the application may request each of the further destination devices to indicate whether one or more keys are unused, and then forward the confirmations from each of the further destination devices to the destination device. The destination device, having received the payload information, may then use (e.g., verify, decrypt, and / or store) the one or more keys forwarded from the source device only if each of the confirmations indicates that one or more keys have never been used before. Otherwise, the destination device may discard the one or more keys forwarded.

[0072] Advantageously, the receiving device can then use confirmation from at least one further receiving device to ensure that one or more of the transferred keys are unused. In this way, the receiving device can detect a replay attack by checking whether the received key has been transferred to another receiving device in a previous transfer session.

[0073] Please understand that the embodiments disclosed herein are merely examples and not limiting.

[0074] In this specification, a disclosure of a method step is also considered a disclosure of means for carrying out each method step. Similarly, a disclosure of means for carrying out a method step is also considered a disclosure of the method step itself.

[0075] Other features of this disclosure will become apparent from the following detailed description, which will be considered in conjunction with the accompanying drawings. However, it should be understood that the drawings are designed for illustrative purposes only and not as a definition of the limitations of this disclosure that should refer to the accompanying claims. It should also be understood that the drawings are not drawn to scale and are intended only to conceptually illustrate the structures and procedures described herein.

[0076] Next, several exemplary embodiments will be described with reference to the accompanying drawings. [Brief explanation of the drawing]

[0077] [Figure 1] This figure shows an exemplary embodiment of the system according to a fourth aspect of the present disclosure. [Figure 2] This flowchart shows an exemplary embodiment of the method according to a first aspect of the present disclosure. [Figure 3] This flowchart shows an exemplary embodiment of the method according to a second aspect of the present disclosure. [Figure 4] This flowchart shows an exemplary embodiment of a method according to a third aspect of the present disclosure. [Figure 5] This is a signaling chart illustrating exemplary embodiments of various aspects of the present disclosure. [Figure 6] This figure shows an exemplary embodiment of the system according to a fourth aspect of the present disclosure. [Figure 7] This is a block diagram of an exemplary embodiment of the apparatus according to a first or second aspect of the present disclosure. [Figure 8] This is a block diagram of an exemplary embodiment of the apparatus according to a third aspect of the present disclosure. [Figure 9] This is a schematic diagram of an example of a tangible, non-temporary computer-readable storage medium. [Modes for carrying out the invention]

[0078] The following description is intended to enhance the understanding of this disclosure and complements, and should be read in conjunction with, the description of exemplary embodiments of this disclosure provided in the summary section above.

[0079] Figure 1 shows an exemplary embodiment of System 100 according to a fourth aspect of the present disclosure.

[0080] Without limiting the scope of this disclosure, System 100 may comprise two devices which can be assumed below to be two Hardware Security Modules (HSMs) 110 and 120. In particular, HSM 110 (see “Src HSM” in Figure 1) may be understood as the source device, and HSM 120 (see “Dest HSM” in Figure 1) may be understood as the destination device. Furthermore, HSM 110 and HSM 120 may be understood as respective devices that protect and manage and / or generate electronic keys and perform encryption and decryption, authentication and other cryptographic functions. HSM 110 and HSM 120 may include tamper-resistant and tamper-evident hardware components, such as secure chips and sensors, to prevent unauthorized access, hacking, or physical attacks.

[0081] As an example, multiple electronic keys 1, 2, 3, 4, and 5 may be stored in the secure electronic memory of HSM110, and these electronic keys may be identified by their respective values ​​(see "Start" and "End" in Figure 1) (for example, identified within a key structure such as a key tree structure). Electronic keys 1, 2, 3, 4, and 5 may also be one-time signature (OTS) keys, and OTS keys 3 and 4 as part of a key slice 140 are transferred from HSM110 to HSM120 via a secure transfer channel 130 between HSM110 and HSM120. Both HSM110 and HSM120 may store state information 180 indicating the state of each electronic key stored in the secure electronic memory of HSM110 and HSM120 (for example, keys 3 and 4).

[0082] In the non-restrictive example in Figure 1, an OTS key can be understood as a cryptographic key used only once for a particular signature, but reusing an OTS key could lead to potential forgery (for example, by compromising the security of the signature scheme). The state information of an OTS key can therefore indicate the state of the OTS key, which is whether or not the OTS key has already been used. For example, such state information of an OTS key needs to be kept up-to-date before the use of the OTS key is requested, especially to ensure the freshness of the OTS key.

[0083] Furthermore, referring to HSM110 and HSM120, both may store a master key 150 (see "MK" in Figure 1), which can be understood as an encryption key for a symmetric encryption algorithm, and the same master key 150 can be used for encryption in HSM110 and decryption in HSM120. Moreover, it can be assumed that HSM110 as a source device is identified by a sender identifier ID_S, and HSM120 as a receiver device is identified by a receiver identifier ID_D, and ID_S and ID_D can be stored in the secure electronic memory of HSM110 and HSM120, respectively.

[0084] With regard to the transfer of OTS keys between HSM110 and HSM120, security and availability may be considered critical requirements to ensure a secure transfer mechanism for unused OTS keys between trusted HSMs. In particular, the reuse of OTS keys must be prevented with respect to security, for example, by restricting the import or export of OTS keys without affecting availability. In addition, vendor lock-in concerns may be addressed to allow migration of the secure transfer mechanism to other security solutions or to ensure compatibility with industry standards.

[0085] Furthermore, referring to the non-limiting example in Figure 1, prerequisites for securely transferring key slice 140, including keys 3 and 4, between HSM110 and HSM120 may include each HSM maintaining its local state (e.g., the state of the keys stored in each HSM), and the existence of a trustworthy relationship between HSM110 and HSM120 (e.g., through a master key MK shared by both HSMs).

[0086] Regarding the actual key slice transfer, the first step may also be to verify the freshness of the keys in the key slice 140 to be transferred by verifying that keys 3 and 4 are in an unused state. Subsequently, a secure transfer channel 130 may be established between HSM 110 and HSM 120 (for example, by an application as further described with reference to Figures 5 and 6 below). The key slice 140 may then be transferred from HSM 110 to HSM 120 (for example, in a generic format to avoid vendor lock-in scenarios), and the states of keys 3 and 4, respectively, may be updated in HSM 110 to indicate that keys 3 and 4 are in use. In response to the transfer of the key slice 140 from HSM 110 to HSM 120, HSM 110 may receive confirmation (for example, from HSM 120 or from the application providing the secure transfer channel 130) that the key slice 140 was successfully transferred or that the transfer of the key slice 140 failed. As a post-transfer condition after a successful transfer, HSM110 can disable keys 3 and 4, while HSM120 can use these keys 3 and 4. Furthermore, HSM110 may also disable keys 3 and 4 as a post-transfer condition after a failed transfer.

[0087] Figure 2 is a flowchart 200 illustrating an exemplary embodiment of a method according to a first aspect of the present disclosure. For example, the steps in flowchart 200 can be assumed to be performed and / or controlled by an apparatus according to a first aspect of the present disclosure (e.g., apparatus 700, described with reference to Figure 7 as a source apparatus).

[0088] Without limiting the scope of this disclosure, the steps of flowchart 200 are described below, taking into consideration system 100 as shown in Figure 1.

[0089] Step 210 is the step of retrieving key information from secure electronic memory, where the key information represents one or more keys.

[0090] For example, HSM110 can retrieve key information from its secure electronic memory, where the key information represents OTS keys 3 and 4 that form key slice 140. In this example, the key information representing OTS keys 3 and 4 can be understood as representing either the actual OTS keys 3 and 4, or a value that identifies OTS keys 3 and 4 (for example, within a key structure such as a key tree structure). Based on the value of such key information, the actual OTS keys 3 and 4 may be retrieved (e.g., searched or determined).

[0091] For example, after the HSM110 receives request information indicating OTS keys 3 and 4 (from an application requesting the transfer of OTS keys 3 and 4, such as an application as further described with reference to Figures 5 and 6), the key information may be obtained in step 210. In the event of such a request, the HSM110 may determine whether OTS keys 3 and 4 are available and unused (for example, in the secure electronic memory of the HSM110).

[0092] Step 220 is the step of determining an encryption key based at least in part on a set of session parameters and a master key, wherein the set of session parameters includes a session identifier, a sender identifier, and a receiver identifier.

[0093] For example, HSM110 may determine the cryptographic key K_enc based on the master key 150 stored in HSM110 and several session parameters (for example, by using a key derivation function). In this case, the several session parameters include a sender identifier ID_S that identifies HSM110 as the source device, a receiver identifier ID_D that identifies HSM120 as the destination device, and a session identifier session_ID that identifies the transfer session between HSM110 and HSM120 for transferring the key slice 140.

[0094] Step 230 is the step of encrypting the key information based at least partially on the determined cryptographic key.

[0095] For example, the HSM110 may encrypt the key information obtained in step 210 using the encryption key K_enc determined in step 220.

[0096] Step 240 is a step of providing payload information, which includes at least encrypted key information and a sender identifier.

[0097] For example, the payload information provided by HSM110 in step 240 includes key information representing OTS keys 3 and 4 contained in the key slice 140, which were encrypted in step 230, and a sender identifier ID_S. In addition, the payload information may further include a receiver identifier ID_D and a session identifier session_ID. HSM110 may provide the payload information to HSM120 via the secure transfer channel 130 by providing the payload information in step 240 to an application that requested the transfer of OTS keys 3 and 4, for example.

[0098] The HSM110 may determine the updated state of OTS keys 3 and 4 by updating the state information 180 to indicate that OTS keys 3 and 4 have been used, either before or after step 240.

[0099] As an additional option for steps 220 and 230, the HSM110 may determine authentication information based at least in part on an authentication key, key information, and multiple session parameters, and the provided payload information further includes the determined authentication information. This may include, for example, determining the authentication key based at least in part on multiple session parameters and a master key.

[0100] For example, HSM110 may determine a message authentication code (MAC) as authentication information based on the key information obtained in step 210, the session parameters ID_S, ID_D, and session_ID, and the authentication key K_mac. The payload information provided in step 240 further includes the MAC for authenticating the key information in addition to the encrypted key information. For encryption and authentication of the key information, HSM110 may use a method to implement authenticated encryption, such as authenticated encryption with associated data (e.g., AES-GCM). Furthermore, the authentication key K_mac used to authenticate the key information may be determined by HSM110 based on the session parameters ID_S, ID_D, session_ID, and the master key 150.

[0101] Figure 3 is a flowchart 300 illustrating an exemplary embodiment of a method according to a second aspect of the present disclosure. For example, the steps in flowchart 300 can be assumed to be performed and / or controlled by an apparatus according to a second aspect of the present disclosure (e.g., apparatus 700, described with reference to Figure 7 as a destination apparatus).

[0102] Without limiting the scope of this disclosure, the steps of flowchart 300 are described below, taking into consideration system 100 as shown in Figure 1.

[0103] Step 310 is the step of obtaining payload information, which includes a sender identifier and encrypted key information, where the key information represents one or more keys.

[0104] For example, HSM120 acquires payload information in step 310 after HSM110 has provided the payload information, as described with reference to step 240 in Figure 2. HSM120 can acquire payload information via a secure transmission channel 130 from applications, for example, as further described with reference to Figures 5 and 6.

[0105] The payload information obtained in step 310 may include a sender identifier ID_S that identifies HSM110 as the source device, and key information representing OTS keys 3 and 4 contained in the key slice 140, encrypted by HSM110 (see step 230 as described with reference to Figure 2). The payload information may further include a receiver identifier ID_D that identifies HSM120 as the destination device, and a session identifier session_ID that identifies the transfer session between HSM110 and HSM120 for transferring the key slice 140. If the payload information includes a receiver identifier ID_D, HSM120 may, after step 310, verify whether the receiver identifier ID_D included in the payload information matches the receiver identifier ID_D that identifies HSM120 stored in HSM120, thereby verifying that the payload information obtained in step 310 is intended for HSM120.

[0106] Step 320 is the step of determining a decryption key based at least in part on a master key and a plurality of session parameters, the plurality of session parameters including a sender identifier, a receiver identifier, and a session identifier.

[0107] For example, HSM120 may determine the decryption key K_dec (for example, by using a key derivation function) based on the master key 150 stored in HSM120 and several session parameters ID_S, ID_D, and session_ID used by HSM110 to determine the cryptographic key K_enc, as described with reference to step 220 in Figure 2.

[0108] Considering multiple session parameters, including session parameters ID_S, ID_D, and session_ID, all of these session parameters may be included in the payload information obtained in step 310. In cases where the payload information does not include ID_D or session_ID, HSM120 may determine these session parameters themselves. With respect to ID_D, HSM120 may assume that its own ID_D stored in HSM120 is ID_D, meaning that HSM120 assumes the payload information obtained in step 310 was intended for HSM120, even if the payload information lacks a corresponding session parameter ID_D that explicitly identifies HSM120 as the destination device. With respect to session_ID, HSM120 may derive session_ID by incrementally incrementing a previous session_ID stored in HSM120 that identifies a previous transfer session between HSM110 and HSM120.

[0109] Step 330 is the step of decrypting the key information based at least partially on the determined decryption key.

[0110] For example, the HSM120 may decrypt the key information obtained in step 310 using the decryption key K_dec determined in step 320.

[0111] Step 340 is the step of storing key information in secure electronic memory.

[0112] For example, the HSM120 can store the decrypted key information in step 330 in its secure electronic memory, where the key information represents OTS keys 3 and 4 contained in key slice 140. In this example, the key information representing OTS keys 3 and 4 can be understood as representing either the actual OTS keys 3 and 4, or a value that identifies OTS keys 3 and 4 (for example, within a key structure such as a key tree structure). Based on the value of such key information, the HSM120 may retrieve (e.g., look up or determine) the actual OTS keys 3 and 4.

[0113] After step 340, the HSM120 can determine the status of OTS keys 3 and 4 as indicating that these keys are unused, thereby ensuring their freshness for subsequent use in the HSM120.

[0114] As an additional option for steps 320 and 330, HSM120 may verify key information and multiple session parameters based at least partially on the verification key and the authentication information contained in the payload information obtained in step 310. This may include, for example, determining the verification key based at least partially on multiple session parameters and the master key. This additional option may be performed by HSM120, for example, when the corresponding additional option for authenticating key information for steps 220 and 230 is performed by HSM110 as described with reference to Figure 2.

[0115] For example, HSM120 may determine a message authentication code (MAC) based on key information, session parameters ID_S, ID_D, and session_ID included in the payload information obtained in step 310, and a verification key K_ver. To verify the key information and session parameters, the MAC determined by HSM120 may be compared with the MAC determined by HSM110, which is included in the payload information and as described with reference to Figure 2. If the MAC determined by HSM120 matches the MAC included in the payload information, the key information and session parameters ID_S, ID_D, and session_ID included in the payload information obtained in step 310 are verified. Furthermore, the verification key K_ver used to verify the key information and session parameters may be determined by HSM120 based on multiple session parameters ID_S, ID_D, and session_ID, as well as a master key 150 stored in HSM120.

[0116] More advantageously, as illustrated by non-limiting examples of steps 210 to 240 performed by HSM110 with reference to Figure 2, and the corresponding steps 310 to 340 performed by HSM120 with reference to Figure 3, the present disclosure provides a secure transfer of one or more keys between a secure environment of a source device and a secure environment of a destination device.

[0117] Regarding security, using symmetric encryption based on a symmetric master key shared among HSMs can enhance resilience against quantum-based attacks. In contrast to symmetric encryption, asymmetric encryption, for example, used by public-key algorithms, may exhibit a vulnerability to quantum-based attacks that can be circumvented by using a symmetric master key. Furthermore, the method of this disclosure defends against replay attacks and guarantees not only the local freshness of the key but also the freshness for key transfer, and therefore the freshness of the entire system to which the key may be distributed. Secure handling of state information across a set of trusted HSMs can be achieved in combination with secure handling of state information within the HSMs. Access to each HSM may be restricted by design to a separate subset of the OTS key, thereby ensuring that each OTS key is used at most once.

[0118] Regarding flexibility, the described transfer of key slices may be performed at the time of key generation, or at a later point in time. This may allow for the transfer of specific parts of a key to another trusted HSM. For example, it may be possible to set up a local signature instance on a new production line. It may also be possible to send back key slices that were previously transferred and subsequently not consumed, while security assurances are maintained and adaptation to the corresponding state is made automatically. Thus, an exclusive "Root HSM" is not required, but all HSMs may be considered equal from a security standpoint. Considering two HSMs as source and destination devices, these roles can be easily changed within multiple HSMs and accordingly represented by session parameters (e.g., ID_S and ID_D). Furthermore, avoiding hierarchical structures between HSMs avoids a single point of failure and enables local key and state management. This method also does not require communication between HSMs prior to key transfer, such as a process or protocol for initiating communication (e.g., a handshake). Applications for transferring protocol messages may be implemented in different ways, for example, not only by a network server, but also via classic media such as USB-Stick or CD / DVD.

[0119] Advantageously, vendor lock-in is addressed by using a clearly defined standard format for key slice transfers that is publicly available and therefore adaptable by various vendors, allowing customers to change systems and / or vendors at any time. This can make it possible to transfer keys in a mixed HSM environment with multiple HSMs from different vendors. For example, all an independent vendor needs to transfer key slices according to this method is knowledge of the corresponding protective key (e.g., the master key).

[0120] Figure 4 is a flowchart 400 illustrating an exemplary embodiment of a method according to a third aspect of the present disclosure.

[0121] Without limiting the scope of this disclosure, the operation of flowchart 400 is described below with reference to the steps shown in Figures 2 and 3, taking into account system 100 as shown in Figure 1. For example, the steps of flowchart 400 can be assumed to be executed and / or controlled by an application. Such an application may be understood as a device according to a third aspect of this disclosure (e.g., device 800), which may be a network server as part of a network that may be used for key transfer, including HSM 110 and HSM 120. In another example, the application may be understood as a portable data storage device (e.g., a USB flash drive) on which payload information can be temporarily stored and transferred from HSM 110 to HSM 120.

[0122] Step 410 is the step of receiving payload information from a source device, the payload information comprising at least encrypted key information representing one or more keys and a sender identifier identifying the source device, the encrypted key information being encrypted at least in part based on an encryption key, the encryption key being determined at least in part based on a plurality of session parameters, the plurality of session parameters comprising a sender identifier, a receiver identifier identifying a destination device and a session identifier identifying a transfer session between the source device and the destination device.

[0123] For example, the application receives payload information provided by HSM110 in step 240 from HSM110 as the source device. The payload information includes encrypted key information representing keys 3 and 4 contained in key slice 140, a sender identifier ID_S that identifies HSM110, an optional further session parameter ID_D that identifies HSM120, and a session_ID that identifies the transfer session between HSM110 and HSM120.

[0124] Step 420 is the step of providing payload information to the destination device.

[0125] For example, the application may provide the payload information received in step 410 to the HSM120, which acts as the destination device, thereby allowing the HSM120 to obtain the payload information as described in step 310.

[0126] Figure 5 is a signaling chart 500 illustrating exemplary embodiments of various aspects of the present disclosure. In a non-limiting example, the signaling chart 500 includes an HSM 510 as a source device identified by a sender identifier ID_S (see “Src HSM” in Figure 5), an HSM 520 as a destination device identified by a receiver identifier ID_D (see “Dest HSM” in Figure 5), and steps S501 to S509 which may be performed by an application 530. The master key MK may be stored in both HSM 510 and 520.

[0127] In step 501, application 530 sends a request to HSM510, which is requested to send a specific key slice ks to HSM520 identified by ID_D included in the request. The request may, for example, indicate one or more specific OTS keys to be sent in key slices to HSM520 identified by ID_D, or, in another example, indicate a specific amount of OTS keys to be sent rather than specifying specific OTS keys.

[0128] In step 502, HSM510 verifies the request received in step 501, which may include determining whether the OTS key indicated in the request is available in HSM510 (for example, in HSM510's secure electronic memory). If available, HSM510 may further determine, based on status information, whether the corresponding OTS key is unused. If the corresponding OTS key is not available in HSM510, or is available but has already been used, the method may be stopped at step 502. Otherwise, HSM510 may retrieve the OTS key from HSM510's secure electronic memory in accordance with the request. Hereinafter, it can be assumed that the actual OTS key is transferred to HSM520, but it is also possible to transfer an underlying OTS key identifier that allows HSM520 to determine the actual OTS key.

[0129] In step 503, HSM510 determines the cryptographic key K_enc and authentication key K_mac as unique session keys for the current transfer session between HSM510 and HSM520. In this regard, steps 503 and the following steps 504 refer to non-exclusive examples of using encryption and authentication for key transfer. In particular, the session keys K_enc and K_mac are derived (for example, by using a key derivation function) based on the master key MK, the session parameter ID_S, ID_D (for example, included in the request in step 501), and session_ID which identifies the current transfer session between HSM510 and HSM520. HSM510 may derive session_ID from an internal persistent session state by incrementing the previous session state by 1, or by setting session_ID to 1 if the previous session state for the transfer session between HSM510 and HSM520 is not available in HSM510. In this case, HSM510 acts as the "sender" and HSM520 acts as the "receiver," meaning that the identifier of HSM510 is used as ID_S and the identifier of HSM520 is used as ID_D. In another case where HSM510 receives a key from HSM520, the roles and corresponding identifiers ID_D and ID_S can be reversed.

[0130] In step 504, the session keys K_enc and K_mac derived in step 503 are used to encrypt and authenticate the key slice containing the OTS key indicated in the request received in step 501, thereby generating payload information (see "Payload=AuthEnc[K_enc,K_mac](key slice)" in Figure 5). For example, an authenticated encryption mode such as AES-GCM may be used to encrypt and authenticate the key slice. In a non-limiting example of step 504, not only the OTS key contained in the key slice but also the session parameters ID_S, ID_D, and session_ID are authenticated. By authenticating the key slice and session parameters, the MAC as authentication information is determined based on the encrypted key slice, session parameters, and K_mac determined in step 503, and the MAC is then included in the payload information. The payload information generated in step 504 includes the encrypted authenticated key slice, authenticated session parameters ID_S, ID_D, and session_ID, and the MAC.

[0131] In steps 505 and 506, the payload information generated in step 504 is transferred from HSM 510 to HSM 520. In the non-limiting example of Figure 5, which includes an application 530 for transferring the payload information, the payload information may be provided to the application 530 by HSM 510 in step 505 and then transmitted from the application 530 to HSM 520 in step 506.

[0132] Application 530 may be understood as a device according to a third aspect of the Disclosure (e.g., device 800), which may be a network server as part of a network that can be used for key transfer, and which includes HSM 510 and HSM 520. In such a case, the network server may, in step 505, receive payload information from HSM 510 (e.g., using the communication interface between HSM 510 and the network server), and then, in step 506, transfer the payload information to HSM 520 (e.g., using the communication interface between HSM 520 and the network server).

[0133] In another example, application 530 may be understood as a portable data storage device (e.g., a USB flash drive) on which payload information can be temporarily stored and transferred from HSM 510 to HSM 520. In such a case, the portable data storage device can receive payload information from HSM 510 in step 505 (e.g., by receiving and storing the payload information on the portable data storage device), and then transfer the payload information to HSM 520 in step 506 (e.g., by retrieving and outputting the payload information from the portable data storage device).

[0134] In step 507, HSM520 determines the decryption key K_dec and verification key K_ver as the unique session keys for the current transfer session between HSM510 and HSM520. HSM520 determines the decryption key K_dec and verification key K_ver (for example, by using their respective key derivation functions) based on the master key MK stored in HSM520 and several session parameters ID_S, ID_D, and session_ID used by HSM510 to determine the encryption key K_enc and authentication key K_mac, as described in step 503. In the non-restrictive example of Figure 5, the session parameters ID_S, ID_D, and session_ID are included in the payload information and are therefore used to determine K_dec and K_ver. In an example where the payload information does not include ID_D or session_ID, HSM520 may assume its own ID_D stored in HSM520 as ID_D, or may further derive session_ID from a previous session_ID stored in HSM520.

[0135] Before determining the session keys K_dec and K_ver, the HSM520 can verify the recipient identifier ID_D included in the payload information transferred in steps 505 and 506 by checking whether the recipient identifier ID_D included in the payload information matches the recipient identifier ID_D stored in the HSM520 that identifies the HSM520, thereby verifying that the transferred payload information is intended for the HSM520.

[0136] In step 508, the HSM520 extracts the payload information received in step 506 using the session key determined in step 507. In the non-limiting example of Figure 5, extracting the payload information includes verifying the encrypted key information representing the OTS key contained in the key slice, as well as the session parameters ID_S, ID_D, and session_ID contained in the payload information. For verification, the HSM520 determines a MAC based on the encrypted key information, the session parameters ID_S, ID_D, and session_ID contained in the payload information, and the verification key K_ver determined in step 507. To verify the key information and session parameters, the MAC determined by the HSM520 may be compared with the MAC contained in the payload information and determined by the HSM510 in step 504. If the MAC determined by the HSM520 matches the MAC contained in the payload information, the key information and session parameters ID_S, ID_D, and session_ID contained in the payload information received in step 506 are verified.

[0137] Furthermore, in step 508, the HSM520 decrypts the encrypted key information using the decryption key K_dec determined in step 507. The authenticity of the payload information and session parameters may ensure the freshness of the key slice and enable the detection of replay attacks. The encrypted key slice containing the OTS keys requested in step 501 is then stored in the secure electronic memory of the HSM520 for subsequent use. For this purpose, the HSM520 may determine the state information of the transferred OTS keys to indicate that these OTS keys are unused.

[0138] In step 509, the HSM520 may confirm to application 530 that the transferred OTS key has been received by the HSM520, for example, by providing application 530 with corresponding status information indicating the OTS key.

[0139] Figure 6 shows an exemplary embodiment of System 600 according to a fourth aspect of the present disclosure.

[0140] Without limiting the scope of this disclosure, system 600 may comprise at least four devices. In this case, HSM610 (see “Src HSM” in Figure 6) may be understood as a source device, and HSM620 (see “Dest HSM” in Figure 6) may be understood as a destination device. Furthermore, application 630 may be understood as a network server that is part of a network including HSM610 and HSM620 and can be used for key transfer between HSM610 and HSM620. Furthermore, system 600 may include at least one additional HSM640 (see “Dest HSM” in Figure 6) which may be understood as at least one further destination device. As shown in Figure 6, HSM640 may store, for example, a master key MK and may be identified by a recipient identifier ID_D.

[0141] Considering system 600, it may be assumed that key transfers between HSM610 and HSM620 involving application 630 can be performed in the corresponding manner as shown in the example in Figure 5 for HSM510, HSM520, and application 530. Thus, HSM610 is identified by sender identifier ID_S, HSM620 is identified by receiver identifier ID_D, and session identifier session_ID identifies the transfer session between HSM610 and HSM620 for transferring payload information containing encrypted key slices having one or more OTS keys.

[0142] At the start of a key transfer session, the HSM610 may be requested by the application 630 to send a specific key slice to the HSM620 (see step 501 as described with reference to Figure 5). For example, after the HSM610 validates the request, determines the session key, and generates payload information (see steps 502 to 504 as described with reference to Figure 5), the HSM610 may provide the application 630 with instructions for one or more OTS keys contained in the key slice to be transferred to the application 630 within the payload information. Such instructions for one or more OTS keys may be understood as actual OTS keys or as values ​​that identify the OTS keys.

[0143] Application 630 receives instructions for one or more OTS keys from HSM610 and then sends a request to HSM640 asking for indication of whether one or more OTS keys are unused. HSM640 may then check whether information (e.g., status information) about one or more OTS keys is available in HSM640 that could indicate whether one or more OTS keys have been used before or have been previously transferred to HSM640 (e.g., in a previous transfer session between HSM610 and HSM640). HSM640 may then respond to the request from Application 630 by sending confirmation information indicating whether one or more OTS keys are unused. This can be understood to mean that the confirmation information may indicate that at least one or more OTS keys have never been used by HSM640 or have never been previously transferred to HSM640, while they may have been used by another HSM or transferred to another HSM that may be part of System 600.

[0144] After receiving confirmation information from HSM640, application 630 can provide this information to HSM620. HSM620 can then retrieve the confirmation information and check whether the OTS key it received from HSM610 (see step 506 described with reference to Figure 5) is unused. For example, HSM620 may use the OTS key transferred from HSM610 (e.g., by decrypting the OTS key and / or storing it in the secure electronic memory of HSM620) only if the confirmation information indicates that the OTS key has never been used before. Otherwise, HSM620 may discard the transferred OTS key.

[0145] The non-limiting example of the system in Figure 6 shows only one additional destination device, HSM640, but it will be understood that the system may have any number of additional destination devices in addition to HSM620. Generally, assuming that system 600 includes multiple HSMs as destination devices, application 630 can request each HSM to indicate whether one or more OTS keys are unused, and then each HSM can transfer confirmation information to HSM620. HSM620 can then use the OTS key transferred from HSM610 (for example, by storing the OTS key in HSM620's secure electronic memory) only if each of the confirmations indicates that the OTS key has never been used before. Otherwise, HSM620 may discard the transferred OTS key.

[0146] Advantageously, HSM620 in system 600 can then use confirmation information from HSM640 to ensure that the transferred OTS key is unused. In this way, HSM640 can detect a replay attack by checking whether the received OTS key has been transferred to another HSM in system 600 in a previous transfer session.

[0147] Figure 7 is a block diagram of an exemplary embodiment of the device according to the first aspect of the present disclosure (e.g., a source device) or the second aspect (e.g., a destination device). Thus, the device 700 may be configured to perform, for example, the steps of the flowchart 200 shown in Figure 2 or the steps of the flowchart 300 shown in Figure 3.

[0148] The device 700 may include a processor 701 that can represent a single processor or multiple processors (e.g., coupled at least partially, via a bus). The processor 701 can execute program code stored in program memory 702 (e.g., program code that causes the device 700 to execute embodiments or parts thereof according to the present disclosure) and can interface with main memory 703. The program memory 702 may further include an operating system for the processor 701 (e.g., a Linux®-based operating system). Some or all of the memory 702 and memory 703 may also be included in the processor 701.

[0149] Furthermore, the processor 701 may control one or more communication interfaces 704 which can be configured to communicate with further devices. One or more communication interfaces 704 may provide one or more wired and / or wireless connections. Some non-limiting examples include wired connections being serial connections (e.g., by the RS-232 standard), Ethernet connections (by any release of the IEEE-802.3 standard), and / or Universal Serial Bus (USB) connections (e.g., by any release of the USB standard). Non-limiting examples of wireless connections are wireless local area network (WLAN) connections (e.g., by the IEEE-802.11 standard family), or Bluetooth® connections (e.g., by any release of the IEEE-802.15.1 standard).

[0150] In a non-limiting example, the device 700 may be understood as an HSM or a component of an HSM, as described with reference to Figure 1. In this case, the processor 701 may be a secure cryptographic processor, and the memory 702 and / or memory 703 may be secure electronic memory protected by physical security measures. It will be understood that the device 700 may comprise further components, such as further components of an HSM.

[0151] Figure 8 is a block diagram of an exemplary embodiment of the apparatus according to a third aspect of the present disclosure. Thus, the apparatus 800 may be configured to perform, for example, the steps of the flowchart 400 shown in Figure 4.

[0152] The device 800 may include a processor 801 that can represent a single processor or multiple processors (e.g., coupled at least partially, via a bus). The processor 801 can execute program code stored in program memory 802 (e.g., program code that causes the device 800 to execute embodiments or parts thereof according to the present disclosure) and can interface with main memory 803. The program memory 802 may further include an operating system for the processor 801 (e.g., a Linux-based operating system). Some or all of the memory 802 and memory 803 may also be included in the processor 801.

[0153] Furthermore, the processor 801 may control one or more communication interfaces 804 that can be configured to communicate with further devices (e.g., device 700). One or more communication interfaces 804 may provide one or more wired and / or wireless connections. Some non-limiting examples include wired connections being serial connections (e.g., by the RS-232 standard), Ethernet connections (by any release of the IEEE-802.3 standard), and / or Universal Serial Bus (USB) connections (e.g., by any release of the USB standard). Non-limiting examples of wireless connections are wireless local area network (WLAN) connections (e.g., by the IEEE-802.11 standard family), or Bluetooth connections (e.g., by any release of the IEEE-802.15.1 standard).

[0154] In a non-limiting example, device 800 may be understood as a network server that can be configured to manage a network including at least two devices (e.g., at least two HSMs) as described with reference to Figure 7.

[0155] Figure 9 is a schematic diagram of an example of a tangible, non-temporary, computer-readable storage medium according to the present disclosure, which may be used to implement, for example, the memory 702 of Figure 7 and / or the memory 802 of Figure 8. For this purpose, Figure 9 shows a flash memory 900 which may be soldered or bonded to, for example, a printed circuit board; a solid-state drive 901 including a plurality of memory chips (e.g., flash memory chips); a magnetic hard drive 902; a Secure Digital (SD) card 903; a Universal Serial Bus (USB) memory stick 904; an optical storage medium 905 (e.g., a CD-ROM or DVD); and a magnetic storage medium 906.

[0156] Any presented connection in the disclosed embodiments should be understood as such that the components involved are operably coupled. Thus, the connection may be a direct or indirect connection with any number or combination of intervening elements, and there may be only a functional relationship between the components.

[0157] Any processor referred to in this disclosure may be any suitable type of processor. Any processor may include, but is not limited to, one or more microprocessors, one or more processors with associated digital signal processors, one or more processors without associated digital signal processors, one or more dedicated computer chips, one or more field-programmable gate arrays (FPGAS), one or more controllers, one or more application-specific integrated circuits (ASICS), or one or more computers. The associated structures / hardware are programmed to perform the functions described.

[0158] Furthermore, any operation or step described or illustrated in this disclosure is performed using executable instructions of a general-purpose or dedicated processor, which may be stored in a computer-readable storage medium (e.g., disk, memory) executed by such a processor. The reference to “computer-readable storage medium” should be understood to include dedicated circuits such as FPGAs, ASICs, signal processing devices, and other devices.

[0159] The terms “A, or B, or C, or any combination thereof” or “at least one of A, B, and C” are not exhaustive and may be understood to include at least: (i) A, or (ii) B, or (iii) C, or (iv) A and B, or (v) A and C, or (vi) B and C, or (vii) A, B, and C.

[0160] The embodiments disclosed herein are illustrative only, and it will be understood that any feature presented in a particular exemplary embodiment may be used in any aspect of this disclosure, either by itself or in combination with any feature presented in the same or another particular exemplary embodiment, and / or in combination with any other feature not mentioned herein. It will also be understood that any feature presented in an exemplary embodiment of a particular category may be used in a corresponding manner in any other exemplary embodiment of any other category.

Claims

1. Method (200), - Obtaining key information (210) from a secure electronic memory, wherein the key information represents one or more keys (140), - Determining (220) an encryption key at least in part based on a plurality of session parameters and a master key (150), wherein the plurality of session parameters include a session identifier, a sender identifier (160), and a receiver identifier (170), - Encrypting the key information based at least in part on the determined encryption key (230), - Providing payload information (240), wherein the payload information includes at least the encrypted key information and the sender identifier (160), Method (200), including the method (200).

2. The method according to claim 1 (200), wherein the provided payload information further includes the session identifier and the recipient identifier (170).

3. - Determining authentication information based at least in part on an authentication key, the key information, and the plurality of session parameters, wherein the provided payload information further includes the determined authentication information. The method according to claim 1 or 2 (200), further comprising:

4. - Determining the authentication key based at least partially on the plurality of session parameters and the master key (150) The method according to claim 3 (200), further comprising:

5. - Receiving request information indicating one or more keys (140), - To determine whether one or more keys (140) indicated by the request information are available and unused, The method according to any one of claims 1 to 4 (200), further comprising:

6. - Determine the updated state of one or more keys (140) The method according to any one of claims 1 to 5 (200), further comprising:

7. - To provide instructions for one or more keys (140) represented by the key information. The method according to any one of claims 1 to 6 (200), further comprising:

8. Method (300), - Acquiring payload information (310), wherein the payload information includes a sender identifier (160) and encrypted key information, and the key information represents one or more keys (140), - Determining (320) a decryption key at least in part based on a master key (150) and a plurality of session parameters, wherein the plurality of session parameters include the sender identifier (160), the receiver identifier (170), and the session identifier. - Decrypting the key information based at least partially on the determined decryption key (330), - Storing the aforementioned key information in a secure electronic memory (340), Method (300), including the method (300).

9. The method according to claim 8 (300), wherein the acquired payload information further includes the session identifier and the recipient identifier (170).

10. - Before determining the decryption key, verify the recipient identifier (170) included in the payload information. The method according to claim 9 (300), further comprising:

11. The acquired payload information further includes authentication information, and the method is - Verify the key information and the multiple session parameters based at least partially on the authentication information and verification key. The method according to any one of claims 8 to 10 (300), further comprising:

12. - Determining the verification key based at least partially on the plurality of session parameters and the master key (150) The method according to claim 11 (300), further comprising:

13. - To provide status information indicating one or more keys (140) The method according to any one of claims 8 to 12 (300), further comprising:

14. - To determine the state of one or more keys (140) The method according to any one of claims 8 to 13, further comprising (300).

15. - Obtaining confirmation information indicating whether or not the one or more keys (140) represented by the key information are unused, wherein the key information is stored in the secure electronic memory when the confirmation information indicates that the one or more keys (140) are unused. The method according to any one of claims 8 to 14 (300), further comprising:

16. The aforementioned payload information is transferred from the source device (110; 510; 610) to the destination device (120; 520; 620). - The sender identifier (160) identifies the source device (110; 510; 610), - The recipient identifier (170) identifies the destination device (120; 520; 620), - The session identifier identifies the transfer session between the source device (110; 510; 610) and the destination device (120; 520; 620) for transferring the payload information. The method according to any one of claims 1 to 15 (200; 300).

17. The method according to any one of claims 1 to 16 (200; 300), wherein the one or more keys (140) are one-time signing keys and / or the one or more keys represent a key slice.

18. Method (400), - Receiving payload information (410) from a source device (110; 510; 610), wherein the payload information includes at least encrypted key information representing one or more keys (140) and a sender identifier (160) identifying the source device (110; 510; 610), wherein the encrypted key information is encrypted at least in part based on an encryption key, the encryption key is determined at least in part based on a plurality of session parameters, the plurality of session parameters including the sender identifier (160), a receiver identifier (170) identifying a destination device (120; 520; 620), and a session identifier identifying a transfer session between the source device (110; 510; 610) and the destination device (120; 520; 620), - Providing the payload information to the destination device (120; 520; 620) (420), Method (400), including the method (400).

19. - Obtaining instructions for one or more keys (140) represented by the key information from the transmitting device (110; 510; 610), - Sending a request to at least one further destination device (640) to indicate whether or not the one or more keys (140) are unused, - In response to the request, receive confirmation information from at least one further destination device (640) indicating whether or not the one or more keys (140) are unused, - To provide the aforementioned confirmation information to the aforementioned destination device (120; 520; 620), The method according to claim 18 (400), further comprising:

20. Apparatus (110; 510; 610; 700) configured to perform the method (200) described in any one of claims 1 to 7, 16 and 17, and / or comprising means (701; 702; 703; 704) for performing the method (200).

21. Apparatus (120; 520; 620; 700) configured to carry out the method (300) according to any one of claims 8 to 17, and / or comprising means (701; 702; 703; 704) for carrying out the method (300).

22. Apparatus (530; 630; 800) configured to carry out the method (400) described in claim 18 or 19, and / or comprising means (801; 802; 803; 804) for carrying out the method (400).

23. A system (100; 600) comprising the apparatus (110; 510; 610; 700) according to claim 20 and the apparatus (120; 520; 620; 700) according to claim 21.

Images