Cryptographic Keys Generating and Renewing System for IoT Network Nodes—A Concept

Designers and users of the Internet of Things (IoT) are devoting more and more attention to the issues of security and privacy as well as the integration of data coming from various areas. A critical element of cooperation is building mutual trust and secure data exchange. Because IoT devices usually have small memory resources, limited computing power, and limited energy resources, it is often impossible to effectively use a well-known solution based on the Certification Authority. This article describes the concept of the system for a cryptographic Key Generating and Renewing system (KGR). The concept of the solution is based on the use of the hardware Trusted Platform Module (TPM) v2.0 to support the procedures of creating trust structures, generating keys, protecting stored data, and securing data exchange between system nodes. The main tasks of the system are the secure distribution of a new symmetric key and renewal of an expired key for data exchange parties. The KGR system is especially designed for clusters of the IoT nodes but can also be used by other systems. A service based on the Message Queuing Telemetry Transport (MQTT) protocol will be used to exchange data between nodes of the KGR system.


Introduction
System designers in which security issues are an important element often use cryptographic techniques to secure stored data and to secure data exchange between system components. The cryptographic algorithms available on the market can be divided into two classes: asymmetric key algorithms and symmetric key algorithms. Each of these classes has different properties and applications. System designers are forced to solve the dilemma of which algorithms to use in a case. In most situations, mixed solutions are used.
Asymmetrical cryptography is used to build trust structures, to sign messages forwarded, and to establish a secure connection with the other party to exchange data. Using asymmetrical cryptography, mechanisms for distribution of symmetric keys are constructed, e.g., according to the Diffie-Hellmann scheme [1]. Asymmetric cryptography is rather not used to encrypt large data, because these algorithms are characterized by a relatively large overhead in relation to encrypted data, are time consuming and resource consuming, and to ensure adequate cipher strength these keys must be relatively long.
Symmetric cryptography is more computationally effective and provides adequate cipher strength by using keys much shorter than asymmetric cryptography. It is estimated that similar and today acceptable cipher power can be obtained for asymmetric cryptography, e.g., RSA for a key length of 3072 bits and for symmetrical cryptography for a key length of 128 bits [2]-the key length difference is very visible. However, there is a significant problem with symmetric cryptography. It is a distribution of the key. For this purpose, asymmetrical algorithms are usually used to establish a connection and

•
Description of the concept of the KGR system intended for the safe distribution and renewal of cryptographic keys for sensor nodes, which are representatives of sensor node clusters formulating the security domain of sensor nodes [7,8]. These keys are designed to protect secure data exchange between domains. Within each secure domain, independent of the KGR system, trust structures are built and implemented mechanisms of data exchange protection and data storage protection. • A method of building trust between KGR system nodes and protecting the resources of each node of the KGR system. • A detailed description of the procedures and protocols for data exchange intended for: initiating the KGR system, preparing nodes for work, and registering the nodes in the KGR system as well as generating, renewing, and distributing keys.

•
Description of how to use the Trusted Platform Module (TPM) v2.0 hardware modules to support procedures for creating trust, protection of sensor node resources and securing data exchange in the KGR system.

•
Description of how to use the Message Queuing Telemetry Transport (MQTT) service to securely distribute data (including cryptographic keys) between KGR system nodes.

•
Evaluation of the solution resistance to the most common attacks on the sensor node network.
The rest of the article is organized as follows. Related work is the content of Section 2. Section 3 presents the concept of KGR system operation and data structures used by system nodes. Section 4 is devoted to a detailed description of the procedures necessary for the proper functioning of the KGR system. The security evaluation of the proposed system is presented in Section 5. The future work is the content of Section 6.

Related Work
In the era of the rapidly growing Internet of Things, a very big challenge is to ensure confidentiality, integrity, and accessibility, which are the main attributes of system security. A large degree of difficulty is compounded by the following facts: IoT nodes are very often mobile, have limited memory resources, computing power and power sources, limited communication link range, are usually very numerous, and operate in difficult environmental conditions and usually in an unattended environment. Security mechanisms based on cryptographic solutions are used to build the trust of cooperating parties and meet security requirements. The implementation of these mechanisms further increases the requirements in terms of memory size and computing power. A critical element of such solutions is the generation and renewal of cryptographic keys as well as the distribution of these keys to nodes exchanging the data. Well-known solutions for building trust and distribution of cryptographic keys can be used here, e.g., Certification Authorities, but in the case of devices with limited capabilities this approach will be effective in few cases.
Attempts to find a compromise between the requirements described above most often resulted in an approach in which a large network of sensor nodes was divided into groups of cooperating nodes for which group key management (GKM) was used as a key distribution mechanism. Keys distributed using GKM are usually shared by nodes forming one group. A very extensive analysis of GKM systems can be found in [11]. Dammak et al. in [11] analyze the properties of GKM systems due to their applications for: wireless body area networks (WBAN) [12], wireless sensor networks (WSN) [13][14][15], cloud computing [16], wireless IPv6 networks [17], and IoT [18][19][20]. They compare solutions for individual groups of GKM applications, taking into account many attributes, the most important of which are: key distribution schemes (i.e., centralized, decentralized, distributed [21]), cryptography type used (symmetric, asymmetric, polynomial, Attribute Based Encryption), forward and backward secrecy (the shared key must be updated when a new node joins the group or some node leaves the group), mutual key independence, existence of single point of failure, and scalability.

The Idea of KGR System Operation
The clients of the KGR system will be mobile sensor node networks. Each sensor node network forms one secure sensor node domain [7,8] in which data exchange is cryptographically secured. Security mechanisms implemented in this domain also ensure the generation and distribution of cryptographic keys inside the domain and cryptographic protection of the resources of each node.
One security domain of sensor nodes is formed by sensor nodes that are registered in the domain. Each sensor node, in addition to performing the normal sensor and/or actuator tasks, plays the role of Master or Replica in the domain. At a given moment, exactly one sensor node in a domain is an authority in the domain. This node acts as a Master. Its resources store up-to-date descriptions of the domain and descriptions of all sensor nodes of the domain as well as data necessary for domain node authentication.
The remaining sensor nodes of the domain play a Replica role. These nodes in their resources store a copy of the safe domain description obtained from the Master node. In the event of a failure of the sensor node acting as the Master, a special procedure for selecting a new Master node from among correctly functioning Replica nodes is launched.
One of the nodes of each domain (it may be either a Master or Replica sensor node) is designated for data exchange between such domains and acts as a Gateway for the domain. This node is a sink node for data originating from domain nodes, but also an emitter of data originating outside the domain for domain nodes. The gateway node is responsible for secure data exchange between domains and is the representative of the domain for the KGR system. For the KGR system, out of all security domain nodes, only the sensor node is important, which at the given moment acts as a Gateway in the security domain of the sensor nodes. In the KGR system, the source of cryptographic keys to protect data transmission will be a separate node (Key Distribution Node) to which the gateway nodes will have access. The way the domains cooperate with the key distribution node is shown in Figure 1.
There will be three types of nodes in the KGR system: • KS node (Key Server)-the node that is equivalent to the Key Distribution Node in Figure 1 and will be the source of the cryptographic keys; Sensors 2020, 20, 5012 5 of 31 • N1, N2, . . . N k nodes-the representative for domains for whom symmetrical keys will be created; • AC node-Authorization Centre-a server for two services: • The service for managing the resources of the KS node, and for adding new identifiers for the authorized N nodes in the resources of the KS node; • The service to prepare N k nodes for work.

The Method of Data Exchange in the KGR System
During one key generation operation, the KS node will prepare two symmetrical keys, NNSK and NNSKsign, which will be used by a pair of nodes-Nm and Nn. The NNSK key (Node to Node Security Key) will be used to encrypt data sent between the Nm and Nn nodes, and the NNSKsign (Node to Node Security Key for signing) key will be used to prepare the HMAC for transmitted data. The sequence of activities carried out during one key generation operation can be described as follows:


Node Nm sends to KS node a request to generate a pair of symmetric keys for Nm and Nn nodes;  Node KS generate NNSK and NNSKsign keys and temporarily stores them;  KS node sends the keys to Nm and Nn nodes;  Node Nn via KS node sends confirmation of key receipt to Nm node;  After sending the confirmation, KS node removes the NNSK and NNSKsign keys from its resources.
The sequence diagram for these activities is shown in Figure 2. The method of data exchange in the KGR system is shown in Figure 3.

The Method of Data Exchange in the KGR System
During one key generation operation, the KS node will prepare two symmetrical keys, NNSK and NNSKsign, which will be used by a pair of nodes-N m and N n . The NNSK key (Node to Node Security Key) will be used to encrypt data sent between the N m and N n nodes, and the NNSKsign (Node to Node Security Key for signing) key will be used to prepare the HMAC for transmitted data. The sequence of activities carried out during one key generation operation can be described as follows: • Node N m sends to KS node a request to generate a pair of symmetric keys for N m and N n nodes; • Node KS generate NNSK and NNSKsign keys and temporarily stores them; • KS node sends the keys to N m and N n nodes; • Node N n via KS node sends confirmation of key receipt to N m node; • After sending the confirmation, KS node removes the NNSK and NNSKsign keys from its resources.
The sequence diagram for these activities is shown in Figure 2. The method of data exchange in the KGR system is shown in Figure 3. Node Nn via KS node sends confirmation of key receipt to Nm node; • After sending the confirmation, KS node removes the NNSK and NNSKsign keys from its resources.
The sequence diagram for these activities is shown in Figure 2. The method of data exchange in the KGR system is shown in Figure 3.

Proposed KGR System for Mobile IoT Network
Considering the observations mentioned in the introduction and the fact that one of the parties to the data exchange may be a mobile IoT network node that has limited memory, and computational and energy resources, it was assumed that the designed system should meet the following assumptions:

•
The KGR system is a source of symmetric cryptographic keys generated using a high entropy random number generator (e.g., a quantum random number generator). • The KGR system is available on the Internet. • The KGR system only handles requests from authorized clients. • Data on authorized clients are provided to the KS node by the administrator of the KGR system.

•
On behalf of each client of the KGR system, there is one node that is the client's representative.

•
The client representative can be implemented in hardware, but there can also be a software component installed on a computer network node that has access to the KGR system.

•
Representatives of two clients applying for a new pair of shared cryptographic keys are the only nodes with which the KGR system exchanges data related to obtaining a common pair of symmetric keys only for these clients.

•
The MQTT protocol will be used to distribute cryptographic keys. • Sensitive data stored in the resources of each node are cryptographically protected.

•
Data transmission between nodes is protected by cryptography.

•
Each node uses the local trust structure.

•
Each node must be registered in the system before it can start normal working-registered nodes before they begin their activities must be authenticated.

•
The security mechanisms offered by the Trusted Platform Module (TPM) will be used to secure data resources and secure data exchange between elements of the KGR system and its clients. TPM is an implementation of a standard developed by the Trusted Computing Group [24,25]. This module is designed to hardware support the cryptographic procedures and protocols that can be used for securing data [2,26].

Key Exchange Domain (KED) Structure
Nodes of the KGR system will form the Key Exchange Domain (KED). There will be one KS

