[雙語(yǔ)翻譯]--外文翻譯--lithe物聯(lián)網(wǎng)中的輕量級(jí)安全coap協(xié)議（原文）

1、IEEE SENSORS JOURNAL, VOL. 13, NO. 10, OCTOBER 2013 3711Lithe: Lightweight Secure CoAP for the Internet of ThingsShahid Raza, Hossein Shafagh, Kasun Hewage, René Hummen, and Thiemo VoigtAbstract—The Internet of Thin

2、gs (IoT) enables a wide range of application scenarios with potentially critical actuating and sensing tasks, e.g., in the e-health domain. For communication at the application layer, resource-constrained devices are exp

3、ected to employ the constrained application protocol (CoAP) that is currently being standardized at the Internet Engineering Task Force. To protect the transmission of sensitive information, secure CoAP mandates the use

4、of datagram transport layer security (DTLS) as the underlying security protocol for authenticated and confidential communication. DTLS, however, was originally designed for comparably powerful devices that are interconne

5、cted via reliable, high-bandwidth links. In this paper, we present Lithe—an integration of DTLS and CoAP for the IoT. With Lithe, we additionally propose a novel DTLS header compression scheme that aims to significantly

6、reduce the energy consumption by leveraging the 6LoWPAN standard. Most importantly, our proposed DTLS header compression scheme does not compromise the end-to-end security properties provided by DTLS. Simul- taneously, i

7、t considerably reduces the number of transmitted bytes while maintaining DTLS standard compliance. We evaluate our approach based on a DTLS implementation for the Contiki operating system. Our evaluation results show sig

8、nificant gains in terms of packet size, energy consumption, processing time, and network-wide response times when compressed DTLS is enabled.Index Terms—CoAP, DTLS, CoAPs, 6LoWPAN, security, IoT.I. INTRODUCTION IPV6 over

9、 Low power Wireless Personal Area Network (6LoWPAN) [1] enables the use of IP in low-power and lossy wireless networks such as Wireless Sensor Net- works (WSNs). Such IP-connected smart devices (Things) are becoming part

10、 of the Internet hence forming the Internet of Things (IoT) or strictly speaking the IP-connected IoT.Manuscript received May 24, 2013; revised July 3, 2013 and July 25, 2013; accepted July 31, 2013. Date of publication

11、August 7, 2013; date of current version August 28, 2013. This work was supported by the SICS Center for Networked Systems (CNS), SSF through the Promos project, and CALIPSO, Connect All IP-Based Smart Objects, funded by

12、the European Commission under FP7 under Contract FP7-ICT-2011.1.3-288879. The associate editor coordinating the review of this paper and approving it for publication was Dr. Chonggang Wang. S. Raza is with SICS Swedish I

13、CT, Kista SE-164 29, Sweden (e-mail: shahid@sics.se). H. Shafagh is with SICS Swedish ICT, Kista SE-164 29, Sweden, and also with Communication and Distributed Systems, RWTH Aachen University, Aachen 52062, Germany (e-ma

14、il: hossein@sics.se). K. Hewage is with the Department of Information Technology, Uppsala University, Uppsala 751 05, Sweden (e-mail: kasun.hewage@it.uu.se). R. Hummen is with Communication and Distributed Systems, RWTH

15、Aachen University, Aachen 52062, Germany (e-mail: hummen@comsys. rwth-aachen.de). T. Voigt is with SICS Swedish ICT, Kista SE-164 29, Sweden, and also with the Department of Information Technology, Uppsala University, Up

16、psala 751 05, Sweden (e-mail: thiemo@sics.se). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/JSEN.2013.2277656TCP perform

17、ance is known to be inefficient in wireless networks, due to its congestion control algorithm, and the situation is exacerbated with the low-power radios and lossy links found in sensor networks. Therefore, the connectio

18、n- less UDP is mostly used in the IoT. Further, HTTP, which is primarily designed to run over TCP, is inefficient in lossy and constrained environments. The IETF is working on the connection-less lightweight Constrained

19、Application Protocol (CoAP) [2], a new proposed standard for the IoT. CoAP is designed to meet specific requirements such as simplicity, low overhead, and multicast support in resource-constrained environments. Security

20、is particularly important for the Things as they are connected to the untrusted Internet. For instance, medical monitoring denotes a typical security-sensitive appli- cation scenario. Here, a smart device, such as an ins

21、ulin,1 may be attached to the patient’s body and periodically report the condition of the patient to a back-end service in the Internet. In emergency cases, a physician may additionally be able to trigger instant injecti

22、on of medication into the patient’s body. CoAP proposes to use Datagram Transport Layer Secu- rity (DTLS) [2] as the security protocol for automatic key management and for data encryption and integrity protection, as wel

23、l as for authentication. CoAP with DTLS support is termed secure CoAP (CoAPs). DTLS is a chatty protocol and requires numerous message exchanges to establish a secure session. While DTLS supports a wide range of cryptogr

24、aphic primitives for peer authentication and payload protection, it was originally designed for network scenarios where message length was not a critical design criterion. Therefore, it is inefficient to use the DTLS pro

