LiKe: Lightweight Certificateless Key Agreement for Secure IoT Communications

Abstract

Certificateless Public Key Cryptography (CL-PKC) schemes are particularly robust against the leakage of secret information stored on a Trusted Third Party (TTP). These security features are particularly relevant for Internet of Things (IoT) domains, where the devices are typically pre-configured with secret keys, usually stored locally on the TTP for following maintenance tasks. Despite some contributions already proposed the adoption of CL-PKC schemes in constrained IoT devices, current solutions generally require high message overhead, are computationally demanding, and generally, place a high toll on the energy budget. To close this gap, we propose LiKe, a lightweight pairing-free certificateless key agreement protocol suitable for integration in the latest Zigbee 3.0 protocol stack and constrained IoT devices. LiKe is an authenticated key agreement protocol characterized by: (i) ephemeral cryptographic materials; (ii) support for intermittent connectivity with the TTP; (iii) lightweight rekeying operations; and, (iv) robustness against impersonation attacks, even when information stored on the TTP are leaked. LiKe has been thoroughly described, and its security properties have been proved via formal tools. Moreover, we have implemented and tested it on real IoT devices, in networks with up to 11 nodes-the source code has been released as open-source. Results are striking: on the OpenMote-b hardware platform, LiKe requires a total time of 3.259 s to establish session keys on each participating device, and at most 0.258% of the overall battery capacity, emerging as a lightweight and energy-friendly solution. Finally, comparisons with competing solutions do show the superior quality and viability of our proposal.

Full text

1
LiKe: Lightweight Certificateless Key Agreement
for Secure IoT Communications
Pietro Tedeschi∗, Savio Sciancalepore∗, Areej Eliyan∗, Roberto Di Pietro∗
∗Division of Information and Computing Technology
College of Science and Engineering, Hamad Bin Khalifa University - Doha, Qatar
{ssciancalepore, rdipietro}@hbku.edu.qa, {ptedeschi, aeliyan}@mail.hbku.edu.qa
Abstract—Certificateless Public Key Cryptography (CL-PKC)
schemes are particularly robust against the leakage of secret
information stored on a Trusted Third Party (TTP). These
security features are particularly relevant for Internet of Things
(IoT) domains, where the devices are typically pre-configured
with secret keys, usually stored locally on the TTP for following
maintenance tasks. Despite some contributions already proposed
the adoption of CL-PKC schemes in constrained IoT devices,
current solutions generally require high message overhead, are
computationally demanding, and generally, place a high toll on
the energy budget.
To close this gap, we propose LiKe, a lightweight pairing-free
certificateless key agreement protocol suitable for integration in
the latest Zigbee 3.0 protocol stack and constrained IoT devices.
LiKe is an authenticated key agreement protocol characterized
by: (i) ephemeral cryptographic materials; (ii) support for
intermittent connectivity with the TTP; (iii) lightweight rekeying
operations; and, (iv) robustness against impersonation attacks,
even when information stored on the TTP are leaked.
LiKe has been thoroughly described, and its security properties
have been proved via formal tools. Moreover, we have imple-
mented and tested it on real IoT devices, in networks with up to
11 nodes — the source code has been released as open-source.
Results are striking: on the OpenMote-b hardware platform,
LiKe requires a total time of 3.259 s to establish session keys
on each participating device, and at most 0.258% of the overall
battery capacity, emerging as a lightweight and energy-friendly
solution. Finally, comparisons with competing solutions do show
the superior quality and viability of our proposal.
Index Terms—Secure Communications, Device-to-Device Com-
munication, Internet of Things, Key Agreement Protocol.
I. INTRODUCTION
Despite being known for almost a decade, the last few
years have seen the definitive explosion of the Internet of
Things (IoT) phenomenon [1]. Thanks to advancements in
chipset production and embedding technologies, tiny and smart
devices are nowadays pervasive, being integrated into our
homes, offices, and roads, enabling capillary access to the
underlying physical environment [2], [3], [4], [5]. According
to Juniper Research, IoT devices connected in 2018 were 21
billion, and their number is expected to exceed 50 billion by
2022 [6]. This increasing trend has been further boosted by
the recent introduction of the updated Zigbee 3.0 standard
This is a personal copy of the authors. Not for redistribution. The final
version of the paper is available through the IEEE Digital Library, at
the link: https://ieeexplore.ieee.org/document/8901222, with the DOI: doi:
10.1109/JIOT.2019.2953549.
specification, offering full-mesh networking capabilities and
supporting hundreds of devices on a single network [7], [8].
While smart applications and enabling scenarios are con-
tinuously emerging and evolving, energy consumption and
security requirements remain a concern. On the one hand, a
large part of IoT devices are battery-powered, and replacing
batteries very often cannot be scalable. Thus, IoT devices
require effective techniques to efficiently manage the reduced
amount of available energy [9]. On the other hand, being often
unattended and embedded within the surrounding environment,
IoT devices need to be appropriately secured against unautho-
rized accesses and malicious usage [10].
However, designing reliable and effective security solutions
for IoT applications is not a trivial task. Indeed, a suitable
solution should guarantee the same level of security offered
by modern regular wireless networks, while also requiring
minimum message overhead, viable complexity, short delays,
and minimal energy consumption [11].
The new Zigbee 3.0 protocol suite deals with the key
agreement at layer-2, by adopting the Certificate-Based Key
Establishment (CBKE) protocol; this latter one allowing the
participating devices to authenticate each other and share
symmetric session keys. These symmetric keys are then used
to secure any message exchanged between the devices. Avail-
able options to establish the unique relationship between the
device and their key materials include the use of X.509
certificates, signed through the well-known Rivest, Shamir,
& Adleman (RSA) and Elliptic Curve Digital Signature Al-
gorithm (ECDSA) cryptography techniques, or the adoption
of Elliptic Curve Qu-Vanstone (ECQV) certificates, being
characterized by reduced size and overhead. However, all these
valuable solutions strongly rely on a central Trusted Third
Party (TTP), namely Certification Authority (CA), often co-
located with a Domain Authority (DA). Thus, if the nodes’
secret information available on this authority are leaked, for
instance, due to software or network management faults, a
malicious adversary could gain the full control of the network,
impersonate any device, and violate data confidentiality—with
little or no chance of being detected.
Contribution. To address the above introduced challeng-
ing scenario, in this paper we propose LiKe, a lightweight
certificateless key agreement scheme specifically designed to
meet the severe bandwidth and energy limitations of resource-
constrained IoT devices. Compared to existing pairing-free
certificateless key agreement schemes, the LiKe protocol in-

2
cludes many adaptations and improvements, both from the
security and from the architectural perspective, that make
certificateless key agreement schemes finally viable for con-
strained IoT devices. Such modifications include ephemeral
keys negotiation, lightweight re-keying operations, support
for offline domain authority, reduced message overhead, re-
duced latency, reduced energy consumption, and improved
scalability— all crucial features for a key agreement protocol
intended to work in real IoT deployments. In addition, we
integrated LiKe in a real communication technology for the
IoT (i.e., the IEEE 802.15.4-2015 standard, at the roots of
the Zigbee 3.0 protocol stack), and we implemented it on real
IoT devices, i.e., the OpenMote-b boards based on the CC2538
System on Chip (SoC).
Compared with standardized security solutions recom-
mended by the latest Zigbee 3.0 protocol suite, LiKe of-
fers unique advantages when the secret nodes’ information
available on the Domain Authority (DA) are leaked to a
powerful adversary. In this challenging scenario, competing
solutions fail to avoid impersonation attacks, while LiKe can
still achieve message source authentication, thus rejecting the
attack. These unique security properties have been formally
verified by using the open-source tool ProVerif, demonstrat-
ing enhanced security features concerning CBKE-based ap-
proaches.
When set up with a 160-bit elliptic curve (providing a
security level of 80 bits) [12], LiKe allows IoT devices to
agree on a shared secure session key in only 0.340 seconds,
by requiring only 2messages per device and only the 0.135%
of the overall battery storage capacity of a typical IoT de-
vice. Compared to the CBKE protocol using X.509-ECDSA
and ECQV certificates, LiKe achieves a reduction in energy
consumption of 14.83% and 0.195%, respectively, while also
enjoying the additional protection against the leakage of secret
information stored at the Domain Authority.
Finally, the source code related to the implementation of the
LiKe protocol in the OpenWSN protocol stack and its auto-
matic security verification using the ProVerif tool have been
released as open-source [13]. This could allow practitioners,
industries, and academia to verify our claims and to compare
their own solutions with LiKe, eventually using our source
code as a ready-to-use basis for their software development.
Roadmap. The rest of the paper is organized as follows:
Section II provides a brief overview of certificateless public
key cryptography, as well as related work discussion; Section
III describes the system model and the description of the
adversary, while Section IV illustrates the logic and details of
the LiKe protocol. Section V discusses security considerations
and provides formal security verification of LiKe via the
ProVerif tool, while Section VI presents the results obtained
through an experimental performance assessment on real IoT
devices. Finally, Section VII tightens the conclusions.
II. BACKGROU ND A ND RE LATE D WORK
In this section, we provide the background on the
Certificateless Public Key Cryptography (CL-PKC) class of
approaches, as well as an overview of the distinguishing
features of our proposed LiKe protocol compared to similar
proposals in the current literature.
A. Certificateless Public Key Cryptography in a nutshell
CL-PKC is a class of cryptographic approaches that was
initially conceived by Al-Riyami and Paterson in [14], to
overcome existing security limitations affecting Identity Based
Cryptography (IBC) schemes. Specifically, in IBC schemes,
as well as in any system based on a Public Key Infrastructure
(PKI), the private-key generation process for all the entities
in the system is completely controlled by a trusted authority,
namely the Key Generation Center (KGC). Thus, an adversary
in possession of secret information leaked from the KGC could
fully impersonate any of the entities, without any chance to
be detected.
Such an issue, namely Key Escrow, is overcome by CL-PKC
schemes by dividing the private key generation process into
two parts, one controlled by the KGC and one controlled by
the requesting entity, respectively [15].
Let us assume a requesting entity Aand a trusted authority
KGC, in charge of generating cryptography materials. Without
loss of generality, a CL-PKC scheme can be summarized in
seven distinct phases, described below.
Setup. This phase is executed by the KGC. Starting from
a security parameter k, this phase generates a Master Public
Key mpk and a Master Private Key msk uniquely associated
with the KGC.
Partial-Private-Key-Extract. This phase is trig-
gered by a request performed on a secure channel by a
requesting entity, namely A, aiming at receiving dedicated
cryptography materials, and it is mainly executed by the
KGC. Starting from the Master Public Key mpk, the Master
Private Key msk and an identity string IDA∈ {0,1}∗of
the requesting entity, this phase generates the correspondent
partial private key dAfor the requesting entity.
Set-Secret-Value. This phase is executed by the
requesting entity A, and it is aimed at generating the second
part of the private key. Specifically, starting from the Master
Public Key mpk, the identity string IDA, and a private
pseudo-random value, this phase generates an entity-dependent
secret key xA.
Set-Private-Key. This phase is executed on the re-
questing entity Aand it is in charge of defining the full private
key of the entity A. Starting from the Master Public Key mpk,
the partial private key dAand the secret value xAof the entity,
it generates the full private key skAof the requesting entity
A.
Set-Public-Key. This phase is executed on the re-
questing entity Aand it is in charge of defining the full public
key of the entity A. Starting from the Master Public Key of
the authority mpk and the secret value xAof the entity, it
generates the public key of the entity, namely pkA∈ PK.
Encrypt. This phase is executed by the entity Awhen it
needs to deliver a new encrypted message. Starting from the
master public key mpk, the receiver’s identity string IDB, the
public key pkBof the entity B, and the clear-text message
m∈ M, this phase generates the correspondent cipher-text

