internet of things (iot): security analysis & security ... · pdf filedoi :...

DOI : 10.23883/IJRTER.2017.3126.6IBUA 417

Internet of Things (IoT): Security Analysis & Security Protocol CoAP

Vishwesh J1, Rajashekar M B2 1, 2Assistant Professor, Computer Science Department, GSSS Institute of Engineering &

Technology for Women, Mysuru, Karnataka, India -570016

Abstract—The paper presents a survey and analysis on the current status and concerns of Internet

of things (IoT) security. The IoT framework aspires to connect anyone with anything at anywhere. IoT

typically has a three layers architecture consisting of Perception, Network, and Application layers. A

number of security principles should be enforced at each layer to achieve a secure IoT realization. With

the rapid growth of IoT, there is also a steady increase in security vulnerabilities of the linked objects.

For example, a car manufacturer may want to link the systems within a car to smart home network

networks to increase sales, but if all the various people involved do not embrace security the system will

be exposed to security risks. As a result, there are several new published protocols of IoT, which focus

on protecting critical data. CoAP (Constrained Application Protocol) is the application layer protocol

designed as replication of the HTTP to serve the small devices coming under class 1 and 2. Many

implementations of CoAP has been accomplished which indicates it’s crucial and upcoming role in the

future of IoT applications. This research article explored the security of CoAP over DTLS incurring

many issues and proposed solutions as well as open challenges for future research.

Keywords—Internet of things; IoT; Security, CoAP

I. INTRODUCTION

Internet of things (IoT) is a collection of many interconnected objects, services, humans, and

devices that can communicate, share data, and information to achieve a common goal in different areas

and applications. IoT has many implementation domains like transportation, agriculture, healthcare,

energy production and distribution. Devices in IoT follow an Identity Management approach to be

identified in a collection of similar and heterogeneous devices. Similarly, a region in IoT can be defined

by an IP address but within each region each entity has a unique.

The purpose of IoT is to transform the way we live today by making intelligent devices around us

perform daily tasks and chores. Smart homes, smart cities, smart transportation and infrastructure etc.

are the terms which are used in relevance with IoT. There are many application domains of IoT,

ranging from personal to enterprise environments [1]. The applications in personal and social domain

enable the IoT users to interact with their surrounding environment, and human users to maintain and

build social relationships. Another application of IoT is in transportation domain, in which various

smart cars, smart roads, and smart traffic signals serve the purpose of safe and convenient transportation

facilities. The enterprises and industries domain encompass the applications used in finance, banking,

marketing etc. to enable different inter- and intra- activities in organizations. The last application

domain is the service and utility monitoring sector which includes agriculture, breeding, energy

management, recycling operations, etc.

The Internet of things protocols are redefining the debate about security issues and therefore open doors

for discussion. Considering the well-known and widely used protocols which are not suitable for the big

International Journal of Recent Trends in Engineering & Research (IJRTER) Volume 03, Issue 03; March - 2017 [ISSN: 2455-1457]

@IJRTER-2017, All Rights Reserved 418

improvement of IoT, new protocols have been introduced which match the light devices used for

communication. Therefore, their recent existence makes security a valuable research topic. In this paper,

we studied and illustrated various protocols by highlighting their security status. Moreover, one of the

protocols, for instance CoAP is examined specifically for its specification architecture, security and

implementation.

The five layers that represent the IoT are physical, MAC, adaptation, network and application. The

protocols mechanism work in parallel with the related layer. Furthermore, physical layer protocols are

modularized to connect with a 2 Mbps data rate transmission [2], which match the diffusion technique

needed for physical communication. Nevertheless, 802.15.4 cover both PHY and MAC layers, the

6LoWPAN adaptation layer is responsible for universal internet connectivity, the RPL works in the

network to routes over low power and lossy networks, and finally CoAP is an application layer protocol.

Moreover, all these protocols contain different technique, data rate and communication channel. Most

importantly, the security standards and issues are also different from each other.

The CoAP is an application layer protocol (for IoT appli-cations) (Figure 1) and is estimated to be the

future of all application protocols. CoAP is a customized and compressed version of HTTP protocol and

share the same methods and principles (RESTful). Many vendors adopt CoAP for their IoT devices

which are light-weight and consume low energy. The security of CoAP is a hot topic as it does not have

reliable stan-dards for secure architectures. As security is important to protect the communication

between devices, DTLS (Datagram Transport Layer Security) is used. DTLS has been examined by

researchers to find out how it optimises the security of the protocol and manages threats. However, there

has been a lack of key research on how security can be managed, which incidentally is also one of the

