IoT-CryptoDiet: Implementing a Lightweight Cryptographic Library

based on ECDH and ECDSA for the Development of Secure and

Privacy-preserving Protocols in Contiki-NG

Eugene Frimpong

and Antonis Michalas

Tampere University, Tampere, Finland

Keywords:

Contiki-NG, Elliptic Curve Cryptography, Key Distribution, Privacy, Wireless Sensor Networks.

Abstract:

Even though the idea of transforming basic objects to smart objects with the aid sensors is not new, it is only

now that we have started seeing the incredible impact of this digital transformation in our societies. There is

no doubt that the Internet of Things (IoT) has the power to change our world and drive us to a complete social

evolution. This is something that has been well understood by the research and industrial communities that

have been investing signiﬁcant resources in the ﬁeld of IoT. In business and industry, there are thousands of IoT

use cases and real-life IoT deployments across a variety of sectors (e.g. industry 4.0 and smart factories, smart

cities, etc.). However, due to the vastly resource-constrained nature of the devices used in IoT, implementing

secure and privacy-preserving services, using, for example, standard asymmetric cryptographic algorithms,

has been a real challenge. The majority of IoT devices on the market currently employ the use of various

forms of symmetric cryptography such as key pre-distribution. The overall efﬁciency of such implementations

correlates directly to the size of the IoT environment and the deployment method. In this paper, we implement

a lightweight cryptographic library that can be used to secure communication protocols between multiple

communicating nodes without the need for external trusted entities or a server. Our work focuses on extending

the functionalities of the User Datagram Protocol (UDP) broadcast application on the Contiki-NG Operating

System (OS) platform.

1 INTRODUCTION

The Internet of Things (IoT) encompasses the inter-

connection of small smart devices connected to the

Internet. In recent years, there has been a huge

surge in the adaptation of IoT technologies in ev-

eryday lives. The technology has been adopted by

huge corporations, small businesses, and individu-

als alike. One aspect of the IoT which continues

to receive a lot of attention is the area of Wire-

less Sensor Networks (WSN). WSNs are networks

that comprise of vastly resource constrained battery-

powered devices. These devices are deployed in vari-

ous environments to register the occurrence of differ-

ent environmental or targeted events, collect data on

said events, and exchange the collected data between

themselves and other digital components with little to

no human intervention. Typical applications of WSNs

can include disaster monitoring, asset monitoring, re-

https://orcid.org/0000-0002-4924-5258

https://orcid.org/0000-0002-0189-3520

mote sensing, habitat monitoring and military deploy-

ment (Liang et al., 2007).

As with any technology associated with data

collection, storage and transmission, there exists a

plethora of security and privacy threats that needs to

be considered during the deployment of such a net-

work. Design and development of secure and privacy-

preserving protocols for WSNs is a topic that attracts

extensive attention from both the academia and the in-

dustry (Schmidt et al., 2018). Asymmetric key cryp-

tography has become the standard for key exchange

and mutual authentication when working on the Inter-

net and is considered a viable option for WSN de-

vices. However, due to the resource constraints of

these devices, it is often challenging to implement

core public key cryptographic functions as these func-

tions are computationally expensive (Piedra et al.,

2013). Currently, the majority of key management

implementations on WSN devices are based on pre-

shared symmetric keys. The security keys in such im-

plementations are pre-installed on the devices before

deployment. This solution is not scalable for deploy-

Frimpong, E. and Michalas, A.

IoT-CryptoDiet: Implementing a Lightweight Cryptographic Library based on ECDH and ECDSA for the Development of Secure and Privacy-preserving Protocols in Contiki-NG.

DOI: 10.5220/0009405401010111

In Proceedings of the 5th International Conference on Internet of Things, Big Data and Security (IoTBDS 2020), pages 101-111

ISBN: 978-989-758-426-8

101

ments that involve tens of millions of devices. For

example, pre-installing 10,000 128-bit AES keys on

a device takes 160KB memory and also poses signiﬁ-

cant look-up latency. Additionally, the de-centralized

ad-hoc nature of WSNs present signiﬁcant limitations

to implementing traditional security solutions. In a

decentralized ad-hoc network setup, the individual

nodes do not have ﬁxed positions before deployment

and also do not possess knowledge of neighbouring

nodes.

In this work, we present a lightweight secure

node-to-node key exchange communication protocol

implementation based on the Elliptic Curve Difﬁe-

Hellman (ECDH) and Elliptic Curve Digital Signa-

ture Algorithm (ECDSA) (Strangio, 2005) on re-

source constrained devices. We extend the capabil-

ities of the Contiki-NG UDP (Contiki-Ng, 2019b)

broadcast application with a reﬁned implementa-

tion of the ECC component of the Tinycrypt li-

brary (Wood, 2019). We do this in such a way that

will enable developers and researchers to easily build

and implement security and privacy-preserving proto-

cols by using our library as a baseline. As part of this

work, we evaluate the performance of our library by

running a toy protocol on the Zolertia Re-Mote board

and the Zolertia Orion Ethernet IP64 router. Our work

focuses on the communication between the individual

WSN devices.

Our Contribution. The main contribution of this

work is threefold. We ﬁrst implement a lightweight

secure node-to-node key exchange communication

protocol based on the Tinycrypt (Wood, 2019) imple-

mentation of the ECDH and ECDSA algorithms. Our

construction was implemented and extensively tested

on the Zolertia IoT boards. Our work also extends the

Contiki-NG UDP communication application to sup-

port and facilitate the proposed implementation. This

work was designed and developed in such a way that it

can be easily adapted by different IoT operating sys-

tems and implemented on various brands of IoT de-

vices. Hence, allowing others to build even better and

more efﬁcient secure and privacy-preserving IoT pro-

