Building Datagram Transport Layer Security (DTLS)-based access control in the Internet-of-Things

(1)

IN

DEGREE PROJECT ELECTRICAL ENGINEERING, SECOND CYCLE, 30 CREDITS

STOCKHOLM SWEDEN 2020,

Building Datagram Transport Layer Security (DTLS)-based access control in the Internet-of- Things

CHENXI FENG

KTH ROYAL INSTITUTE OF TECHNOLOGY

SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

(2)

Building Datagram Transport Layer Security (DTLS)-based access control in the

Internet-of-Things

FENG CHENXI

Master in Embedded System Date: May 23, 2020

Supervisor: Marco Tiloca Examiner: Markus Hidell

Swedish title: Bygg DTLS-baserad åtkomstkontroll i Internet-of-Things

School of Computer Science and Communication

(3)

(4)

iii

Abstract

With the widespread use of the Internet of Things (IoT), the security problem has raised social attention. Due to the limited calculation ability of the constrained device, it is difficult to download the defense software inside and the device just can use the built-in encryption mechanisms to defend attack.To overcome complex and volatile sit- uations and challenges in the IoT, we propose a the solution based on a framework called Authentication and Authorization for Constrained Environment (ACE)-OAuth for authentication and authorization which could be applied in the IoT environment. More specifically, we implement the DTLS profile and Internet Engineering Task Force (IETF) IoT stack in ACE framework to build a secure environment in the transport layer. In this work, we focus on the symmetric-based authenti- cated setup that utilize the pre-shared key mode to build the secure channel. The implementation of the proposed solution is based on the Operating System (OS) Contiki-NG and we use the constrained device Zolertia Firefly. The effectiveness of the proposed solution is evaluated by the operational time, power measurement, and memory footprint of the pre-shared key (PSK) mode to establish a secure channel. The result can be treated as a benchmark for the different protocol steps.

We present the footprint of the Random Access Memory (RAM) and Read-Only Memory (ROM), the power measurement and also the operational time.

(5)

iv

Sammanfattning

Samtidigt som den utbredda användningen av IoT har ökat, har även uppmärksamheten av säkerhetsproblemen ökat. På grund av begrän- sad beräkningsförmåga hos enheten är det svårt att ladda ner skydds- programvara vilket gör att enheten endast kan använda de inbygg- da krypteringsmekanismerna för att försvara sig mot attacker. För att övervinna komplexa och känsliga situationer och utmaningar i IoT, vi föreslår en lösning baserat på ett ramverk kallat ACE-OAuth för autentisering och auktorisering som kan tillämpas i IoT-miljön. Mer specifikt, vi implementerar en DTLS-profil och IETF IoT protokollen i ACE ramverket för att bygga en säker miljön i transportlagret. Vi av- slutar den symmetriskt baserade autentiserade inställningen som an- vänder PSK-läget för att bygga den säkra kanalen, men förhoppnings- vis kommer det att finnas några verk på den asymmetriska baserade autentiserade inställningen som använder RawPublicKey (RPK)-läget i andras framtida arbeten. Implementeringen av den föreslagna lös- ningen baseras på OS Contiki-NG och vi använder den begränsade enheten Zolertia Firefly. Effektiviteten hos den föreslagna lösningen utvärderas genom driftstid, effektmätning, och minnesfotavtryck för PSK-läget för att upprätta en säker kanal. Resultatet kan användas som benchmark av de olika stegen i protokollet. Vi presenterar fotavtrycket på RAM och ROM, effektmätning och även driftstid.

(6)

v

Acknowledgements

First of all, I would like to express my gratitude to my supervisor Marco Tiloca for his guidance and help. Also, I would like to thank Markus Hidell for being my examiner and his valuable feedback.

Then, I would like to thank Niclas Finne, the developer of the tinydtls library at the Swedish Institute of Computer Science (RISE SICS), for his help and encouragement, I could not finish the thesis. Also, I would like to thank the former student, Santiago.

I would like to thank Rijad Alisic for the Swedish abstract.

I want to dedicate this work to my parents. Your love is the strongest support in my life. Also, I would like to thank my friends. You make my master study more colorful.

Last but not least, I would like to express my gratitude to my boyfriend, Yu Wang. Thank you for your support and encouragement. I love you!

Chenxi Feng March 25, 2019 In Stockholm.

(7)

Chapter 1 Introduction

IoT is a conceptual framework based on identifying, sensing, network- ing and data processing abilities of the broad range of the devices via embedded wireless or wired connectivity [31]. Many industries have shown the great interest in applying the IoT technologies to projects, e.g., environment monitoring, automotive and transportation, supply chains/logistics, inventory and production management, food processing industry,security surveillance, and others [7]. A network world survey on IoT trends estimates that there will be over 14.2 billion connected IoT devices by the end of the 2019. With an increasing number of connected devices, the network will expand, and data volumes and amounts of information from IoT devices will continue to grow very fast. With the limitations of the processing power, memory constraints, energy-consumption, size and product costs, the IoT should include a high number of resource-constrained devices directly available on the Internet [17]. The unsecured Internet, limited resources, the lossy communication links and new technologies used in IoT, e.g., IPv6 over Low-power Wireless Personal Area Networks (6LoWPAN) and Routing Protocol for low power Lossy network (RPL), are easily under attack, which makes IoT security a high priority [19].

There is an authorization framework raised to support fine-grained and flexible access control to constrained devices based on established and emerging standards [23]. In the direction of scalability, interoperability, lightness and end-to-end security [13], the IETF Authentication and Authorization for Constrained Environment (ACE) has developed a standardized security solution of authorization to grant access to a requesting entity for IoT environment.

1

(11)

2 CHAPTER 1. INTRODUCTION

Figure 1.1: Secure IoT application based on the ACE framework[2]

As shown in Figure 1.1, the ACE framework provides authentication and authorization in secure IoT application and use CoAP and OAuth 2.0 as building blocks. The framework is called ACE-OAuth [24]. Client is an entity which requests resources from the Resource Server (RS) which holds the resources. The application that sends the lock request to the door is a Client and the door itself is a RS that de- cides whether to respond to the request. However, the communication between the control application and the door is not secure. We hence need to utilize the security protocols to provide the communication.

For example, the communication and security protocols can be defined between the Client and the Resource Server (RS).

1.1 Related Work

The recent developments of wireless technologies, e.g., highly integrated devices and chips, the extended bandwidth, improved compe- tence of computing, processing and analyzing data volume, and the storage power, allow the legacy platforms to be transfered into Inter- net Protocol (IP)-enabled infrastructures. Various protocols have been

(12)

CHAPTER 1. INTRODUCTION 3

