Two way Firewall for Internet of Things1039014/FULLTEXT01.pdf · Internet-connected critical infrastructures from wireless hosts within 6LoWPAN network. 1.1.1. Security solutions

IN DEGREE PROJECT INFORMATION AND COMMUNICATION TECHNOLOGY,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2016

Two way Firewall for Internet of Things

RENUKA VENKATA RAMANI, CHALLA

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING

AcknowledgementI am thankful to Almighty God for giving me the courage and wisdom to completethis work. I am overwhelmed with gratitude for the continuous support of my parentsChalla Veeraiah & Parvathi, my darling sisters Dr. Archana & Dwarakanjali and mybrother-in-law Gunji Raja Ramesh. Without the moral support and their confidencein me, I wouldn’t have come this far. My heartfelt gratitude to my best friend ever,Viswanath Kumar Sandu for his prodigious support to me I can never forget. I amalways grateful and cannot thank enough for the respect, encouragement and love theybestowed on me.

I am grateful to each and every person in SICS Swedish ICT who guided me duringmy thesis. It has been a very good learning experience working with my supervisor atSICS Dr. Shahid Raza. My sincere thanks to Dr. Nicolas Tsiftes and Niclas Finne fortheir unprecedented guidance. I am also thankful to Joakim Eriksson, Zhitao He, Prof.Thiemo Voigt and Thomas Ringstrom for their support.

I thank the professors who have been kind to me through out my journey of Master’s,Bachelor’s program. I’m grateful to my supervisor Prof. Peter Herrmann at NTNU. Myspecial thanks to Dr. Kalyani and Dr. Seetha for always believing in me. I’m gratefulto Bhanu Teja Kotte for creating interest towards Master’s program. I’m thankful toMona Nordaune, Aino Roms and May-Britt Eklund-Larsson for helping me with theadministrative matters.

My sincere thanks to my grandparents, Kalidas & Veeramma, my uncle Konda Mama,relatives and friends for standing on my side during all times.

i

AbstractThe Internet of Things(IoT), an emerging global Internet-based technical architectureimpacts the security and privacy of the stakeholders involved. IoT security is thearea of endeavour concerned with safeguarding connected devices and networks in theInternet of things. It is of utmost importance to allow protected access to IPv6 overLow power Wireless Personal Area Networks (6LoWPAN) networks and protectingInternet-connected critical infrastructures from wireless hosts within 6LoWPAN network.The security architecture deployed must ensure resilience to attacks, data authentication,integrity, access control to data, resources and client privacy. With increasing technology,there is high probability for hackers and intruders to succeed attacking a network. Hence,security of networks is essential.

This solution is to counter the attacks by implementing a two way firewall. Thissolution makes scientific contribution by adding support for the IoT protocol ConstrainedApplication Protocol(CoAP) and Datagram Transport Layer Security(DTLS) which arewidely used for communication in IoT networks. If the packet arrives on CoAP or DTLSport, firewall scans the packet to see that the packet confirms to the message formatintended. Devices in 6LoWPAN are memory constrained possessing less RAM and henceanother key contribution of this thesis is that the rules, stored in files, are read directlyfrom file facilitating minimal use of additional memory. In addition to this, the decisionsof firewall i.e. the blacklisted and whitelisted IP addresses are also saved in files.

The firewall is deployed and evaluated within 6LoWPAN. The power consumption andmemory consumption are calculated. Security is evaluated analytically and it is seen thatthe true positive rate ranges from 80-95% for DoS(Denial of Service) attacks and 90-100%for IP spoofing attacks. It can be concluded that firewall can be deployed with very littleoverhead in terms of memory and power consumption. As an extension to this firewall,multiple IoT protocols parsing such as Message Queuing Telemetry Transport(MQTT),Extensible Messaging and Presence Protocol(XMPP) can be added. Similarly supportfor other attack detection algorithms like IP Spoofing, Distributed DoS(DDoS) can beadded.

ii

AbstraktSakernas Internet år en framväxande global Internet-baserad teknisk arkitektur som på-verkar säkerheten och integriteten för inblandade deltagare. IoT-säkerhet är områdetdär man strävar mot att såkra uppkopplade apparater och nätverk i Sakernas Inter-net. Det är av yttersta vikt att tillåta skyddad tillgång till IPv6 över trådlösa ochenergisnåla lokala nätverk (6LoWPAN), samt att skydda kritisk infrastruktur som harInternet-uppkoppling från trådlösa apparater inom 6LoWPAN-nätverken. Den säker-hetsarkitektur som används måste garantera motståndskraft mot attacker, autentiseringoch integritet av data, tillgångskontroll för data och resurser, samt användares privatliv.Med ökande användning av teknologi stiger möjligheten för hackare att kunna attackeraett nätverk framgångsrikt. Därför är säkerhet i nätverken av yttersta vikt.I denna rapport visar vi hur man kan motverka angrepp på säkerheten genom att im-

plementera en två-vägs-brandvägg. Det vetenskapliga bidraget är att vi lägger till stödför IoT-protokollet Constrained Application Protocol (CoAP) och Datagram TransportLayer Security (DTLS), vilka används av många för kommunikation inom IoT-nätverk.Om ett paket inkommer på en CoAP- eller DTLS-port, så undersöker brandväggen pa-ketet för att se till så att paketet är formaterat korrekt. Apparater i 6LoWPAN har oftaminnesbegränsningar, varför ett annat centralt bidrag i denna rapport är att brandvägg-sreglerna lagras i filer och inläses direkt vid behov för att minimera minnesanvändningen.Dessutom sparas besluten som tas av brandväggen, dvs. svart- och vitlistningar av IP-adresser, i filer.Brandväggen används och utvärderas inom 6LoWPAN. Energiförbrukningen och min-

nesanvändningen beräknas utifrån experimentell data. Säkerheten utvärderas analytiskt,och vi ser att andelen sant positiva beslut är 80-95% för Denial-of-Service (DoS) attacker,samt 90-100% för IP-spoofing attacker. Slutsatsen är att brandväggen kan driftsättasmed väldigt lågt minnesbehov och låg energiförbrukning. Brandväggen kan i framti-den utökas med ytterligare IoT-protokoll som Message Queuing Telemetry Transport(MQTT) och Extensible Messaging and Presence Protocol (XMPP). Dessutom vore detönskvärt med stöd för andra detekteringsmekanismer mot attacker, som exempelvis IP-spoofing och Distributed Denial-of-Service (DDoS).

1

Contents1. Introduction 1

1.1. IoT Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.1. Security solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2. Importance of firewall . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4. Real time example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5. Problem formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.6. Project goals and objectives . . . . . . . . . . . . . . . . . . . . . . . . . 51.7. Research methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.8. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.9. Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.10. Report structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2. Background 72.1. Nobel Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2. Contiki OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3. Border Router and Tunslip interface . . . . . . . . . . . . . . . . . . . . 8

2.3.1. Packet Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4. 6LoWPAN Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5. Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5.1. Stateful packet filters: . . . . . . . . . . . . . . . . . . . . . . . . 102.6. UDP in 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6.1. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6.1.1. CoAP Layers . . . . . . . . . . . . . . . . . . . . . . . . 112.6.1.2. CoAP Layers Advantages . . . . . . . . . . . . . . . . . 11

2.6.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6.2.1. DTLS Layers . . . . . . . . . . . . . . . . . . . . . . . . 12

3. Related Work 143.1. WiFire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2. Defense in Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3. Green Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4. S Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4. Security Survey 174.1. Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

iii

4.2. Manufacturing Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3. Security Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.4. Operational Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.4.1. Internet Protocol Security . . . . . . . . . . . . . . . . . . . . . . 224.4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.4.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . 224.4.4. Physical Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5. Architecture 245.1. Firewall placement and Architecture . . . . . . . . . . . . . . . . . . . . 245.2. Firewall modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3. Packet parsing and dynamic decision making . . . . . . . . . . . . . . . . 265.4. State Information and dynamic decision making . . . . . . . . . . . . . . 275.5. Adding IP address to Whitelist . . . . . . . . . . . . . . . . . . . . . . . 285.6. Adding IP address to Blacklist . . . . . . . . . . . . . . . . . . . . . . . . 28

5.6.1. Denial of Service attack . . . . . . . . . . . . . . . . . . . . . . . 285.6.2. CloneID attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.7. CoAP and DTLS protocol parsing . . . . . . . . . . . . . . . . . . . . . . 295.7.1. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.7.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.7.2.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . . . 315.7.2.2. Handshake Protocol . . . . . . . . . . . . . . . . . . . . 31

5.8. Maintaining Whitelist and Blacklist files . . . . . . . . . . . . . . . . . . 325.9. Distributed Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.10. Parse firewall rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.10.1. Policy Specification . . . . . . . . . . . . . . . . . . . . . . . . . . 355.11. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6. Evaluation 396.1. Experimental setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2.1. Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.2.1.1. Quantitative Analysis . . . . . . . . . . . . . . . . . . . 406.2.1.2. Detection and True Positive Rate . . . . . . . . . . . . . 406.2.1.3. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2.2. Performance Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 426.2.2.1. Memory Consumption . . . . . . . . . . . . . . . . . . . 426.2.2.2. Energy Overhead . . . . . . . . . . . . . . . . . . . . . . 44

7. Discussion and Conclusions 47

8. Limitations and future work 488.1. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

8.1.1. Memory constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 48

iv

8.1.2. CoAP and DLTS support . . . . . . . . . . . . . . . . . . . . . . 488.1.3. Attacks supported . . . . . . . . . . . . . . . . . . . . . . . . . . 48

8.2. Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488.2.1. Support new IoT protocols . . . . . . . . . . . . . . . . . . . . . . 488.2.2. Extend distributed firewall . . . . . . . . . . . . . . . . . . . . . . 498.2.3. Optimize the memory use . . . . . . . . . . . . . . . . . . . . . . 498.2.4. Handle encrypted and tunnelled data . . . . . . . . . . . . . . . . 49

9. NobelGrid 509.1. Standards and requirements . . . . . . . . . . . . . . . . . . . . . . . . . 50

9.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509.1.2. Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509.1.3. Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509.1.4. Replay Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 519.1.5. Non-repudiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

9.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519.2.1. Security and data privacy . . . . . . . . . . . . . . . . . . . . . . 51

9.2.1.1. End to end security . . . . . . . . . . . . . . . . . . . . 519.2.1.2. Link layer security . . . . . . . . . . . . . . . . . . . . . 519.2.1.3. Network security . . . . . . . . . . . . . . . . . . . . . . 529.2.1.4. Privacy concerns . . . . . . . . . . . . . . . . . . . . . . 52

9.3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Appendices 54

A. Appendix 55A.1. Source files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.2. Running firewall application . . . . . . . . . . . . . . . . . . . . . . . . . 56A.3. Configuring the router advertisement daemon . . . . . . . . . . . . . . . 56

Bibliography 58

v

List of Figures1.1. Protocol Stack comparison in IP and 6LoWPAN[Taken from [1]]. . . . . . 21.2. 6LoWPAN network [Source : [2]]. . . . . . . . . . . . . . . . . . . . . . . 3

2.1. Sample 6LoWPAN network [taken from [3]]. . . . . . . . . . . . . . . . . 9

5.1. 6LoWPAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2. Messaging model - Confirmable and Non confirmable messages. . . . . . 305.3. DTLS session establishment. . . . . . . . . . . . . . . . . . . . . . . . . . 325.4. Packet format for acknowledgment. . . . . . . . . . . . . . . . . . . . . . 335.5. State Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.6. Sequence Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.1. Experimental Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2. The true positive rate for DoS attacks ranges from 95-80. The true positive

rate for IP spoofing ranges from 100-90 with increase in rate of packettransmission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.3. Memory consumption comparison of firewall and border router. . . . . . 436.4. Energy consumption of a border router. . . . . . . . . . . . . . . . . . . . 456.5. Cumulative energy consumption for writing to coffee file system. . . . . . 46

9.1. HAN Security Aspects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

vi

List of Tables4.1. Security Threat Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2. Routing Attacks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.1. Out of 48K ROM in a constrained device (zoul mote) firewall requires5.05K. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2. Operating conditions in Zoul Zolteria RE-Mote. . . . . . . . . . . . . . . 44

vii

1. IntroductionThis chapter is divided into several sections. The IoT Security section introduces theproblem that is addressed in this thesis. It is followed by motivation section whichstrengthens the argument of potential usage of the firewall implemented. The problemwith a real time example is explained later. It is followed by pertinent problem statementwhich formulates the potential problems this thesis intends to solve. Once the problemformulation has been distinctly identified, the project goals and objectives are articulatedin the following section. The research methodology section scrutinises the approachpursued to tackle the problem. Finally, the scope and contribution of the project arediscussed.

