ROLL Wei-Cheng Zhao Internet Draft De-Yun Gao Expires: November 11, 2013 Hong-Ke Zhang Wan-Ting Zhu Beijing Jiaotong University November 19, 2014 AAL security in Low Power and Lossy Networks draft-zhao-aalsec-access-00 Abstract Due to the seriously resource-constrained and easily attacked character of Low Power and Lossy Networks-LNs, security becomes even harder to be deployed. Here we present an AAL security scheme to protect devices in AAL layer to help protect to communicate with each other safely including a special key management, encryption, authentication and other security measures. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt -------The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on June 6, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these Zhao et al. Expires November 11, 2015 [Page 1] Internet-Draft AAL security in LLNs November 19, 2014 documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of contents 1. Introduction: ............................................... 2 2. Problem statement: .......................................... 3 3. The whole security scheme ................................... 3 4. Key management scheme ....................................... 5 5. summarize and expectation ................................... 7 6. References ................................................... 7 6.1. Normative References ...................................... 7 6.2. Informative References.... ................................ 8 Acknowledgment................................................... 8 1. Introduction: LLNs consist of low power devices which are seriously resource-constrained in variety link quality condition. The low cost and limited power devices can collect information like light intensity and transmit the data packets though 802.15.4.Meanwhile, these devices can execute some control tasks using typical sensor chip. Due to the situation that LLNs devices are usually deployed at harsh outdoor environment where people can hardly get into, LLNs are self-organized. In this document, we discuss about LLN devices running IPv6 stack. We firstly briefly introduce 6LoWPAN protocol below. 6LoWPAN is a protocol aimed at importing IPv6 in LLNs. It compresses IP and transport layer header (only UDP at present) and fragments packets which are too large for lower layer transmission to realize above function. And AAL is a layer between network layer and data link layer using 6LoWPAN protocol. In this document, a distributed AAL security scheme for LLNs is proposed. We put forward the key management scheme calling network routing protocol RPL. And encryption as well as authentication is carrying on using the key. AAL security scheme accomplish the safely communication using as few resource as possible. Zhao et al. Expires November 11, 2015 [Page 2] Internet-Draft AAL security in LLNs November 19, 2014 2. Problem statement: Due to the transmission method of wireless broadcast, LLNs is naturally vulnerable. While, these low power devices are severely resource-constrained which lead to the lack of computing power as well as the memory capacity. Regular security mechanisms and frameworks are too complex and not suitable for LLNs. 3. The whole security scheme To guarantee communication safety between sensor nodes, security methods are needed in LLNS. However, complicated security protocol can't be executed due to the serious resource-limited characteristic of the sensor nodes. Thus in the document we propose and imple a new security scheme ensuring normal interaction between sensor nodes and being light-weighted. As is mentioned in the introduction, 6LoWPAN is used to compress packets as well as deal with large packets. +-----------------------------------------------------------------------------+ | Application | +-----------------------------------------------------------------------------+ | RPL + key rotation | +-----------------------------------------------------------------------------+ | uIP | +-----------------------------------------------------------------------------+ | 6LoWPAN Header compression | +-----------------------------------------------------------------------------+ | Security | +-----------------------------------------------------------------------------+ | fragmentation | +-----------------------------------------------------------------------------+ | 802.15.4 | +----------------------------------------------------------------------------+ Figure1 System structure The security scheme includes key-management, authentication, encryption and other safety measures. During sending, packets delivered from 6LoWPAN protocol are processed by the security scheme. Zhao et al. Expires November 11, 2015 [Page 3] Internet-Draft AAL security in LLNs November 19, 2014 +-----------------------------------------------------------------------------+ | compressed header | transport layer header | data | +-----------------------------------------------------------------------------+ Figure 2 Packet Format +-----------------------------------------------------------------------------+ |IF_SECURE| FRAG | ENCRPT |AUTH| RESERVE | +-----------------------------------------------------------------------------+ 0 1 2 3 4 7 Figure 3: Security Byte Format Firstly, the packets are analyzed about packet type. We can analyze specific security byte in the compressed header. The first bit(IF_SECURE) stands for whether this packet goes though the security procedure. IF_SECURE=0 means no security needed, IF_SECURE=1 means security scheme deployed by the following bits. FRAG bit stands for whether this packet is fragmented FRAG=0 means this packet is normally complete while FRAG=1 means this packet is fragment packet and needs special process. ENCRPT bit stands for whether this packet should be encrypt. IF_SECURE=1 and ENCRPT=0 means no need to encrypt this packet, IF_SECURE=1 and ENCRPT=1 means we should encrypt current packet. AUTH bit stands for whether this packet should be authenticate. IF_SECURE=1 and AUTH=0 means no need to authenticate this packet, IF_SECURE=1 and AUTH=1 means we should authenticate current packet. The rest bits are reserved and default value is 0. +-----------------------------------------------------------------------------+ | key management | +-----------------------------------------------------------------------------+ | authentication | encryption | anti-replay | +-----------------------------------------------------------------------------+ Figure 4: Security Layer If the packet is found to be a fragmented one, we need to take special action before security goes forward. That is because we deployed security scheme after 6LoWPAN, while 6LoWPAN detect maximum transmission unit in link layer and extra secure bits are added during secure handle. In this paper we get to a solution by move the fragment process part of 6LoWPAN protocol from the top of the secure scheme to the bottom of it. Detailedly, the packet firstly goes though 6LoWPAN without detect of the max length and fragment after secure processes (including encryption and authentication) and process this step after all security movement ends. That is to say, when the packet is too long to transfer, we wait until Zhao et al. Expires November 11, 2015 [Page 4] Internet-Draft AAL security in LLNs November 19, 2014 every step of security accomplish to decide whether this whole packet needs to fragment. If the packet is found to be a DIO packet (detailedly introduce below), step into the key rotating part. Next(no matter what kinds of packet it is), authentication and encryption parts get key from key management part(if needed in security byte format).Key would be calling from the memory of device and encryption and authentication would be applied. In most of the device, radio frequency or CPU chip may provide encryption and authentication algorithm. To reduce consumption of the resource serious device, hardware algorithm is a great way to complete the complex computing. Specifically, only the load (including the uncompressed transport layer header) is encrypted and the whole packet is authenticated. That's because if we encrypt the header we need to add a new header and make the packet much longer, while authentication part doesn't get that problem. Finally, the sequence number is added and the new secure packet is transferred to lower layer to send. That is when we decide whether this packet is too long and needs fragment. Receiving process is similar as sending process including decryption, authentication, key management and fragmentation. 4. Key management scheme Traditional key management schemes are usually based on public key encryption, which is difficult even impossible for LLNs to imply. However, LLNs are more likely to sustain Eavesdropping attack due to Wireless Broadcast Advantage of the LLNs devices. While traditional embedded key management schemes usually use key pool approach which spends a lot of memory to save keys and geographical position message is needed if we want an advanced topology. Thus, a new efficient key management scheme is badly needed. In this document, we propose a key management scheme based on LLNs routing protocol RPL. To start with, we introduce normal network method of LLNs applying RPL. The root device broadcast DIO(a routing passage including link quality message called rank ) to invite other devices nearby to join in its DODAG. These devices get the passage and decide to join in by a parameter called rank, and so on. This project continues until all the devices join in the topology. In this document, security methods like authentication and encryption are added though all the procedure and rotating happened during DIO accept. Firstly, a global public key is assigned to all devices for sequential authentication. Then, first-round authentication happened to routing packets DIO during networking period using previous public key. Packets that pass the authentication will help their senders join the DODAG and Zhao et al. Expires November 11, 2015 [Page 5] Internet-Draft AAL security in LLNs November 19, 2014 lead to the first-round rotating. Child devices analyze DIO and generate first-round encryption key by extracting rank, DODAG number as well as father device ID as original data and encrypting this data by previous key. DAO(response of DIO)including round number to identify key rotating complete in its expand option is send after all above complete. Then both child device and father device can delete the previous key (while father device need to wait for each child giving successful response). Thereafter every DIO lead to a new round key. DIO is a route control packet whose transmission frequency depends on network stability. Rotating caused by DIO connect security together with link state, which improve security efficiency a lot. What is more, rank of different devices are differ from each other as well as device ID, which lead to the phenomenon that devices of different father devices use various round key while these of the same father device share the same key. So that the whole network use different round key to protect the devices from password cracking while every single device only need to save two keys(the key to communication with the father device and the key to communicate with child devices). Assume there are several LLNs devices deployed in the open-round. Root device is very close to device A. Then the interaction diagram below shows the detail process of how the devices join in the DODAG and how they manage to rotate. root A B C | | | | |-------DIOr0---------->| | | | | | | |<------DAOr0-----------| | | | | | | | |--------DIOa0 ---------->| | | | | | | |<-------DAOa0 -----------| | | | | | | | |<-------DISc0----------- | | | | | | | |--------DIOb0----------> | | | | | | | |<-------DAOb0------------| | | | | .................................... After n rounds .................................... | | | | |<----- DIOrn ----------| | | Zhao et al. Expires November 11, 2015 [Page 6] Internet-Draft AAL security in LLNs November 19, 2014 |<------DAOrn ----------| | | | | | | | |-------DIOan ----------->| | | | | | | |<------DAOan ------------| | | | | | | | |<------DIScn-------------| | | | | | | |-------DIObn------------>| | | | | | | |<------DAObn-------------| Figure 5: Interaction Diagram 5. summarize and expectation We put forward a complete AAL security scheme above, especially focus on the key management realizition.By using meaningful syliable in broadcast DIO, we sucessfully carry on key distribution and rotating without using extra link consume and internal memory.The keys are different in the whole network while devices holding the same father device share the same device. LLNs devices can apply this security scheme to complete safty communication. While, this scheme is only suitable for the LLNs based on Ipv6 and deploying RPL routing protocol.What's more, adding new devices to the previous LLNs could cause great risk if the safty of this new one can not be detected.This shortage should be solved in next vision by adding intrusion Detection mechanism.We may also add application layer security and link layer security in next verion. This document does not specify any security considerations. 6. References 6.1. Normative References [RFC6550] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC6550, March 2012. [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6552] P.Thubert, "RPL Objective Function 0", RFC6552, March 2012. Zhao et al. Expires November 11, 2015 [Page 7] Internet-Draft AAL security in LLNs November 19, 2014 [RFC6206] P.Levis, T.Clausen, J.Hui, O.Gnawali, and J.Ko, "The Trickle Algorithm", RFC6206, March 2011. 6.2. Informative References Jennifer Yick. Wireless sensor network survey[J]. Computer networks,2008,52(12): 2292-2330. Holzmann G J. The SPIN Model Checker, Primer and Reference Manual. Addison-Wesley, 2003. POTTIE G J, KAISER W J. Wireless Integrated Network Sensors[J]. Communications of the ACM (S0001-0782), 2000, 43(5) : 551-558. Oscar Delgado-Mohatar, Amparo Futer-Sabater, Jose M.Sierra. Alight-weight authentication scheme for wireless sensor networks. Ad Hoc Networks 9(2011)727-35. Javier Lopez, Rodrigo Roman, Isaac Agudo, Carmen Fernandez-Gago. Trust management systems for wireless sensor networks: Best practices. Computer Communications 33(2010)1086?093. Su Zhong, Lin Chuang, Feng fujun, Ren Fengyuan. Key Management Schemes and Protocols for Wireless Sensor Networks. Journal of Software, V01.18,No.5,May 2007,PP.1218-1231. Authors' Addresses Wei-Cheng Zhao, De-Yun Gao, Hong-Ke Zhang, Yan-fei Ma, Wan-Ting Zhu, National Engineering Lab for NGI Interconnection Devices Beijing Jiaotong University, China Phone: +8613521693762 Email: 11111018@bjtu.edu.cn gaody@bjtu.edu.cn hkzhang@bjtu.edu.cn 11111019@bjtu.edu.cn Acknowledgment This work was supported by the National Major Projects of China (Grant No. 2012ZX03005003). Zhao et al. Expires November 11, 2015 [Page 8]