challenges that face the CoAP protocol. This research presents a security analysis and examines the

current status related to each protocol discussed above and CoAP in detail. Furthermore, the paper also

presents solutions to overcome the existing problems and identifies performance gaps.

Fig. 1: layers and protocols

II. IOT PROTOCOLS & SECURITY

As there are numerous devices that are intelligently connecting various objects or things to each other.

But still there is a need for IoT to integrate these gadgets, which are using different communication

protocols. Communication is the only way for these smart devices to exchange the data with each other.

Therefore, the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task

Force (IETF) are working to form and develop standardized protocols. According to [4], the common

features in all the new IoT protocols and structural standards are:

• Lower power communication: Most devices run on batteries and consume very low power, but

disruption can occur in communication when the battery drains out. However, larger batteries with

more power capacity are not light-weight. Therefore, designing IoT protocols that allow low-power



wireless devices to communicate are a challenging task.

• Reliable and highly communication: For IoT transmission, internet connectivity should be faster and

more reliable. However, the main source of unreliability is external interference due to signal failure

(e.g., Wi-Fi), which can terminate online communication. This may require network agencies to re-

transmit, resulting in the consumption of more power.

• Internet-Enabled: Machine to machine communication enabled by internet connections has to be a

universal approach [2].

A. 802.15.4 Protocol

Both PHY and MAC layers are ruled by IEEE 802.15.4 protocol. IEEE 802.15.4 was established in

2003, and several efforts were made later to improve it. Finally, the task was accomplished in 2006 by

different groups. The most widely used band for this protocol is 2.42.485 GHz frequency. The frequency

limits of the length of a packet is 128 bytes when transmitted by radio. The security of IEEE 802.15.4 is

not designed for the PHY, but it is implemented in the MAC layer. The same protocol will control the

format of MAC header by defining the format of the fields like source and destination. Add to that, in

2008 an added feature was introduced called Time Synchronized Channel Hopping which upgraded the

protocol work by enabling high reliability while maintaining very low duty cycles which are

recommended requirements for the emerging IoT [2].

An IEEE 802.15.4 network is vulnerable to security threats/attack, which include active tampering

and eavesdrop-ping. However, IEEE 802.15.4 offers security services and has a stable mechanism. Also,

the protocol has a set of security modes that include various services. In more detail, the security

depends on Advanced Encryption Standard (AES) and symmetric cryptography. While there are eight

security suites, their specifications vary. It provides data encryption and data authentication with either 32, 64 or 128 bits [3]. Confidentiality, data authenticity and protection are also provided, however they

might be an option in some security modes.

Another security service provided is the access control which enable the devices to search for the

information about a security mode and other security information so it can process the security of the

message. The Time Synchronized Channel Hopping provides protection to replay attacks [3]. Yet the

security in this protocol has a drawback in that it does not apply key management modeling, considering

cases where the messages between the sender and receiver might reuse the nonce value.

B. 6LoWPAN

Lower power wireless 6LoWPAN is a network protocol which allow direct connection to the Internet

using open standards. It defines encapsulation and header compression mechanisms. The standard has

the freedom of frequency band and physical layer. It has the flexibility to perform over multiple

communications platforms, including Ethernet, Wi-Fi and 802.15.4 [2].

6LoWPAN protocol was introduced in 2007, as there was an immense need for a low-energy IoT

protocol. This protocol plays a major role in IoT wireless communication as it replaced IPv6. It acts by

supporting addresses with different lengths, low bandwidth, star and mesh topologies, battery supplied

devices, low cost, large number of devices, unknown node positions, high unreliability, and long idle

periods during when communications interfaces are turned off to save energy [2]. The technique adopted

in this protocol comprises of the frame format and header compression mechanisms.



There are no security mechanisms in the 6LoWPAN adap-tation layer, however there are decent amount

of discussion about vulnerabilities and solution proposals. One of the issues, was identification: a

scenario of forging or duplicating the EUI-64 interface which can compromise the unique interface

identifier of 6LoWPAN. Another key issue was the usage of compression UDP (User Datagram

Protocol) which reduces the number from 16 to 4 bits [3]. The risk here involves the possibility of an

application receiving the wrong type of payload or the wrong message. In section V, we outline the

compression of DTLS through 6LoWPAN for security purposes.

The solution proposal describes the adoption of Internet Protocol Security (IPsec) over the protocol for

future end-to-end IoT or back-end devices. Also, designing compressed secure header was another

approach, for the existing authentication layer (AH) and Encapsulating Security Payload (ESP) for

tunnel and transport mode. Another proposal, was security against packet fragmentation attack. The