applied to IoT devices at 7 layers of the Open System Interconnec- tion Reference Model (OSI). To deal with the constrained environment, IETF has published a specialized transfer web protocol for constrained nodes and environment called CoAP. For Low-Power and Lossy Net- works (LLNs), IETF has published the highly extensible routing protocol RPL [32]. At Link Layer, the Institute of Electrical and Electronics Engineers (IEEE) defines the 802.15.4 standard for low-power wireless personal area networks. At Adaption Layer, the 6LoWPAN is defined for transmission of Internet Protocol version 6 (IPv6) packets over IEEE 802.15.4 networks. All of these protocols are designed for energy preservation and for constrained environments¹.

As "Internet of Things (IoT) is Internet of everything", the Inter- net Protocol version 4 (IPv4) with only 32-bit addresses cannot match the expected amounts of devices . So, the IPv6 which adds longer IP address space with new architecture of 128 bits has become the foun- dation of the IoT. In 2017, the Internet Protocol Security (IPsec) profile has been implemented for ACE framework to contextually establish the a secure IPsec channel between the Client and the RS [3]. The work also provides the implementation of the IPsec profile for Contiki which extends the libraries of proof-of-concept of the ACE framework in constrained environment. Constrained RESTful Environments (OSCORE) is a secure profile to provide the security of CoAP in application-layer with COSE [27]. It is also a new model that implements the OSCORE profile in ACE framework which utilizes the secure communication, server authentication and PoP of the key [25].

This work aims to implement the DTLS profile of the ACE framework based on Contiki OS for secure IoT applications.

1.2 Motivation and Objectives

Although IPv6 has improved and simplified IPv4, the IoT devices and systems are still threatened by security challenges. In the aforemen- tioned content, this work focuses on how to provide strong authentication, authorization and data protection for IoT. IPsec support is mandatory in IPv6, but the use of it is not mandatory. If IPsec is not used in network communication, the traditional related IP attacks as

1SEE https://www.cisco.com/c/en/us/about/security-center/secure-iot- proposed-framework.html#2

(13)

well as the new attacks related to the new characteristics of IPv6 make the communication into danger. On the other hand, it is difficult to deploy and manage the working IPsec security architecture, even re- ducing the use of IPsec [6]. Recently, the Datagram Transport Layer Security (DTLS) protocol is also developed in the IoT security communication. We intend to implement the DTLS into the ACE framework between RS and Client to realize secure IoT applications.

The goal of this is to implement the DTLS protocol into the ACE framework for IoT and also experimentally evaluate its performance.

DTLS enables the dynamic security DTLS channel between the Client and the RS with alternative session. By using the ACE framework, the IoT communication has three roles: Authorization Server (AS), Client and RS. We implement the proposed solution in C language in the Contiki-NG OS in Zolertia Firefly motes(TI CC2538). Furthermore, we use the logging system taht supports per-module log levels to record the process of the communication, collect the date of the DTLS profile communication.

1.3 Problem Statement

With the development of the Internet and computers, IoT has received a lot of attention in recent years. However, securty of IoT is still a challenge and a concern, not only for the companies but also for the private. The security threats restrict the development and the deploy- ment of the IoT. The structure of IoT can be divided into three layers: Perception Layer, Network Layer and Application Layer [33]. The Perception Layer collects data from the environment and transfer it in digital signal; Network Layer helps and secures transmission between two other layers; Application Layer builds the communication between users and applications [8][33]. All these layers are exposed to different security threats. Therefore, different technologies should be applied to protect different layers. Therefore, it is very important to build a secure environment for IoT devices.

Recently, the research focuses on light-weight, portable, and power- saving security solutions of IoT devices.

In this work, we focus on an authorization and authentication solution that enables granted approval and flexible access control capabilities. The solution also provides secure communication between client

(14)

and AS, client and RS. The solution is based on DTLS for the ACE framework, where the DTLS profile is integrated into the ACE framework. The integrated solution of DTLS and ACE can delegate management of authorization information to a trusted host, and reduce the processing energy and memory usage for constrained servers.

This work seeks to answer how the DTLS profile could be implemented in the ACE framework in software running on an IoT device, and how memory usage and power consumption can be measured.

One of the challenges is to investigate existing DTLS implementation and OS environments suitable for building the code framework. An- other challenge is to choose the proper measurement time period. To measure the correct time, we should ensure the starting point of the scenario and the termination of the scenario. We present the scenario in Chapter 5. The message processing time and transfer delay make the scenario time error very large. Compared to time measurement, memory usage is stable. It is sufficient to only measure one time and the calculation method is mature ². The power consumption calculation based on the measurement time is shown in Chapter 5. The calculation shows that the average power consumption and error depend on the average time and error.

1.4 Scope

The literature study of the thesis focuses on the IoT communication and security profiles including the DTLS profile and the ACE framework.

The platform for implementation and evaluation was originally Contiki OS, but was changed during the project to Contiki-NG. As a starting point, we build the environment and evaluate the IPsec secure communication based on the ACE framework. Then we implement the DTLS security profile in the ACE framework. Then, we perform experiments including evaluation of memory usage, communication overhead and energy consumption, as well as a comparison against the alternative IPsec profile for the authorization framework. Finally, we implement our model in the Contiki-NG OS.

2https://mcuoneclipse.com/2013/04/14/text-data-and-bss-code-and-data-size- explained/

(15)

1.5 Research Methodology

The methodology is based on a quantitative research approach. More specifically, it consists of design, implementation, and experimental evaluation. As a starting point, we rerun the prototype of the code framework for the IPsec profile of ACE in the Contiki OS of a former master thesis work which serves as a good reference start [4].

We collect the data of the profile and analyze how perform calcula- tions to produce the final results and which time period is meaning- ful for our analysis. First, the code framework of the DTLS profile in ACE in Contiki-NG OS is designed. The code framework is a test- bench of the IEEE profile DTLS for the ACE framework [11]. Then, the work is implemented on the selected hardware platform. We print all the message information and profile execution information to analyze the Concise Binary Object Representation (CBOR) profile encrypting or decrypting the message correctly and in order. Finally, the performance of the framework is analyzed based on the collected data. Apart from the footprint, which is collected once since it would not change according to other elements, the test of the power consumption at least runs 20 times. We sort the data in average and also calculate the varia- tion. The collected data reflects the memory footprint, trade-offs, and performance of security profiles at different layers of network stack [2].

1.6 Ethics and sustainable development

The work of the thesis itself is not involved in social and ethical issues.

In the DTLS profile on ACE framework, the messages transferred between the entities are artificial messages created by us. They are not data from the real users. The DTLS profile on ACE framework can also prevent the users’ data from being attacked. However, if the result of this thesis is applied to the market, we should respect the privacy of users and give the informed consent for the customers. In this thesis, we also investigate the energy and memory consumption of different profiles. This provides a benchmark for choosing sustainable solutions for constrained devices.

(16)

1.7 Thesis Outline