1.1. IoT SecurityThe Internet of Things (IoT) is a system of interrelated computing devices, mechanicaland digital machines, objects, animals or people that are provided with unique identifiersand the ability to transfer data over a network without requiring human-to-human orhuman-to-computer interaction [4]. LoWPAN is a simple low throughput wireless networkcomprising typically low cost and low power devices. Devices in this network typicallywork together to connect the physical environment to real world applications, e.g.,wireless sensors networks. It is of utmost importance to allow protected access to IPv6over Low power Wireless Personal Area Networks (6LoWPAN) networks and protectingInternet-connected critical infrastructures from wireless hosts within 6LoWPAN network.

1.1.1. Security solutionsThe Internet of Things, an emerging global Internet-based technical architecture impactsthe security and privacy of the stakeholders involved [5]. IoT security is the area ofendeavour concerned with safeguarding connected devices and networks in the Internet ofthings. The security architecture deployed must ensure resilience to attacks, data authen-tication, integrity, access control to data, resources and client privacy. With increasingtechnology, increases the probability for hackers and intruders to succeed attacking anetwork. Hence, security of networks is essential. Several security solutions includefirewalls, authentication/encryption, security protocols and intrusion detection/intrusionprevention systems [6]. These are well proven security principles.

1

1.1.2. Importance of firewallHowever, firewalls are virtually absent in IoT systems, as many rely on simple passwordauthentication and security protocols based on assumptions that embedded devices arenot attractive targets to hackers, devices are not vulnerable to attacks, or authenticationand encryption provide adequate protection for devices. These assumptions turned outto be myths as the number and sophistication of attacks against embedded devicescontinues to rise and greater security measures are vital [7]. A firewall can be defined asis a system designed to prevent unauthorised access to or from a network. Firewalls canbe implemented in both hardware and software, or a combination of both.

Figure 1.1.: Protocol Stack comparison in IP and 6LoWPAN[Taken from [1]].

There are multiple security protocols that are on top of IPV6. However, not all canbe of use in 6LoWPAN as the devices are resource constrained in terms of memory andprocessing capabilities. Hence, there is a need to implement most prominent securityprotocols so that firewall can filter the intended traffic in order to detect any intentionalusage for depletion of resources. Figure 1.1 gives glimpse of comparison of IoT protocolstack.

1.2. MotivationSecurity can be implemented at different levels. End to end security is one such solutionthat can be achieved by implementing IPSec which in turn implements encryption. Thenext is link layer security with which the access to the wireless medium is more limitedfor an intruder, as compromised packets could be discarded immediately. However, thereis a trade-off between the overhead of providing encryption at the link layer and theoverhead of routing fake packets through multiple hops to the destination where theywould be ultimately detected. Another concern worth mentioning is that link layer keymanagement is not standardised whereas IP based security protocols have well specifiedkey management solutions.

2

Though communication security protects messages, networks are still vulnerable toa number of attacks aimed to disrupt the network. In an unprotected IoT setup anyInternet host can easily drain a constraint devices’ power by sending multiple requests. Inthis case, firewall serves the purpose. Firewall stands out to be a better solution becauseFirewall can act as the first line of defence. When designing a secure environment, addinga firewall is a crucial step in securing data. A firewall establishes a barrier between atrusted, secure, internal network and insecure network (like the Internet). It controls theincoming and outgoing network traffic to your servers by analysing the data attemptingto access your server and determining if it should be allowed through. There are plentyof security options out there, but preventing any suspect traffic from even accessing thenetwork with a firewall is vital to achieve network security. Current firewalls are designedto protect local area networks from remote Internet hosts. It is equally necessary thatcritical infrastructure such as smart grid be protected from IP-connected smart homesdevices, while allowing certain limited access. This calls for the need for two-way firewall.

Having told that IPV6 is used for communication in 6LoWPAN, there are a pool ofsecurity protocols available from which choice can be made. However, the challenge isthat these established security protocols are not designed for resource constrained devicesbut for standard computers where power sources, processing capabilities and memoryare abundant. Hence there is a need to complement the existing ones with the protocolsspecifically developed for resource constrained systems.

1.3. The Problem

Figure 1.2.: 6LoWPAN network [Source : [2]].

Figure 1.2, shows how a 6LoWPAN network is connected to Internet. There is a Edgerouter which connects the two networks. The 6LoWPAN network consists of motes.A sensor node, also known as a mote is a node in a sensor network that is capable ofperforming some processing, gathering sensory information and communicating with otherconnected nodes in the network. The traffic into and out of the network pass through

3

the Edge router. In such a scenario, there is a possibility of threat to the 6LoWPANnetwork from the Internet and vice versa. The motes can send control information toInternet connected devices and might pose a threat. Due to the security breaches, dataand motes within the networks might be compromised which indirectly poses a threat toCIA(Confidentiality, Integrity, Availability) of data and resources etc.

To protect from these attacks(especially routing attacks), we need to safeguard theabove mentioned properties of data, resources using security measures. Several provensecurity measures are authentication, encryption etc. Firewall is one such measure thatacts as first line of defence to/from the network. In this case, a two way firewall isnecessary in order to secure the 6LoWPAN network from internet and at the same timescrutinise the data that goes out from 6LoWPAN network to the Internet. Encryptionprovides end-to-end security. However, we are interested in network security and asexplained in motivation, Firewall serves the purpose.

1.4. Real time exampleLet us take an example of a company. Companies do have various types of heating,ventilation and air conditioning (HVAC) systems and security systems across theirlocations or even in the same building. These issues can be addressed by deployinga building automation system(BAS). The technologies for Internet of Things (IoT) isbringing the cost of BAS down. A low cost alternative is to instrument a building usingIoT technologies, such as low cost wireless sensors, on-premises gateways and cloudanalytics.

Some of the primary features in BAS are:

• Single interface for managing multiple systems, HVAC control, including operationmodes and temperature set points.

• Remote control and monitoring from mobile devices (e.g., tablets and smartwatches).

• Real-time remote monitoring of video surveillance.

• Alerts when motion detected by cameras.

• Integration with smoke, noise, temperature, and humidity sensors.

• Alerts when actual values exceed defined threshold values.

• Alarm configuration: activate, deactivate, and reset alarms.

There are sensors that collect information such as the amounts of carbon-dioxide, away to detect fire or smoke in the building. This information can be accessed using anapplication on personal device such as a mobile or tablet. Tablet is an internet connecteddevice. The carbon-dioxide readings must not be tampered. If the sensor node is attacked,then it is compromised and wrong data is sent. Hence, whatever data goes out from the

4

6LoWPAN network must be validated before it goes out. Similarly, a mobile that hasbeen hacked may intentionally send a control signal such as a command to power offthe sensor. This strengthens the argument of protecting the data that is going out ofthe network as well as the data that is flowing into the network. This protection can beprovided by a Firewall.

1.5. Problem formulation1. What may be done to protect 6LoWPAN networks from Internet at network layer?

2. Which IoT protocols support is required to be added to enable protection?

1.6. Project goals and objectivesThe solution to aforementioned problem statement are stated here. These transpireto be as follows : Out of the many security solutions discussed in Section 1.2, firewallcan be used as first line of defence for protecting 6LoWPAN from Internet. Equally, anode within 6LoWPAN can be malicious that intends to send malicious data to Internet-connected critical infrastructures. To counter both the attacks, a two way firewall isimplemented by adding support for the most prominent IoT protocols CoAP and DTLS.It is then deployed and evaluated within 6LoWPAN network.

1.7. Research methodologyAnalytical research mainly deals with the testing of a concept that is not yet verifiedand specifying and inferring relationships by examining the concepts and informationalready available. The research methodology used in this thesis is analytical initiallyto make design decisions about the placement of firewall, architectural design decisionsfor a firewall in 6LoWPAN networks. Experimental research, that often starts with aconcrete problem, is used to evaluate the impact of one peculiar variable of a phenomenonby keeping the other variables controlled. Now that the firewall design decisions havebeen made, the research methodology is shifted to experimental research in the laterhalf to implement and deploy the firewall in nodes. We apply the analytical researchmethodology to analyse a 6LoWPAN. We use the already known concepts and factsabout security threats in the 6LoWPAN networks and examine how the provided securitymechanisms guard against these threats. In order to build a firewall as a security solutionwe first develop hypotheses or ideas about the architecture. We then formulate a designbased on our hypothesis.

5

1.8. ScopeThe scope of this thesis is limited to safeguard 6LoWPAN networks by adding support toCoAP and DTLS IoT protocols and evaluate the firewall to verify that it validates thistraffic. Dynamic decisions to blacklist and whitelist IP addresses are made by firewall.The decisions made by firewall are saved to files. This thesis focuses on detecting andpreventing Denial of service attack and CloneId attack. This thesis does not aim toprotect the network from all possible attacks.

1.9. ContributionThe primary scientific contribution is to implement firewall by adding support for IoTapplication protocol CoAP and DTLS so as to meet the needs for resource constraineddevices in 6LoWPAN networks. In addition to this, decisions regarding the placementof firewall within the system and making design decisions for firewall comprises of themajority of work. The firewall is designed considering the resource constrained natureof devices in 6LoWPAN. In this regard, more importance is given in the architecturaldecisions to make use of files instead of lists that take up more RAM. By using files usingCoffee file system, the memory usage of RAM is reduced[8].

The next major contribution is adding detection and prevention algorithms for DoSand CloneID attacks. A firewall is designed, implemented and evaluated. The resultsshow that it is indeed feasible to use it in the context of 6LoWPAN and the IoT. Theattack detection and prevention algorithms in firewall currently target spoofed or alteredinformation and denial of service attacks.

1.10. Report structureThe first chapter gives an introduction to the problem statement as already described. Itgives an insight into the problem and available solutions and which is best to providenetwork security to counter attacks. The methodology, scope and contribution is alsodiscussed in this chapter. The second chapter introduces the various terms needed tounderstand the report. The protocols which will be supported are explained briefly. Thethird chapter dives into the related work in this field of providing security to sensornetworks. The fourth chapter presents an overview of security survey. It describes thepossible attacks and different kinds of security measures. The fifth chapter details thearchitecture of the firewall in detail. The different modules of a firewall and the variousalgorithms are explained here. The sixth chapter presents evaluation of the architecturein terms of memory and power consumption. The design is also evaluated quantitatively.The next chapters concludes and discusses the limitations and possible extensions tofirewall. The last chapter presents a possible use case where the firewall can be used.

6

2. BackgroundThis chapter is divided into several sections. The background section introduces thekey terminology that is required for a reader to understand this report. It describes thetechnical terms needed and used in this project. It briefly explains NobelGrid, ContikiOS and it’s significance in 6LoWPAN devices. Border Router and tunslip interface areintroduced. It is followed by discussing about significance of UDP in 6LoWPAN. Theimportance of CoAP is detailed next. DTLS protocol is explained briefly.

2.1. Nobel GridA smart grid is an electrical grid which includes a variety of operational and energymeasures including smart meters, smart appliances, renewable energy resources andenergy efficiency resources. Electronic power conditioning and control of the productionand distribution of electricity are important aspects of the smart grid. Nobel Grid willprovide advanced tools and Information and Communication Technology(ICT) servicesto all actors in the Smart Grid and retail electricity market in order to ensure benefitsfrom cheaper prices, more secure and stable grids and clean electricity.

Nobel Grid [9] will provide advanced tools and ICT services to all actors in the SmartGrid and retail electricity market in order to ensure benefits from cheaper prices, moresecure and stable grids and clean electricity. A smart grid is an electrical grid whichincludes a variety of operational and energy measures including smart meters, smartappliances, renewable energy resources and energy efficiency resources.

2.2. Contiki OSContiki [10] is an open source operating system that runs on tiny low-power microcontrollers and makes it possible to develop applications that make efficient use of thehardware while providing standardised low-power wireless communication for a rangeof hardware platforms. Contiki is used in numerous commercial and non-commercialsystems, such as city sound monitoring, street lights, networked electrical power meters,industrial monitoring, radiation monitoring, construction site monitoring, alarm systems,remote house monitoring and so on[11].

7

