2016 IEEE 5th Global Conference on Consumer Electronics
An ARM-Compliant IoT Platform: Security by
Design for the Smart Home
Victoria Beltran, Juan A. Martinez, Antonio Skarmeta
Department of Info. and Communications Engineering
Computer Science Faculty, University of Murcia
Murcia, Spain
{vbm5, juanantonio, skarmeta}@um.es
AbstractIoT heterogeneity and diversity have
promoted the creation of different and isolated IoT
systems. The EU has funded several research projects in
order to promote interoperability and quality aspects for
IoT platforms. More significantly, the IoT-ARM was
conceived as a reference architecture to derive concrete
IoT platforms and establish a common understanding on
quality requirements between different platforms. This
paper describes SMARTIE, an IoT platform that is
compliant with the IoT-ARM and promotes the most
important quality aspects for the Smart Home, that is,
security and interoperability.
KeywordsInternet of things; IoT; ARM; Security
I. INTRODUCTION
The Internet of Things (IoT) is intrinsically adhered to
heterogeneity. There is a plethora of IoT application domains
and for any of them, each specific application needs to
handle with its own diversity in device characteristics,
communication technologies, required functionalities, and so
on. Vertical solutions are designed to accomplish their own
goals and many times renounce quality aspects such as
security and interoperability to minimize costs.
A recent report [1] demonstrates that several home smart
locks present weaknesses that allow attackers unlock doors.
Another report [2] has found security issues in different
smart home products such as smart switches, LEDs and
audio receivers. Video cameras (including security cameras
and baby cameras) have been left open to online viewing1.
Although IoT security is being developed at all the protocol
stack levels through IETF Working Groups such as ROLL,
CoRE, and ACE, the security features of real IoT products
are in most cases very limited.
The lack of interoperability between IoT providers in smart
homes makes Do-It-Yourself painful and not compensatory
since different providers devices cannot interoperate and
hence offer advanced services. Thus, to enjoy fancier and
smarter functionality, smart home users need to keep on a
This paper has been also possible partially by the EU FP7 Smartie Project
and the Spanish National Project EDISON (TIN2014-52099-R).
1
https://www.ftc.gov/news-events/press-releases/2013/09/marketer-
internet-connected-home-security-video-cameras-settles

978-1-5090-2333-2/16/$31.00 2016 IEEE
Pedro Martinez-Julia
Network Science and Convergence Device Technology Lab.
Network System Research Institute
National Institute of Info. and Comm. Technology (NICT)
Tokyo, Japan
pedro@nict.go.jp
single vendors side by acquiring prepackaged kits that
interconnects the vendors devices with its cloud service.
For the sake of interoperability in IoT, the European
Union (EU) has invested efforts on several FP7-programme-
funded projects in the last few years [3]. Notably, in 2010 the
IoT-Architecture (IoT-A) project started with the aim of
developing a reference architecture which was finally
released in 2012 with the name IoT Architectural Reference
Model (IoT-ARM) [3]. Nevertheless, works that show the
application of the IoT-ARM are almost non-existent. To the
best of our knowledge, only the authors of [5] show to a
limited extent their ARM-compliant architecture.
Security and interoperability are two key quality aspects
whose absence in IoT solutions can seriously hold back the
adoption and success of the IoT in any application domain,
including smart homes. Indeed, the Internet Society has
recently brought the IoT perils on interoperability and
security into the open [6].
This short paper introduces SMARTIE, an IoT platform
that promotes security and interoperability in IoT scenarios.
In particular, we highlight the use case of SMARTIE for
smart homes.
II. THE IOT-ARM AND SMARTIE
The IoT-ARM provides a reference framework that
permits to guarantee the quality of IoT platforms, compare
platforms and measure their level of interoperability. The
IoT-ARM addresses the different phases of the architecting
process by providing inputs (e.g., guidance, examples,
common semantics, etc.) that can greatly help architects to
design their IoT systems. It was conceived as an abstract and
application-independent reference framework in order to
support the generation process of IoT architectures in any
IoT domain. Thus, the IoT-ARM defines high-level
concepts, semantics, and functions that are common to any
platform through two main blocks [3]: the IoT Reference
Model and the IoT Reference Architecture. Another essential
contribution of the IoT-ARM is its guidance and supporting
material for the derivation of concrete architectural views.
The SMARTIE architecture [7] has been derived from
the IoT-ARM by paying special attention to the ARMs
Trust, Security and Privacy perspective. It is organized
through the ARM functional groups (FG) and Functional