3
C∈ C. In case the public key is corrupted, this phase produces
an error.
Decrypt. This phase is executed by an entity Breceiving
the encrypted message C, and it is aimed at recovering the
plain-text m. Starting from the master public key mpk, the
receiving private key of the receiving entity skB, and the
cipher-text C∈ C, it generates the plain-text message m∈ M.
Otherwise, if the message is corrupted or the private key does
not match with the public key used in the cipher-text, this
phase ends with an error.
The advantages deriving by the adoption of a CL-PKC
technique are manifold [16]. First, CL-PKC schemes eliminate
certificate chains and certificate verification processes. At
the same time, the unique relationship between an entity
and its public key can be obtained directly from involved
cryptographic values. As such, CL-PKC schemes can get rid of
the transmission of a public key certificate bound to the public
key of the entity, achieving a consistent bandwidth reduction.
At the same time, CL-PKC schemes do not require any pre-
shared secret between communicating entities.
It is worth noting that, when the information about the
partial private key of the nodes, available on the KGC, are
leaked to the adversary, it could be able to obtain only a partial
part of the full private key of an entity, i.e., the cryptographic
material the KGC is in charge of generating. However, being
the full private key of an entity enriched with a self-generated
portion, the malicious entity could not be able to obtain the
full private key, thus not being able to access directly to the
content of legitimate communications. Thus, CL-PKC schemes
are robust even if the information of the devices, stored locally
on the KGC, are leaked to the adversary.
Finally, we remark that CL-PKC schemes are robust until
the adversary is not able to: (i) impersonate the KGC (e.g., by
stealing its secret private key); or, (ii) access to secret stored
locally on the participating devices. In case any of these two
situations occur, CL-PKC schemes become vulnerable, like
any other PKI-based scheme available in the literature. Thus,
as it will be detailed in Sec. III-B, the adversary assumed in
CL-PKC schemes is assumed not to be able to impersonate or
replace the legitimate KGC in the system.
B. Related Work
Legacy CBKE schemes based on X.509 certificates signed
through well-known cryptography schemes, such as Rivest-
Shamir-Adleman (RSA) and ECDSA, have several issues
when adopted in the context of the IoT [17].
Indeed, despite the adoption of the ECDSA technique allows
one to provide the same security level than the RSA technique
by reducing the overall certificate size, still the size of the
certificate is significant (in the order of 864 bytes for a security
level of 160 bits), leading to: (i)large bandwidth overhead;
(ii) large time to validate a certificate; (iii) significant storage
space; and, (iv) overwhelming energy consumption for con-
strained IoT devices [18].
These weaknesses motivated the design of more lightweight
solutions, characterized by limited bandwidth overhead and
computational efforts. One of the most effective solutions
along this direction is the ECQV technique. ECQV-based
schemes consistently reduce the size of the certificate, by
eliminating the need for an explicit signature. At the same
time, they do not require overwhelming cryptographic oper-
ations to be performed on involved devices. For instance, as
demonstrated by the authors in [19], a security level of 160
bits can be achieved leveraging ECQV-based certificates of
only 78 bytes, resulting in reduced MAC-layer messages.
The advantages of the ECQV technique has been also
recognized by many companies and communities. Indeed, in
the latest Zigbee 3.0 protocol suite, the ECQV technique has
been officially integrated as a possible option to decrease the
computational overhead and the bandwidth consumption in
constrained IoT devices [7].
Despite ECQV solved the above issues, that are particularly
relevant in the context of IoT devices, some limitations still
remain. Specifically, according to the ECQV scheme, the KGC
has full knowledge of the secret information of the devices,
such as their private keys. If such information are leaked to the
adversary, the overall security of any node in the network is
compromised. In addition, when a certificate is received by a
node, this device still has to verify the whole certificate chain,
up to the main CA. Such certificates need to be stored on the
devices, leading to additional overhead.
These limitations motivated further research efforts, result-
ing in a new class of approaches, namely Certificateless Public
Key Cryptography (CL-PKC). CL-PKC approaches overcome
the above issues by partially relaxing the dependence of the
key agreement scheme from the KGC [16]. Thanks to the
adoption of CL-PKC schemes, two main advantages can be
achieved. First, being the full private key of the devices not
completely known by the KGC, even if the secret information
of the IoT devices stored on the KGC are leaked to the
adversary, the security of the whole network is still guaranteed.
In addition, CL-PKC schemes eliminate the need for a cer-
tificate associated with each device. Indeed, the participating
devices only have to store the public key of the KGC, and
not the overall certificate chain, from the leaf device to the
KGC. Thus, CL-PKC schemes allow further reduction of the
computational and storage requirements on involved devices.
The above considerations have been summarized in Tab. I,
highlighting the main features of X.509-ECDSA, ECQV, and
CL-PKC approaches along the main system requirements
discussed before.
In the literature it is possible to find many CL-PKC schemes
contextualized in the IoT ecosystems, such as [20]--[26],
characterized by distinctive constructions and properties [16].
Table II provides an overview of their features and a cross-
comparison with the features offered by the proposed LiKe
protocol.
We notice that some existing approaches, including [21],
[23], involve computationally-intensive and time-consuming
pairing operations, very energy-consuming on constrained IoT
devices. At the same time, many of the analyzed approaches,
including [20], [23], and [24], also rely on the availability of
the DA during the key agreement, leading to high message
overhead and significant energy consumption. In addition,
many approaches, including [27], are based on a single static

4
Table I
QUAL ITATIV E CO MPAR ISO N BE TWE EN X.509-ECDSA, ECQV, CL-PKC
NON E:◦◦◦, LOW:•◦◦, MEDIUM:••◦, HIGH:•••
A3SY MBO L IN DIC ATES T HE FU LFI LLM EN T OF A PART ICU LAR F EATU RE ,
A7SY MBO L DE NOTE S TH E MIS S OF T HE FE ATUR E,WHILE THE SYMBOL −
IN DIC ATES T HAT THE F EATU RE I S NOT AP PL ICA BL E.
Feature X.509-ECDSA ECQV CL-PKC
Bandwidth Overhead ••• ••◦ •◦◦
Computational Burden ••• ••◦ •◦◦
Storage Requirements ••• ••◦ •◦◦
Robustness to Information
Leakage from DA 7 7 3
Resilience to
Man In The Middle 3 3 3
Robustness to
Compromised DA 7 7 7
Robustness to
Compromised IoT node 7 7 7
Certificates Management
Overhead ••• ••• ◦◦◦
partial private key provided by the DA. This key cannot be
updated during the lifetime of the device. Thus, if this key is
leaked to the adversary, the IoT node cannot obtain new fresh
cryptographic material (we refer to this very important feature
as Ephemeral Cryptography Material in Tab. II).
In this context, the only real experimental results are avail-
able from the contribution in [25]. The authors of this valuable
contribution report average times of 12.57 seconds for each
key agreement instance, contributing to overwhelming energy
consumption, not suitable for constrained IoT devices. More-
over, the key agreement protocol reported by these authors
involves a leaf IoT device and a drone, equipped with powerful
Graphics Processing Units (GPUs). Thus, it is not suitable for
our target scenario, involving fully-autonomous IoT devices
with really constrained capabilities.
Moreover, in all the analyzed protocols, a new re-keying
operation between two devices involves a computational and
energy cost equal to the previous key establishment process,
with a resulting increased (doubled) energy consumption.
For the best of the authors’ knowledge, LiKe is the first CL-
PKC protocol to be specifically designed and implemented
to meet the stringent bandwidth, computational, and energy
requirements of IoT ecosystems. Thus, it does not require
any computationally-intensive and time-consuming pairing op-
eration, it does not rely on any persistent connection with
the Domain Authority (with large benefits in terms of mes-
sage overhead, energy consumption, and scalability), and it
provides at the same time ephemeral cryptography materials
and lightweight re-keying operations. In addition, LiKe has
been contextualized in a real IoT communication technology,
implemented, and tested via real experimentation. Finally, the
code of LiKe has been released as open-source [13]. For the
best of the authors’ knowledge, at the time of this writing, the
combination of these crucial features are not available in any
CL-PKC scheme published in the literature.
III. SYS TE M AN D ADVE RS ARY MO DE L
This section provides details about the system model and
the adversary model assumed in our work. Sec. III-A describes
the reference scenario and the assumptions, while Sec. III-B
details the adversary and its objectives.
A. System Model and Assumptions
The system model considered in our work is illustrated in
Fig. 1.
IoT Domain I
IoT Domain II
IoT Domain III
Sink
Node
Sink
Node
Sink
Node
Leaf
Node
Domain Authority
Figure 1. Reference Scenario: multiple IoT domains, managed by a unique
Domain Authority (DA), where each domain is organized in a single sink
IoT node and several leaf IoT nodes. Black lines represent intra-domain
connections, while grey lines are inter-domain connections.
The scenario includes several IoT domains, consisting of
several IoT devices (or, equivalently, nodes) spread in the en-
vironment. In each domain, the devices are logically organized
in two classes: leaf IoT nodes and sink IoT nodes.
The leaf IoT nodes (reported in Fig. 1 using the black
color) are in charge of acquiring physical information from the
surrounding environment, e.g., temperature, humidity, light,
acceleration, pressure and possibly others. These information
are transmitted to other devices in the network, up to the
reference sink node of the IoT domain. The sink node (re-
ported in Fig. 1 using the grey color) takes the role of the
aggregator of the information produced by the IoT devices in
the same IoT domain. It can achieve aggregation operations,
as well as basic data processing (including the computation of
simple statistics about the data), following the emerging Edge
Computing architectural paradigm [28]. The communication
technology used by the IoT devices to transmit and receive
information is the IEEE 802.15.4 standard, at the basis of the
new Zigbee 3.0 protocol stack [29].
Without loss of generality, we assume that the IoT do-
mains are managed by the same system administrator. This
assumption translates in trusting a single system DA, directly
connected to the unique system administrator. Without loss of
generality, we assume that the identity and the cryptography
materials related to the unique DA are pre-loaded into the non-
volatile memory of the involved devices (see Sec. VI-A for the
evaluation of the memory requirements of such a choice).
However, the proposed scheme can be easily extended to
work effectively also when multiple independent authorities
are considered. In this case, each communicating device should
provide to the remote communicating party the identity of
the specific DA to trust. At the same time, the cryptography
materials related to other DA should be also pre-loaded in the
memory of the devices.

