WO2022111823A1 - Devices and methods for supporting key management system for internet-of-things - Google Patents

Devices and methods for supporting key management system for internet-of-things Download PDF

Info

Publication number
WO2022111823A1
WO2022111823A1 PCT/EP2020/083847 EP2020083847W WO2022111823A1 WO 2022111823 A1 WO2022111823 A1 WO 2022111823A1 EP 2020083847 W EP2020083847 W EP 2020083847W WO 2022111823 A1 WO2022111823 A1 WO 2022111823A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
message
server device
mac
iot
Prior art date
Application number
PCT/EP2020/083847
Other languages
French (fr)
Inventor
Yong Li
Lijun Liao
Li DUAN
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to CN202080107076.8A priority Critical patent/CN116458110A/en
Priority to PCT/EP2020/083847 priority patent/WO2022111823A1/en
Publication of WO2022111823A1 publication Critical patent/WO2022111823A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Definitions

  • the disclosure relates generally to the field of internet of things (IoT), and particularly to a key management system (KMS) for the IoT.
  • KMS key management system
  • a server device is presented for supporting such a KMS.
  • the server device may upon request generate and update a key for another device based on a master secret key.
  • the disclosure also presents a device for the IoT.
  • the device may request an update of a key of the device from the server device.
  • IoT node deployment increased by quite a lot.
  • more and more data is transmitted in IoT, and ensuring the confidentiality and integrity of such data becomes more important.
  • Authenticated and confidential channel establishment protocols may provide a reliable protection of data, for example, when the underlying algorithms have sufficient strengths and use well managed cryptographic keys.
  • Conventional devices and methods in this respect are based on, for example, using asymmetric cryptography, or are constructed in an ad-hoc manner.
  • provisioned keys may also be used for updating software and firmware on IoT nodes. For instance, an author certificate or a public key may be used for verifying the origin of a firmware update and its integrity. However, storing the keys may increase the attack surface.
  • embodiments of the present disclosure aim to improve the conventional devices and methods for IoT.
  • An objective is, in particular, to provide a KMS for IoT.
  • a key hierarchy and a key update protocol are desired.
  • the key hierarchy should be simple and flexible.
  • the key update protocols should be efficient.
  • the embodiments of the disclosure provide, in particular, a server device for supporting a KMS for IoT, a device for IoT, and corresponding methods.
  • the server device and the device may use a symmetric cryptography, so the key generation speed may be increased and the hardware requirement for IoT devices may be decreased.
  • a first aspect of the disclosure provides a server device for supporting a key management system (KMS) for internet of thing (IOT), the server device being configured to receive a message from another device, the message indicating a request for an update of a first key of the other device, generate the first key for the other device, wherein the first key is valid for a first time period, based on a master secret key, generate a second key for the other device, wherein the second key is valid for a second time period, based on the master secret key, and send a message indicating the second key, to the other device.
  • KMS key management system
  • IOT internet of thing
  • the server device may be, or may be incorporated in, for example, an IoT server.
  • the device may be, or may be incorporated in, for example, an IoT device, a client device, etc.
  • the KMS may be used for generating (e.g., high quality) keys, updating the generated keys when necessary, and revoking compromised keys for various entities.
  • the KMS may be an IoT KMS.
  • the KMS may use a master secret key and a pseudo-random function to generate one or more keys associated with different identifiers (ID) of devices, version numbers and group identifiers.
  • ID identifiers
  • the server device may further be configured to obtain a master secret key for the KMS.
  • the master secret key may be, for example, a long-term secret key owned by KMS and used for deriving other keys.
  • a master secret key may be used for deriving a first key and/or a second key for each device (node) based on its identifier and a version number.
  • the keys managed by the KMS may be, for example, a master secret key, a first key for a device (node), a second key for a device, a group (session) key, etc.
  • the master secret key may be stored only at the server device, so a dedicated high-security hardware can be used for protection of the master secret key.
  • the KMS may be a secure system which may belong to the IoT architecture. Moreover; the KMS may be provisioned with the master secret key.
  • the first key and second key may be, for example, a middle-term key used by the device for IoT (a node of IoT) and may be updated from time to time.
  • the server device may generate the first key for the other device based on the master secret key.
  • the server device may generate the first key before receiving the message indicating the request for the update of the first key of the other device.
  • the server device may generate the first key after receiving the message indicating the request for the update of the first key of the other device.
  • the server device may generate the second key for the other device based on the master secret key, and send the message indicating the second key to the other device.
  • the message may comprise a cipher-text that is encrypted.
  • the encrypted cipher- text may comprise the second key.
  • the server device may support the KMS.
  • the KMS may be for inter-node communications.
  • the KMS may be lightweight, for example, the key hierarchy may be relatively flat with a limited depth, the key update protocols may have the optimal number of messages for explicit authentication, and the computation of key materials and messages may only involves efficient symmetric cryptography.
  • the server device may further use cryptography to separate keys of different owners’ and periods.
  • the server device may comprise a circuitry.
  • the circuitry may comprise hardware and software.
  • the hardware may comprise analog or digital circuitry, or both analog and digital circuitry.
  • the circuitry comprises one or more processors and a non volatile memory connected to the one or more processors.
  • the non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein.
  • the server device is further configured to receive, from the other device, via a communication channel, one or more of:
  • the second key may be generated which may be associated with the identifier of the other device.
  • each of the other devices may have a unique identifier.
  • the sever device may generate, for each of the other devices (IoT nodes), a respective second key which may be associated with its identifier.
  • the sent message further comprises one or more of:
  • the server device may be able to provide the second key to the other device in a secure communication manner, using a symmetric cryptography.
  • the server device may generate the second key.
  • the server device may use a symmetric cryptography and may further generate the cipher- text.
  • the other device IoT node
  • the second key may be provided in a secure communication manner.
  • the first key for the other device is generated based further on the identifier of the other device and the first key counter of the other device.
  • the second key of each of the other devices may be associated with its identifier.
  • the server device may be able to separate the keys of different IoT nodes from each other. Hence, the security may be increased.
  • the second key for the other device is generated based further on the identifier of the other device and a second key counter of the other device.
  • This may provide an advantage that, for example, a simple and flexible key hierarchy may be provided. For example, by using, for each of the other devices, its identifier and its second key counter, a corresponding second key may be generated. This may further increase the security of the KMS.
  • the server device is further configured to determine a first temporary transport key based on the first key of the other device, and generate the cipher-text by encrypting the second key with the first temporary transport key. This may enable the server device to encrypt the second key in a secure manner.
  • the first temporary transport key may be used for encrypting the second key and generating the cipher text in a secure manner.
  • the encryption may be for hiding the second key from an attacker.
  • the encryption may be based on a symmetric key encryption scheme (SKE).
  • SKE symmetric key encryption scheme
  • the server device may use any of the non-deterministic key generation algorithm, the (non- deterministic) encryption algorithm, or the deterministic decryption algorithm, discussed above.
  • the server device is further configured to determine a first message authentication code (MAC) key, based on the first key of the other device, and generate the MAC tag message based on authenticating the cipher-text with the first MAC key.
  • MAC message authentication code
  • the server device may provide the second key to the other device (IoT node) in a secure manner.
  • the message comprising the MAC tag message may be sent to the other device.
  • the other device (IoT node) may receive the message, and may verify an authentication of its MAC tag message (e.g., by calculating a first MAC key).
  • the other device (IoT node) may retrieve the second message.
  • the server device may use message authentication code to protect the integrity of messages and compute the responses.
  • MAC.TagO takes the secret key k and a message m as the input and outputs the authentication tag macT.
  • the server device is further configured to receive, from the other device, an acknowledgment (ACK) message, and update, upon a successful verification of the ACK message, a key counter of the other device to a further key counter of the other device.
  • ACK acknowledgment
  • a second aspect of the disclosure provides a device for IoT, the device comprising a first key of the device, wherein the first key is valid for a first time period, wherein the device is configured to, send a message to a server device, the message indicating a request for an update of the first key of the device, and receive a message from the server device, the message indicating a second key of the device, wherein the second key is valid for a second time period.
  • the device of the second aspect may be, or may be incorporated in, for example, an IoT device, an IoT node, a client device, etc.
  • the server device may be, or may be incorporated in, for example, an IoT server.
  • the device for IoT may comprise a storage unit which may store the first key of the device. Furthermore, the device may support an Advanced Encryption Standard (AES) module.
  • AES Advanced Encryption Standard
  • the device may comprise a circuitry.
  • the circuitry may comprise hardware and software.
  • the hardware may comprise analog or digital circuitry, or both analog and digital circuitry.
  • the circuitry comprises one or more processors and a non-volatile memory connected to the one or more processors.
  • the non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein.
  • the device is further configured to verify an authentication of the received message from the server device, and retrieve the second key of the device.
  • the device may verify the received message.
  • the second key that is indicated in the received message may be retrieved by the device.
  • the device may use a pseudo-random function (PRF) to derive keys.
  • PRF pseudo-random function
  • the PRF may have the property that if the secret key is unknown to the attacker, the output is close to uniformly random in the attacker’s view.
  • the device is further configured to send to the server device, via a communication channel, one or more of:
  • the device may send its identifier, the first random number and the first key counter to the server device.
  • the server device may generate the first key and/or the second key for the device, e.g., based on its identifier, etc.
  • the received message comprises one or more of:
  • the server device may generate the second key.
  • the server device may use a symmetric cryptography and may further generate the cipher-text.
  • the device IoT node
  • the second key may be received in a secure communication manner.
  • the device is further configured to calculate a first MAC key, based on the first key of the device, and verify an authentication of the MAC tag message of the received message, based on the first MAC key. For example, the device may receive the message comprising the MAC tag message. Moreover, the device may verify an authentication of the MAC tag message of the received message. Moreover, for example, after that the authentication of the MAC tag message is verified, the device (IoT node) may retrieve the second message. This may further increase the security of the KMS.
  • the device is further configured to calculate a first temporary transport key, based on the first key of device, and retrieve the second key of the device based on a decryption of the cipher-text using the first temporary transport key.
  • the device may calculate the first temporary transport key, based on the first key of device. Moreover, the first temporary transport key may be used for decrypting the cipher-text indicating the second key. Furthermore, the second key may be retrieved.
  • This may provide an advantage that, for example, a simple and flexible key hierarchy may be provided.
  • the device is further configured to generate an ACK message, based on the first MAC key, and send the ACK message to the server device.
  • a third aspect of the disclosure provides a method for supporting a KMS for IOT, the method comprising receiving a message from an other device, the message indicating a request for an update of a first key of the other device, generating the first key for the other device, wherein the first key is valid for a first time period, based on a master secret key, generating a second key for the other device, wherein the second key is valid for a second time period, based on the master secret key, and sending a message indicating the second key, to the other device.
  • the method further comprises receiving, from the other device, via a communication channel, one or more of:
  • the sent message further comprises one or more of:
  • the method further comprises generating the first key for the other device based further on the identifier of the other device and the first key counter of the other device.
  • the method further comprises generating the second key for the other device based further on the identifier of the other device and a second key counter of the other device.
  • the method further comprises determining a first temporary transport key based on the first key of the other device, and generating the cipher-text by encrypting the second key with the first temporary transport key.
  • the method further comprises determining a first MAC key, based on the first key of the other device, and generating the MAC tag message based on authenticating the cipher-text with the first MAC key.
  • the method further comprises receiving, from the other device, an ACK message, and updating, upon a successful verification of the ACK message, a key counter of the other device to a further key counter of the other device.
  • a fourth aspect of the disclosure provides a method for a device for IOT, the device comprising a first key of the device, wherein the first key is valid for a first time period, wherein the method comprising sending a message to a server device, the message indicating a request for an update of the first key of the device, and receiving a message from the server device, the message indicating a second key of the device, wherein the second key is valid for a second time period.
  • the method further comprises verifying an authentication of the received message from the server device, and retrieving the second key of the device.
  • the method further comprises sending to the server device, via a communication channel, one or more of:
  • the received message comprises one or more of:
  • the method further comprises calculating a first MAC key, based on the first key of the device, and verifying an authentication of the MAC tag message of the received message, based on the first MAC key.
  • the method further comprises calculating a first temporary transport key, based on the first key of device, and retrieving the second key of the device based on a decryption of the cipher-text using the first temporary transport key.
  • the method further comprises generating an ACK message, based on the first MAC key, and sending the ACK message to the server device.
  • the method of the fourth aspect achieves the advantages and effects described for the device of the second aspect.
  • a fifth aspect of the disclosure provides a computer program comprising a program code for performing the method according to the third aspect or the fourth aspect or any of their implementation forms.
  • a sixth aspect of the disclosure provides a non-transitory storage medium storing executable program code which, when executed by a processor, causes the method according to the third aspect or the fourth aspect or any of their implementation forms to be performed.
  • FIG. 1 depicts a schematic view of a server device for supporting a KMS for IOT and a device for IOT, according to an embodiment of the disclosure
  • FIG. 2 shows a key hierarchy for a single IoT node
  • FIG. 3 shows a key hierarchy for multiple nodes
  • FIG. 4 shows an exemplarily key update protocol
  • FIG. 5 an exemplarily key update protocol ⁇ NKUP based on PRF, MAC and a symmetric encryption
  • FIG. 6 shows a computerized system for executing key update protocol ⁇ NKUP and maintaining key states
  • FIG. 7 depicts a schematic view of a flowchart of a method for supporting a KMS for IoT, according to an example of the disclosure.
  • FIG. 8 depicts a schematic view of a flowchart of a method for a device for IoT, according to an example of the disclosure.
  • FIG. 1 shows a schematic view of a server device 100 for supporting a KMS 101 for IoT and a device 200 for IoT, according to an embodiment of the disclosure.
  • the server device 100 may be an IoT server, and the device may be an IoT node.
  • the KMS may be an IoT KMS.
  • the server device 100 for supporting the KMS 101 for internet of thing is configured to receive a message 201 from an other device 200, the message 201 indicating a request for an update of a first key 111 of the other device 200.
  • the server device 100 is further configured to generate the first key 111 for the other device 200, wherein the first key 111 is valid for a first time period, based on a master secret key 110
  • the server device 100 is further configured to generate a second key 112 for the other device 200, wherein the second key 112 is valid for a second time period, based on the master secret key 110.
  • the server device 100 may comprise a processor 120 which may generate the first key, the second key, etc.
  • the server device 100 is further configured to send a message 120 indicating the second key 112, to the other device 200.
  • the device 200 comprises a first key 111 of the device 200, wherein the first key 111 is valid for a first time period.
  • the device 200 is configured to send a message 201 to a server device 100, the message 201 indicating a request for an update of the first key 111 of the device 200.
  • the device 200 is further configured to receive a message 120 from the server device 100, the message 120 indicating a second key 112 of the device 200, wherein the second key 112 is valid for a second time period.
  • the device 200 may comprise a processor 220 which may retrieve the first key, the second key, etc.
  • the server device 100 and/or the device 200 may comprise processing circuitry (not shown in FIG. 1) configured to perform, conduct or initiate the various operations of the device 100 described herein.
  • the processing circuitry may comprise hardware and software.
  • the hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry.
  • the digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors.
  • the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors.
  • the non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the server device 100 and/or the device 200 to perform, conduct or initiate the operations or methods described herein.
  • the server device 200 is based on an IoT server comprising a KMS 101 that is based on an IoT KMS 101, and the device 200 is based on an IoT node.
  • FIG. 2 shows an exemplary key hierarchy for the device 200 (e.g., a single IoT node), from long term master secret key (ms) 110 protected by IoT KMS 101 to temporarily valid transport and MAC keys owned by the device 200.
  • ms master secret key
  • the key hierarchy can be viewed from three planes.
  • the key hierarchy shows the relation between different keys, and it also determines when or where a key update protocol is necessary, and it may guarantee a security of the keys.
  • the master secret key (ms) 110 may be a long-term secret owned by KMS 101 and may be used for deriving other keys.
  • the master secret key 110 may be used to recover a node key or data key.
  • the master secret key 110 may reside only at the server device 100, so that a dedicated high-security hardware can be used for protection.
  • the first key 111 (node key k T ) may be a middle-term key used by the device 200, and may be updated from time to time.
  • the master secret key 110 may be used for deriving first key 111 (key ki for each device 200 (each IoT node) based on its identifier i and a version number CNT, ⁇ , where i and CNT, are public information.
  • the solid arrow “ ” means that lower level keys can be derived from upper layer keys. More specifically, all the node keys comprising k T (the first key 111), and k 1 1 (the second key 112) may be derived from the master secret key 110, and the temporary transport key 212 (ktrans) and the temporary MAC key 211 (kmac) are derived from a current node key (the first key 111 or the second key 112). For example, the temporary transport key 212 (ktrans) and the temporary MAC key 211 (kmac) are derived from the first key 111. Moreover, the temporary transport key 222 (ktrans) and the temporary MAC key 221 (kmac) may be derived from the second key 112.
  • a key update protocol may be implemented that may run by the server device 100 (e.g., the IoT server comprising the KMS 101) and the device 200 (e.g., the IoT node).
  • FIG. 3 shows the key hierarchy for multiple nodes, i.e., in the spatial plane.
  • the server device 200 comprising the KMS 101 may generate the first key 111 for the device 200 (a first node), based on the master secret key 110. Moreover, the temporary transport key 222 (ktrans) and the temporary MAC key 221 (kmac) for the device 200 (the first node), are derived from the first key 111.
  • the server device 200 comprising the KMS 101 may generate the first key 301 for a second node, based on the master secret key 110. Moreover, the temporary transport key 312 (ktrans) and the temporary MAC key 311 (kmac) for the second node, are derived from the first key 301.
  • the server device 100 comprising the KMS 101 may generate the first key 302 for athird node, based on the master secret key 110.
  • the temporary transport key 322 (ktrans) and the temporary MAC key 321 (kmac) for the third node may be derived from the first key 302.
  • the node keys that are derived from the master secret key 110 may be located on separate nodes. They may remain computationally independent and may be updated without considering the state of other nodes.
  • FIG. 4 shows an exemplarily key update protocol.
  • a key update protocol ⁇ NKUP for node keys is shown, which can be viewed as a prototype for key updates in more complicated scenarios.
  • the key update protocol mainly works as follows, where three messages are then exchanged to perform the key update.
  • the update request may be computed by the device 200 (IoT node). If the server device 200 (IoT KMS) confirms its validity, it may generate one or more new keys (e.g., the second key 112 for the device 200), may compute a response from chi, and may generate the new challenge di2.
  • a valid response in M2 may ensure that the device 200 (IoT node) is talking to the real server device 200 comprising the IoT KMS 101.
  • the server device 200 comprising the IoT KMS 101 may confirm that the device 200 (IoT node) has obtained the second key 112, successfully.
  • the request comprises essential identifiers.
  • the challenges may be nounces Ni and N2.
  • the acknowledgement may comprise a MAC value. (See FIG. 5).
  • FIG. 5 shows an exemplarily key update protocol ⁇ NKUP based on PRF, MAC and a symmetric encryption.
  • initialization the server device 100 comprising the IoT KMS 101 is provisioned with the master secret key 110 and the device 200 (IoT node) has the first key (initial key ko). Other information, such as a counter value CNTo and the identifier pidi, has also been provisioned by the end of this phase.
  • update at time t + 1, t > 0 the device 200 (IoT node identified by pidi) may select a random nonce Ni and sends Ni along with its request for key update. Note that, the device 200 (IoT node) holds the current key k T , x > 0.
  • the server device 100 comprising the IoT KMS 101 may recover the key k T for phase x and further derives the temporary transport key ktrans and MAC key kmac.
  • the server device 100 comprising the IoT KMS 101 may generate the second key 112 (for example, by generating a new key for pidi), encrypt it with ktrans 212 and authenticate the ciphertext CT T +i with kmac 211. Then the CT T +i , a new nonce N2 and the MAC tag (macTi) may be sent to the device 200 (IoT node).
  • the device 200 may derive the temporary transport key ktrans 212 and MAC key kmac 211 from the current key k T (e.g., the first key 111).
  • the device 200 (IoT node) may further verify the MAC tag (macTi), and the message. If the verification succeeds, the device 200 (IoT node) may retrieve the second key 112 by decrypting CT 1+ 1. Afterwards, the device 200 (IoT node) may generate an acknowledge MAC tag macT2, as discussed above with respect to FIG. 4.
  • the server device 100 may verify it, and may abort if the verification fails. Otherwise, the server device 100 may update the counter CNT T to the next value CNT 1 + 1.
  • the two random numbers N 1 and N2 may work as challenges for the peer.
  • FIG. 6 shows a computerized system for executing a key update protocol ⁇ NKUP and maintaining the key states.
  • the computerized system shown in FIG. 6 may be implemented in the server device 100 and/or the device 200.
  • the communication interfaces 601 are configured for exchanging messages with the intended peer(s).
  • the message authentication codes (MAC) operator 602 is configured for tagging a message and checking a message with the provisioned secret.
  • the pseudo random function (PRF) operator 603 is configured for deriving keys from the identifier and the provisioned secret.
  • the encryption operator 604 is configured for encrypting new key materials in a reliable way.
  • the synchronization module 605 is configured for synchronizing states internally and with the peer.
  • the synchronization module 605 may control the logic depending on the checking and decrypting results of the MAC) operator 602 and the encryption operator 604.
  • the synchronization module 605, when being implemented in the server device 100 may maintain all synchronization information of all nodes in the same KMS 101.
  • FIG. 7 shows a method 700 according to an embodiment of the disclosure for supporting a KMS 101 for IOT.
  • the method 700 may be carried out by the sever device 100, as it is described above.
  • the method 700 comprises a step 701 of receiving a message 201 from another device 200, the message 201 indicating a request for an update of a first key 111 of the other device 200.
  • the method 700 further comprises a step 702 of generating the first key 111 for the other device 200, wherein the first key 111 is valid for a first time period, based on a master secret key 110.
  • the method 700 further comprises a step 703 of generating a second key 112 for the other device 200, wherein the second key 112 is valid for a second time period, based on the master secret key 110.
  • the method 700 further comprises a step 704 of sending a message 120 indicating the second key 112, to the other device 200.
  • FIG. 8 shows a method 800 according to an embodiment of the disclosure for a device for IOT, the device comprising a first key 111 of the device 200, wherein the first key 111 is valid for a first time period.
  • the method 800 may be carried out by the device 200, as it is described above.
  • the method 800 comprises a step 801 of sending a message 201 to a server device 100, the message 201 indicating a request for an update of the first key 111 of the device 200;
  • the method 800 further comprises a step 802 receiving a message 120 from the server device 100, the message 120 indicating a second key 112 of the device 200, wherein the second key 112 is valid for a second time period.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