2.3. Border Router and Tunslip interfaceBorder routers are routers that can be found at the edge of a network. It is depicted inFigure 2.1. They are also termed as edge routers. Their function is to connect one networkto another. The nodes within the 6LoWPAN will form a Directed Acyclic Graph(DAG)with the border router set as the root. The border router will receive the prefix through aSLIP(Serial Line Interface Protocol) connection and it will be communicated to the restof the nodes in the Routing Protocol(RPL) network. By default the border router hostsa simple web page. This webpage is displayed when the IPv6 address of the border routeris entered in the browser. We need to simulate the scenario in which this RPL networkis connected to an external network. For this purpose the tunslip utility provided inContiki is used. Tunslip creates a bridge between the RPL network and the externalnetwork.

2.3.1. Packet TypesBoth incoming and outgoing packets arrive at border router on tunslip interface. Anynetwork other than this originating network is termed as external network. When apacket arrives from external network and is intended to a node in the 6LoWPAN network,it reaches the border router on tunslip interface. This packet is termed as incomingpacket. Similarly, whenever a packet arrives from the mote within the 6LoWPAN and isdestined to external network, the packet reaches border router on tunslip interface. Thispacket is termed as outgoing packet.

2.4. 6LoWPAN StackThe network stack can be seen in 5.1 There are multiple security protocols that are ontop of IPV6. However, not all can be of use in 6LoWPAN as the devices are resourceconstrained in terms of memory, processing capabilities. Hence, there is a need toimplement security protocols so that firewall can filter the intended traffic. Figure5.1 gives glimpse of IoT protocol stack. The radio packets arrive on radio interface802.15.4. They are passed over to framer for framing packets. It is passed onto Radioduty cycling(RDC) layer. Then comes the MAC layer and finally Network layer. Allthese layers constitute uIP Network stack. IPV6 and RPL are in Network Layer. Thetransport layer is the datagram layer. Several security protocols such as DTLS are atSecurity layer. Application protocols such as CoAP, LWM2M etc are in application layer.The firewall is placed in the network layer of the border router for intelligent packetfiltering.

2.5. Packet FilteringPacket filtering systems route packets between internal and external hosts, but they doit selectively. They allow or block certain types of packets in a way that reflects a site’s

8

Figure 2.1.: Sample 6LoWPAN network [taken from [3]].

own security policy. Every packet has a set of headers containing certain information.The main information is:

• IP source address

• IP destination address

• Protocol (whether the packet is a TCP, UDP or ICMP packet)

• TCP or UDP source port

• TCP or UDP destination port

The router can also look past the packet headers at data further on in the packet;this allows it, for instance, to filter packets based on more detailed information and toverify that packets appear to be formatted as expected for their destination port. Therouter can also make sure that the packet is valid which helps catch a number of denialof service attacks based on malformed packets. In addition, the router knows thingsabout the packet that aren’t reflected in the packet itself such as:

• The interface the packet arrives on

• The interface the packet will go out on

9

A screening router looks at packets more closely. In addition to determining whetheror not it can route a packet towards its destination, a screening router also determineswhether or not it should. Once it has looked at all the information, a straightforwardpacket filtering router can do any of the following things:

• Send the packet on to the destination it was bound for.

• Drop the packet without notifying the sender.

• Reject the packet - refuse to forward it, and return an error to the sender.

• Log information about the packet.

• Set off an alarm to notify somebody about the packet immediately.

• More sophisticated routers might also be able to modify the filtering rules

2.5.1. Stateful packet filters:Stateful packet filters are packet filtering devices that keep track of packets. They arenamed so as they store information about the state of transactions. They may also becalled dynamic packet filters because they change their handling of packets dynamicallydepending on the traffic they see. Devices that look at the content of packets, ratherthan at just their headers, are frequently called intelligent packet filters. In practice,almost all stateful packet filters also are capable of looking at the contents of packets.

2.6. UDP in 6LoWPANA sensor node, also known as a mote is a node in a sensor network that is capable ofperforming some processing, gathering sensory information and communicating withother connected nodes in the network. LoWPAN is a simple low throughput wirelessnetwork comprising typically low cost and low power devices such as motes. Devices inthis network typically work together to connect the physical environment to real worldapplications, e.g., wireless sensors networks and the communication is over IPV6. Hence,IPv6 over Low power Wireless Personal Area Networks is termed as 6LoWPAN networks.

Motes in 6LoWPAN communicate over IPV6 and uses UDP communication. Tounderstand this, need to understand 6LoWPAN. The characteristics of 6LoWPAN are :

• enable use of IPV6 in low power and lossy networks (LLN’s)

• uses a protocol for smart-object inter-networking over LLN’s called - IPV6 RoutingProtocol for LLN called RPL

RPL enables use of standard web services such as REST using data formats such asJSON, XML over LLN’s without the need for application server gateways.

In REpresentational State Transfer(REST), resources are controlled by server and aredecoupled from services. Resources can be represented in formats such as JavaScript

10

Object Notation(JSON), eXtensible Markup Language(XML). The resources can be ma-nipulated based on request/responses using protocols. REST has not bound to a protocol.However, HTTP implementation is well-known and the resources are more commonlymanipulated using GET,POST and PUT calls. IoT and Machine-to-Machine(M2M)applications are developed on top of web services. Due to the differences in traditionalInternet and IoT/M2M applications, use of web services is not straight forward whenreal time or deterministic operation is required. In addition, these applications are shortlived as most of the time, they sleep to save power and wake up only on an event.

2.6.1. CoAPTo deal with such issues, REST based web transfer protocol called Constrained ApplicationProtocol(CoAP) has been proposed. It is close to real time and deterministic operations.CoAP transfer protocol is optimised for resource constrained networks typical of IoTand M2M applications. It is based on REST architecture where resources are servercontrolled abstractions made available by an application process and identified usingURI’s. The primary difference between HTTP and CoAP is that HTTP uses TCP andCoAP uses UDP for communication as less overhead is involved and is apt for short livedapplications.

2.6.1.1. CoAP Layers

CoAP can be summarized as a combination of resources and performance of UDP alongwith reliability of TCP. Therefore, it is implemented in two layers. The Transaction layerhandles the single message exchange between end points. Four types of messages arehandled by this layer:

• Confirmable (requires an acknowledgment)

• Non-confirmable (does not need to be acknowledged)

• Acknowledgment (acknowledges a Confirmable message)

• Reset (indicates that a Confirmable message has been receive but context is missingto be processed).

The Request/Response layer is responsible for the transmission of requests and re-sponses for the resource manipulation and transmission. This is the layer where theREST-based communication occurs. A REST request is piggybacked on a Confirmableor Non-confirmable message, while a REST response is piggybacked on the relatedAcknowledgment message.

2.6.1.2. CoAP Layers Advantages

The use of this dual layer approach allows it to provide reliability mechanisms evenwithout the use of TCP as the transport protocol. This is because a Confirmable message

11

is retransmitted using a default timeout and exponential back-off between retransmissions,until the recipient sends the Acknowledgement message. An important aspect of CoAPas far as response time is that when a server receives a request which it is not able tohandle immediately, it first acknowledges the reception of the message and sends backthe response in an off-line fashion. To keep the message overhead as small as possibleand avoid the significant overhead that the standard HTTP mechanism requires, CoAPuses a number of techniques that will require embedded developers to carefully parsetheir impact on system response times and deterministic operation.

Short header sizeFirst, CoAP uses a short, fixed-length, compact binary header of 4 bytes followed

by compact binary options. A typical request has a total header of about 10-20 bytes.Because a resource on a CoAP server will more often than not change over time, theprotocols been designed to allow a client to constantly observe the resources. The waythis is done is that the client (the observer) registers itself to the resource (the subject)by means of a modified GET request sent to the server. The server establishes anobservation relationship between the client and the resource. Whenever the state ofthe resource changes, the server notifies each client having an observation relationshipwith the resource. The duration of the observation relationship is negotiated during theregistration procedure. While not as neat and efficient as a purely UDP approach, itseems to resolve many of the performance issues.

Support multiple encoding standardsSecond, CoAP also supports other payload encoding standards, such as the widely

used Extensible Markup Language (XML). As it is presently implemented, the verbosityand parsing complexity of XML makes it inappropriate for constrained devices. Onealternative is the more compact data representation in JSON. JSON (JavaScript ObjectNotation) is a lightweight, text-based open standard designed for human-readable datainterchange. It is derived from the JavaScript scripting language for representing simpledata structures. But what JSON lacks is the flexibility of XML. As a result there areongoing efforts to develop more compact binary XML-based representations such as theExtensible XML Interchange (EXI).

2.6.2. DTLSDatagram TLS (DTLS) has been proposed as the primary security protocol by standard-isation to protect CoAP transmissions. Analogous to TLS-protected HTTP (HTTPs),the DTLS-secured, CoAP protocol is termed CoAPs.

2.6.2.1. DTLS Layers

DTLS has two layers[12]. The first layer is the Record layer. The second layer canbe one of the four protocols : Handshake, Alert, ChangeCipherSpec and applicationdata. The ChangeCipherSpec message type indicates that the record layer shall use the

12

cipher suite and security keys negotiated in earlier transactions to encrypt the subsequentmessages. DTLS uses handshake protocol to prevent DoS attacks, handle message lossand reordering of messages. In order to prevent an attacker from consuming excessiveresources on the server, DTLS employs stateless cookie exchange. Alert protocol is usedto communicate the error messages between the DTLS communicating peers.

Record headerThe Record header contains among others content type and fragment fields[ 13]. Basedon the value in the content type the fragment field contains either the Handshakeprotocol, Alert protocol, ChangeCipherSpec protocol or application data. The Recordheader is primarily responsible to cryptographically protect the upper layer protocols orapplication data once the handshake process is completed. The Record protocol includes,confidentiality, integrity protection and authenticity.Handshake protocolThe DTLS Record is a simple protocol in comparison to the Handshake protocol whichconsists of many message exchanges in an asynchronous way. Figure 5.3 shows a fullhandshake process. The handshake messages negotiate encryption algorithms, securitykeys, cipher suites and compression methods.

DTLS promises E2E security of different applications running on a single system andoperates between the transport and application layers as seen in Figure 5.1. A webresource on an IoT device can be accessed securely via CoAPs protocol as:coaps://myIPv6Address:port/MyResource.xml

13

3. Related WorkAs part of literature study, many papers have been read. This chapter discusses thevarious papers that have a done significant work in this area and facilitated as a startingpoint to the thesis.

3.1. WiFireWilhelm [14] presented a system that brings the firewall concept to wireless networks.First, WiFire detects and analyses packets during their transmission, checking theircontent against a set of rules. It then relies on reactive jamming techniques to selectivelyblock undesired communication. WiFire, according to the article helps regaining controlover the RF spectrum by enforcing security policies at the physical layer. They used an802.15.4-based wireless sensor network and an attacker using the KillerBee framework[15] to show several usage scenarios for WiFire.

The system flow is as follows: WiFire scans the RF spectrum for packets that mightreach the protected network, analyses whether they comply to a given ruleset or notand blocks them if necessary. The system achieves this by demodulating and decodingpackets sequentially during their transmission, classifying each individual packet witha set of rules based on its content (such as the source or destination addresses, frametype or even parts of the payload) and jamming it before it reaches the receiver. WiFireproceeds in three steps in its operation: (i) spotting packets, (ii) distinguishing friendsfrom foes, and (iii) destroying malicious packets

Detecting packets : WiFire scans the medium for the physical layer header of 802.15.4,consisting of a preamble and start-of-frame delimiter (SFD).

Identifying malicious packets: When a packet transmission is detected, WiFire analysesthe signal and checks whether a rule in the stored ruleset matches. They have implementedan O-QPSK demodulator and an 802.15.4 frame decoder to access link layer fields orpayload bytes while the packet is on the air, one byte at a time. This output streamis fed into an iptables-style rule checker that supports chains of rules consisting of anarbitrary combination of matches, i.e., functions that check for packet features.

This demonstration in this article is different from what this thesis is focused. Firewallat physical layer is not the best solution as access to the wireless medium is hard toregulate and control as any device in the transmission range can eavesdrop and injectpackets into a network with low effort. This thesis is focused on implementing firewall atnetwork layer. The interesting traffic is only IPV6 packets monitored at network layer.It identifies a node relatively within the network and write rules that deal with data andcontrol frames sent from various nodes in the network.

14

3.2. Defense in DepthIn paper [16], Murthy discusses the firewall and other security tools used to providesecurity to the wired networks and offers a methodology to protect a wireless network.An Analysis of the proposed methodology and its functionality are also presented. Thismethodology has more than one component to avoid single point of failure. The proposedconfiguration adopts the concept of ”defence in depth,” meaning that if one componentof the firewall is compromised, there are other components that will stop the intruder,or at least slow the intruder until the system administrator notices the security breach.The combination of a bastion host with two screening routers increases the strengthof the firewall by adhering to the concept of ”defence in depth”. The solution putforth in this paper combines several forms of technology from traditional Firewalls tochallenge-response systems to arrive at a configuration that offers security of wirelessnetworks.