25、tocol, as it is, for constrained IoT devices. To cope with constrained resources and the size limitations of IEEE 802.15.4-based networks,2 6LoWPAN header compression mechanisms are defined. The 6LoWPAN standard already

26、defines the header compression format for the IP header, IP extension headers, and the UDP header. We believe it is particularly beneficial to apply the 6LoWPAN header compression mechanisms to compress other protocols h

27、aving well-defined header fields, such as DTLS. In this paper we provide a lightweight CoAPs by compress- ing the underneath DTLS protocol [3] with 6LoWPAN header compression mechanisms. We name our lightweight 6LoW- PAN

28、 compressed CoAPs Lithe. The purpose of DTLS header compression is twofold. First, achieving energy efficiency by reducing the message size, since communication requires1Medtronic probes insulin pump risks, Reuters, Octo

29、ber 2011. 2The Maximum Transmission Unit (MTU) size of the IEEE 802.15.4 protocol is 127 bytes.1530-437X © 2013 IEEERAZA et al.: LIGHTWEIGHT SECURE CoAP FOR THE IoT 3713this one. We plan to combine DTLS header compr

30、ession with those ideas to make the mutual certificate-based handshake more efficient. Recently, Generic Header Compression (GHC) [14], analogous to NHC, is also defined to allow upper layer (UDP payload and above) heade

31、r compression. 6LoWPAN- GHC is a generic compression scheme for all headers and header-like structures but is a slightly less efficient approach [14]. It is an alternative to our solution and we plan to compare our 6LoWP

32、AN-NHC with the 6LoWPAN-GHC for the DTLS headers as future work.III. BACKGROUNDDue to the heterogeneity in the IoT, it is challenging to connect resource-constrained devices in a secure and reliable way. Currently, diffe

33、rent protocols such as CoAP [2], 6LoW- PAN [15], the IPv6 Routing Protocol (RPL) [16] for Low- power and Lossy Networks (LLNs) are being standardized by the Internet Engineering Task Force (IETF) to enable the IoT. The f

34、ocus of this paper is to enable secure yet efficient communication among IoT devices that utilize the CoAP protocol. In this section, we highlight the technologies involved in the development of the lightweight CoAPs, th

35、e HTTPs variant for the IoT.A. CoAP and DTLSCoAP is a web protocol that runs over the unreliable UDP protocol and is designed primarily for the IoT. CoAP is a variant of the most used synchronous web protocol, HTTP, and

36、is tailored for constrained devices and machine-to-machine communication. However, while CoAP provides a REST inter- face similar to HTTP, it focuses on being more lightweight and cost-effective than its variant for toda

37、y’s Internet. To protect CoAP transmissions, Datagram TLS (DTLS) has been pro- posed as the primary security protocol [2]. Analogous to TLS- protected HTTP (HTTPs), the DTLS-secured CoAP protocol is termed CoAPs. A web r

38、esource on an IoT device can then be accessed securely via CoAPs protocol as: coaps://myIPv6Address:port/MyResource As a basis for the discussion of our proposed DTLS com- pression mechanisms, we give a brief overview of

39、 the DTLS protocol. DTLS guarantees E2E security of different applications on a single machine by operating between the transport and application layers. DTLS consists of two layers: the lower layer contains the Record p

40、rotocol and the upper layer contains either of the three protocols namely Handshake, Alert, and ChangeCipherSpec, or application data. The ChangeCipher- Spec is used during the handshake process to merely indi- cate that

41、 the Record protocol should protect the subsequent messages with the newly negotiated cipher suite and security keys. DTLS uses the Alert protocol to communicate the error messages between the DTLS peers. Figure 2 shows

42、the structure of a DTLS message in an IP/UDP datagram. The Record protocol [3] is a carrier for the upper layer pro- tocols. The Record header contains among others content type and fragment fields. Based on the value in

43、 the content type, the fragment field contains either the Handshake protocol,Fig. 2. Layout of a packet secured with DTLS.Fig. 3. Full DTLS handshake protocol. Messages marked with a * are optional.Alert protocol, Change

44、CipherSpec protocol, or application data. The Record header is primarily responsible to crypto- graphically protect the upper layer protocols or application data once the handshake process is completed. The Record protoc

45、ol’s protection includes confidentiality, integrity protec- tion and authenticity. The DTLS Record is a rather simple protocol whereas the Handshake protocol is a complex chatty process and contains numerous message exch

46、anges in an asynchronous fashion. Figure 3 shows a full handshake process. The handshake messages, usually organized in flights, are used to negotiate security keys, cipher suites and compression methods. The scope of th

47、is paper is limited to the header compression only and not the cryptographic processing of Record and Handshake protocols. For details of the individual handshake messages we refer to TLS [17] and DTLS [3].B. 6LoWPANThe

48、6LoWPAN standard [1] defines header compression and fragmentation mechanisms of IPv6 datagrams within IPv6-connected WSNs, also called 6LoWPAN networks. The compression mechanism consists of IP Header Compression (IPHC)

49、and Next Header Compression (NHC). The IPHC encodings can compress the IPv6 header length to 2 bytes for a single hop network and 7 bytes in a multi-hop case (1-byte IPHC, 1-byte dispatch, 1-byte Hop Limit, 2-byte Source