The present disclosure relates to a server device for supporting a key management system (KMS) for internet of thing (IoT), and a device for IoT. The server device is configured to receive a message from the device, the message indicating a request for an update of a first key of the other device. The server device is further configured to generate the first key for the other device, based on a master secret key, generate a second key for the other device, based on the master secret key, and send a message indicating the second key, to the other device. The device is configured to send a message to the server device, the message indicating a request for an update of the first key of the device, and receive a message from the server device, the message indicating a second key of the device.

Description

DEVICES AND METHODS FOR SUPPORTING KEY MANAGEMENT SYSTEM
FOR INTERNET-OF-THINGS TECHNICAL FIELD
The disclosure relates generally to the field of internet of things (IoT), and particularly to a key management system (KMS) for the IoT. A server device is presented for supporting such a KMS. The server device may upon request generate and update a key for another device based on a master secret key. The disclosure also presents a device for the IoT. The device may request an update of a key of the device from the server device.
BACKGROUND
Recently, IoT node deployment increased by quite a lot. At the same time, more and more data is transmitted in IoT, and ensuring the confidentiality and integrity of such data becomes more important. Authenticated and confidential channel establishment protocols may provide a reliable protection of data, for example, when the underlying algorithms have sufficient strengths and use well managed cryptographic keys.
Conventional devices and methods in this respect are based on, for example, using asymmetric cryptography, or are constructed in an ad-hoc manner.
However, an issue of the conventional devices and methods is that a typical IoT node may have a limited storage and support for cryptographic algorithms. Thus, heavyweight (asymmetric) public key schemes might not be available for such IoT nodes.
Another issue of the conventional devices and methods is that storing all the keys directly on an IoT node might not be possible, for example, since the storage of a single node may not be able to store multiple keys securely. Moreover, provisioned keys may also be used for updating software and firmware on IoT nodes. For instance, an author certificate or a public key may be used for verifying the origin of a firmware update and its integrity. However, storing the keys may increase the attack surface.
SUMMARY
In view of the above-mentioned problems and disadvantages, embodiments of the present disclosure aim to improve the conventional devices and methods for IoT.
An objective is, in particular, to provide a KMS for IoT. For example, a key hierarchy and a key update protocol are desired. The key hierarchy should be simple and flexible. Furthermore, the key update protocols should be efficient.
The objective is achieved by the embodiments of the disclosure as described in the enclosed independent claims. Advantageous implementations of the embodiments of the disclosure are further defined in the dependent claims.
The embodiments of the disclosure provide, in particular, a server device for supporting a KMS for IoT, a device for IoT, and corresponding methods. The server device and the device may use a symmetric cryptography, so the key generation speed may be increased and the hardware requirement for IoT devices may be decreased.
A first aspect of the disclosure provides a server device for supporting a key management system (KMS) for internet of thing (IOT), the server device being configured to receive a message from another device, the message indicating a request for an update of a first key of the other device, generate the first key for the other device, wherein the first key is valid for a first time period, based on a master secret key, generate a second key for the other device, wherein the second key is valid for a second time period, based on the master secret key, and send a message indicating the second key, to the other device.
The server device may be, or may be incorporated in, for example, an IoT server. The device may be, or may be incorporated in, for example, an IoT device, a client device, etc. The KMS may be used for generating (e.g., high quality) keys, updating the generated keys when necessary, and revoking compromised keys for various entities. The KMS may be an IoT KMS. For example, the KMS may use a master secret key and a pseudo-random function to generate one or more keys associated with different identifiers (ID) of devices, version numbers and group identifiers.
The server device may further be configured to obtain a master secret key for the KMS. The master secret key may be, for example, a long-term secret key owned by KMS and used for deriving other keys. For instance, a master secret key may be used for deriving a first key and/or a second key for each device (node) based on its identifier and a version number.
The keys managed by the KMS may be, for example, a master secret key, a first key for a device (node), a second key for a device, a group (session) key, etc. The master secret key may be stored only at the server device, so a dedicated high-security hardware can be used for protection of the master secret key.
In particular, the KMS may be a secure system which may belong to the IoT architecture. Moreover; the KMS may be provisioned with the master secret key.
The first key and second key may be, for example, a middle-term key used by the device for IoT (a node of IoT) and may be updated from time to time. For example, the server device may generate the first key for the other device based on the master secret key.
In some embodiments, the server device may generate the first key before receiving the message indicating the request for the update of the first key of the other device.
In some embodiments, the server device may generate the first key after receiving the message indicating the request for the update of the first key of the other device.
Moreover, the server device may generate the second key for the other device based on the master secret key, and send the message indicating the second key to the other device. For example, the message may comprise a cipher-text that is encrypted. The encrypted cipher- text may comprise the second key.
Hence, the server device may support the KMS. The KMS may be for inter-node communications. Moreover, the KMS may be lightweight, for example, the key hierarchy may be relatively flat with a limited depth, the key update protocols may have the optimal number of messages for explicit authentication, and the computation of key materials and messages may only involves efficient symmetric cryptography. The server device may further use cryptography to separate keys of different owners’ and periods.
The server device may comprise a circuitry. The circuitry may comprise hardware and software. The hardware may comprise analog or digital circuitry, or both analog and digital circuitry. In some embodiments, the circuitry comprises one or more processors and a non volatile memory connected to the one or more processors. The non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein.
In an implementation form of the first aspect, the server device is further configured to receive, from the other device, via a communication channel, one or more of:
• an identifier of the other device,
• a first random number,
• a first key counter of the other device.
This may provide an advantage that, for example, the second key may be generated which may be associated with the identifier of the other device. For instance, in some embodiments there may be multiple IoT nodes, i.e., a plurality of other devices. Moreover, each of the other devices may have a unique identifier. Furthermore, the sever device may generate, for each of the other devices (IoT nodes), a respective second key which may be associated with its identifier. Moreover, it may be possible to separate the keys of different other devices from each other. This may further increase the security of the KMS.
In a further implementation form of the first aspect, the sent message further comprises one or more of:
• a second random number, • a cipher-text,
• a message authentication code (MAC) tag message.
This may provide an advantage that, for example, the server device may be able to provide the second key to the other device in a secure communication manner, using a symmetric cryptography. For example, the server device may generate the second key. Furthermore, the server device may use a symmetric cryptography and may further generate the cipher- text. Furthermore, the other device (IoT node) may obtain the cipher text and may decrypt it, and may further retrieve the second key. Hence, the second key may be provided in a secure communication manner.
In a further implementation form of the first aspect, the first key for the other device is generated based further on the identifier of the other device and the first key counter of the other device.
This may further increase the security of the KMS. For example, the second key of each of the other devices (IoT nodes) may be associated with its identifier. Moreover, the server device may be able to separate the keys of different IoT nodes from each other. Hence, the security may be increased.
In a further implementation form of the first aspect, the second key for the other device is generated based further on the identifier of the other device and a second key counter of the other device.
This may provide an advantage that, for example, a simple and flexible key hierarchy may be provided. For example, by using, for each of the other devices, its identifier and its second key counter, a corresponding second key may be generated. This may further increase the security of the KMS.
In a further implementation form of the first aspect, the server device is further configured to determine a first temporary transport key based on the first key of the other device, and generate the cipher-text by encrypting the second key with the first temporary transport key. This may enable the server device to encrypt the second key in a secure manner. For example, the first temporary transport key may be used for encrypting the second key and generating the cipher text in a secure manner.
The encryption may be for hiding the second key from an attacker. The encryption may be based on a symmetric key encryption scheme (SKE). For example, the server device may encrypt the generated cipher-text using a symmetric key encryption scheme such as IT = (KGen, Enc, Dec) comprising three algorithms of KGen, Enc and Dec, described as follows.
$
• P. KGen(lK) ® k. A non-deterministic key generation algorithm KGen() that takes the security parameter 1K as the input and outputs one encryption-decryption key k.
$
• P. Enc(k, m) ® CT. A (non-deterministic) encryption algorithm Enc() that takes the key k and a message m as the input and outputs a ciphertext CT.
• P. Dec(k, CT) = m'. A deterministic decryption algorithm Dec() that takes the key k, a ciphertext CT as input and outputs a plaintext m.
The present disclosure is not limited to a specific encryption procedure. For example, the server device may use any of the non-deterministic key generation algorithm, the (non- deterministic) encryption algorithm, or the deterministic decryption algorithm, discussed above.
In a further implementation form of the first aspect, the server device is further configured to determine a first message authentication code (MAC) key, based on the first key of the other device, and generate the MAC tag message based on authenticating the cipher-text with the first MAC key.
This may enable the server device to provide the second key to the other device (IoT node) in a secure manner. For example, the message comprising the MAC tag message may be sent to the other device. The other device (IoT node) may receive the message, and may verify an authentication of its MAC tag message (e.g., by calculating a first MAC key). Moreover, for example, after that the authentication of the MAC tag message is verified, the other device (IoT node) may retrieve the second message.
For example, the server device may use message authentication code to protect the integrity of messages and compute the responses. For instance, the server device may use a MAC scheme such as MAC = (MAC. Gen, MAC. Tag, MAC.Vfy) comprising three algorithms of MAC. Gen, MAC. Tag and MAC.Vfy described as follows:
• MAC.Gen(lK) ® k. A non-deterministic key generation algorithm MAC.Gen() that takes the security parameter 1K as the input and outputs the secret key k.
• MAC.Tag(k,m) ® macT. A (non-deterministic) message tagging algorithm MAC.TagO takes the secret key k and a message m as the input and outputs the authentication tag macT.
• MAC.Vfy(k,m, macT) = b. A deterministic tag verification algorithm MAC.VfyO that takes the secret key k, a message m and a tag macT as input and outputs a boolean value b. b is TRUE if macT is a valid MAC tag on m. In a further implementation form of the first aspect, the server device is further configured to receive, from the other device, an acknowledgment (ACK) message, and update, upon a successful verification of the ACK message, a key counter of the other device to a further key counter of the other device.
This may provide an advantage that, for example, the second key or the key updated protocol may be securely communicated to the other device. Moreover, the ACK message may be received, which may confirm that the second key or the key updated protocol is received by the respective IoT node. A second aspect of the disclosure provides a device for IoT, the device comprising a first key of the device, wherein the first key is valid for a first time period, wherein the device is configured to, send a message to a server device, the message indicating a request for an update of the first key of the device, and receive a message from the server device, the message indicating a second key of the device, wherein the second key is valid for a second time period.
The device of the second aspect may be, or may be incorporated in, for example, an IoT device, an IoT node, a client device, etc. The server device may be, or may be incorporated in, for example, an IoT server.
The device for IoT may comprise a storage unit which may store the first key of the device. Furthermore, the device may support an Advanced Encryption Standard (AES) module.
The device may comprise a circuitry. The circuitry may comprise hardware and software. The hardware may comprise analog or digital circuitry, or both analog and digital circuitry. In some embodiments, the circuitry comprises one or more processors and a non-volatile memory connected to the one or more processors. The non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein.
In an implementation form of the second aspect, the device is further configured to verify an authentication of the received message from the server device, and retrieve the second key of the device.
This may enable the device to securely retrieve the second key. For example, the device may verify the received message. Moreover, the second key that is indicated in the received message may be retrieved by the device.
For example, the device may use a pseudo-random function (PRF) to derive keys. The PRF may have the property that if the secret key is unknown to the attacker, the output is close to uniformly random in the attacker’s view.
For example, the device may use PRF such as a pseudo-random function F= (FKGen, PRF) comprising two algorithms of FKGen and PRF described as follows.
$
• F.FKGen(lK ) ® k. A non-deterministic key generation algorithm FKGen() that takes the security parameter lKas the input and outputs the secret key k. • F.PRF(k, x) = y. A PRF evaluation algorithm PRF() that takes the secret key k and the data x as the input and outputs an image y.
In a further implementation form of the second aspect, the device is further configured to send to the server device, via a communication channel, one or more of:
• an identifier of the device,
• a first random number,
• a first key counter of the device.
This may provide an advantage that, for example, the security of the KMS may be increased. Moreover, the risk of attack surface may be decreased. For example, the device may send its identifier, the first random number and the first key counter to the server device. Moreover, the server device may generate the first key and/or the second key for the device, e.g., based on its identifier, etc.
In a further implementation form of the second aspect, the received message comprises one or more of:
• a second random number,
• a cipher-text,
• a MAC tag message.
This may enable the device to securely receive the second key. For example, the server device may generate the second key. Furthermore, the server device may use a symmetric cryptography and may further generate the cipher-text. Moreover, the device (IoT node) may obtain the cipher text and may decrypt it, and may further retrieve the second key. Hence, the second key may be received in a secure communication manner.
In a further implementation form of the second aspect, the device is further configured to calculate a first MAC key, based on the first key of the device, and verify an authentication of the MAC tag message of the received message, based on the first MAC key. For example, the device may receive the message comprising the MAC tag message. Moreover, the device may verify an authentication of the MAC tag message of the received message. Moreover, for example, after that the authentication of the MAC tag message is verified, the device (IoT node) may retrieve the second message. This may further increase the security of the KMS.
In a further implementation form of the second aspect, the device is further configured to calculate a first temporary transport key, based on the first key of device, and retrieve the second key of the device based on a decryption of the cipher-text using the first temporary transport key.
This may enable the device to securely retrieve the second key. For example, the device may calculate the first temporary transport key, based on the first key of device. Moreover, the first temporary transport key may be used for decrypting the cipher-text indicating the second key. Furthermore, the second key may be retrieved.
This may provide an advantage that, for example, a simple and flexible key hierarchy may be provided.
In a further implementation form of the second aspect, the device is further configured to generate an ACK message, based on the first MAC key, and send the ACK message to the server device.
A third aspect of the disclosure provides a method for supporting a KMS for IOT, the method comprising receiving a message from an other device, the message indicating a request for an update of a first key of the other device, generating the first key for the other device, wherein the first key is valid for a first time period, based on a master secret key, generating a second key for the other device, wherein the second key is valid for a second time period, based on the master secret key, and sending a message indicating the second key, to the other device.
In an implementation form of the third aspect, the method further comprises receiving, from the other device, via a communication channel, one or more of:
• an identifier of the other device, • a first random number,
• a first key counter of the other device.
In a further implementation form of the third aspect, the sent message further comprises one or more of:
• a second random number,
• a cipher-text,
• a MAC tag message.
In a further implementation form of the third aspect, the method further comprises generating the first key for the other device based further on the identifier of the other device and the first key counter of the other device.
In a further implementation form of the third aspect, the method further comprises generating the second key for the other device based further on the identifier of the other device and a second key counter of the other device.
In a further implementation form of the third aspect, the method further comprises determining a first temporary transport key based on the first key of the other device, and generating the cipher-text by encrypting the second key with the first temporary transport key.
In a further implementation form of the third aspect, the method further comprises determining a first MAC key, based on the first key of the other device, and generating the MAC tag message based on authenticating the cipher-text with the first MAC key.
In a further implementation form of the third aspect, the method further comprises receiving, from the other device, an ACK message, and updating, upon a successful verification of the ACK message, a key counter of the other device to a further key counter of the other device.
The method of the third aspect achieves the advantages and effects described for the server device of the first aspect. A fourth aspect of the disclosure provides a method for a device for IOT, the device comprising a first key of the device, wherein the first key is valid for a first time period, wherein the method comprising sending a message to a server device, the message indicating a request for an update of the first key of the device, and receiving a message from the server device, the message indicating a second key of the device, wherein the second key is valid for a second time period.
In an implementation form of the fourth aspect, the method further comprises verifying an authentication of the received message from the server device, and retrieving the second key of the device.
In a further implementation form of the fourth aspect, the method further comprises sending to the server device, via a communication channel, one or more of:
• an identifier of the device,
• a first random number,
• a first key counter of the device.
In a further implementation form of the fourth aspect, the received message comprises one or more of:
• a second random number,
• a cipher-text,
• a tag message.
In a further implementation form of the fourth aspect, the method further comprises calculating a first MAC key, based on the first key of the device, and verifying an authentication of the MAC tag message of the received message, based on the first MAC key.
In a further implementation form of the fourth aspect, the method further comprises calculating a first temporary transport key, based on the first key of device, and retrieving the second key of the device based on a decryption of the cipher-text using the first temporary transport key. In a further implementation form of the fourth aspect, the method further comprises generating an ACK message, based on the first MAC key, and sending the ACK message to the server device.
The method of the fourth aspect achieves the advantages and effects described for the device of the second aspect.
A fifth aspect of the disclosure provides a computer program comprising a program code for performing the method according to the third aspect or the fourth aspect or any of their implementation forms.
A sixth aspect of the disclosure provides a non-transitory storage medium storing executable program code which, when executed by a processor, causes the method according to the third aspect or the fourth aspect or any of their implementation forms to be performed.
It has to be noted that all devices, elements, units and means described in the disclosure could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the disclosure as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.
BRIEF DESCRIPTION OF DRAWINGS
The above described aspects and implementation forms will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which FIG. 1 depicts a schematic view of a server device for supporting a KMS for IOT and a device for IOT, according to an embodiment of the disclosure;
FIG. 2 shows a key hierarchy for a single IoT node;
FIG. 3 shows a key hierarchy for multiple nodes;
FIG. 4 shows an exemplarily key update protocol; FIG. 5 an exemplarily key update protocol åNKUP based on PRF, MAC and a symmetric encryption;
FIG. 6 shows a computerized system for executing key update protocol åNKUP and maintaining key states;
FIG. 7 depicts a schematic view of a flowchart of a method for supporting a KMS for IoT, according to an example of the disclosure; and
FIG. 8 depicts a schematic view of a flowchart of a method for a device for IoT, according to an example of the disclosure.
DETAILED DESCRIPTION OF EMBODIMENTS FIG. 1 shows a schematic view of a server device 100 for supporting a KMS 101 for IoT and a device 200 for IoT, according to an embodiment of the disclosure.
The server device 100 may be an IoT server, and the device may be an IoT node. The KMS may be an IoT KMS.
The server device 100 for supporting the KMS 101 for internet of thing is configured to receive a message 201 from an other device 200, the message 201 indicating a request for an update of a first key 111 of the other device 200. The server device 100 is further configured to generate the first key 111 for the other device 200, wherein the first key 111 is valid for a first time period, based on a master secret key 110
The server device 100 is further configured to generate a second key 112 for the other device 200, wherein the second key 112 is valid for a second time period, based on the master secret key 110.
For example, the server device 100 may comprise a processor 120 which may generate the first key, the second key, etc.
The server device 100 is further configured to send a message 120 indicating the second key 112, to the other device 200.
The device 200 comprises a first key 111 of the device 200, wherein the first key 111 is valid for a first time period.
The device 200 is configured to send a message 201 to a server device 100, the message 201 indicating a request for an update of the first key 111 of the device 200.
The device 200 is further configured to receive a message 120 from the server device 100, the message 120 indicating a second key 112 of the device 200, wherein the second key 112 is valid for a second time period.
For example, the device 200 may comprise a processor 220 which may retrieve the first key, the second key, etc.
The server device 100 and/or the device 200 may comprise processing circuitry (not shown in FIG. 1) configured to perform, conduct or initiate the various operations of the device 100 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the server device 100 and/or the device 200 to perform, conduct or initiate the operations or methods described herein.
Next, the key hierarchies and the associated key update protocols will be discussed, with respect to FIG. 2, FIG. 3, FIG.4, and FIG. 5. Moreover, in the following it is assumed that the server device 200 is based on an IoT server comprising a KMS 101 that is based on an IoT KMS 101, and the device 200 is based on an IoT node.
FIG. 2 shows an exemplary key hierarchy for the device 200 (e.g., a single IoT node), from long term master secret key (ms) 110 protected by IoT KMS 101 to temporarily valid transport and MAC keys owned by the device 200.
The key hierarchy can be viewed from three planes. The key hierarchy shows the relation between different keys, and it also determines when or where a key update protocol is necessary, and it may guarantee a security of the keys.
The master secret key (ms) 110 may be a long-term secret owned by KMS 101 and may be used for deriving other keys. The master secret key 110 may be used to recover a node key or data key. On the other hand, the master secret key 110 may reside only at the server device 100, so that a dedicated high-security hardware can be used for protection. The first key 111 (node key kT) may be a middle-term key used by the device 200, and may be updated from time to time.
For example, the master secret key 110 may be used for deriving first key 111 (key ki for each device 200 (each IoT node) based on its identifier i and a version number CNT,· , where i and CNT, are public information.
As shown in FIG. 2, the solid arrow “ ” means that lower level keys can be derived from upper layer keys. More specifically, all the node keys comprising kT (the first key 111), and k 1 1 (the second key 112) may be derived from the master secret key 110, and the temporary transport key 212 (ktrans) and the temporary MAC key 211 (kmac) are derived from a current node key (the first key 111 or the second key 112). For example, the temporary transport key 212 (ktrans) and the temporary MAC key 211 (kmac) are derived from the first key 111. Moreover, the temporary transport key 222 (ktrans) and the temporary MAC key 221 (kmac) may be derived from the second key 112.
In this hierarchy, keys of different time periods do not computationally depend on each other. To ensure key independency similar to the forward secrecy, a key update protocol may be implemented that may run by the server device 100 (e.g., the IoT server comprising the KMS 101) and the device 200 (e.g., the IoT node).
FIG. 3 shows the key hierarchy for multiple nodes, i.e., in the spatial plane.
For example, the server device 200 comprising the KMS 101 may generate the first key 111 for the device 200 (a first node), based on the master secret key 110. Moreover, the temporary transport key 222 (ktrans) and the temporary MAC key 221 (kmac) for the device 200 (the first node), are derived from the first key 111.
Moreover, the server device 200 comprising the KMS 101 may generate the first key 301 for a second node, based on the master secret key 110. Moreover, the temporary transport key 312 (ktrans) and the temporary MAC key 311 (kmac) for the second node, are derived from the first key 301.
Furthermore, the server device 100 comprising the KMS 101 may generate the first key 302 for athird node, based on the master secret key 110. Moreover, the temporary transport key 322 (ktrans) and the temporary MAC key 321 (kmac) for the third node may be derived from the first key 302.
Moreover, the node keys that are derived from the master secret key 110 may be located on separate nodes. They may remain computationally independent and may be updated without considering the state of other nodes.
Reference is now made to FIG. 4, which shows an exemplarily key update protocol. In FIG. 4, a key update protocol åNKUP for node keys is shown, which can be viewed as a prototype for key updates in more complicated scenarios.
The key update protocol mainly works as follows, where three messages are then exchanged to perform the key update.
The update request, as the first message Mi, may be computed by the device 200 (IoT node). If the server device 200 (IoT KMS) confirms its validity, it may generate one or more new keys (e.g., the second key 112 for the device 200), may compute a response from chi, and may generate the new challenge di2.
A valid response in M2 may ensure that the device 200 (IoT node) is talking to the real server device 200 comprising the IoT KMS 101.
If the device 200 (IoT node) sends back a valid acknowledgement M3 computed from Mi, M2 and di2, the server device 200 comprising the IoT KMS 101 may confirm that the device 200 (IoT node) has obtained the second key 112, successfully.
Next, the key update protocol åNKUP will be discussed in detail. The request comprises essential identifiers. The challenges may be nounces Ni and N2. The acknowledgement may comprise a MAC value. (See FIG. 5).
FIG. 5 shows an exemplarily key update protocol åNKUP based on PRF, MAC and a symmetric encryption.
Moreover, before executing key updates, an initialization is necessary for provisioning initial shared secrets.
At 501, initialization: the server device 100 comprising the IoT KMS 101 is provisioned with the master secret key 110 and the device 200 (IoT node) has the first key (initial key ko). Other information, such as a counter value CNTo and the identifier pidi, has also been provisioned by the end of this phase. At 502, update at time t + 1, t > 0: the device 200 (IoT node identified by pidi) may select a random nonce Ni and sends Ni along with its request for key update. Note that, the device 200 (IoT node) holds the current key kT, x > 0.
Furthermore, upon receiving the request, the server device 100 comprising the IoT KMS 101 may recover the key kT for phase x and further derives the temporary transport key ktrans and MAC key kmac.
Moreover, the server device 100 comprising the IoT KMS 101 may generate the second key 112 (for example, by generating a new key for pidi), encrypt it with ktrans 212 and authenticate the ciphertext CTT +i with kmac 211. Then the CTT +i, a new nonce N2 and the MAC tag (macTi) may be sent to the device 200 (IoT node).
Furtherer, the device 200 (IoT node) may derive the temporary transport key ktrans 212 and MAC key kmac 211 from the current key kT (e.g., the first key 111). The device 200 (IoT node) may further verify the MAC tag (macTi), and the message. If the verification succeeds, the device 200 (IoT node) may retrieve the second key 112 by decrypting CT1+1. Afterwards, the device 200 (IoT node) may generate an acknowledge MAC tag macT2, as discussed above with respect to FIG. 4.
Moreover, upon receiving macT2, the server device 100 comprising the IoT KMS 101 may verify it, and may abort if the verification fails. Otherwise, the server device 100 may update the counter CNTT to the next value CNT1 +1.
The two random numbers N 1 and N2 may work as challenges for the peer.
Reference is now made to FIG. 6, which shows a computerized system for executing a key update protocol åNKUP and maintaining the key states.
The computerized system shown in FIG. 6 may be implemented in the server device 100 and/or the device 200.
The communication interfaces 601 are configured for exchanging messages with the intended peer(s). The message authentication codes (MAC) operator 602 is configured for tagging a message and checking a message with the provisioned secret.
The pseudo random function (PRF) operator 603 is configured for deriving keys from the identifier and the provisioned secret.
The encryption operator 604 is configured for encrypting new key materials in a reliable way.
The synchronization module 605 is configured for synchronizing states internally and with the peer. The synchronization module 605 may control the logic depending on the checking and decrypting results of the MAC) operator 602 and the encryption operator 604.
The synchronization module 605, when being implemented in the server device 100 may maintain all synchronization information of all nodes in the same KMS 101.
FIG. 7 shows a method 700 according to an embodiment of the disclosure for supporting a KMS 101 for IOT. The method 700 may be carried out by the sever device 100, as it is described above.
The method 700 comprises a step 701 of receiving a message 201 from another device 200, the message 201 indicating a request for an update of a first key 111 of the other device 200.
The method 700 further comprises a step 702 of generating the first key 111 for the other device 200, wherein the first key 111 is valid for a first time period, based on a master secret key 110.
The method 700 further comprises a step 703 of generating a second key 112 for the other device 200, wherein the second key 112 is valid for a second time period, based on the master secret key 110. The method 700 further comprises a step 704 of sending a message 120 indicating the second key 112, to the other device 200.
FIG. 8 shows a method 800 according to an embodiment of the disclosure for a device for IOT, the device comprising a first key 111 of the device 200, wherein the first key 111 is valid for a first time period. The method 800 may be carried out by the device 200, as it is described above.
The method 800 comprises a step 801 of sending a message 201 to a server device 100, the message 201 indicating a request for an update of the first key 111 of the device 200; and
The method 800 further comprises a step 802 receiving a message 120 from the server device 100, the message 120 indicating a second key 112 of the device 200, wherein the second key 112 is valid for a second time period.
The disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed disclosure, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

