Lightweight Message
Authentication for the Internet of
Things
RIKARD HÖGLUND
K T H R O Y A L I N S T I T U T E O F T E C H N O L O G Y
I N F O R M A T I O N A N D C O M M U N I C A T I O N T E C H N O L O G Y DEGREE PROJECT IN COMMUNICATION SYSTEMS, SECOND LEVEL STOCKHOLM, SWEDEN 2014
Lightweight Message
Authentication for the Internet of
Things
Rikard Höglund
2014-11-24
Master’s Thesis
Examiner and academic adviser
Professor Gerald Q. Maguire Jr.
School of Information and Communication Technology (ICT)
KTH Royal Institute of Technology
Abstract | i
Abstract
During the last decade, the number of devices capable of connecting to the Internet has grown enormously. The Internet of Things describes a scenario where Internet connected devices are ubiquitous and even the smallest device has a connection to the Internet. Many of these devices will be running on constrained platforms with limited power and computing resources. Implementing protocols that are both secure and resource efficient is challenging. Current protocols have generally been designed for mains powered devices; hence, they are not optimized for running on constrained devices. The Constrained Application Protocol (CoAP) is a protocol for network communication specifically designed for constrained devices. This thesis project examines CoAP and presents an extension that adds authentication in a way that is suitable for constrained devices, with respect to minimizing resource use. The proposed solution has been compared and contrasted with other alternatives for authentication, particularly those alternatives used with CoAP. It has also been implemented in code and experimentally evaluated with regards to performance versus vanilla CoAP.
The main goal of this project is to implement a lightweight authentication extension for CoAP to be deployed and evaluated on constrained devices. This extension, called Short Message Authentication ChecK (SMACK), can be used on devices that require a method for secure authentication of messages while using only limited power. The main goal of the extension is to protect against battery exhaustion and denial of sleep attacks. Other benefits are that the extension adds no additional overhead when compared with the packet structure described in the latest CoAP specification. Minimizing overhead is important since some constrained networks may only support low bandwidth communication.
Keywords:
Constrained Application Protocol, CoAP, Internet of Things, message authentication, constrained devices, Contiki, Short Message Authentication Check, SMACK
Sammanfattning | iii
Sammanfattning
Under det senaste århundradet har antalet enheter som kan ansluta sig till Internet ökat enormt. ”The Internet of Things” beskriver ett scenario där Internet-anslutna enheter är närvarande överallt och även den minsta enhet har en uppkoppling till Internet. Många av dessa enheter kommer att vara begränsade plattformar med restriktioner på både kraft- och beräkningsresurser. Att implementera protokoll som både är säkra och resurseffektiva är en utmaning. Tillgängliga protokoll har i regel varit designade för enheter med anslutning till det fasta kraftnätet; på grund av detta är de inte optimerade för att köras på begränsade plattformar. Constrained Application Protocol (CoAP) är ett protokoll för nätverkskommunikation speciellt framtaget för begränsade plattformar. Denna uppsats undersöker CoAP protokollet och presenterar ett tillägg som erbjuder autentisering på ett sätt som passar begränsade plattformar, med avseende på att minimera resursanvändning. Den föreslagna lösningen har blivit beskriven och jämförd med andra alternativ för autentisering, speciellt de alternativ som används med CoAP. Lösningen har också implementerats i kod och blivit experimentellt utvärderad när det gäller prestanda jämfört med standardversionen av CoAP.
Det huvudsakliga målet för detta projekt är att implementera en lättviktslösning för autentisering till CoAP som ska installeras och utvärderas på begränsade plattformar. Detta tillägg, Short Message Authentication checK (SMACK), kan användas på enheter som behöver en metod för säker autentisering av meddelanden samtidigt som kraftåtgången hålls låg. Huvudmålet för detta tillägg är att skydda mot batteridräneringsattacker och attacker som hindrar en enhet från att gå i viloläge. Andra fördelar är att tillägget inte kräver någon extra dataanvändning jämfört med paketstrukturen som beskrivs i den senaste CoAP-specifikationen. Att minimera overhead i kommunikationsprotokoll är viktigt eftersom vissa begränsade nätverk endast stödjer kommunikation över låg bandbredd.
Nyckelord:
Constrained Application Protocol, CoAP, Internet of Things, meddelandeautentisering, begränsade plattformar, Contiki, Short Message Authentication Check, SMACK
Table
Abstra
Samm
Table
List of
List of
List of
1
Int
1.1 1.2 1.3 1.4 1.5 1.62
Ba
2.1 2.2 2.2 2.2 2.2 2.3 2.4 2.5 2.5 2.5 2.6 2.6 2.6 2.7 2.8 2.9 2.10 2.11 2.123
SM
3.1 3.2 3.3 3.4 3.5 3.6 3.74
Me
4.1 4.2 4.3 4.4e of con
act ...
manfattnin
of conten
f Figures .
f Tables ..
f acronym
troduction
Gene Probl Goals Rese Delim Strucckground
Cons CoAP REST 2.1 CoAP 2.2 CoAP 2.3 Califo Mave Conti Erbium 5.1 Instan 5.2 6LoW Authe 6.1 6LoW Explo 6.2 IPsec Secu Multi DTLS Lithe AnalyMACK ...
Overv Keys Pseud Confi Galoi Repla Examethod ...
Hardw Softw SMAC Energntents
...
ng ...
nts ...
...
...
ms and ab
n ...
eral introdu em definit s ... arch meth mitations .. cture of thd ...
trained De P ... ... Security o Granular s ornium .... en ... iki ... m ... nt Contiki a WPAN ... entication a WPAN ... iting IEEE 8 c ... re Real-tim media Int S ... : Lightwei ysis of Exis...
view ... ... do Random iguration v s fields .... ay detectio mple scena...
ware ... ware envir CK C imple gest ......
...
...
...
...
breviatio
...
uction to t tion ... ... hodology .. ... e thesis .....
evices ... ... ... ptions ... security ... ... ... ... ... and Cooja .. ... and encrypt ... 802.15.4 e ... me Protoco ernet KEY ... ght Secur sting Inter...
... ... m Function values ... ... on ... ario ......
... onment us ementatio ......
...
...
...
...
ns ...
...
the area .. ... ... ... ... ......
... ... ... ... ... ... ... ... ... ... ... tion built in ... ncryption a ... ol ... Ying (MIKE ... re CoAP fo rnet Proto...
... ... n ... ... ... ... ......
... sed for de n ... ......
...
...
...
...
...
...
... ... ... ... ... ......
... ... ... ... ... ... ... ... ... ... ... nto IEEE 80 ... and authen ... ... Y) ... ... r the Inte cols for th...
... ... ... ... ... ... ......
... evelopmen ... ......
...
...
...
...
...
...
... ... ... ... ... ......
... ... ... ... ... ... ... ... ... ... ... 2.15.4 as u ... tication ... ... ... ... ... rnet of Th he Internet...
... ... ... ... ... ... ......
... t ... ... ... Table of co...
...
...
...
...
...
...
... ... ... ... ... ......
... ... ... ... ... ... ... ... ... ... ... used by ... ... ... ... ... ... ings ... t of Things...
... ... ... ... ... ... ......
... ... ... ... ontents | v... i
... iii
... v
... vii
... ix
... xi
... 1
... 1 ... 2 ... 3 ... 3 ... 3 ... 4... 5
... 5 ... 6 ... 8 ... 8 ... 9 ... 10 ... 10 ... 10 ... 10 ... 11 ... 12 ... 12 ... 13 ... 14 ... 14 ... 15 ... 16 ... 17 s .... 18... 21
... 21 ... 22 ... 23 ... 24 ... 25 ... 26 ... 29... 31
... 31 ... 32 ... 32 ... 33vi | Table of contents
5
Analysis ... 35
5.1 Functional Testing ... 35
5.2 Comparison of packet overhead ... 36
5.3 Performance Testing ... 36
5.4 Testing on other constrained devices ... 37
5.5 Chapter summary ... 37
6
Conclusions and Future work ... 39
6.1 Conclusions ... 39
6.2 Future work ... 40
6.3 Required reflections ... 41
References ... 43
List of Figures | vii
List of Figures
Figure 2-1:
Texas Instruments CC2538DK ... 6
Figure 2-2:
CoAP Packet structure [12] ... 7
Figure 3-1:
Keys used by SMACK ... 22
Figure 3-2:
Message sections ... 26
Figure 3-3:
Packet processing flowchart ... 28
List of Tables | ix
List of Tables
Table 2-1:
Fields of a CoAP packet ... 7
Table 2-2:
Yegin CoAP Security Options fields ... 9
Table 2-3:
Granular security options ... 9
Table 3-1:
Generation of Keys A, B, C ... 23
Table 3-2:
SMACK key values ... 25
Table 4-1:
CC2538 test hardware key values ... 32
Table 4-2:
Energest metrics ... 33
Table 5-1:
SMACK measurements ... 36
Table 5-2:
Vanilla CoAP measurements ... 37
Table 5-3:
Energy statistics ... 37
Appendix table A-1:
SMACK full request 1st transaction (A) ... 49
Appendix table A-2:
SMACK MAC check 1st transaction (B) ... 50
Appendix table A-3:
SMACK full request steady-state (C) ... 51
Appendix table A-4:
SMACK MAC check steady-state (D) ... 52
Appendix table A-5:
Vanilla CoAP full request 1st transaction (E) ... 53
List of acronyms and abbreviations | xi
List of acronyms and abbreviations
6LoWPAN IPv6 over Low power Wireless Personal Area Networks
AB
Aktiebolag (Joint-stock company)
ACL
Access Control List
AES
Advanced Encryption Standard
AP Access
Point
CBC
Cipher Block Chaining
CCM
Counter with CBC-MAC
CCS
Code Composer Studio
CEO
Corporate Executive Officer
CLI
Command Line Interface
CoAP
Constrained Application Protocol
CPU
Central Processing Unit
CTR Counter
DNS Domain
Name
System
DoS
Denial of Service
DTLS
Datagram Transport Layer Security
EU European
Union
GNU GNU's
Not
Unix!
HMAC
Hash-based Message Authentication Code
HTTP
Hypertext Transfer Protocol
ICT
Information and Communication Technology
ID Identification
IDE
Integrated Development Environment
IEEE
Institute of Electrical and Electronics Engineers
IETF
Internet Engineering Task Force
IKE
Internet Key Exchange
IoT
Internet of Things
IP Internet
Protocol
IPv4
IP version 4
IPv6
IP version 6
JTAG
Joint Test Action Group
JVM Java
Virtual
Machine
xii | List of acronyms and abbreviations
KDC
Key Distribution Center
KTH
Kungliga Tekniska Högskolan (KTH Royal Institute of Technology)
LPM Low
Power
Mode
M2M
Machine to Machine
MAC Message
Authentication
Code
or Media Access Control depending
upon context
MHz Megahertz
MID Message
ID
MIKEY Multimedia
Internet
KEYing
MITM Man-In-The-Middle
MTU
Maximum Transfer Unit
NSA
National Security Agency
OS Operating
System
PC Personal
Computer
PCAP Packet
CAPture
PKI
Public Key Infrastructure
PRF
Pseudo Random Function
PRNG Pseudo-Random
Number Generator
RAM
Random Access Memory
RC4
Rivest Cipher 4
REST
Representational State Transfer
RFC
Request for Comments
ROM
Read Only Memory
RTC
Real Time Clock
RTP Real-Time
Protocol
RTSP
Real Time Streaming Protocol
SDP
Session Description Protocol
SHA
Secure Hash Algorithm
SICS
SICS (Swedish Institute of Computer Science) Swedish ICT AB
SIP
Session Initiation Protocol
SMACK
Short Message Authentication ChecK
SOAP
Simple Object Access Protocol
SRTP
Secure Real-Time Protocol
S/MIME Secure/Multipurpose
Internet Mail Extensions
TCP
Transmission Control Protocol
List of acronyms and abbreviations | xiii
TI Texas
Instruments
TKL ToKen
Length
TLS
Transport Layer Security
UDP User
Datagram
Protocol
URL
Uniform Resource Locator
USB
Universal Serial Bus
VM Virtual
Machine
VoIP Voice
over
IP
VPN
Virtual Private Network
WWW World-Wide
Web
Introduction | 1
1 Introduction
This report details the results of a master's thesis project “Lightweight Message Authentication for the Internet of Things” performed during the spring of 2014 at KTH Royal Institute of Technology. The project was conducted in cooperation with SICS Swedish ICT AB [1] in Kista.
1.1 General introduction to the area
During the last decade, the growth in the number of Internet enabled devices has been considerable. At the start of this expansion, people typically only owned a few Internet capable devices, typically in the form of personal computers. Today more and more devices have interfaces that allow Internet connectivity. One of the most significant developments has been in the number of smart phone devices. Currently people frequently own many devices that they use interchangeably for Internet access. Every day additional devices join the global Internet, potentially permitting access to or from them by other Internet enabled devices.
The term Internet of Things (IoT) was coined by Kevin Ashton during 1999 [2], although the concept was discussed in scientific literature prior to this time. This term tries to define a future Internet where the growth in the number of device continues and almost all electronic devices have Internet connectivity. This growth is not limited to user-controlled devices, but also includes machine-to-machine (M2M) communication, such as smart sensor systems. All of these Internet connected devices will have a representation in the Internet either in the form of an IP address or some other identifying information. Setting up such an infrastructure has many benefits, including remote monitoring, convenient control of devices owned by an individual, and increasing numbers of automated systems. Estimates of the number of wireless devices connected to the Internet suggest 30 billion devices by 2020 [3]. Even today, IoT has emerged as an area for research and development.
A "constrained device" is a device that has limited resources in terms of processing capacity, memory, or available power. Constrained devices are often used to implement sensor networks and automated systems that utilize M2M communication. The reason these devices are used is that they are small, inexpensive, and can perform the desired function(s), while consuming very little power. The software running on these devices has to be adapted to this constrained environment and ensures sufficient performance without requiring high speed processing, large memory capacity, or using excessive power. Creating small IP stacks and similar software have been necessary steps to realize IoT and to allow constrained devices to communicate efficiently via a network. Making IoT devices accessible through the same protocols used in the global Internet is also important when interconnecting these devices to the existing network infrastructures.
Security is another important aspect of the IoT. If all devices have an IP-address and are accessible via the Internet, then security becomes an even more important issue as the number of potential attackers is greatly increased. Authentication is vital to prevent certain types of attacks against these devices and to confirm the validity of messages. For instance, a device can be inundated with messages in order to exhaust its battery supply, thus authentication has to be performed in an efficient manner and properly take into account the device’s limited power, storage, and computing capabilities. Because of this, the protocols used for authentication have to be adapted for these constrained devices and must meet requirements beyond the conventional requirements for mains powered devices.
Combining the fast growth of IoT devices with limited resources and less mature security options means that these constrained devices can become a prime target for attacks. If these issues are overlooked, then sensitive systems including devices controlling people’s homes or industrial applications are at risk. This is especially true if devices such as smart light bulbs, industrial sensors, radiators, and other such applications continue to gain in popularity. It is important that security is built into the IoT as early as possible, as retrofitting security solutions is more a difficult challenge.
2 | Introduction
1.2 Problem definition
Denial of service (DoS) attacks are malicious actions that attempt to deny access to or shut down some device [4]. For instance, such an attack could attempt to overwhelm a target with traffic or send malformed packets that the device does not know how to handle. For constrained devices the term "denial of sleep" is often used since these devices frequently rely on going to sleep when data is not being actively processed, sent, or received. It is crucial for the radio circuitry to be in sleep mode as long as possible in order to minimize power consumption. Simply receiving, parsing, and processing data sent to a constrained device can be costly since the radio needs to be on in order to receive the data, which drains a lot of power. In addition, power is need for processing the packet(s) that have been received. For these reasons, constrained devices are especially vulnerable to DoS attacks. In addition, they are rarely protected with intrusion detection and prevention systems that are common for servers on the Internet. However, firewalls or other types of gateways can be used to protect these devices from traffic coming from outside the local network.
The problem addressed in this thesis project deals with how to design, implement, and evaluate a message authentication extension to CoAP for constrained devices. This solution must be both secure and economical with the resources of the system. Several important aspects have to be taken into consideration in order to ensure that the proposed extension is secure. First, it should be based on well tested security concepts, i.e., concepts that have been proven over time. Furthermore, authentication must be provided in an efficient manner. When it comes to resource usage, the extension should use code that has been optimized to reduce the amount of memory necessary to ensure that the resulting code will fit into the available memory of the device in question. In addition, the code should be adapted to minimize the required processing power. This can be accomplished by careful selection of algorithms and by reducing the size of fixed arrays and other memory structures that is used. Note that the extension may trade FLASH storage for processing, as generally, microcontrollers have increasing amounts of flash memory – but want to avoid either increasing their processor clock rates or requiring a much larger random access memory (RAM) – as both take additional dynamic power. The amount of RAM available is typical less than the FLASH storage and this limits what session information and other dynamic data that can be allocated and stored in RAM. However, some data has to be kept for each connected device in order to keep track of the session state and which keys are being used.
Short Message Authentication ChecK (SMACK) is an extension of the Constrained Application Protocol (CoAP) [5] specialized for providing message authentication in a resource efficient manner. The methods used to provide this are general and can also be adapted to other communications protocols. Currently a prototype implementation of the SMACK authentication extension to CoAP exists (written in Java). It has been developed internally at SICS as a proof of concept (see beginning of Chapter 3). However, this implementation cannot be tested on most constrained devices since they have insufficient resources to run the required Java virtual machine, hence for such a constrained device there is a need for an optimized implementation in C. This means that a version of this extension written in C needs to be created, tested, and evaluated on constrained devices. This version should be deployed on actual constrained devices for performance testing.
SMACK needs to be discussed in the context of other authentication protocols. An energy efficient authentication protocol should lessen the severity of any DoS, such as a denial of sleep attack, since data that is not authenticated could be ignored by the device. Ignoring such data allows devices to reduce unnecessary message processing and only reply to legitimate requests. However, the resources used for authentication can be part of a DoS attack, hence we need to minimize the energy consumed by this authentication process. As there are a number of alternative protocols for authentication and confidentiality that could be used with CoAP, some of these protocols will be described and contrasted to the solution presented in this thesis.
Introduction | 3
1.3 Goals
The following goals are the main objectives of this project:
1. Implement the SMACK extension to the CoAP protocol in C,
2. Optimize and adapt the implementation to run well on constrained devices, 3. Test and evaluate the performance of the extension on actual constrained devices,
4. Describe other existing alternatives for authentication and how they differ from SMACK, 5. Compare SMACK to vanilla CoAP with practical experiments on constrained devices, 6. Test the system to see that it ensures proper authentication, and
7. Take into account the above test results to improve the extension wherever possible.
1.4 Research methodology
This project has selected a quantitative research methodology because the nature of the topic is suitable for statistical analysis. For instance, the round trip time for a CoAP request with the SMACK extension enabled versus a vanilla CoAP request can be compared. Additionally, we can compare and evaluate the performance of the SMACK extension by collecting data about the time spent performing specific calculations. As the goal of this thesis is to evaluate the SMACK extension to CoAP a quantitative research method is most suitable. The project also considered a qualitative methodology; however, it was rejected as quantitative data and statistical analysis of performance are important. The possibility to automate testing and analyze the results of this testing in a consistent manner favors a quantitative approach.
This project uses a deductive approach to investigate the hypothesis that the SMACK extension to CoAP is a viable option for lightweight message authentication on constrained devices. The basic functionality of the SMACK extension will be tested and verified to work. In addition, the question of to what extent SMACK and in which areas SMACK is superior or inferior to existing systems will be discussed. Existing systems will be evaluated based upon external resources, while SMACK will be analyzed using experimental data.
Empirical research will be performed as a part of this project, thus generating experimental results and data. The project will also utilize secondary sources to acquire information and allow analysis of systems that are not available for direct experiments. Comparison and evaluation of SMACK versus vanilla CoAP will be done using new data collected explicitly for this purpose. Results from these tests will be presented using statistical methods to highlight the performance of the different solutions that have been tested. The hardware used for the tests will be identical and care will be taken to measure equivalent processes relevant to each solution in order to ensure a fair comparison.
1.5 Delimitations
This thesis focuses on issues related to CoAP and authentication protocols implemented at the application, transport, or network layers. There are also methods for authentication and encryption in the lower layers of the protocol stack, such as those built into IEEE 802.15.4 [6] - used by 6LoWPAN. Further details of 6LoWPAN are given in Section 2.6 and relevant details of IEEE 802.15.4 are given in Section 2.6.1. However, these solutions rely on the fact that the underlying network utilizes a specific technology. Most devices connected to the Internet utilize versions of Ethernet that do not support similar functionality. In order to make the proposed solution as general as possible, authentication should be implemented at the network or higher layer. Protection at higher levels also provides end-to-end security, which is important for many applications. Additionally, because the IPv4 and IPv6 protocols are so ubiquitous the solution should be compatible with these network layer protocols, thus this compatibility is a minimum requirement. Therefore the proposed solution does not rely on any specific lower layer technologies. However, we can of course learn from the mechanisms that have been applied at these lower layers (see for example Section 2.6.2).
4 | Introduction
The Contiki operating system (OS) will be used as a basis for the implementation of the authentication extension to CoAP. Section 2.5 gives relevant details of Contiki. Contiki currently has a fully functional CoAP implementation named Erbium (see Section 2.5.1) that is used as a basis for the proposed SMACK implementation. Furthermore, Contiki supports a large number of hardware platforms [7] and is a widely used OS for constrained devices. Contiki is open source software; hence all of the relevant source code is freely accessible. In addition, Contiki has a development environment that includes the Cooja network simulator (see Section 2.5.2). This simulator facilitates testing of applications. The evaluation considers the feasibility of the SMACK extension for authentication independent of the underlying hardware platform. However, benchmarks are used to understand how this authentication protocol performs in comparison with other potential alternatives when actually running on constrained devices.
1.6 Structure of the thesis
The thesis started with a chapter setting out the problem and goals to be addressed in this thesis project. Chapter 2 provides the background knowledge required to understand the topics discussed in the rest of this thesis. This includes technical background concerning existing protocols for authentication that could be used together with CoAP. Chapter 3 describes the design of SMACK and the details of how performing authenticating with it works. After this, the development environment used and information about how to develop for Contiki are given in Chapter 4. This same chapter describes the methodology and design methods used to create a C implementation of the SMACK protocol. The focus of this chapter is on several of the challenges encountered during the development process. Chapter 5 analyzes the results of the implementation described in the previous chapter and compares the proposed solution with alternatives. The thesis concludes in Chapter 6 with a summary of conclusions, suggestions for future work, and a description of some of the ethical, social, economic, sustainability, and other aspects of this thesis project.
Background | 5
2 Background
This chapter contains background information concerning several concepts and tools used this project. Some of these concepts and tools are described in further detail in later chapters. A key aspect underlying this thesis project is the hardware of the constrained devices on which the authentication software is deployed. Another important topic is the software employed during the development and coding phases of this project. Several alternatives for implementing security on constrained devices exist. Some of these are the same protocols used on the Internet and some are protocols that have been adapted or even custom made to function better on constrained devices. The chapter concludes with a description of a number of different communications protocols and standards, as much of the thesis deals with these protocols. Details of these protocols are necessary in order to consider the solutions that have been chosen.
2.1 Constrained Devices
For the purpose of this thesis project, a constrained device is defined as a device that has limited resources in the form of hardware, such as memory, processing, and power. The available power is frequently limited capacity batteries. Furthermore, constrained devices often utilize networks with limited available bandwidth. Combining these factors means that memory usage, algorithm efficiency, and low bandwidth communications are important issues. As power consumption is reduced in sleep mode, these devices typically rely on rapidly transitioning to different levels of sleep when possible, thereby minimizing their battery power usage. Because some components draw more power than others do, it is especially important to optimize the power management of these components. The radio is normally the component that uses the most power and thus keeping it in sleep mode as much of the time as possible is quite important [8].
Sending data is more costly than doing calculations locally. Measurements by Madden et al. have shown that on some systems transmitting one bit is the equivalent of executing 800 instructions [9]. Because of this, the radio should be in sleep mode as much as possible and communications should be kept to a minimum. Often constrained devices are used as sensors or actuators, they generally have limited to no user interaction. This means that they are to a large extent autonomous, sending and receiving data only as necessary. Such M2M communication is different in character and pattern from user-induced communication. If some part of the system malfunctions or an attacker starts sending data to a node, then the node can be tricked into accepting incorrect data readings and the battery could be rapidly drained by keeping the radio constantly listening. In automated systems this might not be noticed until the battery is exhausted, unless the system is designed to inform a management systems of such an apparent attack.
Figure 2-1 shows a typical example of a constrained device in the form of the Texas Instruments’ (TI) CC2538 board attached to a SmartRF board. This combination is frequently used for development purposes. This particular board has a maximum clock speed of 32 MHz [10]. There are constrained devices that are even more limited with regard to resources. For instance the Tmote Sky only has a 8 MHz processor and 10 kB RAM [11], whereas the CC2538 has maximum of 32 kB of RAM (depending on the specific model of this chip). Typically, constrained devices clock the processor at a lower clock rate to reduce power consumption and because they have less demanding computational requirements, thus draining the battery at a slower rate than when clocking the processor at a high rate.
6 | Backg Figure 2
2.2
The Con applicati for use bandwid multicas exchang autonom maintena initiated in a mor can also the radio CoA CoAP fo resource Resource provide subset of response Content" with HT One Protocol drawbac guarante message arrived c CoAP ca an implo session function ground 2-1: TexasCoAP
nstrained Ap ion level of t with constr dth or proce t support, es [12]. An mously comm ance of the by a person re arbitrary p help since i o so as to onl AP is quite si ollows a sim es, and thee Locators (U data from a f the same m e codes follo " and a reply TP, CoAP h key differen l (UDP); in ks, but also ees has to b es" to specify correctly. Th an utilize mu osion of ack with receiv ality UDP pr s Instrumen pplication Pr the Transpor rained device ssing power optimization n important municate wi devices. Th . For instanc pattern where it is easier to ly operate wh milar in stru mple request/ other device URL) are use
temperature methods (in th ow the style y when no co as many oth nce between contrast, to provides som be implemen y that a mes here are also ulticast traffic knowledgeme vers, as is d rovides. ts CC2538D rotocol (CoA rt Control Pro es that suffe r. Key featu ns for use use case ith each oth his kind of t ce, the traffic eas machine o predict wh hen commun ucture to the H /response mo e as a serve ed to identify sensor on a he form of G e of HTTP w rresponding her response HTTP and C HTTP which me benefits. nted by the sage must re o non-confirm c since it ma ents. This m done when DK AP) [12] is otocol (TCP fer from lim ures include on constra for CoAP her – norma traffic has d c pattern can communica hen to expect nication is ex Hypertext T odel that allo er providing fy resources. device at the GET, PUT, P with a reply resource wa codes for va CoAP is that h uses TCP One drawba application eceive an ac mable messa arks such me means that Co using TCP, a communic P)/Internet pr mited resourc low overhe ained device is M2M ally without different char differ since tion can be e t the next tra xpected.
ransfer Proto ows one dev g some reso For instance e host named OST, and DE containing as found uses arious scenar t the transpor . This choic ack is that th on top of cknowledgem ages that do ssages as no oAP refrains , but rather cations proto otocol (IP) s ces, specifica ead and com es, and asy communica t human int racteristics t humans tend extremely re ansmission a ocol (HTTP) vice to act a urces. As w e, coap://exa d example.co ELETE) that a resource u s "4.04 Not F ios. rt protocol us e of transpo he reliable tr UDP. CoA ment to conf not require n-confirmab s from creati it builds u ocol operatin stack. It is sp ally limited mplexity, un ynchronous ation where nteraction ap than commu d to request r egular. This r and thus pow
), but is less as a client, re with HTTP, ample.com/te om. CoAP al t HTTP emp using the co Found". As is sed is User D ort protocol h ransmission AP uses "con
firm that the such a conf ble and thereb
ing a comm upon the se ng at the pecialized network icast and message devices part from unications resources regularity wer on/off complex. equesting Uniform mp could lso uses a loys. The ode "2.05 s the case Datagram has some that TCP nfirmable message firmation. by avoids munication essionless
The protocol by not u The abil actions s reduce th isolated the latest Figure 2 Tabl and has protocol overhead may req only 4 b can be se bytes. Th networks networks Table 2-Field Ver T TKL Code Message Token Options Payload Payload properties o with a simp utilizing the lity to speci such as check he need to s lost message t value until 2-2: CoAP le 2-1 summa few mandat . CoAP allo d, but an app quire confirm ytes. The ma ent unfragme he standard s, as the act s limit link la -1: Fields e ID Marker (0xF of CoAP are ple packet str acknowledg fy whether king a senso switch the ra e is not cruc the next sch P Packet stru
arizes the dif tory fields. T ows an app plication can mation from t aximum reco ented in an IP also specifie tual path MT ayer frames t s of a CoAP Size in FF) e well adapte ructure (see F gements sent messages re or value frequ adio on (thus cial since a m eduled senso ucture [12] fferent fields The fact that plication to n also send m the receiver. ommended p P packet. Th es that assum TU is diffic to only 127 b packet n bits De
2
Ve2
Ty ack4
Le8
M16
M0-64
Co Sim M8
M Da ed to constra Figure 2-2). t by TCP the equire confir uently witho s helping to missed readin or reading. s of a typical t many of th send small more compl . The size o payload size his assumes a ming lower v cult to determ bytes [12]. escription ersion of CoA ype of messa knowledgme ength of toke Message code Matches reque orrelate requ milar to opti Message type, Marks start of ata ained device Using UDP e protocol re rmation mea ut inducing minimize po ng will simp l CoAP pack he fields are non-confirm ex packets w f the manda is 1024 byte an IP Maxim values may mine with c AP used age: confirma ent, or reset en field in by (such as 4.0 est/replies est/response ons of HTTP proxy option payload es in that it i reduces per educes comm ans that devitoo much ne ower consum ply mean tha
et. This pack optional ma mable mess with options tory header es to ensure t mum Transfer be beneficia ertainty. In able, non-con ytes (0-8 byte 4) P ns, cache ma Backg is a relativel r packet over munication o ices can do etwork traffic mption). Typ at the system ket structure akes CoAP a ages with m (including d of a CoAP that the CoA r Unit (MTU al, especially addition, 6L nfirmable, es) ax age, … ground | 7 ly simple rhead and overhead. common c and can ically, an m will use is simple a flexible minimum data) and packet is AP packet U) of 1280 y on IPv4 LoWPAN
8 | Backg Matt and spec Californi GitHub c any meth be used CoAP. A CoAP w described R 2.2.1 Represen prominen Roy Fiel the diffe (WWW) accessed to access HTTP/1. One on a res Protocol function architect operation publishin C 2.2.2 In an ex Protocol protectio CoAP ot Accordin possible function used by be used f Thei Encrypti Cipher B and conf cipher, a additiona Table 2-In co CoAP sp 4 bytes. point of utilized b overhead as oppos for each ground thias Kovats cifically Con ium CoAP J code reposito hod for auth
as the main At the time was an open r d in Sections REST ntational sta nt example b lding in his erent compo ) be can be s d using the H s web conten .1 as can be s of the centr source, typic l (SOAP) tha s are define ture is that it ns. As CoAP ng resources CoAP Sec xpired Intern l (CoAP) op on, and encr ther than the ng to their d
to negotiate ality is impl the sender to for the encry ir draft only ion Standard Block Chaini fidentiality t authenticatio al overhead 2 (in additio ontrast, the S pecification t As the netw f view, it is i by the nodes d is a large m sed to a few message. sch has contr ntiki. Both Java library w ory and a Co hentication. I method for of the start research que s 2.2.2 and 2 te transfer ( being HTTP doctoral dis onents of sy said to be a HTTP protoco nt according seen in chap ral ideas of R cally an URL at uses arbitr ed using XM t is lightweig P is similar . curity opt net-Draft A. tions that ar ryption for th e two securit draft, differe between the lemented by o request dif yption or auth y mentioned d (AES) encr ing-Message to data [19]. on of data, a - since each n to the norm SMACK exte that allows fo work links us important to s. If the pay majority of th larger ones, ributed a lot the Erbium were written ontiki fork fe nstead, the D achieving se of this thesi estion. A pot 2.2.3. (REST) is a P and the Wo sertation in stems, inclu system base ol with a lim to fixed rule ter 6 of Field REST is to re L. One of t rary keyword ML and then ght and less c to HTTP, C tions Yegin and re used for p he CoAP m ty protocols ent cryptogr e sender and defining ne fferent securi hentication. the Counte ryption func Authenticat Positive asp and full enc h encrypted/ mal CoAP he ension does n or a token fie sed by the co o minimize th load of the t he data conta , is particula to CoAP im CoAP imp n mainly by h eaturing Erbi DTLS protoc ecure commu is project, th tential solutio system arch orld Wide W 2000 [15]. In uding how t ed upon URL mited number
es. The idea b ding’s disser ely on specif the main alte
ds or functio n executed a complex bec CoAP also ut Z. Shelby providing da messages.” [1 (IPsec and D raphic algori receiver wh ew options f ity levels an er with CBC ction. In esse tion Code (C pects of this cryption of t /authenticate eaders and pa not require a eld of 0-8 by onstrained de the overhead transmitted m ained in each arly sensitive mplementatio plementation him [13]. He ium [14]. By col (describe unication, in he best way on utilizing n hitecture use Web in gener n essence, R hey can bes Ls that allow r of operatio behind REST rtation [15]. fic keywords ernatives to on names for against data cause of its r tilizes the R proposed “a ata origin au 7] They def DTLS) ment ithms should hich algorithm
for the CoAP d to commun C-MAC (CC ence CCM c CBC-MAC) a approach ar the data. Di ed packet m ayload). any additiona ytes of which evice are oft d low, thus m messages is h sent packe e to big over ons, work on for Contiki e is the owne y design, the ed in Section ncluding auth to impleme new CoAP o ed by many ral. REST w REST tries to st interact. T w objects sto ns (GET, PU T heavily inf s or operation REST is Si r executing o [16]. One b restricted set REST paradig a set of Con uthentication, fined a new tioned in the d be support ms will be us P header. Th nicate data th M) mode [1 combines the algorithms to re strong sec sadvantages must include al overhead w h SMACK by ten constrain minimizing t small, cases et. Sending m head since th n constrained i and the st er of the Ca CoAP proto n 2.10) is exp hentication, ent authentic options for s Internet pro was first pres o define and The world-w ored at websi UT, POST, D fluenced the ns to perform imple Objec operations. I benefit of th of predefine gm for acces nstrained Ap , integrity an method for e CoAP spec ted and it s sed. The new hese new he that will subs
18] of the A e Counter (C o provide aut curity using include 30 the values s when compar y default onl ned from a b the processin s can occur w many small m the overhead d devices, tandalone lifornium ocol lacks xpected to on top of cation for ecurity is otocols, a sented by d describe wide web ites to be DELETE) design of m actions ct Access In SOAP, he REST ed simple ssing and pplication nd replay securing cification. should be w security aders are sequently Advanced CTR) and thenticity the AES bytes of shown in red to the ly utilizes andwidth ng power where the messages, d is added
Table 2-C 2.2.3 Another identifie DTLS p specifyin of protec security propose allows fo The based on authentic AES and proposal 2.2.2). This Security to be app A Secur certificat encryptio encrypte different Table 2-Name Security Security SecurityE As c The calc byte pay paper is However slower fo usage of to packe are signe -2: Yegin CoAP Gra similar app s some key provides is a ng exactly w ction or to u DTLS prov an applicatio or intermedia encryption n the well-k cation and co d AES is fre ls for 6LoW s approach re On option is plied and inc rityToken op tes, or Kerb on paramete ed data. All o t options is sh -3: Granu On Token Encap can be seen culations by yload (the m faster when r, if all the p for a given am f each solutio ets (specifica ed and encry n CoAP Secu C N M O T anular sec proach is pro problems w applied to al which packets use different vides can int on-layer secu aries, such as algorithm u known AES onfidentiality equently use WPAN use th elies on defi s added to ea cludes other f ption is used beros tickets ers including of these optio hown in Tab ular security in the table, Granja, Mon aximum size taking advan payloads are mount of ban on and notes ally only requ
pted. urity Option Name Context ID Nonce MAC OptionCount Total curity oposed in a with the exis
ll packets in s should be p algorithms f terfere with urity solution s gateways. used to provi algorithm an y. In fact, co ed to protect his algorithm fining new h ach protected features, such to provide s. Another f g a nonce v ons are on a ble 2-3. y options Size (bytes) 30 bytes (as Minimum 1 Nonce (12 b , the amount nteiro, and S e to avoid 6L ntage of the encrypted a ndwidth than that their pr uest/replies) ns fields t paper by Gr sting CoAP-n a sessioCoAP-n protected. Th for certain pa gateways an n that is mor ide security nd uses the onstrained de t traffic at t m (including header option d packet. Thi h as timestam identity data field named value, Mess a per-packet b ) ssuming 20 b byte + varia byte) + optio t of overhea Silva state tha
LoWPAN fr granular con and signed, th n CoAP with roposed solu but is slowe Size (bytes)
1
12
16
1
30
ranja, Monte -DTLS secu and there is here is also n ackets. Final nd proxies u re flexible w is by defau CCM mode evices often h the link laye g the securit ns for the C is option spe mps that help a, including SecurityEn sage Authen basis. The es byte URI) able identity onal MAC (8 d depends o at overhead ragmentation ntrol and pro hen the max h DTLS. The ution is only er than CoAPeiro, and Sil rity solution s no provisio
no way to sp lly, the end-t used with Co with regard to ult AES-CCM e of operatio have built in er. Many of ty options m oAP protoco cifies the det p to protect a username/pa cap contains ntication Cod stimated ove data byte) + vari on the securit can be betw n). The propo otecting only imum messa ir measurem superior whe P with DTLS Backg lva [20]. Th ns. First, the on for granu pecify differe to-end transp oAP. Theref o security op M. This alg on that provi hardware su the existing mentioned in ol to add se etails of the p against replay assword, pub s authenticit de (MAC), erhead induc iable encrypt ity option(s) ween 11-55% osed solution y some of the
age rate per ments show th en selectivel S if all of th ground | 9 heir paper e security ularity or ent levels port layer fore, they ptions and orithm is ides both upport for g security n Section curity. A protection y attacks. blic keys, ty and/or and any ed by the ted data selected. of an 88 n in their e packets. second is he energy y applied e packets
10 | Back
2.3
Californi Erbium ( to CoAP the com oriented great ext of the Co the new The developm unsuitab has. In c provides extension future w use any CoAP m accessing2.4
Maven i the GNU that defi easily co changes many int Maven a find not to fail.2.5
Contiki written a on the In on conne operating Memory uIPv6 th Cont efficient mix an e for threa compare low pow sensor ne E 2.5.1 There is named E C. It is w has been takes int kgroundCalifor
ium is a CoA (see Section P draft versio mpatibility w architecture tent [23]. Th oAP draft, s drafts norma resulting Ja ment. One d ble for constr contrast, for s a highly f ns. Another work in the re form of auth messages; how g such resouMaven
s a tool for U "make" co ine the build ompiled and and quickly terdependent also executes only obviouContiki
is an operat at SICS main nternet of Th ecting device g system an y (ROM). Co hat was jointltiki is open s way to impl event driven ading whilst ed to conven wer radio netw
etworks are a Erbium an impleme Erbium and it written by M n tested to en to account t
nium
AP implemen 2.5.1), is th on 11 and hasith the CoA with the log his implemen ince the prot ally try to av ava library drawback is t rained device developmen functional li drawback i eport on Cal hentication. wever later v urces using th simplifying mmand for c d process and developed u recompile th t classes as th s a number o us errors in th
i
ting system nly by Adam hings. Their b es to smartph d can functi ontiki is also ly developed source and fe lement rudim and linear m maintaining ntional fully working and additional ad entation of C t supplies a f Matthias Kov nsure that it f the need to ntation writte e main autho s been tested AP specificat gic split into ntation also atocol is still oid major ch provides a that the lang es because o nt on a PC o brary that c is the lack o lifornium [23 Other system versions of C he “coaps://” the building compiling so d any depen using the M he project. T he design go of built in tes he code but specifically m Dunkels. H business idea hones in a co on on devic o known for d with Cisco a eatures other mentary threa model of exec a low mem multi-thread d power prof dvantages. CoAP includ fully function vatsch, the sa follows the la reduce pow en in Java. M or of Califor d for compati tion [22]. Th several parts attempts to b changing rap hanges to the baseline im guage chosen of the high re or another d can be used of any secur 3]. By defau ms have to b Californium s ” designation g of Java bas oftware [24]. ndencies [25] Maven utility. This tool is he oal is to creat sts when com also to find created for He is current a is to provid onvenient fa ces with as li having a sm and Atmel [2 r innovative ading). Basic cution [27]. B mory footprin ding systems filing [28]. L
ded with the ning version ame author atest (at the t wer usage an Matthias Kov rnium [21]. C ibility at vari his impleme s and employ be backward pidly via fre e protocol’s f mplementatio n for this im equirements device that su d as a base rity solution ult, messages be used to pr started to imp n. ed applicatio . Maven is b ]. Californium This makes elpful since C te a modular mpiling softw subtle proble use on con tly CEO of T de interconne shion. Conti ittle as 10 kB mall impleme 26]. technologies cally prototh Benefits of th nt and also in . Other func Low power re Contiki sou n of the CoAP who created time - 2012) nd is presen vatsch, one o Californium ious so calle entation follo ys abstraction ds compatibl quently relea functionality. on that can plementation the Java Vir upports Java for a CoA , this drawb are sent in rovide secur plement DTL ons. In some based on XM m is distribu s it easy for Californium r and layered ware, this me ems that cau
nstrained dev Thingsquare, ectivity of th ki is a very r B of RAM a entation of th s, such as pro hreads are sta hese technol n many cases ctionality sup equirements rce code. Th P protocol sp d the Californ CoAP draft. nted as a "lo of the main a currently sup ed plugtests t ows a typic n and modul le with older ased drafts. A . be used fo n was Java, rtual Machin a this implem AP applicatio back is ment clear text an rity to the tra LS support a e ways it is s ML configura uted in a for a developer is quite larg d design solu eans that it is use the test c
vices. It was , a company hings, mostly
resource con and 30kB R the IPv6 stac
otothreads (a ackless threa logies includ s reduced co pported by C and solid su his implemen pecification w nium library . This implem ow power C authors of pports up that grade cal object larity to a r versions Although or further as this is ne (JVM) mentation on or for tioned as nd do not ansmitted and allow similar to ation files rm that is r to make e and has tion [23]. s easier to onditions s initially focusing y focusing nservative ead Only ck named a memory ads which de support omplexity Contiki is upport for ntation is written in y. Erbium mentation CoAP for
Contiki" such as t - while improve full CoA Erbiu protocol Erbium’ impleme efficientl compare ContikiM I 2.5.2 A develo Contiki. image im software developm working of the Ub Inclu whilst co and dev monitori dynamic start run with diff client on By l nodes ca simplify as if they and there directly ensuring Furth the captu as Wires traffic an running the CoA Wireshar fields in The capturing other via slows do This is p [29]. This i the ContikiM still retainin message ha AP implemen um employs s following s memory entation with ly while hav ed to a naiv MAC. Instant C opment imag This image mmediately e for Contik ment environ on Contiki d buntu Linux uded in the i ommunicatin velop softwa
ing the netw cally compile nning the spe ferent applic n another or m loading a clie an easily be ies analysis o y were real p e is even a s collecting th g that the pro
hermore, Co ured traffic t shark. This i nd communic under Contik AP requireme rk has a very a packet and alternative o g network tr a radio. The own repeated particularly implementati MAC mechan ng the abilit andling, supp ntation for Co s the built in the REST c footprint si h the Contik ving a small ve implemen Contiki an ge file calle file can be lo provides a d ki. This ima
nment. Insta development distribution. image is a n ng with each are for the work traffic t es the entire ecified applic cations runni more advanc ent process o e simulated of the behav physical devi simple Comm he text outpu gram behave ooja supports to external P is useful bec cation with o ki can easily ents and late y mature pac d Wireshark of analyzing raffic can be e process of d cycles of e true when t
ion takes ful nism that ens
y to commu port callback ontiki is arou n REST eng communicati ince code r ki radio opti memory fo ntation that nd Cooja d "Instant C oaded into vi developer w ge file inclu ant Contiki i t and new ap . network simu h other. The Contiki plat to analyze w Contiki sour cations on th ng on the no ced topologie on one node and monitor vior of the ex ices. Various mand Line In ut from each es correctly. s sniffing of Packet CAPtu cause this pr other nodes. be captured er that they ket-parsing e supports par the softwar e a problem transferring editing and t the developm ll advantage sures the radi unicate effic k functions, und 2600 line gine of Cont ion architect reuse is hi timizations r ootprint and does not ta Contiki" is p irtualization with all the t udes the ful is the recom pplications. T
ulator for sim simulator, n tform. It su what data is urce including
he simulated odes, for ins es.
and the serv red. One of xecuting prog s ports and in nterface (CL h node in the network traf ure (PCAP) roject, and m In this way, d and the rele
correctly ut engine that s rsing of CoA re on actual when the b a program t testing that ment method e of other op io is switched ciently. It al and asynchr es of C code tiki allowing ure, such as igh. Erbium resulting in offers energ ake advantag rovided to f software, su tools needed ll Contiki so mmended sys
The image its
mulating a n named Cooja upports extra being sent o g any chang d nodes. Cooj stance a serv ver on anothe the main b gram(s). For nput/output d LI) available e simulation ffic generate files that can most applicat
the network evant fields c tilize the ne shows the nam AP messages. hardware is boards are co to the board can be nece d relies on m ptimizations d off for as m so uses prot ronous recep . g developers HTTP and m combines a system th gy savings of ge of the b facilitate dev uch as VMwa d to start de ource code stem for dev self is based
network of no a, allows dev acting statist over the netw
es or additio ja can simul er applicatio er node inter enefits of u instance, no data can be m
for each nod n. This helps d by the sim n later be inp tions of Con k traffic gene checked to se w extension mes and dec
more cumbe ommunicatin ds for testing ssary when making incre Backgr that exist in much time as tothreads in ption of pack s to easily im CoAP. This an efficien hat can com
f up to 26 ti benefits conf veloping soft are [30]. Loa eveloping an and a preco velopers to u on a standar nodes running velopers to e tics from no twork. Startin ons made. It late various on on one no raction betw using Cooja odes can be m monitored fro de. A major s with debug mulation and nput to progr ntiki, rely on erated by CoA ee that they b ns SMACK coded values ersome, espe ng directly w g also takes developing emental cha round | 11 n Contiki, s possible order to kets. The mplement s reduces nt CoAP mmunicate imes [29] ferred by ftware for ading this nd testing onfigured use when rd version g Contiki easily test odes and ng Cooja will then networks ode and a een these is that it monitored om Cooja benefit is gging and dumping ams such n network AP nodes both meet provides. of all the ecially as with each time and software. anges and
12 | Back testing w connecti Seve can easil complica concurre Alternati and the t propertie stack, th interfere
2.6
IPv6 ov protocol standard function UDP) [3 low pow This com common hexadeci combina sender a header c compres optimize A 2.6.1 6 The IEE enables Control to an ap transmis integrity MAC lay An i traffic fr When us traffic fr beyond t packets different link laye case with * As cons hardware kground whether the f ing to them v eral configur ly be loaded ated sensor ently. The simively, Cooja transmission es of the rad hus the simu ence and sign
6LoWP
er Low pow to facilitate d that specifi s of 6LoWP 32][31][30][3 wer networks mpression te n knowledge imal) could b ation of sour and receiver compression sed addresse ed to function Authentic 6LoWPAN EE 802.15.4 authenticatio Lists (ACL) pplication to sion. An app y protection yer provides issue when u rom outside, sing ACLs t rom it. Whe the gateway are authentic tiation of sou er technology h the MAC a strained device e platforms. functionality via Universal ration files a d into Cooja networks w mulation canhas the abil n properties o
dio medium ulator is prim nal loss will n
PAN
wer Wireless e operation i fies the oper PAN is comp
31][30]. The s that are con echnique wo
of IPv6 add be a replacem rce and desti
addresses in n [32]. Devic es for comm n well with D cation an N standard pro on and encr that can filt o request an plication can or full conf this function using ACLs there is no w the nodes ha en traffic arr cannot diffe cated. In con urces and aut
y. Higher la address. es have limite is still corre l Serial Bus ( and programm a. Cooja can with more th n be on a hig lity to simula of the radio
are not rele marily used t not be param s Personal A in low powe ration on the pression of t e purpose of nstrained in orks by splitt dresses and o ment and com ination IPv6 nstead of 32 ces can set
unication. T DTLS [33].
nd encryp
ovides suppo ryption at th ter which dev nd set the r n signal to th fidentiality (v
nality as a se is that when way for the i ave to either rives from d erentiate betw ntrast, a secu thentication s yer addressi ed amounts of ect. Extractin (USB) and re ming examp n simulate bo han 10 nod gh abstract le ate lower lev
medium can evant, as CoA to evaluate c meters in the s Area Networ er wireless n e physical a the IP heade f this compre terms of ban tting commu other metada mmon repres 6 addresses. bytes that w up such a There are spe
ption built
ort for encryp he MAC lay vices are allo required sec he MAC laye via encrypti ervice. n one node a internal devic r accept all t different com ween these s urity solutio since a highe ing informati f RAM it may ng the outpu etrieving the ples are inclu
oth simple c des with all
vel, i.e., con vels - since e n be specified AP operates code at the a simulation. rks (6LoWP networks [31 and media ac rs and heade ession is to r ndwidth and unications in ata. For insta sentation for In this way would otherw context and cific adaptio t into IEE ption of the yer [6]. It a owed to com curity param er that the ne ion) of the p cts as a gate ces to know the traffic fr mputers con sources nor c on working o er layer solut ion is also n be difficult to ut from board ir output*. uded in Insta client/server of these n ncerned with each node ha d [30]. For th on higher l application l AN) is an a ]. It relies o ccess layers ers from oth reduce the b time availab to separate ance, the con a specific IP only 1 byte wise be neces d then rely ons of this co EE 802.15 transmitted lso includes mmunicate in meters in the ext packet to packet’s con
eway for the from where rom the gate nected to th can they asc on higher lay
tion is unaffe not lost betw
o collect large ds frequently ant Contiki a topologies a nodes comm the applicati as a physical this thesis pr levels of the layer. For th adaption of on the IEEE [6]. One of her protocols bandwidth us
ble for trans "contexts" t ntext 0x01 (d Pv6 address e will be use ssary when n on the abb ompression t 5.4 as use frames. This s support fo n the network e MAC laye be transmitt ntents. After network, by the traffic o eway or reje he Internet t certain if the yers can pro ected by the ween devices log files on th y requires and these and more municating ion layer. l position roject, the e network his reason the IPv6 802.15.4 f the key (such as sage over missions. hat share defined in or even a ed for the not using breviated, technique ed by s security or Access k. It is up er before ted needs this, the y relaying originates. ct all the the nodes received ovide this choice of as is the hese
A se IEEE 80 overall s • • • • • • One This me have to b Bormann security a link w because drawbac needed o security An e traffic go problem end secu to be co authentic specific n Non contents addressin informat correctly rely on th is possib informat In co end-to-en intermed mechani networks scenario when a u applicati for instan if one or degraded E 2.6.2 In the in IEEE 80 nodes. T ecurity analy 02.15.4 imple security inste • Using th • Losing A • Poor pra • Shared k • Modes th • Insuffici downside o ans the prot be set up for n argue in t the data rem with reduced many netwo k is that dat on top of wh solution for example of p oing to the n is what hap urity, as traff oming from cation in a la node, then th etheless, the following t ng informati tion in the I y by each int he destinatio ble for the en tion for highe ontrast to lay nd security diate devices isms to func s where the s, IoT devic user remotel ion layer me nce: IEEE 80 r more devic d, at least for Exploitin nterest of min 02.15.4 encry This would ysis presented ements secu ead of increas he same key f ACL state at actical suppo keying destro hat employ e ient integrity f the authent tection is onl r all devices their book " mains vulnera security, or w orks do not ta will be un hat IEEE 802 LoWPAN n potential sec node will be ppens to the fic may be m an authentic arger group, he keys for th ere are advan
the IEEE 802 on and head IP-header si ermediate de on IP address ntire data pay er layers can yer 2 security since they a s do not hav ction proper re the end d es will recei ly reads som echanism me 02.15.4 and ces in the ne r well-design g IEEE 80 nimizing pow yption and au split the se d by Sastry urity. They e sing it. Some for multiple A power failur rt for group k oys replay pr encryption bu protection. tication supp ly for a spec in the netwo "The Wireles able in certain when data is use IEEE 80 nprotected at 2.15.4 provid etworks to co curity risks i e authenticat traffic at the modified at th cated device thus if these he entire gro ntages to imp 2.15.4 heade ers of higher ince this inf evice (i.e. rou s to determin yload and for nnot be tampe
y solutions, I are based on ve to share k ly. This can device ower ive packets f me value or re
ans that man IEEE 802.3 etwork are c ned security p 02.15.4 e wer consump uthentication ecurity into & Wagner [ even state th e of the poten ACL entries res, keying, rotection, ut not authen
port built int cific link. Fo ork if end-to ss Embedde n situations. s forwarded 02.15.4 all t t some point des. As a re omplement o is the case w ted and traff e node itself. he node but w e. Furthermo e keys are co oup will be ex plementing se er are protec r layers are p formation is uter). Router ne the next-h r the MAC h ered with, i.e IPsec (see Se n the networ keys or be in n be a grea rs/operators from a remo reconfigures ny different t Ethernet link compromised protocols. encryptio mption, it wou n, thus reduc two parts, 34], found s hat some of ntial security , ntication, and to IEEE 802. or this reaso o-end security ed Internet" This is true at the netwo the way from
or that an a sult they rec or replace IE where a node fic coming fr . The problem will still app ore, IEEE 8 mpromised, xposed to the ecurity at lay cted by the s protected. In necessary f rs must know op. Another headers them e., it has inte ection 2.7) an rk or applic nvolved in a t advantage lack control ote device ov an appliance types of netw ks. End-to-en d the securit n and aut uld be benef cing the need rather than some security the options y issues listed d .15.4 is that n, security a y is to be gu that even w when data le ork layer [35 m the sender additional sec commend IPs EEE 802.15.4 e is comprom rom it will b m stems from pear to other 02.15.4 supp perhaps by a e attacker. yer 2. One is security opti contrast, TL for the mess w where to fo benefit is tha selves. As a grity protect nd the SMAC ation layer. any way in o when deali l, such as th ver the Intern e at home. F works can ea nd security a y of the end thenticat ficial if the g d to do this a n providing Backgr y problems w available re d in their pap it is at the li associations uaranteed. Sh with strong l eaves a link, 5]. This is no r to the rece curity system sec as a goo 4. mised, as in be authentica m the lack o nodes in the ports group a physical at
s that the ent ions. This m LS can not en sage to be orward the pa at integrity p result, the ad tion. CK extension This means order for the ing with tra he Internet. net like, for Furthermore, asily carry th also ensures d-to-end traf tion gateway imp at higher lay end-to-end round | 13 with how educe the per are: ink layer. and keys helby and link-layer traverses oteworthy iver. The m will be od layer 3 this case ated. The of end-to-e nend-to-etwork keys for ttack on a tire frame means that ncrypt the delivered acket and protection ddressing n provide s that the e security affic over In many example, using an he traffic, that even ffic is not plemented ers in the security.
14 | Background
Moreover, it could decrease both the information that needs to be sent over the wireless link and reduce the computations necessary at the constrained device. However, this solution is outside the scope of this thesis project, hence it will not be addressed here, but remains for future work.
2.7 IPsec
Internet Protocol Security (IPsec) is a popular protocol for securing IP traffic with regard to confidentiality (by employing encryption), data integrity, and origin authentication. Its main purpose is to protect data in IP packets by defining the steps and protocols to achieve this. The protocol was first standardized by the Internet Engineering Task Force (IETF) in 1998 in RFC 2401 [36] and further updated in RFC 4301 [37]. This protocol is based upon earlier research protocols*, such as swIPe [38]. Some of these protocols had overly complex specifications [39] and hence it was decided that there was a need for a standardized and secure protocol that would take into account the benefits and lessons learned from the existing options at the time.
One benefit of IPsec is that many different encryption algorithms are supported [37]. Furthermore, IPsec supports key management, session handling, replay protection, and more. IPsec defines a complete security infrastructure that can be used to deploy secure communication. IPsec is a well-tested protocol that is widely used to realize Virtual Private Networks (VPN) [40]. Since IPsec is implemented at the network layer for both IPv4 and IPv6†, it can support any higher layer protocols, such as TCP or UDP. The advantage is that no higher layer protocol needs to be customized to work with IPsec; instead every higher layer protocol can run transparently over an IPsec security association. This is a strong point since it reduces the work needed for adding security to a network. Neither the devices themselves nor intermediary systems need any major modifications to enable IPsec.
Some of the IPsec disadvantages include the fact that it is a quite complex system with many parts. The protocol is dynamic and can support a large number of configurable settings. Unfortunately, this large number of settings makes a complete implementation more difficult to create. The packet overhead for transmitting data is in the order of 50-80 bytes [42]. Performing the encryption and authentication steps also requires processing power. The amount of processing power depends on the chosen algorithm. Because of this IPsec may be impossible to implement on devices that are too constrained in terms of processing capacity or devices with severe limits on available electrical power [43]. The bandwidth overhead can also be a problem in low bandwidth networks, especially when small packets are frequently sent, thus making the overhead a significant part of the total data sent.
2.8 Secure Real-time Protocol
The Secure Real-time Protocol (SRTP) [44] addresses the case where there is a series of small amounts of data that need to be transmitted securely. It supports confidentiality, authentication (optionally), and replay detection - while adding only four bytes to the size of a Real-Time Protocol (RTP) [45] message. It does this by taking advantage of the RTP packet already including a sequence number and timestamp. Note that SRTP can tolerate packet loss. The protocol uses AES for encryption and a Hash-based Message Authentication Code (HMAC) based on the SHA1 hash function. Data confidentiality is realized by replacing the original RTP payload with an encrypted version. As for basing the HMAC on SHA1, even if some collisions or other security issues are found with SHA1, as is the case with MD5, this does not necessarily mean that an HMAC based on SHA1 will be compromised [46].
As mentioned above, the overhead compared to normal RTP traffic is very low. The only new fields defined are an optional field that identifies the master key used and a recommended field with authentication information. Fortunately, RTP already supports functionality typically needed for replay detection and mitigation of other common security flaws in the form of sequence numbers and timestamps. SRTP does not provide confidentiality to the RTP packet headers, the reason for this is to
*
A list of some of this research can be found in the survey: http://web.mit.edu/tytso/www/ipsec/surv9703.html
†