The rest of the thesis is organized as follows. In Chapter 2, we provide the background knowledge needed for the rest of the thesis, including some light-weight profiles designed for constrained device, the ACE framework, and the secure profile implemented in the ACE framework. We also describe the interaction and communication steps to set up the secure DTLS channel. In Chapter 3, we present a prototype model, the model of DTLS profile on ACE framework. In Chapter 4, we give a detail description about the environment of the operating system and the libraries. The configuration and implementation of the libraries are also provided. In Chapter 5, we present the experimental results. The performance of the DTLS for ACE framework is evaluated and the experimental results are discussed in this Chapter. In Chap- ter 5, we present the discussion about our implementation of the work and the suggestion for future work. In Chapter 6, we make a conclusion of this thesis.

(17)

Chapter 2 Background

2.1 DTLS-Secured CoAP

CoAP is a specially designed transfer protocol for machine-to-machine (M2M) applications and constrained environments which usually are 8-bit microcontrollers with limited ROM, RAM and 6LoWPAN. CoAP provides an interaction model between application endpoints which is similar to the HyperText Transfer Protocol (HTTP) Client/Server model. CoAP assumes that Client is the request’s originating endpoint and the response’s destination endpoint while the server is a response’s originating endpoint and the request’s destination endpoint.

Figure 2.1 illustrates a basic CoAP model. The Client sends a confirmable request including 0xbc90 Message ID, payload of coap://

server/temperature and 0x71 Token. The Sever sends a 2.05 response in the Acknowledgement message that acknowledges the request, using the same Message ID and the same Token. As CoAP itself does not provide any secure protocol for authorization and authentication, we bind the communication secure profile like DTLS for CoAP. The CoAPs security modes are indicated by the "coaps" scheme and DTLS- secured CoAP default port [28].

8

(18)

CHAPTER 2. BACKGROUND 9

Figure 2.1: CoAP Confirmable GET Requests with Piggybacked Re- sponses Carried in Confirmable Messages [28]

Like Transport Layer Security (TLS) does for HTTP, it adds some features to set the DTLS for unreliable User Data Protocol (UDP) transport. In this thesis, we use the CoAP binding to DTLS to ensure security. DTLS enables the dynamic security DTLS channel between the Client and the Server with alternative session establishment modes of symmetric authentication with PSKs and asymmetric authentication with RPKs which prevents eavesdropping, tampering and message forgery effectively.

(19)

10 CHAPTER 2. BACKGROUND

Figure 2.2: Abstract Layering of DTLS-Secured CoAP [28]

The CoAP Client also acts as DTLS Client. The Client endpoint initiates the session to the server on the appropriate port. The Client could initiate request after the DTLS handshake finishing. For RPK and certificate mode, DTLS security channel should be set up with mutual authentication for future reuse of message exchanges in each direction [28]. And the system must support TLS_ECDHE_ECDSA- _WITH_AES_128_CCM_8. For PSK mode, the system must support TLS_PSK_WITH_AES_128_CCM_8 cipher suite.

2.2 DTLS Profile

DTLS realizes the TLS security layer on the UDP protocol. As the Se- cure Sockets Layer (SSL)/ TLS based on Transmission Control Protocol (TCP) cannot handle the characteristic of loss of package and reordering of the UDP messages. To make the most use of the TLS codes to solve the problem on how to realize the application of TLS in UDP, DTLS makes small changes in the foundations of the TLS. Compared with the TCP/TLS, DTLS is more lightweight and economic, which is widely applied to the embedded environment currently. In DTLS profile, all data are carried in records which can only be processed when the entire record is available. DTLS utilizes many techniques that make records safe for datagram transport from IPsec. DTLS also inherents the TLS programming model but IPsec has no standard Ap-

(20)

plication Programming Interface (API) or programming model. There- fore, it is difficult to program to the widely deployed IPsec implementation [18].

2.2.1 The Hierarchy of DTLS Profile

DTLS realizes the DTLS communication channel setup between the Client and Server based on the UDP socket. DTLS can be divided into two layers. The lower layer is the record layer and the record packet has a header part and a payload part. The payload of the record packet belongs to the content of the upper layer. The type of the packet can be divided into handshake message, alert message and application data.

Figure 2.3 shows the layout of the DTLS message in an IP/UDP datagram.

During the whole communication, the peers produce the upper layer payload first in the process of structuring the message and then add the header part which will form the complete upper layer message. They then use the completed message as the record layer payload and add the header of the record layer to form the integral text.

The Alert protocol is used for the error messages communication. The ChangeCipherSpec is used for subsequent messages protection.

The encryption process just applies to the payload of record layer(upper layer message). So after the receiver receives the message, it should analyze whether messages are encrypted by the sender or not. If they are encrypted, they should be decrypted first to read the data¹.

The IEEE 802.15.4 Maximum Transmission Unit (MTU) size is 127 bytes which includes IEEE 802.15.4 header 25 bytes, IEEE 802.15.4 security 21bytes, IPv6 header 40 bytes, UDP header 33 bytes and UDP payload 33 bytes.

1SEE https://blog.csdn.net/pengkunlun_hit/article/details/52177227

(21)

Figure 2.3: Layout of a secured DTLS packet profile[20]

2.2.2 DTLS Handshake Protocol

DTLS profile has two critical protocols. One is the Record Protocol for message exchange. The other one is Handshake protocol for session extablishment [1]. During the handshake, the protocol set the retrans- mission timers to deal with the message loss. The modified handshake header also prevents the message loss, reordering an message frag- mentation. Client sends the connection requirements to the server and the server can decide whether to verify the cookie and the certificate according to the configuration.

• Cookie Cookie = HMAC(Secret, Client-IP). As the DTLS are sus- ceptible to the two main types of Denial-of-Service (DoS) attack.

One is the amplifier attack and another is consuming excessive resources attack. In order to counter the attack, DTLS use the cookie to verify that the IP of the peers are authentic.

• Peers Peers identify candidates using information encoded in the DTLS cookie.

(22)

Every ClientHello Message contains the parameter of cookie and if the parameter is empty, it means that the communication peers do not set up the connection before. Then the sever will use the hash methodology to produce a cookie according to the client’s IP and send to the client in the HelloVerifyRequest message. Then the client attaches the received cookie in the second ClientHello message and server com- pares the received cookie with the sent cookie. If they are the same, the communication peers continue to set up the handshake connection. Otherwise, the communication peers will refuse to set up the connection. For successful session negotiation, handshake message even the ChangeCipherSpec message must be reliably delivered.

Figure 2.4: Message Exchange of Full Handshake. The blod represents optional packet and the user could set up sending or not sending.

(23)

2.3 ACE Framework

ACE framework is used for authorization of the IoT environment which consists of several building blocks. The basic building block is OAuth 2.0 framework which enables a third-party application to obtain the limited access to the restricted resources [12]. And another building block CoAP compensating the limit of the HTTP environment typi- cally run on UDP and further reduces the overhead and message exchange [24].The third building blocks is CBOR. CBOR is a data format designed for the extremely small code size and message size and ex- tend the use without version limit [5]. In this thesis, the CBOR is used for encoding the self-contained tokens and encoding transferred payload in protocol message. The fourth building block is the COSE and it is used for securing the self-contained tokens like PoP tokens and enables application layer security. The above four building blocks can basiclly satisfy the IoT device and network constraints.