Proposed KGR System for Mobile IoT Network
Considering the observations mentioned in the introduction and the fact that one of the parties to the data exchange may be a mobile IoT network node that has limited memory, and computational and energy resources, it was assumed that the designed system should meet the following assumptions:

•
The KGR system is a source of symmetric cryptographic keys generated using a high entropy random number generator (e.g., a quantum random number generator). • The KGR system is available on the Internet. • The KGR system only handles requests from authorized clients. • Data on authorized clients are provided to the KS node by the administrator of the KGR system.

•
On behalf of each client of the KGR system, there is one node that is the client's representative.

•
The client representative can be implemented in hardware, but there can also be a software component installed on a computer network node that has access to the KGR system.

•
Representatives of two clients applying for a new pair of shared cryptographic keys are the only nodes with which the KGR system exchanges data related to obtaining a common pair of symmetric keys only for these clients.

•
The MQTT protocol will be used to distribute cryptographic keys. • Sensitive data stored in the resources of each node are cryptographically protected.

•
Data transmission between nodes is protected by cryptography.

•
Each node uses the local trust structure.

•
Each node must be registered in the system before it can start normal working-registered nodes before they begin their activities must be authenticated.

•
The security mechanisms offered by the Trusted Platform Module (TPM) will be used to secure data resources and secure data exchange between elements of the KGR system and its clients. TPM is an implementation of a standard developed by the Trusted Computing Group [24,25]. This module is designed to hardware support the cryptographic procedures and protocols that can be used for securing data [2,26].

Key Exchange Domain (KED) Structure
Nodes of the KGR system will form the Key Exchange Domain (KED). There will be one KS node, one AC node and many N-type nodes in the KED domain. The Broker node will act as a data exchange intermediary between these nodes. The KED domain structure is shown in Figure 4. One of the important elements that determines the correct use of the MQTT service is determining the content of the special string, which is called "topic". The task of the Broker node is to forward data published by one node with a given "topic" to the node that subscribes to messages with such "topic". The presented solution assumes that the content of individual "topic" strings will be randomly generated and known only for a pair of nodes that will exchange data with each other. In the further part of the study, these character strings will be marked as TOPICn, where n = 0, 1, 2, 3, 4. The description of the purpose of each topic is presented in the Table 1. Table 1. List of topics used by the nodes.

Topic
Node Purpose  TOPIC0 1  KS  for each N node for the first request during the registration procedure   TOPIC1  KS  for subsequent requests from the given N node during the registration  procedure  TOPIC2  N  for requests from KS node  TOPIC3mn  Nm  for requests from Nn node  TOPIC4mn Nm for publishing to Nn node 1 Only TOPIC0 has fixed "register" content, the content of other topics is randomly generated.
Depending on the demand and the available Trusted Platform Module (TPM) model, the N-type node can be implemented as:

•
An autonomous device equipped with a hardware TPM, which implements all the features defined in the specification TCG [24]; • An autonomous device equipped with a hardware TPM, which does not support the hardware features encryption/decryption, these modules do not support the encrypt/decrypt function (an example would be two hardware implementations, i.e., LetsTrust TPM 2.0 and Infineon Iridium SLx 9670 available on the market, according to their documentation, they do not support encryption/decryption functions); • An autonomous device equipped with a software simulator TPM, which implements all the features defined in the specification TCG [24]; • A program module that does not use the TPM module but provides the generation and renewal of cryptographic keys for the system of which it is representative.
The KGR system concept presented in the work is prepared for the case in which the TPM hardware modules used do not have the symmetric encryption/decryption function implemented. Therefore, symmetric encryption/decryption must be performed by software. An additional adverse effect of the lack of hardware encryption/decryption function is also the inability to use the "Key One of the important elements that determines the correct use of the MQTT service is determining the content of the special string, which is called "topic". The task of the Broker node is to forward data published by one node with a given "topic" to the node that subscribes to messages with such "topic". The presented solution assumes that the content of individual "topic" strings will be randomly generated and known only for a pair of nodes that will exchange data with each other. In the further part of the study, these character strings will be marked as TOPICn, where n = 0, 1, 2, 3, 4. The description of the purpose of each topic is presented in the Table 1. Table 1. List of topics used by the nodes.

Topic
Node Purpose TOPIC0 1 KS for each N node for the first request during the registration procedure TOPIC1 KS for subsequent requests from the given N node during the registration procedure TOPIC2 N for requests from KS node TOPIC3 mn N m for requests from N n node TOPIC4 mn N m for publishing to N n node 1 Only TOPIC0 has fixed "register" content, the content of other topics is randomly generated.
Depending on the demand and the available Trusted Platform Module (TPM) model, the N-type node can be implemented as:

•
An autonomous device equipped with a hardware TPM, which implements all the features defined in the specification TCG [24]; • An autonomous device equipped with a hardware TPM, which does not support the hardware features encryption/decryption, these modules do not support the encrypt/decrypt function (an example would be two hardware implementations, i.e., LetsTrust TPM 2.0 and Infineon Iridium SLx 9670 available on the market, according to their documentation, they do not support encryption/decryption functions); • An autonomous device equipped with a software simulator TPM, which implements all the features defined in the specification TCG [24]; • A program module that does not use the TPM module but provides the generation and renewal of cryptographic keys for the system of which it is representative.
The KGR system concept presented in the work is prepared for the case in which the TPM hardware modules used do not have the symmetric encryption/decryption function implemented. Therefore, symmetric encryption/decryption must be performed by software. An additional adverse effect of the lack of hardware encryption/decryption function is also the inability to use the "Key Derivation Function" function offered by the TPM module. The lack of this function means that in the NVRAM memory of the TPM module, instead of one "seed" string, two keys will have to be stored, which will be a specific pair, i.e., accordingly, a symmetric key for encrypting/decrypting data and a key for determining HMAC for these data.

The Concept of the Nodes Protection
It was assumed that KS node and N nodes would use their local trust structure. This structure will be used to provide protection for sensitive node data, build trust relationships between KED domain nodes, and to protect data exchange between KED domain nodes. For this reason, it is recommended that each of the KED domain nodes be equipped with the TPM v2.0 module. For this purpose, a hardware TPM v.2.0 was planned, implemented on the extension board attached to the sensor node board (e.g., Raspberry Pi).
TPM is the international standard for a secure crypto processor designed to secure hardware through integrated cryptographic keys. It can be implemented in software or in hardware. TPM typically implements multiple cryptographic algorithms (e.g., SHA-(256, 384, 512), HMAC, RSA (2048, 3072, 16384), ECC (256, 384, 521), and AES (128, 256)) and crypto primitives (e.g., a random number generator, key generation, a public-key cryptographic algorithm, a cryptographic hash function, a mask generation function, digital signature generation and verification, ECC-based Direct Anonymous Attestation, and symmetric-key algorithms). TPM enables the building of several hierarchies of cryptographic keys (platform, storage, and endorsement hierarchies) that can be used to build a local trust structure on each TPM-equipped node. The key hierarchy is built from asymmetric keys. At the top of each hierarchy, there is an asymmetric key, which for a given TPM chip is randomly generated only once, and its private part never leaves the TPM chip and is not readable. With this key, the next key in the hierarchy is secured, etc. Any key that is secured using the key hierarchy is not shared outside the TPM chip in an explicit form. All cryptographic operations with the use of these keys are performed inside the TPM chip. In the TPM module NVRAM, it is possible to safely store sensitive system data (e.g., cryptographic keys). The PCR (Platform Configuration Register) of TPM makes it possible to build a system for detecting unauthorized hardware and software modifications of the resources of the node where the TPM is installed.
Because KS and AC nodes will be nodes of the Internet and will not have restrictions in terms of memory size, computing power, and energy, the possibilities of the Certification Authority will be used to build trust relationships between them.
The local trust structure will be constructed based on one of the hierarchies offered by the TPM v.2.0 module (i.e., storage hierarchy) built from asymmetric keys (e.g., RSA2048 or ECC256). It is expected that the Storage Root Key (SRK) will be at the top of the hierarchy, and the next key will be the asymmetric node key ANK (Asymmetric Node Key) for signing other keys that will be used by the node. For the KS node, the second child of the SRK key will be the KEDK (Key Exchange Domain Key), which will be needed to create the trust relationship between the KS node and the other N-type nodes.

Characteristics of the KS Node
The KS node plays the most important role in the KGR system and is responsible for generating and renewing symmetric keys requested by N nodes and their safe distribution to the node requesting the key and its partner. The data that are necessary to perform these tasks can be divided into the following groups: • Local trust structure of the KS node; • The node's own data; • Data for storing node descriptions (KED domain node data) that can use the services offered by the KS node; • Temporarily stored data that contain cryptographic material created for nodes that are in the process of generating or renewing a symmetric key for those nodes.
It was assumed that this KS node's own data and its local trust structure will be stored in the TPM NVRAM installed on the node. KED domain description data and sensitive temporary data will be stored in the node's SD memory. All mentioned data will be cryptographically secured using TPM mechanisms. The data stored on the KS node are shown in Figure 5.
Individual data of the KS node include: • Asymmetric keys SRK, ANK, and KEDK which create local trust structure; • N_ID-sensor node identifier in the domain; • Keys: • NK (Node Key)-symmetric key for encrypting the data stored in local SD memory (the key is used only internally by this node); • NKsign-key for determining HMAC for data encrypted with the NK key (the key is known only to this node); • BA (Broker Address)-MQTT broker IP address; • TOPIC1-topic subscribed by KS in the MQTT service used to initiate the generation and renewal of session keys by N nodes, common to all registered N nodes (10-byte random string generated by the KS node).  Figure 5. Data stored on the KS node.
Data stored in SD memory of KS node: 1. File node_desc-stores data of KED domain nodes that can use the services offered by the KS node. One record in the file includes a description of one node. If only the N_ID and NTAG fields of a given record are filled, then the node status is "authorized to register". When all the description fields of the node are filled, the node is "registered". Each node description (except the N_ID field) is encrypted with the NK key. After encryption, the HMAC value is generated for the entire record using the NKsign key. Description of the record fields is as the following: • N_ID (Node ID)-identifier of the node authorized to register in the domain (random number 4 bytes long-field generated during the procedure of adding a new authorized node to the domain description); • NTAG (Node Tag)-tag for the node; SHA256 hash from the concatenation of the N_ID field, the public part of the KEDK key, and a double-byte field containing the node Data stored in SD memory of KS node: 1.
File node_desc-stores data of KED domain nodes that can use the services offered by the KS node. One record in the file includes a description of one node. If only the N_ID and NTAG fields of a given record are filled, then the node status is "authorized to register". When all the description fields of the node are filled, the node is "registered". Each node description (except the N_ID field) is encrypted with the NK key. After encryption, the HMAC value is generated for the entire record using the NKsign key. Description of the record fields is as the following: • N_ID (Node ID)-identifier of the node authorized to register in the domain (random number 4 bytes long-field generated during the procedure of adding a new authorized node to the domain description); • NTAG (Node Tag)-tag for the node; SHA256 hash from the concatenation of the N_ID field, the public part of the KEDK key, and a double-byte field containing the node description entry number in the node_desc file (field generated during the procedure of adding a new authorized node to the domain description); • NKSK (Node to Key server Security Key)-a symmetrical key for securing data exchange between a registered node and a KS node (field created during the node registration procedure); • NKSKsign-key for determining HMAC for data encrypted with the NKSK key (the key is only known for the node and KS node); • TOPIC2-topic subscribed by the N node in the MQTT service used to exchange data related to generating/renewing session key for N node (10-byte random string generated by the N node); • HMAC-HMAC value for the entire record, which is generated using the NKsign key.