The ideas presented in this paper can be taken up for building firewall for 6LoWPAN.Working out defence in depth is an agreeable idea that could be implemented. However,the feasibility of this idea in constrained devices in IoT is a question. We need to analysethe overhead involved in providing three layers of security. Moreover this is a centralisedapproach where the firewall is implemented all in one to three devices. It has a singlepoint of failure in the sense that if Internal screening router is compromised, then thewhole network is compromised. Distributed firewall implemented in this thesis avoidssingle point of failure. The firewall is hosted in Border Router in this thesis. A part ofthe firewall is hosted in the IoT devices.

3.3. Green FirewallYi [17] develops an energy efficient intrusion prevention mechanism in WSNs calledgreen firewall. It can isolate an intruder with less overhead, and track the intruder tocontinually prevent the attack. The paper analyses the overhead cost of the green firewalland compare it with the flooding broadcast method. Extensive analysis and simulationsshow that green firewall can prevent the attack and effectively reduce redundant alarmpacket transmissions which results in less energy consumption.

Their goal is to effectively and rapidly eliminate intrusion with less overhead cost toconserve energy. They develop an energy-efficient intrusion prevention in WSNs calledgreen firewall. Green firewall is used to isolate the intruder in WSNs with less energyconsumption. They design an energy efficient method to locally broadcast pre-alarmpackets instead of flooding alarm packet in the whole network. It includes pre-alarmpackets, alarm packets, a greylist, a blacklist and their spread ways the green firewallcan be restructured and extended with mobile intruder in order to enclose and isolatethe intruder forever. Green firewall need not broadcast the alarm packet to all nodes.Instead, it only broadcasts the alarm packet to the nodes which enclose the intruder.The method effectively reduces redundant alarm packets transmissions and meanwhile itdecreases the energy consumption in WSNs.

15

Performance Analysis : The main advantage of green firewall is its low overhead andlow energy consumption in its process. The less clusters the malicious node intrudes,the more advantageous the green firewall shows. Even in the worst condition which isextremely rare, where the intruder does traverse the whole network. At this time, theoverhead of green firewall is the same as flooding broadcast.

This paper is different from this thesis in the way that it assumes that there is aIntrusion Detection system (IDS) for detecting malicious packets and announces a methodto alert other nodes. In this thesis, there exists no IDS for detecting malicious node.Firewall policies are designed in such a way that only intended traffic is allowed. In orderto dynamically add the rules, traffic is monitored, data is analysed and conclusions aredrawn in order to make decisions for adding a new firewall rule to remove the maliciousnode by logging into a file and sending a warning to the system administrator.

3.4. S FirewallMa [18] suggests that when deployed in unintended/hostile area, WSNs may sufferall kinds of attacks like flooding, Sinkhole etc. To apply WSNs more practically andwildly, some secure countermeasures must be deployed in WSNs. In this paper, wedesign a kind of firewall scheme, which based on mobile agent, to isolate the intruderwith less communication overhead and memory cost. The S Firewall can be generated

automatically, distributively and in real time when network-wide attacks happen. Thepaper also proposes a route restoring scheme by local repair and makes a performanceanalysis by prototype implementation of S Firewall.

Because of resource constraint and vulnerabilities of wireless communication, it is easierto suffer all kinds of attacks like signal jamming and eavesdropping, tempering, spoofing,resource exhaustion, altered or replayed routing information and selective forwarding,sinkhole attacks, Sybil attacks, wormhole attacks, flooding attacks and so on [ 19]. Themain contributions of this paper are : S Firewall is used to surround and isolate theintruders in WSNs, Agent scheme - defence agents to form firewall and surround/isolatethe intruders with less resource consumption, Route restoring: when the intruder isfound, S Firewall help to find a new route to bypass the intruder by local route repair,implemented the prototype of S Firewall on NS2 platform.

The S Firewall is used to protect WSN against attacks launched from an intrudernode within the networks. If all neighbour nodes around the node refuse to forward itspackets, the node can not communicate with other nodes in WSNs. The S Firewall usesthe above principle to isolate intruders.

The paper discussed above is different from this thesis in the sense that in my approach,when the firewall detects a malicious packet, it adds the node to the blacklist and henceany further data from that node is blocked. The neighbouring nodes need not know thatthe node is malicious. The firewall, while inspecting packets takes necessary action. Inthis case, it adds the node to blacklist.

16

4. Security Survey

4.1. Security ConsiderationsThis section gives an overview about the security threats and vulnerabilities in the IoTand should sharpen the focus on what must be considered when trying to secure CoAP.Garcia-Morchon, et al. identify nine potential security threats, which are summarised inTable 4.1 ordered by the vulnerable layer and the lifetime phase of a thing [20]

Manufacturing Commissioning andInstallation

Operation

Physical Thing Device Cloning Substitution Privacy ThreatExtraction ofParams

ApplicationLayer

Firmware Replace-ment

Transport Layer EavesdroppingMan-in-the-Middle

EavesdroppingMan-in-the-Middle

Network Layer EavesdroppingMan-in-the-Middle

Routing AttackDoS

Physical Layer DoS

Table 4.1.: Security Threat Analysis.

The potential attacks are grouped by the lifetime phase and the potential point ofvulnerability. Roughly, the security threats can be divided into two categories: physical(local) attacks and non-physical (remote) attacks. Physical attacks are executed by at-tackers which force their way into the physically unprotected thing and try to compromiseit in different ways [21].

Cloning of ThingsAn untrusted manufacturer can easily clone the physical characteristics, firmware and

software, or security configurations during the manufacturing process of a thing. Themanufacturer could sell the cloned thing at a cheaper price in the market to gain financialbenefits or even worse implement additional functionality which could later be used withmalicious intent.

17

Malicious Substitution of ThingsDuring the installation of a thing, a genuine thing may be replaced with a lowquality

variant without being detected. The main motivation may be cost savings by significantlyreducing the installation and operational costs.

Firmware Replacement AttackAfter a certain time into the operational phase, the software or firmware of a thing

may be updated to introduce new functionality or new features. During this maintenancephase, an attacker may be able to exploit such an upgrade by replacing it with malicioussoftware. If such an attack is successful, the operational behaviour of this thing can beinfluenced and exploited afterwards.

Extraction of Security ParametersThings deployed in ambient environments are normally physically unprotected and

can easily be captured by an attacker. When in possession of a thing, the attacker maytry to extract certain security information such as keys from this thing. Once a key iscompromised (e.g., a group key), the whole network may be compromised as well.

Denial-of-Service AttackA Denial-of-Service (DoS) attack can be launched by physically jamming the commu-

nication channel. All of the described attacks depend on a physically present attacker.Therefore, the security measures that need to be taken to protect things against suchattacks go beyond the scope of Internet protocol security. As we focus on securing CoAP,the countermeasures against these attacks will only be discussed in combination withInternet protocol security. The non-physical (remote) attacks include the following [21]:

Eavesdropping AttackDuring commissioning of a thing into a network, it can be vulnerable to eavesdropping:

If security parameters or keying material are exchanged in the clear, the attacker mightbe able to retrieve the secret keys established between the communicating entities. Buteven a protected network can be vulnerable to eavesdropping, e.g., in the event of sessionkey compromise which can happen after a longer period.

Man-in-the-Middle AttackA man-in-the-middle attack is possible during the commissioning phase, e.g., when

keying material is exchanged in the clear and the security of the key agreement algorithmdepends on the assumption that no third party is able to eavesdrop on or sit in betweenthe two communicating entities. During the operational phase, man-in-the-middle attacksare only possible when anonymous connections are used.

Routing AttackRouting attacks include amongst others a) Sinkhole attack, where the attacker declares

himself to have a high-quality route, allowing him to do anything to all packets passing

18

through. b) Selective forwarding, where the attacker may drop or forward packetsselectively. Routing attacks and their effects are listed in Table 4.2.

Denial-of-Service AttackAn attacker can continuously send requests to be processed by specific things and

therefore exhaust their resources. This is especially dangerous in the IoT since thingsusually have tight memory and limited computation capabilities.

Privacy ThreatThe tracking of the location and the usage of a thing may pose a privacy risk to its

users. An attacker could deduce behavioural patterns of the user by inferring informationbased on the gathered data.

As we have identified potential security threats, let us define what we want to achievewhen we talk about security requirements against these threats [21]:

Confidentiality : Confidentiality describes the prevention of disclosure of informationto unauthorised entities. We want to achieve confidentiality to prohibit privacy threatand eavesdropping attacks. Please note that an attacker can observe communicationpatterns of a user even if confidentiality is provided by the connection, allowing him toinfer private information about the user anyway. This attack is just complicated whenconfidentiality is provided, but not fully averted.

Authenticity : Authenticity guarantees that all parties involved in the communicationare who they claim they are.

Integrity : Integrity is violated if a message can actively be altered during trans-mission without being detected. If message integrity and authenticity is guaranteed,man-in-the-middle attacks can be averted.

Non-Repudiation : Non-repudiation implies that one party of a transaction cannotdeny having received a transaction nor can the other party deny having sent a transaction.

Availability : Ensuring the survivability of services to parties when needed, evenduring a DoS attack.

Authorisation : Authorisation is the function of specifying access rights to resources.

Data Freshness : This can mean data freshness as well as key freshness. It ensuresthat no adversary can replay old messages.

These security services can be implemented by a combination of cryptographic mecha-nisms such as block ciphers, hash functions, or signature algorithms and non-cryptographic

19

Attack Name Attack Definition Attack EffectsEavesdropping Overhearing the communication

channel to gather confidentialdata

Reduces data confidentialityExtracts vital WSN informationThreatens privacy protection ofWSN

Traffic Analysis Monitoring the network traffic andcomputing parameters that affectthe network

Degradation of network perfor-manceIncreased packet collisionIncreased contentionTraffic distortion

Camouflage Malicious nodes masquerade asnormal nodes to attract packets

Increased packet loss/corruptionFalse data to network

Sybil Impersonation by malicious nodesas multiple fake identities to at-tract packets from node

Packet loss/ corruptionFalse sensor readingsModification of routing informa-tion

Black hole Attracting all the possible trafficto a compromised node. Can re-sult in launch of other attacks

Triggers other attacks like worm-hole, eavesdroppingExhausts all the network resourcesPacket dropping/ corruptionModification of routing informa-tion

Denial of Service(DoS)

Prevents the user from being ableto use the network services. Ex-tends to all the layers of protocolstack

Reduces WSN availabilityAffects physical layer, link layer,network layer, transport layer andapplication layerPrevents access to network ser-vices by the user

Wormhole Tunneling and replaying messagesfrom one location to another vialow latency links that connect twonodes of WSN

Changes normal message streamFalse routes / misdirectionForged routingChanges network topology

Hello Flood Transmission of a message by ma-licious node with an abnormallyhigh transmission power to makethe nodes believe that it is theirneighbor

False / misleading routes gener-atedRoute disruptionPacket lossConfusion

Grey hole Selective dropping of packets byattracting packets to a compro-mised node.

Suppresses messages in an areaPacket loss and information fabri-cationLaunch other active attack

Table 4.2.: Routing Attacks.

20

mechanisms, which implement authorisation and other security policy enforcement as-pects.

So far, the listed security threats and goals can be applied to arbitrary networks.We, however, are focusing on constrained networks, therefore we need to look at theadditional consequences that arise in constrained environments. One additional problemis the small packet size, which may result in fragmentation of larger packets in securityprotocols (e.g., a large key exchange message). This may open new attack vectors forstate exhaustion DoS attacks [21]. Further, the size and number of messages shouldbe minimised to reduce memory requirements and optimise bandwidth usage, whilemaintaining high security standards. When reducing or simplifying a security protocolin order to minimise energy consumption, one must also expect losses in the securityquality [21]. An appropriate trade-off must be found for each individual environment.

Another problem is the still existing gap between Internet protocols and the IoT,namely 6LoWPAN and CoAP, due to performance reasons. These differences can easilybe bridged using protocol translators at gateways, but it becomes a major obstacle onceend-to-end security measures between IoT devices and Internet hosts are used. Whena message is protected using message authentication codes or encryption or both, theprotected parts of the message become immutable. Thus, making rewriting not possiblefor the translators [21]. As can be seen in Table 4.1, there are roughly three differentphases in the lifetime of each individual thing, each phase exposed to different threatsand having particular security requirements. We will go through these three phases anddescribe the threats and available techniques to protect a thing against those.