• AS

Authorization is a process that is granted an approval to a system entity to access the resource. Authentication is a process that verifies a claim to a system entity and resource with certain attributes [29]. The task of the AS is to provide the access token and RS information to the requesting Client, which makes the Client have the access to the resource hosted by the RS.

• RS

Resource server is an entity that can grant access to a protected resource. RS which hosts protected resources can accept and respond to the protected resource request using access tokens [12].

• Client

Client refers to the application which requests the protected resource from the server.

2.3.1 Access Token and PoP tokens

The framework of Access Token recommends CBOR Web Token (CWT) [15]. AS issues the access token to the third party Client. The Client ac- cesses the the protected resources hosted by RS through the access token which is a string denoting access attributes. The token is CWT in-

(24)

formation object protected by CBOR and opaque to the Client. The security requirements of RS determine the formats, structures and methods of utilization of the tokens. The identity of the Client is deter- mined by the authentication process during the DTLS handshake. In the asymmetric case, the public key will define the Client’s identity, while in the PSK mode, the Client’s identity is defined by the session key generated by the authorization server for this communication.

PoP access token is the access token which is bound to a cryto- graphic key. The key can be used to Client’s authenticate requests by RS. The RS should verify the Client’s key matches the key bound to the tokens after receiving the tokens. For symmetric mode, the PoP key generated by the AS randomly is encrypted and sent to the Client with the access token. For asymmetric mode, Client generated the asymmetric pair and send the public key to the AS. The RS can identify the Client’s public key from the information in the token. And Client uses the corresponding private key for the proof of possession.

(25)

Chapter 3 DTLS on ACE Framework

This Chapter illustrates a basic protocol flow about how the Client, RS and AS interchange the related data. According to different communi- cating endpoints and for the convenience of the coding, We divide the profile of the ACE framework relying on DTLS into three steps: unauthorized Client to RS, retrieve an access token and common protocol flow for the DTLS profile.

3.1 Step1: Unauthorized Client to RS

Figure 3.1: Unauthorized Client to RS

The process in Figure 3.1 is OPTIONAL in the ACE framework. In this step, the Client sends the resource request directly to the RS. As the request is unauthorized, resource server denies the request and sends back the AS necessary information back to the Client like the address

16

(26)

CHAPTER 3. DTLS ON ACE FRAMEWORK 17

of the AS to contact the AS and ask the access token for authorization to the RS.

3.2 Step2: Retrieve an Access Token

Figure 3.2: Retrieve an Access Token

Once the Client has received the basic information about the AS e.g., the address of the AS, it can request the access token to the AS. In this thesis, we assume that the Client and the AS has set up the mutual authentication and it is out of scope of this thesis. The Client should have registered at the AS and have configured the public key of the AS [24]. The AS authenticates Client identities and validates the authorization grant. If the authorization grant is valid, the AS will issue the corresponding access token. The mutual communication between the Client and the AS should be confidentiality protected and ensure authenticity as it may contain confidential data.

3.2.1 Client Token Request in PSK mode

The more generic situation is described in the section 2.3.1 Access To- ken and PoP tokens. The following situation is another specific situation. Before Client sends the Token request and symmetric PoP keys, the Client and AS should set the secure DTLS channel for authentication, message integrity and confidentiality. The Client adds cnf object

(27)

18 CHAPTER 3. DTLS ON ACE FRAMEWORK

with an identifier for symmetric key in access token request. AS uses the identifier to determine the session key to construct the PoP token.

The session key is the symmetric key generated by the AS previously specified for the identity of Client which is used for the communication between Client and RS.

3.2.2 AS’s Response with the Access Token in PSK Mode

The AS adds the access information to the response according to the requested parameters in the Client request, which provides the sufficient information for the Client to set up the DTLS channel with the RS.

DTLS

Header: Created (Code=2.01) Content-Format: application/cbor