2.
File gen_keys-temporarily stores the generated keys, i.e., from the moment they are generated until the confirmation of receipt of these keys by the nodes for which these keys were generated. Each record of the file (except the N_ID1 and N_ID2 fields) is encrypted with the NK key. After encryption, the HMAC value is generated for the entire record using the NKsign key. Description of the record fields is as follows: • N_ID1-identifier of the node that sent the request to generate/renew the key for the pair of nodes N_ID1 and N_ID2; • N_ID2-identifier of the second node in the pair for which the key was generated/renewed; • TOPIC3-topic subscribed by N_ID1 in the MQTT service to receive data from the N_ID2 node; • TOPIC4-topic subscribed by N_ID2 in the MQTT service to receive data from the N_ID1 node.
Due to the fact that the KS node plays the most important role in the system and must be available at all times to system customers, it should be implemented rather as a stationary device that is powered from a constant power source and connected to an efficient Internet connection. The node should be properly configured from a security point of view and protected using tools such as a firewall, IDS/IPS systems, antivirus software, etc. Considering that clients may be different nodes of N-type, which will not necessarily have a commonly used Ethernet or Wi-Fi connection in the Internet, and most often will use other communication technologies specific to IoT networks, the KS node should be equipped with an additional device which will act as a gateway for other communication technologies, e.g., LoRa, Xbee, ZigBee, BLE etc.

Characteristics of N-Type Nodes
The clients of the cryptographic key generation and renewal service are N nodes. Each such node will store in its resources the necessary data to establish a connection and secure data exchange with the KS node, as well as the data necessary for secure data exchange with other N nodes. The data that are necessary to perform these tasks can be divided into the following groups: • Local trust structure of N node; • Node's own data; • Data on current session keys to secure data exchange with other N-type nodes.
It was assumed that this N node's own data and its local trust structure would be stored in the node's NVRAM of the TPM. Data about the current session keys will be stored in the node's SD memory. All mentioned data will be cryptographically secured using TPM mechanisms. These are the secure storage of data in the NVRAM of the TPM, the use of the HMAC hash generation function for each record in the SD memory, and the symmetric encryption/decryption feature that uses keys that are securely stored and shared by previously created hierarchies of keys. Data stored on the KS node are shown in Figure 6.
Individual data of the N node include: • Asymmetric keys SRK and ANK which create a local trust structure. • NTAG (Node Tag)-tag for the node; obtained from the AC node during the procedure of preparing the node for work in the KED domain. • N_ID-sensor node identifier; obtained from the AC node during the procedure of preparing the node for work in the KED domain. • BA (Broker Address)-MQTT broker IP address. • keys: • NK (Node Key)-symmetric key for encrypting the data stored in local SD memory (the key is used only internally by this node); • NKsign-key for determining HMAC for data encrypted with the NK key (the key is known only to this node); • NKSK (Node to Key server Security Key)-a symmetrical key for securing data exchange between a registered node and a KS node (known only for the given node and KS node); created during the procedure of registering the node in the KED domain; • NKSKsign-key for determining HMAC for data encrypted with the NKSK key (known only for the given node and KS node); created during the procedure of registering the node in the KED domain.
• TOPIC1-topic subscribed by KS in the MQTT service used to initiate the generation and renewal of session keys by N nodes, common to all registered N nodes. • TOPIC2-topic subscribed by node N in the MQTT service for exchanging data with the node KS related to generating/renewing session key. o NKsign-key for determining HMAC for data encrypted with the NK key (the key is known only to this node); o NKSK (Node to Key server Security Key)-a symmetrical key for securing data exchange between a registered node and a KS node (known only for the given node and KS node); created during the procedure of registering the node in the KED domain; o NKSKsign-key for determining HMAC for data encrypted with the NKSK key (known only for the given node and KS node); created during the procedure of registering the node in the KED domain.
• TOPIC1-topic subscribed by KS in the MQTT service used to initiate the generation and renewal of session keys by N nodes, common to all registered N nodes. • TOPIC2-topic subscribed by node N in the MQTT service for exchanging data with the node KS related to generating/renewing session key.  Data stored in SD memory of N node: 1. File ses_keys-stores data about valid symmetrical session keys to secure data exchange between a given node and a node with identifier N_ID. One record in the file includes a description of one session key. If the CTime field is zeroed, it means that the session key has not been generated yet or expired. Each session key description (except the N_ID and CTime fields) is encrypted with the NK key. After encryption, the HMAC value is generated for the entire record using the NKsign key. Description of the record fields is as follows: • N_ID (Node ID)-identifier of the target node for which the valid session key is NNSK; • NNSK (Node to Node Security Key)-a symmetrical key for securing data exchange Data stored in SD memory of N node: 1.
File ses_keys-stores data about valid symmetrical session keys to secure data exchange between a given node and a node with identifier N_ID. One record in the file includes a description of one session key. If the CTime field is zeroed, it means that the session key has not been generated yet or expired. Each session key description (except the N_ID and CTime fields) is encrypted with the NK key. After encryption, the HMAC value is generated for the entire record using the NKsign key. Description of the record fields is as follows: • N_ID (Node ID)-identifier of the target node for which the valid session key is NNSK; • NNSK (Node to Node Security Key)-a symmetrical key for securing data exchange between a given node and a node with the identifier N_ID (known only for the given node and node with the identifier N_ID); • NNSKsign-key for determining HMAC for data encrypted with the NNSK key (known only for the given node and node with the identifier N_ID); • TOPIC3-topic subscribed by the local node to receive data from the N_ID node; • TOPIC4-topic subscribed by node N_ID to receive data from the local node; • CTime (Creation Time of the key)-time stamp of the moment of obtaining the session key.
When developing the concept of the KGR system, small requirements were specified for N-type nodes. These nodes, to be clients of the KGR system, should have a communication link ensuring cooperation with the KS node. Regarding N nodes, the following assumptions were made [27]: • Node N is a class 1 (RAM << 10 KB and Flash << 100 KB) or class 2 device (RAM~10 KB and Flash~100 KB) constrained device; • Node N is powered by a class E1 energy source (i.e., "Period energy-limited", for example battery that is periodically recharged or replaced) or E2 ("Lifetime energy-limited", for example nonreplaceable primary battery).
This means that the N node can be a mobile device using a wireless link, has limited memory resources, limited computing power, and is powered from a limited capacity energy source.

Characteristics of the AC Node
It was assumed that the KS node would only support authorized N-type nodes. To accomplish this goal, it is necessary to provide the KS and N-type nodes with relevant data. The KS node will require the information on N-type nodes that will be entitled to cooperate with the KS node. For N-type nodes, you will need the credentials that will enable the initiation of cooperation between the given N node and the KS node. These activities define the main tasks of the AC node in the KGR system.
Due to the fact that the KGR system is designed to support systems that are very diverse in many respects, e.g., in terms of purpose, technology used, information processing method, method of protecting system resources, classification of processed data, organizational and national affiliation, etc., it is very difficult to define a uniform way of cooperation between such systems. Therefore, it was assumed that the process of initiating such cooperation must be based on organizational procedures that will be supported by the AC node. It is expected that AC node resources will store data that reflect these organizational processes. The specification of these processes is not the content of this study.
From the security point of view, the critical moment of initiating cooperation between systems will be the transfer of authentication data to N-type nodes (because they are constrained devices class 1 or 2), which will not be able to fully use the mechanisms of secure data exchange currently used in the Internet. These activities should be performed in a controlled and safe environment. Considering the above observations, it was assumed that the AC node will perform the following tasks: (a) Securely forwarding to the KS node a list of N nodes that will be entitled to use the service of the KGR system and obtaining from the KS node the data necessary to initiate cooperation of each of these nodes with the KS node. This data will include the identifier (N_ID) for N node and the tag (NTAG) for this node; (b) Securely forwarding the credentials prepared by the KS node to authorized N node. These data include the N_ID for N node and the NTAG for this node; (c) Secure transfer to the authorized N node of a list containing the identifiers of other N-type nodes with which the given node will be able to cooperate.
The manner of implementing the above tasks is not the content of the study. It is expected that the task described in item (a) will be able to be performed through the internet application using the HTTPS protocol or using the MQTT service. For the purposes of the study, it was assumed that the data that are the result of the task described in subsection (b) will be transferred via a text file containing one record, which will contain the authentication data for the N node (i.e., N_ID, NTAG and BA). Data that are the result of the task described in subsection (c) will also be transferred via a text file that will contain a list of identifiers of other N-type nodes with which the given node will be able to cooperate.

Procedures in the Key Exchange Domain
Building a secure system requires designing security solutions for the software and hardware configuration of all system components. An important element of these solutions is secure procedures for creating such a system and secure procedures for using such a system and decommissioning it. The following procedures are foreseen for the KGR system:

1.
The procedure for starting the Broker node; 2.
The procedure for initiating the KS node; 3.
The procedure for preparing the credentials for the N node; 4.
The procedure for initiating N node; 5.
The procedure for registration N node in the KED domain; 6.
Procedure for forwarding the list of authorized nodes to cooperation. 7.
The procedure for generating session keys consists of three stages: (a) Requesting the session key; Providing the session key to the destination node; (c) Confirmation of the delivery of the session key to the destination node.

8.
Procedure for secure data exchange between nodes.

9.
The procedure for renewing the session key consists of three stages: (a) Session key renewal request-includes the process of notifying the other party that the procedure has been initiated; Providing a renewed session key to the destination node; (c) Confirmation of the delivery of the renewed session key to the destination node.
The next part of the study contains descriptions of the procedures. In the above list, the procedure names that are described in detail, are marked in bold.

The Procedure for Starting the Broker Node
The Broker node acts as an intermediary in the exchange of data between nodes of the KGR system. Activities related to launching the MQTT service should be performed first when initiating the KGR system. It was assumed that the service must be configured so that data exchange between KGR system nodes is secured using the TLS (Transport Layer Security) mechanism. In addition, the network node on which the MQTT service operates should be properly configured from a security point of view in accordance with good practices in this field. Actions connected with launching the MQTT service are not the content of this study.

The Procedure for Initiating KS Node
The KS node initialization procedure is the first step that must be performed to start the KGR system. The purpose of this procedure is to create a local trust structure for the KS node (including asymmetric keys SRK, ANK, and KEDK) and create individual data for the node. These data include: node identifier N_ID, symmetric key NK and the accompanying NKsign key for securing data stored in the node's SD memory, MQTT broker address, and topic TOPIC1 which will be subscribed by the KS node in the MQTT service to generate or renew the session keys for N nodes. The last step of the procedure is to start subscription to the topic TOPIC0 and TOPIC1, which establishes the readiness of the KS node to work. The sequence diagram for the KS node initialization procedure and the data stored on the KS node after the procedure are shown in Figure 7 (the updated data are highlighted in yellow).
on which the MQTT service operates should be properly configured from a security point of view in accordance with good practices in this field. Actions connected with launching the MQTT service are not the content of this study.