4.2. Manufacturing SecurityThe life of a thing starts when it is manufactured. There are several difficulties duringthis phase: a) Normally, there is no single manufacturer that creates all nodes which mustinteract with each other. Therefore, interoperability and trust bootstrapping betweennodes of different vendors is important. b) An untrusted manufacturer can easily clonethe physical characteristics, firmware, or security configuration of a thing and sell it fora cheaper price, or harm the original manufacturer’s reputation due to lower qualitystandards. c) A manufacturer can implement additional functionality within the clonedthing, such as a backdoor [21]. To solve these security problems, no classic cryptographicmechanism can be used. Rather, legal methods must be applied, like having contractswith the manufacturer regulating these issues. Of course, this technique does not resultin tight security, but during this phase total security cannot be achieved. One needs tohope that trust can be established on pain of penalties.

4.3. Security BootstrappingAs can be seen in Table 4.1, there are several security threats during the commissioningphase. In this phase, a device is first installed and then provided with an identity, secret

21

keys, and a list of identities of nodes it can communicate with during normal operation.Thus, it is crucial that the commissioning phase is not compromised, e.g., an attackercould eavesdrop on a unsecured connection and extract operational keying material.That is why we need security bootstrapping before the network can operate normally.Bootstrapping is complete when settings have been securely transferred prior to normaloperation in the network.

4.4. Operational SecurityThe operational phase starts after the bootstrapping phase is completed. In this phase,CoAP is the main transfer protocol used for communication between things. TheCoAP specification defines two ways to provide security and authentication during theoperational phase: DTLS and IPsec. They differ both at their application as well astheir resulting security.

4.4.1. Internet Protocol SecurityThe IPsec Encapsulating Security Payload (ESP) is a protocol for securing InternetProtocol (IP) communications by encrypting and authenticating each IP packet [20].Unlike DTLS, it operates at the network layer of the Internet protocol suite and thereforeit is transparent to the application layer.

4.4.2. DTLSDTLS is a protocol for securing network traffic which has been specified by the IETFin RFC 6347 [33]. Unlike its role model TLS, it does not depend on reliable messagetransfer and can therefore be used with unreliable datagram transport, e.g., UDP. It isdesigned to be as close to TLS as possible, so it is defined as a series of deltas to TLS.The main changes to the protocol due to lossy message transfer (when using UDP) are:a) Handling packet loss, b) reordering of messages, and c) message sizes.

4.4.3. Link-Layer SecurityAs we have seen security protocols applied at the network and transport layer, let us lookat security at the link layer. The current IoT uses for communication primarily 6LoWPAN[21] which builds on the IEEE 802.15.4 link-layer. 802.15.4 link-layer security is thecurrent state-of-the-art security solution for the IP-connected IoT [31]. It provides dataencryption and integrity verification, which is achieved by a single pre-shared key used forsymmetric cryptography applied to all outgoing packets while message integrity is realisedby including a Message Authentication Code (MAC) in the packets. Its advantages arenetwork protocol independence and hardware support for the cryptographic functionsby 802.15.4 radio chips. Unfortunately, there is one big drawback with this securityapproach: The link-layer security only provides hop-by-hop security which implies that

22

each node in the communication path must be trusted and host authentication is notpossible. Additionally, messages leaving the 802.15.4 network will not be protectedanymore by link-layer security mechanisms. Since end-to-end security cannot be achievedby using solely this approach, additional mechanisms are required as proposed in [21].

4.4.4. Physical SecurityIn the threat analysis, we identified several possible physical attacks to which things areexposed. One of the possible attacks is called node capture, where an adversary tries togain full control over some node through direct physical access. It is usually assumed thatthis attack is easy, as the nodes operate unattended and cannot be made tamper proofbecause they should be as cheap as possible [21]. But, Becher, Benenson, and Dornseiffound out that serious attacks require an absence of captured node for a substantialamount of time, and therefore, countermeasures are possible against such node captureattacks [5]: Standard precautions for protecting microcontrollers from unauthorised accessmust be taken, e.g., by protecting the bootstrap loader password. Provide a hardwareplatform appropriate for the desired security level, which is up-to-date with the newestdevelopments in embedded systems security. Sometimes, building additional protectionaround a partially vulnerable microcontroller might be reasonable. By monitoring nodesfor periods of long inactivity, or noticing the removal of a node from the deployment area,the network can revoke the authorisation tokens of the suspicious node. Or, the nodeitself might erase all confidential data stored on it when suspecting a physical attack.

23

5. ArchitectureIn this chapter, initially firewall placement is analysed followed by proposed architecturefor this firewall. Firewall modules are discussed next. The primary scientific contributionin this thesis is adding support for the IoT protocols CoAP and DTLS. CoAP andDTLS parsing algorithms is then discussed. Packet parsing and dynamic decision makingalgorithm is discussed later. The possible dynamic decisions are discussed in detail foreach protocol. The factors that highly influence 6LoWPAN are explored and how thisarchitecture takes into account, the constraints of the 6LoWPAN in architectural designconsiderations are scrutinised subsequently. Policy formulation is reviewed next.

5.1. Firewall placement and ArchitectureThe placement of firewall is a vital decision which impacts the design of the firewall andthe way the firewall detects attacks. The firewall placement also helps in detection andprevention approaches. As the border router acts as a gateway between the Internet and6LoWPAN, every incoming and outgoing packet will go via the border router. Hence,to inspect packets and to implement an intelligent packet filter, it is apt to incorporatemajority of the functionality of firewall in border router. The firewall applicationscrutinises every packet that goes through the network. It examines all the incomingand outgoing traffic. The firewall application is invoked when a packet is detected in theborder-router.

As 6LoWPAN consists of devices that are resource constrained as shown in Figure2.1, a hybrid approach is preferred. Hybrid approach is a combination of centralisedand distributed components of the firewall. Hence, firewall modules are positionedboth in the border router and constrained sensor nodes. The firewall can be classifiedinto centralised and distributed firewall. The primary features of firewall reside in thecentralised component within the border router as seen in Figure 5.1 . It is composed ofmajor functionalities discussed in detail below. The distributed firewall comprises of aminor portion of the firewall functionality and resides in the constrained sensor motes.

5.2. Firewall modulesThe two way firewall designed and implemented in this thesis is an intelligent packetfilter. It scans the contents of packets to make decisions whether to allow or drop apacket. In addition to making a choice on packet information, it also saves the stateof the packet. It uses this information at later stages of transactions between the same

24

Figure 5.1.: 6LoWPAN.

parties to identify if any of the parties is performing an attack and also it dynamicallymakes decisions to block an attacker on detecting suspicious activity.

The firewall comprises of seven modules.

1. The first is the intelligent packet filter module. This module identifies if the packetis an incoming or outgoing packet and passes the control to input or output filteraccordingly. The input and output filters makes calls to various functions in theremaining modules at different points in time during packet processing. The inputand output filter algorithms are discussed in Section 5.3.

2. The second module is the validation module. It validates the source and destinationIP address and port numbers. It is responsible for detecting and preventing IPspoofing attacks in the network.

3. The third module is packet state module and is responsible for saving states of thepackets. The state of the packet is defined as the source and destination IP address

25

and port numbers in addition to the protocol.This module is further explained inSection 5.4.

4. The fourth module is protocol parsing module. The primary scientific contributionin this thesis is adding support to most commonly used IoT protocols CoAP andDTLS and this is handled in this module. This module verified the CoAP andDTLS packet structures to confirm if the packet is according to the standards. Itis responsible for detecting malformed packets. The algorithms for packet protocolparsing is discussed in Section 5.7.

5. The fifth module is the file operations module and adds significance to the wholefirewall architecture by taking into account the resource constrained propertiesof the devices within the network. In order to make the architecture strong andeffective, the dynamic decisions made by the firewall are stored in files. Thetradeoffs for this approach is discussed in Section 5.8.

6. The sixth module is the rules specification module. The system administrator candynamically add firewall rules which is the similar to that in linux.

7. The seventh module is the last module of firewall called distributed firewall moduleresiding in the end sensor motes. This module is responsible for acknowledging theborder router after receiving a packet. It is briefly discussed in Section 5.9.

5.3. Packet parsing and dynamic decision makingThis Section briefs the algorithms for incoming and outgoing packet parsing. Figure 5.5explains the various tasks performed when an incoming or outgoing packet is detected.

Result: allow or dropif IP address in blacklist then

return drop;endif invalid (CoAP or DTLS protocol parse) then

return drop;endif n(packets) greater than n(maximum allowed) then

return drop;endif IP Address in whitelist then

return allow;endif parse rules then

return policy of ruleelse

return default policyend

Algorithm 1: Outgoing packet filter.

26

As seen in algorithm 1, the outgoing packet is examined if it is a CoAP or DTLS packet.If it is then the protocol is validated accordingly. If it does not confirm to standards, thepacket is dropped else IP address is verified to see if it is blacklisted. If so, the packet isdropped. If the number of packets from the same source IP to the same destination IPand port exceeds the maximum number of packets allowed, the packet is dropped. Ifthe IP address in whitelisted, the packet is forwarded to destination IP. if none of theabove conditions is true, it is checked against the set of firewall rules and the rule policyis applied. If none of the rule matches, default network policy is applied.

Result: allow or dropif IP address in network then

add IP address to input blacklist;return drop;

endif invalid (CoAP or DTLS protocol parse) then

return drop;endif IP address in blacklist then

return drop;endif n(packets) greater than n(maximum allowed) then

return drop;endif IP Address in whitelist then

return allow;endif parse rules then

return policy of ruleelse

return default policyend

Algorithm 2: Incoming packet filter.The algorithm 2 explains the series of steps performed when an incoming packet is

detected. If the protocol matches either CoAP or DTLS then protocol parsing is done.If the destination IP address matches the IP address of the node within the 6LoWPAN,an IP spoofing is detected and the source IP is blacklisted and the packet is dropped. Ifthe IP is blacklisted, the packet is dropped. The remaining steps are similar to that inthe outgoing packet filter algorithm described above.

5.4. State Information and dynamic decision makingIf the packet is a new packet, then it’s state is saved. If there is a response to this packet,the source IP address is added to the whitelist. If the response is to an incoming packet,then the source IP address of the incoming packet is added to input whitelist. In thesimilar way, if the response is received for a previously saved outgoing packet, then thedestination IP address of the previous outgoing packet is added to output whitelist. Once

27

the IP Address is added to Whitelist, the packet is forwarded to the destination. Figure5.6 explains the sequence of steps performed. If the incoming packet’s structure does notcomply with the protocol standards and is found to be false, then a track for numberof packets is maintained. Similar is the case with outgoing packets. If the number ofpackets from the same host exceeds the maximum number of fake packet requests defined,the source IP address is blacklisted and the packet is dropped.Limitation of save state

The architecture is designed considering the limitations of the devices of the 6LoWPAN.Due to memory constrained IoT devices, there is a limit on the number of packets thatcan be saved. This limit can be dynamically set. The request/response is verified fromwithin the maximum number of packets saved. This strength of the firewall is as strongas this strategy as it strongly depends on the number of packets saved. The strengthdepends on several factors. The first one is the response time for a request. It is likelythat the quicker the response, the more the probability that the packet state exists withinthe maximum limit of number of packets that can be held at the moment. The secondfactor is the number of nodes within a 6LoWPAN network. The more the number ofnodes, more is the probability for greater number of transactions. Since the packet isdropped if there is no there is no slot in the queue, the packet is lost.

5.5. Adding IP address to WhitelistA node from external network sends a request to the node in the current network. Thefirewall application saves the state of the incoming packet from the client. The nodevalidates the request and replies with a response on successful validation. The firewallexamines this reply and matches with the saved packet state. The firewall adds thesource IP Address of the node to whitelist after confirming the following steps :

• If the source IP address of the incoming packet matches the destination IP addressof the outgoing packet

• If the destination port of the incoming packet matches the source port of theoutgoing packet

• If the CoAP response message is not RST

• If ChangeCipherSpec and finished messages are exchanged successfully in DTLStransactions

5.6. Adding IP address to Blacklist5.6.1. Denial of Service attackThe firewall examines every incoming packet and saves the packet on confirming it is avalid packet. If the source IP address in not in whitelist and if the number of incoming

28

packets from the same IP address are greater than or equal to the maximum number offake packets allowed, the source IP address is blacklisted. This IP Address is added toinput blacklist. Once an IP address is blacklisted, all the subsequent packets from thatsource IP address are blocked by the firewall.

