A design of the lightweight key management system for multi-level embedded devices
Publicado en línea: 16 dic 2022
Páginas: 1093 - 1104
Recibido: 07 nov 2022
Aceptado: 19 nov 2022
DOI: https://doi.org/10.2478/amns.2021.2.00319
Palabras clave
© 2022 Lei Wang et al., published by Sciendo
This work is licensed under the Creative Commons Attribution 4.0 International License.
Embedded devices are widely used, and it is predicted that there will be more than 25 billion connected devices worldwide by 2025 [1]. However, the embedded device itself has weak security protection capabilities, and the device is vulnerable to attacks from the physical level, resulting in more serious security threats to embedded device data. However, embedded devices are vulnerable to private data theft attacks, which can obtain sensitive data stored, transmitted or manipulated inside the embedded system. The main protection method to deal with such attacks is to use cryptography, which would involve the use of secure cryptographic algorithms and keys to encrypt important data for protection, and require the proper management of the keys [2]. The hypothesis of Kerckhoff [3] pointed out that only the secret key is really secret in the cryptosystem, and thus the key management determines the security of a cryptosystem.
Zhao et al. [4] used PUF technology [5] and PIN code for key generation, and used the TrustZone architecture for key management. Lu et al. [6] proposed a scheme of using embedded trusted hardware to store the master key. Zhao et al. [7] proposed a scheme to enhance the security of key generation by using a USB key, which improved the security of key generation and key storage. For the problem of key leakage, researchers have mentioned that the key multi-version and multi-index technology can be used to reduce the risk of key leakage [8, 9]. Liu et al. [10] designed a lightweight IoT device key management system scheme, but this scheme lacks a device authentication mechanism and cannot resist forgery attacks. Tan et al. [11] proposed a lightweight key management scheme for electric vehicle charging piles, which uses manual security to transmit and update keys, but this scheme is costly, complicated to operate and has poor portability.
In contrast with traditional PC and server facilities, most embedded devices have limited resources, relatively weak computing power and small storage capacity. Traditional key management solutions are not fully applicable to embedded devices. Therefore, it is of great significance to study the key management for embedded devices and design a safe and effective key management system.
Most embedded devices have layered characteristics when used. For example, in a smart home system, the home gateway controls the smart devices in the entire home and is responsible for communicating with the cloud server. In addition, most embedded devices also have the characteristics of fixed position and fixed communication object when in use. Combining the above characteristics, this paper constructs a multi-layer embedded device usage scenario model, as shown in Figure 1.
Fig. 1
Embedded device scenario model
In this model, devices on two adjacent layers can communicate with each other. For some scenarios with a relatively simple network structure, top devices can also communicate directly with the terminal unit. Adopting this model has the advantage of being easy to manage. The upper-layer device only needs to be responsible for the communication and control of the adjacent lower-layer devices, and does not need to maintain the devices in the entire network. In addition, the model also has the advantages of easy adjustment and expansion. When a new device is to be added, it can quickly become a leaf node or locate a new node according to requirements.
This part mainly considers key security and communication security. The key is the core of the encryption system and must be kept safe. Ensuring key security requires the confidentiality, integrity and availability of the key. The key must be stored securely to ensure that it cannot be obtained by attackers, and it must be updated regularly to prevent attackers from brute-forcing the key. Communication security must meet the confidentiality and reliability requirements for devices during the communication process. For example, key data need to be encrypted and transmitted to prevent attackers from eavesdropping on the communication process to obtain confidential information. Our aim in designing the present study is to ensure that key management system proposed herein satisfies the following security requirements:
Secure storage and distribution of keys Anti-man-in-the-middle attack, replay attack and counterfeit device attack Ensure forward safety and backward safety
Embedded devices usually have limited resources and can support limited computing, storage, and communication overhead, which requires key management solutions to be lightweight and efficient. Some traditional key management schemes, such as the public key management system, need to be managed by certificates and CAs, and the storage and communication overhead between nodes is often large; it is thus difficult to deploy these schemes in embedded device usage scenarios. This paper finally selects the symmetric key management system as the support, and introduces the advantages of the public key system to facilitate the management of symmetric keys, thereby ensuring the lightweight nature and security of the system.
During the use of the device, there will be problems such as loss, scrapping, loss reporting and retrieval. These special devices need to be managed through a blacklist mechanism. With the passage of time and the increase in the number of devices, the number of devices registered in the blacklist library will become very large, even exceeding the storage space. While dealing with large-scale blacklists, problems such as updating and synchronisation difficulties are typically encountered. Therefore, when designing the system, the problem of the larger blacklist should be considered, and a reasonable and effective mechanism should be instituted to control the numerical strength of blacklists, with the result that the stability of the system is ensured.
According to the characteristics of the scene model and combined with the idea of hierarchical key management, the lightweight hierarchical key system, as shown in Figure 2, is designed.
Fig. 2
Lightweight hierarchical key system
In this system, keys are divided into three layers: management key, service key and session key. The management key is located at the top layer of the system and is mainly used to encrypt and protect the service key, and also to protect the distribution process of the service key. The management key also provides the device authentication function, which is used to authenticate the identity of the operator when operating the device. The service key is located in the middle layer and is stored in the device. Each service application corresponds to a service key, which is used to encrypt and protect application data. At the same time, the service key also participates in the negotiation process of the session key. The session key is at the bottom and has a very short life cycle. It is generated at the beginning of the session and destroyed at the end of the session. The session key is used to encrypt and decrypt session communication data.
Based on the lightweight key system, the key management system, as shown in Figure 3, is designed. The system can be divided into four modules: key management module, key storage module, device management module and key negotiation module. The functions and features of each module will be explained separately.
Fig. 3
Key management system logical structure
The key management module is the main module of the system, responsible for key generation, distribution, update and destruction. The key management module includes an encryption engine. The encryptor is a hardware device specialised in cryptographic operations. The key generation and encryption and decryption operations are completed in the encryptor. The key management and key storage modules jointly complete operations such as key generation, storage and modification.
The key storage module is responsible for the secure storage of keys. Through this module, the key is encrypted and stored in the keystore in the form of ciphertext to ensure its security, and at the same time, the module also provides functions such as key query and retrieval to the outside world. The device ID represents the unique identification of the device, for example, the serial number of the chip can be used as the device ID. The upper-layer device ID refers to the identification of the upper-layer device of the device, and the key management centre calculates the service key of the lower-layer device according to the identification. The key version Ver represents the current version of the key. When the key is updated, the key version will be judged, and the key version will also be updated after the update is completed. The key database also includes fields such as the version number of the key and the public key information provided by the device during registration.
The device management module provides system configuration services, device blacklist management services and operator management services. The system needs to maintain a blacklist database for devices, and record lost and stolen devices in the blacklist. When a device wants to join a communication group, the system will first determine whether the device is in the blacklist database. If it is in the blacklist database, the device is prohibited from joining the communication, and otherwise normal business communication can be started.
The key negotiation module uses the service key to perform identity authentication on the device when negotiating the key, and the session key can be negotiated only after passing the authentication. The session key encrypts and protects the communication process, and is destroyed when the session process ends. When the next session process starts, the key negotiation module will be called again to generate the session key.
This part includes key generation, key storage, key distribution, key negotiation, key update and key destruction.
Three types of keys need to be generated in this system: management keys, service keys and session keys.
The management key is generated by the corresponding module in the device, and it is mainly used for the encryption protection of the service key, the secure transmission of the service key and the security authentication of the device. For symmetric management keys, a random number is generated and the result of hashing the random number as a key is stored, whereas for asymmetric management keys, a public–private key pair is generated as the management key.
The service key is used to protect the security of service data and also participate in the negotiation of the session key. In order to meet the requirements of being lightweight, the service key is in the form of a symmetric key and managed according to a tree-shaped key structure, and the sub-service key is dispersed from the root service key. The service key generation algorithm is as follows:
Session keys are used during the session cycle for encryption and decryption of communication data. The session key is negotiated by the devices of both parties at the beginning of the session, and when the session period ends, the session key is also destroyed.
Key storage is an important link in key management, since the security of the system is directly affected by whether or not the key is stored securely. The management key is mainly used in the local device, and thus it is mainly stored in the local device. It must be securely stored in the device; otherwise, the service and session keys will be leaked. For a device with a security module, the key can be stored in the module in plaintext, and an external calling interface can be provided.
Service keys are stored in devices and keystores. In the device, the service key is encrypted and stored by the key encryption key.
The session key is mainly used to encrypt and protect the communication data during the session. The session key has the shortest life cycle and only exists in the session cycle. Therefore, the session key does not need to be stored locally. The session key exists in the memory. After the session ends, the session key is destroyed from the memory.
After the key is generated, it needs to be sent to the target device through a secure channel, and the key information cannot be leaked during this process. The secure distribution of business keys can be achieved by means of key transmission keys, and the specific process is shown in Figure 4.
Fig. 4
Key transfer process
During the key transmission process, the key management centre retrieves the key database, and encrypts and stores the newly generated device service key information in the key store. The key transmission process uses the key transmission key to encrypt and protect the service key, which ensures the security of the key distribution process.
Key negotiation is mainly used to negotiate session keys. Communication data during a session is usually protected by session key encryption. The lifetime of the session key is very short, amounting to no more than a single session period. It is generated at the beginning of the session and destroyed at the end of the session. In this system, the negotiation of the session key is performed using the service key. Figure 5 shows the session key negotiation process between adjacent two-layer devices.
Fig. 5
Session key negotiation
The service key is used frequently, and thus the regular update period of the service key cannot be too long. The business layer key is updated in a top-down manner. When the upper-layer device receives the new key, it calculates the new key of the lower-layer device by combining the dispersion factor ID and version Ver. Then the upper-level device uses the old key to calculate the lower-level old key, and encrypts the new key. The upper-level device sends it to the lower-level device. The hash value of the version number is also sent with the key. The function of the hash value is to perform an integrity check on the key to ensure that the key is updated completely and reliably. The lower-layer device can obtain the new service key after decryption with the old service key, and perform key integrity detection in combination with the hash value. After it is ascertained as correct, the update completion response packet is sent to the upper-layer device to complete the key update.
The management key is used less frequently than the service key, and its update period can be appropriately longer than the service key update period. The update of the management key is done locally, and the corresponding key is regenerated by the device and stored locally. In this system, in order to better balance the update relationship between the service and management keys, an update-times counter is used to determine whether to update the management key. When the number of service key updates reaches the threshold, the management key is updated, and after the update, the counter is reset to zero, and the next round of counting starts.
When the device exits the working group, the key should be destroyed to prevent it from being leaked. For the management and service keys in the device, the related interface of the key module is called upon to destroy the key. At the same time, the key management module is responsible for deleting key-related information in the keystore.
The device management module in this system needs to cooperate with the blacklist to manage the devices, prevent illegal devices from entering the normal working group, and ensure the validity and legality of the devices. Therefore, the system also needs to consider the problem of blacklist management. With the accumulation of time, the capacity of the blacklist will become very large, which brings great challenges to the task of blacklist management and control. There have been multiple relevant studies on the enlargement of the blacklist. Malicious personnel use the card self-locking function to lock the device, thereby removing the device from the blacklist and reducing the number of blacklists [12]. In addition, Hu et al. [13] mentioned that the validity period of the device can be set; the validity period is written when the device is put into use, and the system will clear these blacklists when the validity period is exceeded without re-registration. Another study [14] proposed a blacklist processing mechanism for the campus card. By adding the registration expiration period to the campus card, the valid campus cards are regularly screened, and the invalid campus cards are removed from the blacklist, thereby reducing the blacklist library size. Alan and Birant [15] optimised the blacklist management mode of campus card one-card card, and introduced the batch number of the blacklist to prevent the same card from appearing multiple times in the blacklist, ensuring that the blacklist is in the latest version. In this system, a corresponding processing flow is designed for the loss, abnormality, recovery, scrapping and recycling of equipment, as shown in Figure 6.
Fig. 6
Device blacklist management process
When the device is lost, the device identification ID and expiration time are added to the blacklist library. After a device is restored, scrapped or recycled, it is not necessary for this device to have its position maintained in the blacklist, and accordingly, it is cleared from the blacklist. For devices with multiple records in the blacklist, only the latest operation record is kept. After the blacklist is updated, it is delivered to the terminal device.
In addition to the above process, the system introduces equipment validity period and equipment batch number to control the number of blacklists. Specifically, when the device is put to use from the factory, the validity period is written for the device. When the device is in use, the validity period should be checked, and the device that exceeds the validity period will refuse to communicate. During normal use, the device can automatically apply for the next validity period, thereby extending the use time of the device. Equipment that is not used normally or abnormal equipment will no longer be able to apply for the validity period, and the validity period will be exceeded after a period of time. For devices that have expired, the system can delete them from the blacklist library, thereby reducing the number of blacklists. The same batch of equipment is marked using the same batch number. When a batch of equipment needs to be replaced and withdrawn from use, the batch number of the concerned equipment can be deleted from the corresponding batch blacklist database, and only the batch blacklist will then be updated. The library is sufficient, thereby reducing the number of blacklists and the workload of updating and distributing the blacklist library.
In this system, the session key used by the device in the communication process is different each time, and the new session key cannot decrypt the historical session data packets, making the historical communication data packets invalid for this session process. In addition, in the negotiation process of the session key, the communication parties generate random numbers, and a new session key is obtained by generating a new random number each time, which ensures the freshness of the session key. Even if the attacker captures the data packets of a certain negotiation process, the next session key cannot be negotiated.
The service key transmission process uses the key transmission key for protection, and the public key
When the device requests the service key, the key centre will find the corresponding public key information according to the provided ID. If the attacker provides a fake ID or pretends to be another device, the public key information found by the key centre will also be wrong. Since the attacker does not have the corresponding private key, the service key cannot be decrypted.
In addition, the key update policy when the device joins and exits is set in this system. When a device joins or exits, the system will perform a key update operation, and the original key leaked in the device will not be able to participate in the encryption and decryption operations normally, thus ensuring the forward and backward security of the system.
The device needs to store the management key locally, and each service in the device corresponds to a service key. In this system, the upper-layer device does not need to store the key of the lower-layer device, but the device identification provided by the lower-layer device obtains its key through decentralised calculation. In this way, the storage overhead of the device can be effectively reduced and the resource utilisation rate can be improved. This system is more suitable for embedded devices with limited storage resources.
Communication overhead is very important for system performance and stability. This section analyses the key transmission, negotiation and update process based on the number of times of sending and receiving communication packets and the data size of communication packets.
There are three data packets in the key transmission process, and the data packet information is shown in Table 1. During the key distribution process, the amount of communication data is very small, which has little impact on the communication load of the network.
Communication overhead of key distribution process
| 3 | Request key command | Device ID | Ciphertext of |
There are four data packets in the key negotiation process, and the data packet information is shown in Table 2. Through analysis, the contents of the data packets in the negotiation process are ascertained to be mostly hash values and cipher texts; the length of the data packets in the negotiation process is relatively long, and the third data packet has the longest length. The communication overhead generated by the key negotiation process has a great impact on the network.
Communication overhead of key agreement process
| 4 | Request negotiation command | Ciphertext of device ID and random number | Ciphertext of device ID, random number and its hash | Ciphertext of random number and its hash |
There are also four data packets in the key update process, and the data packet information is shown in Table 3. Compared with the key negotiation process, the length of the data packet in the key update process is shorter, and accordingly the impact on the network load is lesser.
Communication overhead of key update process
| 4 | Key update command | Device ID and Ver of key version | New key, ciphertext and hash of the version | Complete the confirmation package |
This paper designs a lightweight key management scheme, and proposes an optimisation scheme for the management and control of the device blacklist. Compared with the traditional key management scheme, the lightweight embedded device key management system scheme designed in this paper has the following advantages:
It is more lightweight. This system is mainly based on symmetric key management, which avoids complicated public key management methods. The key calculation and update speed are fast. In this paper, the service key is managed by a tree structure, and the upper-layer device can quickly disperse the key of the lower-layer device. According to this feature, the upper-layer device can also quickly calculate the new key of the lower-layer device when the key is updated, so as to complete the encryption. Fast update of keys. It has a lower storage resource overhead. In this solution, the device only needs to store the key related to its own device, and does not need to store the keys of other devices, which reduces the storage overhead. In addition, the scheme has good scalability, and the device can quickly become a leaf node after joining, which greatly facilitates device management and key management.