< draft-irtf-t2trg-iot-seccons-16.txt   rfc8576.txt 
Network Working Group O. Garcia-Morchon Internet Research Task Force (IRTF) O. Garcia-Morchon
Internet-Draft Philips IP&S Request for Comments: 8576 Philips
Intended status: Informational S. Kumar Category: Informational S. Kumar
Expires: June 16, 2019 Philips Research ISSN: 2070-1721 Signify
M. Sethi M. Sethi
Ericsson Ericsson
December 13, 2018 April 2019
State-of-the-Art and Challenges for the Internet of Things Security Internet of Things (IoT) Security: State of the Art and Challenges
draft-irtf-t2trg-iot-seccons-16
Abstract Abstract
The Internet of Things (IoT) concept refers to the usage of standard The Internet of Things (IoT) concept refers to the usage of standard
Internet protocols to allow for human-to-thing and thing-to-thing Internet protocols to allow for human-to-thing and thing-to-thing
communication. The security needs for IoT systems are well- communication. The security needs for IoT systems are well
recognized and many standardization steps to provide security have recognized, and many standardization steps to provide security have
been taken, for example, the specification of Constrained Application been taken -- for example, the specification of the Constrained
Protocol (CoAP) secured with Datagram Transport Layer Security Application Protocol (CoAP) secured with Datagram Transport Layer
(DTLS). However, security challenges still exist, not only because Security (DTLS). However, security challenges still exist, not only
there are some use cases that lack a suitable solution, but also because there are some use cases that lack a suitable solution, but
because many IoT devices and systems have been designed and deployed also because many IoT devices and systems have been designed and
with very limited security capabilities. In this document, we first deployed with very limited security capabilities. In this document,
discuss the various stages in the lifecycle of a thing. Next, we we first discuss the various stages in the lifecycle of a thing.
document the security threats to a thing and the challenges that one Next, we document the security threats to a thing and the challenges
might face to protect against these threats. Lastly, we discuss the that one might face to protect against these threats. Lastly, we
next steps needed to facilitate the deployment of secure IoT systems. discuss the next steps needed to facilitate the deployment of secure
This document can be used by implementors and authors of IoT IoT systems. This document can be used by implementers and authors
specifications as a reference for details about security of IoT specifications as a reference for details about security
considerations while documenting their specific security challenges, considerations while documenting their specific security challenges,
threat models, and mitigations. threat models, and mitigations.
This document is a product of the IRTF Thing-to-Thing Research Group This document is a product of the IRTF Thing-to-Thing Research Group
(T2TRG). (T2TRG).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Research Task Force
and may be updated, replaced, or obsoleted by other documents at any (IRTF). The IRTF publishes the results of Internet-related research
time. It is inappropriate to use Internet-Drafts as reference and development activities. These results might not be suitable for
material or to cite them other than as "work in progress." deployment. Documents approved for publication by the IRSG are not
candidates for any level of Internet Standard; see Section 2 of RFC
7841.
This Internet-Draft will expire on June 16, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8576.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document.
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Thing Lifecycle . . . . . . . . . . . . . . . . . . . . . 4 2. The Thing Lifecycle . . . . . . . . . . . . . . . . . . . . . 5
3. Security Threats and Managing Risk . . . . . . . . . . . . . 7 3. Security Threats and Managing Risk . . . . . . . . . . . . . 8
4. State-of-the-Art . . . . . . . . . . . . . . . . . . . . . . 11 4. State of the Art . . . . . . . . . . . . . . . . . . . . . . 13
4.1. IP-based IoT Protocols and Standards . . . . . . . . . . 11 4.1. IP-Based IoT Protocols and Standards . . . . . . . . . . 13
4.2. Existing IP-based Security Protocols and Solutions . . . 14 4.2. Existing IP-Based Security Protocols and Solutions . . . 16
4.3. IoT Security Guidelines . . . . . . . . . . . . . . . . . 16 4.3. IoT Security Guidelines . . . . . . . . . . . . . . . . . 18
5. Challenges for a Secure IoT . . . . . . . . . . . . . . . . . 19 5. Challenges for a Secure IoT . . . . . . . . . . . . . . . . . 21
5.1. Constraints and Heterogeneous Communication . . . . . . . 19 5.1. Constraints and Heterogeneous Communication . . . . . . . 21
5.1.1. Resource Constraints . . . . . . . . . . . . . . . . 19 5.1.1. Resource Constraints . . . . . . . . . . . . . . . . 21
5.1.2. Denial-of-Service Resistance . . . . . . . . . . . . 20 5.1.2. Denial-of-Service Resistance . . . . . . . . . . . . 22
5.1.3. End-to-end security, protocol translation, and the 5.1.3. End-to-End Security, Protocol Translation, and the
role of middleboxes . . . . . . . . . . . . . . . . . 21 Role of Middleboxes . . . . . . . . . . . . . . . . . 23
5.1.4. New network architectures and paradigm . . . . . . . 23 5.1.4. New Network Architectures and Paradigm . . . . . . . 25
5.2. Bootstrapping of a Security Domain . . . . . . . . . . . 23 5.2. Bootstrapping of a Security Domain . . . . . . . . . . . 25
5.3. Operational Challenges . . . . . . . . . . . . . . . . . 24 5.3. Operational Challenges . . . . . . . . . . . . . . . . . 25
5.3.1. Group Membership and Security . . . . . . . . . . . . 24 5.3.1. Group Membership and Security . . . . . . . . . . . . 26
5.3.2. Mobility and IP Network Dynamics . . . . . . . . . . 25 5.3.2. Mobility and IP Network Dynamics . . . . . . . . . . 27
5.4. Secure software update and cryptographic agility . . . . 26 5.4. Secure Software Update and Cryptographic Agility . . . . 27
5.5. End-of-Life . . . . . . . . . . . . . . . . . . . . . . . 28 5.5. End-of-Life . . . . . . . . . . . . . . . . . . . . . . . 30
5.6. Verifying device behavior . . . . . . . . . . . . . . . . 28 5.6. Verifying Device Behavior . . . . . . . . . . . . . . . . 30
5.7. Testing: bug hunting and vulnerabilities . . . . . . . . 29 5.7. Testing: Bug Hunting and Vulnerabilities . . . . . . . . 31
5.8. Quantum-resistance . . . . . . . . . . . . . . . . . . . 30 5.8. Quantum-Resistance . . . . . . . . . . . . . . . . . . . 32
5.9. Privacy protection . . . . . . . . . . . . . . . . . . . 31 5.9. Privacy Protection . . . . . . . . . . . . . . . . . . . 33
5.10. Reverse engineering considerations . . . . . . . . . . . 32 5.10. Reverse-Engineering Considerations . . . . . . . . . . . 34
5.11. Trustworthy IoT Operation . . . . . . . . . . . . . . . . 33 5.11. Trustworthy IoT Operation . . . . . . . . . . . . . . . . 35
6. Conclusions and Next Steps . . . . . . . . . . . . . . . . . 36
6. Conclusions and Next Steps . . . . . . . . . . . . . . . . . 34 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 9. Informative References . . . . . . . . . . . . . . . . . . . 37
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50
10. Informative References . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
The Internet of Things (IoT) denotes the interconnection of highly The Internet of Things (IoT) denotes the interconnection of highly
heterogeneous networked entities and networks that follow a number of heterogeneous networked entities and networks that follow a number of
different communication patterns such as: human-to-human (H2H), different communication patterns, such as: human-to-human (H2H),
human-to-thing (H2T), thing-to-thing (T2T), or thing-to-things human-to-thing (H2T), thing-to-thing (T2T), or thing-to-things
(T2Ts). The term IoT was first coined by the Auto-ID center (T2Ts). The term "IoT" was first coined in 1999 by the Auto-ID
[AUTO-ID] in 1999 which had envisioned a world where every physical center [AUTO-ID], which had envisioned a world where every physical
object is tagged with a radio-frequency identification (RFID) tag object has a radio-frequency identification (RFID) tag with a
having a globally unique identifier. This would not only allow globally unique identifier. This would not only allow tracking of
tracking of objects in real-time but also allow querying of data objects in real time but also allow querying of data about them over
about them over the Internet. However, since then, the meaning of the Internet. However, since then, the meaning of the Internet of
the Internet of Things has expanded and now encompasses a wide Things has expanded and now encompasses a wide variety of
variety of technologies, objects and protocols. It is not surprising technologies, objects, and protocols. It is not surprising that the
that the IoT has received significant attention from the research IoT has received significant attention from the research community to
community to (re)design, apply, and use standard Internet technology (re)design, apply, and use standard Internet technology and protocols
and protocols for the IoT. for the IoT.
The things that are part of the Internet of Things are computing The things that are part of the Internet of Things are computing
devices that understand and react to the environment they reside in. devices that understand and react to the environment they reside in.
These things are also often referred to as smart objects or smart These things are also often referred to as smart objects or smart
devices. The introduction of IPv6 [RFC6568] and CoAP [RFC7252] as devices. The introduction of IPv6 [RFC6568] and CoAP [RFC7252] as
fundamental building blocks for IoT applications allows connecting fundamental building blocks for IoT applications allows connecting
IoT hosts to the Internet. This brings several advantages including: IoT hosts to the Internet. This brings several advantages,
(i) a homogeneous protocol ecosystem that allows simple integration including: (i) a homogeneous protocol ecosystem that allows simple
with other Internet hosts; (ii) simplified development for devices integration with other Internet hosts; (ii) simplified development
that significantly vary in their capabilities; (iii) a unified for devices that significantly vary in their capabilities; (iii) a
interface for applications, removing the need for application-level unified interface for applications, removing the need for
proxies. These building blocks greatly simplify the deployment of application-level proxies. These building blocks greatly simplify
the envisioned scenarios which range from building automation to the deployment of the envisioned scenarios, which range from building
production environments and personal area networks. automation to production environments and personal area networks.
This document presents an overview of important security aspects for This document presents an overview of important security aspects for
the Internet of Things. We begin by discussing the lifecycle of a the Internet of Things. We begin by discussing the lifecycle of a
thing in Section 2. In Section 3, we discuss security threats for thing in Section 2. In Section 3, we discuss security threats for
the IoT and methodologies for managing these threats when designing a the IoT and methodologies for managing these threats when designing a
secure system. Section 4 reviews existing IP-based (security) secure system. Section 4 reviews existing IP-based (security)
protocols for the IoT and briefly summarizes existing guidelines and protocols for the IoT and briefly summarizes existing guidelines and
regulations. Section 5 identifies remaining challenges for a secure regulations. Section 5 identifies remaining challenges for a secure
IoT and discusses potential solutions. Section 6 includes final IoT and discusses potential solutions. Section 6 includes final
remarks and conclusions. This document can be used by IoT standards remarks and conclusions. This document can be used by IoT standards
specifications as a reference for details about security specifications as a reference for details about security
considerations applying to the specified system or protocol. considerations that apply to the specified system or protocol.
The first draft version of this document was submitted in March 2011. The first draft version of this document was submitted in March 2011.
Initial draft versions of this document were presented and discussed Initial draft versions of this document were presented and discussed
during the CORE meetings at IETF 80 and later. Discussions on during the meetings of the Constrained RESTful Environments (CORE)
security lifecycle at IETF 92 (March 2015) evolved into more general Working Group at IETF 80 and later. Discussions on security
security considerations. Thus, the draft was selected to address the lifecycle at IETF 92 (March 2015) evolved into more general security
T2TRG work item on the security considerations and challenges for the considerations. Thus, the draft was selected to address the T2TRG
work item on the security considerations and challenges for the
Internet of Things. Further updates of the draft were presented and Internet of Things. Further updates of the draft were presented and
discussed during the T2TRG meetings at IETF 96 (July 2016) and IETF discussed during the T2TRG meetings at IETF 96 (July 2016) and IETF
97 (November 2016) and at the joint interim in Amsterdam (March 97 (November 2016) and at the joint interim meeting in Amsterdam
2017). This document has been reviewed by, commented on, and (March 2017). This document has been reviewed by, commented on, and
discussed extensively for a period of nearly six years by a vast discussed extensively for a period of nearly six years by a vast
majority of T2TRG and related group members; the number of which majority of the T2TRG and related group members, the number of which
certainly exceeds 100 individuals. It is the consensus of T2TRG that certainly exceeds 100 individuals. It is the consensus of T2TRG that
the security considerations described in this document should be the security considerations described in this document should be
published in the IRTF Stream of the RFC series. This document does published in the IRTF Stream of the RFC series. This document does
not constitute a standard. not constitute a standard.
2. The Thing Lifecycle 2. The Thing Lifecycle
The lifecycle of a thing refers to the operational phases of a thing The lifecycle of a thing refers to the operational phases of a thing
in the context of a given application or use case. Figure 1 shows in the context of a given application or use case. Figure 1 shows
the generic phases of the lifecycle of a thing. This generic the generic phases of the lifecycle of a thing. This generic
lifecycle is applicable to very different IoT applications and lifecycle is applicable to very different IoT applications and
scenarios. For instance, [RFC7744] provides an overview of relevant scenarios. For instance, [RFC7744] provides an overview of relevant
IoT use cases. IoT use cases.
In this document, we consider a Building Automation and Control (BAC) In this document, we consider a Building Automation and Control (BAC)
system to illustrate the lifecycle and the meaning of these different system to illustrate the lifecycle and the meaning of these different
phases. A BAC system consists of a network of interconnected nodes phases. A BAC system consists of a network of interconnected nodes
that performs various functions in the domains of HVAC (Heating, that performs various functions in the domains of Heating,
Ventilating, and Air Conditioning), lighting, safety, etc. The nodes Ventilating, and Air Conditioning (HVAC), lighting, safety, etc. The
vary in functionality and a large majority of them represent nodes vary in functionality, and a large majority of them represent
resource-constrained devices such as sensors and luminaries. Some resource-constrained devices such as sensors and luminaries. Some
devices may be battery operated or may rely on energy harvesting. devices may be battery operated or may rely on energy harvesting.
This requires us to also consider devices that sleep during their This requires us to also consider devices that sleep during their
operation to save energy. In our BAC scenario, the life of a thing operation to save energy. In our BAC scenario, the life of a thing
starts when it is manufactured. Due to the different application starts when it is manufactured. Due to the different application
areas (i.e., HVAC, lighting, or safety) nodes/things are tailored to areas (i.e., HVAC, lighting, or safety), nodes/things are tailored to
a specific task. It is therefore unlikely that one single a specific task. It is therefore unlikely that one single
manufacturer will create all nodes in a building. Hence, manufacturer will create all nodes in a building. Hence,
interoperability as well as trust bootstrapping between nodes of interoperability as well as trust bootstrapping between nodes of
different vendors is important. different vendors is important.
The thing is later installed and commissioned within a network by an The thing is later installed and commissioned within a network by an
installer during the bootstrapping phase. Specifically, the device installer during the bootstrapping phase. Specifically, the device
identity and the secret keys used during normal operation may be identity and the secret keys used during normal operation may be
provided to the device during this phase. Different subcontractors provided to the device during this phase. Different subcontractors
may install different IoT devices for different purposes. may install different IoT devices for different purposes.
Furthermore, the installation and bootstrapping procedures may not be Furthermore, the installation and bootstrapping procedures may not be
a discrete event and may stretch over an extended period. After a discrete event and may stretch over an extended period. After
being bootstrapped, the device and the system of things are in being bootstrapped, the device and the system of things are in
operational mode and execute the functions of the BAC system. During operational mode and execute the functions of the BAC system. During
this operational phase, the device is under the control of the system this operational phase, the device is under the control of the system
owner and used by multiple system users. For devices with lifetimes owner and used by multiple system users. For devices with lifetimes
spanning several years, occasional maintenance cycles may be spanning several years, occasional maintenance cycles may be
required. During each maintenance phase, the software on the device required. During each maintenance phase, the software on the device
can be upgraded or applications running on the device can be can be upgraded, or applications running on the device can be
reconfigured. The maintenance tasks can be performed either locally reconfigured. The maintenance tasks can be performed either locally
or from a backend system. Depending on the operational changes to or from a backend system. Depending on the operational changes to
the device, it may be required to re-bootstrap at the end of a the device, it may be required to rebootstrap at the end of a
maintenance cycle. The device continues to loop through the maintenance cycle. The device continues to loop through the
operational phase and the eventual maintenance phases until the operational phase and the eventual maintenance phases until the
device is decommissioned at the end of its lifecycle. However, the device is decommissioned at the end of its lifecycle. However, the
end-of-life of a device does not necessarily mean that it is end-of-life of a device does not necessarily mean that it is
defective and rather denotes a need to replace and upgrade the defective; rather, it denotes a need to replace and upgrade the
network to the next-generation devices for additional functionality. network to next-generation devices for additional functionality.
Therefore, the device can be removed and re-commissioned to be used Therefore, the device can be removed and recommissioned to be used in
in a different system under a different owner thereby starting the a different system under a different owner, thereby starting the
lifecycle all over again. lifecycle all over again.
We note that the presented lifecycle represents to some extent a We note that the presented lifecycle represents to some extent a
simplified model. For instance, it is possible to argue that the simplified model. For instance, it is possible to argue that the
lifecycle does not start when a tangible device is manufactured but lifecycle does not start when a tangible device is manufactured but
rather when the oldest bit of code that ends up in the device - maybe rather when the oldest bit of code that ends up in the device --
from an open source project or from the used operating system - was maybe from an open-source project or the operating system -- was
written. Similarly, the lifecycle could also include an on-the-shelf written. Similarly, the lifecycle could also include an on-the-shelf
phase where the device is in the supply-chain before an owner/user phase where the device is in the supply chain before an owner/user
purchases and installs it. Another phase could involve the device purchases and installs it. Another phase could involve the device
being re-badged by some vendor who is not the original manufacturer. being rebadged by some vendor who is not the original manufacturer.
Such phases can significantly complicate other phases such as Such phases can significantly complicate other phases such as
maintenance and bootstrapping. Finally, other potential end-states maintenance and bootstrapping. Finally, other potential end states
can be, e.g., a vendor that no longer supports a device type because can be, e.g., a vendor that no longer supports a device type because
it is at end-of-life or a situation in which a device is simply it is at the end of its life or a situation in which a device is
forgotten but remains functional. simply forgotten but remains functional.
_Manufactured _SW update _Decommissioned _Manufactured _SW update _Decommissioned
/ / / / / /
| _Installed | _ Application | _Removed & | _Installed | _ Application | _Removed &
| / | / reconfigured | / replaced | / | / reconfigured | / replaced
| | _Commissioned | | | | | | _Commissioned | | | |
| | / | | | | _Reownership & | | / | | | | _Reownership &
| | | _Application | | _Application | | / recommissioned | | | _Application | | _Application | | / recommissioned
| | | / running | | / running | | | | | | / running | | / running | | |
| | | | | | | | | | \\ | | | | | | | | | | \\
+##+##+###+#############+##+##+#############+##+##+##############>>> +##+##+###+#############+##+##+#############+##+##+##############>>>
\/ \______________/ \/ \_____________/ \___/ time // \/ \______________/ \/ \_____________/ \___/ time //
/ / \ \ \ / / \ \ \
Bootstrapping / Maintenance & \ Maintenance & Bootstrapping / Maintenance & \ Maintenance &
/ re-bootstrapping \ re-bootstrapping / rebootstrapping \ rebootstrapping
Operational Operational Operational Operational
Figure 1: The lifecycle of a thing in the Internet of Things Figure 1: The Lifecycle of a Thing in the Internet of Things
Security is a key requirement in any communication system. However, Security is a key requirement in any communication system. However,
security is an even more critical requirement in real-world IoT security is an even more critical requirement in real-world IoT
deployments for several reasons. First, compromised IoT systems can deployments for several reasons. First, compromised IoT systems can
not only endanger the privacy and security of a user, but can also not only endanger the privacy and security of a user but can also
cause physical harm. This is because IoT systems often comprise cause physical harm. This is because IoT systems often comprise
sensors, actuators and other connected devices in the physical sensors, actuators, and other connected devices in the physical
environment of the user which could adversely affect the user if they environment of the user that could adversely affect the user if they
are compromised. Second, a vulnerable IoT system means that an are compromised. Second, a vulnerable IoT system means that an
attacker can alter the functionality of a device from a given attacker can alter the functionality of a device from a given
manufacturer. This not only affects the manufacturer's brand image, manufacturer. This not only affects the manufacturer's brand image
but can also leak information that is very valuable for the but can also leak information that is very valuable for the
manufacturer (such as proprietary algorithms). Third, the impact of manufacturer (such as proprietary algorithms). Third, the impact of
attacking an IoT system goes beyond a specific device or an isolated attacking an IoT system goes beyond a specific device or an isolated
system since compromised IoT systems can be misused at scale. For system, since compromised IoT systems can be misused at scale. For
example, they may be used to perform a Distributed Denial of Service example, they may be used to perform a Distributed Denial of Service
(DDoS) attack that limits the availability of other networks and (DDoS) attack that limits the availability of other networks and
services. The fact that many IoT systems rely on standard IP services. The fact that many IoT systems rely on standard IP
protocols allows for easier system integration, but this also makes protocols allows for easier system integration, but this also makes
attacks on standard IP protocols widely applicable in other attacks on standard IP protocols widely applicable in other
environments. This results in new requirements regarding the environments. This results in new requirements regarding the
implementation of security. implementation of security.
The term security subsumes a wide range of primitives, protocols, and The term "security" subsumes a wide range of primitives, protocols,
procedures. For instance, the term security includes services such and procedures. For instance, it includes services such as
as confidentiality, authentication, integrity, authorization, source confidentiality, authentication, integrity, authorization, source
authentication, and availability. The term security often also authentication, and availability. It often also includes augmented
includes augmented services such as duplicate detection and detection services such as duplicate detection and detection of stale packets
of stale packets (timeliness). These security services can be (timeliness). These security services can be implemented through a
implemented through a combination of cryptographic mechanisms such as combination of cryptographic mechanisms such as block ciphers, hash
block ciphers, hash functions, and signature algorithms; as well as functions, and signature algorithms, as well as noncryptographic
non-cryptographic mechanisms that implement authorization and other mechanisms that implement authorization and other aspects of
security policy enforcement aspects. For ensuring security in IoT security-policy enforcement. For ensuring security in IoT networks,
networks, one should not only focus on the required security one should not only focus on the required security services but also
services, but also pay special attention to how the services are pay special attention to how the services are realized in the overall
realized in the overall system. system.
3. Security Threats and Managing Risk 3. Security Threats and Managing Risk
Security threats in related IP protocols have been analyzed in Security threats in related IP protocols have been analyzed in
multiple documents including Hypertext Transfer Protocol (HTTP) over multiple documents, including Hypertext Transfer Protocol (HTTP) over
Transport Layer Security (TLS) (HTTPS) [RFC2818], Constrained Transport Layer Security (TLS) (HTTPS) [RFC2818], Constrained
Application Protocol (COAP) [RFC7252], IPv6 over Low-Power Wireless Application Protocol (CoAP) [RFC7252], IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPAN) [RFC4919], Access Node Control Personal Area Networks (6LoWPAN) [RFC4919], Access Node Control
Protocol (ANCP) [RFC5713], Domain Name System (DNS) [RFC3833], IPv6 Protocol (ANCP) [RFC5713], Domain Name System (DNS) [RFC3833], IPv6
Neighbor Discovery (ND) [RFC3756], and Protocol for Carrying Neighbor Discovery (ND) [RFC3756], and Protocol for Carrying
Authentication and Network Access (PANA) [RFC4016]. In this section, Authentication and Network Access (PANA) [RFC4016]. In this section,
we specifically discuss the threats that could compromise an we specifically discuss the threats that could compromise an
individual thing or the network as a whole. Some of these threats individual thing or the network as a whole. Some of these threats
might go beyond the scope of Internet protocols but we gather them might go beyond the scope of Internet protocols, but we gather them
here for the sake of completeness. The threats in the following list here for the sake of completeness. The threats in the following list
are not in any particular order and some threats might be more are not in any particular order, and some threats might be more
critical than others depending on the deployment scenario under critical than others, depending on the deployment scenario under
consideration: consideration:
1. Vulnerable Software/Code: Things in the Internet of Things rely 1. Vulnerable software/code: Things in the Internet of Things rely
on software that might contain severe bugs and/or bad design on software that might contain severe bugs and/or bad design
choices. This makes the things vulnerable to many different choices. This makes the things vulnerable to many different
types of attacks, depending on the criticality of the bugs, types of attacks, depending on the criticality of the bugs,
e.g., buffer overflows or lack of authentication. This can be e.g., buffer overflows or lack of authentication. This can be
considered as one of the most important security threat. The considered one of the most important security threats. The
large-scale distributed denial-of-service (DDoS) attack, large-scale Distributed Denial of Service (DDoS) attack,
popularly known as the Mirai botnet [mirai], was caused by popularly known as the Mirai botnet [Mirai], was caused by
things that had well-known or easy-to-guess passwords for things that had well-known or easy-to-guess passwords for
configuration. configuration.
2. Privacy threat: The tracking of a thing's location and usage may 2. Privacy threat: The tracking of a thing's location and usage may
pose a privacy risk to people around it. For instance, an pose a privacy risk to people around it. For instance, an
attacker can infer privacy sensitive information from the data attacker can infer privacy-sensitive information from the data
gathered and communicated by individual things. Such gathered and communicated by individual things. Such
information may subsequently be sold to interested parties for information may subsequently be sold to interested parties for
marketing purposes and targeted advertising. In extreme cases, marketing purposes and targeted advertising. In extreme cases,
such information might be used to track dissidents in oppressive such information might be used to track dissidents in oppressive
regimes. Unlawful surveillance and interception of traffic to/ regimes. Unlawful surveillance and interception of traffic to/
from a thing by intelligence agencies is also a privacy threat. from a thing by intelligence agencies is also a privacy threat.
3. Cloning of things: During the manufacturing process of a thing, 3. Cloning of things: During the manufacturing process of a thing,
an untrusted factory can easily clone the physical an untrusted factory can easily clone the physical
characteristics, firmware/software, or security configuration of characteristics, firmware/software, or security configuration of
the thing. Deployed things might also be compromised and their the thing. Deployed things might also be compromised and their
software reverse engineered allowing for cloning or software software reverse engineered, allowing for cloning or software
modifications. Such a cloned thing may be sold at a cheaper modifications. Such a cloned thing may be sold at a cheaper
price in the market, and yet can function normally as a genuine price in the market and yet can function normally as a genuine
thing. For example, two cloned devices can still be associated thing. For example, two cloned devices can still be associated
and work with each other. In the worst-case scenario, a cloned and work with each other. In the worst-case scenario, a cloned
device can be used to control a genuine device or perform an device can be used to control a genuine device or perform an
attack. One should note here, that an untrusted factory may attack. One should note here that an untrusted factory may also
also change functionality of the cloned thing, resulting in change functionality of the cloned thing, resulting in degraded
degraded functionality with respect to the genuine thing functionality with respect to the genuine thing (thereby
(thereby, inflicting potential damage to the reputation of the inflicting potential damage to the reputation of the original
original thing manufacturer). Moreover, additional thing manufacturer). Moreover, additional functionality can be
functionality can be introduced in the cloned thing. An example introduced in the cloned thing. An example of such
of such functionality is a backdoor. functionality is a backdoor.
4. Malicious substitution of things: During the installation of a 4. Malicious substitution of things: During the installation of a
thing, a genuine thing may be substituted with a similar variant thing, a genuine thing may be replaced by a similar variant (of
(of lower quality) without being detected. The main motivation lower quality) without being detected. The main motivation may
may be cost savings, where the installation of lower-quality be cost savings, where the installation of lower-quality things
things (for example, non-certified products) may significantly (for example, noncertified products) may significantly reduce
reduce the installation and operational costs. The installers the installation and operational costs. The installers can
can subsequently resell the genuine things to gain further subsequently resell the genuine things to gain further financial
financial benefits. Another motivation may be to inflict damage benefits. Another motivation may be to inflict damage to the
to the reputation of a competitor's offerings. reputation of a competitor's offerings.
5. Eavesdropping attack: During the commissioning of a thing into a 5. Eavesdropping attack: During the commissioning of a thing into a
network, it may be susceptible to eavesdropping, especially if network, it may be susceptible to eavesdropping, especially if
operational keying materials, security parameters, or operational keying materials, security parameters, or
configuration settings, are exchanged in clear using a wireless configuration settings are exchanged in the clear using a
medium or if used cryptographic algorithms are not suitable for wireless medium or if used cryptographic algorithms are not
the envisioned lifetime of the device and the system. After suitable for the envisioned lifetime of the device and the
obtaining the keying material, the attacker might be able to system. After obtaining the keying material, the attacker might
recover the secret keys established between the communicating be able to recover the secret keys established between the
entities, thereby compromising the authenticity and communicating entities, thereby compromising the authenticity
confidentiality of the communication channel, as well as the and confidentiality of the communication channel, as well as the
authenticity of commands and other traffic exchanged over this authenticity of commands and other traffic exchanged over this
communication channel. When the network is in operation, T2T communication channel. When the network is in operation, T2T
communication can be eavesdropped if the communication channel communication can be eavesdropped if the communication channel
is not sufficiently protected or if a session key is compromised is not sufficiently protected or if a session key is compromised
due to protocol weaknesses. An adversary may also be able to due to protocol weaknesses. An adversary may also be able to
eavesdrop if keys are not renewed or updated appropriately. eavesdrop if keys are not renewed or updated appropriately.
Lastly, messages can also be recorded and decrypted offline at a Lastly, messages can also be recorded and decrypted offline at a
later point of time. The Venona project [venona-project] is one later point of time. The VENONA project [venona-project] is one
such example where messages were recorded for offline such example where messages were recorded for offline
decryption. decryption.
6. Man-in-the-middle attack: Both the commissioning phase and 6. Man-in-the-middle attack: Both the commissioning and operational
operational phases may also be vulnerable to man-in-the-middle phases may be vulnerable to man-in-the-middle attacks. For
attacks. For example, when keying material between example, when keying material between communicating entities is
communicating entities is exchanged in the clear and the exchanged in the clear, the security of the key establishment
security of the key establishment protocol depends on the tacit protocol depends on the tacit assumption that no third party can
assumption that no third party can eavesdrop during the eavesdrop during the execution of this protocol. Additionally,
execution of this protocol. Additionally, device authentication device authentication or device authorization may be nontrivial
or device authorization may be non-trivial, or may need support or need the support of a human decision process, since things
of a human decision process, since things usually do not have usually do not have a priori knowledge about each other and
a-priori knowledge about each other and cannot always cannot always differentiate friends and foes via completely
differentiate friends and foes via completely automated automated mechanisms.
mechanisms.
7. Firmware attacks: When a thing is in operation or maintenance 7. Firmware attacks: When a thing is in operation or maintenance
phase, its firmware or software may be updated to allow for new phase, its firmware or software may be updated to allow for new
functionality or new features. An attacker may be able to functionality or new features. An attacker may be able to
exploit such a firmware upgrade by maliciously replacing the exploit such a firmware upgrade by maliciously replacing the
thing's firware, thereby influencing its operational behavior. thing's firmware, thereby influencing its operational behavior.
For example, an attacker could add a piece of malicious code to For example, an attacker could add a piece of malicious code to
the firmware that will cause it to periodically report the the firmware that will cause it to periodically report the
energy usage of the thing to a data repository for analysis. energy usage of the thing to a data repository for analysis.
The attacker can then use this information to determine when a The attacker can then use this information to determine when a
home or enterprise (where the thing is installed) is unoccupied home or enterprise (where the thing is installed) is unoccupied
and break in. Similarly, devices whose software has not been and break in. Similarly, devices whose software has not been
properly maintained and updated might contain vulnerabilities properly maintained and updated might contain vulnerabilities
that might be exploited by attackers to replace the firmware on that might be exploited by attackers to replace the firmware on
the device. the device.
8. Extraction of private information: IoT devices (such as sensors, 8. Extraction of private information: IoT devices (such as sensors,
actuators, etc.) are often physically unprotected in their actuators, etc.) are often physically unprotected in their
ambient environment and they could easily be captured by an ambient environment, and they could easily be captured by an
attacker. An attacker with physical access may then attempt to attacker. An attacker with physical access may then attempt to
extract private information such as keys (for example, device's extract private information such as keys (for example, a group
key, private-key, group key), sensed data (for example, key or the device's private key), data from sensors (for
healthcare status of a user), configuration parameters (for example, healthcare status of a user), configuration parameters
example, the Wi-Fi key), or proprietary algorithms (for example, (for example, the Wi-Fi key), or proprietary algorithms (for
algorithm performing some data analytics task). Even when the example, the algorithm performing some data analytics task).
data originating from a thing is encrypted, attackers can Even when the data originating from a thing is encrypted,
perform traffic analysis to deduce meaningful information which attackers can perform traffic analysis to deduce meaningful
might compromise the privacy of the thing's owner and/or user. information, which might compromise the privacy of the thing's
owner and/or user.
9. Routing attack: As highlighted in [ID-Daniel], routing 9. Routing attack: As highlighted in [Daniel], routing information
information in IoT networks can be spoofed, altered, or in IoT networks can be spoofed, altered, or replayed, in order
replayed, in order to create routing loops, attract/repel to create routing loops, attract/repel network traffic, extend/
network traffic, extend/shorten source routes, etc. A non- shorten source routes, etc. A nonexhaustive list of routing
exhaustive list of routing attacks includes 1) Sinkhole attack attacks includes:
(or blackhole attack), where an attacker declares himself to
have a high-quality route/path to the base station, thus a. Sinkhole attack (or blackhole attack), where an attacker
allowing him to do manipulate all packets passing through it. 2) declares himself to have a high-quality route/path to the
Selective forwarding, where an attacker may selectively forward base station, thus allowing him to do manipulate all packets
packets or simply drop a packet. 3) Wormhole attack, where an passing through it.
attacker may record packets at one location in the network and
tunnel them to another location, thereby influencing perceived b. Selective forwarding, where an attacker may selectively
network behavior and potentially distorting statistics, thus forward packets or simply drop a packet.
greatly impacting the functionality of routing. 4) Sybil attack,
whereby an attacker presents multiple identities to other things c. Wormhole attack, where an attacker may record packets at one
in the network. We refer to [ID-Daniel] for further router location in the network and tunnel them to another location,
attacks and a more detailed description. thereby influencing perceived network behavior and
potentially distorting statistics, thus greatly impacting
the functionality of routing.
d. Sybil attack, whereby an attacker presents multiple
identities to other things in the network. We refer to
[Daniel] for further router attacks and a more detailed
description.
10. Elevation of privilege: An attacker with low privileges can 10. Elevation of privilege: An attacker with low privileges can
misuse additional flaws in the implemented authentication and misuse additional flaws in the implemented authentication and
authorization mechanisms of a thing to gain more privileged authorization mechanisms of a thing to gain more privileged
access to the thing and its data. access to the thing and its data.
11. Denial-of-Service (DoS) attack: Often things have very limited 11. Denial of Service (DoS) attack: Often things have very limited
memory and computation capabilities. Therefore, they are memory and computation capabilities. Therefore, they are
vulnerable to resource exhaustion attack. Attackers can vulnerable to resource-exhaustion attack. Attackers can
continuously send requests to specific things so as to deplete continuously send requests to specific things so as to deplete
their resources. This is especially dangerous in the Internet their resources. This is especially dangerous in the Internet
of Things since an attacker might be located in the backend and of Things since an attacker might be located in the backend and
target resource-constrained devices that are part of a target resource-constrained devices that are part of a
constrained node network [RFC7228]. DoS attack can also be constrained-node network [RFC7228]. A DoS attack can also be
launched by physically jamming the communication channel. launched by physically jamming the communication channel.
Network availability can also be disrupted by flooding the Network availability can also be disrupted by flooding the
network with a large number of packets. On the other hand, network with a large number of packets. On the other hand,
things compromised by attackers can be used to disrupt the things compromised by attackers can be used to disrupt the
operation of other networks or systems by means of a Distributed operation of other networks or systems by means of a Distributed
DoS (DDoS) attack. DoS (DDoS) attack.
To deal with above threats it is required to find and apply suitable To deal with the above threats, it is required to find and apply
security mitigations. However, new threats and exploits appear on a suitable security mitigations. However, new threats and exploits
daily basis and products are deployed in different environments prone appear on a daily basis, and products are deployed in different
to different types of threats. Thus, ensuring a proper level of environments prone to different types of threats. Thus, ensuring a
security in an IoT system at any point of time is challenging. To proper level of security in an IoT system at any point of time is
address this challenge, some of the following methodologies can be challenging. To address this challenge, some of the following
used: methodologies can be used:
1. A Business Impact Analysis (BIA) assesses the consequences of the 1. A Business Impact Analysis (BIA) assesses the consequences of the
loss of basic security attributes: confidentiality, integrity and loss of basic security attributes: confidentiality, integrity,
availability in an IoT system. These consequences might include and availability in an IoT system. These consequences might
the impact from lost data, reduced sales, increased expenses, include the impact from lost data, reduced sales, increased
regulatory fines, customer dissatisfaction, etc. Performing a expenses, regulatory fines, customer dissatisfaction, etc.
business impact analysis allows a business to determine the Performing a business impact analysis allows a business to
relevance of having a proper security design. determine the relevance of having a proper security design.
2. A Risk Assessment (RA) analyzes security threats to an IoT system 2. A Risk Assessment (RA) analyzes security threats to an IoT system
while considering their likelihood and impact. It also includes while considering their likelihood and impact. It also includes
categorizing each of them with a risk level. Risks classified as categorizing each of them with a risk level. Risks classified as
moderate or high must be mitigated, i.e., the security moderate or high must be mitigated, i.e., the security
architecture should be able to deal with those threat. architecture should be able to deal with those threats.
3. A privacy impact assessment (PIA) aims at assessing the 3. A Privacy Impact Assessment (PIA) aims at assessing the
Personally Identifiable Information (PII) that is collected, Personally Identifiable Information (PII) that is collected,
processed, or used in an IoT system. By doing so, the goal is to processed, or used in an IoT system. By doing so, the goal is to
fulfill applicable legal requirements, determine risks and fulfill applicable legal requirements and determine the risks and
effects of manipulation and loss of PII. effects of manipulation and loss of PII.
4. Procedures for incident reporting and mitigation refer to the 4. Procedures for incident reporting and mitigation refer to the
methodologies that allow becoming aware of any security issues methodologies that allow becoming aware of any security issues
that affect an IoT system. Furthermore, this includes steps that affect an IoT system. Furthermore, this includes steps
towards the actual deployment of patches that mitigate the towards the actual deployment of patches that mitigate the
identified vulnerabilities. identified vulnerabilities.
BIA, RA, and PIA should generally be realized during the creation of BIA, RA, and PIA should generally be realized during the creation of
a new IoT system or when deploying significant system/feature a new IoT system or when deploying significant system/feature
upgrades. In general, it is recommended to re-assess them on a upgrades. In general, it is recommended to reassess them on a
regular basis taking into account new use cases and/or threats. The regular basis, taking into account new use cases and/or threats. The
way a BIA, RA, PIA are performed depends on the environment and the way a BIA, RA, or PIA is performed depends on the environment and the
industry. More information can be found in NIST documents such as industry. More information can be found in NIST documents such as
[NISTSP800-34r1], [NISTSP800-30r1], and [NISTSP800-122]. [NISTSP800-34r1], [NISTSP800-30r1], and [NISTSP800-122].
4. State-of-the-Art 4. State of the Art
This section is organized as follows. Section 4.1 summarizes state- This section is organized as follows. Section 4.1 summarizes the
of-the-art on IP-based IoT systems, within IETF and in other state of the art on IP-based IoT systems, within both the IETF and
standardization bodies. Section 4.2 summarizes state-of-the-art on other standardization bodies. Section 4.2 summarizes the state of
IP-based security protocols and their usage. Section 4.3 discusses the art on IP-based security protocols and their usage. Section 4.3
guidelines and regulations for securing IoT as proposed by other discusses guidelines and regulations for securing IoT as proposed by
bodies. Note that the references included in this section are a other bodies. Note that the references included in this section are
representative of the state-of-the-art at the point of writing and a representative of the state of the art at the point of writing, and
they are by no means exhaustive. The references are also at varying they are by no means exhaustive. The references are also at varying
levels of maturity, and thus, it is advisable to review their levels of maturity; thus, it is advisable to review their specific
specific status. status.
4.1. IP-based IoT Protocols and Standards 4.1. IP-Based IoT Protocols and Standards
Nowadays, there exists a multitude of control protocols for IoT. For Nowadays, there exists a multitude of control protocols for IoT. For
BAC systems, the ZigBee standard [ZB], BACNet [BACNET], and DALI BAC systems, the ZigBee standard [ZB], BACNet [BACNET], and DALI
[DALI] play key roles. Recent trends, however, focus on an all-IP [DALI] play key roles. Recent trends, however, focus on an all-IP
approach for system control. approach for system control.
In this setting, a number of IETF working groups are designing new In this setting, a number of IETF working groups are designing new
protocols for resource-constrained networks of smart things. The protocols for resource-constrained networks of smart things. The
6LoWPAN working group [WG-6LoWPAN] for example has defined methods 6LoWPAN Working Group [WG-6LoWPAN], for example, has defined methods
and protocols for the efficient transmission and adaptation of IPv6 and protocols for the efficient transmission and adaptation of IPv6
packets over IEEE 802.15.4 networks [RFC4944]. packets over IEEE 802.15.4 networks [RFC4944].
The CoRE working group [WG-CoRE] has specified the Constrained The CoRE Working Group [WG-CoRE] has specified the Constrained
Application Protocol (CoAP) [RFC7252]. CoAP is a RESTful protocol Application Protocol (CoAP) [RFC7252]. CoAP is a RESTful protocol
for constrained devices that is modeled after HTTP and typically runs for constrained devices that is modeled after HTTP and typically runs
over UDP to enable efficient application-level communication for over UDP to enable efficient application-level communication for
things. things. ("RESTful" refers to the Representational State Transfer
(REST) architecture.)
In many smart object networks, the smart objects are dispersed and In many smart-object networks, the smart objects are dispersed and
have intermittent reachability either because of network outages or have intermittent reachability either because of network outages or
because they sleep during their operational phase to save energy. In because they sleep during their operational phase to save energy. In
such scenarios, direct discovery of resources hosted on the such scenarios, direct discovery of resources hosted on the
constrained server might not be possible. To overcome this barrier, constrained server might not be possible. To overcome this barrier,
the CoRE working group is specifying the concept of a Resource the CoRE Working Group is specifying the concept of a Resource
Directory (RD) [ID-rd]. The Resource Directory hosts descriptions of Directory (RD) [RD]. The Resource Directory hosts descriptions of
resources which are located on other nodes. These resource resources that are located on other nodes. These resource
descriptions are specified as CoRE link format [RFC6690]. descriptions are specified as CoRE link format [RFC6690].
While CoAP defines a standard communication protocol, a format for While CoAP defines a standard communication protocol, a format for
representing sensor measurements and parameters over CoAP is representing sensor measurements and parameters over CoAP is
required. The Sensor Measurement Lists (SenML) [RFC8428] is a required. "Sensor Measurement Lists (SenML)" [RFC8428] is a
specification that defines media types for simple sensor measurements specification that defines media types for simple sensor measurements
and parameters. It has a minimalistic design so that constrained and parameters. It has a minimalistic design so that constrained
devices with limited computational capabilities can easily encode devices with limited computational capabilities can easily encode
their measurements and, at the same time, servers can efficiently their measurements and, at the same time, servers can efficiently
collect large number of measurements. collect a large number of measurements.
In many IoT deployments, the resource-constrained smart objects are In many IoT deployments, the resource-constrained smart objects are
connected to the Internet via a gateway that is directly reachable. connected to the Internet via a gateway that is directly reachable.
For example, an IEEE 802.11 Access Point (AP) typically connects the For example, an IEEE 802.11 Access Point (AP) typically connects the
client devices to the Internet over just one wireless hop. However, client devices to the Internet over just one wireless hop. However,
some deployments of smart object networks require routing between the some deployments of smart-object networks require routing between the
smart objects themselves. The IETF has therefore defined the IPv6 smart objects themselves. The IETF has therefore defined the IPv6
Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550]. Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550].
RPL provides support for multipoint-to-point traffic from resource- RPL provides support for multipoint-to-point traffic from resource-
constrained smart objects towards a more resourceful central control constrained smart objects towards a more resourceful central control
point, as well as point-to-multipoint traffic in the reverse point, as well as point-to-multipoint traffic in the reverse
direction. It also supports point-to-point traffic between the direction. It also supports point-to-point traffic between the
resource-constrained devices. A set of routing metrics and resource-constrained devices. A set of routing metrics and
constraints for path calculation in RPL are also specified [RFC6551]. constraints for path calculation in RPL are also specified [RFC6551].
The IPv6 over Networks of Resource-constrained Nodes (6lo) [WG-6lo] The IPv6 over Networks of Resource-constrained Nodes (6lo) Working
working group of the IETF has specified how IPv6 packets can be Group of the IETF [WG-6lo] has specified how IPv6 packets can be
transmitted over various link layer protocols that are commonly transmitted over various link-layer protocols that are commonly
employed for resource-constrained smart object networks. There is employed for resource-constrained smart-object networks. There is
also ongoing work to specify IPv6 connectivity for a Non-Broadcast also ongoing work to specify IPv6 connectivity for a Non-Broadcast
Multi-Access (NBMA) mesh network that is formed by IEEE 802.15.4 Multi-Access (NBMA) mesh network that is formed by IEEE 802.15.4
TimeSlotted Channel Hopping (TSCH} links [ID-6tisch]. Other link Time-Slotted Channel Hopping (TSCH) links [ARCH-6TiSCH]. Other link-
layer protocols for which IETF has specified or is currently layer protocols for which the IETF has specified or is currently
specifying IPv6 support include Bluetooth [RFC7668], Digital Enhanced specifying IPv6 support include Bluetooth [RFC7668], Digital Enhanced
Cordless Telecommunications (DECT) Ultra Low Energy (ULE) air Cordless Telecommunications (DECT) Ultra Low Energy (ULE) air
interface [RFC8105], and Near Field Communication (NFC) [ID-6lonfc]. interface [RFC8105], and Near Field Communication (NFC)
[IPv6-over-NFC].
Baker and Meyer [RFC6272] identify which IP protocols can be used in Baker and Meyer [RFC6272] identify which IP protocols can be used in
smart grid environments. They give advice to smart grid network smart-grid environments. They give advice to smart-grid network
designers on how they can decide on a profile of the Internet designers on how they can decide on a profile of the Internet
protocol suite for smart grid networks. protocol suite for smart-grid networks.
The Low Power Wide-Area Network (LPWAN) working [WG-LPWAN] group is The Low Power Wide-Area Network (LPWAN) Working Group [WG-LPWAN] is
analyzing features, requirements, and solutions to adapt IP-based analyzing features, requirements, and solutions to adapt IP-based
protocols to networks such as LORA [lora], SigFox [sigfox], NB-IoT protocols to networks such as LoRa [LoRa], Sigfox [sigfox], NB-IoT
[nbiot], etc. These networking technologies enable a smart thing to [NB-IoT], etc. These networking technologies enable a smart thing to
run for years on a single coin-cell by relying on a star network run for years on a single coin-cell by relying on a star network
topology and using optimized radio modulation with frame sizes in the topology and using optimized radio modulation with frame sizes in the
order of tens of bytes. Such networks bring new security challenges order of tens of bytes. Such networks bring new security challenges,
since most existing security mechanism do not work well with such since most existing security mechanism do not work well with such
resource constraints. resource constraints.
JavaScript Object Notation (JSON) is a lightweight text JavaScript Object Notation (JSON) is a lightweight text-
representation format for structured data [RFC8259]. It is often representation format for structured data [RFC8259]. It is often
used for transmitting serialized structured data over the network. used for transmitting serialized structured data over the network.
IETF has defined specifications for encoding cryptographic keys, The IETF has defined specifications for encoding cryptographic keys,
encrypted content, signed content, and claims to be transferred encrypted content, signed content, and claims to be transferred
between two parties as JSON objects. They are referred to as JSON between two parties as JSON objects. They are referred to as JSON
Web Keys (JWK) [RFC7517], JSON Web Encryption (JWE) [RFC7516], JSON Web Keys (JWKs) [RFC7517], JSON Web Encryption (JWE) [RFC7516], JSON
Web Signatures (JWS) [RFC7515] and JSON Web Token (JWT) [RFC7519]. Web Signatures (JWSs) [RFC7515], and JSON Web Token (JWT) [RFC7519].
An alternative to JSON, Concise Binary Object Representation (CBOR) An alternative to JSON, Concise Binary Object Representation (CBOR)
[RFC7049] is a concise binary data format that is used for [RFC7049], is a concise binary data format that is used for
serialization of structured data. It is designed for resource- serialization of structured data. It is designed for resource-
constrained nodes and therefore it aims to provide a fairly small constrained nodes, and therefore it aims to provide a fairly small
message size with minimal implementation code, and extensibility message size with minimal implementation code and extensibility
without the need for version negotiation. CBOR Object Signing and without the need for version negotiation. CBOR Object Signing and
Encryption (COSE) [RFC8152] specifies how to encode cryptographic Encryption (COSE) [RFC8152] specifies how to encode cryptographic
keys, message authentication codes, encrypted content, and signatures keys, message authentication codes, encrypted content, and signatures
with CBOR. with CBOR.
The Light-Weight Implementation Guidance (LWIG) working group The Light-Weight Implementation Guidance (LWIG) Working Group
[WG-LWIG] is collecting experiences from implementers of IP stacks in [WG-LWIG] is collecting experiences from implementers of IP stacks in
constrained devices. The working group has already produced constrained devices. The working group has already produced
documents such as RFC7815 [RFC7815] which defines how a minimal documents such as [RFC7815], which defines how a minimal Internet Key
Internet Key Exchange Version 2 (IKEv2) initiator can be implemented. Exchange Version 2 (IKEv2) initiator can be implemented.
The Thing-2-Thing Research Group (T2TRG) [RG-T2TRG] is investigating The Thing-2-Thing Research Group (T2TRG) [RG-T2TRG] is investigating
the remaining research issues that need to be addressed to quickly the remaining research issues that need to be addressed to quickly
turn the vision of IoT into a reality where resource-constrained turn the vision of IoT into a reality where resource-constrained
nodes can communicate with each other and with other more capable nodes can communicate with each other and with other more capable
nodes on the Internet. nodes on the Internet.
Additionally, industry alliances and other standardization bodies are Additionally, industry alliances and other standardization bodies are
creating constrained IP protocol stacks based on the IETF work. Some creating constrained IP protocol stacks based on the IETF work. Some
important examples of this include: important examples of this include:
1. Thread [Thread]: Specifies the Thread protocol that is intended 1. Thread [Thread]: Specifies the Thread protocol that is intended
for a variety of IoT devices. It is an IPv6-based network for a variety of IoT devices. It is an IPv6-based network
protocol that runs over IEEE 802.15.4. protocol that runs over IEEE 802.15.4.
2. Industrial Internet Consortium [IIoT]: The consortium defines 2. Industrial Internet Consortium [IIoT]: The consortium defines
reference architectures and security frameworks for development, reference architectures and security frameworks for development,
adoption and widespread use of Industrial Internet technologies adoption, and widespread use of Industrial Internet technologies
based on existing IETF standards. based on existing IETF standards.
3. Internet Protocol for Smart Objects IPSO [IPSO]: The alliance 3. IPSO Alliance (which subsequently merged with OMA SpecWorks
specifies a common object model that enables application software [OMASpecWorks]): The alliance specifies a common object model
on any device to interoperate with other conforming devices. that enables application software on any device to interoperate
with other conforming devices.
4. OneM2M [OneM2M]: The standards body defines technical and API 4. OneM2M [OneM2M]: The standards body defines technical and API
specifications for IoT devices. It aims to create a service specifications for IoT devices. It aims to create a service
layer that can run on any IoT device hardware and software. layer that can run on any IoT device hardware and software.
5. Open Connectivity Foundation (OCF) [OCF]: The foundation develops 5. Open Connectivity Foundation (OCF) [OCF]: The foundation develops
standards and certifications primarily for IoT devices that use standards and certifications primarily for IoT devices that use
Constrained Application Protocol (CoAP) as the application layer Constrained Application Protocol (CoAP) as the application-layer
protocol. protocol.
6. Fairhair Alliance [Fairhair]: Specifies an IoT middleware to 6. Fairhair Alliance [Fairhair]: Specifies an IoT middleware to
enable a common IP network infrastructure between different enable a common IP network infrastructure between different
application standards used in building automation and lighting application standards used in building automation and lighting
systems such as BACnet, KNX and ZigBee. systems such as BACnet, KNX, and ZigBee.
7. OMA LWM2M [LWM2M]: OMA Lightweight M2M is a standard from the 7. OMA LwM2M [LWM2M]: OMA Lightweight M2M is a standard from the OMA
Open Mobile Alliance for M2M and IoT device management. LWM2M SpecWorks for M2M and IoT device management. LwM2M relies on
relies on CoAP as the application layer protocol and uses a CoAP as the application-layer protocol and uses a RESTful
RESTful architecture for remote management of IoT devices. architecture for remote management of IoT devices.
4.2. Existing IP-based Security Protocols and Solutions 4.2. Existing IP-Based Security Protocols and Solutions
There are three main security objectives for IoT networks: 1. There are three main security objectives for IoT networks:
protecting the IoT network from attackers. 2. protecting IoT
applications and thus, the things and users. 3. protecting the rest 1. protecting the IoT network from attackers
of the Internet and other things from attacks that use compromised
things as an attack platform. 2. protecting IoT applications and thus the things and users
3. protecting the rest of the Internet and other things from attacks
that use compromised things as an attack platform
In the context of the IP-based IoT deployments, consideration of In the context of the IP-based IoT deployments, consideration of
existing Internet security protocols is important. There are a wide existing Internet security protocols is important. There are a wide
range of specialized as well as general-purpose security solutions range of specialized as well as general-purpose security solutions
for the Internet domain such as IKEv2/IPsec [RFC7296], Transport for the Internet domain, such as IKEv2/IPsec [RFC7296], Transport
Layer Security (TLS) [RFC8446], Datagram Transport Layer Security Layer Security (TLS) [RFC8446], Datagram Transport Layer Security
(DTLS) [RFC6347], Host Identity Protocol (HIP) [RFC7401], PANA (DTLS) [RFC6347], Host Identity Protocol (HIP) [RFC7401], PANA
[RFC5191], Kerberos ([RFC4120]), Simple Authentication and Security [RFC5191], Kerberos [RFC4120], Simple Authentication and Security
Layer (SASL) [RFC4422], and Extensible Authentication Protocol (EAP) Layer (SASL) [RFC4422], and Extensible Authentication Protocol (EAP)
[RFC3748]. [RFC3748].
TLS provides security for TCP and requires a reliable transport. TLS provides security for TCP and requires a reliable transport.
DTLS secures and uses datagram-oriented protocols such as UDP. Both DTLS secures and uses datagram-oriented protocols such as UDP. Both
protocols are intentionally kept similar and share the same ideology protocols are intentionally kept similar and share the same ideology
and cipher suites. The CoAP base specification [RFC7252] provides a and cipher suites. The CoAP base specification [RFC7252] provides a
description of how DTLS can be used for securing CoAP. It proposes description of how DTLS can be used for securing CoAP. It proposes
three different modes for using DTLS: the PreSharedKey mode, where three different modes for using DTLS: the PreSharedKey mode, where
nodes have pre-provisioned keys for initiating a DTLS session with nodes have pre-provisioned keys for initiating a DTLS session with
another node, RawPublicKey mode, where nodes have asymmetric-key another node, RawPublicKey mode, where nodes have asymmetric-key
pairs but no certificates to verify the ownership, and Certificate pairs but no certificates to verify the ownership, and Certificate
mode, where public keys are certified by a certification authority. mode, where public keys are certified by a certification authority.
An IoT implementation profile [RFC7925] is defined for TLS version An IoT implementation profile is defined for TLS version 1.2 and DTLS
1.2 and DTLS version 1.2 that offers communication security for version 1.2 that offers communication security for resource-
resource-constrained nodes. constrained nodes [RFC7925].
There is ongoing work to define an authorization and access-control There is ongoing work to define an authorization and access-control
framework for resource-constrained nodes. The Authentication and framework for resource-constrained nodes. The Authentication and
Authorization for Constrained Environments (ACE) [WG-ACE] working Authorization for Constrained Environments (ACE) Working Group
group is defining a solution to allow only authorized access to [WG-ACE] is defining a solution to allow only authorized access to
resources that are hosted on a smart object server and are identified resources that are hosted on a smart-object server and identified by
by a URI. The current proposal [ID-aceoauth] is based on the OAuth a URI. The current proposal [ACE-OAuth] is based on the OAuth 2.0
2.0 framework [RFC6749] and it comes with profiles intended for framework [RFC6749], and it comes with profiles intended for
different communication scenarios, e.g. DTLS Profile for different communication scenarios, e.g., "Datagram Transport Layer
Authentication and Authorization for Constrained Environments Security (DTLS) Profile for Authentication and Authorization for
[ID-acedtls]. Constrained Environments (ACE)" [ACE-DTLS].
OSCORE [ID-OSCORE] is a proposal that protects CoAP messages by Object Security for Constrained RESTful Environments (OSCORE)
wrapping them in the CBOR Object Signing and Encryption (COSE) [OSCORE] is a proposal that protects CoAP messages by wrapping them
[RFC8152] format. Thus, OSCORE falls in the category of object in the COSE format [RFC8152]. Thus, OSCORE falls in the category of
security and it can be applied wherever CoAP can be used. The object security, and it can be applied wherever CoAP can be used.
advantage of OSCORE over DTLS is that it provides some more The advantage of OSCORE over DTLS is that it provides some more
flexibility when dealing with end-to-end security. Section 5.1.3 flexibility when dealing with end-to-end security. Section 5.1.3
discusses this further. discusses this further.
The Automated Certificate Management Environment (ACME) [WG-ACME] The Automated Certificate Management Environment (ACME) Working Group
working group is specifying conventions for automated X.509 [WG-ACME] is specifying conventions for automated X.509 certificate
certificate management. This includes automatic validation of management. This includes automatic validation of certificate
certificate issuance, certificate renewal, and certificate issuance, certificate renewal, and certificate revocation. While the
revocation. While the initial focus of working group is on domain initial focus of the working group is on domain-name certificates (as
name certificates (as used by web servers), other uses in some IoT used by web servers), other uses in some IoT deployments are
deployments is possible. possible.
The Internet Key Exchange (IKEv2)/IPsec - as well as the less used The Internet Key Exchange (IKEv2)/IPsec -- as well as the less used
Host Identity protocol (HIP) - reside at or above the network layer Host Identity protocol (HIP) -- reside at or above the network layer
in the OSI model. Both protocols are able to perform an in the OSI model. Both protocols are able to perform an
authenticated key exchange and set up the IPsec for secure payload authenticated key exchange and set up the IPsec for secure payload
delivery. Currently, there are also ongoing efforts to create a HIP delivery. Currently, there are also ongoing efforts to create a HIP
variant coined Diet HIP [ID-HIP-DEX] that takes constrained networks variant coined Diet HIP [HIP-DEX] that takes constrained networks and
and nodes into account at the authentication and key exchange level. nodes into account at the authentication and key-exchange level.
Migault et al. [ID-dietesp] are working on a compressed version of Migault et al. [Diet-ESP] are working on a compressed version of
IPsec so that it can easily be used by resource-constrained IoT IPsec so that it can easily be used by resource-constrained IoT
devices. They rely on the Internet Key Exchange Protocol version 2 devices. They rely on the Internet Key Exchange Protocol Version 2
(IKEv2) for negotiating the compression format. (IKEv2) for negotiating the compression format.
The Extensible Authentication Protocol (EAP) [RFC3748] is an The Extensible Authentication Protocol (EAP) [RFC3748] is an
authentication framework supporting multiple authentication methods. authentication framework supporting multiple authentication methods.
EAP runs directly over the data link layer and, thus, does not
require the deployment of IP. It supports duplicate detection and EAP runs directly over the data link layer and thus does not require
retransmission, but does not allow for packet fragmentation. The the deployment of IP. It supports duplicate detection and
Protocol for Carrying Authentication for Network Access (PANA) is a retransmission but does not allow for packet fragmentation. PANA is
network-layer transport for EAP that enables network access a network-layer transport for EAP that enables network access
authentication between clients and the network infrastructure. In authentication between clients and the network infrastructure. In
EAP terms, PANA is a UDP-based EAP lower layer that runs between the EAP terms, PANA is a UDP-based EAP lower layer that runs between the
EAP peer and the EAP authenticator. EAP peer and the EAP authenticator.
4.3. IoT Security Guidelines 4.3. IoT Security Guidelines
Attacks on and from IoT devices have become common in the last years, Attacks on and from IoT devices have become common in recent years --
for instance, large scale Denial of Service (DoS) attacks on the for instance, large-scale DoS attacks on the Internet Infrastructure
Internet Infrastructure from compromised IoT devices. This fact has from compromised IoT devices. This fact has prompted many different
prompted many different standards bodies and consortia to provide standards bodies and consortia to provide guidelines for developers
guidelines for developers and the Internet community at large to and the Internet community at large to build secure IoT devices and
build secure IoT devices and services. A subset of the different services. The following is a subset of the different guidelines and
guidelines and ongoing projects are as follows: ongoing projects:
1. Global System for Mobile Communications (GSM) Association (GSMA) 1. Global System for Mobile Communications Association (GSMA) IoT
IoT security guidelines [GSMAsecurity]: GSMA has published a set security guidelines [GSMAsecurity]: GSMA has published a set of
of security guidelines for the benefit of new IoT product and security guidelines for the benefit of new IoT product and
service providers. The guidelines are aimed at device service providers. The guidelines are aimed at device
manufacturers, service providers, developers and network manufacturers, service providers, developers, and network
operators. An enterprise can complete an IoT Security Self- operators. An enterprise can complete an IoT Security Self-
Assessment to demonstrate that its products and services are Assessment to demonstrate that its products and services are
aligned with the security guidelines of the GSMA. aligned with the security guidelines of the GSMA.
2. Broadband Internet Technical Advisory Group (BITAG) IoT Security 2. Broadband Internet Technical Advisory Group (BITAG) IoT Security
and Privacy Recommendations [BITAG]: BITAG has published and Privacy Recommendations [BITAG]: BITAG has published
recommendations for ensuring security and privacy of IoT device recommendations for ensuring the security and privacy of IoT
users. BITAG observes that many IoT devices are shipped from device users. BITAG observes that many IoT devices are shipped
the factory with software that is already outdated and from the factory with software that is already outdated and
vulnerable. The report also states that many devices with vulnerable. The report also states that many devices with
vulnerabilities will not be fixed either because the vulnerabilities will not be fixed, either because the
manufacturer does not provide updates or because the user does manufacturer does not provide updates or because the user does
not apply them. The recommendations include that IoT devices not apply them. The recommendations include that IoT devices
should function without cloud and Internet connectivity, and should function without cloud and Internet connectivity and that
that all IoT devices should have methods for automatic secure all IoT devices should have methods for automatic secure
software updates. software updates.
3. United Kingdom Department for Digital, Culture, Media and Sport 3. United Kingdom Department for Digital, Culture, Media and Sport
(DCMS) [DCMS]: UK DCMS has released a report that includes a (DCMS) [DCMS]: UK DCMS has released a report that includes a
list of 13 steps for improving IoT security. These steps, for list of 13 steps for improving IoT security. These steps, for
example, highlight the need for implementing a vulnerability example, highlight the need for implementing a vulnerability
disclosure policy and keeping software updated. The report is disclosure policy and keeping software updated. The report is
aimed at device manufacturers, IoT service providers, mobile aimed at device manufacturers, IoT service providers, mobile
application developers and retailers. application developers, and retailers.
4. Cloud Security Alliance (CSA) New Security Guidance for Early 4. Cloud Security Alliance (CSA) New Security Guidance for Early
Adopters of the IoT [CSA]: CSA recommendations for early Adopters of the IoT [CSA]: CSA recommendations for early
adopters of IoT encourages enterprises to implement security at adopters of IoT encourage enterprises to implement security at
different layers of the protocol stack. It also recommends different layers of the protocol stack. It also recommends
implementation of an authentication/authorization framework for implementation of an authentication/authorization framework for
IoT deployments. A complete list of recommendations is IoT deployments. A complete list of recommendations is
available in the report [CSA]. available in the report [CSA].
5. United States Department of Homeland Security [DHS]: DHS has put 5. United States Department of Homeland Security (DHS) [DHS]: DHS
forth six strategic principles that would enable IoT developers, has put forth six strategic principles that would enable IoT
manufacturers, service providers and consumers to maintain developers, manufacturers, service providers, and consumers to
security as they develop, manufacture, implement or use network- maintain security as they develop, manufacture, implement, or
connected IoT devices. use network-connected IoT devices.
6. National Institute of Standards and Technology (NIST) 6. National Institute of Standards and Technology (NIST)
[NIST-Guide]: The NIST special publication urges enterprise and [NIST-Guide]: The NIST special publication urges enterprise and
US federal agencies to address security throughout the systems US federal agencies to address security throughout the systems
engineering process. The publication builds upon the engineering process. The publication builds upon the
International Organization for Standardization International Organization for Standardization
(ISO)/International Electrotechnical Commission (IEC) 15288 (ISO)/International Electrotechnical Commission (IEC) 15288
standard and augments each process in the system lifecycle with standard and augments each process in the system lifecycle with
security enhancements. security enhancements.
7. National Institute of Standards and Technology (NIST) 7. National Institute of Standards and Technology (NIST)
[nist-lightweight-project]: NIST is running a project on [NIST-LW-PROJECT] [NIST-LW-2016]: NIST is running a project on
lightweight cryptography with the purpose of: (i) identifying lightweight cryptography with the purpose of: (i) identifying
application areas for which standard cryptographic algorithms application areas for which standard cryptographic algorithms
are too heavy, classifying them according to some application are too heavy, classifying them according to some application
profiles to be determined; (ii) determining limitations in those profiles to be determined; (ii) determining limitations in those
existing cryptographic standards; and (iii) standardizing existing cryptographic standards; and (iii) standardizing
lightweight algorithms that can be used in specific application lightweight algorithms that can be used in specific application
profiles. profiles.
8. Open Web Application Security Project (OWASP) [OWASP]: OWASP 8. Open Web Application Security Project (OWASP) [OWASP]: OWASP
provides security guidance for IoT manufactures, developers and provides security guidance for IoT manufacturers, developers,
consumers. OWASP also includes guidelines for those who intend and consumers. OWASP also includes guidelines for those who
to test and analyze IoT devices and applications. intend to test and analyze IoT devices and applications.
9. IoT Security foundation [IoTSecFoundation]: IoT security 9. IoT Security Foundation [IoTSecFoundation]: The IoT Security
foundation has published a document that enlists various Foundation has published a document that enlists various
considerations that need to be taken into account when considerations that need to be taken into account when
developing IoT applications. For example, the document states developing IoT applications. For example, the document states
that IoT devices could use hardware-root of trust to ensure that that IoT devices could use a hardware root of trust to ensure
only authorized software runs on the devices. that only authorized software runs on the devices.
10. National Highway Traffic Safety Administration (NHTSA) [NHTSA]: 10. National Highway Traffic Safety Administration (NHTSA) [NHTSA]:
The US NHTSA provides guidance to the automotive industry for The US NHTSA provides guidance to the automotive industry for
improving the cyber security of vehicles. While some of the improving the cyber security of vehicles. While some of the
guidelines are general, the document provides specific guidelines are general, the document provides specific
recommendations for the automotive industry such as how various recommendations for the automotive industry, such as how various
automotive manufacturer can share cyber security vulnerabilities automotive manufacturers can share cybersecurity vulnerabilities
discovered. discovered.
11. Best Current Practices (BCP) for IoT devices [ID-Moore]: This 11. "Best Current Practices for Securing Internet of Things (IoT)
document provides a list of minimum requirements that vendors of Devices" [Moore]: This document provides a list of minimum
Internet of Things (IoT) devices should to take into account requirements that vendors of IoT devices should to take into
while developing applications, services and firmware updates in account while developing applications, services, and firmware
order to reduce the frequency and severity of security incidents updates in order to reduce the frequency and severity of
that arise from compromised IoT devices. security incidents that arise from compromised IoT devices.
12. European Union Agency for Network and Information Security 12. European Union Agency for Network and Information Security
(ENISA) [ENISA-ICS]: ENISA published a document on communication (ENISA) [ENISA-ICS]: ENISA published a document on
network dependencies for Industrial Control Systems communication-network dependencies for Industrial Control
(ICS)/Supervisory Control And Data Acquisition (SCADA) systems Systems (ICS)/Supervisory Control And Data Acquisition (SCADA)
in which security vulnerabilities, guidelines and general systems in which security vulnerabilities, guidelines, and
recommendations are summarized. general recommendations are summarized.
13. Internet Society Online Trust Alliance [ISOC-OTA]: The Internet 13. Internet Society Online Trust Alliance [ISOC-OTA]: The Internet
Society's IoT Trust Framework identifies the core requirements Society's IoT Trust Framework identifies the core requirements
manufacturers, service providers, distributors, purchasers and that manufacturers, service providers, distributors, purchasers,
policymakers need to understand, assess and embrace for and policymakers need to understand, assess, and embrace for
effective security and privacy as part of the Internet of effective security and privacy as part of the Internet of
Things. Things.
Other guideline and recommendation documents may exist or may later Other guideline and recommendation documents may exist or may later
be published. This list should be considered non-exhaustive. be published. This list should be considered nonexhaustive. Despite
Despite the acknowledgment that security in the Internet is needed the acknowledgment that security in the Internet is needed and the
and the existence of multiple guidelines, the fact is that many IoT existence of multiple guidelines, the fact is that many IoT devices
devices and systems have very limited security. There are multiple and systems have very limited security. There are multiple reasons
reasons for this. For instance, some manufactures focus on for this. For instance, some manufacturers focus on delivering a
delivering a product without paying enough attention to security. product without paying enough attention to security. This may be
because of lack of expertise or limited budget. However, the
This may be because of lack of expertise or limited budget. However, deployment of such insecure devices poses a severe threat to the
the deployment of such insecure devices poses a severe threat on the privacy and safety of users. The vast number of devices and their
privacy and safety of users. The vast amount of devices and their inherently mobile nature also imply that an initially secure system
inherent mobile nature also implies that an initially secure system
can become insecure if a compromised device gains access to the can become insecure if a compromised device gains access to the
system at some point in time. Even if all other devices in a given system at some point in time. Even if all other devices in a given
environment are secure, this does not prevent external attacks caused environment are secure, this does not prevent external attacks caused
by insecure devices. Recently the Federal Communications Commission by insecure devices. Recently, the US Federal Communications
(FCC) [FCC] has stated the need for additional regulation of IoT Commission (FCC) has stated the need for additional regulation of IoT
systems. It is possible that we may see other such regional systems [FCC]. It is possible that we may see other such regional
regulations in the future. regulations in the future.
5. Challenges for a Secure IoT 5. Challenges for a Secure IoT
In this section, we take a closer look at the various security In this section, we take a closer look at the various security
challenges in the operational and technical features of IoT and then challenges in the operational and technical features of IoT and then
discuss how existing Internet security protocols cope with these discuss how existing Internet security protocols cope with these
technical and conceptual challenges through the lifecycle of a thing. technical and conceptual challenges through the lifecycle of a thing.
This discussion should neither be understood as a comprehensive This discussion should not be understood as a comprehensive
evaluation of all protocols, nor can it cover all possible aspects of evaluation of all protocols, nor can it cover all possible aspects of
IoT security. Yet, it aims at showing concrete limitations and IoT security. Yet, it aims at showing concrete limitations and
challenges in some IoT design areas rather than giving an abstract challenges in some IoT design areas rather than giving an abstract
discussion. In this regard, the discussion handles issues that are discussion. In this regard, the discussion handles issues that are
most important from the authors' perspectives. most important from the authors' perspectives.
5.1. Constraints and Heterogeneous Communication 5.1. Constraints and Heterogeneous Communication
Coupling resource-constrained networks and the powerful Internet is a Coupling resource-constrained networks and the powerful Internet is a
challenge because the resulting heterogeneity of both networks challenge, because the resulting heterogeneity of both networks
complicates protocol design and system operation. In the following complicates protocol design and system operation. In the following
we briefly discuss the resource constraints of IoT devices and the subsections, we briefly discuss the resource constraints of IoT
consequences for the use of Internet Protocols in the IoT domain. devices and the consequences for the use of Internet protocols in the
IoT domain.
5.1.1. Resource Constraints 5.1.1. Resource Constraints
IoT deployments are often characterized by lossy and low-bandwidth IoT deployments are often characterized by lossy and low-bandwidth
communication channels. IoT devices are also often constrained in communication channels. IoT devices are also often constrained in
terms of CPU, memory, and energy budget available [RFC7228]. These terms of the CPU, memory, and energy budget available [RFC7228].
characteristics directly impact the design of protocols for the IoT These characteristics directly impact the design of protocols for the
domain. For instance, small packet size limits at the physical layer IoT domain. For instance, small packet-size limits at the physical
(127 Bytes in IEEE 802.15.4) can lead to (i) hop-by-hop fragmentation layer (127 Bytes in IEEE 802.15.4) can lead to (i) hop-by-hop
and reassembly or (ii) small IP-layer maximum transmission unit fragmentation and reassembly or (ii) small IP-layer maximum
(MTU). In the first case, excessive fragmentation of large packets transmission unit (MTU). In the first case, excessive fragmentation
that are often required by security protocols may open new attack of large packets that are often required by security protocols may
vectors for state exhaustion attacks. The second case might lead to open new attack vectors for state-exhaustion attacks. The second
more fragmentation at the IP layer which commonly downgrades the case might lead to more fragmentation at the IP layer, which commonly
overall system performance due to packet loss and the need for downgrades the overall system performance due to packet loss and the
retransmission. need for retransmission.
The size and number of messages should be minimized to reduce memory The size and number of messages should be minimized to reduce memory
requirements and optimize bandwidth usage. In this context, layered requirements and optimize bandwidth usage. In this context, layered
approaches involving a number of protocols might lead to worse approaches involving a number of protocols might lead to worse
performance in resource-constrained devices since they combine the performance in resource-constrained devices since they combine the
headers of the different protocols. In some settings, protocol headers of the different protocols. In some settings, protocol
negotiation can increase the number of exchanged messages. To negotiation can increase the number of exchanged messages. To
improve performance during basic procedures such as, for example, improve performance during basic procedures such as, for example,
bootstrapping, it might be a good strategy to perform those bootstrapping, it might be a good strategy to perform those
procedures at a lower layer. procedures at a lower layer.
Small CPUs and scarce memory limit the usage of resource-expensive Small CPUs and scarce memory limit the usage of resource-expensive
cryptographic primitives such as public-key cryptography as used in cryptographic primitives such as public key cryptography as used in
most Internet security standards. This is especially true if the most Internet security standards. This is especially true if the
basic cryptographic blocks need to be frequently used or the basic cryptographic blocks need to be frequently used or the
underlying application demands low delay. underlying application demands low delay.
There are ongoing efforts to reduce the resource consumption of There are ongoing efforts to reduce the resource consumption of
security protocols by using more efficient underlying cryptographic security protocols by using more efficient underlying cryptographic
primitives such as Elliptic Curve Cryptography [RFC8446]. The primitives such as Elliptic Curve Cryptography (ECC) [RFC8446]. The
specification of elliptic curve X25519 [ecc25519], stream ciphers specification of elliptic curve X25519 [ecc25519], stream ciphers
such as ChaCha [ChaCha], Diet HIP [ID-HIP-DEX], and ECC goups for such as ChaCha [ChaCha], Diet HIP [HIP-DEX], and ECC groups for IKEv2
IKEv2 [RFC5903] are all examples of efforts to make security [RFC5903] are all examples of efforts to make security protocols more
protocols more resource efficient. Additionally, most modern resource efficient. Additionally, most modern security protocols
security protocols have been revised in the last few years to enable have been revised in the last few years to enable cryptographic
cryptographic agility, making cryptographic primitives agility, making cryptographic primitives interchangeable. However,
interchangeable. However, these improvements are only a first step these improvements are only a first step in reducing the computation
in reducing the computation and communication overhead of Internet and communication overhead of Internet protocols. The question
protocols. The question remains if other approaches can be applied remains if other approaches can be applied to leverage key agreement
to leverage key agreement in these heavily resource-constrained in these heavily resource-constrained environments.
environments.
A further fundamental need refers to the limited energy budget A further fundamental need refers to the limited energy budget
available to IoT nodes. Careful protocol (re)design and usage is available to IoT nodes. Careful protocol (re)design and usage are
required to reduce not only the energy consumption during normal required to reduce not only the energy consumption during normal
operation, but also under DoS attacks. Since the energy consumption operation but also under DoS attacks. Since the energy consumption
of IoT devices differs from other device classes, judgments on the of IoT devices differs from other device classes, judgments on the
energy consumption of a particular protocol cannot be made without energy consumption of a particular protocol cannot be made without
tailor-made IoT implementations. tailor-made IoT implementations.
5.1.2. Denial-of-Service Resistance 5.1.2. Denial-of-Service Resistance
The tight memory and processing constraints of things naturally The tight memory and processing constraints of things naturally
alleviate resource exhaustion attacks. Especially in unattended T2T alleviate resource-exhaustion attacks. Especially in unattended T2T
communication, such attacks are difficult to notice before the communication, such attacks are difficult to notice before the
service becomes unavailable (for example, because of battery or service becomes unavailable (for example, because of battery or
memory exhaustion). As a DoS countermeasure, DTLS, IKEv2, HIP, and memory exhaustion). As a DoS countermeasure, DTLS, IKEv2, HIP, and
Diet HIP implement return routability checks based on a cookie Diet HIP implement return routability checks based on a cookie
mechanism to delay the establishment of state at the responding host mechanism to delay the establishment of state at the responding host
until the address of the initiating host is verified. The until the address of the initiating host is verified. The
effectiveness of these defenses strongly depend on the routing effectiveness of these defenses strongly depends on the routing
topology of the network. Return routability checks are particularly topology of the network. Return routability checks are particularly
effective if hosts cannot receive packets addressed to other hosts effective if hosts cannot receive packets addressed to other hosts
and if IP addresses present meaningful information as is the case in and if IP addresses present meaningful information as is the case in
today's Internet. However, they are less effective in broadcast today's Internet. However, they are less effective in broadcast
media or when attackers can influence the routing and addressing of media or when attackers can influence the routing and addressing of
hosts (for example, if hosts contribute to the routing infrastructure hosts (for example, if hosts contribute to the routing infrastructure
in ad-hoc networks and meshes). in ad hoc networks and meshes).
In addition, HIP implements a puzzle mechanism that can force the In addition, HIP implements a puzzle mechanism that can force the
initiator of a connection (and potential attacker) to solve initiator of a connection (and potential attacker) to solve
cryptographic puzzles with variable difficulties. Puzzle-based cryptographic puzzles with variable difficulties. Puzzle-based
defense mechanisms are less dependent on the network topology but defense mechanisms are less dependent on the network topology but
perform poorly if CPU resources in the network are heterogeneous (for perform poorly if CPU resources in the network are heterogeneous (for
example, if a powerful Internet host attacks a thing). Increasing example, if a powerful Internet host attacks a thing). Increasing
the puzzle difficulty under attack conditions can easily lead to the puzzle difficulty under attack conditions can easily lead to
situations where a powerful attacker can still solve the puzzle while situations where a powerful attacker can still solve the puzzle while
weak IoT clients cannot and are excluded from communicating with the weak IoT clients cannot and are excluded from communicating with the
victim. Still, puzzle-based approaches are a viable option for victim. Still, puzzle-based approaches are a viable option for
sheltering IoT devices against unintended overload caused by sheltering IoT devices against unintended overload caused by
misconfiguration or malfunctioning things. misconfiguration or malfunctioning things.
5.1.3. End-to-end security, protocol translation, and the role of 5.1.3. End-to-End Security, Protocol Translation, and the Role of
middleboxes Middleboxes
The term end-to-end security often has multiple interpretations. The term "end-to-end security" often has multiple interpretations.
Here, we consider end-to-end security in the context end-to-end IP Here, we consider end-to-end security in the context of end-to-end IP
connectivity, from a sender to a receiver. Services such as connectivity from a sender to a receiver. Services such as
confidentiality and integrity protection on packet data, message confidentiality and integrity protection on packet data, message
authentication codes or encryption are typically used to provide end- authentication codes, or encryption are typically used to provide
to-end security. These protection methods render the protected parts end-to-end security. These protection methods render the protected
of the packets immutable as rewriting is either not possible because parts of the packets immutable as rewriting is either not possible
a) the relevant information is encrypted and inaccessible to the because (i) the relevant information is encrypted and inaccessible to
gateway or b) rewriting integrity-protected parts of the packet would the gateway or (ii) rewriting integrity-protected parts of the packet
invalidate the end-to-end integrity protection. would invalidate the end-to-end integrity protection.
Protocols for constrained IoT networks are not exactly identical to Protocols for constrained IoT networks are not exactly identical to
their larger Internet counterparts for efficiency and performance their larger Internet counterparts, for efficiency and performance
reasons. Hence, more or less subtle differences between protocols reasons. Hence, more or less subtle differences between protocols
for constrained IoT networks and Internet protocols will remain. for constrained IoT networks and Internet protocols will remain.
While these differences can be bridged with protocol translators at While these differences can be bridged with protocol translators at
middleboxes, they may become major obstacles if end-to-end security middleboxes, they may become major obstacles if end-to-end security
measures between IoT devices and Internet hosts are needed. measures between IoT devices and Internet hosts are needed.
If access to data or messages by the middleboxes is required or If access to data or messages by the middleboxes is required or
acceptable, then a diverse set of approaches for handling such a acceptable, then a diverse set of approaches for handling such a
scenario are available. Note that some of these approaches affect scenario is available. Note that some of these approaches affect the
the meaning of end-to-end security in terms of integrity and meaning of end-to-end security in terms of integrity and
confidentiality since the middleboxes will be able to either decrypt confidentiality, since the middleboxes will be able to either decrypt
or modify partially the exchanged messages: or partially modify the exchanged messages:
1. Sharing credentials with middleboxes enables them to transform 1. Sharing credentials with middleboxes enables them to transform
(for example, decompress, convert, etc.) packets and re-apply the (for example, decompress, convert, etc.) packets and reapply the
security measures after transformation. This method abandons security measures after transformation. This method abandons
end-to-end security and is only applicable to simple scenarios end-to-end security and is only applicable to simple scenarios
with a rudimentary security model. with a rudimentary security model.
2. Reusing the Internet wire format for IoT makes conversion between 2. Reusing the Internet wire format for IoT makes conversion between
IoT and Internet protocols unnecessary. However, it can lead to IoT and Internet protocols unnecessary. However, it can lead to
poor performance in some use cases because IoT specific poor performance in some use cases because IoT-specific
optimizations (for example, stateful or stateless compression) optimizations (for example, stateful or stateless compression)
are not possible. are not possible.
3. Selectively protecting vital and immutable packet parts with a 3. Selectively protecting vital and immutable packet parts with a
message authentication code or with encryption requires a careful message authentication code or encryption requires a careful
balance between performance and security. Otherwise this balance between performance and security. Otherwise, this
approach might either result in poor performance or poor security approach might either result in poor performance or poor
depending on which parts are selected for protection, where they security, depending on which parts are selected for protection,
are located in the original packet, and how they are processed. where they are located in the original packet, and how they are
[ID-OSCORE] proposes a solution in this direction by encrypting processed. [OSCORE] proposes a solution in this direction by
and integrity protecting most of the message fields except those encrypting and integrity protecting most of the message fields
parts that a middlebox needs to read or change. except those parts that a middlebox needs to read or change.
4. Homomorphic encryption techniques can be used in the middlebox to 4. Homomorphic encryption techniques can be used in the middlebox to
perform certain operations. However, this is limited to data perform certain operations. However, this is limited to data
processing involving arithmetic operations. Furthermore, processing involving arithmetic operations. Furthermore, the
performance of existing libraries, for example, SEAL [SEAL] is performance of existing libraries -- for example, Microsoft SEAL
still too limited and homomorphic encryption techniques are not [SEAL] -- is still too limited, and homomorphic encryption
widely applicable yet. techniques are not widely applicable yet.
5. Message authentication codes that sustain transformation can be 5. Message authentication codes that sustain transformation can be
realized by considering the order of transformation and realized by considering the order of transformation and
protection (for example, by creating a signature before protection (for example, by creating a signature before
compression so that the gateway can decompress the packet without compression so that the gateway can decompress the packet without
recalculating the signature). Such an approach enables IoT recalculating the signature). Such an approach enables IoT-
specific optimizations but is more complex and may require specific optimizations but is more complex and may require
application-specific transformations before security is applied. application-specific transformations before security is applied.
Moreover, the usage of encrypted or integrity-protected data Moreover, the usage of encrypted or integrity-protected data
prevents middleboxes from transforming packets. prevents middleboxes from transforming packets.
6. Mechanisms based on object security can bridge the protocol 6. Mechanisms based on object security can bridge the protocol
worlds, but still require that the two worlds use the same object worlds but still require that the two worlds use the same object-
security formats. Currently the object security format based on security formats. Currently, the object-security format based on
CBOR Object Signing and Encryption (COSE) [RFC8152] is different COSE [RFC8152] is different from JSON Object Signing and
from JSON Object Signing and Encryption (JOSE) [RFC7520] or Encryption (JOSE) [RFC7520] or Cryptographic Message Syntax (CMS)
Cryptographic Message Syntax (CMS) [RFC5652]. Legacy devices [RFC5652]. Legacy devices relying on traditional Internet
relying on traditional Internet protocols will need to update to protocols will need to update to the newer protocols for
the newer protocols for constrained environments to enable real constrained environments to enable real end-to-end security.
end-to-end security. Furthermore, middleboxes do not have any Furthermore, middleboxes do not have any access to the data, and
access to the data and this approach does not prevent an attacker this approach does not prevent an attacker who is capable of
who is capable of modifying relevant message header fields that modifying relevant message header fields that are not protected.
are not protected.
To the best of our knowledge, none of the mentioned security To the best of our knowledge, none of the mentioned security
approaches that focus on the confidentiality and integrity of the approaches that focus on the confidentiality and integrity of the
communication exchange between two IP end-points provide the perfect communication exchange between two IP endpoints provide the perfect
solution in this problem space. solution in this problem space.
5.1.4. New network architectures and paradigm 5.1.4. New Network Architectures and Paradigm
There is a multitude of new link layer protocols that aim to address There is a multitude of new link-layer protocols that aim to address
the resource-constrained nature of IoT devices. For example, the the resource-constrained nature of IoT devices. For example, IEEE
IEEE 802.11 ah [IEEE802ah] has been specified for extended range and 802.11ah [IEEE802ah] has been specified for extended range and lower
lower energy consumption to support Internet of Things (IoT) devices. energy consumption to support IoT devices. Similarly, LPWAN
Similarly, Low-Power Wide-Area Network (LPWAN) protocols such as LoRa protocols such as LoRa [LoRa], Sigfox [sigfox], and NarrowBand IoT
[lora], Sigfox [sigfox], NarrowBand IoT (NB-IoT) [nbiot] are all (NB-IoT) [NB-IoT] are all designed for resource-constrained devices
designed for resource-constrained devices that require long range and that require long range and low bit rates. [RFC8376] provides an
low bit rates. [RFC8376] provides an informational overview of the informational overview of the set of LPWAN technologies being
set of LPWAN technologies being considered by the IETF. It also considered by the IETF. It also identifies the potential gaps that
identifies the potential gaps that exist between the needs of those exist between the needs of those technologies and the goal of running
technologies and the goal of running IP in such networks. While IP in such networks. While these protocols allow IoT devices to
these protocols allow IoT devices to conserve energy and operate conserve energy and operate efficiently, they also add additional
efficiently, they also add additional security challenges. For security challenges. For example, the relatively small MTU can make
example, the relatively small MTU can make security handshakes with security handshakes with large X509 certificates a significant
large X509 certificates a significant overhead. At the same time, overhead. At the same time, new communication paradigms also allow
new communication paradigms also allow IoT devices to communicate IoT devices to communicate directly amongst themselves with or
directly amongst themselves with or without support from the network. without support from the network. This communication paradigm is
This communication paradigm is also referred to as Device-to-Device also referred to as Device-to-Device (D2D), Machine-to-Machine (M2M),
(D2D) or Machine-to-Machine (M2M) or Thing-to-Thing (T2T) or Thing-to-Thing (T2T) communication, and it is motivated by a
communication and it is motivated by a number of features such as number of features such as improved network performance, lower
improved network performance, lower latency and lower energy latency, and lower energy requirements.
requirements.
5.2. Bootstrapping of a Security Domain 5.2. Bootstrapping of a Security Domain
Creating a security domain from a set of previously unassociated IoT Creating a security domain from a set of previously unassociated IoT
devices is a key operation in the lifecycle of a thing in an IoT devices is a key operation in the lifecycle of a thing in an IoT
network. This aspect is further elaborated and discussed in the network. This aspect is further elaborated and discussed in the
T2TRG draft on bootstrapping [ID-bootstrap]. T2TRG draft on bootstrapping [BOOTSTRAP].
5.3. Operational Challenges 5.3. Operational Challenges
After the bootstrapping phase, the system enters the operational After the bootstrapping phase, the system enters the operational
phase. During the operational phase, things can use the state phase. During the operational phase, things can use the state
information created during the bootstrapping phase in order to information created during the bootstrapping phase in order to
exchange information securely. In this section, we discuss the exchange information securely. In this section, we discuss the
security challenges during the operational phase. Note that many of security challenges during the operational phase. Note that many of
the challenges discussed in Section 5.1 apply during the operational the challenges discussed in Section 5.1 apply during the operational
phase. phase.
5.3.1. Group Membership and Security 5.3.1. Group Membership and Security
Group key negotiation is an important security service for IoT Group-key negotiation is an important security service for IoT
communication patterns in which a thing sends some data to multiple communication patterns in which a thing sends some data to multiple
things or data flows from multiple things towards a thing. All things or data flows from multiple things towards a thing. All
discussed protocols only cover unicast communication and therefore, discussed protocols only cover unicast communication and therefore do
do not focus on group-key establishment. This applies in particular not focus on group-key establishment. This applies in particular to
to (D)TLS and IKEv2. Thus, a solution is required in this area. A (D)TLS and IKEv2. Thus, a solution is required in this area. A
potential solution might be to use the Diffie-Hellman keys - that are potential solution might be to use the Diffie-Hellman keys -- which
used in IKEv2 and HIP to setup a secure unicast link - for group are used in IKEv2 and HIP to set up a secure unicast link -- for
Diffie-Hellman key-negotiations. However, Diffie-Hellman is a group Diffie-Hellman key negotiations. However, Diffie-Hellman is a
relatively heavy solution, especially if the group is large. relatively heavy solution, especially if the group is large.
Symmetric and asymmetric keys can be used in group communication. Symmetric and asymmetric keys can be used in group communication.
Asymmetric keys have the advantage that they can provide source Asymmetric keys have the advantage that they can provide source
authentication. However, doing broadcast encryption with a single authentication. However, doing broadcast encryption with a single
public/private key pair is also not feasible. Although a single public/private key pair is also not feasible. Although a single
symmetric key can be used to encrypt the communication or compute a symmetric key can be used to encrypt the communication or compute a
message authentication code, it has inherent risks since the capture message authentication code, it has inherent risks since the capture
of a single node can compromise the key shared throughout the of a single node can compromise the key shared throughout the
network. The usage of symmetric-keys also does not provide source network. The usage of symmetric keys also does not provide source
authentication. Another factor to consider is that asymmetric authentication. Another factor to consider is that asymmetric
cryptography is more resource-intensive than symmetric key solutions. cryptography is more resource-intensive than symmetric key solutions.
Thus, the security risks and performance trade-offs of applying Thus, the security risks and performance trade-offs of applying
either symmetric or asymmetric keys to a given IoT use case need to either symmetric or asymmetric keys to a given IoT use case need to
be well-analyzed according to risk and usability assessments. be well analyzed according to risk and usability assessments
[ID-multicast] is looking at a combination of symmetric (for [RFC8387]. [MULTICAST] is looking at a combination of
encryption) and asymmetric (for authentication) in the same packet. confidentiality using a group key and source authentication using
public keys in the same packet.
Conceptually, solutions that provide secure group communication at Conceptually, solutions that provide secure group communication at
the network layer (IPsec/IKEv2, HIP/Diet HIP) may have an advantage the network layer (IPsec/IKEv2, HIP/Diet HIP) may have an advantage
in terms of the cryptographic overhead when compared to application- in terms of the cryptographic overhead when compared to application-
focused security solutions (TLS/ DTLS). This is due to the fact that focused security solutions (TLS/DTLS). This is due to the fact that
application-focused solutions require cryptographic operations per application-focused solutions require cryptographic operations per
group application, whereas network layer approaches may allow sharing group application, whereas network-layer approaches may allow sharing
secure group associations between multiple applications (for example, secure group associations between multiple applications (for example,
for neighbor discovery and routing or service discovery). Hence, for neighbor discovery and routing or service discovery). Hence,
implementing shared features lower in the communication stack can implementing shared features lower in the communication stack can
avoid redundant security measures. However, it is important to note avoid redundant security measures. However, it is important to note
that sharing security contexts among different applications involves that sharing security contexts among different applications involves
potential security threats, e.g., if one of the applications is potential security threats, e.g., if one of the applications is
malicious and monitors exchanged messages or injects fake messages. malicious and monitors exchanged messages or injects fake messages.
In the case of OSCORE, it provides security for CoAP group In the case of OSCORE, it provides security for CoAP group
communication as defined in RFC7390, i.e., based on multicast IP. If communication as defined in RFC 7390, i.e., based on multicast IP.
the same security association is reused for each application, then If the same security association is reused for each application, then
this solution does not seem to have more cryptographic overhead this solution does not seem to have more cryptographic overhead
compared to IPsec. compared to IPsec.
Several group key solutions have been developed by the MSEC working Several group-key solutions have been developed by the MSEC Working
group [WG-MSEC] of the IETF. The MIKEY architecture [RFC4738] is one Group of the IETF [WG-MSEC]. The MIKEY architecture [RFC4738] is one
example. While these solutions are specifically tailored for example. While these solutions are specifically tailored for
multicast and group broadcast applications in the Internet, they multicast and group-broadcast applications in the Internet, they
should also be considered as candidate solutions for group key should also be considered as candidate solutions for group-key
agreement in IoT. The MIKEY architecture for example describes a agreement in IoT. The MIKEY architecture, for example, describes a
coordinator entity that disseminates symmetric keys over pair-wise coordinator entity that disseminates symmetric keys over pair-wise
end-to-end secured channels. However, such a centralized approach end-to-end secured channels. However, such a centralized approach
may not be applicable in a distributed IoT environment, where the may not be applicable in a distributed IoT environment, where the
choice of one or several coordinators and the management of the group choice of one or several coordinators and the management of the group
key is not trivial. key is not trivial.
5.3.2. Mobility and IP Network Dynamics 5.3.2. Mobility and IP Network Dynamics
It is expected that many things (for example, wearable sensors, and It is expected that many things (for example, user devices and
user devices) will be mobile in the sense that they are attached to wearable sensors) will be mobile in the sense that they are attached
different networks during the lifetime of a security association. to different networks during the lifetime of a security association.
Built-in mobility signaling can greatly reduce the overhead of the Built-in mobility signaling can greatly reduce the overhead of the
cryptographic protocols because unnecessary and costly re- cryptographic protocols because unnecessary and costly re-
establishments of the session (possibly including handshake and key establishments of the session (possibly including handshake and key
agreement) can be avoided. IKEv2 supports host mobility with the agreement) can be avoided. IKEv2 supports host mobility with the
MOBIKE [RFC4555] and [RFC4621] extension. MOBIKE refrains from MOBIKE extension [RFC4555] [RFC4621]. MOBIKE refrains from applying
applying heavyweight cryptographic extensions for mobility. However, heavyweight cryptographic extensions for mobility. However, MOBIKE
MOBIKE mandates the use of IPsec tunnel mode which requires the mandates the use of IPsec tunnel mode, which requires the
transmission of an additional IP header in each packet. transmission of an additional IP header in each packet.
HIP offers a simple yet effective mobility management by allowing HIP offers simple yet effective mobility management by allowing hosts
hosts to signal changes to their associations [RFC8046]. However, to signal changes to their associations [RFC8046]. However, slight
slight adjustments might be necessary to reduce the cryptographic adjustments might be necessary to reduce the cryptographic costs --
costs, for example, by making the public-key signatures in the for example, by making the public key signatures in the mobility
mobility messages optional. Diet HIP does not define mobility yet messages optional. Diet HIP does not define mobility yet, but it is
but it is sufficiently similar to HIP and can use the same sufficiently similar to HIP and can use the same mechanisms. DTLS
mechanisms. DTLS provides some mobility support by relying on a provides some mobility support by relying on a connection ID (CID).
connection ID (CID). The use of connection IDs can provide all the The use of connection IDs can provide all the mobility functionality
mobility functionality described in [ID-Williams], except, sending described in [Williams] except sending the updated location. The
the updated location. The specific need for IP-layer mobility mainly specific need for IP-layer mobility mainly depends on the scenario in
depends on the scenario in which the nodes operate. In many cases, which the nodes operate. In many cases, mobility supported by means
mobility supported by means of a mobile gateway may suffice to enable of a mobile gateway may suffice to enable mobile IoT networks, such
mobile IoT networks, such as body sensor networks. Using message as body-sensor networks. Using message-based application-layer
based application-layer security solutions such as OSCORE [ID-OSCORE] security solutions such as OSCORE [OSCORE] can also alleviate the
can also alleviate the problem of re-establishing lower-layer problem of re-establishing lower-layer sessions for mobile nodes.
sessions for mobile nodes.
5.4. Secure software update and cryptographic agility 5.4. Secure Software Update and Cryptographic Agility
IoT devices are often expected to stay functional for several years IoT devices are often expected to stay functional for several years
and decades even though they might operate unattended with direct or decades, even though they might operate unattended with direct
Internet connectivity. Software updates for IoT devices are Internet connectivity. Software updates for IoT devices are
therefore not only required for new functionality, but also to therefore required not only for new functionality but also to
eliminate security vulnerabilities due to software bugs, design eliminate security vulnerabilities due to software bugs, design
flaws, or deprecated algorithms. Software bugs might remain even flaws, or deprecated algorithms. Software bugs might remain even
after careful code review. Implementations of security protocols after careful code review. Implementations of security protocols
might contain (design) flaws. Cryptographic algorithms can also might contain (design) flaws. Cryptographic algorithms can also
become insecure due to advances in cryptanalysis. Therefore, it is become insecure due to advances in cryptanalysis. Therefore, it is
necessary that devices which are incapable of verifying a necessary that devices that are incapable of verifying a
cryptographic signature are not exposed to the Internet (even cryptographic signature are not exposed to the Internet, even
indirectly). indirectly.
Schneier [SchneierSecurity] in his essay highlights several In his essay, Schneier highlights several challenges that hinder
challenges that hinder mechanisms for secure software update of IoT mechanisms for secure software update of IoT devices
devices. First, there is a lack of incentives for manufactures, [SchneierSecurity]. First, there is a lack of incentives for
vendors and others on the supply chain to issue updates for their manufacturers, vendors, and others on the supply chain to issue
devices. Second, parts of the software running on IoT devices is updates for their devices. Second, parts of the software running on
simply a binary blob without any source code available. Since the IoT devices is simply a binary blob without any source code
complete source code is not available, no patches can be written for available. Since the complete source code is not available, no
that piece of code. Lastly Schneier points out that even when patches can be written for that piece of code. Lastly, Schneier
updates are available, users generally have to manually download and points out that even when updates are available, users generally have
install them. However, users are never alerted about security to manually download and install them. However, users are never
updates and at many times do not have the necessary expertise to alerted about security updates, and many times do not have the
manually administer the required updates. necessary expertise to manually administer the required updates.
The FTC staff report on Internet of Things - Privacy & Security in a The US Federal Trade Commission (FTC) staff report on "Internet of
Connected World [FTCreport] and the Article 29 Working Party Opinion Things - Privacy & Security in a Connected World" [FTCreport] and the
8/2014 on the Recent Developments on the Internet of Things Article 29 Working Party's "Opinion 8/2014 on the Recent Developments
[Article29] also document the challenges for secure remote software on the Internet of Things" [Article29] also document the challenges
update of IoT devices. They note that even providing such a software for secure remote software update of IoT devices. They note that
update capability may add new vulnerabilities for constrained even providing such a software-update capability may add new
devices. For example, a buffer overflow vulnerability in the vulnerabilities for constrained devices. For example, a buffer
implementation of a software update protocol (TR69) [TR69] and an overflow vulnerability in the implementation of a software update
expired certificate in a hub device [wink] demonstrate how the protocol (TR69) [TR69] and an expired certificate in a hub device
software update process itself can introduce vulnerabilities. [wink] demonstrate how the software-update process itself can
introduce vulnerabilities.
Powerful IoT devices that run general purpose operating systems can Powerful IoT devices that run general-purpose operating systems can
make use of sophisticated software update mechanisms known from the make use of sophisticated software-update mechanisms known from the
desktop world. However, resource-constrained devices typically do desktop world. However, resource-constrained devices typically do
not have any operating system and are often not equipped with a not have any operating system and are often not equipped with a
memory management unit or similar tools. Therefore, they might memory management unit or similar tools. Therefore, they might
require more specialized solutions. require more specialized solutions.
An important requirement for secure software and firmware updates is An important requirement for secure software and firmware updates is
source authentication. Source authentication requires the resource- source authentication. Source authentication requires the resource-
constrained things to implement public-key signature verification constrained things to implement public key signature verification
algorithms. As stated in Section 5.1.1, resource-constrained things algorithms. As stated in Section 5.1.1, resource-constrained things
have limited amount of computational capabilities and energy supply have limited computational capabilities and energy supply available,
available which can hinder the amount and frequency of cryptographic which can hinder the amount and frequency of cryptographic processing
processing that they can perform. In addition to source that they can perform. In addition to source authentication,
authentication, software updates might require confidential delivery software updates might require confidential delivery over a secure
over a secure (encrypted) channel. The complexity of broadcast (encrypted) channel. The complexity of broadcast encryption can
encryption can force the usage of point-to-point secure links - force the usage of point-to-point secure links; however, this
however, this increases the duration of a software update in a large increases the duration of a software update in a large system.
system. Alternatively, it may force the usage of solutions in which Alternatively, it may force the usage of solutions in which the
the software update is delivered to a gateway, and then distributed software update is delivered to a gateway and then distributed to the
to the rest of the system with a network key. Sending large amounts rest of the system with a network key. Sending large amounts of data
of data that later needs to be assembled and verified over a secure that later needs to be assembled and verified over a secure channel
channel can consume a lot of energy and computational resources. can consume a lot of energy and computational resources. Correct
Correct scheduling of the software updates is also a crucial design scheduling of the software updates is also a crucial design
challenge. For example, a user of connected light bulbs would not challenge. For example, a user of connected light bulbs would not
want them to update and restart at night. More importantly, the user want them to update and restart at night. More importantly, the user
would not want all the lights to update at the same time. would not want all the lights to update at the same time.
Software updates in IoT systems are also needed to update old and Software updates in IoT systems are also needed to update old and
insecure cryptographic primitives. However, many IoT systems, some insecure cryptographic primitives. However, many IoT systems, some
of which are already deployed, are not designed with provisions for of which are already deployed, are not designed with provisions for
cryptographic agility. For example, many devices come with a cryptographic agility. For example, many devices come with a
wireless radio that has an AES128 hardware co-processor. These wireless radio that has an AES128 hardware coprocessor. These
devices solely rely on the co-processor for encrypting and devices solely rely on the coprocessor for encrypting and
authenticating messages. A software update adding support for new authenticating messages. A software update adding support for new
cryptographic algorithms implemented solely in software might not fit cryptographic algorithms implemented solely in software might not fit
on these devices due to limited memory, or might drastically hinder on these devices due to limited memory, or might drastically hinder
its operational performance. This can lead to the use of old and its operational performance. This can lead to the use of old and
insecure software. Therefore, it is important to account for the insecure software. Therefore, it is important to account for the
fact that cryptographic algorithms would need to be updated and fact that cryptographic algorithms would need to be updated and
consider the following when planning for cryptographic agility: consider the following when planning for cryptographic agility:
1. Would it be secure to use the existing cryptographic algorithms 1. Would it be secure to use the existing cryptographic algorithms
available on the device for updating with new cryptographic available on the device for updating with new cryptographic
skipping to change at page 28, line 13 skipping to change at page 29, line 50
device be severely hindered by the update? device be severely hindered by the update?
Finally, we would like to highlight the previous and ongoing work in Finally, we would like to highlight the previous and ongoing work in
the area of secure software and firmware updates at the IETF. the area of secure software and firmware updates at the IETF.
[RFC4108] describes how Cryptographic Message Syntax (CMS) [RFC5652] [RFC4108] describes how Cryptographic Message Syntax (CMS) [RFC5652]
can be used to protect firmware packages. The IAB has also organized can be used to protect firmware packages. The IAB has also organized
a workshop to understand the challenges for secure software update of a workshop to understand the challenges for secure software update of
IoT devices. A summary of the recommendations to the standards IoT devices. A summary of the recommendations to the standards
community derived from the discussions during that workshop have been community derived from the discussions during that workshop have been
documented [RFC8240]. A working group called Software Updates for documented [RFC8240]. A working group called Software Updates for
Internet of Things (suit) [WG-SUIT] is currently working on a new Internet of Things (SUIT) [WG-SUIT] is currently working on a new
version [RFC4108] to reflect the best current practices for firmware specification to reflect the best current practices for firmware
update based on experience from IoT deployments. It is specifically update based on experience from IoT deployments. It is specifically
working on describing an IoT firmware update architecture and working on describing an IoT firmware update architecture and
specifying a manifest format that contains meta-data about the specifying a manifest format that contains metadata about the
firmware update package. Finally, the Trusted Execution Environment firmware update package. Finally, the Trusted Execution Environment
Provisioning working group [WG-TEEP] aims at developing a protocol Provisioning Working Group [WG-TEEP] aims at developing a protocol
for lifecycle management of trusted applications running on the for lifecycle management of trusted applications running on the
secure area of a processor (Trusted Execution Enviornment (TEE)). secure area of a processor (Trusted Execution Environment (TEE)).
5.5. End-of-Life 5.5. End-of-Life
Like all commercial devices, IoT devices have a given useful Like all commercial devices, IoT devices have a given useful
lifetime. The term end-of-life (EOL) is used by vendors or network lifetime. The term "end-of-life" (EOL) is used by vendors or network
operators to indicate the point of time in which they limit or end operators to indicate the point of time at which they limit or end
support for the IoT device. This may be planned or unplanned (for support for the IoT device. This may be planned or unplanned (for
example when the manufacturer goes bankrupt, when the vendor just example, when the manufacturer goes bankrupt, the vendor just decides
decides to abandon a product, or when a network operator moves to a to abandon a product, or a network operator moves to a different type
different type of networking technology). A user should still be of networking technology). A user should still be able to use and
able to use and perhaps even update the device. This requires for perhaps even update the device. This requires for some form of
some form of authorization handover. authorization handover.
Although this may seem far-fetched given the commercial interests and Although this may seem far-fetched given the commercial interests and
market dynamics, we have examples from the mobile world where the market dynamics, we have examples from the mobile world where the
devices have been functional and up-to-date long after the original devices have been functional and up to date long after the original
vendor stopped supporting the device. CyanogenMod for Android vendor stopped supporting the device. CyanogenMod for Android
devices, and OpenWrt for home routers are two such instances where devices and OpenWrt for home routers are two such instances where
users have been able to use and update their devices even after the users have been able to use and update their devices even after the
official EOL. Admittedly it is not easy for an average user to official EOL. Admittedly, it is not easy for an average user to
install and configure their devices on their own. With the install and configure their devices on their own. With the
deployment of millions of IoT devices, simpler mechanisms are needed deployment of millions of IoT devices, simpler mechanisms are needed
to allow users to add new root-of-trusts and install software and to allow users to add new trust anchors [RFC6024] and install
firmware from other sources once the device is EOL. software and firmware from other sources once the device is EOL.
5.6. Verifying device behavior 5.6. Verifying Device Behavior
Users using new IoT appliances such as Internet-connected smart Users using new IoT appliances such as Internet-connected smart
televisions, speakers and cameras are often unaware that these televisions, speakers, and cameras are often unaware that these
devices can undermine their privacy. Recent revelations have shown devices can undermine their privacy. Recent revelations have shown
that many IoT device vendors have been collecting sensitive private that many IoT device vendors have been collecting sensitive private
data through these connected appliances with or without appropriate data through these connected appliances with or without appropriate
user warnings [cctv]. user warnings [cctv].
An IoT device user/owner would like to monitor and verify its An IoT device's user/owner would like to monitor and verify its
operational behavior. For instance, the user might want to know if operational behavior. For instance, the user might want to know if
the device is connecting to the server of the manufacturer for any the device is connecting to the server of the manufacturer for any
reason. This feature - connecting to the manufacturer's server - may reason. This feature -- connecting to the manufacturer's server --
be necessary in some scenarios, such as during the initial may be necessary in some scenarios, such as during the initial
configuration of the device. However, the user should be kept aware configuration of the device. However, the user should be kept aware
of the data that the device is sending back to the vendor. For of the data that the device is sending back to the vendor. For
example, the user might want to know if his/her TV is sending data example, the user might want to know if his/her TV is sending data
when he/she inserts a new USB stick. when he/she inserts a new USB stick.
Providing such information to the users in an understandable fashion Providing such information to the users in an understandable fashion
is challenging. This is because IoT devices are not only resource- is challenging. This is because IoT devices are not only resource
constrained in terms of their computational capability, but also in constrained in terms of their computational capability but also in
terms of the user interface available. Also, the network terms of the user interface available. Also, the network
infrastructure where these devices are deployed will vary infrastructure where these devices are deployed will vary
significantly from one user environment to another. Therefore, where significantly from one user environment to another. Therefore, where
and how this monitoring feature is implemented still remains an open and how this monitoring feature is implemented still remains an open
question. question.
Manufacturer Usage Description (MUD) files [ID-MUD] are perhaps a Manufacturer Usage Description (MUD) files [RFC8520] are perhaps a
first step towards implementation of such a monitoring service. The first step towards implementation of such a monitoring service. The
idea behind MUD files is relatively simple: IoT devices would idea behind MUD files is relatively simple: IoT devices would
disclose the location of their MUD file to the network during disclose the location of their MUD file to the network during
installation. The network can then retrieve those files, and learn installation. The network can then retrieve those files and learn
about the intended behavior of the devices stated by the device about the intended behavior of the devices stated by the device
manufacturer. A network monitoring service could then warn the user/ manufacturer. A network-monitoring service could then warn the user/
owner of devices if they don't behave as expected. owner of devices if they don't behave as expected.
Many devices and software services that automatically learn and Many devices and software services that automatically learn and
monitor the behavior of different IoT devices in a given network are monitor the behavior of different IoT devices in a given network are
commercially available. Such monitoring devices/services can be commercially available. Such monitoring devices/services can be
configured by the user to limit network traffic and trigger alarms configured by the user to limit network traffic and trigger alarms
when unexpected operation of IoT devices is detected. when unexpected operation of IoT devices is detected.
5.7. Testing: bug hunting and vulnerabilities 5.7. Testing: Bug Hunting and Vulnerabilities
Given that IoT devices often have inadvertent vulnerabilities, both Given that IoT devices often have inadvertent vulnerabilities, both
users and developers would want to perform extensive testing on their users and developers would want to perform extensive testing on their
IoT devices, networks, and systems. Nonetheless, since the devices IoT devices, networks, and systems. Nonetheless, since the devices
are resource-constrained and manufactured by multiple vendors, some are resource constrained and manufactured by multiple vendors, some
of them very small, devices might be shipped with very limited of them very small, devices might be shipped with very limited
testing, so that bugs can remain and can be exploited at a later testing, so that bugs can remain and can be exploited at a later
stage. This leads to two main types of challenges: stage. This leads to two main types of challenges:
1. It remains to be seen how the software testing and quality 1. It remains to be seen how the software-testing and quality-
assurance mechanisms used from the desktop and mobile world will assurance mechanisms used from the desktop and mobile world will
be applied to IoT devices to give end users the confidence that be applied to IoT devices to give end users the confidence that
the purchased devices are robust. Bodies such as the European the purchased devices are robust. Bodies such as the European
Cyber Security Organization (ECSO) [ECSO] are working on Cyber Security Organization (ECSO) [ECSO] are working on
processes for security certification of IoT devices. processes for security certification of IoT devices.
2. It is also an open question how the combination of devices from 2. It is also an open question how the combination of devices from
multiple vendors might actually lead to dangerous network multiple vendors might actually lead to dangerous network
configurations. For example, if combination of specific devices configurations -- for example, if the combination of specific
can trigger unexpected behavior. It is needless to say that the devices can trigger unexpected behavior. It is needless to say
security of the whole system is limited by its weakest point. that the security of the whole system is limited by its weakest
point.
5.8. Quantum-resistance 5.8. Quantum-Resistance
Many IoT systems that are being deployed today will remain Many IoT systems that are being deployed today will remain
operational for many years. With the advancements made in the field operational for many years. With the advancements made in the field
of quantum computers, it is possible that large-scale quantum of quantum computers, it is possible that large-scale quantum
computers are available in the future for performing cryptanalysis on computers will be available in the future for performing
existing cryptographic algorithms and cipher suites. If this cryptanalysis on existing cryptographic algorithms and cipher suites.
happens, it will have two consequences. First, functionalities If this happens, it will have two consequences. First,
enabled by means of primitives such as RSA or ECC - namely key functionalities enabled by means of primitives such as RSA or ECC --
exchange, public-key encryption and signature - would not be secure namely, key exchange, public key encryption, and signature -- would
anymore due to Shor's algorithm. Second, the security level of not be secure anymore due to Shor's algorithm. Second, the security
symmetric algorithms will decrease, for example, the security of a level of symmetric algorithms will decrease, for example, the
block cipher with a key size of b bits will only offer b/2 bits of security of a block cipher with a key size of b bits will only offer
security due to Grover's algorithm. b/2 bits of security due to Grover's algorithm.
The above scenario becomes more urgent when we consider the so called The above scenario becomes more urgent when we consider the so-called
"harvest and decrypt" attack in which an attacker can start to "harvest and decrypt" attack in which an attacker can start to
harvest (store) encrypted data today, before a quantum-computer is harvest (store) encrypted data today, before a quantum computer is
available, and decrypt it years later, once a quantum computer is available, and decrypt it years later, once a quantum computer is
available. Such "harvest and decrypt" attacks are not new and were available. Such "harvest and decrypt" attacks are not new and were
used in the Venona project [venona-project]. Many IoT devices that used in the VENONA project [venona-project]. Many IoT devices that
are being deployed today will remain operational for a decade or even are being deployed today will remain operational for a decade or even
longer. During this time, digital signatures used to sign software longer. During this time, digital signatures used to sign software
updates might become obsolete making the secure update of IoT devices updates might become obsolete, making the secure update of IoT
challenging. devices challenging.
This situation would require us to move to quantum-resistant This situation would require us to move to quantum-resistant
alternatives, in particular, for those functionalities involving key alternatives -- in particular, for those functionalities involving
exchange, public-key encryption and signatures. [ID-c2pq] describes key exchange, public key encryption, and signatures. [C2PQ]
when quantum computers may become widely available and what steps are describes when quantum computers may become widely available and what
necessary for transition to cryptographic algorithms that provide steps are necessary for transitioning to cryptographic algorithms
security even in presence of quantum computers. While future that provide security even in the presence of quantum computers.
planning is hard, it may be a necessity in certain critical IoT While future planning is hard, it may be a necessity in certain
deployments which are expected to last decades or more. Although critical IoT deployments that are expected to last decades or more.
increasing the key-size of the different algorithms is definitely an Although increasing the key size of the different algorithms is
option, it would also incur additional computational overhead and definitely an option, it would also incur additional computational
network traffic. This would be undesirable in most scenarios. There overhead and network traffic. This would be undesirable in most
have been recent advancements in quantum-resistant cryptography. We scenarios. There have been recent advancements in quantum-resistant
refer to [ETSI-GR-QSC-001] for an extensive overview of existing cryptography. We refer to [ETSI-GR-QSC-001] for an extensive
quantum-resistant cryptography and [RFC7696] provides guidelines for overview of existing quantum-resistant cryptography, and [RFC7696]
cryptographic algorithm agility. provides guidelines for cryptographic algorithm agility.
5.9. Privacy protection 5.9. Privacy Protection
People will eventually be surrounded by hundreds of connected IoT People will eventually be surrounded by hundreds of connected IoT
devices. Even if the communication links are encrypted and devices. Even if the communication links are encrypted and
protected, information about people might still be collected or protected, information about people might still be collected or
processed for different purposes. The fact that IoT devices in the processed for different purposes. The fact that IoT devices in the
vicinity of people might enable more pervasive monitoring can vicinity of people might enable more pervasive monitoring can
negatively impact their privacy. For instance, imagine the scenario negatively impact their privacy. For instance, imagine the scenario
where a static presence sensor emits a packet due to the presence or where a static presence sensor emits a packet due to the presence or
absence of people in its vicinity. In such a scenario, anyone who absence of people in its vicinity. In such a scenario, anyone who
can observe the packet, can gather critical privacy-sensitive can observe the packet can gather critical privacy-sensitive
information. information.
Such information about people is referred to as personal data in the Such information about people is referred to as personal data in the
European Union (EU) or Personally identifiable information (PII) in European Union (EU) or Personally identifiable information (PII) in
the United States (US), In particular, the General Data Protection the US. In particular, the General Data Protection Regulation (GDPR)
Regulation (GDPR) [GDPR] defines personal data as: 'any information [GDPR] defines personal data as: "any information relating to an
relating to an identified or identifiable natural person ('data identified or identifiable natural person ('data subject'); an
subject'); an identifiable natural person is one who can be identifiable natural person is one who can be identified, directly or
identified, directly or indirectly, in particular by reference to an indirectly, in particular by reference to an identifier such as a
identifier such as a name, an identification number, location data, name, an identification number, location data, an online identifier
an online identifier or to one or more factors specific to the or to one or more factors specific to the physical, physiological,
physical, physiological, genetic, mental, economic, cultural or genetic, mental, economic, cultural or social identity of that
social identity of that natural person'. natural person".
Ziegeldorf [Ziegeldorf] defines privacy in IoT as a threefold Ziegeldorf [Ziegeldorf] defines privacy in IoT as a threefold
guarantee: guarantee:
1. Awareness of the privacy risks imposed by IoT devices and 1. Awareness of the privacy risks imposed by IoT devices and
services. This awareness is achieved by means of transparent services. This awareness is achieved by means of transparent
practices by the data controller, i.e., the entity that is practices by the data controller, i.e., the entity that is
providing IoT devices and/or services. providing IoT devices and/or services.
2. Individual control over the collection and processing of personal 2. Individual control over the collection and processing of personal
information by IoT devices and services. information by IoT devices and services.
3. Awareness and control of the subsequent use and dissemination of 3. Awareness and control of the subsequent use and dissemination of
personal information by data controllers to any entity outside personal information by data controllers to any entity outside
the subject's personal control sphere. This point implies that the subject's personal control sphere. This point implies that
the data controller must be accountable for its actions on the the data controller must be accountable for its actions on the
personal information. personal information.
Based on this definition, several threats to the privacy of users Based on this definition, several threats to the privacy of users
have been documented [Ziegeldorf] and [RFC6973], in particular have been documented [Ziegeldorf] [RFC6973], in particular
considering the IoT environment and its lifecycle: considering the IoT environment and its lifecycle:
1. Identification - refers to the identification of the users, their 1. Identification - refers to the identification of the users, their
IoT devices, and generated data. IoT devices, and generated data.
2. Localization - relates to the capability of locating a user and 2. Localization - relates to the capability of locating a user and
even tracking them, e.g., by tracking MAC addresses in Wi-Fi or even tracking them, e.g., by tracking MAC addresses in Wi-Fi or
Bluetooth. Bluetooth.
3. Profiling - is about creating a profile of the user and their 3. Profiling - is about creating a profile of the user and their
skipping to change at page 32, line 42 skipping to change at page 34, line 35
When IoT systems are deployed, the above issues should be considered When IoT systems are deployed, the above issues should be considered
to ensure that private data remains private. These issues are to ensure that private data remains private. These issues are
particularly challenging in environments in which multiple users with particularly challenging in environments in which multiple users with
different privacy preferences interact with the same IoT devices. different privacy preferences interact with the same IoT devices.
For example, an IoT device controlled by user A (low privacy For example, an IoT device controlled by user A (low privacy
settings) might leak private information about another user B (high settings) might leak private information about another user B (high
privacy settings). How to deal with these threats in practice is an privacy settings). How to deal with these threats in practice is an
area of ongoing research. area of ongoing research.
5.10. Reverse engineering considerations 5.10. Reverse-Engineering Considerations
Many IoT devices are resource-constrained and often deployed in Many IoT devices are resource constrained and often deployed in
unattended environments. Some of these devices can also be purchased unattended environments. Some of these devices can also be purchased
off-the-shelf or online without any credential-provisioning process. off the shelf or online without any credential-provisioning process.
Therefore, an attacker can have direct access to the device and apply Therefore, an attacker can have direct access to the device and apply
advanced techniques to retrieve information that a traditional black advanced techniques to retrieve information that a traditional black-
box model does not consider. Example of those techniques are side- box model does not consider. Examples of those techniques are side-
channel attacks or code disassembly. By doing this, the attacker can channel attacks or code disassembly. By doing this, the attacker can
try to retrieve data such as: try to retrieve data such as:
1. long term keys. These long term keys can be extracted by means 1. Long-term keys. These long-term keys can be extracted by means
of a side-channel attack or reverse engineering. If these keys of a side-channel attack or reverse engineering. If these keys
are exposed, then they might be used to perform attacks on are exposed, then they might be used to perform attacks on
devices deployed in other locations. devices deployed in other locations.
2. source code. Extraction of source code might allow the attacker 2. Source code. Extraction of source code might allow the attacker
to determine bugs or find exploits to perform other types of to determine bugs or find exploits to perform other types of
attacks. The attacker might also just sell the source code. attacks. The attacker might also just sell the source code.
3. proprietary algorithms. The attacker can analyze these 3. Proprietary algorithms. The attacker can analyze these
algorithms gaining valuable know-how. The attacker can also algorithms gaining valuable know-how. The attacker can also
create copies of the product (based on those proprietary create copies of the product (based on those proprietary
algorithms) or modify the algorithms to perform more advanced algorithms) or modify the algorithms to perform more advanced
attacks. attacks.
4. configuration or personal data. The attacker might be able to 4. Configuration or personal data. The attacker might be able to
read personal data, e.g., healthcare data, that has been stored read personal data, e.g., healthcare data, that has been stored
on a device. on a device.
One existing solution to prevent such data leaks is the use of a One existing solution to prevent such data leaks is the use of a
secure element, a tamper-resistant device that is capable of securely secure element, a tamper-resistant device that is capable of securely
hosting applications and their confidential data. Another potential hosting applications and their confidential data. Another potential
solution is the usage of of Physical Unclonable Function (PUFs) that solution is the usage of a Physical Unclonable Function (PUF) that
serves as unique digital fingerprint of a hardware device. PUFs can serves as unique digital fingerprint of a hardware device. PUFs can
also enable other functionalities such as secure key storage. also enable other functionalities such as secure key storage.
Protection against such data leakage patterns is non-trivial since Protection against such data leakage patterns is not trivial since
devices are inherently resource-constrained. An open question is devices are inherently resource-constrained. An open question is
whether there are any viable techniques to protect IoT devices and whether there are any viable techniques to protect IoT devices and
the data in the devices in such an adversarial model. the data in the devices in such an adversarial model.
5.11. Trustworthy IoT Operation 5.11. Trustworthy IoT Operation
Flaws in the design and implementation of IoT devices and networks Flaws in the design and implementation of IoT devices and networks
can lead to security vulnerabilities. A common flaw is the use of can lead to security vulnerabilities. A common flaw is the use of
well-known or easy-to-guess passwords for configuration of IoT well-known or easy-to-guess passwords for configuration of IoT
devices. Many such compromised IoT devices can be found on the devices. Many such compromised IoT devices can be found on the
Internet by means of tools such as Shodan [shodan]. Once discovered, Internet by means of tools such as Shodan [shodan]. Once discovered,
these compromised devices can be exploited at scale, for example, to these compromised devices can be exploited at scale -- for example,
launch DDoS attacks. Dyn, a major DNS , was attacked by means of a to launch DDoS attacks. Dyn, a major DNS service provider, was
DDoS attack originating from a large IoT botnet composed of thousands attacked by means of a DDoS attack originating from a large IoT
of compromised IP-cameras [dyn-attack]. There are several open botnet composed of thousands of compromised IP cameras [Dyn-Attack].
research questions in this area: There are several open research questions in this area:
1. How to avoid vulnerabilities in IoT devices that can lead to 1. How to avoid vulnerabilities in IoT devices that can lead to
large-scale attacks? large-scale attacks?
2. How to detect sophisticated attacks against IoT devices? 2. How to detect sophisticated attacks against IoT devices?
3. How to prevent attackers from exploiting known vulnerabilities at 3. How to prevent attackers from exploiting known vulnerabilities at
a large scale? a large scale?
Some ideas are being explored to address this issue. One of the Some ideas are being explored to address this issue. One of the
approaches relies on the use of Manufacturer Usage Description (MUD) approaches relies on the use of Manufacturer Usage Description (MUD)
files [ID-MUD]. As explained earlier, this proposal requires IoT files [RFC8520]. As explained earlier, this proposal requires IoT
devices to disclose the location of their MUD file to the network devices to disclose the location of their MUD file to the network
during installation. The network can then (i) retrieve those files, during installation. The network can then (i) retrieve those files,
(ii) learn from the manufacturers the intended usage of the devices, (ii) learn from the manufacturers the intended usage of the devices
for example, which services they need to access, and then (iii) (for example, which services they need to access), and then (iii)
create suitable filters and firewall rules. create suitable filters and firewall rules.
6. Conclusions and Next Steps 6. Conclusions and Next Steps
This Internet Draft provides IoT security researchers, system This document provides IoT security researchers, system designers,
designers and implementers with an overview of security requirements and implementers with an overview of security requirements in the IP-
in the IP-based Internet of Things. We discuss the security threats, based Internet of Things. We discuss the security threats, state of
state-of-the-art, and challenges. the art, and challenges.
Although plenty of steps have been realized during the last few years Although plenty of steps have been realized during the last few years
(summarized in Section 4.1) and many organizations are publishing (summarized in Section 4.1) and many organizations are publishing
general recommendations (Section 4.3) describing how IoT should be general recommendations describing how IoT should be secured
secured, there are many challenges ahead that require further (Section 4.3), there are many challenges ahead that require further
attention. Challenges of particular importance are bootstrapping of attention. Challenges of particular importance are bootstrapping of
security, group security, secure software updates, long-term security security, group security, secure software updates, long-term security
and quantum-resistance, privacy protection, data leakage prevention - and quantum-resistance, privacy protection, data leakage prevention
where data could be cryptographic keys, personal data, or even -- where data could be cryptographic keys, personal data, or even
algorithms - and ensuring trustworthy IoT operation. algorithms -- and ensuring trustworthy IoT operation.
Authors of new IoT specifications and implementors need to consider Authors of new IoT specifications and implementers need to consider
how all the security challenges discussed in this draft (and those how all the security challenges discussed in this document (and those
that emerge later) affect their work. The authors of IoT that emerge later) affect their work. The authors of IoT
specifications not only need to put in a real effort towards specifications need to put in a real effort towards not only
addressing the security challenges, but also clearly documenting how addressing the security challenges but also clearly documenting how
the security challenges are addressed. This would reduce the chances the security challenges are addressed. This would reduce the chances
of security vulnerabilities in the code written by implementors of of security vulnerabilities in the code written by implementers of
those specifications. those specifications.
7. Security Considerations 7. Security Considerations
This entire memo deals with security issues. This entire memo deals with security issues.
8. IANA Considerations 8. IANA Considerations
This document contains no request to IANA. This document has no IANA actions.
9. Acknowledgments 9. Informative References
We gratefully acknowledge feedback and fruitful discussion with [ACE-DTLS] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
Tobias Heer, Robert Moskowitz, Thorsten Dahm, Hannes Tschofenig, L. Seitz, "Datagram Transport Layer Security (DTLS)
Carsten Bormann, Barry Raveendran, Ari Keranen, Goran Selander, Fred Profile for Authentication and Authorization for
Baker, Vicent Roca, Thomas Fossati and Eliot Lear. We acknowledge Constrained Environments (ACE)", Work in Progress,
the additional authors of the previous version of this document Sye draft-ietf-ace-dtls-authorize-08, April 2019.
Loong Keoh, Rene Hummen and Rene Struik.
10. Informative References [ACE-OAuth]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", Work in Progress, draft-ietf-ace-
oauth-authz-24, March 2019.
[ARCH-6TiSCH]
Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", Work in Progress, draft-ietf-6tisch-
architecture-20, March 2019.
[Article29] [Article29]
"Opinion 8/2014 on the on Recent Developments on the Article 29 Data Protection Working Party, "Opinion 8/2014
Internet of Things", Web http://ec.europa.eu/justice/data- on the Recent Developments on the Internet of Things",
protection/article-29/documentation/opinion- WP 223, September 2014, <https://ec.europa.eu/justice/
recommendation/files/2014/wp223_en.pdf, n.d.. article-29/documentation/opinion-
recommendation/files/2014/wp223_en.pdf>.
[AUTO-ID] "AUTO-ID LABS", Web http://www.autoidlabs.org/, September [AUTO-ID] "Auto-ID Labs", September 2010,
2010. <https://www.autoidlabs.org/>.
[BACNET] "BACnet", Web http://www.bacnet.org/, February 2011. [BACNET] American Society of Heating, Refrigerating and Air-
Conditioning Engineers (ASHRAE), "BACnet", February 2011,
<http://www.bacnet.org>.
[BITAG] "Internet of Things (IoT) Security and Privacy [BITAG] Broadband Internet Technical Advisory Group, "Internet of
Recommendations", Web http://www.bitag.org/report- Things (IoT) Security and Privacy Recommendations",
internet-of-things-security-privacy-recommendations.php, November 2016, <https://www.bitag.org/report-internet-of-
n.d.. things-security-privacy-recommendations.php>.
[BOOTSTRAP]
Sarikaya, B., Sethi, M., and D. Garcia-Carillo, "Secure
IoT Bootstrapping: A Survey", Work in Progress,
draft-sarikaya-t2trg-sbootstrapping-06, January 2019.
[C2PQ] Hoffman, P., "The Transition from Classical to Post-
Quantum Cryptography", Work in Progress, draft-hoffman-
c2pq-04, August 2018.
[cctv] "Backdoor In MVPower DVR Firmware Sends CCTV Stills To an [cctv] "Backdoor In MVPower DVR Firmware Sends CCTV Stills To an
Email Address In China", Web Email Address In China", February 2016,
https://hardware.slashdot.org/story/16/02/17/0422259/ <https://hardware.slashdot.org/story/16/02/17/0422259/
backdoor-in-mvpower-dvr-firmware-sends-cctv-stills-to-an- backdoor-in-mvpower-dvr-firmware-sends-cctv-stills-to-an-
email-address-in-china, n.d.. email-address-in-china>.
[ChaCha] Bernstein, D., "ChaCha, a variant of Salsa20", Web [ChaCha] Bernstein, D., "ChaCha, a variant of Salsa20", January
http://cr.yp.to/chacha/chacha-20080128.pdf, n.d.. 2008, <http://cr.yp.to/chacha/chacha-20080128.pdf>.
[CSA] "Security Guidance for Early Adopters of the Internet of [CSA] Cloud Security Alliance Mobile Working Group, "Security
Things (IoT)", Web Guidance for Early Adopters of the Internet of Things
https://downloads.cloudsecurityalliance.org/whitepapers/Se (IoT)", April 2015,
curity_Guidance_for_Early_Adopters_of_the_Internet_of_Thin <https://downloads.cloudsecurityalliance.org/whitepapers/S
gs.pdf, n.d.. ecurity_Guidance_for_Early_Adopters_of_the_Internet_of_Thi
ngs.pdf>.
[DALI] "DALI", Web http://www.dalibydesign.us/dali.html, February [DALI] DALIbyDesign, "DALI Explained", February 2011,
2011. <http://www.dalibydesign.us/dali.html>.
[DCMS] "Secure by Design: Improving the cyber security of [Daniel] Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J.
consumer Internet of Things Report", Web Laganier, "IPv6 over Low Power WPAN Security Analysis",
https://www.gov.uk/government/publications/secure-by- Work in Progress, draft-daniel-6lowpan-security-analysis-
design, n.d.. 05, March 2011.
[DHS] "Strategic Principles For Securing the Internet of Things [DCMS] UK Department for Digital Culture, Media & Sport, "Secure
(IoT)", Web by Design: Improving the cyber security of consumer
https://www.dhs.gov/sites/default/files/publications/ Internet of Things Report", March 2018,
<https://www.gov.uk/government/publications/
secure-by-design-report>.
[DHS] U.S. Department of Homeland Security, "Strategic
Principles For Securing the Internet of Things (IoT)",
November 2016,
<https://www.dhs.gov/sites/default/files/publications/
Strategic_Principles_for_Securing_the_Internet_of_Things- Strategic_Principles_for_Securing_the_Internet_of_Things-
2016-1115-FINAL....pdf, n.d.. 2016-1115-FINAL....pdf>.
[dyn-attack] [Diet-ESP] Migault, D., Guggemos, T., Bormann, C., and D. Schinazi,
"Dyn Analysis Summary Of Friday October 21 Attack", Web "ESP Header Compression and Diet-ESP", Work in Progress,
https://dyn.com/blog/dyn-analysis-summary-of-friday- draft-mglt-ipsecme-diet-esp-07, March 2019.
october-21-attack/, n.d..
[ecc25519] [Dyn-Attack]
Bernstein, D., "Curve25519: new Diffie-Hellman speed Oracle Dyn, "Dyn Analysis Summary Of Friday October 21
records", Attack", October 2016, <https://dyn.com/blog/
Web https://cr.yp.to/ecdh/curve25519-20060209.pdf, n.d.. dyn-analysis-summary-of-friday-october-21-attack/>.
[ECSO] "European Cyber Security Organization", Web [ecc25519] Bernstein, D., "Curve25519: new Diffie-Hellman speed
https://www.ecs-org.eu/, n.d.. records", February 2006,
<https://cr.yp.to/ecdh/curve25519-20060209.pdf>.
[ECSO] "European Cyber Security Organisation",
<https://www.ecs-org.eu/>.
[ENISA-ICS] [ENISA-ICS]
"Communication network dependencies for ICS/SCADA European Union Agency for Network and Information
Systems", European Union Agency For Network And Security, "Communication network dependencies for ICS/
Information Security , February 2017. SCADA Systems", February 2017,
<https://www.enisa.europa.eu/publications/
ics-scada-dependencies>.
[ETSI-GR-QSC-001] [ETSI-GR-QSC-001]
"Quantum-Safe Cryptography (QSC);Quantum-safe algorithmic European Telecommunications Standards Institute (ETSI),
framework", European Telecommunications Standards "Quantum-Safe Cryptography (QSC); Quantum-safe algorithmic
Institute (ETSI) , June 2016. framework", ETSI GR QSC 001, July 2016,
<https://www.etsi.org/deliver/etsi_gr/
QSC/001_099/001/01.01.01_60/gr_qsc001v010101p.pdf>.
[Fairhair] [Fairhair] "The Fairhair Alliance",
"Fairhair Alliance", Web https://www.fairhair- <https://www.fairhair-alliance.org/>.
alliance.org/, n.d..
[FCC] "Federal Communications Comssion Response 12-05-2016", [FCC] US Federal Communications Commission, Chairman Tom Wheeler
FCC , February 2016. to Senator Mark Warner, December 2016,
<https://docs.fcc.gov/public/attachments/
DOC-342761A1.pdf>.
[FTCreport] [FTCreport]
"FTC Report on Internet of Things Urges Companies to Adopt US Federal Trade Commission, "FTC Report on Internet of
Best Practices to Address Consumer Privacy and Security Things Urges Companies to Adopt Best Practices to Address
Risks", Web https://www.ftc.gov/news-events/press- Consumer Privacy and Security Risks", January 2015,
releases/2015/01/ftc-report-internet-things-urges- <https://www.ftc.gov/news-events/press-releases/2015/01/
companies-adopt-best-practices, n.d.. ftc-report-internet-things-urges-companies-adopt-best-
practices>.
[GDPR] "The EU General Data Protection Regulation", [GDPR] "The EU General Data Protection Regulation",
Web https://www.eugdpr.org/, n.d.. <https://www.eugdpr.org>.
[GSMAsecurity] [GSMAsecurity]
"GSMA IoT Security Guidelines", Web "GSMA IoT Security Guidelines and Assessment",
http://www.gsma.com/connectedliving/future-iot- <http://www.gsma.com/connectedliving/future-iot-networks/
networks/iot-security-guidelines/, n.d.. iot-security-guidelines>.
[ID-6lonfc] [HIP-DEX] Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)",
Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, Work in Progress, draft-ietf-hip-dex-06, December 2017.
"Transmission of IPv6 Packets over Near Field
Communication", draft-ietf-6lo-nfc-12 (work in progress),
November 2018.
[ID-6tisch] [IEEE802ah]
Thubert, P., "An Architecture for IPv6 over the TSCH mode IEEE, "Status of Project IEEE 802.11ah", IEEE P802.11 -
of IEEE 802.15.4", draft-ietf-6tisch-architecture-18 (work Task Group AH - Meeting Update,
in progress), December 2018. <http://www.ieee802.org/11/Reports/tgah_update.htm>.
[ID-acedtls] [IIoT] "Industrial Internet Consortium",
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and <http://www.iiconsortium.org>.
L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-05 (work in progress), October 2018.
[ID-aceoauth] [IoTSecFoundation]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Internet of Things Security Foundation, "Establishing
H. Tschofenig, "Authentication and Authorization for Principles for Internet of Things Security",
Constrained Environments (ACE) using the OAuth 2.0 <https://iotsecurityfoundation.org/establishing-
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-17 principles-for-internet-of-things-security>.
(work in progress), November 2018.
[ID-bootstrap] [IPv6-over-NFC]
Sarikaya, B., Sethi, M., and D. Garcia-Carillo, "Secure Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi,
IoT Bootstrapping: A Survey", draft-sarikaya-t2trg- "Transmission of IPv6 Packets over Near Field
sbootstrapping-05 (work in progress), September 2018. Communication", Work in Progress, draft-ietf-6lo-nfc-13,
February 2019.
[ID-c2pq] Hoffman, P., "The Transition from Classical to Post- [ISOC-OTA] Internet Society, "Online Trust Alliance (OTA)",
Quantum Cryptography", draft-hoffman-c2pq-04 (work in <https://www.internetsociety.org/ota/>.
progress), August 2018.
[ID-Daniel] [LoRa] "LoRa Alliance", <https://www.lora-alliance.org/>.
Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J.
Laganier, "IPv6 over Low Power WPAN Security Analysis",
draft-daniel-6lowpan-security-analysis-05 (work in
progress), March 2011.
[ID-dietesp] [LWM2M] OMA SpecWorks, "Lightweight M2M (LWM2M)",
Migault, D., Guggemos, T., and C. Bormann, "Diet-ESP: a <http://openmobilealliance.org/iot/lightweight-m2m-lwm2m>.
flexible and compressed format for IPsec/ESP", draft-mglt-
6lo-diet-esp-02 (work in progress), July 2016.
[ID-HIP-DEX] [Mirai] Kolias, C., Kambourakis, G., Stavrou, A., and J. Voas,,
Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz- "DDoS in the IoT: Mirai and Other Botnets", Computer,
hip-rg-dex-06 (work in progress), May 2012. Vol. 50, Issue 7, DOI 10.1109/MC.2017.201, July 2017,
<https://ieeexplore.ieee.org/document/7971869>.
[ID-Moore] [Moore] Moore, K., Barnes, R., and H. Tschofenig, "Best Current
Moore, K., Barnes, R., and H. Tschofenig, "Best Current
Practices for Securing Internet of Things (IoT) Devices", Practices for Securing Internet of Things (IoT) Devices",
draft-moore-iot-security-bcp-01 (work in progress), July Work in Progress, draft-moore-iot-security-bcp-01, July
2017. 2017.
[ID-MUD] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage [MULTICAST]
Description Specification", draft-ietf-opsawg-mud-25 (work
in progress), June 2018.
[ID-multicast]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP", "Group OSCORE - Secure Group Communication for CoAP", Work
draft-ietf-core-oscore-groupcomm-03 (work in progress), in Progress, draft-ietf-core-oscore-groupcomm-04, March
October 2018. 2019.
[ID-OSCORE]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-15 (work in
progress), August 2018.
[ID-rd] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-17 (work in progress), October 2018.
[ID-Williams]
Williams, M. and J. Barrett, "Mobile DTLS", draft-barrett-
mobile-dtls-00 (work in progress), March 2009.
[IEEE802ah]
"Status of Project IEEE 802.11ah, IEEE P802.11- Task Group
AH-Meeting Update.",
Web http://www.ieee802.org/11/Reports/tgah_update.htm,
n.d..
[IIoT] "Industrial Internet Consortium",
Web http://www.iiconsortium.org/, n.d..
[IoTSecFoundation]
"Establishing Principles for Internet of Things Security",
Web https://iotsecurityfoundation.org/establishing-
principles-for-internet-of-things-security/, n.d..
[IPSO] "IPSO Alliance", Web http://www.ipso-alliance.org, n.d..
[ISOC-OTA]
"Internet Society's Online Trust Alliance (OTA)",
Web https://www.internetsociety.org/ota/, n.d..
[lora] "LoRa - Wide Area Networks for IoT", Web https://www.lora-
alliance.org/, n.d..
[LWM2M] "OMA LWM2M", Web
http://openmobilealliance.org/iot/lightweight-m2m-lwm2m,
n.d..
[mirai] Kolias, C., Kambourakis, G., Stavrou, A., and J. Voas,,
"DDoS in the IoT: Mirai and Other Botnets", IEEE
Computer , 2017.
[nbiot] "NarrowBand IoT", Web [NB-IoT] Qualcomm Incorporated, "New Work Item: NarrowBand IOT (NB-
http://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_69/Docs/RP- IOT)", September 2015,
151621.zip, n.d.. <http://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_69/Docs/
RP-151621.zip>.
[NHTSA] "Cybersecurity Best Practices for Modern Vehicles", Web [NHTSA] National Highway Traffic Safety Administration,
https://www.nhtsa.gov/staticfiles/nvs/ "Cybersecurity Best Practices for Modern Vehicles", Report
pdf/812333_CybersecurityForModernVehicles.pdf, n.d.. No. DOT HS 812 333, October 2016,
<https://www.nhtsa.gov/staticfiles/nvs/
pdf/812333_CybersecurityForModernVehicles.pdf>.
[NIST-Guide] [NIST-Guide]
Ross, R., McEvilley, M., and J. Oren, "Systems Security Ross, R., McEvilley, M., and J. Oren, "Systems Security
Engineering", Web Engineering: Considerations for a Multidisciplinary
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ Approach in the Engineering of Trustworthy Secure
NIST.SP.800-160.pdf, n.d.. Systems", NIST Special Publication 800-160,
DOI 10.6028/NIST.SP.800-160, November 2016,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800\ -160.pdf>.
[nist-lightweight-project] [NIST-LW-2016]
"NIST lightweight Project", Web www.nist.gov/programs- Sonmez Turan, M., "NIST's Lightweight Crypto Project",
projects/lightweight-cryptography, October 2016, <https://www.nist.gov/sites/default/files/
www.nist.gov/sites/default/files/documents/2016/10/17/ documents/2016/10/17/
sonmez-turan-presentation-lwc2016.pdf, n.d.. sonmez-turan-presentation-lwc2016.pdf>.
[NIST-LW-PROJECT]
NIST, "Lightweight Cryptography", <https://www.nist.gov/
programs-projects/lightweight-cryptography>.
[NISTSP800-122] [NISTSP800-122]
Erika McCallister, ., Tim Grance, ., and . Karen Scarfone, McCallister, E., Grance, T., and K. Scarfone, "Guide to
"NIST SP800-122 - Guide to Protecting the Confidentiality Protecting the Confidentiality of Personally Identifiable
of Personally Identifiable Information", Web Information (PII)", NIST Special Publication 800-122,
https://nvlpubs.nist.gov/nistpubs/legacy/sp/ April 2010, <https://nvlpubs.nist.gov/nistpubs/legacy/sp/
nistspecialpublication800-122.pdf, n.d.. nistspecialpublication800-122.pdf>.
[NISTSP800-30r1] [NISTSP800-30r1]
"NIST SP 800-30r1 - Guide for Conducting Risk National Institute of Standards and Technology, "Guide for
Assessments", Web Conducting Risk Assessments", NIST Special
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ Publication 800-30 Revision 1, September 2012,
nistspecialpublication800-30r1.pdf, n.d.. <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-30r1.pdf>.
[NISTSP800-34r1] [NISTSP800-34r1]
Marianne Swanson, ., Pauline Bowen, ., Amy Wohl Phillips, Swanson, M., Bowen, P., Phillips, A., Gallup, D., and D.
., Dean Gallup, ., and . David Lynes, "NIST SP800-34r1 - Lynes, "Contingency Planning Guide for Federal Information
Contingency Planning Guide for Federal Information Systems", NIST Special Publication 800-34 Revision 1, May
Systems", Web https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ 2010, <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-34r1.pdf, n.d.. nistspecialpublication800-34r1.pdf>.
[OCF] "Open Connectivity Foundation", [OCF] "Open Connectivity Foundation",
Web https://openconnectivity.org/, n.d.. <https://openconnectivity.org/>.
[OneM2M] "OneM2M", Web http://www.onem2m.org/, n.d.. [OMASpecWorks]
"OMA SpecWorks",
<https://www.omaspecworks.org/ipso-alliance>.
[OWASP] "IoT Security Guidance", [OneM2M] "OneM2M", <http://www.onem2m.org>.
Web https://www.owasp.org/index.php/IoT_Security_Guidance,
n.d.. [OSCORE] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", Work in Progress, draft-ietf-core-object-
security-16, March 2019.
[OWASP] The OWASP Foundation, "IoT Security Guidance", February
2017,
<https://www.owasp.org/index.php/IoT_Security_Guidance>.
[RD] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, Ed., "CoRE Resource Directory", Work in
Progress, draft-ietf-core-resource-directory-20, March
2019.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
skipping to change at page 42, line 19 skipping to change at page 44, line 15
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security
Threats and Security Requirements for the Access Node Threats and Security Requirements for the Access Node
Control Protocol (ANCP)", RFC 5713, DOI 10.17487/RFC5713, Control Protocol (ANCP)", RFC 5713, DOI 10.17487/RFC5713,
January 2010, <https://www.rfc-editor.org/info/rfc5713>. January 2010, <https://www.rfc-editor.org/info/rfc5713>.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Prime (ECP Groups) for IKE and IKEv2", RFC 5903, Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
DOI 10.17487/RFC5903, June 2010, DOI 10.17487/RFC5903, June 2010,
<https://www.rfc-editor.org/info/rfc5903>. <https://www.rfc-editor.org/info/rfc5903>.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", RFC 6024, DOI 10.17487/RFC6024, October
2010, <https://www.rfc-editor.org/info/rfc6024>.
[RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart
Grid", RFC 6272, DOI 10.17487/RFC6272, June 2011, Grid", RFC 6272, DOI 10.17487/RFC6272, June 2011,
<https://www.rfc-editor.org/info/rfc6272>. <https://www.rfc-editor.org/info/rfc6272>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
skipping to change at page 45, line 19 skipping to change at page 47, line 19
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>. <https://www.rfc-editor.org/info/rfc8376>.
[RFC8387] Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical
Considerations and Implementation Experiences in Securing
Smart Object Networks", RFC 8387, DOI 10.17487/RFC8387,
May 2018, <https://www.rfc-editor.org/info/rfc8387>.
[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
DOI 10.17487/RFC8428, August 2018, DOI 10.17487/RFC8428, August 2018,
<https://www.rfc-editor.org/info/rfc8428>. <https://www.rfc-editor.org/info/rfc8428>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RG-T2TRG] [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
"IRTF Thing-to-Thing (T2TRG) Research Group", Description Specification", RFC 8520,
Web https://datatracker.ietf.org/rg/t2trg/charter/, n.d.. DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/info/rfc8520>.
[RG-T2TRG] IRTF, "Thing-to-Thing Research Group (T2TRG)",
<https://datatracker.ietf.org/rg/t2trg/charter/>.
[SchneierSecurity] [SchneierSecurity]
"The Internet of Things Is Wildly Insecure--And Often Schneier, B., "The Internet of Things Is Wildly Insecure
Unpatchable", Web -- And Often Unpatchable", January 2014,
https://www.schneier.com/essays/archives/2014/01/ <https://www.schneier.com/essays/archives/2014/01/
the_internet_of_thin.html, n.d.. the_internet_of_thin.html>.
[SEAL] "Simple Encrypted Arithmetic Library - SEAL", Web [SEAL] Microsoft, "Microsoft SEAL: Fast and Easy-to-Use
https://www.microsoft.com/en- Homomorphic Encryption Library",
us/research/publication/simple-encrypted-arithmetic- <https://www.microsoft.com/en-us/research/project/
library-seal-v2-0/, n.d.. microsoft-seal/>.
[shodan] "Shodan", Web https://www.shodan.io/, n.d.. [shodan] "Shodan", <https://www.shodan.io>.
[sigfox] "Sigfox - The Global Communications Service Provider for [sigfox] "Sigfox - The Global Communications Service Provider for
the Internet of Things (IoT)", the Internet of Things (IoT)", <https://www.sigfox.com>.
Web https://www.sigfox.com/, n.d..
[Thread] "Thread Group", Web http://threadgroup.org/, n.d.. [Thread] "Thread", <http://threadgroup.org>.
[TR69] "Too Many Cooks - Exploiting the Internet-of-TR- [TR69] Oppenheim, L. and S. Tal, "Too Many Cooks - Exploiting the
069-Things", Web https://media.ccc.de/v/31c3_-_6166_-_en_- Internet-of-TR-069-Things", December 2014,
_saal_6_-_201412282145_-_too_many_cooks_- <https://media.ccc.de/v/31c3_-_6166_-_en_-_saal_6_-
_exploiting_the_internet-of-tr-069-things_- _201412282145_-_too_many_cooks_-_exploiting_the_internet-
_lior_oppenheim_-_shahar_tal, n.d.. of-tr-069-things_-_lior_oppenheim_-_shahar_tal>.
[venona-project] [venona-project]
"Venona Project", Web https://www.nsa.gov/news- National Security Agency | Central Security Service,
features/declassified-documents/venona/index.shtml, n.d.. "VENONA", <https://www.nsa.gov/news-features/declassified-
documents/venona/index.shtml>.
[WG-6lo] "IETF IPv6 over Networks of Resource-constrained Nodes [WG-6lo] IETF, "IPv6 over Networks of Resource-constrained Nodes
(6lo) Working Group", (6lo)", <https://datatracker.ietf.org/wg/6lo/charter/>.
Web https://datatracker.ietf.org/wg/6lo/charter/, n.d..
[WG-6LoWPAN] [WG-6LoWPAN]
"IETF IPv6 over Low power WPAN (6lowpan) Working Group", IETF, "IPv6 over Low power WPAN (6lowpan)",
Web http://tools.ietf.org/wg/6lowpan/, n.d.. <http://datatracker.ietf.org/wg/6lowpan/charter/>.
[WG-ACE] "IETF Authentication and Authorization for Constrained [WG-ACE] IETF, "Authentication and Authorization for Constrained
Environments (ACE) Working Group", Environments (ace)",
Web https://datatracker.ietf.org/wg/ace/charter/, n.d.. <https://datatracker.ietf.org/wg/ace/charter/>.
[WG-ACME] "Automated Certificate Management Environment Working [WG-ACME] IETF, "Automated Certificate Management Environment
Group", Web https://datatracker.ietf.org/wg/acme/about/, (acme)", <https://datatracker.ietf.org/wg/acme/charter/>.
n.d..
[WG-CoRE] "IETF Constrained RESTful Environment (CoRE) Working [WG-CoRE] IETF, "Constrained RESTful Environment (core)",
Group", Web https://datatracker.ietf.org/wg/core/charter/, <https://datatracker.ietf.org/wg/core/charter/>.
n.d..
[WG-LPWAN] [WG-LPWAN] IETF, "IPv6 over Low Power Wide-Area Networks (lpwan)",
"IETF Low Power Wide-Area Networks Working Group", <https://datatracker.ietf.org/wg/lpwan/charter/>.
Web https://datatracker.ietf.org/wg/lpwan/, n.d..
[WG-LWIG] "IETF Light-Weight Implementation Guidance (LWIG) Working [WG-LWIG] IETF, "Light-Weight Implementation Guidance (lwig)",
Group", Web https://datatracker.ietf.org/wg/lwig/charter/, <https://datatracker.ietf.org/wg/lwig/charter/>.
n.d..
[WG-MSEC] "IETF MSEC Working Group", [WG-MSEC] IETF, "Multicast Security (msec)",
Web https://datatracker.ietf.org/wg/msec/, n.d.. <https://datatracker.ietf.org/wg/msec/charter/>.
[WG-SUIT] "IETF Software Updates for Internet of Things (suit)", [WG-SUIT] IETF, "Software Updates for Internet of Things (suit)",
Web https://datatracker.ietf.org/group/suit/about/, n.d.. <https://datatracker.ietf.org/wg/suit/charter/>.
[WG-TEEP] "IETF Trusted Execution Environment Provisioning (teep)", [WG-TEEP] IETF, "Trusted Execution Environment Provisioning (teep)",
Web https://datatracker.ietf.org/wg/teep/about/, n.d.. <https://datatracker.ietf.org/wg/teep/charter/>.
[wink] "Wink's Outage Shows Us How Frustrating Smart Homes Could [Williams] Williams, M. and J. Barrett, "Mobile DTLS", Work in
Be", Web http://www.wired.com/2015/04/smart-home- Progress, draft-barrett-mobile-dtls-00, March 2009.
headaches/, n.d..
[ZB] "ZigBee Alliance", Web http://www.zigbee.org/, February [wink] Barrett, B., "Wink's Outage Shows Us How Frustrating Smart
2011. Homes Could Be", Wired, Gear, April 2015,
<http://www.wired.com/2015/04/smart-home-headaches/>.
[ZB] "Zigbee Alliance", <http://www.zigbee.org/>.
[Ziegeldorf] [Ziegeldorf]
Ziegeldorf, J., Garcia-Morchon, O., and K. Wehrle,, Ziegeldorf, J., Garcia Morchon, O., and K. Wehrle,
"Privacy in the Internet of Things: Threats and "Privacy in the Internet of Things: Threats and
Challenges", Security and Communication Networks - Special Challenges", Security and Communication Networks, Vol. 7,
Issue on Security in a Completely Interconnected World , Issue 12, pp. 2728-2742, DOI 10.1002/sec.795, 2014.
2013.
Acknowledgments
We gratefully acknowledge feedback and fruitful discussion with
Tobias Heer, Robert Moskowitz, Thorsten Dahm, Hannes Tschofenig,
Carsten Bormann, Barry Raveendran, Ari Keranen, Goran Selander, Fred
Baker, Vicent Roca, Thomas Fossati, and Eliot Lear. We acknowledge
the additional authors of a draft version of this document: Sye Loong
Keoh, Rene Hummen, and Rene Struik.
Authors' Addresses Authors' Addresses
Oscar Garcia-Morchon Oscar Garcia-Morchon
Philips IP&S Philips
High Tech Campus 5 High Tech Campus 5
Eindhoven, 5656 AA Eindhoven, 5656 AE
The Netherlands The Netherlands
Email: oscar.garcia-morchon@philips.com Email: oscar.garcia-morchon@philips.com
Sandeep S. Kumar Sandeep S. Kumar
Philips Research Signify
High Tech Campus High Tech Campus 7
Eindhoven, 5656 AA Eindhoven, 5656 AE
The Netherlands The Netherlands
Email: sandeep.kumar@philips.com Email: sandeep.kumar@signify.com
Mohit Sethi Mohit Sethi
Ericsson Ericsson
Hirsalantie 11 Jorvas 02420
Jorvas, 02420
Finland Finland
Email: mohit@piuha.net Email: mohit@piuha.net
 End of changes. 305 change blocks. 
947 lines changed or deleted 972 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/