Elsevier Editorial System(tm) for Journal of

Network and Computer Applications

Manuscript Draft

Manuscript Number:

Title: Towards the inclusion of end-to-end security in the OM2M platform

Article Type: Research Paper

Keywords: CoAPS; ECQV; tinydtls; microECC; Scandium; oneM2M;

interoperability; authentication; authorization

Corresponding Author: Mr. Simone Patonico, M.D.

Corresponding Author's Institution: Vrije Universiteit Brussel

First Author: Simone Patonico, M.D.

Order of Authors: Simone Patonico, M.D.; Thanh-Long Nguyen, M.D.; Placide

Shabisha, M.D.; An Braeken; Kris Steenhaut

Abstract: The exponential growth in the number of Internet of Things

(IoT) devices and their potential in many applications
in a vast number of domains fuelled the development of dierent IoT
platforms, supported by big companies and
industry groups. These platforms are able to provide reliable services to
IoT devices and reduce the time to market for the targeted applications.
Unfortunately, these proprietary solutions fragment the IoT market and
hamper horizontal integration. The need to interoperate the dierent IoT
platforms and communication protocols pushed the Standards Developing
Organizations (SDOs) to the specification of a Machine-to-Machine (M2M)
service layer, published as the oneM2M standard. Although, the oneM2M
standard provides generic guidelines to implement security solutions
which include authentication, authorization, confidentiality and data
integrity, more ecient security schemes should be investigated when
constrained IoT devices are concerned. This paper presents two main
contributions.
First, a CoAPS binding for the OM2M platform is provided that enables
secure and reliable communication with
constrained IoT devices. Second, a lightweight dynamic access control
system is designed, developed and integrated
in a oneM2M-based architecture. It allows to dynamically grant or revoke
access permission in an anonymous way
to constrained IoT devices for controlling some actuators. From the
experimental results, we can conclude that the
computational complexity of the proposed security scheme is extremely low
for the client device which requests data
access. We show that a constrained IoT device establishes a trust
relationship with the OM2M server in few seconds.
Cover Letter

Dear Editor,

We are submitting our manuscript titled “Towards the inclusion of end-to-end security in the OM2M
platform” for consideration to be published on Journal of Network and Computer Applications.

We believe that the paper may be of particular interest to this journal, as it proposes an efficient
dynamic authorization system for a oneM2M-based architecture. This innovative security scheme has
been implemented for the OM2M platform. We also provide a performance evaluation with different
devices and libraries.

We hereby state that the paper contains original information and has not submitted to other journals

Thanks very much for your attention to it.

Best regards,

Simone Patonico
*Suggested List of Potential Referees

Potential Referees
Pardeep Kumar is associate professor at the Department of Computer Science, Swansea University, email:
pardeep.kumar@swansea.ac.uk

Nele Mentens is associate professor at KU Leuven, email:

Nele.Mentens@kuleuven.be

Madhusanka Liyanage is associate professor at the School of Computer Science, University College Dublin, Ireland and
Centre for Wireless Communications, University of Oulu, Finland, email: mashuanka@ucd.ie,
madhusanka.liyanage@oulu.fi

Susanna Spinsante is assistant researcher at the Department of Information Engineering of the Università Politecnica delle
Marche, email: s.spinsante@staff.univpm.it
*Manuscript
Click here to view linked References

Towards the inclusion of end-to-end security in the OM2M platform

Simone Patonicoa,b,∗, Thanh-Long Nguyena , Placide Shabishaa,b , An Braekenb , Kris Steenhauta,b

a Department of Electronics and Informatics (ETRO), Vrije Universiteit Brussel
b Department of Engineering Technology (INDI), Vrije Universiteit Brussel

Abstract
The exponential growth in the number of Internet of Things (IoT) devices and their potential in many applications
in a vast number of domains fuelled the development of different IoT platforms, supported by big companies and
industry groups. These platforms are able to provide reliable services to IoT devices and reduce the time to market for
the targeted applications. Unfortunately, these proprietary solutions fragment the IoT market and hamper horizontal
integration. The need to interoperate the different IoT platforms and communication protocols pushed the Standards
Developing Organizations (SDOs) to the specification of a Machine-to-Machine (M2M) service layer, published as
the oneM2M standard. Although, the oneM2M standard provides generic guidelines to implement security solu-
tions which include authentication, authorization, confidentiality and data integrity, more efficient security schemes
should be investigated when constrained IoT devices are concerned. This paper presents two main contributions.
First, a CoAPS binding for the OM2M platform is provided that enables secure and reliable communication with
constrained IoT devices. Second, a lightweight dynamic access control system is designed, developed and integrated
in a oneM2M-based architecture. It allows to dynamically grant or revoke access permission in an anonymous way
to constrained IoT devices for controlling some actuators. From the experimental results, we can conclude that the
computational complexity of the proposed security scheme is extremely low for the client device which requests data
access. We show that a constrained IoT device establishes a trust relationship with the OM2M server in few seconds.
Keywords:
CoAPS, ECQV, tinydtls, microECC, Scandium, oneM2M, interoperability, authentication, authorization

1. Introduction munication between proprietary IoT devices resulted in

The use of smart devices to improve the efficiency of
many applications is now considered a common prac-
tice and becoming an ordinary part of many daily activ-
ities. The possibility to transmit data in real time and
to automate processes attracted many companies which
invested considerable amounts of money in the produc-
tion of Internet of Things (IoT) devices and the design
of communication platforms and protocols. Groups of
companies and big companies such as Google and Ap-
ple developed specific IoT platforms for their propri-
etary IoT devices to enhance the reliability and security
of their systems. However, this trend led to an extremely
fragmented IoT market where each device could only
work with a specific protocol stack. The growing de-
mand for an interoperable solution to enable the com-
∗ PhD student at the Department of Electronics and Informatics
(ETRO) at Vrije Universiteit Brussel (VUB)
Email address: spatonic@etrovub.be (Simone Patonico)
the development of the oneM2M standard (oneM2M
(2012)). The oneM2M framework is conceived as a hor-
izontal service layer that provides several service func-
tions to manage IoT devices and sensor data. Since
the publication of the oneM2M standard, many open
source implementations for it became available such as
OM2M, OCEAN, IoTDM, OASIS SI, OpenMTC and
ATIS OS-IoT. We use OM2M, one of the first imple-
mentations that became available. IoT devices are of-
ten connected to the Internet, to transmit their data to
more powerful machines, which creates several security
threats. As they are often deployed in public environ-
ments, they are extremely vulnerable to cyber-attacks.
To avoid that a small or large group of malicious de-
vices can compromise the security of the whole system,
strong security mechanisms need to be used. Although
the oneM2M standard defines several security features
which include authentication and authorization of the
device, data integrity and confidentiality, the OM2M

Preprint submitted to Journal of Network and Computer Applications May 7, 2019