5.6.2. CloneID attackIf the source address of incoming packet is one of the nodes in the current network, itindicates the IP address is spoofed. This source IP address is blacklisted.

5.7. CoAP and DTLS protocol parsing5.7.1. CoAPThe Constrained Application Protocol (CoAP) [22] is a specialised web transfer protocolfor use with constrained nodes and constrained networks. The protocol is designed formachine-to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints andincludes key concepts of the Web such as URIs and Internet media types. CoAP isdesigned to easily interface with HTTP for integration with the Web while meetingspecialised requirements such as very low overhead, and simplicity for constrainedenvironments.

Primary features of CoAP are:

• M2M requirements in constrained environments are fulfilled.

• UDP binding with discretionary support for unicast and multicast requests

• URI and Content-type support

• proxy and caching capabilities

• stateless HTTP mapping allowing access to CoAP resources

• Security binding to Datagram Transport Layer Security (DTLS)

Result: pass or failcheck message type; if message type != confirmable or non-confirmable oracknowledgement or reset then

return fail;endcheck class; if class != request code or class!= response code then

return fail;endreturn pass;

Algorithm 3: CoAP protocol parsing.

29

Figure 5.2.: Messaging model - Confirmable and Non confirmable messages.

Messaging ModelThe CoAP messaging model is based on the exchange of messages over UDP between

endpoints. CoAP uses a short fixed-length binary header (4 bytes) that may be followed bycompact binary options and a payload. The various message types according to algorithm3 are briefed here. According to [22] a message when marked as Confirmable(CON)adds reliability feature of TCP. A Confirmable message is retransmitted using a defaulttimeout and exponential back-off between retransmissions, until the recipient sends anAcknowledgement message (ACK) with the same Message ID from the correspondingendpoint as shown in Figure 5.2 When a recipient is not at all able to process a Confirmablemessage, it replies with a Reset message (RST) instead of an Acknowledgement (ACK).A message like stream of sensor data that does not require reliable transmission can besent as a Non-confirmable message (NON). The message has a Message ID for duplicatedetection though they are not acknowledged.

Request/Response ModelCoAP messages include either a Method Code or Response Code while CoAP request

and response semantics are carried out. A request is carried in a Confirmable (CON)or Non-confirmable (NON) message, and, if immediately available, the response to arequest carried in a Confirmable message is carried in the resulting Acknowledgement(ACK) message. CoAP makes use of GET, PUT, POST and DELETE methods, Methodsbeyond the basic four can be added to CoAP in separate specifications.

5.7.2. DTLSThe DTLS protocol adds security to communication data between applications. Datagramtransport does not provide reliability or in-order delivery of data. DTLS is to construct”TLS over datagram transport”. Packet loss and reordering is very common in datagramcommunications. Hence, TLS cannot be used.

30

5.7.2.1. Record Layer

As explained in [12], in addition to the TLS 1.1 record layer, explicit sequence number isincluded in DTLS record layer. This sequence number allows the recipient to correctlyverify the TLS MAC. The DTLS record format is shown below:

