Abstract
Internet of Things (IoT) technologies allow everyday objects to be capable of connecting to the Internet, thereby making smart and convenient daily life. Although users' daily lives can be convenient due to various smart services utilizing IoT, it can also be a target of attack through the Internet. Thus, security has now been recognized as mandatory technology to activate IoT based smart service. Several standard organizations related to IoT technologies recommend using the CoAP over DTLS protocol stacks for enabling secure communications between resource constrained things. In general DTLS, a cipher suite required to support specific security service should be negotiated between the CoAP client and server in the process of performing the DTLS handshake protocol. However, the handshake requires too much processing and transmission overhead in constrained IoT environment. To improve such an issue, this paper proposes a secure but efficient scheme for resource constrained things. The proposed scheme can selectively apply application data encryption or integrity to the DTLS record layer during an on-going secure session, thereby reducing the burden of DTLS handshake in resource constrained Internet of Things.
1. Introduction
In recent years, smart services of information and communication technology (ICT) have been developed actively in various industrial sectors and much attention has been paid to the Internet of Things (IoT) technology as core technology of new growth engine [1]. The IoT is a technology that interconnects everything daily life objects which were not considered in the past [2]. Gartner reported that less than 1% things are currently connected to the Internet and this will increase to 50 billion interconnected devices by 2020 according to the Cisco data [3].
When the IoT technology is applied to daily life objects, the number of devices exchanging information through the Internet will increase significantly. Although users' daily lives can be convenient due to various smart services such as smart home, smart car, and smart factory based on connecting things, it can also be a target of attack through the Internet and secondary security threat using the leaked information is also increasing. In fact, several security vulnerabilities have been reported recently in smart electronics and smart home services where various devices are applied [4]. For example, a temperature control device sold by a company in the USA controls indoor temperature based on user's indoor movements to use power efficiently. If such information is leaked due to security vulnerability, it can not only infringe personal privacy but also incur physical intrusion. In addition, a demonstration was given at the Black-Hat Conference in 2014 to inject code inside the memory and execute using the USB port in the device.
For the reasons, security has now been recognized as mandatory technology to activate IoT-based smart service [5]. If security is not provided with various smart services, not only information leakage or simple economic damage but also human life can be threatened. In addition, a variety of heterogeneous devices used in non-ICT industries exchange information by means of the Internet as a main medium, which means an increase in a range of attack targets and scope as well as incurring enormous damage, encompassing our reasonable estimation.
A variety of IoT environments such as smart electronics, smart car, and smart office consist of various heterogeneous devices from tiny sensors used in sensor networks to devices with relatively no limit of computing performances. However, most daily life objects, which are intended to support smart service, are present as embedded forms so their computing resources such as CPU, memory, and battery are limited compared to general computing devices used in the Internet. In particular, low energy consumption of functions is the core requirement to provide services reliably and to reduce cost of developing an IoT device [6].
Considering the resource constrained characteristics, the IETF specified the Constrained Application Protocol (CoAP) [7]. Also, to solve the security issues, CoAP specifies the use of Datagram Transport Layer Security (DTLS) [8]. The CoAP standard specifies the use of “AES_CCM” that provides data integrity and confidentiality as a default cipher suite for DTLS.
However, DTLS was not designed for resource constrained IoT devices but for traditional systems on the Internet. So there are several problems in applying DTLS into the IoT directly [9, 10]. In particular, the six flight messages transferred during the DTLS handshake process cause an increase in a transfer amount. The DTLS handshake processing is required to exchange supported cipher suite list and transfer of certification for sharing secret key. Thus, the overburden handshake must be repeated whenever a communication entity wants to change a cipher suite. Also, not all CoAP messages require both data integrity and confidentiality. For example, in case of CoAP messages that include information for turning a light off at home or in a building, or simple ACK information, encryption might not be necessary because such information might not be useful to attackers. Furthermore, from the perspective of effective resource use of resource constrained devices, reducing the computation load required to perform data encryption every time is necessary.
In that respect, this paper proposes an efficient scheme that can selectively apply application data encryption (i.e., confidentiality) or integrity to the DTLS record layer during an on-going secure session. The proposed scheme can reduce the burden of DTLS handshake for resource constrained Internet of Things.
The remainder of the paper is organized as follows. Section 2 describes the basic information about the DTLS and TinyDTLS (http://tinydtls.sourceforge.net/) which is known as the most lightweight DTLS implementation. In Section 3, we describe several limitations of applying traditional DTLS into resource constrained environments. The proposed scheme and our implementation are presented in Sections 4 and 5, respectively. Finally, we conclude in Section 6.
2. Preliminary
In the IETF, a number of working groups (WG) such as 6LowPAN, 6Lo, 6tisch, ROLL, and LWIG have been created to standardize technologies that can apply the TCP/IP protocol stacks to various IoT environments, especially for resource constrained environments [11, 12]. The CoAP has been standardized as an application layer protocol to send data between resource constrained devices. CoAP has been designed to transfer data between lightweight devices over the Low Power Lossy Networks (LLN) where transfer delay and packet loss can appear because of the purpose of low-power transfer. Recently, the CoAP has been applied to various IoT standard platforms such as LWM2M (Lightweight M2M) of OMA, oneM2M standard platform, and IoTivity of the OIC [13].
In the CoAP standards, the use of the DTLS protocol has been recommended for communication security between two devices [7, 13]. In this chapter, the DTLS protocol and its lightweight implementation, which is the TinyDTLS library, are discussed.
2.1. DTLS
The DTLS is secure protocol designed to establish secure session between applications that use the UDP as a transport protocol. The DTLS has been recommended to be used for CoAP as its security protocol because it is an end-to-end security protocol based on the UDP that can provide confidentiality and integrity between end processes.
The DTLS consists of four protocols: handshake, alert, change cipher spec, and record [8]. Generally, the DTLS can be divided into handshake phase that performs opening a secure session and data transfer phase in which encrypted application data are transferred. That is, once a handshake process between two communication parties is complete, crypto suite that is used to protect data to be transferred and secure key that is applied to the security algorithm are safely shared. Transferred data experience fragmentation according to the protocol data unit size. Fragmented data are compressed, authenticated, and encrypted at the record layer and then transferred into secure session. Figure 1 shows a structure of the record layer header used to transfer data.
Structure of DTLS record layer.
The content type whose size is 1 byte is used to distinguish whether transferred message is for handshake process or encrypted application message, and the version represents the DTLS protocol version. The 2-byte epoch field is incremented whenever the cipher suite is changed. If the epoch value is changed, sequence number is reset to 0. The sequence number (6 bytes) is a value that indicates an order of transmission message explicitly since the DTLS is run based on unreliable UDP. In contrast with the TLS, sequence number is utilized at the receiving end in the DTLS thereby verifying the MAC accurately. The length refers to a message length to be transmitted. The fragment value is used when a size of the application message is large. If a size of message to be transferred at the application layer is larger than the MTU size of network, a message is fragmented and transferred.
2.2. TinyDTLS
TinyDTLS is an open source library implementing minimum functions provided in the DTLS protocol with C language. The most up-to-date version is 0.8.2 as at the writing of this paper and it supports the DTLS 1.2 standards [6]. TinyDTLS consists of an algorithm that implements the DTLS, encryption, hash, session management, and queue management as separate modules. As its main implementation modules, dtls-client, dtls-server, dtls, peer, crypto, rijndael, and ccm can be found.
The modules dtls-client and dtls-server refer to two parties that communicate and the module dtls includes the DTLS API and its structure. The module peer contains information about the other party in the session and the module crypto calls encryption-related module according to the cipher suite to be used. The cryptographic modules such as AES, HMAC, ECC, and CCM are provided, and “TLS_PSK_WITH_AES_128_CCM_8” that shares a key in advance by two devices and “TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8” that is a public key method are implemented. Figure 2 shows the data transfer procedure from the record layer of TinyDTLS after handshake process.
Function flow of TinyDTLS sender.
The first function, which is processed after the handshake process, is the dtls_write() function in the dtls module. The dtls_write() is a function that is run when only data are transferred at the transmitting side. When a session is connected, data transfer is ordered in the dtls_send(). The function dtls_prepare_record() employs the function dtls_set_record_header() in order to create a record header. In addition, the dtls_ccm_encrypt_message() function in ccm module is run for data authentication and encryption. The dtls_ccm_encrypt_message() includes function mac() for data authentication and encrypt() for data encryption.
When data are received, the function dtls_handle_message() in dtls module that manages received data is operated as shown in Figure 3. The dtls_handle_message() calls the function decrypt_verify() to decrypt encrypted data. The decrypt_verify() is called to run the function dtls_ccm_decrypt_message() that is implemented in the ccm module through the function dtls_ccm_decrypt(). The dtls_ccm_decrypt_message() also includes the mac() and encrypt() functions as the same as in the dtls_ccm_encrypt_message() of sender.
Function flow of TinyDTLS receiver.
In this paper, the functions dtls_write(), decrypt_verify(), dtls_ccm_encrypt_message(), and dtls_ccm_decrypt_message() in the modules peer and dtls were modified to implement the proposed system.
3. Problem Statement
As described in the above section, the DTLS has been recommended to be used as the standard security protocol for CoAP. When the DTLS protocol is applied to the IoT, it has an advantage of increase in compatibility by reusing the protocol that is already used in the Internet environment [14]. However, the DTLS protocol has no computing resource limitation and used in the Internet environment where network performances are excellent. Thus, it is not suitable to be used in the IoT environment where computing resources are limited such as CPU, memory, and battery. As a result, it is necessary to consider the characteristics of the IoT for the DTLS to be used in the IoT environment [6, 9, 10].
In the specification of CoAP over DTLS, the “TLS_PSK_WITH_AES_128_CCM_8” is specified as mandatory cipher suite to be implemented basically. For public key-based DTLS cipher suite, “TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8” has been recommended. The DTLS cipher suite is negotiated during the DTLS handshake protocol process between client and server in CoAP. The CoAP messages provide integrity and confidentiality using “AES_CCM” at the DTLS record protocol after the DTLS handshake protocol is complete.
However, it shall be reconsidered that data integrity and confidentiality are always provided for CoAP messages in the resource-limited IoT environment. For example, it is doubted that data confidentiality shall be provided even for CoAP message transmission that turns off one electric switch in households or buildings. When all offices in a building or all electric points in a household are turned on or off, it could give a clue whether residents at buildings or households are present or not for malicious attackers who attempt illegal intrusion. However, turning on or off a single or several electric lamps is not much meaningful information for malicious attackers through CoAP message wiretapping. Thus, in order to minimize resource waste in IoT devices, data confidentiality function shall be provided selectively according to the service scenarios.
In the TLS cipher suites, a cipher suite that provides data integrity by using a hash function such as “TLS_PSK_WITH_NULL_SHA256” is defined in [15]. The “TLS_PSK_WITH_NULL_SHA256” cipher suite that provides data integrity function during the DTLS handshake protocol process between CoAP client and server can be optionally selected and only data integrity function can be provided for CoAP messages. However, if both of the “TLS_PSK_WITH_AES_128_CCM_8” and “TLS_PSK_WITH_NULL_SHA256” are implemented in resource-limited devices, it shall mount SHA256 module additionally, which can be a burden on memory capacity, compared to devices that only implement “TLS_PSK_WITH_AES_128_CCM_8.”
CoAP messages that require encryption or no encryption can be exchanged during the effective time after the DTLS session is connected. If encryption-required CoAP messages are transferred, the DTLS session is set to “TLS_PSK_WITH_AES_128_CCM_8” and if encryption is not required, the DTLS session to transfer CoAP messages is set to “TLS_PSK_WITH_NULL_SHA256,” and then CoAP nodes shall set up DTLS session frequently and resetup due to the unpredictable IoT service scenarios ((a) in Figure 4).
Advantage of the proposed scheme.
This will be a main cause of resource waste while applying the DTLS to CoAP nodes. In this paper, we propose a method that can apply security service optionally and dynamically in the DTLS record layer according to the need of application. That is, a DTLS peer can change security services (from supporting “both confidentiality and integrity” to “just a confidentiality”) without rehandshaking with his peer to change the security service. Part (b) in Figure 4 shows proposed scheme that applies security service optionally by using flag (F) and flag bits value corresponding to each requirement during an on-going secure session (see the table in Figure 7 for flag bits). In addition, the proposed scheme complies with the default DTLS cipher suite specified in CoAP and run the existing DTLS record protocol without significant modification.
4. Proposed Scheme
In the proposed scheme, two resource constrained devices perform the DTLS handshake phase, in which “AES_CCM” is decided as a default cipher suite, to deliver CoAP message securely. The “AES_CCM” is a mode of operation for block encryption. Now the two devices complete the preparation for selectively providing the CoAP message with data integrity in the DTLS record layer, or for providing both data integrity and confidentiality. Simple system architecture of the proposed scheme is shown in Figure 5, where client 1 and client 2 differently select their own security service. As an example in the figure, client 2 requires integrity only whereas client 1 requires both confidentiality and integrity support.
Simple scenario of the proposed scheme.
The “AES_CCM” mode first generates authentication tag values of a CoAP message and then encrypts the CoAP message with the authentication tag values. Figure 6 shows how the AES-CCM is operated. First, CMAC (CBC-MAC) is operated to generate a Tag that denotes authentication tag value. And then CTR (counter mode) is operated to make
AES_CCM operations.
Flag bits in epoch field.
The proposed system performs the four situations (see the table in Figure 7), especially whether only authentication tag to support integrity is created using “AES_CCM” for CoAP messages during the data transmission phase or whether even up to encryption function after authentication tag creation is provided. For CoAP messages that require encryption, authentication tag is created and message and its authentication tag value are encrypted and transferred. This follows the existing “AES_CCM” function as shown in Figure 6.
When encryption is not required, only Tag in this figure is created. Also, when only encryption is needed, only encryption is conducted without creating and encrypting an authentication tag ((A) in Figure 6). In addition, if both message authentication and encryption are not applied and only a plain text is sent, “AES_CCM” is not operated.
A DTLS sender sets the flag bits value in the epoch field of the record header to indicate whether authentication and encryption are applied during data transmission. Authentication and encryption are applied to data according to the flag bits value in the record header and then transferred. A receiver checks whether message authentication and encryption were applied or not thereby verifying message authentication and encryption values according to the flag bits value. To achieve this, upper 2 bits in the epoch field are used as illustrated in Figure 7.
The epoch field is an increment value whenever cipher suite is changed and it allows from 0 to 65536 times of change. However, it is not necessary to change the cipher suite during a single session as many as that number. Thus, the upper 2 bits in the epoch field are divided into fields that indicate the four situations that represents whether message authentication and encryption are applied or not. A table in Figure 7 explains the flag bits values to be employed and what the number represents.
We utilize the first two bits of epoch field of record header of a DTLS message to indicate whether message authentication and/or encryption are applied or not. Thus the proposed scheme does not present additional transmission overhead. In addition, if various functions can be provided through a field representing whether message authentication and encryption are applied without changing the cipher suite, it is unlikely to increase the epoch value thereby reducing the need to reset the session for the cipher suite.
5. Implementation and Evaluation
The extended DTLS was implemented to enable the selective application of confidentiality and integrity without carrying additional handshake processing between resource constrained devices connected with the DTLS session. Raspberry Pi, which used Linux as its OS, was used as the devices applied for implementation. The extended DTLS was implemented based on the TinyDTLS (version 0.8.2) which was a widely used open source library for DTLS. Since the TinyDTLS library supported IPv6, IPv6 was set for Raspberry Pi. Also, “TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8” provided in TinyDTLS was used as the default cipher suite.
The epoch field of DTLS record header is used as an identifier which allows CoAP sender to select whether or not to provide confidentiality and integrity and CoAP receiver to confirm that it is used in the suggested system. The functions were implemented and added to TinyDTLS to allow DTLS transmitter module to set the flag bits in epoch field and the receiver module to confirm the flag bits. The dtls_write() function of the DTLS transmission module uses the epoch field value of the DTLS header differently based on the set value (i.e., like a flag valuable) through the implemented function. That is, the implemented system examines the epoch field value and applies “AES_CCM” mode differently to the data to be transmitted. The dtls_ccm_encrypt_message() function of the “AES_CCM” module applies the mac() and encrypt() to data differentially according to the value of data authentication and encryption application field. If the field value is 00, both authentication and encryption are applied to data, if it is 01, authentication is applied to data, if it is 10, encryption is applied to data, and and if it is 11, neither authentication nor encryption is applied to data.
In case of receiving data, the decrypt_verify() function of the dtls module checks the value of data authentication and encryption application field and operates the dtls_ccm_decrypt_message() function of the ccm module in order to verify data except for a case that neither authentication nor encryption is applied to data. The dtls_ccm_decrypt_message() function applies the mac() and encrypt() to data according to each field value and verifies data.
Figure 8 is the screenshot of the proposed system being implemented and executed. As a result of execution, the contents of message where MAC or encryption is executed according to the flag bits value of epoch field which decides whether or not to apply data authentication and encryption can be confirmed. All the transmitted data are the same as “a” (see the table in Figure 8). Also, data processed according to the value of data authentication and encryption application field between two devices can be confirmed using Wireshark which is the packet analysis utility. Figure 8 shows a screenshot of packet transmitted, where the transmitting data was “-F 1 a.”
Result of transmitting “-F 1 a” message.
(A) and (B) in Figure 9 indicate the decimal value and the hexadecimal value where the value of data authentication and encryption application field and the epoch field are applied, respectively. It can be confirmed through (A) and (B) that 01 has been set for the upper 2-bit value which is the data authentication and encryption application field. Also, it can be confirmed through (C) that a message set to use data integrity only is transmitted.
Screenshot of a packet captured using Wireshark.
If the proposed scheme is used, communication parties can change the security service flexibly without carrying out the DTLS handshake process each time under a resource constrained environment. As mentioned earlier, the DTLS handshake processing applies a significant burden to the resource constrained devices and network as well. Especially, in case it is applied to low power communication environments such as IEEE 802.15.4, fragmentation occurs with small MTU. A fragmented packet causes retransmission due to delay and loss, degrading the network performance. Also, the fragmentation may increase security threats to allow malicious attackers to interrupt normal processing of a fragmented packet with a fragment duplication attack [16]. A large amount of resources including energy consumption and memory is used to carry out the DTLS handshake process. Table 1 shows the measurement result of time and energy consumption used for DTLS handshake processing under the multihop environments. We use MTM-CM3000-MSP module that is ultralight device for this experiment. Timer is set 10 seconds for PSK-based handshake and 15 seconds for ECDHE-based handshake to prevent unnecessary retransmission. When the timer expires, the device that is in waiting state retransmits a flight having current handshake state.
Execution time and energy consumption required for DTLS handshake.
In this experiment, 6LowPAN GW for the sender and 6LowPAN GW for the receiver are connected directly through the Internet. In Table 1, 1:1, 1:2, and 2:2 mean the hop between the sender and receiver devices and 6LowPAN GW. That is, 1:2 indicates that the sender device is directly connected to the 6LowPAN GW (i.e., 1 hop) located within the sender PAN and the receiver device is connected to the receiver's 6LowPAN GW via 2 hops. Table 1 shows that, in case of connecting through the multihop, the performance deteriorates and ECDHE-based handshake requires more time and energy consumption than PSK-based handshake.
Figure 10 shows the time taken for data transmission using the suggested system according to the value of data authentication and encryption application field. It shows that the proposed system is more efficient as the size of data to be transmitted is larger. Also, there is a significant difference between the execution time of ECDHE-based DTLS handshake in Table 1 and the time taken for data transmission according to the value of data authentication and encryption application field. That is, it is more efficient in terms of resource utilization to apply the data authentication and encryption selectively as needed through this proposed system than to execute the handshake each time to set and reset the session as needed.
Computing time using the proposed system according to the data size.
6. Conclusion
In this paper, the scheme to allow communication parties to change the security service flexibly without carrying out the DTLS handshake process each time under a resource constrained IoT environment was proposed. In the scheme, the cipher suite can be changed flexibly and dynamically even in the condition that the DTLS session between two parties who intend to transmit data is connected. Through this, a device that intends to transmit can select the confidentiality and integrity flexibly according to the security characteristics of a message which the device intends to transmit. Therefore, the DTLS handshake process which should be carried out each time to change the characteristics of security session in the previous DTLS can be minimized, securing benefit in terms of performance and energy consumption. Also, the proposed system utilizes the epoch field of the record header so that it also has an advantage that no communication overhead occurs due to the proposed scheme.
Footnotes
Competing Interests
The authors declare that they have no competing interests.
Acknowledgments
This research was supported by the MSIP (Ministry of Science, ICT and Future Planning), Korea, under the ITRC (Information Technology Research Center) support program (IITP-2016-H8501-16-1008) supervised by the IITP (Institute for Information & Communications Technology Promotion).