Payload:{

access token: h’d08343a10...

(remainder of Access Token omitted for brevity)

profile: coap_dtls

expires_in 86400

token_type: pop

cnf: { COSE_Key: {

kty: symmetric

k: h’73657373696f6e6b6579’

alg: HS256

}

Table 3.1:Example of Access Token Response with a symmetric key as a PoP key

• Content-Format It is assumed that the CBOR payload is used in transport layer communication. If the COSE is included, it is assumed that the object security is based on COSE.

• Access Token Access token is credential to access the protected resources and includes many parameters like cnf, key.

• profile The parameters defines network security protocol is used in the communication.

(28)

• expires_in It is represents the lifetime of the access token in sec- onds. The value "3600" denotes that the access token will be valid in one hour from the response was generated.

• token_type The Client just uses the access token when it under- stands the access token. The Client can utilize the access token to make a protected resource request (with type-specific attributes) with the access token type information [12]. As the CBOR encoding is used, the value of the token_type must be CBOR text strings. An identical request and response parameter is defined for the token endpoint to allow requesting and stating confirma- tion keys which aims at making token theft harder [24].

• cnf The PoP framework uses the PoP tokens, using the cnf (con- firmation) claim which contains the parameters used to identity the PoP key.

• COSE_Key COSE_Key contains the symmetric session key to be used between RS and the Client.

• kty The parameter refers to the identification of the key type. The symmetric type value is 4 [26].

• k The k refers the PSK.

• kid The KEY ID can identify the PoP key instead the actual key and the recipient can obtain the identified key using the KEY ID [26].

• alg The alg defines the key algorithm using restriction. For DTLS of symmetric key, it defines the PSK exchange algorithm and as- sociated ciphersuites [30].

(29)

3.2.3 Client Token Request in RPK Mode

DTLS

Uri_Path: token

Header: POST (Code=0.02)

Content-Format: application/cbor

grant_type: client_credentials

aud: RS

client_id: myclient

client_secret: qwerty

req_cnf: { COSE_Key: {

kid: b64’c29tZSBwdWJsaWMga2V5IGlk’

kty: EC2

crv: P-256

x: b64’f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU’

y: b64’x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0’

} } }

Table 3.2: Example of Request Payload for RPK Mode

• grant_type The resource owner’s authorization used by the Client to obtain the access token. If the type is Client Credential, it represents that the Client request the access to RS based on the authorization from the AS previously.

• aud Audience is a parameter that the Client request the token for like RS.

• client_id The AS issues a client id to the registered Client[12].

The Client Id is a unique string to the AS and represents the Client registration information. It is used for the authorization request and token request and is public.

• client_secret The client_secret is a private parameter which is only known to the AS and application¹. If the parameter is empty, the Client can omit it.

1https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/

(30)

DTLS

Header: 2.05 Content

Payload:{

access_token: b64’SlAV32hkKG ...’

(remainder of CWT omitted for brevity)

token_type: PoP

profile: CoAP_DTLS

rs_cnf: { COSE_Key: {

kid : b64’c29tZSBwdWJsaWMga2V5IGlk’

kty: EC2

k: b64’hJtXhkV8FJG+Onbc6mxCcQh’

crv : P-256

x: b64’MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4’

y: b64’4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM’

} } }

Table 3.3: Example of AS Access Token Response for RPK Mode The Client generates the private and public key pair before the communication. If we want to build the RPK mode, the Client request should include either the raw public key of Client or the unique identifier like Client ID and Client Secret of Client public key which is al- ready known to the AS.

3.2.4 AS Response with the Access Token in RPK Mode

• RS_cnf The parameter of the rs_cnf provides the RPK key for the RS.

• crv It represents the identifier of the curve for the key [21].

• x It represents the x-coordinate for the Elliptic Curve (EC) point.

• y It represents either the y-coordinate for the EC point or the sign bit.

• Crv, x and y represent the public key.

(31)

aud: RS

exp: 1360289224

cnf: { COSE_Key: {

kid: b64’1Bg8vub9tLe1gHMzV76e8’

kty: EC2

crv: P-256

} }

Table 3.4: The Content of Access Token in AS response in RPK Mode

• For EC with both coordinates, the parameter of kty could be set to EC2 [21].

The content of the access token specified in table 3.3 is shown in table 3.4. The response of the AS can be divided into PoP access token and access information. The access information includes the RS’s public key and the access token include the Client’s public key [24]. The Client and RS use the RPK to ensure the communication security.

(32)

3.3 Step3: Common Protocol flow for the DTLS Profile

Figure 3.3: Client provides the access token to RS

After receiving an Access Token and access information, Client checks the payload of Access Information. With sufficient information, the Client can start to establish the new secure DTLS channel with the RS.

The Client sends the POST plain CoAP request with access token to the RS at the authz-info endpoint. Then, the Client starts to run the handshake. If the RS verifies access token from the valid AS, the RS and the Client will finish the handshake using their respective key material.

After running the DTLS handshake successfully, the Client could send the GET coap request to the RS based on established secure channel, then the RS should respond with the resource over the channel.

3.3.1 Client request to the RS with the Access Token in PSK Mode

In PSK mode, Client uses the cnf parameters included in AS response as PSK key and PSK exchange algorithm to construct the premaster se-

(33)

cret [11]. Before starting the handshake, Client should send the Access Token to RS authz-info endpoint.RS uses the cnf parameter information in the Access Token to determine the actual session key.

3.3.2 Client request to the RS with the Access Token in RPK Mode

DTLS

Header: POST (Code=0.02)

Uri-path: "authz-info"

Payload:{

grant_type: { Client_Credentials cnf: {

COSE_Key: {

kid: b64’c29tZSBwdWJsaWMga2V5IGlk’

kty: EC2

crv: P-256

} } }

Table 3.5: Example of Access Token provisioning to RS for RPK Mode The RS and the Client starts the handshake with the raw public keys established in step 1 and step 2. The public key should be the same as the one used to construct Access Token with SubjectPublicInfo structure in the DTLS handshake.

• cnf The object should include the Client’s unique identifier or raw public key for the public key which has been known by the AS [11].

(34)

Chapter 4 Implementation

In this chapter, we illustrate details of how to set the configuration and describe important commands of executing operations. The most important library is presented and also gives the method about how to implement it in the environment and the modification that we have made. The algorithms of the encryption and authentication, the Zol- ertia Firefly specification and the development platform which is used to test the code are also presented. In the next chapter, the evaluation scenario of the implementation and the benchmark results will be presented.

4.1 Contiki-NG

Contiki is an open source operating system which was created by Adam Dunkels in 2002 for Internet of Things¹. Contiki is also a Wireless Sen- sor Networks (WSN) platform for constrained devices based on event- driven kernel and implements protothreads using C syntax which reduced software complexity [10]. Contiki also implements the built- in and multitasking Internet Protocol Suite (TCP/IP stack) including IPv6, for memory-constrained device with less than 10k RAM and 30k ROM. Contiki also provides the radio duty cycling mechanism Con- tikiMAC for highly power efficient operation [9].

Contiki-NG inherits some features of Contiki and develops as a new fork of it. Contiki-NG is also an open-source operating system for IoT device of next generation². It mainly works as a cross -plantform

1SEE http://www.contiki-os.org/

2SEE https://github.com/Contiki-NG/Contiki-NG

25

(35)

26 CHAPTER 4. IMPLEMENTATION

system for constrained communication and protocols, like CoAP which uses in this thesis and other popular Internet protocols like IPv6, 6LoW- PAN and RPL.

The set up of the Contiki-NG system is in the wiki of the Contiki- NG in the documentation of setting up Contiki-NG³. We use the method of installing native toolchain in Linux to set up the environment.

4.1.1 CoAP and CoAPs for Contiki-NG

In Contiki, the Erbium CoAP library is used. CoAP leverages the ContikiMAC low-power duty cycling mechanism to provide power- efficient operation at the application layer [16]. CoAP implementation is based on the low-power Representational State Transfer (REST) En- gine Erbium which includes a comprehensive embedded CoAP implementation. The engine also provides convenient API for devel- opers to handle rest resources [14]. For the proof-of-concept of ACE framework, we use this API to define required endpoints, like /authz- info and /token. For Contiki-NG, the CoAP in Contiki-NG has been refactored based on the Erbium implementation. The default transport of CoAP implementation is micro IP (UIP). The secure version of the CoAP integrate the DTLS profile and is called CoAPs.

• Build the CoAP application Add the sentence in the Makefile which used for including the CoAP library.

#Include the CoAP implementation MODULES += os/net/app-layer/coap

• Provide the resources of CoAP Provide the resource code un- der the coap/resources file and activate the resources with coap- _active_resource in the process.

4.1.2 Tinydtls for Contiki-NG

The tinydtls library has been intergrated into the CoAP library. It has the basic support for the PSK mode of the DTLS. The structures and the function of the library can help construct the single-threaded UDP server with DTLS library.

3SEE https://github.com/Contiki-NG/Contiki-NG/wiki

(36)

CHAPTER 4. IMPLEMENTATION 27

The step of using DTLS

• Make some changes in project-conf.h for both client (Client) and the server Add the definition of the DTLS PSK key(the PSK of the Client and server should be same):

#define COAP_DTLS_PSK_DEFAULT_IDENTITY "Client_identity"

#define COAP_DTLS_PSK_DEFAULT_KEY "secretPSK"

• Make some changes of the address The CoAP format of the ad- dress is "coap://[fe80::XXXX:XXXX:XXXX:XXXX]", while the CoAPs format of the address should be changed to

"coaps://[fe80::XXXX:XXXX:XXXX:XXXX]".

• Build the example First, we should do the distclean.

$ make distclean

Then, we should build the project. We use the MAKE_WITH_DTLS to invoke the DTLS and the DTLS has three format of the key-

store:make_coap_dtls_keystore_none, make_coap_dtls_keystore_simple, make_coap_dtls_keystore_lwm2m.

$ make TARGET=zoul BOARD=firefly-reva MAKE_WITH_DTLS=1 MAKE_COAP_DTLS_KEYSTORE=

MAKE_COAP_DTLS_KEYSTORE_SIMPLE example-xxxx.upload

• Initialize DAG root in the server part If you want to use the mode in the board rather than the native mode, you should add the following code in the server part for the communication between the Client and the server.

NETSTACK_ROUTING.root_start();

• Solve the problem of overflow in the Zolertia Firefly platforms When we use the configuration of the DTLS profile and want to directly download it into the board, it always fails. We always get the error message like the following:

/usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ld:

coap-example-client.elf section ‘.bss’ will not fit in region ‘FRSRAM’

/usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ld:

region ‘FRSRAM’ overflowed by 6440 bytes collect2: error: ld re- turned 1 exit status

../../arch/cpu/arm/cortex-m/cm3/Makefile.cm3:27: recipe for tar- get ’coap-example-client.elf’ failed

We should use the command:

(37)

28 CHAPTER 4. IMPLEMENTATION

#define LPM_CONF_MAX_PM 1.

The command set the maximum pm to 1 and the system on chip (SoC) will never drop to the power mode deeper than PM1⁴.

4.1.3 CBOR and COSE for Contiki-NG

We use the extended library of CBOR and COSE which is based on the RISE SICS version to handle access token in the ACE framework with its corresponding objects and parameters including the DTLS structure and supports efficient complex structure encoding. As the library is imported from the CONTIKI-3.0 version, we modify the library to make it run successfully in the Contiki-NG. So the library of CBOR is a basic cbor library after importing from the CONTIKI-3.0 version.

4.1.4 ENERGEST Module

In this thesis, we use the Energest module to track the time that various hardware components are turned on and off. We could get the data of the power consumption of the components and then with these data, we could estimate the energy consumption. We use the function mainly to estimate the ticks that the Central Processing Unit (CPU) is active, sleeping and deep sleeping and also the radio is off, listening and transmitting. But the ENERGEST Library is based on the Contiki- NG timer library, no matter the Rtimer Library or the Contiki-NG system clock library.

4.2 The ZOLERTIA FIREFLY PLANTFROM

The Firefly is an out-of-the-box Zoul implementation board which is based in the CC2538 Advanced RISC Machine (ARM) Cortex-M3 SoC with 512KB flash and 32KB RAM. The board supports 6LoWPAN and IEEE 802.15.4 protocol very well and the on-board hardware also in- crease the security(SHA2, AES-128/256, ECC-128/256 and RSA for secure key exchange). ⁵

4SEE: https://Contiki-NG.readthedocs.io/en/latest/_api/group__cc2538.html

#ga3ea1f4389b9ca7e2b4deeb0a6fe227aa

5SEE https://github.com/Zolertia/Resources/wiki/Firefly

(38)

Chapter 5 Protocol Evaluation

In the chapter, we illustrate the evaluation of the key setup of the secure DTLS channel in ACE framework which is also described in the chapter of implementation. We describe the measured scenario, the security analysis of this design model, the evaluation of the performance and our implementation result discussion.

5.1 Scenario Description

The scenarios refer to some abstract use case of the ACE framework where the Client asks the access of the protected resource which owns by the RS in constrained conditions. We assume the Client, RS and AS are resource-constrained devices while the AS should have less constraint in computation and network resources actually as the AS should delegate the authentication and authorization of the request. In our experiment, the AS and RS should initialize the the Direct Acyclic Graph (DAG) root and make the operation of the Routing Protocol for RPL.

• (A) The Client sends the request to the AS to obtain the access token.

• (B) After AS verifies the Access Token Request, the AS sends the Access Token and the RS information to the Client.

• (C) The Client analyzes the Access Information in which is called RS information in the old version and sends the access token to the RS

29

(39)

30 CHAPTER 5. PROTOCOL EVALUATION

• (D) If the operation of posting an access token has a positive re- sponse, the Client could initiate the DTLS handshake and build the secure channel with the RS

• (E) After the secure DTLS channel is established successfully, the Client is authorized the request the resource from the RS.

• (F) After verifying the request received in this channel, the RS could send the requested protected resource to the Client.

5.1.1 Protocol Limitations

The limits of the features of IoT scenarios and the ACE framework design are shown as follows:

• As the AS plays the role of the fully-trusted third-part, the endpoint could potentially learn some sensitive message that the Clients request access tokens even the Client public key and the information about the requested resources. Even with the credentials grant, the AS can track the Client.

• If we want to obtain more performance benefits of Client and RS, the AS could make the lifetime of the access token and the proof- of-possession key size short which will cause the message size short.

• If the interacting parties suffer from the direct physical attacks, e.g., the device clone and the tampering role outside the scope of the adversary model, the ACE framework could not find the way to deal with it. Moreover, the security guarantees of the ACE framework and the DTLS profile could be break.

• In the ACE framework, the RS could get the access token from the Client. So, the RS could impersonate the Client to communi- cate with the RS in the audience.

• If the CWT has not been encrypted, it could leak the information during the process of the transmission.

(40)

CHAPTER 5. PROTOCOL EVALUATION 31

5.2 Performance Evaluation and Benchmark Discussion

In the section, we provide the results of the performance evaluation of our implementation of the DTLS profile in the proof-of-concept in the ACE framework. The building blocks defined in the former chapter are used in the Contiki-NG running on the Zolertia Firefly platform.

For the convenience, we use the same method in the published paper [4] to evaluate the scenario which is described in the former section in a constrained environment and also the Client, AS and RS performance.

We just evaluate the one DTLS channel establishment method: PSK mode and also the pure ACE framework without any profile imple- menting in the ACE framework. This baseline ACE framework does not have the secure channel between the Client and AS and also the secure channel between the Client and the RS, and no information about DTLS is included in any messages. In Table 5.1, we list the evaluated setup configurations, the secure channel establishment method and the security mode of the protocol.

Security Protocol

Secure channel establishment Method

DTLS PSK

I × × ACE framework without DTLS profile

II X X PSK mode in ACE framework

Table 5.1: Evaluated setup configurations

• Network Latency and Processing Time In the implementation, we choose the rtimer library instead of the standard system clock as the rtimer supports the real-time task scheduling and safe from interrupt in the Contiki-NG system. The measurement (1) and (3) include the network latency as round-trip time. Every time before we want to measure total time, we call the energy_flush to make sure that the total time has been updated. The configuration of the ENERGEST module by default should use the Rtimer library. We want to covert it into the seconds, so use the parameter ENERGEST_SECOND which is the number of the ticks per second from the Energest time source. Applying the following formula¹:

1SEE: https://github.com/Contiki-NG/Contiki-NG/wiki/Tutorial:-Energy- monitoring

(41)

time = energest_type_time EN ERGEST_SECON D

• Energy consumption We use the ENERGEST library to measure the energy consumption. The ENERGEST is just a module which can track the state that the components are turned on or off. We should caculate the energy consumption use the following formula:

We mainly divide the energest consumption into four parts: (1) Tx is the number of ticks that the radio has been in transmission mode which use the ENERGEST_TYPE_TRANSMIT function. Rx is the number of the ticks that the radio has been in reception mode which use the ENERGEST_TYPE_LISTEN function. CPU is the number of the ticks that the system spent on processing data which use the ENERGEST_TYPE_CPU². We check all the reference data in the datasheet of the Zolertia Firefly Board Datasheet³ and also the CC2538 datasheet⁴.

ticksT x = energest_type_time(EN ERGEST _T Y P E_T RAN SM IT ) time_{T x} = ticks_{T x}/EN ERGEST_SECON D

Energy = time_tx× V oltage_{T x}× Current_{T x}

ticksRx= energest_type_time(EN ERGEST _T Y P E_LIST EN ) time_Rx= ticks_Rx/EN ERGEST_SECON D

Energy = time_Rx× V oltage_Rx× Current_Rx

tickscpu = energest_type_time(EN ERGEST _T Y P E_CP U ) time_cpu = ticks_cpu/EN ERGEST_SECON D

Energy = time_cpu× V oltage_cpu× Current_cpu

We could print the ENERGEST_SECOND in the system and then get the number of the ticks of 1 second. ENERGEST_SECOND value equals to 32768 in my test.

2) Energy where you are still able to use Energest.

3) Time intervals, by using simple local timers. For instance you