The Procedure for Initiating KS Node
The KS node initialization procedure is the first step that must be performed to start the KGR system. The purpose of this procedure is to create a local trust structure for the KS node (including asymmetric keys SRK, ANK, and KEDK) and create individual data for the node. These data include: node identifier N_ID, symmetric key NK and the accompanying NKsign key for securing data stored in the node's SD memory, MQTT broker address, and topic TOPIC1 which will be subscribed by the KS node in the MQTT service to generate or renew the session keys for N nodes. The last step of the procedure is to start subscription to the topic TOPIC0 and TOPIC1, which establishes the readiness of the KS node to work. The sequence diagram for the KS node initialization procedure and the data stored on the KS node after the procedure are shown in Figure 7 (the updated data are highlighted in yellow).
(a) (b) Figure 7. The sequence diagram for the KS node initialization procedure (a) and the data stored on the KS node after the initialization procedure (b).

The Procedure for Preparing the Credentials for N Nodes
According to suggestions in the description of the AC node (Section 3.5.3), this procedure is not described here in detail. The AC node sends request to the KS node to prepare credentials for the given N node. The KS node generates the credentials and sends them to the AC node. The way the two nodes work together during this procedure is shown in Figure 8.

The Procedure for Preparing the Credentials for N Nodes
According to suggestions in the description of the AC node (Section 3.5.3), this procedure is not described here in detail. The AC node sends request to the KS node to prepare credentials for the given N node. The KS node generates the credentials and sends them to the AC node. The way the two nodes work together during this procedure is shown in Figure 8. The result of this procedure is the appearance of a new entry in the node_desc file stored in the resources of the KS node and a text file containing the credentials intended for given N node that have just been added to the resources of the KS node. An example of data stored on the KS node after the procedure is shown in Figure 9. (the updated data after adding the first node are highlighted in yellow). The result of this procedure is the appearance of a new entry in the node_desc file stored in the resources of the KS node and a text file containing the credentials intended for given N node that have just been added to the resources of the KS node. An example of data stored on the KS node after the procedure is shown in Figure 9. (the updated data after adding the first node are highlighted in yellow).
The result of this procedure is the appearance of a new entry in the node_desc file stored in the resources of the KS node and a text file containing the credentials intended for given N node that have just been added to the resources of the KS node. An example of data stored on the KS node after the procedure is shown in Figure 9. (the updated data after adding the first node are highlighted in yellow).

The Procedure for Initiating the N Node
The procedure for initiating the given N node aims to create a local trust structure for the N node (including asymmetric keys SRK and ANK), load the credentials obtained from the AC node, and create individual data for the node. Loaded data include: node tag NTAG and node identifier N_ID. Generated data include: symmetric key NK and the accompanying NKsign key for securing data stored in the node's SD memory, and topic TOPIC2, which will be subscribed by the given N node in the MQTT service during the procedure for registration the N node in the KED domain and the procedure of generating or renewing the session keys for the N node. In the last step, the IP address of the MQTT broker is loaded to the BA field. The way the AC node and the N node work together

The Procedure for Initiating the N Node
The procedure for initiating the given N node aims to create a local trust structure for the N node (including asymmetric keys SRK and ANK), load the credentials obtained from the AC node, and create individual data for the node. Loaded data include: node tag NTAG and node identifier N_ID. Generated data include: symmetric key NK and the accompanying NKsign key for securing data stored in the node's SD memory, and topic TOPIC2, which will be subscribed by the given N node in the MQTT service during the procedure for registration the N node in the KED domain and the procedure of generating or renewing the session keys for the N node. In the last step, the IP address of the MQTT broker is loaded to the BA field. The way the AC node and the N node work together during this procedure is shown in Figure 10. The sequence diagram for the procedure and the data stored on the N node after the procedure are shown in Figure 11 (the updated data after the initialization procedure for the N node are highlighted in yellow).
Sensors 2020, 20, x FOR PEER REVIEW 15 of 30 during this procedure is shown in Figure 10. The sequence diagram for the procedure and the data stored on the N node after the procedure are shown in Figure 11 (the updated data after the initialization procedure for the N node are highlighted in yellow).  Figure 10. The way the AC node and the N node work together during the procedure for initiating the N node.
(1) Generating local trust structure (SRK, ANK)  Figure 10. The way the AC node and the N node work together during the procedure for initiating the N node. route for N node credentials N1 N2 N k Figure 10. The way the AC node and the N node work together during the procedure for initiating the N node.
(a) (b) Figure 11. The sequence diagram for the N node initialization procedure (a) and the data stored on the KS node after the initialization procedure (b).

The Procedure for Registration N node in KED Domain
This procedure is intended to register the N node in the resources of the KS node and generate and transfer to the registered node the NKSK and NKSKSign keys to secure future data exchange between the given N node and KS node. Data from the N_ID, NTAG fields of the registered node, which this node obtained from the AC node in the node initialization procedure, and TOPIC2 field are encrypted using the contents of the NTAG field (the contents of this field will be used as a "one time password"). HMAC is determined for all sent data also using NTAG, and then the data are sent to the KS node. The KS node checks the authorization of the received request. If the KS node detects any abnormalities in the request, it ignores the request. These abnormalities include the following situations: in the KS resource, no description of the node that issued the request, an invalid NTAG, or an invalid HMAC hash.
In the next step, the KS node generates NKSK and NKSKsign keys for the registered node, completes the description of this node in the local file node_desc, and in response sends the generated keys supplemented with the field TOPIC1 to the registered node. The contents of the NTAG field of the node being registered is used to protect the response. The MQTT service is used during the registration procedure. The way the KS node and the N node work together during this procedure is shown in Figure 12. The sequence diagram of the procedure for the registration of the node in the domain is shown in Figure 13.   Figure 11. The sequence diagram for the N node initialization procedure (a) and the data stored on the KS node after the initialization procedure (b).

The Procedure for Registration N Node in KED Domain
This procedure is intended to register the N node in the resources of the KS node and generate and transfer to the registered node the NKSK and NKSKSign keys to secure future data exchange between the given N node and KS node. Data from the N_ID, NTAG fields of the registered node, which this node obtained from the AC node in the node initialization procedure, and TOPIC2 field are encrypted using the contents of the NTAG field (the contents of this field will be used as a "one time password"). HMAC is determined for all sent data also using NTAG, and then the data are sent to the KS node. The KS node checks the authorization of the received request. If the KS node detects any abnormalities in the request, it ignores the request. These abnormalities include the following situations: in the KS resource, no description of the node that issued the request, an invalid NTAG, or an invalid HMAC hash.
In the next step, the KS node generates NKSK and NKSKsign keys for the registered node, completes the description of this node in the local file node_desc, and in response sends the generated keys supplemented with the field TOPIC1 to the registered node. The contents of the NTAG field of the node being registered is used to protect the response. The MQTT service is used during the registration procedure. The way the KS node and the N node work together during this procedure is shown in Figure 12. The sequence diagram of the procedure for the registration of the node in the domain is shown in Figure 13.  Figure 12. The way the KS node and N node work together during the procedure for registration of the N node.

KS node N node
(1) Generate node registration request nksk_key_req (2) Generate keys: NKSK and Figure 12. The way the KS node and N node work together during the procedure for registration of the N node.
route for N node credentials N1 N2 N k Figure 12. The way the KS node and N node work together during the procedure for registration of the N node.
The result of the node registration procedure in the key exchange domain is the update of data in the KS node resources and the resources of the registered node. The contents of the KS node and the first registered node in the domain are shown in Figure 14 (the updated data after the registration procedure are highlighted in yellow). The result of the node registration procedure in the key exchange domain is the update of data in the KS node resources and the resources of the registered node. The contents of the KS node and the first registered node in the domain are shown in Figure 14 (the updated data after the registration procedure are highlighted in yellow).