solution proposed is to add new fields to the protocol fragmentation header to support security against

unidirectional and bidirectional fragment replays. Key management was the last proposal which can be

used to deal with the authentication, and one of the approaches is to compress the IKE headers and

payload information using the protocol [1].

C. Routing - RPL

RPL, also known as the network layer protocol is a distance vector routing protocol for Low power and

Lossy Networks (LLNs) using IPv6. Network devices running RPL protocol are connected with no

present cycles. Due to that, the Destination Oriented Directed Acyclic Graph (DODAG) was built and is

called a DODAG root [2].

RPL supports message confidentiality and integrity. It has been designed in such a manner that link-

layer mechanisms can be used when available and appropriate; yet, in their absence, RPL can use its own mechanisms. RPL has three basic security modes.

III. COAP OVERVIEW

The application layer CoAP protocol was originally developed for web transfer with constrained nodes

and networks in the Internet of Things. The protocol is a HTTP remark-able version to match the IoT

requirement for low overhead and multicast support. CoAP depends on REST, a principle adopted from

HTTP and embedded in UDP for the transaction. The initial reason for developing this protocol is to

match the high requirement of IoT and the need for low rate and light protocol [2, 3]. Overall, the main

features of CoAP are: it supports M2M requirements in constrained environments, UDP binding with

optional supporting unicast and multi-cast requests, asynchronous message exchanges, low header

overhead and parsing complexity, supports URI (Universal Resource Identifier) and content-type, and

that it has simple proxy and caching capabilities [5].

A. CoAP Architecture

CoAP architecture split into two layers, message layer and request/response layer. The first layer is

responsible for controlling the message exchange over UDP between two end points. The format of the

message will be outlined next. While the second layer carries the request and response which hold the

method code and response code in order to avoid issues such as the arrival of messages that are out of

order, lost or duplicated. Thus, CoAP is a reliable mechanism with rich features such as, simple stop-and

wait re-transmissions, duplicate detection and multicast support. CoAP uses a short fixed-length binary

header and components, and messages are encoded in binary simple format [2, 3]. Figures 2 and 3 show



each component and the message format.

The methods supported in CoAP are based on the REST ful structure which is listed as follows:

Fig. 2: structure/format of CoAP message

• GET: operation to retrieve representation in resource identified by the URI request;

• POST: request the server to create a new subordinate resource under the requested parent URI;

• PUT: requests resource identified by the request URI to update/created with the enclosed message

body;

• DELETE: requests resource identified by the request URI to delete.

URI in CoAP is similar to HTTP, where the unsecure URL starts with CoAP:// and the secure URI is

CoAPs:// [6]

Fig. 3: Details of CoAP message components

IV. IOT SECURITY ISSUES

Typical security goals of Confidentiality, Integrity and Availability (CIA) also apply to IoT. However,

the IoT has many restrictions and limitations in terms of the components and devices, computational

and power resources, and even the heterogonous and ubiquitous nature of IoT that introduce additional

concerns. This section consists of two parts: the general security features that the IoT must have, and the

security issues specific to each layer of the IoT.

A. The Security Features of IoT

The security challenges of IoT can be broadly divided into two classes; Technological challenges and

Security challenges [5]. The technological challenges arise due to the heterogeneous and ubiquitous

nature of IoT devices, while the security challenges are related to the principles and functionalities that



should be enforced to achieve a secure network. Technological challenges are typically related to

wireless technologies, scalability, energy, and distributed nature, while security challenges require the

ability to ensure security by authentication, confidentiality, end-to-end security, integrity etc. Security

should be enforced in IoT throughout the development and operational lifecycle of all IoT devices and

hubs [4]. There are different mechanisms to ensure security including:

The software running on all IoT devices should be authorized.

When an IoT device is turned on, it should first authenticate itself into the network before collecting or sending data.

Since the IoT devices have limited computation and memory capabilities, firewalling is necessary

in IoT network to filter packets directed to the devices.

The updates and patches on the device should be installed in a way that additional bandwidth is not consumed.

Given below are the security principles that should be enforced to achieve a secure communication

framework for the people, software, processes, and things.

1) Confidentiality:

It is very important to ensure that the data is secure and only available to authorized users. In IoT a user

can be human, machines and services, and internal objects (devices that are part of the network) and

external objects (devices that are not part of the network.

2) Integrity

The IoT is based on exchanging data between many different devices, which is why it is very important

to ensure the accuracy of the data; that it is coming from the right sender as well as to ensure that the

data is not tampered during the process of transmission due to intended or unintended interference. The

integrity feature can be imposed by maintaining end-to-end security in IoT communication. The data