2SEE: https://stackoverflow.com/questions/45644277/how-to-calculate-total- energy-consumption-using-cooja

3SEE: https://github.com/Zolertia/Resources/blob/master/Firefly/Hardware /Revision%20A/Datasheets/ZOL-BO001-A2%20-%20Firefly%20revision%20A%20 Datasheet%20v.1.0.0.pdf

4SEE: http://www.ti.com/lit/ds/symlink/cc2538.pdf

(42)

• (0)Token Decoding

• (1)The DTLS secure channel setup and Client to AS Exchange

• (2)Token Encoding

• (3)Client to RS Exchange including the secure channel setup

• (4)Token Setup

• (5)DTLS Secure channel setup

• (6)The overall process

Figure 5.1: The evaluation of the setup

can measure: we choose the same time period with the published paper " as [4].

• (0) The mark 0 represents the time period that the Client decodes the access information, which we call it "Token decoding".

(43)

• (1) The mark 1 represents the time from when Client initializes the DTLS channel setup and then sends the Access Token Re- quest to AS until when it has received the Access Token Response, which we call it "Client to AS exchange".

• (2) The mark 2 represents the time period that the AS encodes the access token and the access information, which we call it "Token encoding".

• (3)The mark 3 represents the overall high-level time from when Client sends the Access Token and resource request to RS until when Client has received the CoAP response from RS, which we call it "Client to RS exchange".