5
Table II
COMPARISON OF LIKE AGAIN ST S TATE-OF -TH E-ART A PPR OACH ES U SIN G CL-PKC TEC HN IQU ES .
Feature [20] [21] [22] [23] [24] [25] [26] [27] LiKe
Pairing-free 3 7 3 7 3 3 3 3 3
Non-persistent Connection with Domain Authority 7 7 3 7 7 3 3 3 3
Ephemeral Cryptography Material 7 7 3 7 3 3 7 7 3
Integration in a Real IoT Enabling Technology 7 7 7 7 7 3 7 7 3
Implementation on Real IoT Devices 7 7 7 7 7 3 7 7 3
Real Performance Evaluation 7 7 7 7 7 3 7 7 3
Energy Friendly Approach -----7- - 3
Suitability for Autonomous IoT Domains 777777773
Lightweight Re-Keying 777777773
Open-Source Code 777777773
In this context, thanks to its inherent lightweight features,
the LiKe protocol proposed in this work (discussed in details
in Sec. IV) could be applied between any constrained IoT
devices, being either (i) two leaf IoT nodes, or (ii) a sink IoT
node and a leaf IoT node, whenever a secure communication
channel needs to be established. However, to take the discus-
sion at a general level, we will refer to the communicating
entities as Aand B.
It is worth noting that, in line with the Zigbee 3.0 specifica-
tion, the IoT devices within the IoT domains can be connected
at the MAC layer using any physical topology. Indeed, LiKe is
a key establishment protocol working at layer-2 of the protocol
stack. Thus, it is designed to allow any couple of neighboring
devices to agree on a shared key, to be used to secure any
message exchanged between the devices.
On the one hand, we anticipate that LiKe requires the setup
of cryptography materials by the Domain Authority only
during the Setup Phase, that is executed offline, before the
deployment of the devices. Thus, LiKe does not require
any interaction with centralized authorities during the Online
Phase.
On the other hand, working at the MAC-layer between any
couple of neighboring devices, LiKe implicitly supports any
network topology at the physical layer, being it a star network,
a chain, a tree, or a mesh topology.
Therefore, as soon as two neighboring devices discover each
other (thanks to the reception of an IEEE 802.15.4 beacon
frame), they can trigger the execution of the LiKe protocol to
agree on a session key to secure any further message exchange.
An important assumption in our work is that the devices
within the IoT network are already synchronized, and they
share a common vision of time. We clarify that ensuring
time synchronization among the devices in the IoT network
is the task in charge of a network synchronization protocol.
The synchronization protocol is typically run between two (or
more) neighboring devices at the joining time, i.e., when a
new device joins the network.
First, we highlight that the LiKe protocol proposed in this
paper is executed immediately after a device joins the network.
Thus, we assume that the neighboring devices have already
discovered each other (thanks to the transmission/reception of
a beacon frame), and that they have already run a synchroniza-
tion protocol, sharing a common view of the time. Looking
at the LiKe protocol, the specific synchronization protocol in
place between the devices can be considered out of scope,
and we only consider that a generic synchronization protocol
is running and working effectively to provide a shared vision
of the time.
However, to provide further insights, we would like to high-
light that the network can use many different synchronization
protocols, and that such synchronization protocols can be also
executed at different layers of the protocol stack, from the
MAC layer to the Application Layer.
Without loss of generality, we can assume that, as soon
as the two devices discover each other thanks to the send-
ing/reception of an IEEE 802.15.4 beacon frame, they syn-
chronize each other to a shared vision of time. For instance,
the IEEE 802.15.4 standard specification enables the syn-
chronization between a couple of neighboring devices based
on the information transmitted/received in beacon frames.
Specifically, the device transmitting the beacon frame includes
in the message a time value, indicating the number of time-
slots that elapsed from the deployment of the network and
the time when the beacon frame has been transmitted. At the
reception of the beacon, the receiving device simply aligns its
time reference to the one of the transmitting device.
We also remark that the LiKe protocol proposed in our
paper is intended to be executed between any two neighboring
devices, immediately after the two devices discover each other
thanks to the delivery/reception of beacon frames at the MAC
layer (layer-2). Thus, the specific strategies to secure the
joining operations can be considered out of scope of LiKe,
as its only responsibility is to allow two devices to establish
pairwise keys. We also highlight that the cryptographic values
exchanged between the two devices are simply included as a
payload of a standard IEEE 802.15.4 message, without any
further encryption or authentication of the message. Indeed,
as demonstrated by the automatic verification carried out
in Section V, even accessing these cryptographic values, an
adversary cannot violate the security of the protocol.
We also highlight that, despite the Zigbee 3.0 specification
recommends the transmission of packets using the Carrier
Sense Multiple Access (CSMA) scheme to access the wireless
medium, this recommendation does not conflict with the
LiKe protocol. We recall that the logic of LiKe, its security
properties, its computational requirements, and the number
of MAC-layer messages required to establish secure pairwise
session keys, only depend on the specific hardware board and

6
on the usage of the IEEE 802.15.4 communication technology
at the PHY/MAC layer. These features are independent of the
particular strategy selected to access the wireless medium.
Thus, being compatible with the IEEE 802.15.4 standard
specification, LiKe inherently supports both the CSMA and
the TSCH protocol.
Finally, it is worth noting that, in contrast with the vast
majority of certificateless schemes discussed in the litera-
ture, LiKe does assume neither any pre-deployment of the
public keys of other remote entities in the memory of the
participating devices nor any storage of such public keys on
dedicated public servers. On the one hand, this assumption
implies that the devices have to deliver their public key to
any other device they want to establish a communication
with. On the other hand, such a strategy provides memory
footprint reduction and alleviates pre-deployment efforts by
the system administrator. Given that our scenarios involve
memory and energy-constrained devices, such a choice is key
to avoid memory shortages and energy-consuming periodic
keys synchronization activities with the DA.
The notation used throughout this work is summarized in
Tab. III.
Table III
NOTATIO N SUM MA RY
Eelliptic curve group
qlarge prime number
Ga generator of Eof order n
Fqprime finite field
E/Fqelliptic curve defined over Fq
(c, C)DA master private and public key pair
IDiidentity string of the device i
nidevice nonce
tipublic key validity time period
(xi, Xi)first partial private and public key of device i
(pi, Pi)second partial private and public key of device i
Kij , Kji session key established between the devices iand j
Hcryptographic hashing function
ψkeyed-hash message authentication code function
ϕgeneric Key Derivation Function
sk preliminary session key
σiauthentication tag generated by the device i.
B. Adversary Model
In this work, we assume a very powerful adversary, char-
acterized by both passive and active features.
In detail, the adversary model assumed in our work is con-
sistent with the Dolev-Yao attacker model, used by the large
majority of contributions in the literature working on CBKE
[30], [31].
According to the Dolev-Yao attacker model, the adversary can
eavesdrop all the communications between any two involved
devices, by simply tuning its radio on the same frequency and
channel used by the target devices, independently from the
selected communication technology. In addition, the adversary
can transmit its own messages, either replaying messages
previously eavesdropped on the communication channel, or
forging new ad-hoc messages, impersonating any party in the
system.
Thanks to these powerful features, the adversary aims to
access to messages exchanged between IoT devices, and/or
to impersonate any of the two parties in the key agreement
protocol, thus being accepted as a legitimate entity in the
network (i.e., achieving an impersonation or a Man-In-The-
Middle attack).
On top of this (widely accepted) adversary model, we add
a new, powerful feature. Specifically, we assume that the
adversary can have access also to all the nodes’ information
available on the DA. These information include the crypto-
graphic values provided by the IoT nodes to the DA during
the setup phase of the key agreement protocol.
Note that this is a typical situation in the field, verifiable when
attackers can steal secret nodes’ information from the DA,
without fully compromising its role in the network [32].
Thus, on the one hand, the adversary model assumed in
our work is consistent with a widely accepted model in the
literature, which is the Dolev-Yao attacker model. On the other
hand, this basic adversary model is further enriched with an
additional powerful feature, being stronger than the majority
of works currently available in the literature.
In line with the current literature, we also assume that the
adversary cannot access the local secret values of the DA and
the IoT devices in the network. Indeed, this is consistent with
the adversary models assumed in the large majority of con-
tributions working with Certificate-Based Key Establishment
(CBKE) and Certificate-Less Public Key Cryptography (CL-
PKC). Indeed, it is a remote adversary, that does not have the
physical access to the IoT device and cannot obtain its full
private key. It is also in line with a typical IoT and Industrial
IoT scenario, where the adversary typically attacks the network
from the public Internet, without having physical access to the
IoT devices.
On the one hand, the physical protection of the IoT device can
be considered out of the scope of the present contribution. On
the other hand, LiKe can be integrated with additional dedi-
cated strategies, specifically tailored to protect the secrets of an
IoT device (e.g., the private key) from a physical compromise
[33]. We refer the interested readers to the contributions in
[34] and [35] for more details on hardware security for IoT
devices.
IV. THE LIKEPROTOCOL
In this section, we provide the details of the LiKe scheme,
proposed to allow constrained devices to establish a session
key to be used for secure communications. Overall, LiKe
involves two different phases: a pre-deployment phase (de-
scribed in Sec. IV-A) and a key agreement phase (described
in Sec. IV-B). Further considerations on re-keying operations
will be finally provided in Sec. IV-C.
A. Pre-Deployment Phase
In the pre-deployment phase, each device participating in
the system interacts securely with the DA, to receive dedicated
cryptography elements. Without loss of generality, we assume
that this phase is performed directly by the manufacturer of
the device, before their effective deployment.

7
The flow of the interactions between the DA and a generic
device iis depicted in the following Fig. 2.
ωi
pi , Pi
Generation of partial keys pi ,Pi
Key
Validation
piG = Pi+ hiC
Domain
Authority
Device i
Figure 2. LiKe: Sequence Diagram of the Setup Phase.
At the boot-up of the system, the system administrator
establishes the public parameters of the system, enforced by
the DA. They include:
•the elliptic curve group E;
•the generator G∈ E of order nof the group E;
•the elliptic curve E/Fqover a prime finite field Fq;
•the cryptographic hashing function H:{0,1}∗→Z∗
n;
•the keyed-hash message authentication code function ψ;
•the Key Derivation Function (KDF) ϕ.
Then, the DA computes its own private and public key pair.
Specifically, starting from a k-bit prime number q, the DA
generates its own private key c∈Z∗
n, and its own public key
as C=cG. Finally, it makes publicly available the public
system parameters, as params={Fq, E/Fq,E, G, C, H, ϕ, ψ}.
Let us assume that the generic device ineeds to be equipped
with cryptography elements necessary to establish secure
session keys with communicating devices. The device (or the
user acting on its behalf) extracts a random value xi∈Z∗
n,
and sets this value as the first (fully secret) part of its private
key. The corresponding first part of its public key is computed
as Xi=xiG.
Then, the device icomputes the following two elements: (i)
an identity string IDi∈ {0,1}∗, representing its identity on
a string, and (ii) a time period ti∈ {0,1}∗, representing the
desired validity time of its public key.
Then, the device icomputes the string ωi, as in the
following Eq. 1, and it provides the string to the DA.
ωi= (IDiktikXi).(1)
The DA first checks that the desired time validity requested
by the user is consistent with the system-level security require-
ments. If this is valid, it considers tias the target time validity,
otherwise, tiwill be set to a default value established by the
DA. We remark that the time validity period tiof the partial
private key delivered by the authority should be set as short
as possible, e.g., it can be equal to the battery lifetime. It is
worth noting that establishing a time-limited validity is crucial
in case the key material is leaked or somehow compromised.
In such a case, its limited time-validity poses a time limit on
its persistent usability.
Then, the DA generates the correspondent second part of
the private key for each device ias follows:
1) The DA selects a random value ri∈Z∗
n, computes its
projection on the elliptic curve as Pi=riG, and then
computes hi=H(ωikPi).
2) The DA computes the value pi=ri+hicmod n.
3) The DA delivers to the device the second partial private
key piand the second partial public key Pito the device
i.
When the device ireceives the private key, it can verify
the authenticity of the received information by verifying the
following equation Eq. 2:
pi·G=Pi+hi·C(2)
If the above relationship is verified, the key can be consid-
ered authentic and correctly generated by the DA. Thus, the
device can set its full private key as ski= (xi, pi)and its full
public key as pk = (Xi, Pi).
It is important to remark that, as a novel contribution
of LiKe, the inclusion of Xiin the string ωiallows to
uniquely bind the part of the public key self-generated by
the device to the device itself. Such a strategy prevents any
possible impersonation attack that could be carried out when
the information available on the DA are compromised. More
details will be provided in Sec. V.
B. Key Agreement Phase
Without loss of generality, we assume that some crypto-
graphic elements are pre-configured in each device by the
network administrator before the physical deployment. These
include all the values previously defined in params, as well as
the public key Cof the DA.
The rationale of the LiKe scheme consists of the exchange
of four different logical messages, two per each involved
device. The first two messages, one per participating device,
are dedicated to the exchange of the cryptography materials,
including the public keys of the devices. The public key
received by the remote device is then used to generate a shared
secret, namely the Preliminary Session Key, according to the
well-known Elliptic Curve Diffie Hellman (ECDH) scheme.
The last two messages, instead, one per each device, allow
any of the two entities to verify the authenticity of the remote
party and to establish a unique session key, that will be used
to protect messages delivered on the wireless communication
channel.
Given that the communicating devices are directly con-
nected, we assume that LiKe is integrated at layer-2 of
the protocol stack, and in particular as a payload of the
IEEE 802.15.4 communication technology, standardized as the
reference MAC-layer of the Zigbee 3.0 protocol suite. Thus,
the cryptography elements delivered in each of the messages
are assumed to be integrated into the layer-2 payload of the
message.
Let us assume two generic constrained devices Aand B.
Concerning the scenario discussed above, they can be either