tocols.

Organization. The rest of this paper is organized as

follows. In section 2, we present existing works that

relate to privacy preserving solutions and cryptogra-

phy in resource constrained devices. In section 3, we

formally deﬁne our system model. A description of

the cryptographic primitives used for our work and

the threat model are presented in section 4. In sec-

tion 5, we give a brief overview of current security im-

plementations in Contiki-NG and provide a detailed

description of our proposed implementation. We then

delve into a security analysis of the cryptographic li-

brary we have chosen and the proposed toy protocol

in section 6. Section 7 provides an extended evalu-

ation of our proposed implementations and ﬁnally in

section 8 we conclude the paper.

2 RELATED WORK

In (Eschenauer and Gligor, 2002) authors introduced

a key-management scheme designed to meet the op-

erational and security requirements of distributed sen-

sor nodes (DSN). Their proposed scheme included se-

lective distribution and revocation of keys to sensor

nodes as well the capability of nodes to re-key with-

out substantial computational overhead. This pro-

posed scheme relied on three primary phases: key pre-

distribution, shared-key discovery and path-key es-

tablishment. Authors used probabilistic key sharing

among nodes and implemented a simple but effective

shared-key discovery protocol to achieve the primary

features of their scheme (i.e. key distribution, revo-

cation and node re-keying). Unlike this scheme, our

implementation eliminates the need to pre-distribute

keys and focuses on enabling the WSN nodes gener-

ate shared keys.

Another design of a secure network access sys-

tem for wireless sensor networks in (Sun et al., 2009)

used an elliptic curve public key cryptosystem, a

polynomial-based weak authentication scheme, and

hardware-based symmetric key cryptography. The

authors used ECC as a network admission control

to add new nodes to their environment. Further-

more, they introduced a controller node in their net-

work to authenticate new nodes using self-certiﬁed

ECDH protocol. The hardware-based symmetric key

cryptography was implemented using the hardware

security interface offered by TinyOS (Community,

2019) with the Imote2 sensor (Technology, ) running

TinyOS. The Imote2 platform comes with 256KB

SRAM, 32MB SDRAM and 32MB ﬂash. However,

contrary to this implementation, our work does not

require the use of a controller node or any third party

entity to verify nodes.

In (Zhou et al., 2019) authors present a re-

designed NIST P-256 and 256 SM2 (Feng, 2017)

cryptographic algorithm to ﬁt low-end IoT platforms

such as the 8-bit AVR processor. The authors adopt

an optimized ﬁnite ﬁeld arithmetic and elliptic curve

group arithmetic for optimum performance on their

selected IoT platform. The primary focus of the pa-

per is the use of techniques for various modular re-

duction and the adoption of the fastest method of big

IoTBDS 2020 - 5th International Conference on Internet of Things, Big Data and Security

102

integer multiplication and regular scalar multiplica-

tion algorithms. Authors used an optimized masked

operand technique for the modular addition and sub-

traction to reduce the latency while using Karatsuba

technique (Hutter and Wenger, 2011) to achieve sub-

quadratic complexity. Additionally, authors in (Raza

et al., 2017) proposed an end-to-end secure commu-

nication architecture between the IoT and a cloud

backend. Their implementation focused primarily

on the communication between the IoT smart de-

vices and the cloud platform rather than the inter-

communication between IoT nodes. The effort of au-

thors centered on extending the functionalities of the

Sics

Sense cloud platform for IoT with secure CoAP

features and DTLS. The results of their experimenta-

tions showed the DTLS handshake to be challenging

due to the utilization of public key cryptography.

3 SYSTEM MODEL

In this section, we introduce our system model by

explicitly deﬁning the main entities that are consid-

ered in our design and their capabilities. For the pur-

poses of our implementation, we let S = {s

,...,s

}

be the set of all sensor nodes (SN) in the WSN that

are deployed to register the occurrence of a speciﬁc

event and R = {r

,. ..,r

} be the set of all router

nodes (RN) deployed to aggregate data collected from

the sensor nodes. Furthermore, we assume that an

∈ S , registers a speciﬁc event by using sensed data.

The set of all sensed events by s

is denoted as E

,. ..,e

Sensor Node: An s

is a device responsible

for registering the occurrence of an environmental

or a speciﬁed events and sending data about the

event to a router r

. In our setup, the set S of

all sensor nodes consists of Zolertia Re-Mote board

devices that are based on the Texas Instruments

CC2538 ARM Cortex-M3 system on chip (SoC) (S.L,

2017b). The board has 512KB of programmable ﬂash

and 32KB of RAM and possesses a built-in battery

charger (500 mA) with energy harvesting capabili-

ties. We chose this Zolertia Re-Mote board due to

its industrial-grade design, ultra-low power consump-

tion capabilities and the very low amount of resources

available to it. The operations that an s

can perform

are:

1. Register the occurrence of a speciﬁc event, e

;

2. Generate a unique ECC private and public key

pair (sk

/pk

);

3. Generate a unique ECDSA signing and verifying

key pair (sig

/ver

);

4. Exchange the generated public key (pk

) with a

neighbouring node s

or a router r

;

5. Generate a shared symmetric key (K

i,j

) based on

a received public key;

6. Share data on a sensed event securely with the

other device partaking in the protocol;

The shared symmetric key is used to secure the

communication medium between the two communi-

cating entities.

Router Node: In our WSN environment, an r

is a

more powerful device in the network that is respon-

sible for aggregating data sent from sensor nodes in

S and then forwarding to a service or a cloud ser-

vice provider (CSP) for the beneﬁts of external users.

For this work, the set R of all router nodes consists

of Zolertia Orion Ethernet IP64 Router (S.L, 2017a)