Claims
1. A server device (100) for supporting a key management system, KMS, (101) for internet of thing, IoT, the server device (100) being configured to: receive a message (201) from an other device (200), the message (201) indicating a request for an update of a first key (111) of the other device (200); generate the first key (111) for the other device (200), wherein the first key (111) is valid for a first time period, based on a master secret key (110); generate a second key (112) for the other device (200), wherein the second key (112) is valid for a second time period, based on the master secret key (110), and send a message (120) indicating the second key (112), to the other device (200).
2. The server device (100) according to claim 1, further configured to: receive, from the other device (200), via a communication channel, one or more of: - an identifier of the other device (200); a first random number; a first key counter of the other device (200 ).
3. The server device (100) according to claim 1 or 2, wherein: the sent message (120) further comprises one or more of: a second random number; a cipher-text; a message authentication code, MAC, tag message.
4. The server device (100) according to claim 2, wherein: the first key (111) for the other device (200) is generated based further on the identifier of the other device (200) and the first key counter of the other device (200).
5. The server device (100) according to one of the claims 2 to 4, wherein: the second key (112) for the other device (112) is generated based further on the identifier of the other device (200) and a second key counter of the other device (200).
6. The server device (100) according to one of the claims 3 to 5, further configured to: determine a first temporary transport key (212) based on the first key (111) of the other device (200); and generate the cipher-text by encrypting the second key (112) with the first temporary transport key (212).
7. The server device (100) according to one of the claims 3 to 6, further configured to determine a first message authentication code, MAC, key (211), based on the first key (111) of the other device (200); and generate the MAC tag message based on authenticating the cipher-text with the first MAC key (211).
8. The server device (100) according to one of the claims 1 to 7, further configured to: receive, from the other device (200), an acknowledgment, ACK, message; update, upon a successful verification of the ACK message, a key counter of the other device (200) to a further key counter of the other device (200).
9. A device (200) for internet of things, IoT, the device comprising a first key (111) of the device (200), wherein the first key (111) is valid for a first time period, wherein the device is configured to; send a message (201) to a server device (100), the message (201) indicating a request for an update of the first key (111) of the device (200); and receive a message (120) from the server device (100), the message (120) indicating a second key (112) of the device (200), wherein the second key (112) is valid for a second time period.
10. The device (200) according to claim 9, further configured to: verify an authentication of the received message (120) from the server device (100), and retrieve the second key (112) of the device.
11. The device (200) according to claim 9 or 10, further configured to: send to the server device (100), via a communication channel, one or more of: an identifier of the device (200); a first random number; a first key counter of the device (200).
12. The device (200) according to one of the claims 9 to 11, wherein: the received message (120) comprises one or more of: - a second random number; a cipher-text; a message authentication code, MAC, tag message.
13. The device (200) according to claim 12, further configured to: calculate a first message authentication code, MAC, key (311), based on the first key (111) of the device (200); and verify an authentication of the MAC tag message of the received message (120), based on the first MAC key (311).
14. The device (200) according to claim 12 or 13, further configured to: calculate a first temporary transport key (312), based on the first key (111) of device (200); and retrieve the second key (112) of the device (200) based on a decryption of the cipher-text using the first temporary transport key (312).
15. The device (200) according to one of the claims 13 or 14, further configured to: generate an acknowledgment, ACK, message, based on the first MAC key (311); and send the ACK message to the server device (100).
16. A method for supporting a key management system, KMS, for internet of thing, IoT, the method comprising: receiving a message (201) from an other device (200), the message (201) indicating a request for an update of a first key (111) of the other device (200); generating the first key (111) for the other device (200), wherein the first key (111) is valid for a first time period, based on a master secret key (110); generating a second key (112) for the other device (200), wherein the second key (112) is valid for a second time period, based on the master secret key (110), and sending a message (120) indicating the second key (112), to the other device (200).
17. A method for a device for internet of things, IoT, the device comprising a first key (111) of the device (200), wherein the first key (111) is valid for a first time period, wherein the method comprising: sending a message (201) to a server device (100), the message (201) indicating a request for an update of the first key (111) of the device (200); and receiving a message (120) from the server device (100), the message (120) indicating a second key (112) of the device (200), wherein the second key (112) is valid for a second time period.
18. A computer program product comprising instructions, which, when the program is executed by a computer, cause the computer to carry out the steps of the method of claim 16 or claim 17 to be performed.
PCT/EP2020/083847 2020-11-30 2020-11-30 Devices and methods for supporting key management system for internet-of-things WO2022111823A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202080107076.8A CN116458110A (en) 2020-11-30 2020-11-30 Apparatus and method for supporting key management system for internet of things
PCT/EP2020/083847 WO2022111823A1 (en) 2020-11-30 2020-11-30 Devices and methods for supporting key management system for internet-of-things

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2020/083847 WO2022111823A1 (en) 2020-11-30 2020-11-30 Devices and methods for supporting key management system for internet-of-things