8
Generation of
PreMaster Session Key
KAB
Generation of
PreMaster Session Key
KBA
Generation of
Preliminary Session
Key sk
Generation of
Preliminary Session
Key sk
Peer Authentication
Peer Authentication
Generation of Session
Link Key Lk
Generation of Session
Link Key Lk
Device A Device B
1. ωA, PA, nA
2. ωB, PB, nB
3. σA
4. σB
Figure 3. LiKe: Sequence Diagram of the Key Agreement Phase.
two leaf IoT devices, or a leaf IoT node and a sink IoT node.
To establish a secure communication channel, the two devices
require a fresh session key. To this aim, they run the key
agreement protocol depicted in Fig. 3 and described below:
1) The device Agenerates the first message of the
protocol (Message #1), including the string ωA=
(IDAktAkXA), the second part of the public key PA,
and a random nonce nA. Then, it delivers this message
to the IoT device B.
2) On receiving this message, the device Bchecks the time
consistency of the received data, i.e., it verifies that the
time validity tAincluded in the string ωAis posterior to
the current time t, i.e., tA> t. If this preliminary step
is successful, the device Bstores locally the received
values. Then, it replies with a new message (Message
#2) including the string ωB= (IDBktBkXB), the
second part of the public key PB, and a random nonce
nB.
3) On receiving this message, the device Achecks the time
consistency of the received data, i.e., it verifies that the
time validity tBincluded in the string ωBis posterior to
the current time t, i.e., tB> t. If this preliminary step is
successful, the device Bstores the received parameters.
Then, it computes a preliminary key value, composed by
two parts, as KAB =KAB,1kKAB,2, as in the following
Eqs. 3 and 4.
KAB,1=pA(PB+H(IDBktBkXBkPB)C)
=pA(rBG+hBcG)
=pA(rB+hBc)G
=pApBG
(3)
KAB,2=xAXB=xAxBG(4)
4) Then, the same device Acan compute a preliminary
session key, as in the following Eq. 5.
sk =skAB =ϕ(KAB )(5)
The function ϕis a Key Derivation Function, used to
create a key from a bit-string. The device Astores the
preliminary session key skAB in a local Key Table, for
further usage (see Sec. IV-C for more details).
5) The device Aprepares an authentication message. As-
suming ψis a keyed-hash message authentication code
function, the device computes an authentication tag σA,
using the preliminary session key sk, according to the
following Eq. 6.
σA=ψ[sk, (ωA, PA, ωB, PB, nA, nB)] (6)
Then, the device Adelivers the authentication tag as the
layer-2 payload of a message (Message #3), using the
session key sk previously computed as the encryption
key.
6) The device Bexecutes similar operations. It computes
the preliminary key value, composed by two parts, as
KBA =KBA,1kKB A,2, as in the following Eqs. 7 and
8.
KBA,1=pB(PA+H(IDAktAkXAkPA)C)
=pB(rAG+hAcG)
=pB(rA+hAc)G
=pBpAG
(7)
KBA,2=xBXA=xBxAG(8)
7) Then, the device Bcan compute a preliminary session
key, using the preliminary session key sk, as in the
following Eq. 9.
sk =skBA =ϕ(KBA )(9)
The device Bstores the preliminary session key sk =
skBA in a local Key Table, for further usage (see Sec.
IV-C for more details).
8) At the reception of the authentication tag σAfrom the
device A, the device Bcan verify its authenticity, by
re-computing it locally and verifying the following Eq.
10.
σ0
A=ψ[sk, (ωA, PA, ωB, PB, nA, nB)] = σA(10)
If the value σ0
Acomputed locally matches the value σA
received from the remote device, Bcan safely assess that
it is indeed communicating with Aand that its public
key is authentic, i.e., it has been generated by the DA.
Thus, if the above check is successful, Bproceeds on
with the next steps of the protocol. Otherwise, it stops
its execution and aborts the session.
9) The device Bprepares the respective authentication
message. Assuming ψis a keyed-hash message au-
thentication code function, the device Bcomputes an
authentication tag σB, using the preliminary session key
sk, according to the following Eq. 11.
σB=ψ[sk, (ωB, PB, ωA, PA, nB, nA)] (11)
Then, the device Bdelivers the authentication tag as the
layer-2 encrypted payload of a message (Message #4 ),
using the session key skBA previously computed as the
encryption key.

9
10) At the reception of the authentication tag σBfrom the
device B, the device Adecrypts the authentication tag
σB, by using the preliminary session key skBA, and
thus it can verify the authenticity of the communicating
party, by re-computing the tag locally and verifying the
following Eq. 12.
σ0
B=ψ[sk, (ωB, PB, ωA, PA, nB, nA)] = σB(12)
If the value σ0
Blocally computed matches the value σB
received from the remote device, Acan safely assess that
it is indeed communicating with Band that its public
key is authentic, i.e., it has been generated by the DA.
Thus, if the above check is successful, Aproceeds on
with the next steps of the protocol. Otherwise, it stops
its execution and aborts the session.
11) Finally, both the devices can generate the same (authen-
ticated) Session Link Key Lk, according to the following
Eq. 13.
Lk=ϕ(KAB knAknB) = ϕ(KBA knAknB)
(13)
The Session Link Key will now be used as the encryp-
tion and decryption layer-2 key for all the messages
exchanged by the communicating entities during the
current session.
C. Considerations on Re-Keying Operations
The protocol flow previously described is fully executed
when the devices Aand Bneed to exchange data for the first
time. Indeed, as the two devices never exchanged data before,
none cryptography materials could have been shared.
When the two devices need to establish a new session, a
Re-keying operation is necessary to establish a new session
key. Re-keying operations can be either synchronous or asyn-
chronous. Synchronous re-keying operations can be scheduled
at will by the network administrator, based on the time validity
of the established session keys, trading off between security,
usability, and energy consumption. In the most secure setup,
the network administrator could decide to schedule re-keying
operations every time a device needs to deliver a message
to the other one. In this case, any time a message needs to
be sent, an instance of the key agreement protocol should
be run, resulting in the establishment of a new session key.
Indeed, despite being the most secure configuration, this setup
is also the most energy-consuming, resulting in the triggering
of a new instance of the key establishment protocol for each
message delivery. Alternatively, the network administrator
could decide to schedule re-keying operations on a daily basis,
i.e., every time 24 hours elapsed from the last key agreement
instance. In this setup, the devices could gain energy, reducing
the security level. Overall, based on the requirements of the
particular scenario, the network administrator should decide
the time validity of the session keys, thus establishing the time
when re-keying operations should happen.
Asynchronous re-keying operations can be triggered by the
network administrator in special situations, outside the reg-
ular maintenance schedule. For instance, when the network
administrator is informed about the leakage of the specific
session key on an IoT device, or about an ongoing attack
targeting the session key of a specific IoT device, it can trigger
asynchronous re-keying operations to update the cryptographic
material.
However, note that a new run of LiKe leads to the generation
of the same preliminary session key, as its computation does
not involve any new cryptographic value. On the one hand,
this property does not break the security of the protocol, as
the new session key will be generated using the two fresh
nonces exchanged in the new key agreement phase. On the
other hand, in the re-keying, the two devices can skip the
computations that start with the reception of the cryptography
elements of the remote device and end with the generation
of the preliminary session key, leveraging values previously
computed and stored in the local keys table. The best option
is to save this cryptographic value in the Non-Volatile Random
Access Memory (NVRAM). In this way, even in case the
device reboots, the preliminary key value previously negotiated
remains available to the device.
The above property allows gaining significant time, and
energy, contributing to make the whole scheme a lightweight
and fast re-keying agreement technique.
We remark that the two devices still need to exchange the
first two messages of the protocol, as the new nonces included
in the respective messages will be crucial for the generation
of a fresh and secure session key.
V. SECURITY CONSIDERATIONS
In this section, we discuss the most important security
aspects of LiKe. In Sec. V-A we summarize the most important
security properties provided by LiKe, while Sec. V-B describes
the automatic formal security verification of the protocol
conducted using the ProVerif tool.
A. Security Properties
LiKe achieves the security properties listed below.
Protection Against Leakage of Secret DA Information.
The self-generated portion of the public key of each device
is now bound to the identity of the generating party, via the
string ωi. This smart feature is particularly useful when the
information available on the DA are leaked to an adversary.
Indeed, even if the adversary could know the partial private key
of one of the two devices, it could not be able to impersonate
any of them, being not aware of the remaining part of the
private key [36].
To provide further insights, let us assume a scenario where
the secret information of the IoT devices (i.e., their private
keys) are created and stored on the DA, and they are leaked
to the adversary (see, for instance, the case discussed in [32]).
At the same time, let us assume that the adversary only has
access to these information (e.g., by temporary reading or
stealing the file), while it cannot get the private key of the DA,
and neither its full control. Assuming the above-introduced
challenging scenario, legacy certificate-based schemes (e.g.,
using X.509-ECDSA, and ECQV certificates) cannot continue
to guarantee the security of the communications between IoT
devices. Indeed, given that the security of the session keys