struct {ContentType type;ProtocolVersion version;uint16 epoch; // New fielduint48 sequence number; // New fielduint16 length;opaque fragment[DTLSPlaintext.length];} DTLSPlaintext;

5.7.2.2. Handshake Protocol

In addition to the flows as TLS, DTLS has added the following changes:

• A stateless cookie exchange has been added to prevent denial of service attacks.

• Modifications to the handshake header to handle message loss, reordering andfragmentation.

• Retransmission timers to handle message loss.

Result: pass or failcheck content type; if content type != (handshake or changecipherspec or alert orapplicationdata) then

return fail;endif major version != (valid version) then

return fail;endif minor version != (valid version) then

return fail;endcheck handshake type; if handshake type != valid codes then

return fail;endcheck changecipherspec;if changecipherspec is NOT valid then

return fail;endreturn pass;

Algorithm 4: DTLS protocol parsing.

31

Figure 5.3.: DTLS session establishment.

The algorithm for filtering DTLS packets is described in 4DTLS session can be seen inFigure 5.3. The firewall tracks the number of times a DTLS client is trying to establishDTLS session with a DTLS server. Any communication that does not end with theChangeCipherSpec and finished is counted as an attempt to establish unsuccessful DTLSsession. If the number of such attempts exceeds the maximum number of connection triesallowed, it is blacklisted. If the connection is successful, the IP address is whitelisted.The stateless cookie in ClientHelloVerify is verified against the cookie in Client Hello inorder to prevent denial of service attacks.

5.8. Maintaining Whitelist and Blacklist filesThe architectural design decision made is to use files instead of lists. This decision is aptin the environment with resource constrained devices as memory available is limited. Theprimary scientific contribution of this thesis is using files to whitelist and blacklist theIP addresses instead of using lists/data structures as they occupy much RAM/memoryduring execution. By saving the whitelist, blacklist, rules in files, only the requiredrecords are loaded in the memory during execution and this reduces the need for moreresources in the constrained devices. Coffee file system [8] is used to deal with fileoperations such as open a file, close a file, read from file, write into file, reserving spacefor files. The file system size is 8KB. 500MB has been reserved for each of the four files.

32

Figure 5.4.: Packet format for acknowledgment.

The four files are input whitelist, output whitelist, input blacklist and output blacklist.As is evident from the name, all the incoming packets with a source IP address in

the input whitelist are forwarded. Similarly, all the outgoing packets with a source IPaddress in the output whitelist are forwarded to destination. In a similar way, all theincoming packets with a source IP address in the input blacklist are dropped at borderrouter. The outgoing packets with the source IP address in output blacklist are droppedat border router.

Tradeoffs between files and lists

As mentioned above, the 6LoWPAN has sensor nodes with constrained memory. Hence,it is beneficial to use the file system instead of lists which take up RAM. When filesystem is used to store decisions of firewall, it takes up relatively low memory from RAM.Each time, an IP address comparison is made, the file is loaded from file memory andread. Hence RAM takes up only memory as the size of the IP address. This is much lowwhen compared to loading the entire list of IP addresses in memory. The performance interms of time taken when a file system is used can be slightly higher than when list areused. This is absolutely fine considering the resource constrained feature of devices in6LoWPAN.

5.9. Distributed FirewallIn certain cases where a request does not expect a response immediately, it is not ac-knowledged. In such conditions, it is difficult to identify if the packet has been processedsuccessfully or dropped due to an error. This strengthens the argument of having adistributed firewall. In this case, a minor functionality of firewall is added to the endmotes. The end mote acknowledges the border router with the status of packet processing.For example, in CoAP, non-confirmable[NON] messages are not acknowledged. When aCoAP server receives NON, it acknowledges the border router if the message is processed

33

successfully else it returns an error. This helps the border router to identify an attack andtake necessary action. On encountering such a scenario, the firewall tracks the numberof allowable attempts before it blacklists the IP. The packet structure is shown in Figure5.4:As seen in the Figure 5.4, the msg id matches with the message id of the saved packet. Thetype is a character. ’a’ is used to indicate it is an acknowledgment. The status field ’0’ in-dicates it is OK and ’1’ indicates an error has occurred. The structure is described below :

struct ack packet{uint16 t msg id;char type;uint8 t status;}The below structure is the state information of each packet that is saved.struct state{uint16 t id;uint16 t proto;uip ip6addr t srcipaddr, destipaddr;uint16 t srcport, destport;uint16 t mesg id;}The acknowledgment sent to border router consists of message id(msg id) that mustmatch with the mesg id in the state. If the status sent is OK, the source ip address isadded to whitelist.

5.10. Parse firewall rulesThe architecture also provides a flexibility to dynamically add a policy or rule like the IPtables style. This can be done dynamically by the system administrator or anyone withthe right privileges/ access rights. Each rule expects the protocol, source IP address,destination IP address, source port and destination port and a target . The target cantake either of the two possible values - accept or drop. This is the last action that isperformed on a packet data. If none of the above four mentioned actions are not ableto decide to block or allow a packet, this action is reached and executed. The packetdetails are checked against the firewall policies. The IP header data - protocol, source IPaddress, destination IP address and UDP header data - source port and destination portare examined. The target of first rule that matches the packet details is executed andterminated. If the target is allow, then the packet is forwarded. If the target is drop, thenthe packet is dropped. If none of the firewall policies match, then the default policy iscarried out. The default policy depends on the security policy of the 6LoWPAN network.In this experiment, the default policy is forwarding the packet to the destination.

34

5.10.1. Policy SpecificationThe firewall rules can be added by administrator. The rule must be specified in a formatin a file. The structure of firewall rule is :struct rule{struct rule *next;uint16 t id;uint16 t proto;uip ip6addr t srcipaddr, destipaddr;char target;uint16 t srcport, destport;}

A specific format is proposed to specify a firewall rule. JSON format can be used toparse firewall rules. It is not yet implemented. Example :{"rules": [{"protocol": "17","srcipaddr": "aaaa::1234:0:0:3","destipaddr": "bbbb::1234:0:0:5","srcport": "5683","destport": "NULL","target": "a"},{"protocol": "17","srcipaddr": "aaaa::1234:0:0:3","destipaddr": "bbbb::1234:0:0:5","srcport": "5683","destport": "NULL","target": "a"}]}

5.11. ImplementationThe firewall is implemented in Contiki OS, an operating system for IoT. Contiki has awell tested implementation of Routing Protocol [RPL] used by border router to createa DODAG. As firewall is primarily designed to detect and prevent routing attacks, wemake use Contiki operating system to develop the firewall modules. To provide IP

35

communication in 6LoWPAN we use IP, an IP stack in Contiki, and SICSLoWPAN, theContiki implementation of 6LoWPAN header compression. We also implement the denialof service and IP spoofing attacks to evaluate firewall.

The next chapter discusses the experimental setup and evaluation of the firewall.

36

Figure 5.5.: State Diagram.

37

Figure 5.6.: Sequence Diagram.38

6. Evaluation

6.1. Experimental setupThe experiments are carried out on sensor motes running Zolertia Zoul RE-Mote platform.The platform is based on TI’s CC2538 system on chip (SoC), with 32-bit ARM Cortex-M3running at 32MHz. It comprises the powerful CC2538 System-on-Chip 512 kB of programflash and 32 kB of RAM. It has double RF interface : a built-in 2.4 GHz and 863-950MHz radio interfaces (CC1200) compatible with the IEEE 802.15.4 standard.

The border router is compiled on zoul platform. A 6LoWPAN Border Router connects6LoWPAN devices to the Internet and is responsible for handling traffic to and from theIPv6 and 802.15.4 interfaces.

The network is a small, linear 2-hop network with static routes. One Zoul RE-Moteimplements the 6LoWPAN border router connected to a computer running Linux. TheLinux machine simulates a CoAP californium server. The 802.15.4 radio is configured tochannel 15, which underlies WiFi interference.

Figure 6.1.: Experimental Setup.

The setup is shown in Figure 6.1

39

For DTLS client server testbed, leshan server is used as DTLS server. Wakaamabootstrap server is present. Both Leshan server [23] and Wakaama [24] bootstrap serverrun in a linux machine outside the 6LoWPAN. There is a DTLS client node inside6LoWPAN. The DTLS client is programmed to contact bootstrap server which in turnprovides leshan server IP address to the DTLS client in 6LoWPAN.

In this experiment, NULLMAC and NULLRDC are used in order to support DTLSsession establishment. Hence, there is 100% radio duty cycling. The results displayedare averaged over 100 runs. We characterize the motes energy consumption via Contiki’sbuilt-in energy profiler Powertrace.

6.2. Analysis6.2.1. Security Analysis6.2.1.1. Quantitative Analysis

In this section, quantitative evaluation is presented. Here the detection rate is quanti-tatively evaluated. The number of malicious packets successfully detected against thetotal number of malicious packets sent. The true positives rate can be defined as thetotal number of successful processing of packets divided by the total number of packets.Using the above mentioned experimental setup, experiments are run for 30, 60, 90 and100 packets. In all experiments, the firewall application is invoked on packet detectionat border router. The malicious packets are the packets having spoofed IP addresses(cloneId attack), malformed packets having wrong CoAP or DTLS packet structuresthough they arrive on the right port, sending continuous malformed packets (Denialof service) from the same source IP address to the same destination IP address canspoof or alter information, and/or can perform cloneID or DoS attacks. In the followingexperiments firewall first reserves and initializes the various files for storing blacklistedand whitelisted IP addresses, populates the firewall rules to check against. The borderrouter, on detecting a packet invokes the firewall application, that performs packetfiltering as described in Section 5.3, in order to detecting DoS or CloneId attacks attacks.Each experiment is run in a lossless network. Lossless links provide the perfect scenariofor firewall, as all requests and responses return without delay and loss and we get a truepicture of the network.

6.2.1.2. Detection and True Positive Rate

Denial of Service AttacksThe results for the DoS attacks in a lossless network scenario show almost 95% truepositive rate during the first 30 packets. No false positives are detected during thesimulations. This 5% reduction in the true positive rate can be owed to the algorithmimplementation explained in Section 6.2.1.3. A lossless network configuration means thatall requested data is gathered quickly and without losses, which implies that the map ofthe network is a perfect representation of the actual network. Because of this it is very

40

easy to detect all DoS attacks without any false positives. However, with the increase innumber of transmissions, the true positive rate decreases. This is because the packetswere discarded as there is limited space to save the packets. Any packet arrived whenthe list of saved packets is full is discarded. The true positive rate was over 80% for upto100 packets. The rate of transmission also is important. If the packets burst is sent, thenthere is high chance of packets being dropped before they reach the destination.

The various testcases for DoS attacks include

• sending malformed CoAP and DTLS packets

• sending udp packets from same source to same destination

• flooding with clienthello and serverhello in DTLS

From these results it is evident that firewall is very effective against DoS attacks in anetwork with no or few losses.

6.2.1.3. Limitation

However, when the number of packets are sent by a malicious node for the first time, itis forwarded to the destination after performing steps in algorithm 1 or 2. If the numberof such malicious packets surpasses the threshold number allowed, it is blacklisted. Inthis case, first few initial packets are forwarded.

CloneID attacksIn CloneID attack. the IP address of node within the 6LoWPAN is spoofed. Hence,

the source IP address of an incoming packet will be same as the IP address of one of thenodes in 6LoWPAN. In a clone ID attack[21], an attacker copies the identities of a validnode onto another physical node. This can, for example, be used in order to gain accessto a larger part of the network or in order to overcome voting schemes. By keeping trackof the number of instances of each identity it is possible to detect cloned identities whichis done in firewall. The firewall also verifies to see if an IP address has been spoofed.The results are 100% true positives for the initial 30 packets. However, as the packetsincreased, due to insufficient space in the list, the true positive rate was over 90%.

We also measure the detection rate during all of the above experiments. We achieve100% detection rate meaning that we can detect all malicious nodes that launch cloneIdattacks. It should be noted that the 100% detection rate is for the current set ofexperiments with the current setting.

As can be seen in Figure 6.2 the true positive rate is not 100% during detection ofmalicious packets as explained above. Number of fake packets sent is 75 packets. Numberof genuine packets are 25 for experimental purposes.

41

Figure 6.2.: The true positive rate for DoS attacks ranges from 95-80. The true positiverate for IP spoofing ranges from 100-90 with increase in rate of packettransmission.

6.2.2. Performance Analysis6.2.2.1. Memory Consumption

In Table 6.1 presents extra ROM requirements of different modules of firewall. The totaladditional ROM required to host firewall modules inside a constrained node is 5.05kwhich is well below the total available ROM in constrained devices such as 48k in zoulmote. In Table 6.1 it is important to note the overhead column which shows the pureoverhead of firewall modules in Contiki.

Most of the firewall modules are run in border router. Even though border router isnot targeted towards running on constrained nodes it is still lightweight enough and canbe used for small networks.

42

Configuration Overhead(bytes)

Input packet filter 483Output packet filter 252Validation module 1243packet state module 1704protocol parsing module 369rules specification module 890distributed firewall 110

Table 6.1.: Out of 48K ROM in a constrained device (zoul mote) firewall requires 5.05K.

Figure 6.3.: Memory consumption comparison of firewall and border router.

As seen in figure 6.3, the memory share of the FIrewall application is very less comparedto the total application. The data takes 24 bytes, text occupies 5050 bytes, initializedmemory takes upto 808 bytes.

43

6.2.2.2. Energy Overhead

The nodes in the IoT are usually battery powered and hence energy is a scarce resource.Here we measure firewall power consumption at node-level. We use Contiki Powertrace[25] to measure the power consumption. The output from the Powertrace application isthe total time the different parts of the system were on [26]. We calculate the energyusage and power consumption using the nominal values, the typical operating conditionsof the zoul zolteria mote, shown in 6.2

Typical conditions MIN NOM MAX UNITVoltage 2 3.6 VNo Radio, No MCU, Read Flash on 8 mANo Radio, No MCU, Write Flash on 8 mARadio RX, No MCU 20 27 mARadio TX, No MCU 24 34 mAMCU on 13 mAMCU idle 0.0013 mA

Table 6.2.: Operating conditions in Zoul Zolteria RE-Mote.

We use 3V in our calculations. Table 6.2 lists the operating conditions for zoul mote.In the rest of the discussion MCU idle while the radio is off is referred to as low powermode, or LPM. The time the MCU is on and the radio is off is referred to as CPU time.The time the radio is receiving and transmitting with the MCU on is referred to as listenand transmit respectively. We measure energy in duty cycled networks. ENERGEST[27] is used to measure the power consumption values.

Network-wide with Duty CyclingHere we evaluate network-wide energy consumption of a network with and without thefirewall in a duty cycled network. We use ContikiMAC [28], a duty cycling MAC protocolin Contiki. We use the default ContikiMAC setting that has 8 wakeups per second andwithout traffic the radio is on for 0.6% of the time.

Figure 6.4 shows the energy consumption in mJ of border router. Similarly, Figure 6.4portraits the overhead of the firewall and is found to be negligible. Recall that with dutycycling the radio is off for approximately 99% of the time.

Network-wide without Duty CyclingIn order to support DTLS transactions, non duty cycled network is used. The experimentsare run in a non duty cycled network where the radio is always turned on to receiveand transmit packets. When we compare the results of border router with the firewalldetection algorithms we see that the overhead is negligible. This is because the radio isalways on.

44

Figure 6.4.: Energy consumption of a border router.

The energy of border router is calculated as follows

Energy(mJ) = (CPU ∗13mA+LPM ∗0.0013mA+read∗8mA+write∗8mA)∗3V/32768(6.1)

From the network wide energy usage, we calculate the average power as,

Power(mW ) = Energy(mJ)/T ime(s) (6.2)

Write to flashIn this thesis, one of the major decisions in design is to use the flash file system insteadof RAM to save the rules and decisions of the firewall. Here, the write operations energyconsumption is measured. It can be seen in Figure 6.5. As can be seen, these valuesare taken for 100 packets. Energy consumption to write to flash is less than 0.7 mJ perpacket. Here we measure the energy consumption of handling a single packet processingby the firewall inside a border router. Table 6.2 lists the energy required to performdifferent tasks

45

Figure 6.5.: Cumulative energy consumption for writing to coffee file system.

46

7. Discussion and ConclusionsConsidering the potential applications of the IoT it is vital to protect 6LoWPAN networksagainst internal and external attacks. The primary scientific contribution of this thesisis addition of protocol parsing support to IoT protocols CoAP and DTLS. Designingthe firewall considering the resource constrained nature of devices in 6LoWPAN. In thisregard, more importance is given in the architectural decisions to make use of files insteadof lists that take up more RAM. By using files using Coffee file system, the memoryusage of RAM is reduced.

The next major contribution is adding detection and prevention algorithms for DoSand IP spoofing attacks. A firewall is designed, implemented and evaluated. The resultsshow that it is indeed feasible to use it in the context of 6LoWPAN, and the IoT. Theattack detection and prevention algorithms in firewall currently target spoofed or alteredinformation, denial of service attacks. It is flexible and can be extended to detect moreattacks. In addition, it can be extended to add support to more IoT protocols.

The security analysis and performance analysis is carried out on the firewall. Thesecurity analysis show that the true positives rate ranges from 80%-95% and 90%-100%for DoS attacks and IP spoofing respectively. The memory overhead is feasible whencompared to the entire set of applications running in the border router. The overhead interms of power consumption is very less compared to the overall power consumption ofthe border router. Hence, it is feasible to use the firewall for real time networks.

47

8. Limitations and future work

8.1. Limitations8.1.1. Memory constraintsDue to memory constraints of the devices, only certain packets can be processed at atime. If there is no free slot available in the list to store the state information, the packetis dropped. The architecture is designed considering the limitations of the devices of the6LoWPAN. Due to memory constrained IoT devices, there is a limit on the number ofpackets that can be saved. This limit can be dynamically set. The request/response isverified from within the maximum number of packets saved. This strength of the firewallis as strong as this strategy as it strongly depends on the number of packets saved. Thestrength depends on several factors. The first one is the response time for a request. Itis likely that the quicker the response, the more the probability that the packet stateexists within the maximum limit of number of packets that can be held at the moment.The second factor is the number of nodes within a 6LoWPAN network. The more thenumber of nodes, more is the probability for greater number of transactions. Since thepacket is dropped if there is no there is no slot in the queue, the packet is lost.

8.1.2. CoAP and DLTS supportIn the current implementation, only CoAP and DTLS protocol parsing has been added.It does not support other protocols. Only IPV6 UDP packets are handled.

8.1.3. Attacks supportedCloneId and Denial of Service are only supported. Attacks such as wormhole, sybil etcare not detected.

8.2. Future work8.2.1. Support new IoT protocolsThe primary advantages of the architecture proposed in this thesis is extensibility. Thedeveloped system to detect and prevent attacks is scalable. This system design canpotentially add functionality to other IoT protocols like MQTT, LWM2M etc because of

48

the modular approach. In addition to this, support to new attacks can be easily addedas and when new attacks are detected.

8.2.2. Extend distributed firewallAs most of the functionality resides in border router, reliability can be added by havingmultiple copies of border router. This can serve as potential solution to counter thesingle point of failure. Though, the send nodes acknowledge the border router as partof distributed architecture, it cannot independently take any decision. Very minimalfunctionality is in end nodes due to resource constrained nature of the devices. Basedon the application, if flexibility is given to use more efficient end nodes, IoT protocolparsing module can be moved to end node. In this use case, even if the border router isattacked, the end node will be able to defend itself to a certain extent.

8.2.3. Optimize the memory useOne more improvement can be performed in terms of storing the IP address in files usingcoffee file system. Instead of saving the whole 16 bytes of an IPV6 address for nodeswithin the 6LoWPAN, only significant bytes of IP address can be stored. The prefix canbe ignored as it is same for the nodes in a 6LoWPAN. This saves significant amount ofmemory while adding IP addresses to whitelist and blacklist. The space taken up by therules can also be cut down.

8.2.4. Handle encrypted and tunnelled dataDetection of Wormhole attacks can be added. Right now only unencrypted data can beparsed and read by firewall application existing in border router. Encrypted data anddata communication over a tunnel cannot be parsed. As the data is unencrypted at theend node, it is beneficial to implement this module in end nodes instead of in the borderrouter. This can be one extension to existing distributed firewall. Support to detectsybil attacks, impersonation by malicious nodes as multiple fake identities to attractpackets from node, can be added. GUI for adding the firewall rules can be developed.The information gathered can be analysed to detect new attacks and make decisions.

49

9. NobelGridNobel Grid will provide advanced tools and ICT services to all actors in the Smart Gridand retail electricity market in order to ensure benefits from cheaper prices, more secureand stable grids and clean electricity[9]. A smart grid is an electrical grid which includesa variety of operational and energy measures including smart meters, smart appliances,renewable energy resources and energy efficiency resources.

Nobel grid can be considered as a special use case of the problem this thesis tried toaddress.

Figure 9.1 shows the Smart Meter eXtension(SMX) and home area network overviewwith proposed security components highlighted, which are presented below.

9.1. Standards and requirementsThe following security services are necessary within general security requirements:

9.1.1. ConfidentialityMessages that flow between a Smart Home Intelligent Controller(SHIC) and the SMXcould be easily intercepted by an attacker and secret contents are revealed. Therefore,these messages should be hidden from the intermediate entities; in other words, End-to-End (E2E) message secrecy is required in the IoT. Confidentiality services ensure thisthrough encryption/decryption.

9.1.2. Data IntegrityNo intermediary between a SHIC and SMX should be able to undetectably change secretcontents of messages. Message Integrity Codes (MIC) are mostly used to provide thisservice. Source Integrity or Authentication: Both the SHIC and the SMX should be ableto verify the identities of each other to ensure that they are communicating with theentities who they claim to be.

9.1.3. AvailabilityFor smooth working of the HAN and access to data whenever needed, it is also importantthat services that applications offer should be always available and work properly. Inother words malicious activities should be detected. Firewalls, in addition to the securitymechanisms above, can be used to ensure availability security services.

50

9.1.4. Replay ProtectionA compromised intermediate node can store a data packet and replay it at later stage.The replayed packet can contain a typical sensor reading (e.g. a temperature reading)or a DR Service request. It is therefore important that there should be mechanisms todetect duplicate or replayed messages. Replay protection or freshness security servicesprovide this, which can be achieved through integrity-protected timestamps, sequencenumbers, nonces etc.

9.1.5. Non-repudiationNon-repudiation ensures that neither SHIC nor SMX can deny a message that they havesent, such as a request for a service, or a report on request fulfilment. Digital signaturescan be used to provide a non-repudiation security service. While the listed functionalitiesneed to be provided by a complete system, they can be enforced on different systemlevels, with different benefits and constraints. Below we discuss issues specific to differentsystem levels.

9.2. Security9.2.1. Security and data privacySecurity and privacy issues are of key importance when introducing new technology toconsumers, especially in home areas and regarding potentially sensitive personal data.This section exists to highlight security requirements and security aspects of the selectedsolutions.

9.2.1.1. End to end security

By selecting IPv6 as the base for the Smart Home communication, advanced securityprotocols of top of IP becomes available. The primary challenge that may hinder theuse of these security solutions in HANs is that established protocols are not designed forresource constrained devices but for standard computers where energy sources, processingcapability and storage space are not main constraints. Hence the old standards willneed to be complemented with protocols specifically developed for resource constrainedsystems.

9.2.1.2. Link layer security

End to end security protocols are necessary, and to ensure most of the required securityservices they are sufficient. However, they are not always suitable as replacements of linklayer security, for networks with a large number of hops. With link layer security, theaccess to the wireless medium is more limited for an intruder, as compromised packetscould be discarded immediately. However, there is a trade-off between the overhead of

51

Figure 9.1.: HAN Security Aspects.

providing encryption at the link layer and the overhead of routing fake/injected packetsthrough multiple hops to the destination where they would be ultimately detected.Another concern is that link layer key management is not standardised whereas IP basedsecurity protocols have well specified key management solutions.

9.2.1.3. Network security

Though communication security protects messages, networks are still vulnerable to anumber of attacks aimed to disrupt the network. In an unprotected IoT setup anyInternet host can easily drain a constraint devices’ power by sending multiple requests.To this end, firewall functionality to protect the interface between a HAN and the SMXservices is needed. Current firewalls are design to protect local area networks from remoteInternet hosts. It is necessary that critical infrastructure such as smart grid be protectedfrom IP-connected smart homes devices, while allowing certain limited access.

9.2.1.4. Privacy concerns

With the proposed design, scenarios where appliances are communicating with multiplehosts are possible. An example would be a washing machine which could be controllablefrom an SMX application, and at the same time report usage data directly to themanufacturer, or alternatively is controlled directly from the manufacturer’s externalserver, but allows status data to be read locally. This highlights: The need for a two wayfirewall; if the appliance is compromised and starts behaving badly the traffic could beblocked. The need for mechanisms to revoke data access rights from applications, in any

52

case where the user stops trusting the manufacturer and no longer wants to risk havingdata leaked from the local application.

9.3. SolutionIn order to meet the above requirements, the goal is to allow only CoAP, DTLS andLWM2M protocols from the sensor network to the outside world. Hence, this thesisserves as a solution to the above problem by allowing protocol parsing support alongwith the encryption of data using DTLS. This adds validation of packets by performingprotocol parsing and also identifying and preventing Denial of Service and IP spoofingattacks, thus providing network and end-to-end security of the communicating parties.

53

Appendices

54

A. Appendix

A.1. Source filesThe list of files in source code are described in this section. In the contiki tree, go to appsfolder. There is a application by name ”firewall”. There are multiple files in the app.

1. The header file contains macro definitions, structures, data structures like liststhat are used in the app. It has list of method definitions used in the source files.Various structures defined are :

• state - defines state information of packet - protocol, source ip address andport, destination ip address and port, message id.

• rule - defines rule information including protocol, source ip address and port,destination ip address and port and target.

• ip list - defines IP address• ack packet - defines the acknowledgment packet structure to be sent to border

router.

2. The source files contain the actual logic.The initialisations file has the different initialisations.

• initialize rules• initialize files• initialize log file• init save state

3. The protocol parsing file contains the code for parsing the packet when it receivesa CoAP or DTLS packet. The algorithms mentioned in architecture chapter forprotocol parsing are implemented in this file.

• parse app data - Parses the packet data• check in list

4. The firewall fileoperations has all the source code related to whitelisting andblacklisting files. It has methods that reserve memory and initialise the files, addsan IP address to file and reads an IP address from file. Some of the importantmethods are :

55

• add to list• check in list• print addr• print rules• print udp headers• print packet data

5. The firewall file has the main logic. Some of the important functionalities are:• firewall init - Initializes the firewall application• validate ip - validates IP address• validate port - validates port• save packet state - saves the packet data and verifies if a response has arrived• packet input filter - performs series of processing steps on incoming packets• packet output filter - performs series of processing steps on outgoing packets• parse rules

A.2. Running firewall applicationTo run the firewall application, compile border router to include the firewall application.In Makefile of border router, include firewall application by :

APPS+=firewall

A.3. Configuring the router advertisement daemonBefore setting up the DTLS servers you will need to setup the networking if you arenot running both the 6LoWPAN network border router and the DTLS servers on thesame PC. To get all the connected nodes on the ethernet network to be able to reach the6LoWPAN network on the 6LoWPAN prefix the IoT gateway needs to be forwardingIPv6 traffic and to announce router information. To configure for IPv6 forwarding do:

sudo sysctl -w net.ipv6.conf.all.forwarding=1

Start up the radvd daemon on the IoT Gateway - running the border router - withthe following configuration: (in /etc/radvd.conf)

56

interface eth0{AdvSendAdvert onprefix fd01::/64{AdvOnLink on;AdvAutonomous on;}prefix fd00::/64{AdvOnLink off;AdvAutonomous off;}}This script assigns IP address with prefix fd01 to all the linux machines that are connectedvia a switch. The 6LoWPAN prefix in this case id fd00.

In project-conf.h, set the MAC and RDC to NULLMAC and NULLRDC in orderto support DTLS transactions. Also, increase the buffer size to maximum. For otherprotocols like CoAP, default settings of CONTIKIMAC and CSMA can be used. Thedefault buffer size of 140 bytes can be used.

#undef NETSTACK CONF RDC#define NETSTACK CONF RDC nullrdc driver

#undef NETSTACK CONF MAC#define NETSTACK CONF MAC nullmac driver

#ifndef UIP CONF BUFFER SIZE#define UIP CONF BUFFER SIZE 1280#endif

Make a callback to the packet filter function.To run the border- router along with the firewall application, compile any mote with

border router.Example command for zoul mote:

$sudo make clean TARGET=zoul border-router.upload

Run tunslip on a interface connected to a machine running Linux, MAC OS, Win-dows. The tutorial can be referred [29]

57

Bibliography[1] “Tcp versus 6lowpan.” http://orbigo.net/wp-content/uploads/2011/06/

6LoWPAN_Stack.png. Accessed: 2016-06-16.

[2] “6lowpan.” http://processors.wiki.ti.com/images/8/8c/20979_6LowPan_mesh.jpg. Accessed: 2016-06-21.

[3] “Rpl border router.” http://anrg.usc.edu/contiki/images/e/ee/Diagram.png.Accessed: 2016-06-16.

[4] “Iot.” http://internetofthingsagenda.techtarget.com/definition/Internet-of-Things-IoT. Accessed: 2016-06-17.

[5] R. H. Weber, “Internet of things–new security and privacy challenges,” ComputerLaw & Security Review, vol. 26, no. 1, pp. 23–30, 2010.

[6] “Security solutions in iot.” http://www.iconlabs.com/prod/internet-secure-things-%E2%80%93-what-really-needed-secure-internet-things.Accessed: 2016-03-14.

[7] “Firewall importance.” http://www.iconlabs.com/prod/security-requirements-embedded-devices-%E2%80%93-what-really-needed.Accessed: 2016-06-17.

[8] N. Tsiftes, A. Dunkels, Z. He, and T. Voigt, “Enabling large-scale storage in sensornetworks with the coffee file system,” in Proceedings of the 2009 InternationalConference on Information Processing in Sensor Networks, pp. 349–360, IEEEComputer Society, 2009.

[9] “Nobel grid.” http://nobelgrid.eu/about-nobel-grid/. Accessed: 2016-02-24.

[10] “Contiki os.” http://www.contiki-os.org/. Accessed: 2016-02-24.

[11] A. Dunkels, B. Gronvall, and T. Voigt, “Contiki-a lightweight and flexible operatingsystem for tiny networked sensors,” in Local Computer Networks, 2004. 29th AnnualIEEE International Conference on, pp. 455–462, IEEE, 2004.

[12] E. Rescorla and N. Modadugu, “Datagram transport layer security version 1.2,” RFC6347, RFC Editor, January 2012. http://www.rfc-editor.org/rfc/rfc6347.txt.

58

[13] S. Raza, H. Shafagh, K. Hewage, R. Hummen, and T. Voigt, “Lithe: Lightweightsecure coap for the internet of things,” IEEE Sensors Journal, vol. 13, pp. 3711–3720,Oct 2013.

[14] M. Wilhelm, I. Martinovic, J. B. Schmitt, and V. Lenders, “Wifire: a firewall forwireless networks,” ACM SIGCOMM Computer Communication Review, vol. 41,no. 4, pp. 456–457, 2011.

[15] “J. wright. killerbee practical zigbee exploitation framework (presented at toorcon10), oct. 2010..” https://github.com/riverloopsec/killerbee. Accessed: 2016-02-24.

[16] U. Murthy, O. Bukhres, W. Winn, and E. Vanderdez, “Firewalls for security inwireless networks,” in System Sciences, 1998., Proceedings of the Thirty-First HawaiiInternational Conference on, vol. 7, pp. 672–680, IEEE, 1998.

[17] P. Yi, T. Zhu, Q. Zhang, Y. Wu, and J. Li, “Green firewall: an energy-efficient intru-sion prevention mechanism in wireless sensor network,” in Global CommunicationsConference (GLOBECOM), 2012 IEEE, pp. 3037–3042, IEEE, 2012.

[18] J. Ma, P. Yi, Y. Zhong, and S. Zhang, “S firewall: A firewall in wireless sensornetworks,” in Wireless Communications, Networking and Mobile Computing, 2006.WiCOM 2006. International Conference on, pp. 1–4, IEEE, 2006.

[19] C. Karlof and D. Wagner, “Secure routing in wireless sensor networks: Attacks andcountermeasures,” Ad hoc networks, vol. 1, no. 2, pp. 293–315, 2003.

[20] O. Garcia-Morchon, S. Kumar, R. Struik, S. Keoh, and R. Hummen, “Securityconsiderations in the ip-based internet of things,” 2013.

[21] L. Wallgren, S. Raza, and T. Voigt, “Routing attacks and countermeasures in therpl-based internet of things,” International Journal of Distributed Sensor Networks,vol. 2013, 2013.

[22] Z. Shelby, K. Hartke, and C. Bormann, “The constrained application protocol(coap),” RFC 7252, RFC Editor, June 2014. http://www.rfc-editor.org/rfc/rfc7252.txt.

[23] “Leshan server.” http://www.eclipse.org/leshan/. Accessed: 2016-06-16.

[24] “Wakaama bootstrap server.” http://projects.eclipse.org/projects/technology.wakaama. Accessed: 2016-06-16.

[25] A. Dunkels, J. Eriksson, N. Finne, and N. Tsiftes, “Powertrace: Network-level powerprofiling for low-power wireless networks,” Tech. Rep. T2011:05, Swedish Instituteof Computer Science, Mar. 2011.

59

[26] S. Raza, L. Wallgren, and T. Voigt, “Svelte: Real-time intrusion detection in theinternet of things,” Ad Hoc Netw., vol. 11, pp. 2661–2674, Nov. 2013.

[27] A. Dunkels, F. Osterlind, N. Tsiftes, and Z. He, “Software-based on-line energyestimation for sensor nodes,” in Proceedings of the 4th workshop on Embeddednetworked sensors, pp. 28–32, ACM, 2007.

[28] “Contikimac.” http://soda.swedish-ict.se/5128/. Accessed: 2016-06-14.

[29] “Rpl border router.” http://anrg.usc.edu/contiki/index.php/RPL_Border_Router. Accessed: 2016-06-16.

60

TRITA TRITA EE 2016:110

www.kth.se