board has 512KB ﬂash and 32KB RAM (16KB re-

tention) and 32MHz. This board is also an IPv4/IPv6

routing device with an Ethernet 10BASE-T interface.

As with the Zolertia Re-Mote board, we chose this

board due to its high resource constraints, power con-

sumption and industrial-grade design. Every router

node out of those in the set R is able to connect to a

central service (e.g. a CSP) via its Ethernet interface.

An r

is able to perform the following operations:

1. Generate a unique ECC private and public key

pair (sk

/pk

);

2. Generate a unique ECDSA signing and verifying

key pair (sig

/ver

);

3. Exchange the generated public key pk

with an s

that wishes to share data on a sensed event, e

;

4. Generate a shared symmetric key K

i,j

based on

the received pk

to create a secure communica-

tion medium;

The method by which the router nodes commu-

nicate to the CSP is beyond the scope of this paper

and as such will not be discussed. We however as-

sume this is done by means of a secure communica-

tion channel.

Cloud Service Provider (CSP): For the purposes of

our implementation, we assume the existence of a

CSP similar to the one described in (Paladi et al.,

2017; Paladi et al., 2014). The CSP can be seen as an

abstract external platform that consists of cloud hosts

operating virtual machines that communicate through

a network. The CSP will be the ﬁnal destination of

messages aggregated by R within the WSN. Speciﬁc

capabilities and features of the CSP are beyond the

focus of this paper and as such is not discussed into

detail. However, we assume CSP that takes advan-

tage of the beneﬁts of trusted computed – similar to

the one presented in (Paladi et al., 2017).

IoT-CryptoDiet: Implementing a Lightweight Cryptographic Library based on ECDH and ECDSA for the Development of Secure and

Privacy-preserving Protocols in Contiki-NG

103

4 CRYPTOGRAPHIC

PRIMITIVES AND THREAT

MODEL

In this section, we formally deﬁne the cryptographic

primitives that are used throughout the paper. Addi-

tionally, we describe the threat model that we consider

to ensure the security of our work.

4.1 Cryptographic Primitives

We utilize the ECDH key exchange protocol to se-

curely generate a shared symmetric key over a pre-

viously insecure medium. ECDH is an anonymous

key agreement protocol based on the popular Difﬁe-

Hellman algorithm implemented using elliptic curves.

With ECDH, two communicating parties both pos-

sessing an ECC public and private key pair are able

to establish a shared secret. The established shared

secret can be used directly as a symmetric key or used

to derive another symmetric key. We also implement

the ECDSA scheme to ensure message integrity in

the form of digital signature creation and veriﬁcation.

In our ECDH implementation, every s

in the set S

and every r

in the set R , generate an ECC key pair

(sk

,pk

) and (sk

,pk

) respectively. The key ex-

change protocol is completed when each communi-

cating entity exchanges their ECC public key to es-

tablish K

i,j

. in our work we utilize the P-256, which

we denoted simply as P − 256.

The following notations for cryptographic func-

tions are used throughout this paper.

1. ECC GenKeyPair : A probabilistic key generation

algorithm that takes as input, a prime p, a base-

point G, and the order of the ECC curve P − 256

and outputs an ECC private and public keypair. It

is used by all entities in our work to generate their

ECC private and public key pairs. We denote this

by (sk

,pk

) ← KeyGen(P − 256).

2. ECDH GenSharedKey : A probabilistic algorithm

that takes as input the ECC private key sk

of s

and the ECC public key pk

of r

. After a success-

ful run, it outputs a shared symmetric key K

i,j

. We