10
generated between the devices using these schemes is fully
based on the secrecy of the private keys, looking at the
message exchange, the device can both reconstruct the session
keys and impersonate any of the two devices in the network.
Instead, when LiKe is adopted, being the full private key of the
device composed by a part that is not known by the DA, the
adversary still does not have the full information necessary to
reconstruct the session keys already established or to predict
future session keys that will be negotiated by the devices in
the network.
Thus, any tampering attempt by a malicious device would
lead the two communicating parties to compute different
preliminary session keys, thus causing irrecoverable errors
when the authentication tags are exchanged and verified. Such
powerful security features have been also formally verified via
ProVerif (see Sec. V-B).
Ephemeral Cryptography Materials. A time validity pe-
riod ti, set as short as possible, can now be uniquely associated
with the cryptography elements released by the DA. Indeed, if
the legitimate entity continues to use the public key beyond the
intended time validity period, it can be immediately detected
by any remote party involved in the proposed key agreement
protocol. Further, any local malicious modification of such
validity time can be immediately detected, as the unique
relationship between the string ωiand the related public key
would not be verified, anymore.
Protection Against Man-in-the-Middle Attacks. LiKe
binds the partial public keys to its owner in a trusted fashion.
This makes LiKe robust against Man-in-the-Middle (MITM)
attacks, as any party would need the private portion of the
public key of a given entity to fully emulate its identity.
Moreover, in the second part of LiKe, two authentication
messages are exchanged, involving all the data exchanged in
the previous communications. This is inspired by the Finished
messages in the Transport Layer Security (TLS) protocol, and
the effectiveness of this strategy to protect against MITM and
tampering attacks can be provided via the same proofs already
performed for the TLS protocol [37]. The formal verification
of this property has been also provided by using the ProVerif
tool (see Sec. V-B).
Protection Against Replay Attacks. Despite the prelimi-
nary session key remains the same across different instances
of LiKe, fresh nonces are generated ex-novo any time. In
fact, they guarantee effective verification of the identity of
the devices and generation of new session keys per each
new protocol instance, protecting against any replay attack.
Thus, any replay of old messages will lead the two devices
to compute wrong authentication tags (see Sec. V-B for the
formal verification of this property).
Protection Against Known-Key Attacks. Each run of
LiKe produces a unique session key, based on the preliminary
session key and the fresh nonces. As a consequence, even
if a malicious entity can compromise a session key, it is
not able to re-compute the private keys of the legitimate
entities, as it is assumed that it is not able to solve the well-
known Elliptic Curve Computational Diffie-Hellman Problem
(ECCDHP) and the Elliptic Curve Discrete Logarithm Problem
(ECDLP). Thus, a new re-keying operation will nullify the
efforts of the adversary, which will have to find out the new
key from scratch.
Considerations on Energy-Depletion Attacks. The LiKe
protocol can detect the presence of a malicious party in the key
establishment process only after the exchange of the Messages
#3 and #4 of the protocol (see Fig. 3), i.e. at the steps
no. 8and 10. In some setup, this could make the protocol
more exposed to energy-depletion attacks, where the adversary
engages the legitimate IoT device in several unsuccessful
instances of the LiKe protocol. Assuming kis the number of
instances initiated by the malicious IoT device, the legitimate
IoT device would realize the presence of the attacks only after
sending/receiving 2·klogical messages, with a linear increase
to the number of instances. This vulnerability can be mitigated
through smart implementation techniques, e.g., by rejecting a
request to start the LiKe protocol from a particular device after
a given number of unsuccessful instances— in typical server
processes, this number is fixed to 3unsuccessful instances. At
the time of this event, an alarm could be emitted by the target
device, calling for further investigation.
However, as will be shown in Section VI, we highlight
that the number of MAC-layer messages (directly connected
to the energy consumption) required when using the LiKe
protocol before detecting an attack is not higher than the
number of messages required to detect such an attack when
using other Public Key Cryptography (PKC) schemes, such as
X.509-ECDSA certificates, and ECQV implicit certificates. In
fact, as will be experimentally demonstrated in Section VI,
considering an elliptic curve group size of 256 bits, when
using the CBKE-ECQV scheme, an IoT device could reject
an instance of the key agreement protocol (thus detecting an
attack) after the exchange of 2messages, while 9messages
need to be exchanged at the MAC-layer to reject a request
when using the CBKE-ECDSA scheme. When using LiKe, a
device can reject a request after receiving 2messages at the
MAC-layer. Thus, the inclusion of the LiKe protocol does not
increase the minimum number of messages to be exchanged at
the MAC layer to detect an attack. Therefore, we can conclude
that the adoption of the LiKe protocol is neutral compared
to the sensitivity of a key agreement scheme against energy-
depletion attacks.
B. Formal Verification using ProVerif
The most important security objectives achieved by LiKe
have been formally evaluated using the automated tool
ProVerif [38], developed by researchers at Inria and widely
used in the recent literature to formally verify the security of
cryptographic protocols [39], [40], [41].
Assuming that: (i) the cryptographic primitives used in the
protocol are inherently robust; and, (ii) the attacker knows the
algorithm and specific cryptography values, ProVerif enables
the formal verification of any security protocol against a
powerful attacker, able to read, modify, delete, and inject
messages on the communication channel (consistent with the
Dolev-Yao attacker model). In case an attack is found, ProVerif
also lists the steps needed by the attacker to violate the desired
security feature.

11
The LiKe protocol has been implemented in the ProVerif
tool, and four main events have been identified:
•begin_LiKe_A: indicating that node B is requested to start
an instance of the LiKe protocol by a requesting entity
identified as node A;
•begin_LiKe_B: indicating that node A is requested to start
an instance of the LiKe protocol by a requesting entity
identified as node B;
•end_LiKe_A: indicating that node A completes success-
fully an instance of the LiKE protocol with an entity
identified as node B;
•end_LiKe_B: indicating that node B completes success-
fully an instance of the LiKE protocol with an entity
identified as node A.
In addition, we recall that ProVerif provides the following
output:
•not attacker(elem[]): meaning that the attacker is not in
possession of the value of elem;
•attacker(elem[]): meaning that the attacker is in posses-
sion of the value of elem;
•inj-event(last_event ()) ==> inj-event(previous_event ())
is true: meaning that the function last_event is executed
only when another function, namely previous_event is
really executed;
•inj-event(last_event ()) ==> inj-event(previous_event ())
is false: meaning that when the function last_event is
executed, it is not always true that the function previ-
ous_event has been executed before.
We conducted two different tests to validate the security
features offered by the LiKe protocol. The output of the
ProVerif tool in the two cases, when executed on a local
machine, is shown in Fig. 4.
(a) Test 1: Security Verification of LiKe when the private keys of the involved
devices are assumed to be secret.
(b) Test 2: Security Verification of LiKe when the partial private keys of
the involved devices maintained by the DA are assumed to be leaked to the
adversary.
Figure 4. Screenshots of the output provided by the ProVerif automatic tool.
In the first test, namely LiKe_test_1, we assumed that all the
partial private keys of the nodes, including both the ones in
possession of the DA (i.e., pA[] and pB[]) and the ones stored
locally on the devices (i.e., xA[] and xB[]) are kept secret, as
shown in the lines 1-2-3-4of Fig. 4(a). With this configuration,
we notice that: (i) the device B ends successfully the protocol
only when the device A started it, and (ii) the device A ends
successfully the protocol only when the device B started it.
Thus, the two devices A and B are mutually authenticated.
The positive outcome of these two queries verify the security
of the LiKe protocol against Man-In-The-Middle and replay
attacks, contemplated by the Dolev-Yao attacker model in the
ProVerif tool.
In the second test, namely LiKe_test_2, we assumed that the
partial private keys of the devices stored on the DA (i.e., pA[]
and pB[]) are leaked to the adversary, as shown by the output
not attacker(pA[]) is false at line 1 and not attacker(pB[]) is
false at line 2in Fig. 4(b). Even assuming this challenging
scenario, LiKe continues to guarantee security and robustness
against any impersonation attack, such as Man-In-The-Middle
and replay attacks, as depicted by the output at lines 5-6of Fig.
4(b). In fact, the secrets stored locally on the two devices still
contribute to identifying uniquely the participating entities.
The successful output of this test formally verifies the security
of the LiKe protocol in the scenario where nodes’ information
stored on the DA are leaked to the adversary.
The source code of the LiKe protocol in the ProVerif tool
has been also released as open-source [13], to allow interested
readers to verify our claim and further use our code as a ready-
to-use basis for their software protocol verification.
VI. PE RF OR MA NC E EVALUATI ON
We implemented the LiKe protocol using real IoT devices,
and we tested its performance, in terms of message overhead
and energy consumption, in dense IoT networks including
up to 11 IoT nodes. The details of the implementation are
provided in Sec. VI-A, while considerations about the time
required by the protocol to complete and its energy con-
sumption are reported in Sec. VI-B. Sec. VI-C offers the
comparison between LiKe and baseline CL-PKC approaches
and, finally, Sec. VI-D reports the experimental comparison of
LiKe against standardized approaches used in the Zigbee 3.0
protocol suite.
A. Implementation Details
The LiKe protocol has been implemented using real IoT
devices, i.e., the OpenMote-b hardware platform. This is a
state-of-the-art IoT board, used for real experimentation and
rapid prototyping of IoT algorithms and solutions [42], [43].
The hardware platform features a CC2538 System on Chip
(SoC), 32 MHz ARM Cortex M3 processor, 512 kB of ROM
and 32 kB of RAM.
As for the operating system, we selected the OpenWSN
operating system, consistently with other related work on IoT
security [19], [44] [45], since it integrates a slotted channel
access mechanism and the IEEE 802.15.4 standard operating
in the TSCH mode, used as the PHY and MAC layer of the
Zigbee 3.0 protocol suite [46].
The LiKe protocol has been implemented at the MAC layer
(i.e., layer-2), and integrated within the IEEE 802.15.4 MAC.
We recall that the IEEE 802.15.4 communication technology
requires the exchange of packets having a maximum size of
127 bytes. Thus, when the protocol requires larger informa-
tion to be exchanged within communicating nodes, message
fragmentation is required.
As a powerful feature, the CC2538 within the OpenMote-b
includes a crypto-processor, able to execute atomic big number

12
modular and Elliptic Curve Cryptography (ECC) operations,
using hardware accelerators. We implemented software rou-
tines that efficiently combine and orchestrate these atomic
operations to provide advanced cryptographic operations, such
as the one required by LiKe and competing approaches. As for
the cryptographic curves used in our experimental evaluation,
we have used the elliptic curves secp160r1,secp192r1, and
secp256r1. These curves are publicly recognized as secure
by the scientific community, and they all achieve a security
level equal or higher than the minimum acceptable security
level assumed for an ECC curve, fixed at 80 bits [12]. As a
strengthening feature, the CC2538 crypto-processor also pro-
vides enhanced protection against physical-layer timing-based
attacks against ECC operations, implementing via hardware
the Montgomery Ladder technique, widely recognized as a
valid technique to defeat side-channel attacks.
As for the supporting cryptographic operations, we used the
HMAC-SHA hardware function provided by the CC2538 as
the hashing function, while the well-known P1363 KDF has
been used to translate a string into a key of a given length
[47]. To evaluate the time duration of any hardware/software
operation, we used the built-in 32 MHz clock provided by
the CC2538 SoC, recording the starting and ending time
of the operations via dedicated software instructions. As for
the energy consumption, we used an oscilloscope Keysight
InfiniVision DSOX2012A, equipped with two input channels
a resolution bandwidth of 100 MHz, by sampling the voltage
drop to the terminals of a 1Ω probe resistor, bridging the pins
in series with the CC2538 chipset. The oscilloscope has been
set with a vertical resolution of 8bits, a vertical range of 50
mV/div, and a horizontal range of 1ms/div. Figure 5 shows
our experimental testbed.
Figure 5. Our real proof-of-concept, using the OpenMote-b hardware plat-
forms, a laptop for managing the IoT network, and the oscilloscope used for
the energy consumption evaluation.
As a novel result, we report in the following Figs. 6 and 7
the time needed to complete each atomic hardware operation
on the OpenMote-b hardware platform, as well as the energy
consumption of each operation.
It emerges that, independently from the selected elliptic
curve size, the most time-consuming operation is the Elliptic
Curve Point Multiplication, requiring from a minimum time
Elliptic Curve Addition
Elliptic Curve Multiplication
HMAC-SHA
Modular Addition
Modular Division
Modular Multiplication
10-2
10-1
100
101
102
Average Time [ms]
secp160r1
secp192r1
secp256r1
Figure 6. Average Time required to execute the cryptographic operations on
the OpenMote-b hardware platform, with different size of the elliptic curve.
Elliptic Curve Addition
Elliptic Curve Multiplication
HMAC-SHA
Modular Addition
Modular Division
Modular Multiplication
101
102
103
104
Energy Consumption [mJ]
secp160r1
secp192r1
secp256r1
Figure 7. Energy Consumption of the cryptographic operations on the
OpenMote-b hardware platform, with different size of the elliptic curve.
of 58.72 ms when the secp160r1 curve is used up to a
maximum time of 109.3ms when the secp256r1 curve is used.
The HMAC-SHA algorithm always requires 2.53 ms, and
the Elliptic Curve Addition varies between 1.44 ms and 2.75
ms. Finally, we notice that the modular operations are more
lightweight, requiring always less than 0.05 ms to complete.
As for energy consumption, we notice that the amount
of energy required to complete a given operation is not
always dependent on the time required to complete it. In
fact, while the most energy-consuming operation is always
the Elliptic Curve Multiplication (requiring 5,582 mJ, 7,939
mJ, and 11,045 mJ using the secp160r1,secp192r1, and the
secp256r1, respectively), increasing the size of the elliptic
curve for the other operations always lead to similar values
of the energy consumption, equal to approximately 244 mJ.
In its complete fully-fledged version, the LiKe protocol
requires only 13.594 kB of ROM and 960 bytes of RAM,
thus occupying about the 2.65% of the devices’ ROM and a
negligible portion of the available RAM. The source code of
the implemented protocol has been released as open-source
[13], to further push the innovation, as well as to allow
researchers and academia to further use our code as a ready-
to-use basis for further software development.