Components (FCs), as shown in Figure 1. The rightmost
column is the Security FG, which contains different security-
related components such as XACML for security policies,
DCapBAC [8] for decentralized, self-contained authorization
tokens, and CP-ABE for encryption-based authorization [9].
Thus, the resulting SMARTIE platform is compliant with
many of the ARM requirements on security and privacy.
III. USE CASES
The IETF has recently released the RFC 7744 [8] to
booster the discussion on uses cases for authorization in IoT.
Home automation is one of the seven application domains
addressed by this document. In particular, the use case whose
goal is to let homeowners to allow visitors to come into his
house through smart locks has been paid special attention.
Let us begin with the description of the main SMARTIE
architecture components and their interaction involved in this
use case. A smart house is equipped with the public key of
its security authority, what we call Capability Manager (CM)
in SMARTIE terminology. This CM relies on a Policy
Decision Point (PDP) that handles the systems security
policies, which in turn are handled through XACML. Smart
locks provide information about the access requests (i.e.,
access log) to the IoT Broker. Based on CP-ABE, the IoT
broker can inform subscribers about smart locks events (e.g.
suspicious access event) in an efficient and confidential way
by applying encryption-based authorization.
SMARTIE promotes interoperability in the smart house
since IETF communication protocols are used (i.e.
CoAP/DTLS or MQTT) and any sensor deployed into the
house can been registered into the Resource Directory
component that offers a CoAP-compliant discovery method.
When the homeowner wishes to delegate authorization to
a visitor, he uses his mobile application to access the system
and generates a new security policy through the PDP
component for allowing the visitor to enter his house (by
specifying the period of time for such permission and
possibly the authorized areas within the house). Note that
SMARTIE is an integrating infrastructure and hence is
independent from any front-end GUI such as mobile apps.
Later on, the visitor logs into the system and (after
authentication) requests the CM authorization to get into the
homeowners house. When the CM verifies the
2016 IEEE 5th Global Conference on Consumer Electronics
homeowners authorization through the PDP, it replies the
visitor with a capability token (CT) that contains the access
control rules set by the homeowner.
When the visitor goes to the host house, he uses his
mobile application to sign the CT with his private key and
present it to the houses smart lock. The lock validated the
token by verifying both the CMs and the visitors signatures
on the token. Thus, the smart lock can locally guarantee that
the CM has authorized the client that is trying to use the
token. If both authentication and authorization are right, the
visitor will be able to enter the house enjoying his authorized
areas during that specific period of time.
Different members of the homeowners family have
subscribed to the smart lock through the IoT broker. Thus,
they have obtained the attributes that are necessary to
decrypt notifications from the smart lock. When the visitor
presents its token to the smart lock, the latter notifies the IoT
which will automatically notify all the subscribers.
Authorization is implicit by the capability of the subscribers
to decrypt the content of notifications through CP-ABE
based on their attributes.
IV. CONCLUSION
In this short paper, we have presented SMARTIE
architecture, an IoT-ARM complaint architecture aimed to
provide security and privacy in the information provided by
sensors integrated in it. As an example we have described the
interaction of different components of this architecture for a
representative use case of the Smart Home domain.
REFERENCES
[1] Ho, G., Leung, D., Mishra, P., Hosseini, A., Song, D., & Wagner, D.
(2016). Smart Locks: Lessons for Securing Commodity Internet of
Things Devices.
[2] BitDefender Research Paper The internet of things: Risks in the
Connected Home, February 2006. Online at:
http://download.bitdefender.com/resources/files/News/CaseStudies/st
udy/87/Bitdefender-2016-IoT-A4-en-EN-web.pdf
[3] Krco, S., Pokric, B., & Carrez, F. (2014, March). Designing IoT
architecture (s): A European perspective. In Internet of Things (WF-
IoT), 2014 IEEE World Forum on (pp. 79-84). IEEE.
[4] Bassi, A., Bauer, M., Fiedler, M., Kramp, T., Van Kranenburg, R.,
Lange, S., & Meissner, S. (2013). Enabling things to talk. Designing
IoT Solutions With the IoT Architectural Reference Model, 163-211.
[5] Fernandes, J., Nati, M., Loumis, N. S., Nikoletseas, S., Raptis, T. P.,
Krco, S., ... & Ziegler, S. (2015, April). IoT Lab: Towards co-design
and IoT solution testing using the crowd. In Recent Advances in
Internet of Things (RIoT), 2015 International Conference on (pp. 1-
6). IEEE.
[6] The Internet Society, The Internet of Things: An Overview.
Understanding the issues and challenges of a more connected world,
October 2015. Online at: http://www.internetsociety.org/doc/iot-
overview
[7] SMARTIE Initial Architecture Specification, SMARTIE project
Deliverable 2.3, http://www.smartie-project.eu/download/D2.3-
Initial%20Architecture%20Specification.pdf.
[8] Gerdes, S., Seitz, L., Selander, G., Mani, M., & Kumar, S. (2016).
Use Cases for Authentication and Authorization in Constrained
Environments (No. RFC 7744).