Publications (1)

Publication Number Publication Date
WO2022111823A1 true WO2022111823A1 (en) 2022-06-02

Family

ID=73654809

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/083847 WO2022111823A1 (en) 2020-11-30 2020-11-30 Devices and methods for supporting key management system for internet-of-things

Country Status (2)

Country Link
CN (1) CN116458110A (en)
WO (1) WO2022111823A1 (en)

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DUAN LI LIDUAN@MAIL UPB DE ET AL: "Lightweight key management system for inter-node communication in IoT", PROCEEDINGS OF THE 10TH INTERNATIONAL CONFERENCE ON THE INTERNET OF THINGS, ACMPUB27, NEW YORK, NY, USA, 6 October 2020 (2020-10-06), pages 1 - 8, XP058478059, ISBN: 978-1-4503-8758-3, DOI: 10.1145/3410992.3411006 *

Also Published As

Publication number Publication date
CN116458110A (en) 2023-07-18

Similar Documents

Publication Publication Date Title
US10785019B2 (en) Data transmission method and apparatus
JP6515246B2 (en) Determination of common secrets for the secure exchange of information and hierarchical and deterministic encryption keys
US8670563B2 (en) System and method for designing secure client-server communication protocols based on certificateless public key infrastructure
JP5562687B2 (en) Securing communications sent by a first user to a second user
JP2019509648A (en) Secure multi-party loss-tolerant storage and transfer of cryptographic keys for blockchain-based systems in conjunction with wallet management systems
US11018866B2 (en) Dynamic second factor authentication for cookie-based authentication
EP2361462B1 (en) Method for generating an encryption/decryption key
US9130744B1 (en) Sending an encrypted key pair and a secret shared by two devices to a trusted intermediary
JP2011501585A (en) Method, system and apparatus for key distribution
US12010216B2 (en) Computer-implemented system and method for highly secure, high speed encryption and transmission of data
JPWO2019093478A1 (en) Key exchange device, key exchange system, key exchange method, and key exchange program
US11528127B2 (en) Computer-implemented system and method for highly secure, high speed encryption and transmission of data
CN109218251B (en) Anti-replay authentication method and system
TWI761243B (en) Encryption system and encryption method for group instant massaging
KR102350015B1 (en) Method and System for Authentication and Key Agreement through One Time Quantum Symmetric Key based on Elliptic Curve Diffie Hellman Algorithm
WO2022111823A1 (en) Devices and methods for supporting key management system for internet-of-things
KR20170087120A (en) Certificateless public key encryption system and receiving terminal
CN116599771B (en) Data hierarchical protection transmission method and device, storage medium and terminal
US20240129111A1 (en) Key exchange system, terminal, server, key exchange method, and program
JP6404958B2 (en) Authentication system, method, program, and server
WO2023027730A1 (en) Authentication
JP2018117388A (en) Authentication system, method and program, mobile device and server
JP2011109544A (en) Key exchange system, and key exchange method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20816955

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202080107076.8

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20816955

Country of ref document: EP

Kind code of ref document: A1