13
B. Evaluating the LiKe Protocol
Figure 8 provides a simplified temporal diagram of the LiKe
protocol on the OpenMote-b hardware platform, configured
with the elliptic curve secp160r1, where the reported time
duration have been averaged over 10 independent protocol
executions.
We notice that the average time required for two devices
to complete the LiKe protocol is about 340.478 ms, where
243.392 ms are required for the first phase of the protocol (up
to the generation of the DH key), while the remaining 97.086
ms are required to exchange the authentication materials and
compute the final Session Key. We highlight that the overall
duration of the protocol can be severely affected by the
configuration of the schedule of the OpenWSN operating
system at the MAC layer, i.e., the number of slots available
for RF operations in a time unit. For the tests reported in Fig.
8, we used the default slot duration of 10 ms recommended
by the IEEE 802.15.4 standard specification, with a slot-frame
duration of 11 slots and 5slots available for transmission and
reception operations on the 2.4GHz frequency band. Thus, the
average time required to transmit a packet from a device to
the other is set to 30 ms (the average between the best case, 0
ms, and the worst case, 60 ms). As expected from the analysis
reported in Fig. 6, the most time-consuming operation is the
Elliptic Curve Multiplication, taking 61.86 ms on the devices.
We highlight that, when a re-keying operation is required,
a significant amount of time can be gained. In fact, all the
cryptographic operations required in the first phase do not need
to be executed (indeed, cryptography elements do not change),
and thus a significant of time and energy can be saved. Overall,
in case of a re-keying operation, the time necessary to compute
a new session key reduces to 157.818 ms, further reducing the
overhead of the LiKe protocol.
To provide further insights, we also measured the time
needed to complete the LiKe protocol in a dense IoT network,
comprising up to 11 nodes. To decrease the RAM requirements
on constrained IoT devices, we set up the protocol in a way
to handle maximum a single instance of the LiKe protocol per
time, completed on a First-Come First-Served (FCFS) basis.
As the physical topology of reference, we considered the
star topology, i.e., a single sink IoT node and several leaf IoT
nodes in direct visibility with the sink.
Fig. 9 reports the needed for each all the nodes in the
network to set up a session key with its preferred neighbor,
while increasing the number of leaf IoT nodes from 1to 10.
The tests have been repeated 100 times, and we report the
mean value and the 95% confidence intervals.
Overall, the time needed by LiKe to complete the setup
of the session keys for each device in the networks grows
proportionally with the number of devices. This is expected,
given that the sink IoT node can be involved in only a single
LiKe instance per time. In the worst case, where up to 10 leaf
nodes are deployed (total of 11 nodes in the network, including
the sink IoT node), the time required for all the nodes to have
a secure session key with the sink IoT node is 3.259 seconds,
that is indeed a viable overhead in the scenario assumed in
our work.
We remark that the results reported in Fig. 9 are valid also
in the case of a physical chain topology, where there is a single
sink IoT node, and several leaf IoT nodes connected one to
the other in a chain, with only one leaf node connected to
the sink. Indeed, to find an optimum balance between energy
consumption and throughput of the network, assuming the
scenario described in Sec. III-A, each leaf IoT device should
be configured to accept an incoming request to start an instance
of the LiKe protocol only if it has previously negotiated a
session key with its preferred neighbor, towards the sink IoT
node. Otherwise, data packets directed towards the sink node
would be transmitted over at least one unsecured link, leading
to an insecure network. Thus, as obtained for the star topology,
each device should be involved in a single instance of the LiKe
protocol and the time needed to set up a fully secure network
will increase linearly with the number of nodes in the chain.
C. Performance Comparison with other CL-PKC schemes.
In this section, we compare the performance of the pro-
posed LiKe protocol with other CL-PKC schemes described
in Section II-B, with reference both to main computational
requirements and time required by other CL-PKC schemes.
We highlight that our comparison considers the main
sources of computational efforts by the participating devices,
i.e., the number of ECC point addition, ECC point mul-
tiplication, pairing, hashing, and exponentiation operations.
Lightweight operations, such as modular addition and multipli-
cation operations, being less demanding (as shown in Fig. 6),
are neglected.
The summary of our comparison is reported in Tab. IV,
with reference to the number of operations to be executed
per involved device. Note that, when used, nrefers to the
number of nodes in the network. Overall, LiKe emerges
as a lightweight solution, scalable with the number of IoT
devices, and being characterized by a limited amount of
ECC point addition, ECC point multiplication, hashing, and
exponentiation operations. In addition, LiKe does not require
any pairing operation, hence being suitable for the integration
in computationally-constrained IoT devices.
To provide further insights, we also compared LiKe against
three baseline CL-PKC approaches, i.e., [23], [20], and [26]—
with reference to the duration of the authenticated key agree-
ment protocol.
These baseline approaches were selected based on their
distinctive features. The approach in [23] includes both pairing
operations and interactions with the DA; the scheme described
in [20] includes none pairing operations, but it requires online
interactions with the DA; and, finally, [26] includes neither
pairing operations nor interactions with the DA.
To enable the comparison, we took into account the protocol
flow of the reference approaches. In addition, we considered
as the time duration of the particular operation the one exper-
imentally measured in the target hardware board, as reported
in Fig. 6. As for the duration of the pairing operation, as
experimentally verified by the authors in [48], we assumed
that the related time duration is 24 times higher than the
cost of a regular ECC point multiplication. The overview of

14
Preliminary Session
Key Generation: 243.392 ms
Mutual Authentication and
Session Key Generation: 97.086 ms
LiKe Protocol Duration: 340.478 ms
Verify σ`A = σA : 15 ms
RX Msg. 1: 0.366 ms
Prepare Msg. 2: 0.366 ms
RX Msg. 2: 0.366 ms
Compute H(IDB||tB||XB||PB)C: 61.86 ms
Compute PB+ H(IDB||tB||XB||PB)C: 1.44 ms
Compute pA(PB+ H(IDB||tB||XB||PB)C): 59.68 ms
Compute xAXB: 59.68 ms
Compute σA: 3.354 ms
Prepare Msg. 1: 0.366 ms
TX Msg. 2: 30 ms
TX Msg. 1: 30 ms
RX Msg. 3: 0.366 ms
Verify σ`B = σB: 15 ms
Compute Lk: 18 ms
TX Msg. 4: 30 ms
Device A
Device B
t [ms]
Compute H(IDA||tA||XA||PA)C: 61.86 ms
Compute PA+ H(IDA||tA||XA||PA)C: 1.44 ms
Compute pB(PA+ H(IDA||tA||XA||PA)C): 59.68 ms
Compute xBXA: 59.68 ms
Compute σB: 3.354 ms
TX Msg. 3: 30 ms
Prepare Msg. 3: 0.366 ms
Prepare Msg. 4: 0.366 ms
RX Msg. 4: 0.366 ms
Compute Lk: 18 ms
t [ms]
Figure 8. Temporal diagram of the LiKe protocol. The operations identified with black rectangles can be skipped at the re-keying time, operations identified
with dark grey rectangles cannot be skipped at the re-keying time, while operations identified with light grey rectangles are management and RF operations.
Table IV
PERFORMANCE COMPARISON OF LIKE AGAIN ST S TATE-OF -THE -ART A PPR OACH ES U SIN G CL-PKC TEC HN IQU ES .
Scheme ECC Point
Addition
Operations
ECC Point
Multiplication
Operations
Pairing
Operations
Hashing
Operations
Exponentiations
[20] 35020
[21] 00124
[22] 1 5 + 4n0 2 0
[23] 02110
[24] 66040
[25] 2 10 0 8 0
[26] 16040
[27] 4n4(n+ 2) 0 5 0
LiKe 13050
Table V
COMPARISON BETWEEN LIKE AND RE FE REN CE CL-PKC TE CH NIQ UE S IN TE RM S OF TH E TI ME DU RATI ON OF T HE AU THE NT ICATE D KE Y AGR EEM EN T.
Scheme Key Agreement Time (ms)
Elliptic Curve Group Size
160 bit
Elliptic Curve Group Size
192 bit
Elliptic Curve Group Size
256 bit
[23] 1811.660 2312.202 3127.075
[26] 798.566 1038.960 1416.740
[20] 585.503 682.832 842.464
Like 340.478 406.080 500.980

15
01234567891011
Number of Leaf Nodes
0
0.5
1
1.5
2
2.5
3
3.5
Time [s]
Mean
Confidence Interval
Figure 9. Time to setup session keys at the MAC layer in a reference IoT
network, consisting of up to 10 leaf nodes (11 total IoT devices, including
the sink IoT noderk).
our comparison is provided in Tab. V. The results confirm
that LiKe is particularly suitable for constrained devices in
the IoT. Indeed, it is characterized by a total key agreement
time that, independently from the particular size of the elliptic
curve, is always the least among the considered approaches. In
particular, considering the most secure configuration (elliptic
curve group size of 256 bits), [23], [26], and [20] require
a time that is 524%, 182%, and 68% more than LiKe,
respectively.
D. Comparison with standard CBKE approaches
To provide a benchmark and enable cross-comparisons,
we evaluate LiKe against the two competing approaches,
recommended by the Zigbee 3.0 standard specification [7].
By considering the same structure of the proposed protocol
flow, we first assumed the use of the widely adopted X.509
certificates, signed through the standardized ECDSA mech-
anism, and then we assumed the usage of ECQV implicit
certificates, also recommended by the Zigbee 3.0 protocol
suite, as presented in the recent publication [19]. The bit-string
sizes of the parameters used for the reference approaches in the
performance evaluation are summarized in Tab. VI. It is worth
noting that, to provide a fair and straightforward comparison,
we did not consider any point compression technique for
points on elliptic curves, in line with the considered reference
approaches.
Table VI
OVE RVIE W OF TH E BI T-STRING SIZE OF THE CONSIDERED
CRYPTOGRAPHY ELEMENTS.
Parameter Size
Device Identifier 2bytes
Timestamp 10 bytes
Nonce 2bytes
Public Key dependent on the EC size
Authentication Tag 20 bytes
ECQV Certificate 38 +size key ×2(bytes)
X.509-ECDSA Certificate 824 +size key ×2(bytes)
By assuming the exchange of the above values in standard-
compliant layer-2 frames (as per the LiKe protocol), we carried
out a performance comparison by evaluating the message
overhead and the overall energy consumption of the LiKe
protocol and the competing approaches. We report that, for
X.509 certificates signed through ECDSA, we computed the
overall certificate size using the parameters reported in Tab.
VI and the well-known openssl tool.
We first investigated the number of messages per involved
device required by LiKe and the competing solutions, by
assuming the usage of the three elliptic curves presented
above. The results are reported in Fig. 10.
0 50 100 150 200 250 300
Elliptic Curve Group Size [bits]
0
2
4
6
8
10
12
Number of Layer-2 Messages
LiKe - IEEE 802.15.4
CBKE ECQV - IEEE 802.15.4
CBKE X.509-ECDSA - IEEE 802.15.4
Figure 10. MAC-layer messages required to complete the key agreement,
considering X.509-ECDSA, ECQV, and LiKe.
X.509-ECDSA certificates are characterized by a very high
size, leading to an overwhelming amount of messages to be
exchanged between the involved devices, i.e., 10 messages per
involved device. Comparing LiKe and the ECQV approach in
[19], it emerges that they require a very similar number of
messages. When the curves secp160r1 and secp192r1 are used,
both LiKe and the ECQV-based key agreement in [19] require
4messages, while the message overhead required by this latter
increases to 6messages (3per device) using secp256r1, one
message more than LiKe.
We also compared the energy consumption required by each
of the three approaches. To provide a meaningful evaluation,
not dependant on any external factor (e.g., the configuration of
the IEEE 802.15.4 MAC schedule and the access to the trans-
mission media), we first evaluated the energy consumed for
the transmission (and reception) of a single data packet using
the target hardware platform. Then we computed the overall
energy consumption of each of the discussed approaches by
considering: (i) the experimental energy cost per byte of
RF operations, (ii) the required number of transmission and
reception operations, and (iii) the energy cost of cryptographic
operations (reported in Fig. 7).
We recall that a single transmission/reception operation in
IEEE 802.15.4 takes place in a time-slot, fixed to 10 ms by
the standard, and defined as the time needed to transmit a data
packet and receive the corresponding acknowledgment by the
receiver. Thus, considering a single IEEE 802.15.4 active slot
(10 ms), using the same experimental setup described in the
previous subsection, we evaluated the energy consumed by
the data transmitter and the data receiver device. Figure 11
summarizes our findings.
We notice the presence of two spikes in the energy con-
sumption, one located at an offset of about 3ms and the other