traffic is managed by the use of firewalls and protocols, but it does not guarantee the security at

endpoints because of the characteristic nature of low computational power at IoT nodes.

3) Availability

The vision of IoT is to connect as many smart devices as possible. The users of the IoT should have

all the data available whenever they need it. However data is not the only component that is used in

the IoT; devices and services must also be reachable and available when needed in a timely

fashion in order to achieve the expectations of IoT.

4) Authentication

Each object in the IoT must be able to clearly identify and authenticate other objects. However, this

process can be very challenging because of the nature of the IoT; many entities are involved (devices,

people, services, service providers and processing units) and one other thing is that sometimes objects

may need to interact with others for the first time (objects they do not know) [8]. Because of all this, a

mechanism to mutually authenticate entities in every interaction in the IoT is needed.

5) Lightweight Solutions

Lightweight solutions are a unique security feature that is introduced because of the limitations in the

computational and power capabilities of the devices involved in the IoT. It is not a goal in itself rather a

restriction that must be considered while designing and implementing protocols either in encryption or

authentication of data and devices in IoT. Since these algorithms are meant to be run on IoT devices

with limited capabilities, so they ought to be compatible with the device capabilities.



V. COAP SECURITY ANALYSIS

Security for CoAP protocol requires the existence of an additional encrypted protocol as a cover, similar

to traditional XML-data representations and protocols (e.g., HTTP and Transport Layer Security (TLS)).

The CoAP uses a UDP protocol and encryption is most commonly accomplished using Datagram

Transport Layer Security (DTLS) and some-times with IPSec. A binding of DTLS to CoAP is required

to secure the messages. DTLS is applied in the transport layer and the fundamental AES/CCM provides

confidentiality, integrity, authentication, and non-repudiation. DTLS is based on the Transport Layer

Security (TLS) protocol and not the application layer. DTLS records are 8 bytes longer than in TLS.

Once a handshake on DTLS is completed an additional 13 bytes will be over headed overhead per

datagram. The process of handshake comes in outgoing and incoming messages scenarios. In the

incoming scenarios the protocol will verify through decryption and decompressing. For outgoing, the

protocol applies encryption algorithm, add authentication code (MAC) and compress the message as

shown in Fig 7. As the header of 6LoWPAN compression employs 10 bytes and CoAP header 4 bytes,

therefore the focus is to compress the DTLS.

Fig. 7: Handshake process

There are four security modes defined for CoAP which are:

• NoSec: this alternative assumes that security is not provided in this mode or in the CoAP transmitted

message.

• PreshardKey: this mode is enabled by sensing devices preprogrammed with symmetric

cryptographic keys. This mode is suitable for applications that support devices that are unable to

employ the public key cryptography. Also, applications can use one key per device or one key for a

group of devices.

• RawPublicKey: the mandatory mode for devices that require authentication based on public key.

The devices are programmed with pre-provisioned list of keys so that devices can initiate a DTLS

session without certificate.

• Certificates: supports authentication based on public key and application that participate in

certification chain. The assumption of this mode is that security infrastructure is available. Devices

that include asymmetric key and have unknown X.509 certificates can be validated using the

certificate mode and provisioning trusted root keys.

VI. SECURITY CHALLENGES IN COAP

In terms of security, CoAP is under scrutiny as there are many challenges and debates. Although it is a

new protocol it is must be compressed with low power. The biggest challenge is to keep the high

performance while maintaining the security standards and providing protection. To elaborate, DTLS is

the official and custom application layer security protocol which can be implemented to provide security

in CoAP, which is not without its limitations and other issues such as: large message and handshake

compression [14], and that DTLS does not suit the CoAP proxy modes.



A study by [15] indicates the issue in the end-to-end communication as in some scenarios a HTTP client

needs to access resource from CoAP back-end server. In that case, the proxy must translate the packet

without scanning to check if there is a malicious code. However, the challenge is that DTLS does not

support multi-cast messages in group communications. In this case, the proxy can translate from HTTP

to CoAP, but the proxy has to decide if it is a multi-cast or unicast message.

A robust key management process provides a solution for all protocols including CoAP. However, in the

case, key management can help in solving the multi-cast message issue within the DTLS and to ensure

security standards are applied.

VII. CONCLUSION

The vision of IoT is to not only make our everyday lives easier but to create safety benefits also.

Security in IoT involves researcher of products to reconsider how they create technologies, secure code

and hardware for example physical, network, applications, compliance etc. Through this paper, we

concentrate on a critical aspect of IoT associated with internet protocols. Although these protocols have

been researched and published, but still required a deep and wide research for further study and analysis