• (4)The mark 4 represents the time from when Client receives the Access Token Response from the AS until when it has finished processing it, which we call it "Token setup".

• (5) The mark 5 represents the time from when C starts the DTLS handshake by sending the ClientHello to RS, until when it has completed it, which we call it "Token setup".

• (6) The mark 6 represents the total time of the whole process from when the Client initializes the DTLS handshake, until the Client gets the resource from the RS.

Due to the limitations of the measurement, we just could realize the measure of the process running in the application. So, we just present the step(1), (3), (5) and (6).

5.2.1 Time and Energy Evaluation and Discussion

All of our evaluation is based on the role of the Client.

(44)

Figure 5.2: (1)The Client’s time evaluation of the secure channel setup and Client to AS results

Figure 5.3: (1)The Client’s energy evaluation of the secure channel setup and Client to AS results

(45)

Figure 5.4: (3)The Client’s time evaluation of Client to RS results

Figure 5.5: (3)The energy evaluation of Client to RS results To reduce the error and get more exact data, we run the model 20 times for DTLS PSK configuration and the standard deviation (SD). We can see the total time including network latency and processing time, and energy consumption that Client to AS consumes. In the measurement (1), the comparable performance regarding DTLS secure channel setup method PSK mode and the behaviour of access token request and response is consistent cross the PSK setup configuration. In the measurement (3), the total time and energy consumed to finish the communication between the Client and the RS in PSK mode. As the

(46)

measurement (1)(3) both build the secure DTLS channel during the process.

Figure 5.6: (5)The Client’s time evaluation of setup of the DTLS secure channel

Figure 5.7: (5)The Client’s energy evaluation of setup of the DTLS secure channel

In Figure 5.6 and Figure 5.7 , we present the result of the secure channel setup evaluation between RS and Client with the configuration PSK mode. The RX energy consumption is remarkably big com- pare with other two parameters. We measure these parameters in a

(47)

noisy testing environment and the recurrent RPL messages sent by different endpoints have the effect on our measurement and the results by adding noise.

Figure 5.8: (6)The Client’s time evaluation of the total process

Figure 5.9: (6)The Client’s energy evaluation of the total process In Figure 5.8 and Figure 5.9 , we present the result of total time and the total energy consumption of the process. The value of the total process is equal to the summary of the measure of the (1) and (3). The black line in each bar stands for SD of every parameter. We collect the 20 group data for each parameter in different situation. The noisy in

(48)

the environment, the delay of the network and the temperature of the environment and so many other reasons will lead to the error of the results. It is unavoidable and it is in certain reasonable range.

5.2.2 The Evaluation and Discussion of Memory Foot- print

We use the following command to measure the memory⁵. size <binary file name>.elf.

• We measure the RAM using the bss and data.

RAM = data + bss

• We measure the ROM using the text and data.

ROM = data + text

• The bss represents the uninitialized variables storage, data represents the initialized variable area and the text represents the code and constants.

Figure 5.10: The Comparison of the Memory Footprint

5SEE: https://linux.die.net/man/1/size

(49)

In Figure 5.10, we present the comparison of the Memory Footprint evaluation results for the different secure channel setup of DTLS profile. We just measure the memory footprint once as it is completely deterministic and will not change like time and energy every time. We present the ROM and RAM footprint absolute value for the setup configuration of the baseline and the DTLS PSK mode. As is shown in Figure 5.10, the DTLS PSK mode have bigger memory footprint, as more resource material are required.

5.3 Chapter Summary