16
0 1 2 3 4 5 6 7 8 9 10
Time [ms]
0
5
10
15
20
25
30
35
40
45
Current Drain [mA]
TX/RX Data
TX/RX Ack
Data Transmitter
Data Receiver
Figure 11. Current Consumption of a Data Transmission and a Data Reception
Operation within the duration of a IEEE 802.15.4 time-slot (10 ms).
one located at an offset about 6.5ms. Indeed, they are related
to the execution of RF operations. The first spike is the longest,
and lasts for around 3ms. It corresponds to the transmission
of the first data packet of our LiKe protocol, consisting of an
overall number of 92 bytes (including the MAC-layer payload
of the LiKe protocol and the IEEE 802.15.4 MAC header). In
this smaller time frame, we notice that the data transmitter has
higher levels of energy consumption than the data receiver, i.e.
about 36.74 mA (black line) equivalent to 115.96 mJ against
28.41 mA equivalent to 89.69 mJ (grey line). Also, we notice
that the receiver goes up a little in advance, to be sure to
receive the full packet content. The second spike, instead,
refers to the transmission and reception of the Acknowledge-
ment at the MAC layer, as imposed by the IEEE 802.15.4
standard for the transmission of any data packet. In this case,
the data receiver (grey line) reports higher energy consumption
values (being the one transmitting the acknowledgment), while
the data transmitter (black line) reports lower values, being
involved in an RF reception operation. Finally, when the RF
radio chip is not active, the energy consumption of the two
devices is about 12.14 mA equivalent to 35.28 mJ in a time
slot, and it is due to pure-software operations. Overall, the
energy consumption of the whole time-slot can be computed as
the area underlying the current consumption curve, as depicted
by Eq. 14.
E[mJ]=3.3V·ZT
0
i(t)dt, (14)
where Eis the energy (measured in mJ), i(t)is the instanta-
neous current drain (in mA), Tis the time slot duration (10
ms), and finally 3.3V, is the voltage of the OpenMote-b board
(in Volts). Thus, a data transmission slot requires 802.65 mJ,
while a data reception slot requires 778.51 mJ.
We can compute the energy consumption of CBKE when
using X.509-ECDSA certificates, CBKE using ECQV certifi-
cates, and the LiKe protocol, by considering: (i) the above
experimental measurements, (ii) the experimental energy con-
sumption for each atomic cryptographic operation (see Fig. 7),
and (iii) the number of required messages, as a function of the
elliptic curve size. The results are summarized in Fig. 12.
The results emphasize that the use of X.509 certificates
signed through the ECDSA algorithm leads to high energy
0 50 100 150 200 250 300
Elliptic Curve Group Size [bits]
2
2.2
2.4
2.6
2.8
3
3.2
3.4
3.6
3.8
Energy Consumption [mJ]
104
LiKe - IEEE 802.15.4
CBKE ECQV - IEEE 802.15.4
CBKE X.509-ECDSA - IEEE 802.15.4
Figure 12. Energy consumption on each device involved in the key agreement,
by considering X.509-ECDSA, ECQV, and LiKe, using different elliptic
curves.
consumption, from 21,855 mJ using an elliptic curve of 160
bits, up to 38,952.87 mJ using an elliptic curve of 256 bits.
As per the message overhead, ECQV-based approaches and
LiKe show similar levels of energy consumption. Overall,
LiKe exhibits a slightly less energy consumption, due to the
reduced number of bytes involved in RF operations. When an
elliptic curve of 256 bits is used, LiKe consumes 35,726 mJ,
against the 36,080 mJ consumed by the ECQV-based approach
in [19], i.e., 0.98% less.
Overall, a single OpenMote-b board is powered by two
AA batteries, and a typical Manganese/Alkaline AA battery
drains about 2.56 ampere-hours with a voltage of 1.5volts,
thus consuming roughly 3.84 watt-hours, i.e., 13,824 Joules
of storage capacity. Thus, in a single instance, LiKe consumes
roughly at most the 0.134% of the devices’ battery, i.e. really
a negligible portion of the available energy.
On the one hand, we highlight that such a slight improve-
ment compared to the ECQV-based approaches can become
significant when considering larger IoT networks. For instance,
in the largest IoT network considered in Sec. VI-B, by adopt-
ing the LiKe protocol the sink IoT device could gain up to
140.83% of energy compared to the X.509-ECDSA approach,
and 1.95% of energy to an ECQV-based approach. On the
other hand, we emphasize that, contrary to LiKe, ECQV-
based approaches are not robust against the adversary model
supposed in our work. In fact, if the secret nodes’ information
available on the DA are leaked, ECQV-based approaches
cannot further guarantee the authenticity of the identity of
communicating devices, thus being subject to impersonation
attacks. When using LiKe, instead, it is possible to be still
robust against the powerful adversary described in Sec. III-B,
even in such a challenging scenario, by achieving similar
(optimal) levels of message overhead and energy consumption,
as achieved by using ECQV-based approaches. Table VII
summarizes all the features and the requirements of CBKE
approaches and LiKe, assuming the usage of a 256-bit elliptic
curve.
While all the considered approaches can reject classical
Man-In-The-Middle attacks, LiKe is the only solution robust
also when the secret nodes’ information available on the

17
Table VII
COMPARISON OF LIKE AGAI NS T CBKE APP ROAC HES B ASE D ON
X.509-ECDSA AND ECQV, ASSUMING A 256-B IT EL LI PTI C CU RVE.
Feature X.509-ECDSA ECQV LiKe
Robustness to
Man-In-The-Middle 3 3 3
No. of messages to
detect an attack 9 2 2
Message Overhead
per Key Agreement Instance 10 3 2
Energy Consumption per
Key Agreement Instance (mJ) 38,953 36,080 35,726
Robustness to DA Secret
Information Disclosure 7 7 3
DA are leaked. This advantage is coupled with a limited
message overhead and energy consumption on IoT devices,
as demonstrated by our experimental analysis. We highlight
that, using a 256-bit elliptic curve (e.g., secp256r1), LiKe can
detect an ongoing attack after exchanging the same amount of
IEEE 802.15.4 messages than ECQV-based approaches, still
emerging as an energy-friendly approach.
Finally, we remark that the aim of the performance as-
sessment reported above is to provide the evidence that the
adoption of CL-PKC schemes is feasible for IoT devices based
on the IEEE 802.15.4 communication technology, and that its
integration in devices compatible with the Zigbee 3.0 protocol
stack does not generate additional overhead compared with
the usage of standardized approaches based on CBKE-ECDSA
and CBKE-ECQV.
VII. CONCLUSION
In this paper, we demonstrate that certificateless crypto-
graphic schemes are now really viable on constrained IoT
devices. We proposed and implemented LiKe, a novel key
agreement scheme based on the Certificateless Public Key
Cryptography (CL-PKC) class of techniques. Contrary to
most of the certificateless approaches, LiKe is a pairing-free
and energy-friendly scheme, that does not need a persistent
connection with a trusted authority during the key agreement.
Moreover, it enjoys lightweight computational requirements
and re-keying operations— all features that make it extremely
suitable for constrained IoT environments.
As reported by our real experimental campaign, in a real
network with up to 11 IoT nodes (including 10 leaf IoT
nodes), LiKe outperforms competing solutions. In particular,
LiKe completes all the key agreement instances in about 3.259
seconds, requiring only 2layer-2 frames for each involved
leaf IoT node. Compared to standardized approaches based
on the Certificate-Based Key Establishment (CBKE) protocol,
recommended by the Zigbee 3.0 protocol suite, LiKe reports
minimum message overhead (4MAC-layer messages when
using up to a 256-bit elliptic curve) and very limited energy
consumption (at most 0.258% of the devices’ battery per single
protocol instance). Besides, when re-keying is needed, LiKe
requires only 3new hashing operations, further improving
its efficiency. Moreover, from the security perspective, LiKe
provides enhanced protection against Man-In-The-Middle and
impersonation attacks also when the information stored on the
Domain Authority are leaked to the adversary.
Finally, the implementation of LiKe in the OpenWSN
protocol stack and the security verification using the ProVerif
automated tool have been released as open-source, to help
industry and academia in the development of fully resilient
IoT networks.
ACK NOW LE DG EM EN TS
The authors would like to thank the anonymous reviewers,
that helped to improve the quality of the manuscript.
This publication was partially supported by awards NPRP11S-
0109-180242, UREP23-065-1-014, and NPRP X-063-1-014
from the QNRF-Qatar National Research Fund, a member of
The Qatar Foundation. The information and views set out in
this publication are those of the authors and do not necessarily
reflect the official opinion of the QNRF.
REFERENCES
[1] F. Javed, M. K. Afzal, M. Sharif, and B. Kim, “Internet of Things
(IoT) Operating Systems Support, Networking Technologies, Applica-
tions, and Challenges: A Comparative Review,” IEEE Communications
Surveys & Tutorials, vol. 20, no. 3, pp. 2062–2100, 2018.
[2] B. Afzal, M. Umair, G. A. Shah, and E. Ahmed, “Enabling IoT platforms
for social IoT applications: Vision, feature mapping, and challenges,”
Future Generation Computer Systems, vol. 92, pp. 718 – 731, 2019.
[3] S. Pattar, R. Buyya, K. R. Venugopal, S. S. Iyengar, and L. M.
Patnaik, “Searching for the IoT Resources: Fundamentals, Requirements,
Comprehensive Review, and Future Directions,” IEEE Communications
Surveys & Tutorials, vol. 20, no. 3, pp. 2101–2132, 2018.
[4] C. Chang, W. Lee, Y. Liu, B. Goi, and R. C. . Phan, “Signature Gateway:
Offloading Signature Generation to IoT Gateway Accelerated by GPU,”
IEEE Internet of Things Journal, vol. 6, no. 3, pp. 4448–4461, Jun.
2019.
[5] J. B. Hoffmann, P. Heimes, and S. Senel, “IoT Platforms for the Internet
of Production,” IEEE Internet of Things Journal, vol. 6, no. 3, pp. 4098–
4105, June 2019.
[6] Juniper Research, “IoT Connections to grow 140% to
hit 50 billion by 2022, as Edge Computing accelerates
ROI,” https://www.juniperresearch.com/press/press-releases/
iot-connections- to-grow-140-to-hit-50-billion, 2018, (Accessed:
2019-07-17).
[7] NXP, ZigBee 3.0 Stack User Guide, pp. 1–508, Set. 2018.
[8] Zigbee Alliance, “Zigbee is the only complete loT solution,” https:
//www.zigbee.org/zigbee-for-developers/zigbee-3-0/, 2019, (Accessed:
2019-07-17).
[9] X. Liu and N. Ansari, “Toward Green IoT: Energy Solutions and Key
Challenges,” IEEE Communications Magazine, vol. 57, no. 3, pp. 104–
110, March 2019.
[10] M. Conti, A. Dehghantanha, K. Franke, and S. Watson, “Internet of
Things security and forensics: Challenges and opportunities,” Future
Generation Computer Systems, vol. 78, pp. 544 – 546, 2018.
[11] J. Granjal, E. Monteiro, and J. Sá Silva, “Security for the Internet of
Things: A Survey of Existing Protocols and Open Research Issues,”
IEEE Communications Surveys & Tutorials, vol. 17, no. 3, pp. 1294–
1312, 2015.
[12] E. Barker, “Recommendation for Key Management Part 1: General.”
National Institute of Standards and Technology (NIST), Jan 2016.
[13] Cybersecurity Research and Innovation Lab (CRI-LAB), “Open-source
code of the implementation of LiKe in the OpenWSN protocol stack
and code of the ProVerif tool,” https://github.com/pietrotedeschi/like-iot,
2019, (Accessed: 2019-07-17).
[14] Al-Riyami, S. S. and Paterson, K. G., “Certificateless Public Key
Cryptography,” in Advances in Cryptology - ASIACRYPT. Springer,
2003, pp. 452–473.
[15] J. Baek, R. Safavi-Naini, and W. Susilo, “Certificateless Public Key
Encryption Without Pairing,” in Information Security. Springer Berlin
Heidelberg, 2005, pp. 134–148.