for different issues such as security and solutions mainly. CoAP is one of the major protocols defined as

an application layer protocol. CoAP binds DTLS as the security agent, however there are areas where

DTLS is still lacking and can be considered as a threat for the protocol. The various implementations of

CoAP has considerably increased market interest towards the IoT technologies as there are high chances

that CoAP might change the future of all applications. Future work will focus on simulation evaluation

criteria/ frameworks related to IoT protocols.

REFERENCES 1. L. Atzori, A. Iera, , and G. Morabito, The internet of things: A survey, Computer Networks, Vol. 54, no. 15, pp. 2787-

2805, 2010.

2. M. R. Palattella, N. Accettura, X. Vilajosana, T. Watteyne, L. A. Grieco, G. Boggia and M. Dohler, Standardized

protocol stack for the internet of (important) things, IEEE Communications Surveys & Tutorials, Vol. 15, no. 3, pp.

1389-1406, 2013.

3. J. Granjal, E. Monteiro and J. Silva, Security for the Internet of Things: A Survey of Existing Protocols and Open

Research issues, IEEE Com-munications Surveys & Tutorials, Vol. 17, no.3, pp. 1294-1312, 2015.

4. F. Skarmeta, J. L. Hernndez-Ramos and M. Moreno, A decentralized approach for security and privacy challenges in

the internet of things, in proceedings of the IEEE World Forum on Internet of Things (WF-IoT), South Korea, March 6-

8, 2014.

5. B. C. Villaverde, D. Pesch, R. D. Alberola, S. Fedor and M. Boubekeur, Constrained application protocol for low

power embedded networks: A survey, in proceedings of the IEEE 6th International Conference on Innovative Mobile

and Internet Services in Ubiquitous Computing (IMIS), Italy, July 4-6, 2012.

6. T. A. Alghamdi, A. Lasebae, and M. Aiash, Security analysis of the con-strained application protocol in the Internet of

Things, in proceedings of 2nd IEEE International Conference on Future Generation Communication Technology

(FGCT), UK, Nov 12-14, 2013.

7. I. Ishaq, D. Carels, G. K. Teklemariam, J. Hoebeke, F. D. Abeele, E. D. Poorter, E. D., and P. Demeester, IETF

standardization in the field of the internet of things (IoT): a survey, Journal of Sensor and Actuator Networks, Vol. 2,

no. 2, pp. 235-287, 2013.

8. C. Bormann, A. P. Castellani, and Z. Shelby, Coap: An application protocol for billions of tiny internet nodes, IEEE

Internet Computing, Vol. 16, no.2, pp. 62-67, 2012.

9. C. Lerche, K. Hartke and M. Kovatsch, Industry adoption of the internet of things: a constrained application protocol

survey, in proceedings of the IEEE 17th International Conference on Emerging Technologies & Factory Automation

(ETFA), Poland, Sep 17-21, 2012.

10. K. Kuladinithi, O. Bergmann, T. Ptsch, M. Becker, and C. Grg, Implementation of CoAP and its application in

transport logistics, in proceedings of the Workshop on Extending the Internet to Low power and Lossy Networks,

Chicago, USA, April, 2011.

11. M. Kovatsch, M. Lanter and Z. Shelby, Californium: Scalable cloud services for the internet of things with CoAP, in



proceedings of the IEEE 4th International Conference on Internet of Things (IOT), USA, Oct 6-8, 2014.

12. S. Raza, H. Shafagh, K. Hewage, R. Hummen and T. Voigt, Lithe: Lightweight secure CoAP for the internet of things,

IEEE Sensors Journal, Vol. 13, no. 10, pp. 3711-3720, 2013.

13. A. Bhattacharyya, T. Bose, S. Bandyopadhyay, A. Ukil, and A. Pal, LESS: Lightweight Establishment of Secure

Session: A Cross-Layer Ap-proach Using CoAP and DTLS-PSK Channel Encryption, in proceedings of the IEEE 29th

International Conference on Advanced Information Networking and Applications Workshops, South Korea, Mar 24-27,

2015.

14. A. Capossele, V. Cervo, G. De Cicco, and C. Petrioli, Security as a CoAP resource: an optimized DTLS

implementation for the IoT. In proceedings of the IEEE International Conference on Communication, UK, June 8-12,

2015.

15. M. Brachmann, O. Garcia-Morchon, and M. Kirsche, Security for prac-tical coap applications: Issues and solution

approaches, in proceedings of the 10th GI/ITG KuVS Fachgesprch Sensornetze (FGSN), Germany, 2011.

internet of things (iot): security analysis & security ... · pdf filedoi :...

Documents