In the first part of this chapter, we describe the implementation scenario. We use described setups and metrics benchmark and the protocol limitations of our implementation model. We measure one secure channel establishment method which contains the memory-footprint, energy consumption, network latency and processing time. Due to the limitations of the DTLS library, we just measure the PSK mode. There are still many improvements and future work needed to be discussed.

We cover this point in next chapter and also summarize the work in general and comment on our work.

(50)

Chapter 6 Conclusion

In this master thesis, we analyze the key role participating in the authorization and authentication in IoT. We use these two assurances in the complicated environment to address security concerns.

We build our model based on the basic ACE framework and extended it following the IETF draft. The constrained server can authenticate and authorize the delegated Client in the ACE framework. The framework reduces the limitations in processing power and footprint and adds the interoperability from the regular Internet to secure IoT.

The DTLS profile supports two different flexible secure channel setup methods which can be applied to different IoT user cases in different environments. For these two methods, we implement the COSE profile in our model to create the key cryptographic material specification. The design of the DTLS profile for ACE framework can be found in [11]. It includes the symmetric key authentication which uses PSK mode and asymmetric key authentication which uses RPK mode. We provide a model that implements the DTLS profile of the PSK mode in Contiki-NG OS of IoT.

We test our implementation in the Zolertia Firefly Board which is a constrained environment with 512KB flash and 32KB RAM with 32MHZ and integrated IEEE 802.15.4 radio capabilities. We provide some extended library serving for our model. Our model is based on the model of ACE framework in constrained platforms. We evaluate the PSK mode of the DTLS profile in operation time, energy consumption and the memory footprint of the ROM and RAM.

In conclusion, the token-based DTLS secure channel setup methods can authenticate and authorize in a constrained environment. The

41

(51)

42 CHAPTER 6. CONCLUSION

framework can guarantee the transport layer security of the IoT. As a result, the deployments of the IoT could access the protected resources with authorization and authentication through the secure channel.

(52)

Chapter 7 Discussion and Future Work

In this chapter, we make a reflection on the efficiency of our work and discuss the limitation of our work and we also give the suggestions about the future work which could be continued based on our work.

7.1 A Note on Efficiency

The work of this master thesis is the first attempt to implement the DTLS profile in ACE frame work and test it in the constrained device especially Zolertia Firefly Board which supports the Contiki-NG system well. The implementation of the protocol is still at the level of proof-of-concept, so the implementation have much room to enhance.

We further make some changes based on the Santiago’s work in the CBOR and COSE library to make the parameter values and the names cast to the numerical values more accurate and concise.

By inheriting this method of the former master students’ idea, the size of the ACE packet has been reduced significantly. To further reduce the memory footprint evaluation, we discard almost all unnecessary print operation. The embedded keys in the token request message and the access token messages should be handled and process by cryptographic material which will parse the memory-efficient libraries. As a result, the evaluation of the memory footprint will be changed due to the enhancement.

Finally, due to the change from CONTIKI-3.0 to Contiki-NG, we could not maintain all the features of the ACE framework that the former student built. We could not find any features and libraries of hardware-based accelerations for the cryptographic opearation and

43

(53)

44 CHAPTER 7. DISCUSSION AND FUTURE WORK

due to the change of the contents of the systems. We also omit and optimize the function of the CBOR library. It is still unknown that whether it will cause some changes in the results.

7.2 The Challenge in the Thesis Work

• Fixing download problem when running the DTLS library The first problem we meet when building the DTLS library in the communication is that we could not successfully download the example to the ZOL board as it always says that the file is too big. Thanks to the Niclas Finne help, we solve the problem and know the reason of the problem.

#define LPM_CONF_MAX_PM 1

We could disable the unnecessary components to save the memory.

• Fixing the bug of the tinydtls library First, we have success- fully build the CoAP protocol example based on the Contiki-NG CoAP example. And then, we invoke the tinydtls library based on the successful CoAP example but it always fails when verifying the correctness of the key. It cost some time to successfully build the DTLS example.

7.3 Performance Evaluation Discussion

The experiment environment of the time and energy evaluation is not comparatively standard. We present it in the section of time and energy measurement. We make the experiment in the work area with some noise which is more like in the real practical application scene, for benchmarking purposes leading to a suboptimal evaluatuion with high variability in the results. We try to minimize the added noise like benchmarking in the least loaded channel. Despite the effort the noise was not able to be completely avoided. In the experiment, we assume that the AS is the constrained device like RS and Client and all of them run in the constrained environment. In fact, we should set up the AS as a non-constrained device which can access the Client and RS by In- ternet. In case that the distance of three roles have a bad effect, we make the boards become as close as possible.

Building Datagram Transport Layer Security (DTLS)-based access control in the Internet-of-Things

Building Datagram Transport Layer Security (DTLS)-based access control in the Internet-of- Things

CHENXI FENG

Building Datagram Transport Layer Security (DTLS)-based access control in the

Internet-of-Things

FENG CHENXI

Abstract

Sammanfattning

Acknowledgements

Contents

Chapter 1 Introduction

1.1 Related Work

1.2 Motivation and Objectives

1.3 Problem Statement

1.4 Scope

1.5 Research Methodology

1.6 Ethics and sustainable development

1.7 Thesis Outline

Chapter 2 Background

2.1 DTLS-Secured CoAP

2.2 DTLS Profile

2.2.1 The Hierarchy of DTLS Profile

2.2.2 DTLS Handshake Protocol

2.3 ACE Framework

2.3.1 Access Token and PoP tokens

Chapter 3

DTLS on ACE Framework

3.1 Step1: Unauthorized Client to RS

3.2 Step2: Retrieve an Access Token

3.2.1 Client Token Request in PSK mode

3.2.2 AS’s Response with the Access Token in PSK Mode

3.2.3 Client Token Request in RPK Mode

3.2.4 AS Response with the Access Token in RPK Mode

3.3 Step3: Common Protocol flow for the DTLS Profile

3.3.1 Client request to the RS with the Access Token in PSK Mode

3.3.2 Client request to the RS with the Access Token in RPK Mode

Chapter 4

Implementation

4.1 Contiki-NG

4.1.1 CoAP and CoAPs for Contiki-NG

4.1.2 Tinydtls for Contiki-NG

4.1.3 CBOR and COSE for Contiki-NG

4.1.4 ENERGEST Module

4.2 The ZOLERTIA FIREFLY PLANTFROM

Chapter 5

Protocol Evaluation

5.1 Scenario Description

5.1.1 Protocol Limitations

5.2 Performance Evaluation and Benchmark Discussion

5.2.1 Time and Energy Evaluation and Discussion

5.2.2 The Evaluation and Discussion of Memory Foot- print

5.3 Chapter Summary

Chapter 6 Conclusion

Chapter 7

Discussion and Future Work

7.1 A Note on Efficiency

7.2 The Challenge in the Thesis Work

7.3 Performance Evaluation Discussion