denote this by (K

i,j

) ← Gen(sk

,pk

3. AES Encrypt : A probabilistic algorithm that

takes as input a symmetric key K

i,j

and a mes-

sage m. After a successful run of this algorithm,

a ciphertext c

is outputted. We denote this by

← Enc(K

i,j

,m).

4. AES Decrypt : A deterministic algorithm that

takes as input a symmetric key K

i,j

and a ciper-

text c

. A successful run of this algorithm out-

puts the original message m. We denote this by

Dec(K

i,j

) → m.

5. ECDSA sign : A probabilistic algorithm that takes

as input the ECDSA private key sig

and the hash

of a message H(m) and outputs a signature. We

denote by sig

(m) → σ

(H(m)).

6. ECDSA verify : A deterministic algorithm that

takes as input the signed message, m, the signature

(H(m)) and the corresponding ECDSA public

key sig

. A successful run of the algorithm out-

puts a boolean value: valid or invalid.

4.2 Threat Model

This paper focuses primarily on the implementation

of cryptographic operations described in Section 4 as

part of Contiki-NG OS for IoT devices with very high

resource constraints. As such, we do not deﬁne a strict

threat model under which these operations are con-

sidered secure. However, our work lays a foundation

for protocols that consider the Dolev-Yao adversar-

ial model (Dolev and Yao, 1983) and the semi-honest

threat model. WSNs are particularly susceptible to

types of attacks performed in a number of arbitrary

ways such as denial of service attacks (Michalas et al.,

2010; Michalas et al., 2011b; Michalas et al., 2011a;

Michalas et al., 2012), privacy violation attacks (Dim-

itriou and Michalas, 2014), physical attacks, and node

replication attacks. We denote both a local and remote

adversary as ADV and we focus explicitly on privacy

violation attacks. Due to resource and computational

restraints on WSNs, it is almost impossible to guard

against a well-orchestrated and powerful ADV ca-

pable of performing denial-of-service attacks as well

as sensor communication jamming. To this end, we

make the following assumptions as extensions to the

adversarial model in (Dolev and Yao, 1983).

Cryptographic Security: We assume encryption

schemes are semantically secure and the ADV can-

not obtain the plain text of encrypted messages. We

also assume the signature scheme is unforgeable, i.e

ADV cannot forge the signature of an entity from our

system model and that the underlying cryptographic

hash functions can correctly verify the integrity and

authenticity of the exchanged messages. We assume

that the ADV , with a high probability, cannot predict

the output of a pseudorandom function. We explicitly

exclude denial-of-service attacks and focus on ADV

that aim to compromise the conﬁdentiality and pri-

vacy of participating SNs. However, we would like

to stress that for our main cryptographic schemes, we

use the TinyCrypt library (Wood, 2019). Develop-

ers of TinyCrypt state that the cryptographic schemes

implemented are not meant to be fully side-channel

IoTBDS 2020 - 5th International Conference on Internet of Things, Big Data and Security

104

resistant but rather offer certain generic timing-attack

countermeasures.

Physical Security: We assume the physical security

of the environment where the WSNs have been de-

ployed. This assumption is important due to the fact

that the WSN devices are not tamper resistant. Any

ADV with physical access to the devices can bypass

all security implementations.

5 EXTENSION TO Contiki-NG

In this section, we provide a brief overview of the

Contiki-NG OS and its current support for various

application-layer and link-layer security strategies.

We describe with the aid of a toy protocol, the exten-

sions that this work makes to the Simple UDP appli-

cation provided by Contiki-NG to implement a secure

end-to-end communication medium between multiple

communicating WSN nodes.

5.1 Contiki-NG

Contiki-NG is the most recent version of the popular

Contiki Project (Kurniawan, 2018). The Contiki-NG

OS uses Protothread which combines the merits of

both multithreading and event driven programming.

The OS uses the C programming language for writ-

ing applications and provides hardware abstractions

that enable it to work with various different WSN

hardware. The general architecture of Contiki-NG

OS consists of the Kernel, Program loader, Language

run-time, Communication service, and the Loaded

program modules. Currently, Contiki-NG comes

with support for application-layer security in the way

of DTLS and link-layer security for IEEE.802.15.4

TSCH (Contiki-Ng, 2019a). The application-layer se-

curity is achieved by modifying a version of the Tiny-

DTLS cryptographic library (Eclipse, 2018) which

comes with support for DTLS with pre-shared key

mode. DTLS is the standard for communications pri-

vacy when using User Datagram Protocols (UDP).

It enables client/server applications to communicate

in a secure way to prevent eavesdropping, message

forging and tampering (Michalas and Murray, 2017)

with a design based on the stream-oriented Transport

Layer Security (TLS) protocol. The obvious limita-

tions with the Contiki-NG implementation of appli-

cation security is the client/server nature of DTLS,

pre-shared key mode of DTLS and the size of hand-

shake messages (DTLS and TLS handshake messages

are up to 2

24−1

bytes while UDP datagrams are of-

ten limited to < 1500 bytes). Developers also provide

support for both the unsecure CoAP and the secure

CoAPs over DTLS. CoAP is an application-layer pro-

tocol quite similar to HTTP but transported over UDP

instead of TCP.

The secure implementation of CoAP integrates

DTLS to encrypt both the CoAP header and pay-

load, as well as authenticate the communication be-

tween client and server. To the best of our knowl-

edge, the only secure CoAP mode implemented by

Contiki-NG is the pre-shared key mode based on the

speciﬁc DTLS mode implemented by TinyDTLS. The

primary disadvantage with using the pre-shared node

is the amount of memory consumed by the DTLS key.

5.2 Extension to Contiki-NG

In this section, we present an overview of the exten-

sions made to the native UDP broadcast application

provided by Contiki-NG to provide an end-to-end se-

cure communication between multiple nodes. The

objective of the UDP broadcast application is to en-

able one node (i.e a sensor node s

) broadcast data

to other nodes (i.e a router node r

or another sen-

sor node s

). As part of its design, the application is

based on the simple_udp_connection module pro-

vided by Contiki-NG developers and is comprised

of three core functions. The simple_udp_sendto()

function used for sending broadcast messages, the

simple_udp_register() function which registers

and initializes a UDP connection, and attaches a call-

back to it and the udp_rx_callback() function for

listening for incoming UDP broadcast messages. The

functions are deﬁned as follows:

simple udp sendto()

simple_udp_sendto

(struct simple_udp_connection *c,

const void *data,

uint16_t datalen,

const uip_ipaddr_t *to)

simple udp register()

simple_udp_register

(struct simple_udp_conection *c,

uint16_t local_port,

uip_ipaddr_t *remote\_addr,

uint16_t remote_port,

udp_rx_callback)

IoT-CryptoDiet: Implementing a Lightweight Cryptographic Library based on ECDH and ECDSA for the Development of Secure and

Privacy-preserving Protocols in Contiki-NG

105

udp rx callback()

udp_rx_callback

(struct simple_udp_connection *c,

const uip_ipaddr_t *sender_addr,

uint16_t sender_port,

const uip_ipaddr_t *dest_addr,

uint16_t dest_port,

const uint8_t *data,

uint16_t datalen)

The broadcast message is transmitted in

plaintext as the data variable in both the

simple_udp_sendto() and udp_rx_callback()

functions. Therefore, to secure the contents

of the broadcast message, we implemented

the ECC GenKeyPair, ECDH GenSharedKey,

AES Encrypt, AES Decrypt, ECDSA sign and

ECDSA verify functions, presented in Section4, in

the native UDP application. To give a clear under-

standing of the extensions we made, we ﬁrst describe

the current implementation and then we proceed with

the description of the designed algorithms.

On runtime, a node s

that wishes to send a broad-

cast message initializes and registers a UDP connec-

tion using the function simple_udp_register().

Once this step is completed, s

searches its rout-

ing table to ﬁnd any nodes that have initial-

ized and registered their UDP connections with

NETSTACK_ROUTING.node_is_reachable()

function. The IP address of any discov-

ered node (r

or s

) is retrieved using the

NETSTACK_ROUTING.get_root_ipaddr() func-

tion. With the retrieved IP address, s

generates the

message to be sent and transmits it in plaintext by

using the simple_udp_sendto() function.

All communicating nodes run the

udp_rx_callback() function continuously in

the background to listen for any incoming messages.

Once a node receives a broadcast message, it retrieves

the data and sender addr variables for any further

back and forth communication. We note that there are

no operations performed on the data being transmit-

ted between nodes. We leverage the functionalities of

the simple UDP application to implement an efﬁcient

three-phased secure communication protocol. The

phases incorporated in our implementation are the

Handshake Phase, Shared Key Generation Phase,

and the Secure Communication Phase.

Handshake Phase: All nodes generate an ECC key

pair by running the ECC.GenKeyPair function. Once

the key pairs have been generated, each node ini-

tializes and registers a UDP connection using the

simple_udp_register() function. To broadcast

data about a sensed event, s

scans its routing table

for neighboring nodes and retrieves their IP addresses.

The handshake phase between s

and another node

(e.g a router node r

) is complete when s

utilizes

the simple_udp_sendto() function to send pk

and receives pk

from r

by listening for responses

using the udp_rx_callback() function.

Algorithm 1: ECC GenKeyPair.

Input: P − 256

Output: sk

,pk

function call;

if GenKeyPair == True then

return sk

,pk

;

else

Key Generation Failed!;

end

Algorithm 2: ECDH GenSharedKey.

Input: sk

,pk

,P − 256

Output: K

i,j

function call;

if (K

i,j

) ← Gen(sk

,pk

) == True then

return K

i,j

;

else

Shared Key Generation Failed!;

end

Algorithm 3: AES Encrypt.

Input: K

i,j

Output: c

initialize function call;

← Enc(K

i,j

,m);

return c

to the node

Algorithm 4: AES Decrypt.

Input: c

i,j

Output: m

initialize function call;

Dec(K

i,j

) → m;

Algorithm 5: ECDSA sign.

Input: sig

,m, P − 256

Output: σ

(H(m))

initialize function call;

HASH(m) → H(m);

Return σ

(H(m)) to node;

IoTBDS 2020 - 5th International Conference on Internet of Things, Big Data and Security

106

Algorithm 6: ECDSA verify.

Input: ver

,œ

(H(m)),m,P − 256

Output: True / False

initialize function call;

HASH(m) → H(m);

ECDSA verify(ver

,H(m),curve);

if ECDSA verify(ver

,H(m),curve) == True

then

Signature Veriﬁcation Successful!;

else

Signature Veriﬁcation Fail!;

end

Shared Key Generation Phase: We assume that

the participating nodes have successfully exchanged

their public keys from the previous phase. In this

phase, s

and r

compute a shared symmetric key K

i,j

by running the ECDH.GenSharedKey function (algo-

rithm 2). This phase is considered successful when

both nodes obtain the same K

i,j

based on the ex-

changed public keys.

Secure Communication Phase: Now that a shared

key K

i,j

has been successfully computed by the com-

municating nodes, s

is now ready to securely broad-

cast the data about a sensed event. To do so, s

en-

crypts a message m with K

i,j

to produce a ciphertext

which is sent to r

using simple_udp_sendto().

Upon reception of the broadcast message, r

recovers

m by decrypting c

5.3 Toy Protocol

To further elaborate how our implementation can be

used by researchers and developers to build secure

and privacy-preserving protocols, we describe a sim-

ple secure end-to-end protocol between a sensor node

and a router node r

. The s

is deployed in an en-

vironment to monitor a speciﬁed event. This protocol

seeks to ensure that messages between s

and r

are

secure, fresh and integrity protected.

At the beginning of our toy protocol, s

and r

gen-

erate an ECDH key pair, (sk

,pk

) and (sk

,pk

and an ECDSA key pair for message signing and sig-

nature veriﬁcation (sig

,ver

) and (sig

,ver

). To

establish a secure channel, s

exchanges pk

and ver

with r

and vice versa (Step 1 and 2 in Figure 1). Now

computes K

i,j

using the ECDH GenSharedKey

function with inputs hsk

,pk

i while r

also com-

putes K

i,j

with inputs hsk

,pk

To send a message m to r

, s

generates a ran-

dom number R

and encrypts m with K

i,j

to produce

the ciphertext c

. The hash of c

and R

is signed

with sig

to output σ

(H(c

||R

)) (algorithm 5).

Once this is done, s

generates a message, msg

,σ

(H(c

||R

))i and sends it to r

. This mes-

sage format is used with the aim of achieving message

freshness and integrity. Upon reception of msg

, r

decrypts c

with K

i,j

and veriﬁes σ

(H(c

||R

)) with

ver

(algorithm 6). The protocol is successful when

successfully veriﬁes the signature. A high-level il-

lustration of the protocol is presented in Figure 1. It

is worth mentioning that our extension to Contiki-NG

can be used to secure any protocol that involves the

communication of two parties without the need to in-

volve any other entity such as a server or a trusted

authority.

,ver

msg

= R

,σ

(H(c

))

Figure 1: End-to-End Communication.

6 SECURITY ANALYSIS

In this section we elaborate on the security of our ap-

proach. To do so, we ﬁrst discuss the security of Tiny-

Crypt and the schemes that we used (AES, ECDH,

and ECDSA) and then move on by providing a brief

security analysis of the toy protocol presented earlier

in the presence of a malicious adversary. At this point,

it is worth mentioning that the security of the main

cryptographic schemes is not examined since their se-

mantic security has been already proved. However,

we elaborate on the security of the actual TinyCrypt

implementation.

6.1 Tinycrypt Library Security

It should be noted that developers of Tinycrypt em-

phatically state that the library is not intended to

be side-channel resistant due to the large variety

of side-channel attacks available. In an attempt to

make the library safe for use, they implement spe-

ciﬁc generic timing-attack countermeasures (Fan and

Verbauwhede, 2012) which do not affect the overall

code size. Tinycrypt seeks to implement all cryp-

IoT-CryptoDiet: Implementing a Lightweight Cryptographic Library based on ECDH and ECDSA for the Development of Secure and

Privacy-preserving Protocols in Contiki-NG

107

tographic schemes with a minimum set of standard

cryptographic primitives. The library is built entirely

with the goal of ensuring security, minimum footprint

possible and ﬂexibility. In an effort to ensure the secu-

rity of the implemented schemes, the library utilizes

a reliable pseudo-random generator that is claimed to

be vetted by a community of experts.

When implementing SHA-256, the number of

hashed bits in any state is not checked for data over-

ﬂow. However, this becomes an issue if one intends to

hash a message of more than 2

bits. The library also

does not provide support for AES key lengths greater

than 128. This limitation is based on the fact that

AES-256 requires key schedules almost 40% larger

than AES-128 with double the key size. Considering

the fact that we are working with resource constrained

devices, this limitation of the AES implementation is

not considered critical. Concerning the ECDH and

ECDSA implementations, a cryptographically secure

pseudorandom number generator (PRNG) function is

initiated to ensure the secure generation of random

numbers. In an effort to reduce the code size, all large

integers are represented with little endian words. Us-

ing little endian words enable efﬁcient writing of mul-

tiple precision math routines utilized by the library (

i.e operations can be performed on the least signiﬁ-

cant bytes while the most signiﬁcant bytes are being

fetched from memory).

To verify the correctness of the schemes imple-

mented, the library also provides a set of test val-

ues that can be used to test each cryptographic prim-

itive against publicly available validated test vectors.

The ECDH and ECDSA implementations are tested

against vectors from the NIST Cryptographic Algo-

rithm Validation Program (CAVP) (Division et al., ).

During our experiments, we tested all the adopted

schemes from Tinycrypt against these NIST CAVP

vectors and successfully veriﬁed their correctness and

integrity.

6.2 Toy Protocol Security

Realistic Assumption: We assume that all nodes are

able to verify the owner of a public key. By doing this,

we eliminate the possibility of a man-in-the-middle

attack.

Our goal here is to show that by using our work,

researchers can build protocols that will ensure secure

communication between two or more entities. To do

so, we will brieﬂy prove the security of the toy pro-

tocol presented in ﬁgure 1 by assuming the existence

of a malicious adversary ADV that tries to fool any

of the participating entities either by replaying old

messages or by replacing original messages with fake

ones.

Proposition 1 (Message Compromise). Let ADV

be a malicious adversary that seeks to tamper with

the contents of msg

or create a fake message msg

ADV successfully completes this attack if she tam-

pers with the contents of the message msg

or creates

a new message, msg

, such that neither s

nor r

able to distinguish between the real message and the

modiﬁed or fake message.

Proof. ADV can choose either to tamper with the

random number R

or with the actual ciphertext c

However, since both of these values are included in

the signature, σ

(H(c

||R

)), part of the real msg

changing them implies forging s

’s signature. How-

ever, based on our threat model where we have as-

sumed cryptographic security, this attack can only

happen with negligible probability. Thus, r

, would

understand that the message has been tampered with,

and drop the connection

Proposition 2 (Message Replay). Let ADV be a

malicious adversary that seeks to deceive one of the

communicating parties by replaying an old message,

msg

= hR

,σ

(H(c

||R

))i, with a valid signa-

ture σ

. ADV will successfully launch this attack if

accepts the message as valid.

Proof. Here we consider the scenario where ADV

replays an old message msg

to r

in an attempt to

convince r

that she is a legitimate sensor node in

the network. ADV can either choose to generate a

new random R

or reuse the same random number R

that was used in an old run of the protocol between

and r

. Even though the structure of the message

is correct and it also contains a valid signature σ

can easily identify that the received message is not

fresh. This is because R

is not the same as the ran-

dom number hashed in the second part of the mes-

sage, σ

(H(c

||R

)), or that the re-used R

is part of

an old message. Therefore, the veriﬁcation step of the

protocol will fail and r

will drop the connection.

7 EXPERIMENTAL RESULTS

In this section, we evaluate the performance of our

implementation on the WSN devices. Our testbed

consisted of a sensor node (a zolertia Re-Mote board

with 512KB programmable ﬂash and 32KB of RAM)

and a router node (a zolertia Orion Ethernet IP64

Router with 32KB RAM (16KB retention and 512KB

ﬂash). All programming for this section was in C

language on the Contiki-NG OS platform. We also

IoTBDS 2020 - 5th International Conference on Internet of Things, Big Data and Security

108

utilized a modiﬁed version of the Tinycrypt library

to implement all the cryptographic functions required

for our work. To facilitate the performance of our

work, we built a Contiki-NG testing application pur-

posely to evaluate all functions introduced in Sec-

tion 4. Once completed, we integrated the functions

into the native Contiki-NG UDP broadcast applica-

tion and analysed the difference in speciﬁc perfor-

mance metrics. Due to the resource constrained na-

ture of the WSN devices, our experiments mainly

aimed at analysing the processing time of the under-

lying encryption schemes, code size and the amount

of data being used by the applications.

7.1 Performance of Cryptographic

Functions

To comprehensively measure the performance of each

function of the WSN devices, we repeatedly run the

functions on both the router node and the sensor node.

The performance of a function comprises the execu-

tion time, energy usage and memory usage. Our test

application aimed to measure the execution times of

these functions. To ensure accurate readings, we ran

each test 50 times.

Execution Time. We measured the execution times

of the proposed functions by using the timer li-

brary provided by Contiki-NG. Essentially, we mea-

sured the time period for the completion of a spe-

ciﬁc function. During our experiments, we observed

that the system time in most WSN platforms, includ-

ing the CC2538 platform for which all our devices

are based on, is represented as CPU ticks and lim-

ited to long unsigned values. Due to this limita-

tion, all performance ﬁgures received from our ex-

periments were recorded in ticks and externally con-

verted to seconds. We derived speciﬁc ﬁgures by di-

viding the number of recorded ticks by 128 (CPU

ticks per second is 128 as deﬁned in Contiki-NG).

The results of this phase of the experiments can be

seen in Table 1. As can be seen from the table,

ECC GenKeyPair function requires around 167 CPU

ticks to complete which corresponds to 1.305sec.

ECDH GenSharedKey function’s execution time is

approximately 165 CPU ticks which corresponds

to 1.289sec. AES Encrypt and AES Decrypt both

needed around 1 CPU tick corresponding to 0.007sec

to complete. ECDSA sign executes in around 176

CPU ticks while ECDSA verify in 198 CPU ticks cor-

responding to 1.375sec and 1.547sec respectively.

Table 1: Function Execution Times.

CPU Ticks Time(sec)

ECC GenKeyPair 167 1.305

ECDH GenSharedKey 165 1.289

AES Encrypt 1 0.007

AES Decrypt 1 0.007

ECDSA sign 176 1.375

ECDSA verify 198 1.547

Memory Usage. In this phase of the experiments,

we shift our focus to the application components sizes

in memory. More speciﬁcally, we compared the mem-

ory usage of the native UDP broadcast application

without our extensions and the new application which

integrates all of our proposed functions. It is worth

mentioning that the Contiki-NG OS provides support

for two forms of data storage (external and internal

MCU). Our work focuses on the internal MCU stor-

age model which comprises the ROM and RAM com-

ponents (in the future, we plan to look at exploiting

external storage models to provide support for imple-

mentations with larger data requirements). Altogether

with the necessary drivers and the Contiki-NG OS,

the native UDP broadcast application ﬁts in 41998-

bytes of ROM and consumes a total of 12807-bytes

of RAM. However, when our functions are integrated

with the application, it ﬁts in 46015-bytes of ROM

and consumes a total of 13943-bytes of RAM. Table 2

provides a breakdown of memory utilization of both

programs. It can be observed that the primary differ-

ence between both programs is the size of the data

section of the RAM. This can be associated to the

additional data variables included to store the cryp-

tographic data.

Table 2: Application Memory Usage.

ROM RAM RAM

Native Application 41998 544 12263

Extended Application 46015 1616 12327

Energy Consumption. For this phase, we utilized

the Energest module provided by Contiki-NG. This

module offers lightweight software-based energy es-

timations for resource constrained WSN devices by

monitoring the operations of the device’s various

hardware components (i.e. CPU and Radio).

In our experiments, the CPU active and radio lis-

tening modes were active and the measurements for

these correlate directly to the execution times of the

underlying functions. In other words, the more time it

takes to execute a function, the more energy is con-

sumed. We utilized the CPU current consumption

values from (S.L, 2017b) to calculate the energy con-

sumption of each of the designed functions. Table 3

IoT-CryptoDiet: Implementing a Lightweight Cryptographic Library based on ECDH and ECDSA for the Development of Secure and

Privacy-preserving Protocols in Contiki-NG

109

Table 3: Energy Consumption based on Execution Times.

Time(s) Energy(mJ)

ECC GenKeyPair 1.305 78.3

ECDH GenSharedKey 1.289 77.34

AES Encrypt 0.007 0.42

AES Decrypt 0.007 0.42

ECDSA sign 1.375 82.5

ECDSA verify 1.547 92.82

provides a summary of the CPU energy usage for each

of the described functions.

7.2 Open Science & Reproducible

Research

As a way to support open science and reproducible

research and to give the opportunity for other re-

searchers to use, test and hopefully extend/enhance

our scheme, we have made available the code of the

actual scheme publicly through Gitlab

. Additionally,

the script used for testing the performance of the cryp-

tographic components has also been uploaded as a re-

search artefact (Open Access) on Zenodo

8 CONCLUSION

WSN devices have become a huge part of basic

smart environment design and development among

researchers and industrial key players. Implementing

standard security protocols on these devices has gar-

nered a lot of interest from all stakeholders. In this

paper, we implemented a lightweight cryptographic

library that we used to design a simple secure key

exchange protocol on Zolertia devices. Our work

was based on the modiﬁcation of the ECDH and

ECDSA components of the Tinycrypt library. Our

implementation extends the functionalities of the na-

tive UDP broadcast application on Contiki-NG to pro-

vide Key Generation, Encryption, Decryption, Sign-

ing and Signature Veriﬁcation. One of the primary ad-

vantages of our work over the currently implemented

DTLS on the Contiki-NG OS platform is that our im-

plementation has no need for a server or any trusted

third party. We believe this work will lay the founda-

tion for researchers to design and securely implement

privacy-preserving protocols as well as to implement

additional cryptographic schemes that will meet the

speciﬁc needs of IoT.

https://gitlab.com/nisec/iot-cryptodiet-experiments.git

https://zenodo.org/record/3686865

ACKNOWLEDGEMENT

This research has received funding from the Euro-

pean Union’s Horizon 2020 research and innovation

Programme under grant agreement No 825355 (CY-

BELE).

REFERENCES

Community, T. (2019). Tinyos project.

Contiki-Ng (2019a). Contiki-ng: Communication security.

Contiki-Ng (2019b). Contiki-ng: Documentation.

Dimitriou, T. and Michalas, A. (2014). Multi-party trust

computation in decentralized environments in the

presence of malicious adversaries. Ad Hoc Networks,

15:53–66.

Division, C. S., Laboratory, I. T., of Standards, N. I., Tech-

nology, and of Commerce, D. Cryptographic algo-

rithm validation program.

Dolev, D. and Yao, A. (1983). On the security of public key

protocols. IEEE Transactions on Information Theory,

29(2):198–208.

Eclipse (2018). Elipse - tinydtls.

Eschenauer, L. and Gligor, V. D. (2002). A key-

management scheme for distributed sensor networks.

ACM Conference on Computer and Communications

Security, (3):41–47.

Fan, J. and Verbauwhede, I. (2012). An updated survey

on secure ecc implementations: Attacks, countermea-

sures and cost. Cryptography and Security: From The-

ory to Applications Lecture Notes in Computer Sci-

ence, page 265–282.

Feng, D. (2017). Trusted computing: Principles and Appli-

cations. De Gruyter.

Hutter, M. and Wenger, E. (2011). Fast multi-precision mul-

tiplication for public-key cryptography on embedded

microprocessors. Cryptographic Hardware and Em-

bedded Systems – CHES 2011 Lecture Notes in Com-

puter Science, page 459–474.

Kurniawan, A. (2018). Practical Contiki-NG: Program-

ming for Wireless Sensor Networks. Apress.

Liang, Z., Walters, J. P., Chaudhary, V., and Shi, W. (2007).

Wireless sensor network security. Security in Dis-

tributed, Grid, Mobile, and Pervasive Computing,

page 367–409.

Michalas, A., Komninos, N., and Prasad, N. (2011a). Multi-

player game for ddos attacks resilience in ad hoc net-

works. In Wireless Communication, Vehicular Tech-

nology, Information Theory and Aerospace Electronic

Systems Technology (Wireless VITAE), 2011 2nd In-

ternational Conference on, pages 1–5.

Michalas, A., Komninos, N., and Prasad, N. R. (2011b).

Mitigate dos and ddos attack in mobile ad hoc net-

works. International Journal of Digital Crime and

Forensics (IJDCF), 3(1):14–36.

Michalas, A., Komninos, N., and Prasad, N. R. (2012).

Cryptographic puzzles and game theory against dos

IoTBDS 2020 - 5th International Conference on Internet of Things, Big Data and Security

110

and ddos attacks in networks. International Journal

of Computer Research, 19(1):79.

Michalas, A., Komninos, N., Prasad, N. R., and Oleshchuk,

V. A. (2010). New client puzzle approach for dos re-

sistance in ad hoc networks. In Information Theory

and Information Security (ICITIS), 2010 IEEE Inter-

national Conference, pages 568–573. IEEE.

Michalas, A. and Murray, R. (2017). Keep pies away from

kids: A raspberry pi attacking tool. In Proceedings of

the 2017 Workshop on Internet of Things Security and

Privacy, IoTS&P ’17, pages 61–62, New York,

NY, USA. ACM.

Paladi, N., Gehrmann, C., and Michalas, A. (2017). Pro-

viding user security guarantees in public infrastruc-

ture clouds. IEEE Transactions on Cloud Computing,

5(3):405–419.

Paladi, N., Michalas, A., and Gehrmann, C. (2014). Do-

main based storage protection with secure access con-

trol for the cloud. In Proceedings of the 2014 Inter-

national Workshop on Security in Cloud Computing,

ASIACCS ’14, New York, NY, USA. ACM.

Piedra, A. D. L., Braeken, A., and Touhaﬁ, A. (2013).

Leveraging the dsp48e1 block in lightweight crypto-

graphic implementations. 2013 IEEE 15th Interna-

tional Conference on e-Health Networking, Applica-

tions and Services (Healthcom 2013).

Raza, S., Helgason, T., Papadimitratos, P., and Voigt, T.

(2017). Securesense: End-to-end secure commu-

nication architecture for the cloud-connected inter-

net of things. Future Generation Computer Systems,

77:40–51.

Schmidt, S., Tausig, M., Koschuch, M., Hudler, M.,

Simhandl, G., Puddu, P., and Stojkovic, Z. (2018).

How little is enough? implementation and evaluation

of a lightweight secure ﬁrmware update process for

the internet of things. Proceedings of the 3rd Interna-

tional Conference on Internet of Things, Big Data and

Security.

S.L, Z. (2017a). Zolertia/orion ethernet ip64 router.

S.L, Z. (2017b). Zolertia/re-mote platform.

Strangio, M. A. (2005). Efﬁcient difﬁe-hellmann two-party

key agreement protocols based on elliptic curves. Pro-

ceedings of the 2005 ACM symposium on Applied

computing - SAC 05.

Sun, K., Liu, A., Xu, R., Ning, P., and Maughan, D. (2009).

Securing network access in wireless sensor networks.

Proceedings of the second ACM conference on Wire-

less network security - WiSec 09.

Technology, C. M. Wireless sensor networks: Imote2.

Wood, M. (2019). Tinycrypt.

Zhou, L., Su, C., Hu, Z., Lee, S., and Seo, H. (2019).

Lightweight implementations of nist p-256 and sm2

ecc on 8-bit resource-constraint embedded device.

ACM Transactions on Embedded Computing Systems,

18(3):1–13.

IoT-CryptoDiet: Implementing a Lightweight Cryptographic Library based on ECDH and ECDSA for the Development of Secure and

Privacy-preserving Protocols in Contiki-NG

111