N1
N2 N k Figure 12. The way the KS node and N node work together during the procedure for registration of the N node.
The result of the node registration procedure in the key exchange domain is the update of data in the KS node resources and the resources of the registered node. The contents of the KS node and the first registered node in the domain are shown in Figure 14 (the updated data after the registration procedure are highlighted in yellow). Detailed descriptions of the most important steps of the procedure (in Figure 13, the numbers in parentheses (e.g., (2)) preceding the descriptions indicate the numbers of the individual steps) are as follows: (1) Generate node registration request-a node registration request sent to the KS node is also a request to send the keys NKSK and NKSKsign, and string TOPIC1 back to the N node. Conduct the following: • Prepare the nksk_key_req packet containing the following data: N_ID, NTAG, and TOPIC2 of the registered N node (Figure 15). The packet is encrypted using the string from NTAG field, and NTAG is also used to determine the HMAC hash; • Publish a nksk_key_req packet using the topic TOPIC0.
the following: • Prepare the nksk_key_req packet containing the following data: N_ID, NTAG, and TOPIC2 of the registered N node (Figure 15). The packet is encrypted using the string from NTAG field, and NTAG is also used to determine the HMAC hash; • Publish a nksk_key_req packet using the topic TOPIC0.
N_ID -ID of N node NTAG -Node tag TOPIC2 -Topic will be subscribed by N node HMAC -Digital signature of the frame code "151" NTAG ( Figure 15. The node registration request frame. (2) Generate keys: NKSK and NKSKsign and update the N node description in the node_desc file. Conduct the following: • On the KS node, decrypt the data from the nksk_key_req packet using the NTAG from the description of the N_ID node and verify the correctness of the NTAG field from the packet.
If it is not correct, stop the procedure.

•
On the KS node, generate the keys NKSK with the initialization vector and NKSKsign, prepare the N node description, and then encrypt this description using the NK and the IV vector of the KS node, determine the HMAC using NKsign, and update the N node description in local file node_desc. The fields of the description should have the following values: N_ID = the content remains unchanged (the field is not encrypted); NTAG = the content remains unchanged; NKSK and IV = value generated by the KS node; NKSKsign = value generated by the KS node; TOPIC2 = TOPIC2 gathered from the nksk_key_req packet. • Publish a confirmation of registration to node N (nksk_key_ans packet in Figure 16) using topic TOPIC2 of registered node. The confirmation contains NKSK, IV, NKSKsign, TOPIC1. The fields are encrypted using the NTAG of the registered node, and for the encrypted blob, the HMAC is determined also using NTAG of the registered node. (2) Generate keys: NKSK and NKSKsign and update the N node description in the node_desc file. Conduct the following: • On the KS node, decrypt the data from the nksk_key_req packet using the NTAG from the description of the N_ID node and verify the correctness of the NTAG field from the packet.
If it is not correct, stop the procedure.

•
On the KS node, generate the keys NKSK with the initialization vector and NKSKsign, prepare the N node description, and then encrypt this description using the NK and the IV vector of the KS node, determine the HMAC using NKsign, and update the N node description in local file node_desc. The fields of the description should have the following values: N_ID = the content remains unchanged (the field is not encrypted); NTAG = the content remains unchanged; NKSK and IV = value generated by the KS node; NKSKsign = value generated by the KS node; TOPIC2 = TOPIC2 gathered from the nksk_key_req packet.

•
Publish a confirmation of registration to node N (nksk_key_ans packet in Figure 16) using topic TOPIC2 of registered node. The confirmation contains NKSK, IV, NKSKsign, TOPIC1. The fields are encrypted using the NTAG of the registered node, and for the encrypted blob, the HMAC is determined also using NTAG of the registered node. follows: (1) Generate node registration request-a node registration request sent to the KS node is also a request to send the keys NKSK and NKSKsign, and string TOPIC1 back to the N node. Conduct the following: • Prepare the nksk_key_req packet containing the following data: N_ID, NTAG, and TOPIC2 of the registered N node (Figure 15). The packet is encrypted using the string from NTAG field, and NTAG is also used to determine the HMAC hash; • Publish a nksk_key_req packet using the topic TOPIC0.
N_ID -ID of N node NTAG -Node tag TOPIC2 -Topic will be subscribed by N node HMAC -Digital signature of the frame  Figure 15. The node registration request frame.
(2) Generate keys: NKSK and NKSKsign and update the N node description in the node_desc file. Conduct the following: • On the KS node, decrypt the data from the nksk_key_req packet using the NTAG from the description of the N_ID node and verify the correctness of the NTAG field from the packet.
If it is not correct, stop the procedure.

•
On the KS node, generate the keys NKSK with the initialization vector and NKSKsign, prepare the N node description, and then encrypt this description using the NK and the IV vector of the KS node, determine the HMAC using NKsign, and update the N node description in local file node_desc. The fields of the description should have the following values: N_ID = the content remains unchanged (the field is not encrypted); NTAG = the content remains unchanged; NKSK and IV = value generated by the KS node; NKSKsign = value generated by the KS node; TOPIC2 = TOPIC2 gathered from the nksk_key_req packet.
NKSK -Node to Ker server Key + Initialization vector NKSKsign -Node to Ker server Security Key for signing TOPIC1 -Topic subscribed by KS node HMAC -Digital signature of the frame code "152" NKSK • Publish a confirmation of registration to node N (nksk_key_ans packet in Figure 16) using topic TOPIC2 of registered node. The confirmation contains NKSK, IV, NKSKsign, TOPIC1. The fields are encrypted using the NTAG of the registered node, and for the encrypted blob, the HMAC is determined also using NTAG of the registered node. (3) Acquire NKSK, NKSKsign, and TOPIC1. Conduct the following: • On the N node, decrypt received the nksk_key_ans packet using NTAG, save the received data in NVRAM of TPM. The data should have the following values: NKSK and IV = NKSK gathered from the nksk_key_ans packet; NKSKsign = NKSKsign gathered from the nksk_key_ans packet; TOPIC1 = TOPIC1 gathered from the nksk_key_req packet.
The contents of the N node after registration in the domain are shown on the right side of the Figure 14 (the updated data after the registration procedure are highlighted in yellow).
The sequence diagram of the data exchange in the MQTT service for the registration procedure of the N node in the domain is shown in the Figure 17. The contents of the N node after registration in the domain are shown on the right side of the Figure 14 (the updated data after the registration procedure are highlighted in yellow).
The sequence diagram of the data exchange in the MQTT service for the registration procedure of the N node in the domain is shown in the Figure 17.

Procedure for Forwarding the List of Authorized Nodes to Cooperation
This procedure requires N node cooperation with an AC node. Similarly to the procedure for preparing the credentials for N nodes (described in Section 0), this procedure is not described here in detail, but only the expected results of this procedure are given. The result of this procedure is the appearance of new, incomplete entries in the file ses_keys stored in the resources of the N node. These new records contain only identifiers and TOPIC3 (the remaining fields are empty) for other N-type nodes with which the given node is authorized to establish a common symmetrical session key with those nodes. The list of such nodes is the basis for the procedure for generating session keys, a description of this procedure is given in the Section 0. An example of data stored on the N node after the procedure in which two new nodes were added is shown in Figure 18 (the updated data after adding two identifiers are highlighted in yellow).

Procedure for Forwarding the List of Authorized Nodes to Cooperation
This procedure requires N node cooperation with an AC node. Similarly to the procedure for preparing the credentials for N nodes (described in Section 4.3), this procedure is not described here in detail, but only the expected results of this procedure are given. The result of this procedure is the appearance of new, incomplete entries in the file ses_keys stored in the resources of the N node. These new records contain only identifiers and TOPIC3 (the remaining fields are empty) for other N-type nodes with which the given node is authorized to establish a common symmetrical session key with those nodes. The list of such nodes is the basis for the procedure for generating session keys, a description of this procedure is given in the Section 4.7. An example of data stored on the N node after the procedure in which two new nodes were added is shown in Figure 18 (the updated data after adding two identifiers are highlighted in yellow). TOPIC1 = TOPIC1 gathered from the nksk_key_req packet.
The contents of the N node after registration in the domain are shown on the right side of the Figure 14 (the updated data after the registration procedure are highlighted in yellow).
The sequence diagram of the data exchange in the MQTT service for the registration procedure of the N node in the domain is shown in the Figure 17.

Procedure for Forwarding the List of Authorized Nodes to Cooperation
This procedure requires N node cooperation with an AC node. Similarly to the procedure for preparing the credentials for N nodes (described in Section 0), this procedure is not described here in detail, but only the expected results of this procedure are given. The result of this procedure is the appearance of new, incomplete entries in the file ses_keys stored in the resources of the N node. These new records contain only identifiers and TOPIC3 (the remaining fields are empty) for other N-type nodes with which the given node is authorized to establish a common symmetrical session key with those nodes. The list of such nodes is the basis for the procedure for generating session keys, a description of this procedure is given in the Section 0. An example of data stored on the N node after the procedure in which two new nodes were added is shown in Figure 18 (the updated data after adding two identifiers are highlighted in yellow).

The Procedure for Generating Session Keys
This procedure is intended to generate a new symmetric session key for a pair of N-type nodes (one element of the pair is a given node and the other element is another N-type node) and ensure secure transfer of the generated keys to another N node. The KS node is responsible for generating the session key and distributing it to the nodes concerned. The procedure consists of three stages:  The condition for the correct completion of the procedure is to register both nodes in the resources of the KS node before starting the procedure of generating the session key for these nodes. In the further description of the procedure, it was assumed that the key will be generated for the pair of N1 and N2 nodes. The designation N1 refers to a given node, which will initiate the session key generation procedure, and N2 refers to the second node from this pair of nodes. As a result of the procedure, the session key generated at the request of the N1 node and topics TOPIC3 and TOPIC4 will be securely transferred to the N1 and N2 nodes. Later, these topics will be used by the N1 and N2 nodes in the MQTT service during secure data exchange that will use the generated session key.
The way the KS node and the N node work together during this procedure is shown in Figure 19. The sequence diagram for the procedure is shown in Figure 20, and an example of the data stored on each N-type node after the procedure is shown in Figure 21 (the updated data after generating sessions key are highlighted in yellow). The content of data stored by the KS node after step (2) and after step (5) is shown in Figure 22. After completing the procedure, in the gen_keys file stored by the KS node, there is no longer the entry regarding the generated key.
(one element of the pair is a given node and the other element is another N-type node) and ensure secure transfer of the generated keys to another N node. The KS node is responsible for generating the session key and distributing it to the nodes concerned. The procedure consists of three stages: (a) Requesting the session key; (b) Providing the session key to the destination node; (c) Confirmation of the delivery of the session key to the destination node.
The condition for the correct completion of the procedure is to register both nodes in the resources of the KS node before starting the procedure of generating the session key for these nodes. In the further description of the procedure, it was assumed that the key will be generated for the pair of N1 and N2 nodes. The designation N1 refers to a given node, which will initiate the session key generation procedure, and N2 refers to the second node from this pair of nodes. As a result of the procedure, the session key generated at the request of the N1 node and topics TOPIC3 and TOPIC4 will be securely transferred to the N1 and N2 nodes. Later, these topics will be used by the N1 and N2 nodes in the MQTT service during secure data exchange that will use the generated session key. The way the KS node and the N node work together during this procedure is shown in Figure 19. The sequence diagram for the procedure is shown in Figure 20, and an example of the data stored on each N-type node after the procedure is shown in Figure 21 (the updated data after generating sessions key are highlighted in yellow). The content of data stored by the KS node after step (2) and after step (5) is shown in Figure 22. After completing the procedure, in the gen_keys file stored by the KS node, there is no longer the entry regarding the generated key.   secure transfer of the generated keys to another N node. The KS node is responsible for generating the session key and distributing it to the nodes concerned. The procedure consists of three stages:

KS
(a) Requesting the session key; (b) Providing the session key to the destination node; (c) Confirmation of the delivery of the session key to the destination node.
The condition for the correct completion of the procedure is to register both nodes in the resources of the KS node before starting the procedure of generating the session key for these nodes. In the further description of the procedure, it was assumed that the key will be generated for the pair of N1 and N2 nodes. The designation N1 refers to a given node, which will initiate the session key generation procedure, and N2 refers to the second node from this pair of nodes. As a result of the procedure, the session key generated at the request of the N1 node and topics TOPIC3 and TOPIC4 will be securely transferred to the N1 and N2 nodes. Later, these topics will be used by the N1 and N2 nodes in the MQTT service during secure data exchange that will use the generated session key. The way the KS node and the N node work together during this procedure is shown in Figure 19. The sequence diagram for the procedure is shown in Figure 20, and an example of the data stored on each N-type node after the procedure is shown in Figure 21 (the updated data after generating sessions key are highlighted in yellow). The content of data stored by the KS node after step (2) and after step (5) is shown in Figure 22. After completing the procedure, in the gen_keys file stored by the KS node, there is no longer the entry regarding the generated key.    Detailed descriptions of the most important steps of the procedure (in Figure 20, the numbers in parentheses (e.g., (2)) preceding the descriptions indicate the numbers of the individual steps) are as follows:

KS
(1) Generate session key request. Conduct the following:

•
Prepare the nnsk_key_req packet ( Figure 23) containing the following data: N_ID1, N_ID2, and topic TOPIC3 which will be subscribed by the N_ID1 node during secure data exchange with the N_ID2 node. The N_ID2 and TOPIC3 fields of the packet are encrypted using the NKSK of N_ID1 node, the HMAC is determined for all fields of the packet using the NKSKsign of the N_ID1 node; • Publish a nnsk_key req packet using the topic TOPIC1.   Detailed descriptions of the most important steps of the procedure (in Figure 20, the numbers in parentheses (e.g., (2)) preceding the descriptions indicate the numbers of the individual steps) are as follows: (1) Generate session key request. Conduct the following:

•
Prepare the nnsk_key_req packet ( Figure 23) containing the following data: N_ID1, N_ID2, and topic TOPIC3 which will be subscribed by the N_ID1 node during secure data exchange with the N_ID2 node. The N_ID2 and TOPIC3 fields of the packet are encrypted using the NKSK of N_ID1 node, the HMAC is determined for all fields of the packet using the NKSKsign of the N_ID1 node; • Publish a nnsk_key req packet using the topic TOPIC1. Detailed descriptions of the most important steps of the procedure (in Figure 20, the numbers in parentheses (e.g., (2)) preceding the descriptions indicate the numbers of the individual steps) are as follows: (1) Generate session key request. Conduct the following:

•
Prepare the nnsk_key_req packet ( Figure 23) containing the following data: N_ID1, N_ID2, and topic TOPIC3 which will be subscribed by the N_ID1 node during secure data exchange with the N_ID2 node. The N_ID2 and TOPIC3 fields of the packet are encrypted using the NKSK of N_ID1 node, the HMAC is determined for all fields of the packet using the NKSKsign of the N_ID1 node; • Publish a nnsk_key req packet using the topic TOPIC1.  Detailed descriptions of the most important steps of the procedure (in Figure 20, the numbers in parentheses (e.g., (2)) preceding the descriptions indicate the numbers of the individual steps) are as follows: (1) Generate session key request. Conduct the following:

•
Prepare the nnsk_key_req packet ( Figure 23) containing the following data: N_ID1, N_ID2, and topic TOPIC3 which will be subscribed by the N_ID1 node during secure data exchange with the N_ID2 node. The N_ID2 and TOPIC3 fields of the packet are encrypted using the NKSK of N_ID1 node, the HMAC is determined for all fields of the packet using the NKSKsign of the N_ID1 node; • Publish a nnsk_key req packet using the topic TOPIC1. (2) Generate keys: NNSK and NNSKsign and create a new entry in the gen_keys file. Conduct the following: • On the KS node, decrypt the data from the nnsk_key_req packet using the NKSK from the description of the N_ID1 node and verify the HMAC.

•
On the KS node, generate the keys NNSK with the initialization vector and NNSKsign, create the description of these keys, and then encrypt this description using the NK and the IV vector of the KS node; determine the HMAC using NKsign and append the keys description in local file gen_keys. The fields of the description should have the following values: N_ID1 = N_ID1 gathered from the nksk_key_req packet; N_ID2 = N_ID2 gathered from the nksk_key_req packet; NNSK and IV = value generated by the KS node; NNSKsign = value generated by the KS node; TOPIC3 = TOPIC3 gathered from the nksk_key_req packet; TOPIC4 = empty; HMAC = HMAC determined for all fields of the entry using NKsign key; CTime-time stamp of the operation; The fields NNSK, NNSKsign, TOPIC3, and TOPIC4 are encrypted using the NK key of the KS node.

•
Publish a response to the session key request frame to the N_ID1 node (nnsk_key_ans packet showed in Figure 24) using topic TOPIC2 of N1 node. The fields: N_ID1, N_ID2, NNSK, and NNSKsign are encrypted using the NKSK of N_ID1 node; the HMAC is determined for all fields of the packet using the NKSKsign of N_ID1 node.
Sensors 2020, 20, x FOR PEER REVIEW 21 of 30 (2) Generate keys: NNSK and NNSKsign and create a new entry in the gen_keys file. Conduct the following: • On the KS node, decrypt the data from the nnsk_key_req packet using the NKSK from the description of the N_ID1 node and verify the HMAC.

•
On the KS node, generate the keys NNSK with the initialization vector and NNSKsign, create the description of these keys, and then encrypt this description using the NK and the IV vector of the KS node; determine the HMAC using NKsign and append the keys description in local file gen_keys. The fields of the description should have the following values: N_ID1 = N_ID1 gathered from the nksk_key_req packet; N_ID2 = N_ID2 gathered from the nksk_key_req packet; NNSK and IV = value generated by the KS node; NNSKsign = value generated by the KS node; TOPIC3 = TOPIC3 gathered from the nksk_key_req packet; TOPIC4 = empty; HMAC = HMAC determined for all fields of the entry using NKsign key; CTime-time stamp of the operation; The fields NNSK, NNSKsign, TOPIC3, and TOPIC4 are encrypted using the NK key of the KS node.
• Publish a response to the session key request frame to the N_ID1 node (nnsk_key_ans packet showed in Figure 24) using topic TOPIC2 of N1 node. The fields: N_ID1, N_ID2, NNSK, and NNSKsign are encrypted using the NKSK of N_ID1 node; the HMAC is determined for all fields of the packet using the NKSKsign of N_ID1 node. • Publish a notification about the new session key to N_ID2 node (nnsk_not_req packet showed in Figure 25) using topic TOPIC2 of the N2 node. The fields: N_ID, NNSK, NNSKsign, and TOPIC3 are encrypted using the NKSK of N_ID2 node; the HMAC is determined for all fields of the packet using the NKSKsign of N_ID2 node.
N_ID -ID of requesting N node NNSK -Node to Node Security Key + Initialization Vector NNSKsign -Node to Node Security Key for signing  • Publish a notification about the new session key to N_ID2 node (nnsk_not_req packet showed in Figure 25) using topic TOPIC2 of the N2 node. The fields: N_ID, NNSK, NNSKsign, and TOPIC3 are encrypted using the NKSK of N_ID2 node; the HMAC is determined for all fields of the packet using the NKSKsign of N_ID2 node.
Sensors 2020, 20, x FOR PEER REVIEW 21 of 30 (2) Generate keys: NNSK and NNSKsign and create a new entry in the gen_keys file. Conduct the following: • On the KS node, decrypt the data from the nnsk_key_req packet using the NKSK from the description of the N_ID1 node and verify the HMAC.

•
On the KS node, generate the keys NNSK with the initialization vector and NNSKsign, create the description of these keys, and then encrypt this description using the NK and the IV vector of the KS node; determine the HMAC using NKsign and append the keys description in local file gen_keys. The fields of the description should have the following values: N_ID1 = N_ID1 gathered from the nksk_key_req packet; N_ID2 = N_ID2 gathered from the nksk_key_req packet; NNSK and IV = value generated by the KS node; NNSKsign = value generated by the KS node; TOPIC3 = TOPIC3 gathered from the nksk_key_req packet; TOPIC4 = empty; HMAC = HMAC determined for all fields of the entry using NKsign key; CTime-time stamp of the operation; The fields NNSK, NNSKsign, TOPIC3, and TOPIC4 are encrypted using the NK key of the KS node.
• Publish a response to the session key request frame to the N_ID1 node (nnsk_key_ans packet showed in Figure 24) using topic TOPIC2 of N1 node. The fields: N_ID1, N_ID2, NNSK, and NNSKsign are encrypted using the NKSK of N_ID1 node; the HMAC is determined for all fields of the packet using the NKSKsign of N_ID1 node. • Publish a notification about the new session key to N_ID2 node (nnsk_not_req packet showed in Figure 25) using topic TOPIC2 of the N2 node. The fields: N_ID, NNSK, NNSKsign, and TOPIC3 are encrypted using the NKSK of N_ID2 node; the HMAC is determined for all fields of the packet using the NKSKsign of N_ID2 node.
N_ID -ID of requesting N node NNSK -Node to Node Security Key + Initialization Vector NNSKsign -Node to Node Security Key for signing  (3) On N1 node-acquire keys: NNSK and NNSKsign and update the ses_key file. Conduct the following: • On the N1 node, decrypt the data from the nnsk_key_ans packet using the NKSK of the N1 node and verify the HMAC.

•
On the N1 node, update the entry for node N_ID2 in the ses_keys file based on the data from the received frame. The fields of the entry should have the following values: N_ID-should be the same as field N_ID2 from the received frame; NNSK and IV = NNSK gathered from the nnsk_key_ans packet; NNSKsign = NNSKsign gathered from the nnsk_key_ans packet; TOPIC3-should remain unchanged; TOPIC4 = empty; HMAC = HMAC determined for all fields of the entry using the NKsign key; The fields NNSK, NNSKsign, TOPIC3, and TOPIC4 are encrypted using NK key of the N1 node.
(4) On N2 node-acquire keys: NNSK and NNSKsign and update ses_key file. Conduct the following: • On the N2 node, decrypt the data from the nnsk_not_req packet using the NKSK of the N2 node and verify the HMAC.

•
On the N2 node, create the entry for node N_ID1 in ses_keys file based on the data from the received frame. The fields of the entry should have the following values: N_ID-N_ID gathered from the nnsk_not_req packet; NNSK and IV = NNSK gathered from the nnsk_not_req packet; NNSKsign = NNSKsign gathered from the nnsk_not_req packet; TOPIC-10-bytes string generated by the the N2 node; TOPIC4 = TOPIC3 gathered from the nnsk_not_req packet; HMAC = HMAC determined for all fields of the entry using the NKsign key; The fields NNSK, NNSKsign, TOPIC3, and TOPIC4 are encrypted using the NK key of the N2 node.

•
Publish response to notification about the new session key to KS node (nnsk_not_ans packet showed in Figure 26) using topic TOPIC1 of the KS node. The fields: N_ID2 and TOPIC4 are encrypted using the NKSK of the N_ID2 node; the HMAC is determined for all fields of the packet using the NKSKsign of N_ID2 node. (3) On N1 node-acquire keys: NNSK and NNSKsign and update the ses_key file. Conduct the following: • On the N1 node, decrypt the data from the nnsk_key_ans packet using the NKSK of the N1 node and verify the HMAC.

•
On the N1 node, update the entry for node N_ID2 in the ses_keys file based on the data from the received frame. The fields of the entry should have the following values: N_ID-should be the same as field N_ID2 from the received frame; NNSK and IV = NNSK gathered from the nnsk_key_ans packet; NNSKsign = NNSKsign gathered from the nnsk_key_ans packet; TOPIC3-should remain unchanged; TOPIC4 = empty; HMAC = HMAC determined for all fields of the entry using the NKsign key; The fields NNSK, NNSKsign, TOPIC3, and TOPIC4 are encrypted using NK key of the N1 node.
(4) On N2 node-acquire keys: NNSK and NNSKsign and update ses_key file. Conduct the following: • On the N2 node, decrypt the data from the nnsk_not_req packet using the NKSK of the N2 node and verify the HMAC.

•
On the N2 node, create the entry for node N_ID1 in ses_keys file based on the data from the received frame. The fields of the entry should have the following values: N_ID-N_ID gathered from the nnsk_not_req packet; NNSK and IV = NNSK gathered from the nnsk_not_req packet; NNSKsign = NNSKsign gathered from the nnsk_not_req packet; TOPIC-10-bytes string generated by the the N2 node; TOPIC4 = TOPIC3 gathered from the nnsk_not_req packet; HMAC = HMAC determined for all fields of the entry using the NKsign key; The fields NNSK, NNSKsign, TOPIC3, and TOPIC4 are encrypted using the NK key of the N2 node.
• Publish response to notification about the new session key to KS node (nnsk_not_ans packet showed in Figure 26) using topic TOPIC1 of the KS node. The fields: N_ID2 and TOPIC4 are encrypted using the NKSK of the N_ID2 node; the HMAC is determined for all fields of the packet using the NKSKsign of N_ID2 node. (5) Update gen_keys file. Conduct the following: • On the KS node, decrypt the data from the nnsk_not_ans packet using the NKSK from the description of the N_ID2 node and verify the HMAC.

•
On the KS node, update the description of the session key requested by the N_ID1 node in the gen_keys file. The fields of the description should have the following values: N_ID1-should be the same as field N_ID1 from the received frame; N_ID2-should be the same as field N_ID2 from the received frame; (5) Update gen_keys file. Conduct the following: • On the KS node, decrypt the data from the nnsk_not_ans packet using the NKSK from the description of the N_ID2 node and verify the HMAC.

•
On the KS node, update the description of the session key requested by the N_ID1 node in the gen_keys file. The fields of the description should have the following values: N_ID1-should be the same as field N_ID1 from the received frame; N_ID2-should be the same as field N_ID2 from the received frame; NNSK and IV-should remain unchanged; NNSKsign-should remain unchanged; TOPIC3-should remain unchanged; TOPIC4 = TOPIC4 gathered from nnsk_not_ans packet; HMAC = HMAC determined for all fields of the entry using NKsign key of the KS node; The fields N_ID2, NNSK, NNSKsign, TOPIC3, and TOPIC4 are encrypted using the NK key of the KS node. • Publish a session key confirmation request to the N1 node (nnsk_conf_req packet showed in Figure 27) using topic TOPIC2 of the N1 node. The fields: N_ID1, N_ID2, and TOPIC4 are encrypted using the NKSK of N_ID1 node; the HMAC is determined for all fields of the packet using the NKSKsign of N_ID1 node. • Publish a session key confirmation request to the N1 node (nnsk_conf_req packet showed in Figure 27) using topic TOPIC2 of the N1 node. The fields: N_ID1, N_ID2, and TOPIC4 are encrypted using the NKSK of N_ID1 node; the HMAC is determined for all fields of the packet using the NKSKsign of N_ID1 node. (6) Update ses_key file. Conduct the following: • On the N1 node, decrypt the data from the nnsk_conf_req packet using the NKSK of the N1 node and verify the HMAC.

•
On the N1 node, update the entry for node N_ID2 in the ses_keys file based on the data from the received frame. The fields of the entry should have the following values: N_ID-should be the same as field N_ID2 from the received frame; NNSK and IV-should remain unchanged; NNSKsign should remain unchanged; TOPIC3-should remain unchanged; TOPIC4 = TOPIC4 gathered from the nnsk_conf_req packet; HMAC = HMAC determined for all fields of the entry using the NKsign key; The fields NNSK, NNSKsign, TOPIC3, and TOPIC4 are encrypted using NK key of the N1 node. • Publish a response to session key confirmation request to SK node (nnsk_conf_ans packet showed in Figure 28) using topic TOPIC1 of the KS node. The field N_ID2 is encrypted using the NKSK of N_ID1 node, the HMAC is determined for all fields of the packet using the NKSKsign of the N_ID1 node.
(7) Delete NNSK data from gen_keys file. Conduct the following: • On the KS node, decrypt the data from the nnsk_conf_ans packet using the NKSK from the description of the N_ID1 node and verify the HMAC; • Delete the session key entry for the N_ID1 and N_ID2 node pair from the gen_keys file. (6) Update ses_key file. Conduct the following: • On the N1 node, decrypt the data from the nnsk_conf_req packet using the NKSK of the N1 node and verify the HMAC.

•
On the N1 node, update the entry for node N_ID2 in the ses_keys file based on the data from the received frame. The fields of the entry should have the following values: N_ID-should be the same as field N_ID2 from the received frame; NNSK and IV-should remain unchanged; NNSKsign should remain unchanged; TOPIC3-should remain unchanged; TOPIC4 = TOPIC4 gathered from the nnsk_conf_req packet; HMAC = HMAC determined for all fields of the entry using the NKsign key; The fields NNSK, NNSKsign, TOPIC3, and TOPIC4 are encrypted using NK key of the N1 node.

•
Publish a response to session key confirmation request to SK node (nnsk_conf_ans packet showed in Figure 28) using topic TOPIC1 of the KS node. The field N_ID2 is encrypted using the NKSK of N_ID1 node, the HMAC is determined for all fields of the packet using the NKSKsign of the N_ID1 node. • Publish a session key confirmation request to the N1 node (nnsk_conf_req packet showed in Figure 27) using topic TOPIC2 of the N1 node. The fields: N_ID1, N_ID2, and TOPIC4 are encrypted using the NKSK of N_ID1 node; the HMAC is determined for all fields of the packet using the NKSKsign of N_ID1 node. (6) Update ses_key file. Conduct the following: • On the N1 node, decrypt the data from the nnsk_conf_req packet using the NKSK of the N1 node and verify the HMAC.

•
On the N1 node, update the entry for node N_ID2 in the ses_keys file based on the data from the received frame. The fields of the entry should have the following values: N_ID-should be the same as field N_ID2 from the received frame; NNSK and IV-should remain unchanged; NNSKsign should remain unchanged; TOPIC3-should remain unchanged; TOPIC4 = TOPIC4 gathered from the nnsk_conf_req packet; HMAC = HMAC determined for all fields of the entry using the NKsign key; The fields NNSK, NNSKsign, TOPIC3, and TOPIC4 are encrypted using NK key of the N1 node. • Publish a response to session key confirmation request to SK node (nnsk_conf_ans packet showed in Figure 28) using topic TOPIC1 of the KS node. The field N_ID2 is encrypted using the NKSK of N_ID1 node, the HMAC is determined for all fields of the packet using the NKSKsign of the N_ID1 node.
(7) Delete NNSK data from gen_keys file. Conduct the following: • On the KS node, decrypt the data from the nnsk_conf_ans packet using the NKSK from the • On the KS node, decrypt the data from the nnsk_conf_ans packet using the NKSK from the description of the N_ID1 node and verify the HMAC; • Delete the session key entry for the N_ID1 and N_ID2 node pair from the gen_keys file.
The sequence diagram of the data exchange in the MQTT service for the procedure of generating the session keys for N1 and N2 nodes is shown in the Figure 29.
Sensors 2020, 20, x FOR PEER REVIEW 24 of 30 The sequence diagram of the data exchange in the MQTT service for the procedure of generating the session keys for N1 and N2 nodes is shown in the Figure 29.
N2 node (4) Figure 29. The sequence diagram of the data exchange in the MQTT service for the session key generation procedure.

Procedure for Secure Data Exchange between Nodes
The data exchange protocol between the N1 and N2 nodes for which session keys were generated depends on how the two nodes cooperate and is established outside the key generation/renewal system. This topic is not the content of the study. For this reason, to demonstrate the operation of the KGR system, a simple transmission of a 12-byte character string from node N1 to node N2 will be shown as well as sending a response frame. The way the N1 node and the N2 node work together during this experiment is shown in Figure 30. The sequence diagram for the procedure is shown in Figure 31.

Procedure for Secure Data Exchange between Nodes
The data exchange protocol between the N1 and N2 nodes for which session keys were generated depends on how the two nodes cooperate and is established outside the key generation/renewal system. This topic is not the content of the study. For this reason, to demonstrate the operation of the KGR system, a simple transmission of a 12-byte character string from node N1 to node N2 will be shown as well as sending a response frame. The way the N1 node and the N2 node work together during this experiment is shown in Figure 30. The sequence diagram for the procedure is shown in Figure 31. The sequence diagram of the data exchange in the MQTT service for the procedure of generating the session keys for N1 and N2 nodes is shown in the Figure 29.
N2 node (4) Figure 29. The sequence diagram of the data exchange in the MQTT service for the session key generation procedure.

Procedure for Secure Data Exchange between Nodes
The data exchange protocol between the N1 and N2 nodes for which session keys were generated depends on how the two nodes cooperate and is established outside the key generation/renewal system. This topic is not the content of the study. For this reason, to demonstrate the operation of the KGR system, a simple transmission of a 12-byte character string from node N1 to node N2 will be shown as well as sending a response frame. The way the N1 node and the N2 node work together during this experiment is shown in Figure 30. The sequence diagram for the procedure is shown in Figure 31.

N1 N2
credentials N k preparation procedure route for N node credentials Figure 30. The way the N1 node and the N2 node work together during the data exchanging.

N2 node N1 node
(1) Generate data packet node_data_req node_data_ans (2) Acquire data Figure 31. The sequence diagram for the procedure of exchanging data between nodes. Figure 31. The sequence diagram for the procedure of exchanging data between nodes.
Detailed descriptions of the most important steps of the procedure (in Figure 31, the numbers in parentheses (e.g., (2)) preceding the descriptions indicate the numbers of the individual steps) are as follows: (1) Generate data packet. Conduct the following:

•
Prepare the node_data_req packet ( Figure 32) containing the following data: N_ID1 (ID of sending node), N_ID2 (ID od destination node), and DATA. The N_ID2 and DATA fields of the packet are encrypted using the NKSK session key common for N_ID1 and N_ID2 nodes; the HMAC is determined for all fields of the packet using also common NNSKsign; Sensors 2020, 20, x FOR PEER REVIEW 25 of 30 Detailed descriptions of the most important steps of the procedure (in Figure 31. , the numbers in parentheses (e.g., (2)) preceding the descriptions indicate the numbers of the individual steps) are as follows: (1) Generate data packet. Conduct the following:

•
Prepare the node_data_req packet ( Figure 32) containing the following data: N_ID1 (ID of sending node), N_ID2 (ID od destination node), and DATA. The N_ID2 and DATA fields of the packet are encrypted using the NKSK session key common for N_ID1 and N_ID2 nodes; the HMAC is determined for all fields of the packet using also common NNSKsign;

•
Publish a node_data_req packet using the topic TOPIC3 subscribed by the N_ID2 node for exchange data session with N_ID1 node. (2) Acquire data. Conduct the following:

•
On the N2 node, decrypt the data from the node_data_req packet using the NNSK session key for a pair of nodes N1 and N2 and verify the HMAC.

•
Extract the data from the DATA field.

•
Publish a response to the data packet frame to the N_ID1 node (node_data_ans packet showed in Figure 33) using topic TOPIC3 subscribed by the N_ID1 node for exchange data session with the N_ID2 node. The field N_ID2 is encrypted using the NNSK session key for a pair of nodes N1 and N2, the HMAC is determined for all fields of the packet using common NKSKsign.
N_ID2 -ID of the response sending node N_ID1 -ID of the node that sent the message HMAC -Digital signature of the frame code "160" N_ID2 (2) (4) The sequence diagram of the data exchange in the MQTT service for the procedure of sending data from N1 node to N2 node is shown in the Generating session keys for N1 and N2

•
Publish a node_data_req packet using the topic TOPIC3 subscribed by the N_ID2 node for exchange data session with N_ID1 node.
(2) Acquire data. Conduct the following: • On the N2 node, decrypt the data from the node_data_req packet using the NNSK session key for a pair of nodes N1 and N2 and verify the HMAC.

•
Extract the data from the DATA field.

•
Publish a response to the data packet frame to the N_ID1 node (node_data_ans packet showed in Figure 33) using topic TOPIC3 subscribed by the N_ID1 node for exchange data session with the N_ID2 node. The field N_ID2 is encrypted using the NNSK session key for a pair of nodes N1 and N2, the HMAC is determined for all fields of the packet using common NKSKsign.
Sensors 2020, 20, x FOR PEER REVIEW 25 of 30 Detailed descriptions of the most important steps of the procedure (in Figure 31. , the numbers in parentheses (e.g., (2)) preceding the descriptions indicate the numbers of the individual steps) are as follows: (1) Generate data packet. Conduct the following:

•
Prepare the node_data_req packet ( Figure 32) containing the following data: N_ID1 (ID of sending node), N_ID2 (ID od destination node), and DATA. The N_ID2 and DATA fields of the packet are encrypted using the NKSK session key common for N_ID1 and N_ID2 nodes; the HMAC is determined for all fields of the packet using also common NNSKsign;

•
Publish a node_data_req packet using the topic TOPIC3 subscribed by the N_ID2 node for exchange data session with N_ID1 node. (2) Acquire data. Conduct the following:

•
On the N2 node, decrypt the data from the node_data_req packet using the NNSK session key for a pair of nodes N1 and N2 and verify the HMAC.

•
Extract the data from the DATA field.

•
Publish a response to the data packet frame to the N_ID1 node (node_data_ans packet showed in Figure 33) using topic TOPIC3 subscribed by the N_ID1 node for exchange data session with the N_ID2 node. The field N_ID2 is encrypted using the NNSK session key for a pair of nodes N1 and N2, the HMAC is determined for all fields of the packet using common NKSKsign.
N_ID2 -ID of the response sending node N_ID1 -ID of the node that sent the message HMAC -Digital signature of the frame code "160" N_ID2 (2) (4) The sequence diagram of the data exchange in the MQTT service for the procedure of sending data from N1 node to N2 node is shown in the Figure 34.  The sequence diagram of the data exchange in the MQTT service for the procedure of sending data from N1 node to N2 node is shown in the Figure 34.
N_ID2 -ID of the response sending node N_ID1 -ID of the node that sent the message HMAC -Digital signature of the frame code "160" N_ID2 (2) (4) The sequence diagram of the data exchange in the MQTT service for the procedure of sending data from N1 node to N2 node is shown in the Figure 34.

Data exchange
Generating session keys for N1 and N2 Figure 34. The sequence diagram of the data exchange in the MQTT service for the procedure of sending data from N1 node to N2 node. Figure 34. The sequence diagram of the data exchange in the MQTT service for the procedure of sending data from N1 node to N2 node.

The Procedure for Renewing the Session Keys
Each cryptographic key loses its validity and must be renewed, regardless of how the cryptographic key was generated, what the key was used for, or how it was stored. Too long using the same key makes it easier to guess by unauthorized persons. A separate and very important problem is determining the criterion of validity of the cryptographic key. As a measure of the "consumption" of the key, you can use the passage of time from the moment the key is generated, the number of data portions (e.g., frames) secured with the key, or the size of the data (calculated in bytes) secured with the key, etc. The KGR system does not provide mechanisms for determining the key renewal criterion, and these issues are not the content of the study. In contrast, the KGR system is ready to renew keys upon request of N-type nodes.
This procedure is intended to renew invalid symmetric session key for a pair of N-type nodes and ensure secure transfer of the generated keys to both N nodes. The KS node is responsible for generating a new session key and distributing it to the nodes concerned. The procedure consists of three stages: (a) Session key renewal request-includes the process of notifying the other party that the procedure has been initiated; (b) Providing a renewed session key to the destination node; (c) Confirmation of the delivery of the renewed session key to the destination node.
The KS node stores the generated keys during the key distribution process, and after sending the key to interested parties, all data related to this key are deleted from the resources of the KS node. From the KGR system point of view, the procedure for renewing the session key is very similar to the procedure for generating the session key. The only difference is that when generating a new key in the resources of N1 and N2 nodes, new entries are created in their ses_keys files containing the key attributes, and in the renewal procedure, the entries already exist but are filled with a new data.
During key renewal, the following fields are modified: NNSK and NNSKsign keys as well as TOPIC3 and TOPIC4 fields.
Because the session key generation procedure is described in detail in the Section 4.7, and due to the similarity of both procedures, the procedure for renewing the session key will not be described in detail here.

Security Evaluation
Comprehensive security solutions for secure implementation of the Internet of Things should include preventive, detective, and reactive measures [28]. In the concept of the KGR system attention has been paid to preventive measures. The goal is to prevent and obstruct a certain group of typical attacks. This does not mean that the concept completely omits the use of detective and reactive measures. Because the KGR system is mainly intended for IoT network nodes, which usually use wireless links to exchange data, the risks specific to such networks were considered in the security analysis. In most cases, sensor network nodes are unattended and can be an easy target for attack. For this reason, the following attacks will be considered: malicious sensor node injection (node replication attack), sensor impersonation (imitation), attacks on the information in transit, DoS attacks, and routing attacks [28]. The presented solution uses selected mechanisms offered by TPM to counteract these attacks. These include: securing cryptographic keys through a hierarchy of keys, creating a local trust structure, using PCR registers to detect attempts of unauthorized modification of data, software and hardware configuration of the sensor node, cryptographic protection of data stored in sensor node resources (in SD and NVRAM memory), and determining the value of the HMAC function for transmitted and stored data to ensure data integrity. The following sections also present what TPM mechanisms have been used for this purpose.

Node Replication Attack
The attack involves adding a cloned node to the network. For IoT nodes, this attack is relatively easy to perform when the node is unsecured. In the case of KGR system nodes, such an attack will not be possible, because the KS node and N-type nodes are equipped with TPM modules. Each TPM will use a symmetric SRK key that cannot be deleted or regenerated. This key is at the top of the key hierarchy, which creates a local trust structure. In this structure, each node has an ANK key, which is used to secure the cryptographic material stored in the node's resources and to secure the cryptographic keys of the node. It has been assumed that the creation of a local trust structure on a node is conditioned by passing credentials to the new node. The prepared node can only obtain this data in a secure and controlled area via the AC node. It should be recognized that such an attempt will not be possible by unauthorized persons. Another way could be to try to obtain an ASK key from a working node. However, this attempt requires unauthorized interference with the node's resources. These types of actions can be detected by the mechanism offered by the TPM module using its Platform Configuration Registers (PCR). If such actions are detected, then the node's software may take various actions, e.g., turning off the device, deleting sensitive data, informing other nodes about such an incident, as well as physical destruction of the node. These types of activities are not the content of this study.

Sensor Impersonation
Impersonation of the sensor is very difficult to perform. Before starting normal operation, its node identifier (N_ID) and special tag (NTAG) are set for each node. These node credentials are stored in the node's TPM resources and protected using TPM mechanisms. All these parameters are determined during the node preparation procedure and used during the domain registration procedure. The NTAG tag is of utmost importance. This tag is never passed in explicit form. Determining the value of this tag requires knowledge of the node identifier and other fields known only to the KS node.

Attack on Information in Transit
Data sent over wireless links are particularly susceptible to eavesdropping, modification, injection, interruption, and traffic analysis. The concept of the KGR system provides the use of authentication techniques and confidentiality and integrity checking of transmitted data. Each portion of data transferred will be supplemented with HMAC, which will use keys known only to individual pairs of nodes that exchange data. An additional safeguard, which is provided in the concept, is the generation of individual strings for topics used in the MQTT service. The content of each topic will also be known only for a pair of nodes that exchange data via the MQTT service. The distribution of these topics will take place during the secure distribution of cryptographic keys between nodes.

Denial of Service
DoS attack at the physical level and in the upper layers is beyond the scope of protection offered by mechanisms of the KGR system. To increase the system's resistance to these types of attacks, you should use all known methods of securing your network against such attacks.

Routing Attacks
Many attacks choose the WSN routing protocol as their target. Almost all such attacks, such as Selective Forwarding, Sybil Attack, Wormhole Attack, Sinkhole Attack, or False Routing Information, require the placement of a malicious node in the network or manipulation of an existing node. The possibilities of performing such attacks in the KGR system are very limited. The mechanisms described in Sections 5.1 and 5.2 counteract this.

Botnet Activities
Botnets are a significant threat to the IoT network. Botnets are designed to spread infection to misconfigured devices and then attack the target node after receiving the appropriate command from the person controlling the bot. An example of such a bot is Mirai malware [29]. Solutions proposed in the concept of the KGR system ensure resistance to the injection of bots by protecting its resources using the PCR registers of the TPM module. These issues are not considered in the study.

Implementation
The presented concept has not yet been fully verified. However, attempts were made to examine a very simple version of the cryptographic key generation system that met the selected requirements described at the beginning of Section 3.1. The design and demonstrator of this version were described in [30]. The prepared demonstrator included three N-type nodes (N1, N2, and N3), a KS node, and an MQTT broker node (AC node not implemented). All nodes were implemented using the Raspberry Pi 3 Model B board. Nodes N1, N2, and N3 and the KS node were additionally equipped with a LetsTrust TPM module containing the Infineon Optiga ™ SLB 9670 TPM 2.0 chip and 32GB SD memory ( Figure 35). OASIS MQTT Version 3.1.1 was used to support the MQTT protocol. An Ethernet interface was used for data exchange. The structure of the demonstrator is shown in the Figure 36. The demonstrator software was prepared with the use of Python and the IBM TSS 1470 library.

Botnet Activities
Botnets are a significant threat to the IoT network. Botnets are designed to spread infection to misconfigured devices and then attack the target node after receiving the appropriate command from the person controlling the bot. An example of such a bot is Mirai malware [29]. Solutions proposed in the concept of the KGR system ensure resistance to the injection of bots by protecting its resources using the PCR registers of the TPM module. These issues are not considered in the study.

Implementation
The presented concept has not yet been fully verified. However, attempts were made to examine a very simple version of the cryptographic key generation system that met the selected requirements described at the beginning of Section 0. The design and demonstrator of this version were described in [30]. The prepared demonstrator included three N-type nodes (N1, N2, and N3), a KS node, and an MQTT broker node (AC node not implemented). All nodes were implemented using the Raspberry Pi 3 Model B board. Nodes N1, N2, and N3 and the KS node were additionally equipped with a LetsTrust TPM module containing the Infineon Optiga ™ SLB 9670 TPM 2.0 chip and 32GB SD memory (Figure 35). OASIS MQTT Version 3.1.1 was used to support the MQTT protocol. An Ethernet interface was used for data exchange. The structure of the demonstrator is shown in the Figure 36. The demonstrator software was prepared with the use of Python and the IBM TSS 1470 library. The conclusions of the experiments were the basis for developing the presented concept and specifying the requirements for the system, which in addition to generating cryptographic keys should give the opportunity to renew the keys. Particular attention was paid to refining secure data exchange in all phases of the system life cycle. The conclusions of the experiments were the basis for developing the presented concept and specifying the requirements for the system, which in addition to generating cryptographic keys should give the opportunity to renew the keys. Particular attention was paid to refining secure data exchange in all phases of the system life cycle.

Future Work
Future work will be focused on the implementation of the presented system and its testing. I predict that in the first stage of testing, the correctness of the solutions presented in the concept will be verified, and in the second stage, penetration tests for the system and testing of system resistance to various attacks will be performed. Further research stages will include the use of the KGR system for the secure exchange of data between secure domains of sensor nodes [7,8] and the extension of N-node preparation procedures for the case of hardware TPM v2.0, which implements all the features defined in the specification [25].
Funding: This research received no external funding. The funders had no role in the design of the study; in the collection, analyses, or interpretation of data; in the writing of the manuscript, or in the decision to publish the results.