implementation lacks most of these features. Regarding
device authentication, the common approach is based on
explicit certificates provided by a Trusted Third Party
(TTP) which acts as certificate authority. This is the
strategy suggested by the oneM2M standard that pro-
poses the use of an external entity for implementing
a M2M Authentication Function (MAF). Mechanisms
to provide anonymity are not yet described in the stan-
dard. However, anonymity plays a more and more im-
portant role, knowing that relevant information can be
derived from communication patterns between entities.
In a smart home application, for instance, based on the
relation between the behavior of the house owner and
the sensor data collected by the server, one can extract
relevant information related to occupancy of the house.
In this paper we focus on two contributions that enhance
the security properties of OM2M. On the one hand, we
include the Datagram Transport Layer Security (DTLS)
protocol (rfcDTLS (2012)) to secure the communication
between the Wireless Sensor Networks (WSNs), which
consists of constrained IoT devices, and the OM2M
gateway. This way, we guarantee the integrity and con-
fidentiality of the sensor data on the fly that have to be
stored in the OM2M server. DTLS is the best solution to
fit into the constrained hardware of IoT devices because
it works on top of the User Datagram Protocol (UDP)
as transport layer, which is lightweight and limits the
number of bytes to transmit. The use of the Constrained
Application Protocol (CoAP) on top of DTLS eases the
implementation of the application logic and the map-
ping with the oneM2M service layer. The combination
of CoAP and DTLS is called secure CoAP, abbreviated
to CoAPS. On the other hand, we developed an effi-
cient Identity and Access Management (IAM) system
to authenticate and authorize clients that want to access
sensor data from the OM2M platform in an anonymous
way. A big effort in the development of strong authenti-
cation and authorization solutions has been done in re-
cent years. Some surveys (Naik and Jenkins (2016);
Younis et al. (2015)) have investigated the evaluation
criteria for IAM systems in a cloud-based architec-
ture. Authors in (Indu and Anand (2016)) propose a
hybrid IAM system for web applications able to com-
bine the advantages of well-known access control meth-
ods such as Discretionary Access Control (DAC), Role
Based Access Control (RBAC) and Attribute Based Ac-
cess Control (ABAC). Other researchers (Fotiou et al.
(2016); Kim and Lee (2017)) focus more on access
control systems for IoT devices with limited compu-
tational and storage resources. A detailed analysis of
pros and cons of centralized and distributed authenti-
cation and authorization systems involving IoT devices
2
is provided in (Kim and Lee (2017). Recently, several
research studies (Liu et al. (2016); Gope and Hwang
(2016); Li et al. (2019)) investigated client anonymity
in access control systems for cloud-based architecture
and WSNs. However, the security system proposed in
(Liu et al. (2016)) requires the presence of two addi-
tional entities beyond client, cloud service provider and
authentication server to distribute security credentials
to the client. Moreover, the client must perform sev-
eral operations to be authenticated and the scheme in-
volves the heavy bilinear pairing operations. Other stud-
ies (Sun et al. (2019); Jan et al. (2019)) investigated the
anonymity of IoT devices in a fog-based architecture for
smart city applications. Conversely, authors in (Gope
and Hwang (2016)) designed a lightweight anonymous
authentication protocol for data access in WSNs. The
scheme is computationally efficient and guarantees user
privacy, but it requires a secure channel between user
and gateway for the provision of a smart e-card. Simi-
larly, an efficient authentication protocol for mobile de-
vices in smart cities has been proposed in (Li et al.
(2019)). Although this scheme has been proven secured
against several attacks, it still requires a secure chan-
nel between mobile users and servers in the registration
phase. The proposed IAM system differs from previ-
ous solutions by using the lightweight Elliptic Curve
Qu-Vanstone (ECQV) implicit certificates, which are
much smaller than the standard X.509 certificates and
provide anonymity to the entity. This way, also a very
constrained battery-powered IoT device can authenti-
cate itself and access the sensor data from the OM2M
server. The rest of the paper is organized as follows.
First, we provide some necessary background where we
describe the oneM2M standard and introduce the prin-
ciples behind the security scheme offered by Elliptic
Curve Cryptography (ECC). Also, we briefly describe
the integration of DTLS to secure the communication
between M2M devices and discuss the authentication
and authorization systems suggested by the oneM2M
standard. Then, an analysis of the most recent research
in the DTLS protocol for IoT devices and the IAM se-
curity solutions for oneM2M is provided. Next, we de-
scribe the proposed security solutions and the system
architecture used to conduct some performance experi-
ments. Finally, we conclude the paper.
2. Preliminaries
The use of different IoT devices with a variety of
features and requirements using dedicated proprietary
solutions serving the same application such as smart
city monitoring requires interoperability (Corici et al.
 Figure 1: The oneM2M functional architecture which identifies all the entities that each oneM2M node must or may contain.
(2014)). In that situation the use of a horizontal layer
(Swetina et al. (2014); Elmangoush et al. (2014)) able to
mediate between different protocol stacks is mandatory.
A fully interoperable platform should provide technical,
syntactic and semantic interoperability.
2.1. The oneM2M standard
The oneM2M global initiative was founded in 2012
by a group of Standard Development Organizations
(SDOs) together with several industrial consortia. The
oneM2M service layer was conceived as a resource-
based framework. This means everything is considered
as a resource, and resources are organized in a hierar-
chical tree. To fulfil the property of technical inter-
operability, three standardized bindings have been in-
cluded that facilitate the communication with devices
using Hyper Text Transfer Protocol (HTTP), CoAP or
Message Queue Telemetry Transport (MQTT) applica-
3
tion protocols. To manipulate oneM2M resources, two
message types called oneM2M primitive request and re-
sponse have been defined. Bindings specify rules for
encapsulating these primitive messages in HTTP, CoAP
or MQTT packets so as to use them as transport ve-
hicles. Since oneM2M has a Representational State
Transfer (REST) architecture, binding with HTTP and
CoAP is straightforward. To allow a flexible communi-
cation protocol interoperability, an Interworking Proxy
Entity (IPE) can be included. This way, any com-
munication protocol or software framework (Wu et al.
(2017)) can be integrated in oneM2M. The IPE imple-
ments the server and/or client side of the specific pro-
tocol that needs to be bound and makes the conversion
between protocol specific and oneM2M primitive mes-
sages. The oneM2M standard defines five operations
to manage resources: CREATE, RETRIEVE, UPDATE,
DELETE and NOTIFY (CRUD+N). Two different en-
tities are described by the standard: Application Entity
(AE) and Common Service Entity (CSE). The AE is an
M2M application service logic and represents an appli-
cation residing in a specific device, whereas the CSE
provides a set of Common Service Functions (CSFs)
to offer useful functionalities such as data and device
management to the other entities. Beyond this distinc-
tion, oneM2M defines different types of nodes that are
represented in Figure 1. The Infrastructure Node (IN)
is the core of the oneM2M platform and must contain
at least one CSE. There is only one IN per oneM2M
service provider. The Middle Node (MN) is usually
deployed close to the IoT sensor devices and acts as
a gateway. Since also this oneM2M node has to pro-
vide services to the other nodes of the system, it must
also contain a CSE. The Application Dedicated Node
(ADN) can reside in a constrained IoT device and needs
at least an AE to communicate with other CSEs through
one of the standardized bindings. The Application Ser-
vice Node (ASN) is a CSE-capable node that must con-
tain one CSE and one AE. It can reside in a M2M de-
vice such as a smartphone. The Non-oneM2M Device
Node (NoDN) does not contain any AEs or CSEs, so it
requires the implementation of an IPE to communicate
with oneM2M devices.
2.2. Elliptic Curve Cryptography
ECC provides lightweight public key cryptography
which offers the same level of security as the ordinary
Rivest-Shamir-Adleman (RSA) but with shorter keys.
Since shorter key reduce the complexity of the crypto-
graphic operations, ECC can be used in IoT devices,
avoiding the long delays of the RSA algorithm. ECC is
based on the algebraic structure of elliptic curves (EC)
over finite fields. We denote the curve E p(a,b) over the fi-
nite field F p with the generator point G of order n. The
product A = aG = (A x , Ay ), with a ∈ F p , is an EC mul-
tiplication and the result A is a point of the curve. To
transmit a point of the curve, it is sufficient to transmit
its x coordinate together with a single bit for the sign,
according to the encoding rules described in (Research
(2009)). The security of ECC is based on two computa-
tional hard problems: the Elliptic Curve Discrete Loga-
rithm Problem (ECDLP) and the Elliptic Curve Diffie
Hellman Problem (ECDHP). The ECDLP states that,
given two points A and B of an EC, it is computationally
hard to find a value x, such that A = xB. The ECDHP
affirms that, given two points A = xG and B = yG with
x,y unknown, it is computationally hard to find the point
Q = xyG.
4
2.3. Secure communications in oneM2M
The Transport Layer Security (TLS) or the DTLS
protocols have been selected by the oneM2M stan-
dard as security solutions to protect data exchanged be-
tween different M2M devices. In our previous work
(Patonico et al. (2018)), we investigated the usabil-
ity of DTLS in a constrained WSN device and devel-
oped an IPE to integrate DTLS in a oneM2M CSE-
capable device. In particular, we used the tinydtls li-
brary to implement DTLS clients in several WSN de-
vices which act as NoDNs, whereas the Scandium li-
brary was exploited to develop the IPE featuring a
DTLS server. We analyzed the DTLS handshake for two
cipher suites: TLS PSK WITH AES 128 CCM 8 and
TLS ECDHE ECDSA WITH AES 128 CCM 8. The
former uses symmetric key cryptography for device
authentication and key exchange, making the hand-
shake less resource-hungry. The latter uses asymmetric
key cryptography, leveraging the Elliptic Curve Digi-
tal Signature Algorithm (ECDSA) for mutual authenti-
cation and the Elliptic Curve Diffie-Hellman Exchange
(ECDHE) for the key exchange. Although the EC-
based cipher suite offers a higher level of security, it
also consumes many more resources compared to the
PSK-based cipher suite. We also provided a perfor-
mance comparison between these two cipher suites in
the constrained NoDN by measuring the DTLS hand-
shake duration and energy consumption.
2.4. Authentication and authorization in oneM2M
The oneM2M standard proposes several solutions for
identifying and authenticating an entity which requires
services from a CSE. The identification process verifies
if an identity fits in a certificate. Authentication can be
done through the verification of the signature in case of
a certificate-based method or through computation of a
Message Integrity Code (MIC) when using a symmetric
key-based approach. For authorization, oneM2M pro-
poses different methods such as RBAC, ABAC, etc. To
take an access decision, the roles or attributes are evalu-
ated against Access Control Policies (ACPs) that protect
the oneM2M resources. oneM2M defines two types of
dynamic authorization systems classified as direct dy-
namic authorization and indirect dynamic authorization.
These systems, shown in Figure 2, provide temporary
permission to the originator of the request to access pro-
tected resources. The direct dynamic authorization sys-
tem assumes that the originator of the request had al-
ready been provisioned with an access token or a token
identifier before the start of the authorization procedure.
Upon reception of a request, the hosting CSE interacts
Figure 2: The dynamic authorization systems suggested in the oneM2M standard to provide temporary access permissions: (a) The direct dynamic
authorization system assumes that the originator of the request is pre-provisioned with access tokens; (b) In the indirect dynamic authorization
system, the originator of the request has to request access tokens to the dynamic authorization server before being able to access the protected
resources from the oneM2M hosting CSE.
with the dynamic authorization server before computing
the access decision. In the indirect dynamic authoriza-
tion system, the originator of the request receives token
request information from the hosting CSE in case of de-
nied access. Then, the originator can use this token in-
formation to request either a token or a token identifier
from the dynamic authorization server. The OM2M im-
plementation only includes a basic authorization mod-
ule which defines one or more ACPs. The oneM2M
originator, which is a parameter of a oneM2M primitive
request, is evaluated against these ACPs and access is
granted when at least one ACP allows it. We now pro-
pose an efficient scheme following the different steps
described in the indirect dynamic authorization scheme,
where in addition a common shared secret session key is
established between the originator and the hosting CSE
in an anonymous way.
3. Related work
Since we provide a security solution for constrained
IoT sensor devices using the DTLS protocol on the one
side and a customized IAM solution for client IoT de-
vices wanting to access protected resources on the other
side, related work will be split in two paragraphs. In
5
the first one we present the state of the art of DTLS im-
plementations used in constrained IoT sensor nodes. In
the second one we investigate security systems with fo-
cus on device authorization in oneM2M-based architec-
tures.
3.1. DTLS in WSN devices
The usage of the DTLS handshake on constrained
WSN devices can be very costly in terms of energy con-
sumption and computation time. For this reason, sev-
eral research works focus on solutions that move the
computational complexity of the DTLS handshake from
the WSN devices to a more powerful router or gate-
way. (Granjal and Monteiro (2016)) propose a medi-
ated DTLS handshake which moves the ECC complex-
ity of the mutual authentication and key exchange from
the sensor device to a more powerful border router. The
communication between constrained sensor devices and
the border router is still secured using the DTLS pro-
tocol but with the Pre-Shared Key (PSK) cipher suite
that is much more lightweight. However, their approach
requires the deployment of access control servers and
a certificate authority to provide reliable authentication
of the sensor devices. A solution based on a DTLS
terminated gateway is described by (Van den Abeele
et al. (2015)). This gateway can perform multiple DTLS
handshakes with multiple Internet hosts and can main-
tain a long-lived DTLS session with constrained WSN
devices. This way, they avoid that multiple DTLS hand-
shake sessions exhaust the limited resources of WSN
devices. Moreover, the gateway offers a flexible solu-
tion, permitting public key cryptography for the DTLS
session with the Internet hosts and a more suitable PSK
cipher suite for establishing a secure channel with WSN
devices. Our previous work (Patonico et al. (2018))
provides a solution to perform the DTLS handshake
with the ECC-based cipher suite using the tinydtls li-
brary on the constrained Zolertia RE-mote. However,
we were forced to add an extra handshake message from
the client side to acknowledge the ServerKeyExchange
message avoiding overwhelming the constrained client
with other handshake messages during the signature
verification procedure. (Staudemeyer et al. (2018)) pro-
pose to integrate different ECC implementations such as
MicroECC in tinydtls to speed up the EC point multipli-
cation. In the same direction, (Capossele et al. (2015))
provide an extensive study on the use of DTLS with the
ECC cipher suite in very constrained WSN devices. To
speed up the DTLS handshake, they propose several op-
timizations in the calculation of the EC multiplication
for a customized WSN platform with an 8-bit ultra-low
power 16 MHz microcontroller. They also measured the
improvements in terms of latency and energy consump-
tion of each optimization. They were able to perform
an EC multiplication in tens of milliseconds, but their
solution was tailored to their specific platform. (Paton-
ico et al. (2018)) offers a solution that integrates DTLS
into the OM2M framework. No application protocol has
been included in (Patonico et al. (2018)), which in con-
trast is the case in (Granjal and Monteiro (2016); Van
den Abeele et al. (2015); Staudemeyer et al. (2018); Ca-
possele et al. (2015)). Therefore, we extend our previ-
ous work to a CoAPS implementation and made a cor-
responding binding to the OM2M platform.
3.2. IAM systems for oneM2M-based architectures
The oneM2M standard specifies many security solu-
tions to provide authentication, authorization, identity
management, confidentiality and data integrity. These
security features are not included in most oneM2M im-
plementations. A few recent papers propose solutions to
enhance the security functionalities of oneM2M-based
systems. (Oh and Kim (2017)) focus on the integration
of authentication and authorization by implementing the
OAuth 2.0 framework for the Mobius implementation
of the oneM2M standard. To automate the authenti-
cation and authorization processes, they used the “re-
6
source owner password credentials” grant type to issue
the token. This solution can only be used with trusted
clients that can securely store the owner’s credentials.
(Lee et al. (2018)) propose to integrate a blockchain
framework in a oneM2M-based architecture. This way,
they improve the security of data storage by moving
from a standard centralized database used by oneM2M
to the distributed approach offered by the blockchain
technology. They used Logchain, a type of blockchain
suitable to IoT platforms, with blind voting as consen-
sus rule. (Hsu and Lin (2017)) follow the guidelines
of the oneM2M standard to implement a certificate-
based authentication and authorization system which
uses a Machine-to-Machine Enrolment Function (MEF)
for credentials provisioning. They also developed two
solutions for the OM2M implementation that avoid the
use of the same certificate in multiple machines. Their
security system requires a certificate-based TLS hand-
shake that is too heavy for constrained WSN devices.
Even on a standard PC implementation, the total pro-
cess takes more than 8s. A certification procedure for
IoT/M2M devices is provided by (Neisse et al. (2017)).
The authors propose to combine model-based testing
and policy-based management to detect vulnerabilities
in IoT platforms and enforce runtime policies to cor-
rect the problem. As a test case, they evaluate the se-
curity level of access control policies of oneM2M. The
use of Software Defined network Perimeters (SDP) to
provide advanced security features for oneM2M-based
platforms has been investigated in (Balfour (2015)).
However, SDP uses certificates to authenticate and au-
thorize M2M devices requiring access that cannot be
used for constrained WSN devices. For the implementa-
tions of (Oh and Kim (2017); Lee et al. (2018); Neisse
et al. (2017); Balfour (2015)), performance results are
not provided. None of the approaches (Oh and Kim
(2017); Lee et al. (2018); Hsu and Lin (2017); Neisse
et al. (2017); Balfour (2015)) include anonymity during
the authorization and authentication process.
4. Proposed solution
We developed two security solutions to enhance the
security services provided by our oneM2M-based archi-
tecture. The developed CoAPS binding for the OM2M
platform allows the IoT sensor devices to securely send
their measurements to the OM2M gateway. The OM2M
gateway will forward the data to the OM2M server over
a secure HTTPS channel. The designed and imple-
mented security scheme for authenticating and autho-
rizing clients that want to access the protected resources
stored in the OM2M server in an anonymous way.
 Figure 3: The system setup used to demonstrate the dynamic authorization system, showing the main functionalities of the involved entities.
4.1. System architecture
The proposed dynamic authorization system is a
complete security solution which takes care of sensor
data integrity and confidentiality as well as client iden-
tification, authentication and authorization. The set-up,
demonstrating this solution is represented in Figure 3.
It consists of six entities:
• A Sensor Owner, who deploys several WSN de-
vices in the field to measure some physical param-
eters.
• A WSN, which consists of several Zolertia RE-
motes featuring several sensors. These devices can
securely send data by exploiting CoAP and DTLS.
These data will be opportunely decrypted and
transformed in oneM2M resources by the CoAPS
binding software that we added to the OM2M gate-
way.
• A OM2M gateway, which is a oneM2M MN-CSE
providing the CoAPS interface to securely receive
data from the WSN devices. The OM2M gateway
exploits a pre-installed HTTPS channel to forward
7
the sensor data to the more storing-capable OM2M
server.
• A OM2M server, which is a oneM2M IN-CSE in
charge of storing the data gathered by the WSN and
relayed by the OM2M gateway. The OM2M server
must also guarantee that only authenticated and au-
thorized clients can access the protected oneM2M
resources.
• A Dynamic Authorization Server (DAS) is the en-
tity which stores dynamic access information ob-
tained through interaction with the sensor owner
during the installation phase. This external server
uses a MySQL database to store access tokens,
linked to specific WSN devices deployed by the
sensor owner.
• A Client that wants to access the protected re-
sources from the OM2M server. This entity needs
to communicate with the DAS to obtain a ticket
before being able to retrieve data from the OM2M
server.
We also assume the presence of a secure channel be-
tween the OM2M server and the DAS, and between the
OM2M server and the OM2M gateway. These channels
are fundamental for the exchange of sensitive authoriza-
tion information and the privacy of sensor data, respec-
tively. Moreover, the OM2M server and the DAS share
a symmetric key that will be used to verify the client’s
authenticity in an anonymous way.
4.2. CoAPS binding for oneM2M
In previous work (Patonico et al. (2018)) we modi-
fied the tinydtls library, which is a lightweight imple-
mentation of the DTLS protocol, to fix the problems
during the handshake when we use the EC-based cipher
suite in the Zolertia RE-mote. We also developed an
IPE to implement a DTLS server in the oneM2M IN-
CSE using the Scandium library. To improve the in-
tegration and usability of DTLS in oneM2M devices,
we created the CoAPS protocol binding which features
CoAP and DTLS. Following the same approach as the
other standardized bindings, we registered the CoAPS
service by extending the RestClientService.java class.
We also modified the Erbium implementation of CoAP
in Contiki OS to integrate the security features provided
by tinydtls. This mainly involves the addition of the files
er-coap-dtls.c and er-coap-dtls.h to provide the APIs for
the data encryption/decryption and the installation of se-
curity credentials for the mutual authentication. More-
over, we replaced the ECC implementation included in
tinydtls with the MicroECC library that speeds up the
EC multiplication and addition operations. This way,
constrained WSN devices can verify the signature of the
other party using the ECDSA in a couple of seconds.
The WSN devices are programmed as CoAPS clients
and they initiate the DTLS handshake with the CoAPS
server involved in the CoAPS binding. Once the hand-
shake is completed, CoAPS clients and the oneM2M
MN-CSE can communicate securely using the estab-
lished session key.
4.3. Security scheme for client authentication and au-
thorization
Client authentication and authorization are funda-
mental features of a security system that provide protec-
tion against several attacks such as impersonation, man-
in-the-middle, denial of service, replay, etc. To avoid
leakage of sensitive data, strong authentication and au-
thorization solutions should be deployed. The oneM2M
standard suggests different solutions to tackle unautho-
rized access to protected resources. In this paper, we
follow the guidelines related to the indirect dynamic au-
thorization system which is represented in Figure 2b.
8
Since the communication between the access request
originators and DAS (steps 3-4 of Figure 2b) is not de-
fined in the oneM2M technical specification TS-0003,
we developed our own authorization system and added
the anonymity feature to it. The security scheme has
been designed to be as lightweight as possible. Be-
yond client authentication and authorization, the secu-
rity scheme allows the client and OM2M server to agree
on a session key that can be used to establish a secure
channel. The security scheme consists of three phases:
• Installation phase: the sensor owner creates dy-
namic authorization information per WSN device.
• Registration phase: the client registers to a partic-
ular resource and receives a temporary access right
(token) to the resource possibly after a successful
payment.
• Key Agreement phase: the client requests access to
the protected resource. The OM2M server evalu-
ates the access request after the client’s authentic-
ity has been verified. If resource access is granted,
client and OM2M server end up sharing a common
session key.
4.3.1. Installation phase
The installation phase is started by the DAS. It estab-
lishes a connection with the MySQL database, generates
its private key k and public key PDAS using the APIs of
the BouncyCastle library and creates a table called AC-
CESS TOKEN to store dynamic access tokens issued by
the sensor owner. The ACCESS TOKEN table contains
information about a specific access token, such as:
• token identifier: a seven characters length unique
identifier;
• issuer: the unique identifier of the AE created by
the WSN device in the OM2M server;
• holder: always the DAS entity;
• validity period: time interval where the access to-
ken is considered valid and can be used to access
the protected resource;
• token name: the name of the resource that the token
is protecting (e.g. temperature, humidity, etc...);
• audience: the unique identifier of the client that
received the access token;
Figure 4: The Login Page (a) and Token Creation Page (b) used by the owner of the sensor nodes to define new access tokens for the ones he has
deployed.
• permission: the level of permissions granted to the
client. There are two levels of permissions: only
retrieve or retrieve plus discovery that are identi-
fied by the numbers 32 and 34 respectively. For
retrieve only, the client is authorized to request just
the latest measurement; whereas in case of retrieve
plus discovery, the client can retrieve all the mea-
surements of the requested resource;
• business data: some information detailing the type
of subscription chosen by the client and the fee to
receive the access token.
The sensor owner can deploy his WSN devices that
will automatically start the DTLS handshake with the
OM2M gateway using asymmetric key cryptography
for mutual authentication and key exchange. Next, the
WSN devices will use the CoAPS protocol to securely
send new sensor data to the OM2M gateway which will
forward it to the OM2M server. At this point, we as-
sume that the DAS and the sensor owner are provisioned
with valid certificates by a third-party Certificate Au-
thority (CA). This way, the sensor owner can install the
valid certificate in his browser and can securely access
the login.html page provided by the DAS entity. Upon
successful login, the sensor owner is redirected to the
createTokens.html page where he can issue new access
tokens. In particular, the sensor owner must specify the
name of the protected resource, the level of permission
and the type of subscription needed for billing associ-
ated to the new access token. The login.html and cre-
ateTokens.html webpages are shown in Figure 4.
4.3.2. Registration phase
The registration phase has two main functionalities
that are needed for the key agreement algorithm: the
derivation of the client’s key pair and the client’s sub-
scription to a particular access token. Assuming that
9
each client is pre-provisioned with a unique identifier
by the manufacturer, the derivation of security creden-
tials for the client is performed using the ECQV scheme
(Qu (2000)). The ECQV is a very efficient algorithm
that allows a TTP to issue an implicit certificate and de-
rive the key pair to the client without the necessity of a
secure channel between TTP and client. (Brown et al.
(2002)) have proven the security of this scheme. Thanks
to its efficiency, the ECQV implicit certificate scheme
has been studied to improve the security features in IoT
applications (Park (2017)). In our scheme, the DAS as-
sumes the role of the TTP to perform the ECQV implicit
certificate protocol with the client. Figure 5 represents
all the cryptographic operations performed by the two
entities as well as the messages exchanged.
The scheme is started by the client that requests the
derivation of its key pair and corresponding certificate
to the DAS. For doing so, the client generates a random
value u, obtains the point U = uG by performing an
EC multiplication and sends its identifier IDu and the
computed point U to the DAS. The latter also gener-
ates a random value a, computes the point A = aG as
an EC multiplication and the client’s implicit certificate
certu = U + A executing an EC addition. Next, the DAS
computes the implicit signature as:
qu = H(certu kIDu )a + k
and the client’s public key as:
Pu = H(certu kIDu )certu + PDAS
where the hash operation SHA256 is denoted by H()
whereas the concatenation operation is represented by
the symbol k. The client’s certificate certu , the implicit
signature qu and the DAS’s public key PDAS are sent to
the client over the public channel. Upon reception of the
message (certu , qu , PDAS ), the client derives its private
Figure 5: The Elliptic Curve Qu-Vanstone algorithm that is used by the client to derive its key pair and receive the implicit certificate from the
DAS.
and public key respectively as:
du = H(certu kIDu )u + qu
Pu = duG
Since the client’s private key is computed using secret
information of both client and DAS, there is no key es-
crow problem. To verify the authenticity of the DAS,
the client can also compute its own public key by using
the public key of the DAS:
P∗u = H(certu kIDu )certu + PDAS
If Pu equals P∗u , the client is sure about the authentic-
ity of the certificate received and can trust the key pair
computed using the DAS’s implicit signature qu . Note
that given certu , IDu and PDAS , which are public infor-
mation, any other entity of the system can compute the
public key Pu . Upon reception of an ECQV initializa-
tion request from a client, the DAS stores the client’s
identifier IDu , certificate certu and public key Pu in the
CLIENTS table created in a MySQL database. This is
done to maintain a list of all clients that performed the
ECQV scheme with the DAS. The second part of the
registration phase consists in the client’s subscription to
a particular resource protected by a specific access to-
ken. The client communicates with the DAS to receive
10
an access token. The client’s subscription algorithm is
described in Figure 6. To start, the client generates two
random numbers c, z and a timestamp T R . Next, it com-
putes the EC point Z = zG, and two symmetric keys,
denoted Kr and Kz , using a Diffie Hellman based con-
struction using PDAS and Z respectively. The last one al-
lows anonymous encryption of the subscription request
S ub which includes the resource in which the client is
interested denoted Rn , the type of subscription chosen
denoted T ype, the random number denoted c, identity
of the client denoted IDu and the key denoted Kr . The
inclusion of the key Kr guarantees the authentication of
the client. The subscription request S ub is sent to the
DAS together with the timestamp of the request T R and
the point Z. Upon reception of the request, the DAS
computes the key Kz using Z and the received times-
tamp T R , and decrypts S ub in order to obtain the name
of the resource Rn the client is interested in, the type
of subscription chosen T ype, the random number c, the
client’s identifier IDu as well as the key Kr . Next, it
checks if the client’s identifier and corresponding pub-
lic key Pu are already present in the CLIENTS table.
Then, it computes the same disposable symmetric key
Kr using the received timestamp T R and checks if it cor-
responds with the received value. Next, the CLIENTS
 Figure 6: The client’s subscription algorithm to obtain dynamic authorization information from the DAS.
table is updated with resource name and subscription
type obtained from the ciphertext S ub. The DAS gen-
erates a new symmetric key Kt , based on the usage of
the masked identity Qu = H(IDu kc) and the common
shared key K s with the OM2M server. The key Kt is
used to derive the so called ticket for the client denoted
by Ticket in step 12 of Figure 6. The ticket includes the
specific token identifier corresponding to the resource
the client is interested in, the name of the resource and
the expiration date. Finally, the DAS sends the ticket,
encrypted with the key Kr , back to the client in response
to the subscription request.
4.3.3. Key agreement phase
The client uses the key agreement algorithm, shown
in Figure 7, to compute and share a common session
key SK with the OM2M server. Beyond this, the algo-
rithm allows the OM2M server to verify the client’s au-
thenticity while the DAS checks if the presented ticket
contains a valid token identifier for the requesting client.
In the following we describe the necessary operations
and data exchanges performed by the three entities in-
volved. First, the client generates the masked identity
Qu using the secret random number c and sends a mes-
11
sage containing the masked identity Qu and the ticket
received during the registration phase to the OM2M
server. As soon as the OM2M server receives the au-
thentication request, it computes the decryption key
Kt , using the client’s masked identity and the common
shared key K s , to allow the decryption of the ticket. If
the result contains a valid resource name Rn , a valid
expiration time and a fresh token identifier, the client
is authenticated. Then, the OM2M server generates a
timestamp T s , retrieves the AE identifier containing the
measurements corresponding to the requested resource
and sends a message which consists of AE identifier,
T s and token identifier over the secure HTTPS chan-
nel. Upon reception of this message, the DAS veri-
fies the presence and validity of the token identifier in
the ACCESS TOKEN table and updates it with the re-
ceived AE identifier. If this verification succeeds, the
client is considered authorized to access the protected
resource. The DAS computes the session key SK using
the received timestamp T s and delivers it to the OM2M
server through the secure HTTPS channel. Finally, the
OM2M server sends timestamp T s and the encrypted
Uniform Resource Identifier (URI) of the requested re-
source with SK to the client so that it can compute the
Figure 7: The Key Agreement algorithm used by the client and OM2M server to establish a common session key SK with the help of the DAS.
During this phase the client is also authenticated by the OM2M server and authorized by the DAS.
same session key and check the validity by verifying
if the decryption leads to a valid URI. This shared ses-
sion key can now be used by client and OM2M server to
create a secure channel for the coming session. Every
time the client wants to refresh the secret credentials,
it can freely initiate a new registration phase. This dy-
namic access control system requires the execution of
a few EC multiplications, encryptions/decryptions and
hash operations and hence is extremely lightweight. For
this reason, even a constrained client, unable to store
and send the heavy X.509 certificates, can authenticate
itself with other parties.
5. Security evaluation
We now discuss the strength of the proposed IAM
solution with respect to the main important attacks.
• Replay attacks: A replay attack in the subscrip-
tion algorithm is not possible due to the usage of a
timestamp, which is included in the encrypted sub-
scription message of the client and the encrypted
ticket response of the DAS. Also, in the key agree-
ment algorithm, a replay attack is impossible as the
OM2M server verifies the freshness of the token
identifier and the session key is computed using the
current timestamp.
12
• Man-in-the-middle attacks: In the subscription al-
gorithm, an attacker intercepting the subscription
and corresponding response messages is not able to
change the subscription message to a useful mes-
sage without being able to solve the ECDLP. In the
key agreement phase, an attacker is not able to cre-
ate a valid ticket, without knowledge of the com-
mon shared key between DAS and OM2M server.
In addition, the attacker cannot force the response
of the OM2M server to the client without being
able to know the secret key of either the client or
the DAS.
• Impersonation attacks are avoided thanks to the
mutual authentication feature, which is established
in both the subscription and the key agreement al-
gorithms. This is guaranteed in the subscription
algorithm thanks to the usage of a randomized ver-
sion of the Diffie Hellman key between the client
and the DAS. In the key agreement algorithm, the
authentication of a legitimate member is performed
by the OM2M server. The additional identity-
based authentication is guaranteed thanks to the
help of the DAS, who generates the session key
as a randomized Diffie Hellman key between DAS
and Client.
• Denial of service attacks become very difficult due
Table 1: The average time and 99.9% confidence interval of the EC point multiplication, EC point addition, AES 128 CCM 8 symmetric encryp-
tion/decryption and SHA256 hash function for the Zolertia RE-mote, Raspberry PI 3B and personal computer.
Device Library EC mult(µs)
tinyDTLS-
Zolertia RE-mote 993917 ± 7
microECC
ARM Cortex-M3 @
Hardware
32MHz, 32KB
Acceleration 344659 ± 7
RAM.
Engine
Raspberry PI 3B
Quad Core 1.2GHz, BouncyCastle 37943 ± 85
1GB RAM.
Personal Computer
Intel Core i7-8750H
BouncyCastle 1148.2 ± 0.8
CPU @ 2.2GHz,
16GB RAM.
to the small number of communication phases in
the algorithms. In the subscription phase on the
one hand, the DAS server can check immediately
the validity of the request and does not need to keep
sessions open. In the key agreement phase on the
other hand, also the OM2M server is able to verify
if a legitimate request is made and stop otherwise.
• Identity retrieval of the client is impossible due to
the ECDLP problem in the subscription algorithm.
Also, in the key agreement algorithm, the identity
of the client cannot be derived as the random num-
ber c or the ticket in cleartext has never been re-
vealed by the client. Also, in the response of the
OM2M server to the client, no further link to the
identity of the client is made. As such, the pro-
posed IAM protocol satisfies anonymity and un-
linkability of the client. Note that anonymity is not
included in the ECQV registration phase as it is a
one-time operation and it does not allow to derive
user behavior. It is very easy to include anonymity
in that phase by simply using public key encryption
for sending the user identities in the first step.
6. Experimental Results
To demonstrate the feasibility of the proposed IAM
system and the possibility to use constrained WSN de-
vices as clients that try to automatically access the pro-
tected resources from the OM2M IN-CSE, we evaluated
the time required to perform the cryptographic opera-
tions described previously. In addition, we measured the
required memory to include CoAP and DTLS in the IoT
protocol stack when using Contiki 3.0 operating system
for the Zolertia RE-mote.
13
EC add(µs) AES(µs) SHA256(µs)
17262 ± 8 2024 ± 7 1047 ± 7
5080 ± 8 150 ± 7 68 ± 7
181.7 ± 0.5 60.47 ± 0.07 15.50 ± 0.02
4.866 ± 0.005 2.90 ± 0.03 1.023 ± 0.002
6.1. Time cost evaluation
The time required by the IAM scheme to identify, au-
thenticate, authorize and establish a secure channel is an
essential feature that should be kept as low as possible
to improve the usability of the application. To investi-
gate the overall latency of the proposed IAM scheme,
we first performed a micro benchmarking analysis mea-
suring the time required by each cryptographic opera-
tion involved in the algorithm. We also computed the
average and 99.9% confidence interval over 40 sam-
ples for the EC point multiplication and EC point ad-
dition, the symmetric encryption/decryption using the
AES 128 CCM 8 cipher and the hash operation using
the SHA256 algorithm. For the symmetric encryption
algorithm and the hash function we used a payload size
of 128 bytes. These operations have been tested us-
ing the BouncyCastle library for a Raspberry PI 3B
and a personal computer. Regarding the Zolertia RE-
mote, we performed the aforementioned operations us-
ing the tinydtls and microECC libraries and the hard-
ware encryption engine for AES and SHA256 and the
public key acceleration engine for the EC multiplica-
tion and addition. To maximize the reliability of our
measurements, we used the Java Microbenchmark Har-
ness (JMH) toolkit to estimate the time required by the
aforementioned operations for the Raspberry PI 3B and
the personal computer. JMH eases the implementation
of benchmarks by taking into account all the optimiza-
tions that the Java Virtual Machine (JVM) applies to
the code when it is executed multiple times. JMH al-
lows us to set a number of warmup iterations before
the real measurements to exclude the effect of the code
optimizations. For the Zolertia RE-mote, we used the
real timer library to measure the cryptographic opera-
Table 2: The cryptographic operations that the client device has to perform in the three phases of the proposed IAM scheme. The total computational
time for the client device is also computed for each type of device used.

Raspberry PI
PC(ms) Zolertia RE-mote(ms)
Phase Client operations 3B(ms)
Hardware
tinydtls-
BouncyCastle BouncyCastle Acceleration
microECC
Engine
ECQV
3T m + 1T a + 2T h 3.45 114.04 1039.19 3000.06
registration
Client
3T m + 2T s + 2T h 3.45 113.98 1034.41 2987.89
subscription
Key agreement 1T m + 1T s + 2T h 1.15 38.03 344.95 998.04
7T m + 1T a +
Total 8.05 266.05 2418.55 6985.99
3T s + 6T h

tions. The results are reported in Table 1 where we

denote the EC point multiplication, EC point addition,
AES 128 CCM 8 encryption/decryption, SHA256 hash
operation as EC mult, EC add, AES and SHA respec-
tively.
To evaluate the performance of the proposed IAM
scheme, we computed the time required by the client de-
vice to establish a common session key with the OM2M
server in Table 2. Since the DAS and OM2M server
usually have high computational power, we focus on the
performance of the client device when using the per-
sonal computer, the Raspberry PI and the Zolertia RE-
mote. Table 2 reports the computational time required
during the ECQV registration phase, the client subscrip-
tion phase and the key exchange phase. The times for
the EC point multiplication, EC point addition, symmet-
ric encryption/decryption with the AES 128 CCM 8 ci-
Figure 8: The IoT protocol stack that has been used to perform exper-
pher and SHA256 hash operation are denoted by T m , iments in the Zolertia RE-mote. CoAP and DTLS have been added on
T a , T s , T h respectively. As you can see, the personal top of this protocol stack.
computer and the Raspberry PI 3B can execute all the
required operation in less than 1 second. The Zolertia
RE-mote, which is considered a constrained IoT device,
only takes around 7 seconds to perform the operations the sum of data and Block Started by Symbol (bss)
when tinydtls and microECC are used. A sensible im- sections occupied by the application must not exceed
provement can be noted when the hardware acceleration 16370 B. We measured the total RAM and ROM
engine is used. In this case the Zolertia RE-mote only needed by the client application when it uses the
takes about 2.5 seconds to execute all the cryptographic IoT protocol stack represented in Figure 8 with the
operation required by the proposed security scheme. inclusion of only CoAP, only DTLS and both the
CoAP and DTLS protocols. The measurements are
represented in Table 3. Regarding CoAP, we used
6.2. Memory consumption in constrained WSN devices
the Erbium implementation that is already included in
The Zolertia RE-mote platform was developed by Contiki 3.0, whereas the tinydtls library has been used
a group of universities and industrial partners during as implementation of DTLS. The reader can find an
the European project RERUM. It features an ARM extensive study in the performance of tinydtls for the
Cortex M3 with 32 MHz of clock speed, 512 KB of Zolertia RE-mote in our previous work Patonico et al.
ROM and 32 KB of RAM. To avoid RAM overflows, (2018). To improve the speed of EC operations in the
14
Table 3: The RAM and ROM consumption when including CoAP
and DTLS in the IoT protocol stack of Contiki 3.0 operating
system for the Zolertia RE-mote platform. The Erbium library
has been used for CoAP, whereas tinydtls+microECC implements
DTLS when using an EC-based cipher suite to perform the hand-
shake.
CoAP DTLS CoAP+DTLS
RAM(B) 13129 13527 16142
ROM(B) 54270 68757 89820
constrained Zolertia RE-mote, we replaced the standard
ECC implementation of tinydtls with the microECC
library. Although microECC increases the RAM
consumption of DTLS of about 150 B, it speeds up the
EC multiplication operation almost 10 times. This way,
it is possible to perform the DTLS handshake using
the TLS ECDHE ECDSA WITH AES 128 CCM 8
cipher suite in few seconds.
The inclusion of both CoAP and DTLS heavily uses
the RAM of the device by provoking the overflow. To
avoid this, we needed to modify the standard values of
some of the variables defined in Contiki 3.0. The ap-
plied modifications are reported in Table 4. Note the
necessary increase in the stack space to avoid unwanted
reboots during the DTLS handshake.
7. Conclusion
The interoperability offered by the oneM2M stan-
dard is an essential feature for many M2M applica-
tions which adopt heterogeneous hardware and differ-
ent communication technologies. However, the security
of oneM2M-based architectures should be carefully de-
signed and implemented to avoid unauthorized data ac-
cess and leakage of private information. In this paper we
propose two solutions to enhance the security features
of the OM2M platform. First, we integrated the CoAPS
binding to secure the communication between OM2M
gateway and WSN devices. Following the principles of
the indirect dynamic authorization system suggested in
the oneM2M standard, we designed and implemented
a lightweight anonymous IAM system for the OM2M
platform to allow client devices and OM2M server to
establish a trust relationship as well as a secure chan-
nel. Since the proposed scheme only uses lightweight
cryptographic operations, the computational complex-
ity to provide client authentication, client authorization
and the key agreement is very low. To perform all the re-
quired cryptographic operations the client device needs
Table 4: The modified configuration parameters of the IoT protocol stack
used in Contiki 3.0 for the client application running in the Zolertia RE-
mote.
Configuration parameter Value
REST MAX CHUNK SIZE 128
COAP MAX OPEN TRANSACTIONS 2
UIP CONF BUFFER SIZE 500
NBR TABLE CONF MAX NEIGHBORS 3
UIP CONF MAX ROUTES 3
stack array in startup-gcc.c 320
about 8 ms when the personal computer is used and 266
ms for a Raspberry PI 3B. We prove that the scheme can
be used even for constrained clients such as a Zolertia
RE-motes. Indeed, it only takes 7 seconds to perform
all the cryptographic operations involved in the security
scheme on these devices when tinydtls and microECC
are used. This time can be reduced to 2.5 seconds if the
cryptographic operations are performed with the hard-
ware acceleration engine of the Zolertia RE-mote.
References
Balfour, R.E., 2015. Building the ”Internet of Everything” (IoE)
for first responders, in: 2015 Long Island Systems, Applications
and Technology, IEEE. pp. 1–6. URL: http://ieeexplore.
ieee.org/document/7160172/, doi:10.1109/LISAT.2015.
7160172.
Brown, D.R.L., Gallant, R., Vanstone, S.A., 2002. Provably Se-
cure Implicit Certificate Schemes, Springer, Berlin, Heidelberg,
pp. 156–165. URL: http://link.springer.com/10.1007/
3-540-46088-8{\_}15, doi:10.1007/3-540-46088-8_15.
Capossele, A., Cervo, V., De Cicco, G., Petrioli, C., 2015. Security
as a CoAP resource: An optimized DTLS implementation for the
IoT, in: 2015 IEEE International Conference on Communications
(ICC), IEEE. pp. 549–554. URL: http://ieeexplore.ieee.
org/document/7248379/, doi:10.1109/ICC.2015.7248379.
Corici, A., Elmangoush, A., Steinke, R., Magedanz, T., Mwangama,
J., Ventura, N., 2014. Utilizing M2M Technologies for Build-
ing Reliable Smart Cities, in: 2014 6th International Confer-
ence on New Technologies, Mobility and Security (NTMS), IEEE.
pp. 1–5. URL: http://ieeexplore.ieee.org/document/
6814059/, doi:10.1109/NTMS.2014.6814059.
Elmangoush, A., Al-Hezmi, A., Magedanz, T., 2014. The devel-
opment of M2M standards for ubiquitous sensing service layer,
in: 2014 IEEE Globecom Workshops (GC Wkshps), IEEE. pp.
624–629. URL: http://ieeexplore.ieee.org/document/
7063502/, doi:10.1109/GLOCOMW.2014.7063502.
Fotiou, N., Kotsonis, T., Marias, G.F., Polyzos, G.C., 2016. Ac-
cess Control for the Internet of Things, in: 2016 International
Workshop on Secure Internet of Things (SIoT), IEEE. pp. 29–38.
URL: http://ieeexplore.ieee.org/document/7913563/,
doi:10.1109/SIoT.2016.010.
Gope, P., Hwang, T., 2016. A Realistic Lightweight Anony-
mous Authentication Protocol for Securing Real-Time Applica-
tion Data Access in Wireless Sensor Networks. IEEE Transac-
tions on Industrial Electronics 63, 7124–7132. URL: http://
15
 ieeexplore.ieee.org/document/7500072/, doi:10.1109/
TIE.2016.2585081.
Granjal, J., Monteiro, E., 2016. End-to-end transparent transport-layer
security for Internet-integrated mobile sensing devices, in: 2016
IFIP Networking Conference (IFIP Networking) and Workshops,
IEEE. pp. 306–314. URL: http://ieeexplore.ieee.org/
document/7497235/, doi:10.1109/IFIPNetworking.2016.
7497235.
Hsu, Y.H., Lin, F.J., 2017. Preventing Misuse of Duplicate Certifi-
cates in IoT/M2M Systems, in: 2017 26th International Confer-
ence on Computer Communication and Networks (ICCCN), IEEE.
pp. 1–8. URL: http://ieeexplore.ieee.org/document/
8038508/, doi:10.1109/ICCCN.2017.8038508.
Indu, I., Anand, P.M.R., 2016. Hybrid authentication and au-
thorization model for web based applications, in: 2016 Inter-
national Conference on Wireless Communications, Signal Pro-
cessing and Networking (WiSPNET), IEEE. pp. 1187–1191.
URL: http://ieeexplore.ieee.org/document/7566324/,
doi:10.1109/WiSPNET.2016.7566324.
Jan, M.A., Zhang, W., Usman, M., Tan, Z., Khan, F.,
Luo, E., 2019. SmartEdge: An end-to-end encryp-
tion framework for an edge-enabled smart city applica-
tion. Journal of Network and Computer Applications
137, 1–10. URL: https://www.sciencedirect.com/
science/article/pii/S1084804519300827, doi:10.1016/
J.JNCA.2019.02.023.
Kim, H., Lee, E.A., 2017. Authentication and Authorization for the
Internet of Things. IT Professional 19, 27–33. URL: http://
ieeexplore.ieee.org/document/8057722/, doi:10.1109/
MITP.2017.3680960.
Lee, C., Nkenyereye, L., Sung, N., Song, J., 2018. To-
wards a Blockchain-enabled IoT Platform using oneM2M Stan-
dards, in: 2018 International Conference on Information and
Communication Technology Convergence (ICTC), IEEE. pp.
97–102. URL: https://ieeexplore.ieee.org/document/
8539724/, doi:10.1109/ICTC.2018.8539724.
Li, J., Zhang, W., Dabra, V., Choo, K.K.R., Kumari, S., Hogrefe,
D., 2019. AEP-PPA: An anonymous, efficient and provably-
secure privacy-preserving authentication protocol for mobile ser-
vices in smart cities. Journal of Network and Computer Applica-
tions 134, 52–61. URL: https://www.sciencedirect.com/
science/article/pii/S1084804519300475, doi:10.1016/
J.JNCA.2019.02.003.
Liu, J.K., Au, M.H., Huang, X., Lu, R., Li, J., 2016. Fine-
Grained Two-Factor Access Control for Web-Based Cloud Com-
puting Services. IEEE Transactions on Information Forensics and
Security 11, 484–497. URL: http://ieeexplore.ieee.org/
document/7305762/, doi:10.1109/TIFS.2015.2493983.
Naik, N., Jenkins, P., 2016. A Secure Mobile Cloud Identity:
Criteria for Effective Identity and Access Management Stan-
dards, in: 2016 4th IEEE International Conference on Mo-
bile Cloud Computing, Services, and Engineering (MobileCloud),
IEEE. pp. 89–90. URL: http://ieeexplore.ieee.org/
lpdocs/epic03/wrapper.htm?arnumber=7474415, doi:10.
1109/MobileCloud.2016.22.
Neisse, R., Baldini, G., Steri, G., Ahmad, A., Fourneret, E., Leg-
eard, B., 2017. Improving Internet of Things device certification
with policy-based management, in: 2017 Global Internet of Things
Summit (GIoTS), IEEE. pp. 1–6. URL: http://ieeexplore.
ieee.org/document/8016273/, doi:10.1109/GIOTS.2017.
8016273.
Oh, S.R., Kim, Y.G., 2017. Development of IoT security com-
ponent for interoperability, in: 2017 13th International Com-
puter Engineering Conference (ICENCO), IEEE. pp. 41–44.
URL: http://ieeexplore.ieee.org/document/8289760/,
16
doi:10.1109/ICENCO.2017.8289760.
oneM2M, 2012. oneM2M - Home. URL: http://www.onem2m.
org/.
Park, C.S., 2017. A Secure and Efficient ECQV Implicit Cer-
tificate Issuance Protocol for the Internet of Things Applica-
tions. IEEE Sensors Journal 17, 2215–2223. URL: http://
ieeexplore.ieee.org/document/7737016/, doi:10.1109/
JSEN.2016.2625821.
Patonico, S., Nguyen, T.L., Placide, S., An, B., Kris, S., 2018. DTLS
Integration in oneM2M based on Zolertia RE-motes, in: The 4th
International Conference on Cloud Computing Technologies and
Applications.
Qu, M.V.S.A., 2000. Implicit certificate scheme. URL: https://
patents.google.com/patent/US6792530.
Research, C., 2009. Standards for Efficient Cryptography SEC 1:
Elliptic Curve Cryptography. Technical Report. URL: https:
//www.secg.org/sec1-v2.pdf.
rfcDTLS, 2012. RFC 6347 - Datagram Transport Layer Secu-
rity Version 1.2 URL: http://www.rfc-editor.org/info/
rfc6347.
Staudemeyer, R.C., Pohls, H.C., Wojcik, M., 2018. The Road to
Privacy in IoT: Beyond Encryption and Signatures, Towards Un-
observable Communication, in: 2018 IEEE 19th International
Symposium on ”A World of Wireless, Mobile and Multimedia
Networks” (WoWMoM), IEEE. pp. 14–20. URL: https://
ieeexplore.ieee.org/document/8449779/, doi:10.1109/
WoWMoM.2018.8449779.
Sun, G., Sun, S., Sun, J., Yu, H., Du, X., Guizani, M., 2019. Se-
curity and privacy preservation in fog-based crowd sensing on the
internet of vehicles. Journal of Network and Computer Applica-
tions 134, 89–99. URL: https://www.sciencedirect.com/
science/article/pii/S1084804519300694, doi:10.1016/
J.JNCA.2019.02.018.
Swetina, J., Lu, G., Jacobs, P., Ennesser, F., Song, J., 2014. To-
ward a standardized common M2M service layer platform: Intro-
duction to oneM2M. IEEE Wireless Communications 21, 20–26.
URL: http://ieeexplore.ieee.org/document/6845045/,
doi:10.1109/MWC.2014.6845045.
Van den Abeele, F., Vandewinckele, T., Hoebeke, J., Moerman,
I., Demeester, P., 2015. Secure communication in IP-based
wireless sensor networks via a trusted gateway, in: 2015 IEEE
Tenth International Conference on Intelligent Sensors, Sensor
Networks and Information Processing (ISSNIP), IEEE. pp. 1–6.
URL: http://ieeexplore.ieee.org/document/7106963/,
doi:10.1109/ISSNIP.2015.7106963.
Wu, C.W., Lin, F.J., Wang, C.H., Chang, N., 2017. OneM2M-
based IoT protocol integration, in: 2017 IEEE Conference on Stan-
dards for Communications and Networking (CSCN), IEEE. pp.
252–257. URL: http://ieeexplore.ieee.org/document/
8088630/, doi:10.1109/CSCN.2017.8088630.
Younis, Y.A., Kifayat, K., Merabti, M., 2015. A novel evaluation
criteria to cloud based access control models, in: 2015 11th In-
ternational Conference on Innovations in Information Technol-
ogy (IIT), IEEE. pp. 68–73. URL: http://ieeexplore.ieee.
org/document/7381517/, doi:10.1109/INNOVATIONS.2015.
7381517.
*Author Biography

Simone Patonico obtained the Bachelor and Master degree in Electronics Engineering
from Università Politecnica delle Marche (UNIVPM) respectively in 2014 and 2017.
Currently, he is a Ph.D. student under the supervision of Prof. Kris Steenhaut and Prof.
An Braeken at the Department of Electronics and Informatics (ETRO) at Vrije
Universiteit Brussel (VUB). As member of the research group, he worked on the
Horizontal-IoT project to investigate the interoperability between different application
protocols using the oneM2M standard. He also contributed to the Inter-OM2M project
which focuses on the creation of a common middleware to link different interoperable
frameworks. His research interests include the investigation, design and implementation of
communication and security protocols in wireless sensor networks.
*Conflict of Interest

Declaration of interests

☒ The authors declare that they have no known competing financial interests or personal relationships
that could have appeared to influence the work reported in this paper.

☐The authors declare the following financial interests/personal relationships which may be considered
as potential competing interests:

Simone Patonico