18
[16] A. W. Dent, “A survey of Certificateless Encryption Schemes and
Security Models,” International Journal of Information Security, vol. 7,
no. 5, pp. 349–377, Oct 2008.
[17] M. Ammar, G. Russello, and B. Crispo, “Internet of Things: A survey
on the security of IoT frameworks,” Journal of Information Security and
Applications, vol. 38, pp. 8 – 27, 2018.
[18] R. Hummen, J. H. Ziegeldorf, H. Shafagh, S. Raza, and K. Wehrle,
“Towards Viable Certificate-based Authentication for the Internet of
Things,” in Proceedings of the 2Nd ACM Workshop on Hot Topics on
Wireless Network Security and Privacy, ser. HotWiSec ’13, 2013.
[19] S. Sciancalepore, G. Piro, G. Boggia, and G. Bianchi, “Public Key
Authentication and Key Agreement in IoT Devices With Minimal
Airtime Consumption,” IEEE Embedded Systems Letters, vol. 9, no. 1,
pp. 1–4, Mar. 2017.
[20] D. He, S. Padhye, and J. Chen, “An efficient certificateless two-party
authenticated key agreement protocol,” Computers & Mathematics with
Applications, vol. 64, no. 6, pp. 1914 – 1926, 2012.
[21] A. Karati, S. H. Islam, and M. Karuppiah, “Provably Secure and
Lightweight Certificateless Signature Scheme for IIoT Environments,”
IEEE Transactions on Industrial Informatics, vol. 14, no. 8, pp. 3701–
3711, Aug 2018.
[22] S. Ji, Z. Gui, T. Zhou, H. Yan, and J. Shen, “An Efficient and
Certificateless Conditional Privacy-Preserving Authentication Scheme
for Wireless Body Area Networks Big Data Services,” IEEE Access,
vol. 6, pp. 69 603–69 611, 2018.
[23] S.-B. Wang, Z.-F. Cao, and H.-Y. Bao, “Efficient Certificateless Au-
thentication and Key Agreement (CL-AK) for Grid Computing,” Inter-
national Journal of Network Security, vol. 7, no. 3, pp. 342–347, 2008.
[24] J. Shen, Z. Gui, S. Ji, J. Shen, H. Tan, and Y. Tang, “Cloud-aided
lightweight certificateless authentication protocol with anonymity for
wireless body area networks,” Journal of Network and Computer Appli-
cations, vol. 106, pp. 117 – 123, 2018.
[25] J. Won, S. Seo, and E. Bertino, “Certificateless Cryptographic Protocols
for Efficient Drone-Based Smart City Applications,” IEEE Access, vol. 5,
pp. 3721–3749, 2017.
[26] M. E. S. Saeed, Q.-Y. Liu, G. Tian, B. Gao, and F. Li, “AKAIoTs:
authenticated key agreement for Internet of Things,” Wireless Networks,
vol. 25, no. 6, pp. 3081–3101, Aug 2019.
[27] N. B. Gayathri, G. Thumbur, P. R. Kumar, M. Z. U. Rahman, P. V.
Reddy, and A. Lay-Ekuakille, “Efficient and Secure Pairing-Free Cer-
tificateless Aggregate Signature Scheme for Healthcare Wireless Medical
Sensor Networks,” IEEE Internet of Things Journal, pp. 1–1, 2019.
[28] J. Pan and J. McElhannon, “Future Edge Cloud and Edge Computing
for Internet of Things Applications,” IEEE Internet of Things Journal,
vol. 5, no. 1, pp. 439–449, Feb 2018.
[29] “IEEE Standard for Low-Rate Wireless Networks,” IEEE Std 802.15.4-
2015 (Revision of IEEE Std 802.15.4-2011), pp. 1–709, Apr. 2016.
[30] I. Cervesato, “The Dolev-Yao intruder is the most powerful attacker,” in
16th Annual Symposium on Logic in Computer Science—LICS, vol. 1,
2001.
[31] M. Rocchetto and N. O. Tippenhauer, “CPDY: extending the Dolev-Yao
attacker with physical-layer interactions,” in International Conference
on Formal Engineering Methods. Springer, 2016, pp. 175–192.
[32] R. Wright, “23,000 Symantec certificates revoked following leak of
private keys,” https://searchsecurity.techtarget.com/news/252436120/
23000-Symantec- certificates-revoked-following-leak-of-private-keys,
2018, (Accessed: 2019-10-17).
[33] S. Berger, R. Cáceres, K. A. Goldman, R. Perez, R. Sailer, and
L. van Doorn, “vTPM: Virtualizing the Trusted Platform Module,” in
Proceedings of the 15th Conference on USENIX Security Symposium
- Volume 15, ser. USENIX-SS’06. Berkeley, CA, USA: USENIX
Association, 2006.
[34] C. Lesjak, D. Hein, and J. Winter, “Hardware-security technologies for
industrial IoT: TrustZone and security controller,” in IECON 2015 -
41st Annual Conference of the IEEE Industrial Electronics Society, Nov
2015, pp. 2589–2595.
[35] B. Halak, M. Zwolinski, and M. S. Mispan, “Overview of PUF-based
hardware security solutions for the internet of things,” in IEEE 59th
International Midwest Symposium on Circuits and Systems (MWSCAS),
Oct 2016, pp. 1–4.
[36] M. H. Au, Y. Mu, J. Chen, D. S. Wong, J. K. Liu, and G. Yang,
“Malicious KGC Attacks in Certificateless Cryptography,” in Proceed-
ings of the 2Nd ACM Symposium on Information, Computer and
Communications Security, ser. ASIACCS ’07, 2007, pp. 302–311.
[37] H. Krawczyk, K. G. Paterson, and H. Wee, “On the Security of the TLS
Protocol: A Systematic Analysis,” in Advances in Cryptology. Springer,
2013, pp. 429–448.
[38] B. Blanchet, “Automatic Verification of Correspondences for Security
Protocols,” Journal of Computer Security, vol. 17, no. 4, pp. 363–434,
2009.
[39] C. Cremers and L. Hirschi, “Improving Automated Symbolic Analysis
of Ballot Secrecy for E-voting Protocols: A Method Based on Sufficient
Conditions,” 4th IEEE European Symposium on Security and Privacy
(EuroS&P’19), Jun. 2019.
[40] T. Antignac, M. Mukelabai, and G. Schneider, “Specification, Design,
and Verification of an Accountability-aware Surveillance Protocol,” in
Proceedings of the Symposium on Applied Computing, ser. SAC ’17,
2017, pp. 1372–1378.
[41] S. Sciancalepore, G. Piro, E. Vogli, G. Boggia, L. A. Grieco, and
G. Cavone, “LICITUS: A lightweight and standard compatible frame-
work for securing layer-2 communications in the IoT,” Computer
Networks, vol. 108, pp. 66–77, 2016.
[42] X. Vilajosana, P. Tuset, T. Watteyne, and K. Pister, “OpenMote: Open-
Source Prototyping Platform for the Industrial IoT,” in Ad Hoc Networks.
Springer, 2015, pp. 211–222.
[43] P. Tuset-Peiró, X. Vilajosana, and T. Watteyne, “OpenMote+: A Range-
Agile Multi-Radio Mote,” in Proceedings of the 2016 International
Conference on Embedded Wireless Systems and Networks, ser. EWSN
’16, 2016, pp. 333–334.
[44] S. Sciancalepore, G. Oligeri, and R. Di Pietro, “Strength of Crowd
(SOC)—Defeating a Reactive Jammer in IoT with Decoy Messages,”
Sensors, Special Issue on Emerging Methodologies and Practical Solu-
tions for M2M and D2D Communications in the Internet of Things Era,
vol. 18, no. 10, 2018.
[45] D. Stanislowski, X. Vilajosana, Q. Wang, T. Watteyne, and K. S. J.
Pister, “Adaptive Synchronization in IEEE802.15.4e Networks,” IEEE
Trans. on Industrial Informatics, vol. 10, no. 1, pp. 795–802, Feb. 2014.
[46] T. Watteyne, X. Vilajosana, B. Kerkez, F. Chraim, K. Weekly, Q. Wang,
S. Glaser, and K. Pister, “OpenWSN: a standards-based low-power
wireless development environment,” Transactions on Emerging Telecom-
munications Technologies, vol. 23, no. 5, pp. 480–493, 2012.
[47] “IEEE Standard Specifications for Public-Key Cryptography,” IEEE Std
1363-2000, pp. 1–228, Aug 2000.
[48] M. Kumar, C. P. Katti, and P. C. Saxena, “An untraceable identity-based
blind signature scheme without pairing for e-cash payment system,” in
Ubiquitous Communications and Network Computing, N. Kumar and
A. Thakre, Eds. Springer International Publishing, 2018, pp. 67–78.
Pietro Tedeschi is a PhD Student at HBKU-CSE-
ICT, Doha, Qatar. He received his Master’s degree
with honors in Computer Engineering at Politecnico
di Bari, Italy. He worked as Security Researcher
at CNIT, Italy, for the EU H2020 SymbIoTe. His
security research interests lie in Drone, Wireless,
IoT, Applied Cryptography.
Savio Sciancalepore is currently Post Doc at
HBKU-CSE-ICT, Doha, Qatar. He received his mas-
ter degree in Telecommunications Engineering in
2013 and the PhD in 2017 in Electric and Infor-
mation Engineering, both from the Politecnico di
Bari, Italy. He received the prestigious award from
the ERCIM Security, Trust, and Management (STM)
Working Group for the best Ph.D. Thesis in Infor-
mation and Network Security in 2018. His major
research interests include security issues in Internet
of Things (IoT) and Cyber-Physical Systems.

19
Areej Eliyan received the B.Sc degree (2018) in
Computer Engineering from Qatar University (QU).
She is currently a Master’s student in cybersecurity
at Hamad Bin Khalifa University (HBKU). Her
main research interests include computer networks
security, IoT, and network communication.
Roberto Di Pietro is full professor of cyber
security at HBKU-CSE, Doha-Qatar. Prior to that,
he served as Global Lead for Security Research
at Bell Labs. In 2010-11 he was awarded a
Chair of Excellence at University Carlos III,
Madrid. His research interests are in Distributed
Systems Security, Wireless Security, On-line Social
Networks Security, Intrusion Detection, leading
to 200+scientific publications and patents. As
for Google Scholar, he has been totaling 7600+
citations, with h-index=42, and i-index=116.