draft-ietf-lwig-crypto-sensors-06.txt   rfc8387.txt 
Light-Weight Implementation Guidance M. Sethi Internet Engineering Task Force (IETF) M. Sethi
Internet-Draft J. Arkko Request for Comments: 8387 J. Arkko
Intended status: Informational A. Keranen Category: Informational A. Keranen
Expires: August 30, 2018 Ericsson ISSN: 2070-1721 Ericsson
H. Back H. Back
Nokia Nokia
February 26, 2018 May 2018
Practical Considerations and Implementation Experiences in Securing Practical Considerations and Implementation Experiences in
Smart Object Networks Securing Smart Object Networks
draft-ietf-lwig-crypto-sensors-06
Abstract Abstract
This memo describes challenges associated with securing resource- This memo describes challenges associated with securing resource-
constrained smart object devices. The memo describes a possible constrained smart object devices. The memo describes a possible
deployment model where resource-constrained devices sign message deployment model where resource-constrained devices sign message
objects, discusses the availability of cryptographic libraries for objects, discusses the availability of cryptographic libraries for
resource-constrained devices and presents some preliminary resource-constrained devices, and presents some preliminary
experiences with those libraries for message signing on resource- experiences with those libraries for message signing on resource-
constrained devices. Lastly, the memo discusses trade-offs involving constrained devices. Lastly, the memo discusses trade-offs involving
different types of security approaches. different types of security approaches.
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 Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on August 30, 2018. 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/rfc8387.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 6 4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 6
4.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Protocol Architecture . . . . . . . . . . . . . . . . . . 9 4.2. Protocol Architecture . . . . . . . . . . . . . . . . . . 9
5. Code Availability . . . . . . . . . . . . . . . . . . . . . . 10 5. Code Availability . . . . . . . . . . . . . . . . . . . . . . 10
6. Implementation Experiences . . . . . . . . . . . . . . . . . 11 6. Implementation Experiences . . . . . . . . . . . . . . . . . 12
7. Example Application . . . . . . . . . . . . . . . . . . . . . 18 7. Example Application . . . . . . . . . . . . . . . . . . . . . 18
8. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21 8. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Feasibility . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Feasibility . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 22 8.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 22
8.3. Layering . . . . . . . . . . . . . . . . . . . . . . . . 24 8.3. Layering . . . . . . . . . . . . . . . . . . . . . . . . 24
8.4. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . 26 8.4. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . 26
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12. Informative references . . . . . . . . . . . . . . . . . . . 27 12. Informative References . . . . . . . . . . . . . . . . . . . 27
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 34 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This memo describes challenges associated with securing smart object This memo describes challenges associated with securing smart object
devices in constrained implementations and environments. In devices in constrained implementations and environments. In
Section 3 we specifically discuss three challenges: the Section 3, we specifically discuss three challenges: the
implementation difficulties encountered on resource-constrained implementation difficulties encountered on resource-constrained
platforms, the problem of provisioning keys and making the choice of platforms, the problem of provisioning keys, and making the choice of
implementing security at the appropriate layer. implementing security at the appropriate layer.
Section 4 discusses a potential deployment model for constrained Section 4 discusses a potential deployment model for constrained
environments. The model requires minimal amount of configuration, environments. The model requires a minimal amount of configuration,
and we believe it is a natural fit with the typical communication and we believe it is a natural fit with the typical communication
practices in smart object networking environments. practices in smart object networking environments.
Section 5 discusses the availability of cryptographic libraries. Section 5 discusses the availability of cryptographic libraries.
Section 6 presents some experiences in implementing cryptography on Section 6 presents some experiences in implementing cryptography on
resource-constrained devices using those libraries, including resource-constrained devices using those libraries, including
information about achievable code sizes and speeds on typical information about achievable code sizes and speeds on typical
hardware. hardware. Section 7 describes an example proof-of-concept prototype
implementation that uses public-key cryptography on resource-
constrained devices to provide end-to-end data authenticity and
integrity protection.
Finally, Section 8 discusses trade-offs involving different types of Finally, Section 8 discusses trade-offs involving different types of
security approaches. security approaches.
2. Related Work 2. Related Work
Constrained Application Protocol (CoAP) [RFC7252] is a light-weight The Constrained Application Protocol (CoAP) [RFC7252] is a
protocol designed to be used in machine-to-machine applications such lightweight protocol designed to be used in machine-to-machine
as smart energy and building automation. Our discussion uses this applications such as smart energy and building automation. Our
protocol as an example, but the conclusions may apply to other discussion uses this protocol as an example, but the conclusions may
similar protocols. The CoAP base specification [RFC7252] outlines apply to other similar protocols. The CoAP base specification
how to use DTLS [RFC6347] and IPsec [RFC4303] for securing the [RFC7252] outlines how to use DTLS [RFC6347] and IPsec [RFC4303] for
protocol. DTLS can be applied with pairwise shared keys, raw public securing the protocol. DTLS can be applied with pairwise shared
keys or with certificates. The security model in all cases is mutual keys, raw public keys, or certificates. The security model in all
authentication, so while there is some commonality to HTTP [RFC7230] cases is mutual authentication, so while there is some commonality to
in verifying the server identity, in practice the models are quite HTTP [RFC7230] in verifying the server identity, in practice the
different. The use of IPsec with CoAP is described with regards to models are quite different. The use of IPsec with CoAP is described
the protocol requirements, noting that lightweight implementations of with regards to the protocol requirements, noting that lightweight
IKEv2 exist [RFC7815]. However, the CoAP specification is silent on implementations of the Internet Key Exchange Protocol Version 2
policy and other aspects that are normally necessary in order to (IKEv2) exist [RFC7815]. However, the CoAP specification is silent
on policy and other aspects that are normally necessary in order to
implement interoperable use of IPsec in any environment [RFC5406]. implement interoperable use of IPsec in any environment [RFC5406].
[I-D.irtf-t2trg-iot-seccons] documents the different stages in the [IoT-SECURITY] documents the different stages in the life cycle of a
lifecycle of a smart object. Next, it highlights the security smart object. Next, it highlights the security threats for smart
threats for smart objects and the challenges that one might face to objects and the challenges that one might face to protect against
protect against these threats. The document also looks at various these threats. The document also looks at various security protocols
security protocols available, including IKEv2/IPsec [RFC7296], TLS/ available, including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS
SSL [RFC5246], DTLS [RFC6347], HIP [RFC7401], [RFC6347], the Host Identity Protocol (HIP) [RFC7401], HIP Diet
[I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP [RFC3748]. Lastly, EXchange [HIP-DEX], a Protocol for Carrying Authentication for
[I-D.sarikaya-t2trg-sbootstrapping] discusses bootstrapping Network Access (PANA) [RFC5191], and the Extensible Authentication
mechanisms available for resource-constrained IoT devices. Protocol (EAP) [RFC3748]. Lastly, [IoT-BOOTSTRAPPING] discusses
bootstrapping mechanisms available for resource-constrained Internet
of Things (IoT) devices.
[RFC6574] gives an overview of the security discussions at the March [RFC6574] gives an overview of the security discussions at the March
2011 IAB workshop on smart objects. The workshop recommended that 2011 IAB workshop on smart objects. The workshop recommended that
additional work should be undertaken in developing suitable additional work should be undertaken in developing suitable
credential management mechanisms (perhaps something similar to the credential management mechanisms (perhaps something similar to the
Bluetooth pairing mechanism), understanding the implementability of Bluetooth pairing mechanism), understanding the implementability of
standard security mechanisms in resource-constrained devices, and standard security mechanisms in resource-constrained devices, and
additional research in the area of lightweight cryptographic conducting additional research in the area of lightweight
primitives. cryptographic primitives.
[I-D.moskowitz-hip-dex] defines a light-weight version of the HIP [HIP-DEX] defines a lightweight version of the HIP protocol for low-
protocol for low-power nodes. This version uses a fixed set of power nodes. This version uses a fixed set of algorithms, Elliptic
algorithms, Elliptic Curve Cryptography (ECC), and eliminates hash Curve Cryptography (ECC), and eliminates hash functions. The
functions. The protocol still operates based on host identities, and protocol still operates based on host identities and runs end-to-end
runs end-to-end between hosts, protecting all IP layer between hosts, protecting all IP-layer communications. [RFC6078]
communications. [RFC6078] describes an extension of HIP that can be describes an extension of HIP that can be used to send upper-layer
used to send upper layer protocol messages without running the usual protocol messages without running the usual HIP base exchange at all.
HIP base exchange at all.
[I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis [IPV6-LOWPAN-SEC] makes a comprehensive analysis of security issues
of security issues related to 6LoWPAN networks, but its findings also related to IPv6 over Low-Power Wireless Personal Area Network
apply more generally for all low-powered networks. Some of the (6LoWPAN) networks, but its findings also apply more generally for
issues this document discusses include the need to minimize the all low-powered networks. Some of the issues this document discusses
number of transmitted bits and simplify implementations, threats in include the need to minimize the number of transmitted bits and
the smart object networking environments, and the suitability of simplify implementations, threats in the smart object networking
6LoWPAN security mechanisms, IPsec, and key management protocols for environments, and the suitability of 6LoWPAN security mechanisms,
implementation in these environments. IPsec, and key management protocols for implementation in these
environments.
3. Challenges 3. Challenges
This section discusses three challenges: 1) implementation This section discusses three challenges: 1) implementation
difficulties, 2) practical provisioning problems, 3) layering and difficulties, 2) practical provisioning problems, and 3) layering and
communication models. communication models.
One of the most often discussed issues in the security for the One of the most often discussed issues in the security for the
Internet of Things relate to implementation difficulties. The desire Internet of Things relate to implementation difficulties. The desire
to build resource-constrained, battery-operated, and inexpensive to build resource-constrained, battery-operated, and inexpensive
devices drives the creation of devices with a limited protocol and devices drives the creation of devices with a limited protocol and
application suite. Some of the typical limitations include running application suite. Some of the typical limitations include running
CoAP instead of HTTP, limited support for security mechanisms, CoAP instead of HTTP, limited support for security mechanisms,
limited processing power for long key lengths, sleep schedule that limited processing power for long key lengths, a sleep schedule that
does not allow communication at all times, and so on. In addition, does not allow communication at all times, and so on. In addition,
the devices typically have very limited support for configuration, the devices typically have very limited support for configuration,
making it hard to set up secrets and trust anchors. making it hard to set up secrets and trust anchors.
The implementation difficulties are important, but they should not be The implementation difficulties are important, but they should not be
overemphasized. It is important to select the right security overemphasized. It is important to select the right security
mechanisms and avoid duplicated or unnecessary functionality. But at mechanisms and avoid duplicated or unnecessary functionality. But at
the end of the day, if strong cryptographic security is needed, the the end of the day, if strong cryptographic security is needed, the
implementations have to support that. It is important for developers implementations have to support that. It is important for developers
and product designers to determine what security threats they want to and product designers to determine what security threats they want to
tackle and the resulting security requirements before selecting the tackle and the resulting security requirements before selecting the
hardware. Often, development work in the wild happens in the wrong hardware. Often, development work in the wild happens in the wrong
order: a particular platform with a resource-constrained order: a particular platform with a resource-constrained
microcontroller is chosen first, and then the security features that microcontroller is chosen first, and then the security features that
can fit on it are decided. Also, the use of the most lightweight can fit on it are decided. Also, the most lightweight algorithms and
algorithms and cryptographic primitives is useful, but should not be cryptographic primitives are useful but should not be the only
the only consideration in the design and development. consideration in the design and development. Interoperability is
Interoperability is also important, and often other parts of the also important, and often other parts of the system, such as key
system, such as key management protocols or certificate formats are management protocols or certificate formats, are heavier to implement
heavier to implement than the algorithms themselves. than the algorithms themselves.
The second challenge relates to practical provisioning problems. The second challenge relates to practical provisioning problems.
This is perhaps the most fundamental and difficult issue, and This is perhaps the most fundamental and difficult issue and is
unfortunately often neglected in the design. There are several unfortunately often neglected in the design. There are several
problems in the provisioning and management of smart object networks: problems in the provisioning and management of smart object networks:
o Resource-constrained devices have no natural user interface for o Resource-constrained devices have no natural user interface for
configuration that would be required for the installation of configuration that would be required for the installation of
shared secrets and other security-related parameters. Typically, shared secrets and other security-related parameters. Typically,
there is no keyboard, no display, and there may not even be there is no keyboard or display, and there may not even be buttons
buttons to press. Some devices may only have one interface, the to press. Some devices may only have one interface, the interface
interface to the network. to the network.
o Manual configuration is rarely, if at all, possible, as the o Manual configuration is rarely, if at all, possible, as the
necessary skills are missing in typical installation environments necessary skills are missing in typical installation environments
(such as in family homes). (such as in family homes).
o There may be a large number of devices. Configuration tasks that o There may be a large number of devices. Configuration tasks that
may be acceptable when performed for one device may become may be acceptable when performed for one device may become
unacceptable with dozens or hundreds of devices. unacceptable with dozens or hundreds of devices.
o Smart object networks may rely on different radio technologies. o Smart object networks may rely on different radio technologies.
skipping to change at page 5, line 44 skipping to change at page 6, line 20
In light of the above challenges, resource-constrained devices are In light of the above challenges, resource-constrained devices are
often shipped with a single static identity. In many cases, it is a often shipped with a single static identity. In many cases, it is a
single raw public key. These long-term static identities makes it single raw public key. These long-term static identities makes it
easy to track the devices (and their owners) when they move. The easy to track the devices (and their owners) when they move. The
static identities may also allow an attacker to track these devices static identities may also allow an attacker to track these devices
across ownership changes. across ownership changes.
Finally, layering and communication models present difficulties for Finally, layering and communication models present difficulties for
straightforward use of the most obvious security mechanisms. Smart straightforward use of the most obvious security mechanisms. Smart
object networks typically pass information through multiple object networks typically pass information through multiple
participating nodes [I-D.arkko-core-sleepy-sensors] and end-to-end participating nodes [CoAP-SENSORS], and end-to-end security for IP or
security for IP or transport layers may not fit such communication transport layers may not fit such communication models very well.
models very well. The primary reasons for needing middleboxes The primary reasons for needing middleboxes relate to the need to
relates to the need to accommodate for sleeping nodes as well to accommodate for sleeping nodes as well to enable the implementation
enable the implementation of nodes that store or aggregate of nodes that store or aggregate information.
information.
4. Proposed Deployment Model 4. Proposed Deployment Model
[I-D.arkko-core-security-arch] recognizes the provisioning model as [CoAP-SECURITY] recognizes the provisioning model as the driver of
the driver of what kind of security architecture is useful. This what kind of security architecture is useful. This section
section re-introduces this model briefly here in order to facilitate reintroduces this model briefly here in order to facilitate the
the discussion of the various design alternatives later. discussion of the various design alternatives later.
The basis of the proposed architecture are self-generated secure The basis of the proposed architecture are self-generated secure
identities, similar to Cryptographically Generated Addresses (CGAs) identities, similar to Cryptographically Generated Addresses (CGAs)
[RFC3972] or Host Identity Tags (HITs) [RFC7401]. That is, we assume [RFC3972] or Host Identity Tags (HITs) [RFC7401]. That is, we assume
the following holds: the following holds:
I = h(P|O) I = h(P|O)
where I is the secure identity of the device, h is a hash function, P where I is the secure identity of the device, h is a hash function, P
is the public key from a key pair generated by the device, and O is is the public key from a key pair generated by the device, and O is
optional other information. | here denotes the concatenation optional other information. "|" (vertical bar) here denotes the
operator. concatenation operator.
4.1. Provisioning 4.1. Provisioning
As it is difficult to provision security credentials, shared secrets, As it is difficult to provision security credentials, shared secrets,
and policy information, the provisioning model is based only on the and policy information, the provisioning model is based only on the
secure identities. A typical network installation involves physical secure identities. A typical network installation involves physical
placement of a number of devices while noting the identities of these placement of a number of devices while noting the identities of these
devices. This list of short identifiers can then be fed to a central devices. This list of short identifiers can then be fed to a central
server as a list of authorized devices. Secure communications can server as a list of authorized devices. Secure communications can
then commence with the devices, at least as far as information from then commence with the devices, at least as far as information from
from the devices to the server is concerned, which is what is needed the devices to the server is concerned, which is what is needed for
for sensor networks. sensor networks.
The above architecture is a perfect fit for sensor networks where The above architecture is a perfect fit for sensor networks where
information flows from large number of devices to small number of information flows from a large number of devices to a small number of
servers. But it is not sufficient alone for other types of servers. But it is not sufficient alone for other types of
applications. For instance, in actuator applications a large number applications. For instance, in actuator applications, a large number
of devices need to take commands from somewhere else. In such of devices need to take commands from somewhere else. In such
applications it is necessary to secure that the commands come from an applications, it is necessary to secure that the commands come from
authorized source. an authorized source.
This can be supported, with some additional provisioning effort and This can be supported, with some additional provisioning effort and
optional pairing protocols. The basic provisioning approach is as optional pairing protocols. The basic provisioning approach is as
described earlier, but in addition there must be something that described earlier; however, in addition there must be something that
informs the devices of the identity of the trusted server(s). There informs the devices of the identity of the trusted server(s). There
are multiple ways to provide this information. One simple approach are multiple ways to provide this information. One simple approach
is to feed the identities of the trusted server(s) to devices at is to feed the identities of the trusted server(s) to devices at
installation time. This requires either a separate user interface, installation time. This requires a separate user interface, a local
local connection (such as USB), or using the network interface of the connection (such as USB), or use of the network interface of the
device for configuration. In any case, as with sensor networks the device for configuration. In any case, as with sensor networks, the
amount of configuration information is minimized: just one short amount of configuration information is minimized: just one short
identity value needs to be fed in (not both an identity and identity value needs to be fed in (not both an identity and
certificate or shared secrets that must be kept confidential). An certificate or shared secrets that must be kept confidential). An
even simpler provisioning approach is that the devices in the device even simpler provisioning approach is that the devices in the device
group trust each other. Then no configuration is needed at group trust each other. Then no configuration is needed at
installation time. installation time.
Once both the parties interested in communicating know the expected Once both the parties interested in communicating know the expected
cryptographic identity of the other off-line, secure communications cryptographic identity of the other offline, secure communications
can commence. Alternatively, various pairing schemes can be can commence. Alternatively, various pairing schemes can be
employed. Note that these schemes can benefit from the already employed. Note that these schemes can benefit from the already
secure identifiers on the device side. For instance, the server can secure identifiers on the device side. For instance, the server can
send a pairing message to each device after their initial power-on send a pairing message to each device after their initial power-on
and before they have been paired with anyone, encrypted with the and before they have been paired with anyone, encrypted with the
public key of the device. As with all pairing schemes that do not public key of the device. As with all pairing schemes that do not
employ a shared secret or the secure identity of both parties, there employ a shared secret or the secure identity of both parties, there
are some remaining vulnerabilities that may or may not be acceptable are some remaining vulnerabilities that may or may not be acceptable
for the application in question. For example, many leap-of-faith or for the application in question. For example, many pairing methods
trust-on-first-use based pairing methods assume that the attacker is based on "leap of faith" or "trust on first use" assume that the
not present during the initial setup. Therefore, they are vulnerable attacker is not present during the initial setup. Therefore, they
to eavesdropping or man-in-the-middle (MitM) attacks. are vulnerable to eavesdropping or man-in-the-middle (MitM) attacks.
In any case, the secure identities help again in ensuring that the In any case, the secure identities help again in ensuring that the
operations are as simple as possible. Only identities need to be operations are as simple as possible. Only identities need to be
communicated to the devices, not certificates, not shared secrets or communicated to the devices, not certificates, shared secrets, or,
e.g. IPsec policy rules. e.g., IPsec policy rules.
Where necessary, the information collected at installation time may Where necessary, the information collected at installation time may
also include other parameters relevant to the application, such as also include other parameters relevant to the application, such as
the location or purpose of the devices. This would enable the server the location or purpose of the devices. This would enable the server
to know, for instance, that a particular device is the temperature to know, for instance, that a particular device is the temperature
sensor for the kitchen. sensor for the kitchen.
Collecting the identity information at installation time can be Collecting the identity information at installation time can be
arranged in a number of ways. One simple but not completely secure arranged in a number of ways. One simple but not completely secure
method where the last few digits of the identity are printed on a method is where the last few digits of the identity are printed on a
tiny device just a few millimeters across. Alternatively, the tiny device just a few millimeters across. Alternatively, the
packaging for the device may include the full identity (typically 32 packaging for the device may include the full identity (typically 32
hex digits), retrieved from the device at manufacturing time. This hex digits) retrieved from the device at manufacturing time. This
identity can be read, for instance, by a bar code reader carried by identity can be read, for instance, by a bar code reader carried by
the installation personnel. (Note that the identities are not the installation personnel. (Note that the identities are not
secret, the security of the system is not dependent on the identity secret; the security of the system is not dependent on the identity
information leaking to others. The real owner of an identity can information leaking to others. The real owner of an identity can
always prove its ownership with the private key which never leaves always prove its ownership with the private key, which never leaves
the device.) Finally, the device may use its wired network interface the device.) Finally, the device may use its wired network interface
or proximity-based communications, such as Near-Field Communications or proximity-based communications, such as Near-Field Communications
(NFC) or Radio-Frequency Identity tags (RFIDs). Such interfaces (NFC) or Radio-Frequency Identity (RFID) tags. Such interfaces allow
allow secure communication of the device identity to an information secure communication of the device identity to an information
gathering device at installation time. gathering device at installation time.
No matter what the method of information collection is, this No matter what the method of information collection is, this
provisioning model minimizes the effort required to set up the provisioning model minimizes the effort required to set up the
security. Each device generates its own identity in a random, secure security. Each device generates its own identity in a random, secure
key generation process. The identities are self-securing in the key-generation process. The identities are self-securing in the
sense that if you know the identity of the peer you want to sense that if you know the identity of the peer you want to
communicate with, messages from the peer can be signed by the peer's communicate with, messages from the peer can be signed by the peer's
private key and it is trivial to verify that the message came from private key, and it is trivial to verify that the message came from
the expected peer. There is no need to configure an identity and the expected peer. There is no need to configure an identity and
certificate of that identity separately. There is no need to certificate of that identity separately. There is no need to
configure a group secret or a shared secret. There is no need to configure a group secret or a shared secret. There is no need to
configure a trust anchor. In addition, the identities are typically configure a trust anchor. In addition, the identities are typically
collected anyway for application purposes (such as identifying which collected anyway for application purposes (such as identifying which
sensor is in which room). Under most circumstances there is actually sensor is in which room). Under most circumstances, there is
no additional configuration effort from provisioning security. actually no additional configuration effort needed for provisioning
security.
As discussed in the previous section, long-term static identities As discussed in the previous section, long-term static identities
negatively affect the privacy of the devices and their owners. negatively affect the privacy of the devices and their owners.
Therefore, it is beneficial for devices to generate new identities at Therefore, it is beneficial for devices to generate new identities at
appropriate times during their lifecycle. For example, after a appropriate times during their life cycle; an example is after a
factory reset or an ownership handover. Thus, in our proposed factory reset or an ownership handover. Thus, in our proposed
deployment model, the devices would generate a new asymmetric key deployment model, the devices would generate a new asymmetric key
pair and use the new public-key P' to generate the new identity I'. pair and use the new public-key P' to generate the new identity I'.
It is also desirable that these identities are only used during the It is also desirable that these identities are only used during the
provisioning stage. Temporary identities (such as dynamic IPv6 provisioning stage. Temporary identities (such as dynamic IPv6
addresses) can be used for network communication protocols once the addresses) can be used for network communication protocols once the
device is operational. device is operational.
Groups of devices can be managed through single identifiers as well. Groups of devices can be managed through single identifiers as well.
In these deployment cases it is also possible to configure the In these deployment cases, it is also possible to configure the
identity of an entire group of devices, rather than registering the identity of an entire group of devices, rather than registering the
individual devices. For instance, many installations employ a kit of individual devices. For instance, many installations employ a kit of
devices bought from the same manufacturer in one package. It is easy devices bought from the same manufacturer in one package. It is easy
to provide an identity for such a set of devices as follows: to provide an identity for such a set of devices as follows:
Idev = h(Pdev|Potherdev1|Potherdev2|...|Potherdevn) Idev = h(Pdev|Potherdev1|Potherdev2|...|Potherdevn)
Igrp = h(Pdev1|Pdev2|...|Pdevm) Igrp = h(Pdev1|Pdev2|...|Pdevm)
where Idev is the identity of an individual device, Pdev is the where Idev is the identity of an individual device, Pdev is the
public key of that device, and Potherdevi are the public keys of public key of that device, Potherdevi are the public keys of other
other devices in the group, n is all the devices in the group except devices in the group, n is all the devices in the group except the
the device with Pdev as its public key, and m is the total number of device with Pdev as its public key, and m is the total number of
devices in the group. Now, we can define the secure identity of the devices in the group. Now, we can define the secure identity of the
group (Igrp) as a hash of all the public keys of the devices in the group (Igrp) as a hash of all the public keys of the devices in the
group (Pdevi). group (Pdevi).
The installation personnel can scan the identity of the group from The installation personnel can scan the identity of the group from
the box that the kit came in, and this identity can be stored in a the box that the kit came in, and this identity can be stored in a
server that is expected to receive information from the nodes. Later server that is expected to receive information from the nodes. Later
when the individual devices contact this server, they will be able to when the individual devices contact this server, they will be able to
show that they are part of the group, as they can reveal their own show that they are part of the group, as they can reveal their own
public key and the public keys of the other devices. Devices that do public key and the public keys of the other devices. Devices that do
not belong to the kit can not claim to be in the group, because the not belong to the kit cannot claim to be in the group, because the
group identity would change if any new keys were added to the group identity would change if any new keys were added to the
identity of the group (Igrp). identity of the group (Igrp).
4.2. Protocol Architecture 4.2. Protocol Architecture
As noted above, the starting point of the architecture is that nodes As noted above, the starting point of the architecture is that nodes
self-generate secure identities which are then communicated out-of- self-generate secure identities, which are then communicated out of
band to the peers that need to know what devices to trust. To band to the peers that need to know what devices to trust. To
support this model in a protocol architecture, we also need to use support this model in a protocol architecture, we also need to use
these secure identities to implement secure messaging between the these secure identities to implement secure messaging between the
peers, explain how the system can respond to different types of peers, explain how the system can respond to different types of
attacks such as replay attempts, and decide at what protocol layer attacks such as replay attempts, and decide what protocol layer and
and endpoints the architecture should use. endpoints the architecture should use.
The deployment itself is suitable for a variety of design choices The deployment itself is suitable for a variety of design choices
regarding layering and protocol mechanisms. regarding layering and protocol mechanisms. [CoAP-SECURITY] was
[I-D.arkko-core-security-arch] was mostly focused on employing end- mostly focused on employing end-to-end data-object security as
to-end data object security as opposed to hop-by-hop security. But opposed to hop-by-hop security. But other approaches are possible.
other approaches are possible. For instance, HIP in its For instance, HIP in its opportunistic mode could be used to
opportunistic mode could be used to implement largely the same implement largely the same functionality at the IP layer. However,
functionality at the IP layer. However, it is our belief that the it is our belief that the right layer for this solution is at the
right layer for this solution is at the application layer. More application layer, and more specifically, in the data formats
specifically, in the data formats transported in the payload part of transported in the payload part of CoAP. This approach provides the
CoAP. This approach provides the following benefits: following benefits:
o Ability for intermediaries to act as caches to support different o Ability for intermediaries to act as caches to support different
sleep schedules, without the security model being impacted. sleep schedules, without the security model being impacted.
o Ability for intermediaries to be built to perform aggregation, o Ability for intermediaries to be built to perform aggregation,
filtering, storage and other actions, again without impacting the filtering, storage, and other actions, again without impacting the
security of the data being transmitted or stored. security of the data being transmitted or stored.
o Ability to operate in the presence of traditional middleboxes, o Ability to operate in the presence of traditional middleboxes,
such as a protocol translators or even NATs (not that we recommend such as a protocol translators or even NATs (not that we recommend
their use in these environments). their use in these environments).
However, as we will see later there are also some technical However, as we will see later, there are also some technical
implications, namely that link, network, and transport layer implications, namely that link, network, and transport-layer
solutions are more likely to be able to benefit from sessions where solutions are more likely to be able to benefit from sessions where
the cost of expensive operations can be amortized over multiple data the cost of expensive operations can be amortized over multiple data
transmissions. While this is not impossible in data object security transmissions. While this is not impossible in data-object security
solutions, it is generally not the typical arrangement. solutions, it is generally not the typical arrangement.
5. Code Availability 5. Code Availability
For implementing public key cryptography on resource constrained For implementing public-key cryptography on resource-constrained
environments, we chose Arduino Uno board [arduino-uno] as the test environments, we chose the Arduino Uno board [arduino-uno] as the
platform. Arduino Uno has an ATmega328 microcontroller, an 8-bit test platform. Arduino Uno has an ATmega328 microcontroller, an
processor with a clock speed of 16 MHz, 2 kB of RAM, and 32 kB of 8-bit processor with a clock speed of 16 MHz, 2 kB of RAM, and 32 kB
flash memory. Our choice of a 8-bit platform may seem surprising of flash memory. Our choice of an 8-bit platform may seem surprising
since cheaper and more energy-efficient 32-bit platforms are since cheaper and more energy-efficient 32-bit platforms are
available. However, our intention was to evaluate the performance of available. However, our intention was to evaluate the performance of
public-key cryptography on the most resource-constrained platforms public-key cryptography on the most resource-constrained platforms
available. It is reasonable to expect better performance results available. It is reasonable to expect better performance results
from 32-bit microcontrollers. from 32-bit microcontrollers.
For selecting potential asymmetric cryptographic libraries, we For selecting potential asymmetric cryptographic libraries, we
surveyed and came up with a set of possible code sources, and surveyed and came up with a set of possible code sources and
performed an initial analysis of how well they fit the Arduino performed an initial analysis of how well they fit the Arduino
environment. Note that the results are preliminary, and could easily environment. Note that the results are preliminary and could easily
be affected in any direction by implementation bugs, configuration be affected in any direction by implementation bugs, configuration
errors, and other mistakes. It is advisable to verify the numbers errors, and other mistakes. It is advisable to verify the numbers
before relying on them for building something. No significant effort before relying on them for building something. No significant effort
was done to optimize ROM memory usage beyond what the libraries was done to optimize ROM memory usage beyond what the libraries
provided themselves, so those numbers should be taken as upper provided themselves, so those numbers should be taken as upper
limits. limits.
Here is the set of libraries we found: Here is the set of libraries we found:
o AvrCryptolib [avr-cryptolib]: This library provides symmetric key o AVRCryptoLib [avr-cryptolib]: This library provides symmetric key
algorithms such as AES. It provides RSA as an asymmetric key algorithms such as AES. It provides RSA as an asymmetric key
algorithm. Parts of the library were written in AVR-8 bit algorithm. Parts of the library were written in AVR 8-bit
assembly language to reduce the size and optimize the performance. assembly language to reduce the size and optimize the performance.
o Relic-Toolkit [relic-toolkit]: This library is written entirely in o Relic-toolkit [relic-toolkit]: This library is written entirely in
C and provides a highly flexible and customizable implementation C and provides a highly flexible and customizable implementation
of a large variety of cryptographic algorithms. This not only of a large variety of cryptographic algorithms. This not only
includes RSA and ECC, but also pairing based asymmetric includes RSA and ECC but also pairing-based asymmetric
cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures. cryptography, Boneh-Lynn-Shacham signatures, and Boneh-Boyen short
The library has also added support for curve25519 (for elliptic signatures. The library has also added support for curve25519
curve Diffie-Hellman key exchange) [RFC7748] and edwards25519 (for (for Elliptic Curve Diffie-Hellman key exchange) [RFC7748] and
elliptic curve digital signatures) [RFC8032]. The toolkit edwards25519 (for elliptic curve digital signatures) [RFC8032].
provides an option to build only the desired components for the The toolkit provides an option to build only the desired
required platform. components for the required platform.
o TinyECC [tinyecc]: TinyECC was designed for using elliptic curve o TinyECC [tinyecc]: TinyECC was designed for using elliptic-curve-
based public key cryptography on sensor networks. It is written based public-key cryptography on sensor networks. It is written
in the nesC programming language [nesC] and as such is designed in the nesC programming language [nesC] and as such is designed
for specific use on TinyOS. However, the library can be ported to for specific use on TinyOS. However, the library can be ported to
standard C either with tool-chains or manually rewriting parts of standard C either with tool chains or by manually rewriting parts
the code. It also has one of the smallest memory footprints among of the code. It also has one of the smallest memory footprints
the set of elliptic curve libraries surveyed so far. among the set of elliptic curve libraries surveyed so far.
o Wiselib [wiselib]: Wiselib is a generic library written for sensor o Wiselib [wiselib]: Wiselib is a generic library written for sensor
networks containing a wide variety of algorithms. While the networks containing a wide variety of algorithms. While the
stable version contains algorithms for routing only, the test stable version contains algorithms for routing only, the test
version includes many more algorithms including algorithms for version includes algorithms for cryptography, localization,
cryptography, localization, topology management and many more. topology management, and many more. The library was designed with
The library was designed with the idea of making it easy to the idea of making it easy to interface the library with operating
interface the library with operating systems like iSense and systems like iSense and Contiki. However, since the library is
Contiki. However, since the library is written entirely in C++ written entirely in C++ with a template-based model similar to
with a template based model similar to Boost/CGAL, it can be used Boost/CGAL, it can be used on any platform directly without using
on any platform directly without using any of the operating system any of the operating system interfaces provided. This approach
interfaces provided. This approach was taken to test the code on was taken to test the code on Arduino Uno.
Arduino Uno.
o MatrixSSL [matrix-ssl]: This library provides a low footprint o MatrixSSL [matrix-ssl]: This library provides a low footprint
implementation of several cryptographic algorithms including RSA implementation of several cryptographic algorithms including RSA
and ECC (with a commercial license). The library in the original and ECC (with a commercial license). The library in the original
form takes about 50 kB of ROM and is intended for 32-bit form takes about 50 kB of ROM and is intended for 32-bit
platforms. platforms.
This is by no ways an exhaustive list and there exist other This is by no means an exhaustive list, and there exists other
cryptographic libraries targeting resource-constrained devices. cryptographic libraries targeting resource-constrained devices.
There are also a number of operating systems that are specifically There are also a number of operating systems that are specifically
targeted for resource-constrained devices. These operating systems targeted for resource-constrained devices. These operating systems
may included libraries and code for security. Hahm et al.[hahmos] may include libraries and code for security. Hahm et al. [hahmos]
conduct a survey of such operating systems. The ARM mbed OS [mbed] conducted a survey of such operating systems. The ARM Mbed OS [mbed]
is one such operating system that provides various cryptographic is one such operating system that provides various cryptographic
primitives that are necessary for SSL/TLS protocol implementation as primitives that are necessary for SSL/TLS protocol implementation as
well as X509 certificate handling. The library provides an API for well as X509 certificate handling. The library provides an API for
developer with a minimal code footprint. It is intended for various developers with a minimal code footprint. It is intended for various
ARM platforms such as ARM Cortex M0, ARM Cortex M0+ and ARM Cortex ARM platforms such as ARM Cortex M0, ARM Cortex M0+, and ARM Cortex
M3. M3.
6. Implementation Experiences 6. Implementation Experiences
While evaluating the implementation experiences, we were particularly While evaluating the implementation experiences, we were particularly
interested in the signature generation operation. This was because interested in the signature generation operation. This was because
our example application discussed in Section 7 required only the our example application discussed in Section 7 required only the
signature generation operation on the resource-constrained platforms. signature generation operation on the resource-constrained platforms.
We have summarized the initial results of RSA private key We have summarized the initial results of RSA private-key
exponentiation performance using AvrCryptolib [avr-crypto-lib] in exponentiation performance using AVRCryptoLib [avr-crypto-lib] in
Table 1. All results are from a single run since repeating the test Table 1. All results are from a single run since repeating the test
did not change (or had only minimal impact on) the results. The did not change (or had only minimal impact on) the results. The
execution time for a key size of 2048 bits was inordinately long and execution time for a key size of 2048 bits was inordinately long and
would be a deterrent in real-world deployments. would be a deterrent in real-world deployments.
+--------------+------------------------+---------------------------+ +--------------+------------------------+---------------------------+
| Key length | Execution time (ms); | Memory footprint (bytes); | | Key length | Execution time (ms); | Memory footprint (bytes); |
| (bits) | key in RAM | key in RAM | | (bits) | key in RAM | key in RAM |
+--------------+------------------------+---------------------------+ +--------------+------------------------+---------------------------+
| 2048 | 1587567 | 1280 | | 2048 | 1587567 | 1280 |
+--------------+------------------------+---------------------------+ +--------------+------------------------+---------------------------+
RSA private key operation performance Table 1: RSA Private-Key Operation Performance
Table 1
The code size was about 3.6 kB with potential for further reduction. The code size was about 3.6 kB with potential for further reduction.
It is also worth noting that the implementation performs basic It is also worth noting that the implementation performs basic
exponentiation and multiplication operations without using any exponentiation and multiplication operations without using any
mathematical optimizations such as Montgomery multiplication, mathematical optimizations such as Montgomery multiplication,
optimized squaring, etc. as described in [rsa-high-speed]. With more optimized squaring, etc., as described in [rsa-high-speed]. With
RAM, we believe that 2048-bit operations can be performed in much more RAM, we believe that 2048-bit operations can be performed in
less time as has been shown in [rsa-8bit]. much less time as has been shown in [rsa-8bit].
In Table 2 we present the results obtained by manually porting In Table 2, we present the results obtained by manually porting
TinyECC into C99 standard and running the Elliptic Curve Digital TinyECC into the C99 standard and running the Elliptic Curve Digital
Signature Algorithm (ECDSA) on the Arduino Uno board. TinyECC Signature Algorithm (ECDSA) on the Arduino Uno board. TinyECC
supports a variety of SEC 2 recommended Elliptic Curve domain supports a variety of SEC-2-recommended elliptic curve domain
parameters [sec2ecc]. The execution time and memory footprint are parameters [sec2ecc]. The execution time and memory footprint are
shown next to each of the curve parameters. These results were shown next to each of the curve parameters. These results were
obtained by turning on all the optimizations and using assembly code obtained by turning on all the optimizations and using assembly code
where available. where available.
The results from the performance evaluation of ECDSA in the following The results from the performance evaluation of ECDSA in the following
tables also contains a column stating the approximate comparable RSA tables also contain a column stating the approximate comparable RSA
key length as documented in [sec2ecc]. It is clearly observable that key length as documented in [sec2ecc]. It is clearly observable that
for similar security levels, Elliptic Curve public key cryptography for similar security levels, elliptic curve public-key cryptography
outperforms RSA. outperforms RSA.
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
| Curve | Execution | Memory | Comparable RSA | | Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | Footprint | key length | | parameters | time (ms) | footprint | key length |
| | | (bytes) | | | | | (bytes) | |
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
| secp160k1 | 2228 | 892 | 1024 | | secp160k1 | 2228 | 892 | 1024 |
| secp160r1 | 2250 | 892 | 1024 | | secp160r1 | 2250 | 892 | 1024 |
| secp160r2 | 2467 | 892 | 1024 | | secp160r2 | 2467 | 892 | 1024 |
| secp192k1 | 3425 | 1008 | 1536 | | secp192k1 | 3425 | 1008 | 1536 |
| secp192r1 | 3578 | 1008 | 1536 | | secp192r1 | 3578 | 1008 | 1536 |
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
Performance of ECDSA sign operation with TinyECC Table 2: Performance of ECDSA Sign Operation with TinyECC
Table 2
We also performed experiments by removing the assembly optimization We also performed experiments by removing the assembly optimization
and using a C only form of the library. This gives us an idea of the and using a C-only form of the library. This gives us an idea of the
performance that can be achieved with TinyECC on any platform performance that can be achieved with TinyECC on any platform
regardless of what kind of OS and assembly instruction set available. regardless of what kind of OS and assembly instruction set is
The memory footprint remains the same with or without assembly code. available. The memory footprint remains the same with or without
The tables contain the maximum RAM that is used when all the possible assembly code. The tables contain the maximum RAM that is used when
optimizations are on. If however, the amount of RAM available is all the possible optimizations are on. However, if the amount of RAM
smaller in size, some of the optimizations can be turned off to available is smaller in size, some of the optimizations can be turned
reduce the memory consumption accordingly. off to reduce the memory consumption accordingly.
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
| Curve | Execution | Memory | Comparable RSA | | Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | Footprint | key length | | parameters | time (ms) | footprint | key length |
| | | (bytes) | | | | | (bytes) | |
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
| secp160k1 | 3795 | 892 | 1024 | | secp160k1 | 3795 | 892 | 1024 |
| secp160r1 | 3841 | 892 | 1024 | | secp160r1 | 3841 | 892 | 1024 |
| secp160r2 | 4118 | 892 | 1024 | | secp160r2 | 4118 | 892 | 1024 |
| secp192k1 | 6091 | 1008 | 1536 | | secp192k1 | 6091 | 1008 | 1536 |
| secp192r1 | 6217 | 1008 | 1536 | | secp192r1 | 6217 | 1008 | 1536 |
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
Performance of ECDSA sign operation with TinyECC (No assembly Table 3: Performance of ECDSA Sign Operation with TinyECC
optimizations) (No Assembly Optimizations)
Table 3
Table 4 documents the performance of Wiselib. Since there were no Table 4 documents the performance of Wiselib. Since there were no
optimizations that could be turned on or off, we have only one set of optimizations that could be turned on or off, we have only one set of
results. By default Wiselib only supports some of the standard SEC 2 results. By default, Wiselib only supports some of the standard SEC
Elliptic curves, but it is easy to change the domain parameters and 2 elliptic curves, but it is easy to change the domain parameters and
obtain results for all the 128, 160 and 192-bit SEC 2 Elliptic obtain results for all the 128-, 160-, and 192-bit SEC 2 elliptic
curves. The ROM size for all the experiments was less than 16 kB. curves. The ROM size for all the experiments was less than 16 kB.
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
| Curve | Execution | Memory | Comparable RSA | | Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | Footprint | key length | | parameters | time (ms) | footprint | key length |
| | | (bytes) | | | | | (bytes) | |
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
| secp160k1 | 10957 | 842 | 1024 | | secp160k1 | 10957 | 842 | 1024 |
| secp160r1 | 10972 | 842 | 1024 | | secp160r1 | 10972 | 842 | 1024 |
| secp160r2 | 10971 | 842 | 1024 | | secp160r2 | 10971 | 842 | 1024 |
| secp192k1 | 18814 | 952 | 1536 | | secp192k1 | 18814 | 952 | 1536 |
| secp192r1 | 18825 | 952 | 1536 | | secp192r1 | 18825 | 952 | 1536 |
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
Performance ECDSA sign operation with Wiselib Table 4: Performance ECDSA Sign Operation with Wiselib
Table 4
For testing the relic-toolkit we used a different board because it For testing the relic-toolkit, we used a different board because it
required more RAM/ROM and we were unable to perform experiments with required more RAM/ROM, and we were unable to perform experiments with
it on Arduino Uno. Arduino Mega has the same 8-bit architecture like it on Arduino Uno. Arduino Mega has the same 8-bit architecture as
the Arduino Uno but has a much larger RAM/ROM. We used Arduino Mega Arduino Uno, but it has a much larger RAM/ROM. We used Arduino Mega
for experimenting with the relic-toolkit. Again, it is important to for experimenting with the relic-toolkit. Again, it is important to
mention that we used Arduino as it is a convenient prototyping mention that we used Arduino as it is a convenient prototyping
platform. Our intention was to demonstrate the feasibility of the platform. Our intention was to demonstrate the feasibility of the
entire architecture with public key cryptography on an 8-bit entire architecture with public-key cryptography on an 8-bit
microcontroller. However it is important to state that 32-bit microcontroller. However, it is important to state that 32-bit
microcontrollers are much more easily available, at lower costs and microcontrollers are much more easily available, at lower costs, and
are more power efficient. Therefore, real deployments are better off are more power efficient. Therefore, real deployments are better off
using 32-bit microcontrollers that allow developers to include the using 32-bit microcontrollers that allow developers to include the
necessary cryptographic libraries. There is no good reason to choose necessary cryptographic libraries. There is no good reason to choose
platforms that do not provide sufficient computing power to run the platforms that do not provide sufficient computing power to run the
necessary cryptographic operations. necessary cryptographic operations.
The relic-toolkit supports Koblitz curves over prime as well as The relic-toolkit supports Koblitz curves over prime as well as
binary fields. We have experimented with Koblitz curves over binary binary fields. We have experimented with Koblitz curves over binary
fields only. We do not run our experiments with all the curves fields only. We do not run our experiments with all the curves
available in the library since the aim of this work is not prove available in the library since the aim of this work is not to prove
which curves perform the fastest, and rather show that asymmetric which curves perform the fastest but rather to show that asymmetric
cryptography is possible on resource-constrained devices. cryptography is possible on resource-constrained devices.
The results from relic-toolkit are documented in two separate tables The results from relic-toolkit are documented separately in Tables 5
shown in Table 5 and Table 6. The first set of results were and 6. The first set of results were performed with the library
performed with the library configured for high speed performance with configured for high-speed performance with no consideration given to
no consideration given to the amount of memory used. For the second the amount of memory used. For the second set, the library was
set, the library was configured for low memory usage irrespective of configured for low-memory usage irrespective of the execution time
the execution time required by different curves. By turning on/off required by different curves. By turning on/off optimizations
optimizations included in the library, a trade-off between memory and included in the library, a trade-off between memory and execution
execution time between these values can be achieved. time between these values can be achieved.
+-----------------+--------------+----------------+-----------------+ +-----------------+--------------+----------------+-----------------+
| Curve | Execution | Memory | Comparable RSA | | Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | Footprint | key length | | parameters | time (ms) | footprint | key length |
| | | (bytes) | | | | | (bytes) | |
+-----------------+--------------+----------------+-----------------+ +-----------------+--------------+----------------+-----------------+
| sect163k1 | 261 | 2804 | 1024 | | sect163k1 | 261 | 2804 | 1024 |
| (assembly math) | | | | | (assembly math) | | | |
| sect163k1 | 932 | 2750 | 1024 | | sect163k1 | 932 | 2750 | 1024 |
| sect163r2 | 2243 | 2444 | 1024 | | sect163r2 | 2243 | 2444 | 1024 |
| sect233k1 | 1736 | 3675 | 2048 | | sect233k1 | 1736 | 3675 | 2048 |
| sect233r1 | 4471 | 3261 | 2048 | | sect233r1 | 4471 | 3261 | 2048 |
+-----------------+--------------+----------------+-----------------+ +-----------------+--------------+----------------+-----------------+
Performance of ECDSA sign operation with relic-toolkit (Fast) Table 5: Performance of ECDSA Sign Operation with
relic-toolkit (Fast)
Table 5
+-----------------+--------------+----------------+-----------------+ +-----------------+--------------+----------------+-----------------+
| Curve | Execution | Memory | Comparable RSA | | Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | Footprint | key length | | parameters | time (ms) | footprint | key length |
| | | (bytes) | | | | | (bytes) | |
+-----------------+--------------+----------------+-----------------+ +-----------------+--------------+----------------+-----------------+
| sect163k1 | 592 | 2087 | 1024 | | sect163k1 | 592 | 2087 | 1024 |
| (assembly math) | | | | | (assembly math) | | | |
| sect163k1 | 2950 | 2215 | 1024 | | sect163k1 | 2950 | 2215 | 1024 |
| sect163r2 | 3213 | 2071 | 1024 | | sect163r2 | 3213 | 2071 | 1024 |
| sect233k1 | 6450 | 2935 | 2048 | | sect233k1 | 6450 | 2935 | 2048 |
| sect233r1 | 6100 | 2737 | 2048 | | sect233r1 | 6100 | 2737 | 2048 |
+-----------------+--------------+----------------+-----------------+ +-----------------+--------------+----------------+-----------------+
Performance of ECDSA sign operation with relic-toolkit (Low Memory) Table 6: Performance of ECDSA Sign Operation with relic-toolkit
(Low Memory)
Table 6
It is important to note the following points about the elliptic curve It is important to note the following points about the elliptic curve
measurements: measurements:
o Some boards (e.g. Arduino Uno) do not provide a hardware random o Some boards (e.g., Arduino Uno) do not provide a hardware random
number generator. On such boards, obtaining cryptographic-quality number generator. On such boards, obtaining cryptographic-quality
randomness is a challenge. Real-world deployments must rely on a randomness is a challenge. Real-world deployments must rely on a
hardware random number generator for cryptographic operations such hardware random number generator for cryptographic operations such
as generating a public-private key pair. The Nordic nRF52832 as generating a public-private key pair. The Nordic nRF52832
board [nordic] for example provides a hardware random number board [nordic], for example, provides a hardware random number
generator. A detailed discussion on requirements and best generator. A detailed discussion on requirements and best
practices for cryptographic-quality randomness is documented in practices for cryptographic-quality randomness is documented in
[RFC4086] [RFC4086]
o For measuring the memory footprint of all the ECC libraries, we o For measuring the memory footprint of all the ECC libraries, we
used the Avrora simulator [avrora]. Only stack memory was used to used the Avrora simulator [avrora]. Only stack memory was used to
easily track the RAM consumption. easily track the RAM consumption.
Tschofenig and Pegourie-Gonnard [armecdsa] have also evaluated the Tschofenig and Pegourie-Gonnard [armecdsa] have also evaluated the
performance of Elliptic Curve Cryptography (ECC) on ARM Coretex performance of ECC on an ARM Coretex platform. The results for the
platform. The results for ECDSA sign operation shown in Table 7 are ECDSA sign operation shown in Table 7 are performed on a Freescale
performed on a Freescale FRDM-KL25Z board [freescale] that has a ARM FRDM-KL25Z board [freescale] that has an ARM Cortex-M0+ 48MHz
Cortex-M0+ 48MHz microcontroller with 128kB of flash memory and 16kB microcontroller with 128 kB of flash memory and 16 kB of RAM. The
of RAM. The sliding window technique for efficient exponentiation sliding window technique for efficient exponentiation was used with a
was used with a window size of 2. All other optimizations were window size of 2. All other optimizations were disabled for these
disabled for these measurements. measurements.
+------------------+---------------------+--------------------------+ +------------------+---------------------+--------------------------+
| Curve parameters | Execution time (ms) | Comparable RSA key | | Curve parameters | Execution time (ms) | Comparable RSA key |
| | | length | | | | length |
+------------------+---------------------+--------------------------+ +------------------+---------------------+--------------------------+
| secp192r1 | 2165 | 1536 | | secp192r1 | 2165 | 1536 |
| secp224r1 | 3014 | 2048 | | secp224r1 | 3014 | 2048 |
| secp256r1 | 3649 | 2048 | | secp256r1 | 3649 | 2048 |
+------------------+---------------------+--------------------------+ +------------------+---------------------+--------------------------+
Performance of ECDSA sign operation with ARM mbed TLS stack on Table 7: Performance of ECDSA Sign Operation with an ARM Mbed TLS
Freescale FRDM-KL25Z Stack on Freescale FRDM-KL25Z
Table 7
Tschofenig and Pegourie-Gonnard [armecdsa] also measured the Tschofenig and Pegourie-Gonnard [armecdsa] also measured the
performance of curves on a ST Nucleo F091 (STM32F091RCT6) board performance of curves on an ST Nucleo F091 (STM32F091RCT6) board
[stnucleo] that has a ARM Cortex-M0 48MHz microcontroller with 256 kB [stnucleo] that has an ARM Cortex-M0 48 MHz microcontroller with 256
of flash memory and 32kB of RAM. The execution time for ECDSA sign kB of flash memory and 32 kB of RAM. The execution time for the
operation with different curves is shown in Table 8. The sliding ECDSA sign operation with different curves is shown in Table 8. The
window technique for efficient exponentiation was used with a window sliding window technique for efficient exponentiation was used with a
size of 7. Fixed point optimization and NIST curve specific window size of 7. Fixed-point optimization and NIST curve-specific
optimizations were used for these measurements. optimizations were used for these measurements.
+------------------+---------------------+--------------------------+ +------------------+---------------------+--------------------------+
| Curve parameters | Execution time (ms) | Comparable RSA key | | Curve parameters | Execution time (ms) | Comparable RSA key |
| | | length | | | | length |
+------------------+---------------------+--------------------------+ +------------------+---------------------+--------------------------+
| secp192k1 | 291 | 1536 | | secp192k1 | 291 | 1536 |
| secp192r1 | 225 | 1536 | | secp192r1 | 225 | 1536 |
| secp224k1 | 375 | 2048 | | secp224k1 | 375 | 2048 |
| secp224r1 | 307 | 2048 | | secp224r1 | 307 | 2048 |
| secp256k1 | 486 | 2048 | | secp256k1 | 486 | 2048 |
| secp256r1 | 459 | 2048 | | secp256r1 | 459 | 2048 |
| secp384r1 | 811 | 7680 | | secp384r1 | 811 | 7680 |
| secp521r1 | 1602 | 15360 | | secp521r1 | 1602 | 15360 |
+------------------+---------------------+--------------------------+ +------------------+---------------------+--------------------------+
ECDSA signature performance with ARM mbed TLS stack on ST Nucleo F091 Table 8: ECDSA Signature Performance with an ARM Mbed TLS Stack on ST
(STM32F091RCT6) Nucleo F091 (STM32F091RCT6)
Table 8
Finally, Tschofenig and Pegourie-Gonnard [armecdsa] also measured the Finally, Tschofenig and Pegourie-Gonnard [armecdsa] also measured the
RAM consumption by calculating the heap consumed for the RAM consumption by calculating the heap consumed for the
cryptographic operations using a custom memory allocation handler. cryptographic operations using a custom memory allocation handler.
They did not measure the minimal stack memory consumption. Depending They did not measure the minimal stack memory consumption. Depending
on the curve and the different optimizations enable or disabled, the on the curve and the different optimizations enable or disabled, the
memory consumption for the ECDSA sign operation varied from 1500 memory consumption for the ECDSA sign operation varied from 1500
bytes to 15000 bytes. bytes to 15000 bytes.
At the time of performing these measurements and study, it was At the time of performing these measurements and this study, it was
unclear which exact elliptic curve(s) would be selected by the IETF unclear which exact elliptic curve(s) would be selected by the IETF
community for use with resource-constrained devices. However now, community for use with resource-constrained devices. However,
[RFC7748] defines two elliptic curves over prime fields (Curve25519 [RFC7748] defines two elliptic curves over prime fields (Curve25519
and Curve448) that offer a high level of practical security for and Curve448) that offer a high-level of practical security for
Diffie-Hellman key exchange. Correspondingly, there is ongoing work Diffie-Hellman key exchange. Correspondingly, there is ongoing work
to specify elliptic curve signature schemes with Edwards-curve to specify elliptic curve signature schemes with Edwards-curve
Digital Signature Algorithm (EdDSA). [RFC8032] specifies the Digital Signature Algorithm (EdDSA). [RFC8032] specifies the
recommended parameters for the edwards25519 and edwards448 curves. recommended parameters for the edwards25519 and edwards448 curves.
From these, curve25519 (for elliptic curve Diffie-Hellman key From these, curve25519 (for Elliptic Curve Diffie-Hellman key
exchange) and edwards25519 (for elliptic curve digital signatures) exchange) and edwards25519 (for elliptic curve digital signatures)
are especially suitable for resource-constrained devices. are especially suitable for resource-constrained devices.
We found that the NaCl [nacl] and MicoNaCl [micronacl] libraries We found that the NaCl [nacl] and MicoNaCl [micronacl] libraries
provide highly efficient implementations of Diffie-Hellman key provide highly efficient implementations of Diffie-Hellman key
exchange with curve25519. The results have shown that these exchange with curve25519. The results have shown that these
libraries with curve25519 outperform other elliptic curves that libraries with curve25519 outperform other elliptic curves that
provide similar levels of security. Hutter and Schwabe [naclavr] provide similar levels of security. Hutter and Schwabe [naclavr]
also show that signing of data using the curve Ed25519 from the NaCl also show that the signing of data using the curve Ed25519 from the
library needs only 23216241 cycles on the same microcontroller that NaCl library needs only 23216241 cycles on the same microcontroller
we used for our evaluations (Arduino Mega ATmega2560). This that we used for our evaluations (Arduino Mega ATmega2560). This
corresponds to about 1451 milliseconds of execution time. When corresponds to about 1451 milliseconds of execution time. When
compared to the results for other curves and libraries that offer compared to the results for other curves and libraries that offer a
similar level of security (such as NIST B233, NIST K233), this similar level of security (such as sect233r1 and sect233k1), this
implementation far outperforms all others. As such, it is recommend implementation far outperforms all others. As such, it is
that the IETF community uses these curves for protocol specification recommended that the IETF community use these curves for protocol
and implementations. specification and implementations.
A summary library flash memory use is shown in Table 9. A summary library flash memory use is shown in Table 9.
+------------------------+------------------------------------+ +------------------------+------------------------------------+
| Library | Flash memory Footprint (Kilobytes) | | Library | Flash memory footprint (kilobytes) |
+------------------------+------------------------------------+ +------------------------+------------------------------------+
| AvrCryptolib | 3.6 | | AVRCryptoLib | 3.6 |
| Wiselib | 16 | | Wiselib | 16 |
| TinyECC | 18 | | TinyECC | 18 |
| Relic-toolkit | 29 | | Relic-toolkit | 29 |
| NaCl Ed25519 [naclavr] | 17-29 | | NaCl Ed25519 [naclavr] | 17-29 |
+------------------------+------------------------------------+ +------------------------+------------------------------------+
Summary of library flash memory consumption Table 9: Summary of Library Flash Memory Consumption
Table 9
All the measurements here are only provided as an example to show All the measurements here are only provided as an example to show
that asymmetric-key cryptography (particularly, digital signatures) that asymmetric-key cryptography (particularly, digital signatures)
is possible on resource-constrained devices. These numbers by no way is possible on resource-constrained devices. By no means are these
are the final source for measurements and some curves presented here numbers the final source for measurements, and some curves presented
may not be acceptable for real in-the-wild deployments anymore. For here may no longer be acceptable for real in-the-wild deployments.
example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also For example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also
document performance of ECDSA on similar resource-constrained document the performance of ECDSA on similar resource-constrained
devices. devices.
7. Example Application 7. Example Application
We developed an example application on the Arduino platform to use We developed an example application on the Arduino platform to use
public key crypto mechanisms, data object security, and an easy public-key cryptography, data-object security, and an easy
provisioning model. Our application was originally developed to test provisioning model. Our application was originally developed to test
different approaches to supporting communications to "always off" different approaches to supporting communications to "always off"
sensor nodes. These battery-operated or energy scavenging nodes do sensor nodes. These battery-operated or energy-scavenging nodes do
not have enough power to stay on at all times. They wake up not have enough power to stay on at all times. They wake up
periodically and transmit their readings. periodically and transmit their readings.
Such sensor nodes can be supported in various ways. Such sensor nodes can be supported in various ways. [CoAP-SENSORS]
[I-D.arkko-core-sleepy-sensors] was an early multicast-based was an early multicast-based approach. In the current application,
approach. In the current application we have switched to using we have switched to using resource directories [CoRE-RD] and publish-
resource directories [I-D.ietf-core-resource-directory] and publish- subscribe brokers [CoAP-BROKER] instead. Architecturally, the idea
subscribe brokers [I-D.ietf-core-coap-pubsub] instead. is that sensors can delegate a part of their role to a node in the
Architecturally, the idea is that sensors can delegate a part of network. Such a network node could be either a local resource or
their role to a node in the network. Such a network node could be something in the Internet. In the case of CoAP publish-subscribe
either a local resource or something in the Internet. In the case of brokers, the network node agrees to hold the web resources on behalf
CoAP publish-subscribe brokers, the network node agrees to hold the of the sensor, while the sensor is asleep. The only role that the
web resources on behalf of the sensor, while the sensor is asleep. sensor has is to register itself at the publish-subscribe broker and
The only role that the sensor has is to register itself at the periodically update the readings. All queries from the rest of the
publish-subscribe broker, and periodically update the readings. All world go to the publish-subscribe broker.
queries from the rest of the world go to the publish-subscribe
broker.
We constructed a system with four entities: We constructed a system with four entities:
Sensor Sensor: This is an Arduino-based device that runs a CoAP publish-
subscribe broker client and relic-toolkit. Relic takes 29 kB of
This is an Arduino-based device that runs a CoAP publish-subscribe flash memory, and the simple CoAP client takes roughly 3 kB.
broker client and Relic-toolkit. Relic takes 29 Kbytes of flash
memory, and the simple CoAP client roughly 3 kilobytes.
Publish-Subscribe Broker
This is a publish-subscribe broker that holds resources on the
sensor's behalf. The sensor registers itself to this node.
Resource Directory
While physically in the same node in our implementation, a Publish-Subscribe Broker: This is a publish-subscribe broker that
resource directory is a logical function that allows sensors and holds resources on the sensor's behalf. The sensor registers
publish-subscribe brokers to register resources in the directory. itself to this node.
These resources can be queried by applications.
Application Resource Directory: While physically in the same node in our
implementation, a resource directory is a logical function that
allows sensors and publish-subscribe brokers to register resources
in the directory. These resources can be queried by applications.
This is a simple application that runs on a general purpose Application: This is a simple application that runs on a general
computer and can retrieve both registrations from the resource purpose computer and can retrieve both registrations from the
directory and most recent sensor readings from the publish- resource directory and most recent sensor readings from the
subscribe broker. publish-subscribe broker.
The security of this system relies on an SSH-like approach. In Step The security of this system relies on a secure-shell-like approach.
1, upon first boot, sensors generate keys and register themselves in In Step 1, upon first boot, sensors generate keys and register
the publish-subscribe broker. Their public key is submitted along themselves in the publish-subscribe broker. Their public key is
with the registration as an attribute in the CORE Link Format data submitted along with the registration as an attribute in the CoRE
[RFC6690]. Link Format data [RFC6690].
In Step 2, when the sensor makes a measurement, it sends an update to In Step 2, when the sensor makes a measurement, it sends an update to
the publish-subscribe broker and signs the message contents with a the publish-subscribe broker and signs the message contents with a
JOSE signature on the used JSON/SENML payload [RFC7515] JSON Object Signing and Encryption (JOSE) signature on the used JSON
[I-D.ietf-core-senml]. The sensor can also alternatively use CBOR [RFC7515] and Sensor Measurement List (SenML) payload [MT-SenML].
Object Signing and Encryption (COSE) [RFC8152] for signing the sensor The sensor can also alternatively use CBOR Object Signing and
measurement. Encryption (COSE) [RFC8152] for signing the sensor measurement.
In Step 3, any other device in the network -- including the publish- In Step 3, any other device in the network -- including the publish-
subscribe broker, resource directory and the application -- can check subscribe broker, resource directory, and the application -- can
that the public key from the registration corresponds to the private check that the public key from the registration corresponds to the
key used to make the signature in the data update. private key used to make the signature in the data update.
Note that checks can be done at any time and there is no need for the Note that checks can be done at any time, and there is no need for
sensor and the checking node to be awake at the same time. In our the sensor and the checking node to be awake at the same time. In
implementation, the checking is done in the application node. This our implementation, the checking is done in the application node.
demonstrates how it is possible to implement end-to-end security even This demonstrates how it is possible to implement end-to-end security
with the presence of assisting middleboxes. even with the presence of assisting middleboxes.
To verify the feasibility of our architecture we developed a proof- To verify the feasibility of our architecture, we developed a
of-concept prototype. In our prototype, the sensor was implemented proof-of-concept prototype. In our prototype, the sensor was
using the Arduino Ethernet shield over an Arduino Mega board. Our implemented using the Arduino Ethernet shield over an Arduino Mega
implementation uses the standard C99 programming language on the board. Our implementation uses the standard C99 programming language
Arduino Mega board. In this prototype, the publish-subscribe broker on the Arduino Mega board. In this prototype, the publish-subscribe
and the Resource Directory (RD) reside on the same physical host. A broker and the Resource Directory (RD) reside on the same physical
64-bit x86 linux machine serves as the broker and the RD, while a host. A 64-bit x86 Linux machine serves as the broker and the RD,
similar but physically distinct 64-bit x86 linux machine serves as while a similar but physically distinct 64-bit x86 Linux machine
the client that requests data from the sensor. We chose the Relic serves as the client that requests data from the sensor. We chose
library version 0.3.1 for our sample prototype as it can be easily the Relic library version 0.3.1 for our sample prototype as it can be
compiled for different bit-length processors. Therefore, we were easily compiled for different bit-length processors. Therefore, we
able to use it on the 8-bit processor of the Arduino Mega, as well as were able to use it on the 8-bit processor of the Arduino Mega, as
on the 64-bit processor of the x86 client. We used ECDSA to sign and well as on the 64-bit processor of the x86 client. We used ECDSA to
verify data updates with the standard NIST-K163 curve parameters. sign and verify data updates with the standard sect163k1 curve
While compiling Relic for our prototype, we used the fast parameters. While compiling Relic for our prototype, we used the
configuration without any assembly optimizations. fast configuration without any assembly optimizations.
The gateway implements the CoAP base specification in the Java The gateway implements the CoAP base specification in the Java
programming language and extends it to add support for publish- programming language and extends it to add support for publish-
subscribe broker and Resource Directory REST interfaces. We also subscribe broker and Resource Directory Representational State
developed a minimalistic CoAP C-library for the Arduino sensor and Transfer (REST) interfaces. We also developed a minimalistic CoAP
for the client requesting data updates for a resource. The library C-library for the Arduino sensor and for the client requesting data
has small RAM requirements and uses stack-based allocation only. It updates for a resource. The library has small RAM requirements and
is interoperable with the Java implementation of CoAP running on the uses stack-based allocation only. It is interoperable with the Java
gateway. The location of the resource directory was configured into implementation of CoAP running on the gateway. The location of the
the smart object sensor by hardcoding the IP address. A real resource directory was configured into the smart object sensor by
implementation based on this prototype would instead use the domain hardcoding the IP address. A real implementation based on this
name system for obtaining the location of the resource directory. prototype would instead use the domain name system for obtaining the
location of the resource directory.
Our intention was to demonstrate that it is possible to implement the Our intention was to demonstrate that it is possible to implement the
entire architecture with public-key cryptography on an 8-bit entire architecture with public-key cryptography on an 8-bit
microcontroller. The stated values can be improved further by a microcontroller. The stated values can be improved further by a
considerable amount. For example, the flash memory and RAM considerable amount. For example, the flash memory and RAM
consumption is relatively high because some of the Arduino libraries consumption is relatively high because some of the Arduino libraries
were used out-of-the-box and there are several functions which can be were used out of the box, and there are several functions that can be
removed. Similarly we used the fast version of the Relic library in removed. Similarly, we used the fast version of the Relic library in
the prototype instead of the low memory version. However, it is the prototype instead of the low-memory version. However, it is
important to note that this was only a research prototype to verify important to note that this was only a research prototype to verify
the feasibility of this architecture and as stated elsewhere, most the feasibility of this architecture and, as stated elsewhere, most
modern development boards have a 32-bit microcontroller since they modern development boards have a 32-bit microcontroller since they
are more economical and have better energy efficiency. are more economical and have better energy efficiency.
8. Design Trade-Offs 8. Design Trade-Offs
This section attempts to make some early conclusions regarding trade- This section attempts to make some early conclusions regarding trade-
offs in the design space, based on deployment considerations for offs in the design space, based on deployment considerations for
various mechanisms and the relative ease or difficulty of various mechanisms and the relative ease or difficulty of
implementing them. In particular, this analysis looks at layering, implementing them. In particular, this analysis looks at layering,
freshness and the choice of symmetric vs. asymmetric cryptography. freshness, and the choice of symmetric vs. asymmetric cryptography.
8.1. Feasibility 8.1. Feasibility
The first question is whether using cryptographic security and The first question is whether using cryptographic security and
asymmetric cryptography in particular is feasible at all on resource- asymmetric cryptography in particular is feasible at all on resource-
constrained devices. The numbers above give a mixed message. constrained devices. The numbers above give a mixed message.
Clearly, an implementation of a significant cryptographic operation Clearly, an implementation of a significant cryptographic operation
such as public key signing can be done in surprisingly small amount such as public-key signing can be done in a surprisingly small amount
of code space. It could even be argued that our chosen prototype of code space. It could even be argued that our chosen prototype
platform was unnecessarily restrictive in the amount of code space it platform was unnecessarily restrictive in the amount of code space it
allows: we chose this platform on purpose to demonstrate something allows: we chose this platform on purpose to demonstrate something
that is as resource-constrained and difficult as possible. that is as resource constrained and difficult as possible.
A recent trend in microcontrollers is the introduction of 32-bit CPUs A recent trend in microcontrollers is the introduction of 32-bit CPUs
that are becoming cheaper and more easily available than 8-bit CPUs, that are becoming cheaper and more easily available than 8-bit CPUs,
in addition to being more easily programmable. The flash memory size in addition to being more easily programmable. The flash memory size
is probably easier to grow than other parameters in microcontrollers. is probably easier to grow than other parameters in microcontrollers.
Flash memory size is not expected to be the most significant limiting Flash memory size is not expected to be the most significant limiting
factor. Before picking a platform, developers should also plan for factor. Before picking a platform, developers should also plan for
firmware updates. This would essentially mean that the platform firmware updates. This would essentially mean that the platform
should at least have a flash memory size of the total code size * 2, should at least have a flash memory size of the total code size * 2,
plus some space for buffer. plus some space for buffer.
The situation is less clear with regards to the amount of CPU power The situation is less clear with regards to the amount of CPU power
needed to run the algorithms. The demonstrated speeds are sufficient needed to run the algorithms. The demonstrated speeds are sufficient
for many applications. For instance, a sensor that wakes up every for many applications. For instance, a sensor that wakes up every
now and then can likely spend a fraction of a second, or even spend now and then can likely spend a fraction of a second, or even spend
multiple seconds in some cases, for the computation of a signature multiple seconds in some cases, for the computation of a signature
for the message that it is about to send. Most applications that use for the message that it is about to send. Most applications that use
protocols such as DTLS that use public key cryptography only at the protocols such as DTLS that use public-key cryptography only at the
beginning of the session would also be fine with any of these beginning of the session would also be fine with any of these
execution times. execution times.
Yet, with reasonably long key sizes the execution times are in the Yet, with reasonably long key sizes, the execution times are in the
seconds, dozens of seconds, or even longer. For some applications seconds, dozens of seconds, or even longer. For some applications,
this is too long. Nevertheless, these algorithms can successfully be this is too long. Nevertheless, these algorithms can successfully be
employed in resource-constrained devices for the following reasons: employed in resource-constrained devices for the following reasons:
o With the right selection of algorithms and libraries, the o With the right selection of algorithms and libraries, the
execution times can actually be very small (less than 500 ms). execution times can actually be very small (less than 500 ms).
o As discussed in [wiman], in general the power requirements o As discussed in [wiman], in general, the power requirements
necessary to turn the radio on/off and sending or receiving necessary to turn the radio on/off and sending or receiving
messages are far bigger than those needed to execute cryptographic messages are far bigger than those needed to execute cryptographic
operations. While there are newer radios that significantly lower operations. While there are newer radios that significantly lower
the energy consumption of sending and receiving messages, there is the energy consumption of sending and receiving messages, there is
no good reason to choose platforms that do not provide sufficient no good reason to choose platforms that do not provide sufficient
computing power to run the necessary cryptographic operations. computing power to run the necessary cryptographic operations.
o Commercial libraries and the use of full potential for various o Commercial libraries and the use of full potential for various
optimizations will provide a better result than what we arrived at optimizations will provide a better result than what we arrived at
in this memo. in this memo.
o Using public-key cryptography only at the beginning of a session o Using public-key cryptography only at the beginning of a session
will reduce the per-packet processing times significantly. will reduce the per-packet processing times significantly.
While we did not do an exhaustive performance evaluation of While we did not do an exhaustive performance evaluation of
asymmetric key pair generation on resource-constrained devices, we asymmetric key-pair generation on resource-constrained devices, we
did note that it is possible for such devices to generate a new key did note that it is possible for such devices to generate a new key
pair. Given that this operation would only occur in rare pair. Given that this operation would only occur in rare
circumstances (such as a factory reset or ownership change) and its circumstances (such as a factory reset or ownership change) and its
potential privacy benefits, developers should provide mechanisms for potential privacy benefits, developers should provide mechanisms for
generating new identities. It is however extremely important to note generating new identities. However, it is extremely important to
that the security of this operation relies on access to note that the security of this operation relies on access to
cryptographic-quality randomness. cryptographic-quality randomness.
8.2. Freshness 8.2. Freshness
In our architecture, if implemented as described thus far, messages In our architecture, if implemented as described thus far, messages
along with their signatures sent from the sensors to the publish- along with their signatures sent from the sensors to the publish-
subscribe broker can be recorded and replayed by an eavesdropper. subscribe broker can be recorded and replayed by an eavesdropper.
The publish-subscribe broker has no mechanism to distinguish The publish-subscribe broker has no mechanism to distinguish
previously received packets from those that are retransmitted by the previously received packets from those that are retransmitted by the
sender or replayed by an eavesdropper. Therefore, it is essential sender or replayed by an eavesdropper. Therefore, it is essential
for the smart objects to ensure that data updates include a freshness for the smart objects to ensure that data updates include a freshness
indicator. However, ensuring freshness on constrained devices can be indicator. However, ensuring freshness on constrained devices can be
non-trivial because of several reasons which include: non-trivial because of several reasons, which include:
o Communication is mostly unidirectional to save energy. o Communication is mostly unidirectional to save energy.
o Internal clocks might not be accurate and may be reset several o Internal clocks might not be accurate and may be reset several
times during the operational phase of the smart object. times during the operational phase of the smart object.
o Network time synchronization protocols such as Network Time o Network time synchronization protocols such as the Network Time
Protocol (NTP) [RFC5905] are resource intensive and therefore may Protocol (NTP) [RFC5905] are resource intensive and therefore may
be undesirable in many smart object networks. be undesirable in many smart object networks.
There are several different methods that can be used in our There are several different methods that can be used in our
architecture for replay protection. The selection of the appropriate architecture for replay protection. The selection of the appropriate
choice depends on the actual deployment scenario. choice depends on the actual deployment scenario.
Including sequence numbers in signed messages can provide an Including sequence numbers in signed messages can provide an
effective method of replay protection. The publish-subscribe broker effective method of replay protection. The publish-subscribe broker
should verify the sequence number of each incoming message and accept should verify the sequence number of each incoming message and accept
it only if it is greater than the highest previously seen sequence it only if it is greater than the highest previously seen sequence
number. The publish-subscribe broker drops any packet with a number. The publish-subscribe broker drops any packet with a
sequence number that has already been received or if the received sequence number that has already been received or if the received
sequence number is greater than the highest previously seen sequence sequence number is greater than the highest previously seen sequence
number by an amount larger than the preset threshold. number by an amount larger than the preset threshold.
Sequence numbers can wrap around at their maximum value and, Sequence numbers can wrap around at their maximum value; therefore,
therefore, it is essential to ensure that sequence numbers are it is essential to ensure that sequence numbers are sufficiently
sufficiently long. However, including long sequence numbers in long. However, including long sequence numbers in packets can
packets can increase the network traffic originating from the sensor increase the network traffic originating from the sensor and can thus
and can thus decrease its energy efficiency. To overcome the problem decrease its energy efficiency. To overcome the problem of long
of long sequence numbers, we can use a scheme similar to that of sequence numbers, we can use a scheme similar to that of Huang
Huang [huang], where the sender and receiver maintain and sign long [huang], where the sender and receiver maintain and sign long
sequence numbers of equal bit-lengths but they transmit only the sequence numbers of equal bit lengths, but they transmit only the
least significant bits. least-significant bits.
It is important for the smart object to write the sequence number It is important for the smart object to write the sequence number
into the permanent flash memory after each increment and before it is into the permanent flash memory after each increment and before it is
included in the message to be transmitted. This ensures that the included in the message to be transmitted. This ensures that the
sensor can obtain the last sequence number it had intended to send in sensor can obtain the last sequence number it had intended to send in
case of a reset or a power failure. However, the sensor and the case of a reset or a power failure. However, the sensor and the
publish-subscribe broker can still end up in a discordant state where publish-subscribe broker can still end up in a discordant state where
the sequence number received by the publish-subscribe broker exceeds the sequence number received by the publish-subscribe broker exceeds
the expected sequence number by an amount greater than the preset the expected sequence number by an amount greater than the preset
threshold. This may happen because of a prolonged network outage or threshold. This may happen because of a prolonged network outage or
if the publish-subscribe broker experiences a power failure for some if the publish-subscribe broker experiences a power failure for some
reason. Therefore it is essential for sensors that normally send reason. Therefore, it is essential for sensors that normally send
Non-Confirmable data updates to send some Confirmable updates and re- Non-Confirmable data updates to send some Confirmable updates and
synchronize with the publish-subscribe broker if a reset message is resynchronize with the publish-subscribe broker if a reset message is
received. The sensors re-synchronize by sending a new registration received. The sensors resynchronize by sending a new registration
message with the current sequence number. message with the current sequence number.
Although sequence numbers protect the system from replay attacks, a Although sequence numbers protect the system from replay attacks, a
publish-subscribe broker has no mechanism to determine the time at publish-subscribe broker has no mechanism to determine the time at
which updates were created by the sensor. Moreover, if sequence which updates were created by the sensor. Moreover, if sequence
numbers are the only freshness indicator used, a malicious numbers are the only freshness indicator used, a malicious
eavesdropper can induce inordinate delays to the communication of eavesdropper can induce inordinate delays to the communication of
signed updates by buffering messages. It may be important in certain signed updates by buffering messages. It may be important in certain
smart object networks for sensors to send data updates which include smart object networks for sensors to send data updates that include
timestamps to allow the publish-subscribe broker to determine the timestamps to allow the publish-subscribe broker to determine the
time when the update was created. For example, when the publish- time when the update was created. For example, when the publish-
subscribe broker is collecting temperature data, it may be necessary subscribe broker is collecting temperature data, it may be necessary
to know when exactly the temperature measurement was made by the to know when exactly the temperature measurement was made by the
sensor. A simple solution to this problem is for the publish- sensor. A simple solution to this problem is for the publish-
subscribe broker to assume that the data object was created when it subscribe broker to assume that the data object was created when it
receives the update. In a relatively reliable network with low RTT, receives the update. In a relatively reliable network with low RTT,
it can be acceptable to make such an assumption. However most it can be acceptable to make such an assumption. However, most
networks are susceptible to packet loss and hostile attacks making networks are susceptible to packet loss and hostile attacks making
this assumption unsustainable. this assumption unsustainable.
Depending on the hardware used by the smart objects, they may have Depending on the hardware used by the smart objects, they may have
access to accurate hardware clocks which can be used to include access to accurate hardware clocks, which can be used to include
timestamps in the signed updates. These timestamps are included in timestamps in the signed updates. These timestamps are included in
addition to sequence numbers. The clock time in the smart objects addition to sequence numbers. The clock time in the smart objects
can be set by the manufacturer or the current time can be can be set by the manufacturer, or the current time can be
communicated by the publish-subscribe broker during the registration communicated by the publish-subscribe broker during the registration
phase. However, these approaches require the smart objects to either phase. However, these approaches require the smart objects to either
rely on the long-term accuracy of the clock set by the manufacturer rely on the long-term accuracy of the clock set by the manufacturer
or to trust the publish-subscribe broker thereby increasing the or trust the publish-subscribe broker thereby increasing the
potential vulnerability of the system. The smart objects could also potential vulnerability of the system. The smart objects could also
obtain the current time from NTP, but this may consume additional obtain the current time from NTP, but this may consume additional
energy and give rise to security issues discussed in [RFC5905]. The energy and give rise to security issues discussed in [RFC5905]. The
smart objects could also have access to a mobile network or the smart objects could also have access to a mobile network or the
Global Positioning System (GPS), and they can be used obtain the Global Positioning System (GPS), and they can be used obtain the
current time. Finally, if the sensors need to co-ordinate their current time. Finally, if the sensors need to coordinate their sleep
sleep cycles, or if the publish-subscribe broker computes an average cycles, or if the publish-subscribe broker computes an average or
or mean of updates collected from multiple smart objects, it is mean of updates collected from multiple smart objects, it is
important for the network nodes to synchronize the time among them. important for the network nodes to synchronize the time among them.
This can be done by using existing synchronization schemes. This can be done by using existing synchronization schemes.
8.3. Layering 8.3. Layering
It would be useful to select just one layer where security is It would be useful to select just one layer where security is
provided at. Otherwise a simple device needs to implement multiple provided at. Otherwise, a simple device needs to implement multiple
security mechanisms. While some code can probably be shared across security mechanisms. While some code can probably be shared across
such implementations (like algorithms), it is likely that most of the such implementations (like algorithms), it is likely that most of the
code involving the actual protocol machinery cannot. Looking at the code involving the actual protocol machinery cannot. Looking at the
different layers, here are the choices and their implications: different layers, here are the choices and their implications:
link layer link layer: This is probably the most common solution today. The
primary benefits of this choice of layer are that security
This is probably the most common solution today. The biggest services are commonly available (WLAN secrets, cellular SIM cards,
benefits of this choice of layer are that security services are etc.) and that their application protects the entire
commonly available (WLAN secrets, cellular SIM cards, etc.) and communications.
that their application protects the entire communications.
The main drawback is that there is no security beyond the first The main drawback is that there is no security beyond the first
hop. This can be problematic, e.g., in many devices that hop. This can be problematic, e.g., in many devices that
communicate to a server in the Internet. A Withings scale communicate to a server in the Internet. A smart home weighing
[Withings], for instance, can support WLAN security but without scale, for instance, can support WLAN security, but without some
some level of end-to-end security, it would be difficult to level of end-to-end security, it would be difficult to prevent
prevent fraudulent data submissions to the servers. fraudulent data submissions to the servers.
Another drawback is that some commonly implemented link layer Another drawback is that some commonly implemented link-layer
security designs use group secrets. This allows any device within security designs use group secrets. This allows any device within
the local network (e.g., an infected laptop) to attack the the local network (e.g., an infected laptop) to attack the
communications. communications.
network layer network layer: There are a number of solutions in this space and
many new ones and variations thereof being proposed: IPsec, PANA,
There are a number of solutions in this space, and many new ones and so on. In general, these solutions have similar
and variations thereof being proposed: IPsec, PANA, and so on. In characteristics to those in the transport layer: they work across
general, these solutions have similar characteristics to those in forwarding hops but only as far as to the next middlebox or
the transport layer: they work across forwarding hops but only as application entity. There is plenty of existing solutions and
far as to the next middlebox or application entity. There is designs.
plenty of existing solutions and designs.
Experience has shown that it is difficult to control IP layer Experience has shown that it is difficult to control IP-layer
entities from an application process. While this is theoretically entities from an application process. While this is theoretically
easy, in practice the necessary APIs do not exist. For instance, easy, in practice the necessary APIs do not exist. For instance,
most IPsec software has been built for the VPN use case, and is most IPsec software has been built for the VPN use case and is
difficult or impossible to tweak to be used on a per-application difficult or impossible to tweak to be used on a per-application
basis. As a result, the authors are not particularly enthusiastic basis. As a result, the authors are not particularly enthusiastic
about recommending these solutions. about recommending these solutions.
transport and application layer transport and application layer: This is another popular solution
along with link-layer designs. TLS with HTTP (HTTPS) and DTLS
This is another popular solution along with link layer designs. with CoAP are examples of solutions in this space and have been
TLS with HTTP (HTTPS) and DTLS with CoAP are examples of solutions proven to work well. These solutions are typically easy to take
in this space, and have been proven to work well. These solutions into use in an application, without assuming anything from the
are typically easy to take into use in an application, without underlying OS, and they are easy to control as needed by the
assuming anything from the underlying OS, and they are easy to applications. The main drawback is that generally speaking, these
control as needed by the applications. The main drawback is that solutions only run as far as the next application level entity.
generally speaking, these solutions only run as far as the next And even for this case, HTTPS can be made to work through proxies,
application level entity. And even for this case, HTTPS can be so this limit is not unsolvable. Another drawback is that attacks
made to work through proxies, so this limit is not unsolvable. on the link layer, network layer, and in some cases, transport
Another drawback is that attacks on link layer, network layer and layer, cannot be protected against. However, if the upper layers
in some cases, transport layer, can not be protected against. have been protected, such attacks can at most result in a denial
However, if the upper layers have been protected, such attacks can of service. Since denial of service can often be caused anyway,
at most result in a denial-of-service. Since denial-of-service it is not clear if this is a real drawback.
can often be caused anyway, it is not clear if this is a real
drawback.
data object layer data-object layer: This solution does not protect any of the
This solution does not protect any of the protocol layers, but protocol layers but protects individual data elements being sent.
protects individual data elements being sent. It works It works particularly well when there are multiple application-
particularly well when there are multiple application layer layer entities on the path of the data. Smart object networks are
entities on the path of the data. Smart object networks are
likely to employ such entities for storage, filtering, aggregation likely to employ such entities for storage, filtering, aggregation
and other reasons, and as such, an end-to-end solution is the only and other reasons, and as such, an end-to-end solution is the only
one that can protect the actual data. one that can protect the actual data.
The downside is that the lower layers are not protected. But The downside is that the lower layers are not protected. But
again, as long as the data is protected and checked upon every again, as long as the data is protected and checked upon every
time it passes through an application level entity, it is not time it passes through an application-level entity, it is not
clear that there are attacks beyond denial-of-service. clear that there are attacks beyond denial of service.
The main question mark is whether this type of a solution provides The main question mark is whether this type of a solution provides
sufficient advantages over the more commonly implemented transport sufficient advantages over the more commonly implemented transport
and application layer solutions. and application-layer solutions.
8.4. Symmetric vs. Asymmetric Crypto 8.4. Symmetric vs. Asymmetric Crypto
The second trade-off that is worth discussing is the use of plain The second trade-off that is worth discussing is the use of plain
asymmetric cryptographic mechanisms, plain symmetric cryptographic asymmetric cryptographic mechanisms, plain symmetric cryptographic
mechanisms, or some mixture thereof. mechanisms, or some mixture thereof.
Contrary to popular cryptographic community beliefs, a symmetric Contrary to popular cryptographic community beliefs, a symmetric
cryptographic solution can be deployed in large scale. In fact, one cryptographic solution can be deployed in large scale. In fact, one
of the largest deployment of cryptographic security, the cellular of the largest deployments of cryptographic security, the cellular
network authentication system, uses SIM cards that are based on network authentication system, uses Subscriber Identification Module
symmetric secrets. In contrast, public key systems have yet to show (SIM) cards that are based on symmetric secrets. In contrast,
ability to scale to hundreds of millions of devices, let alone public-key systems have yet to show an ability to scale to hundreds
billions. But the authors do not believe scaling is an important of millions of devices, let alone billions. But the authors do not
differentiator when comparing the solutions. believe scaling is an important differentiator when comparing the
solutions.
As can be seen from the Section 6, the time needed to calculate some As can be seen from Section 6, the time needed to calculate some of
of the asymmetric cryptographic operations with reasonable key the asymmetric cryptographic operations with reasonable key lengths
lengths can be significant. There are two contrary observations that can be significant. There are two contrary observations that can be
can be made from this. First, recent wisdom indicates that computing made from this. First, recent wisdom indicates that computing power
power on resource-constrained devices is far cheaper than on resource-constrained devices is far cheaper than transmission
transmission power [wiman], and keeps on becoming more efficient very power [wiman], and it keeps on becoming more efficient very quickly.
quickly. From this we can conclude that the sufficient CPU is or at From this we can conclude that the sufficient CPU is or at least will
least will be easily available. be easily available.
But the other observation is that when there are very costly But the other observation is that when there are very costly
asymmetric operations, doing a key exchange followed by the use of asymmetric operations, doing a key exchange followed by the use of
generated symmetric keys would make sense. This model works very generated symmetric keys would make sense. This model works very
well for DTLS and other transport layer solutions, but works less well for DTLS and other transport-layer solutions, but it works less
well for data object security, particularly when the number of well for data-object security, particularly when the number of
communicating entities is not exactly two. communicating entities is not exactly two.
9. Summary 9. Summary
This document makes several security recommendations based on our This document makes several security recommendations based on our
implementation experience. We summarize some of the important ones implementation experience. We summarize some of the important ones
here: here:
o Developers and product designers should choose the hardware after o Developers and product designers should choose the hardware after
determining the security requirements for their application determining the security requirements for their application
scenario. scenario.
o Elliptic Curve Cryptography (ECC) outperforms RSA based operations o ECC outperforms RSA-based operations; therefore, it is recommended
and therefore it is recommended for resource-constrained devices. for resource-constrained devices.
o Cryptographic-quality randomness is needed for many security o Cryptographic-quality randomness is needed for many security
protocols. Developers and vendors should ensure that the protocols. Developers and vendors should ensure that the
sufficient randomness is available for security critical tasks. sufficient randomness is available for security critical tasks.
o 32-bit microcontrollers are much more easily available, at lower o 32-bit microcontrollers are much more easily available, at lower
costs and are more power efficient. Therefore, real-world costs, and are more power efficient. Therefore, real-world
deployments are better off using 32-bit microcontrollers. deployments are better off using 32-bit microcontrollers.
o Developers should provide mechanisms for devices to generate new o Developers should provide mechanisms for devices to generate new
identities at appropriate times during their lifecycle. For identities at appropriate times during their life cycle, for
example, after a factory reset or an ownership handover. example, after a factory reset or an ownership handover.
o Planning for firmware updates is important. The hardware platform o Planning for firmware updates is important. The hardware platform
chosen should at least have a flash memory size of the total code chosen should at least have a flash memory size of the total code
size * 2, plus some space for buffer. size * 2, plus some space for buffer.
10. Security Considerations 10. Security Considerations
This entire memo deals with security issues. This entire memo deals with security issues.
11. IANA Considerations 11. IANA Considerations
There are no IANA impacts in this memo. This document has no IANA actions.
12. Informative references 12. Informative References
[arduino-uno] [arduino-uno]
Arduino, "Arduino Uno", September 2015, Arduino, "Arduino Uno REV3",
<http://arduino.cc/en/Main/arduinoBoardUno>. <http://arduino.cc/en/Main/arduinoBoardUno>.
[armecdsa] [armecdsa] Tschofenig, H. and M. Pegourie-Gonnard, "Performance
Tschofenig, H. and M. Pegourie-Gonnard, "Performance
Investigations", March 2015, Investigations", March 2015,
<https://www.ietf.org/proceedings/92/slides/ <https://www.ietf.org/proceedings/92/slides/
slides-92-lwig-3.pdf>. slides-92-lwig-3.pdf>.
[avr-crypto-lib] [avr-crypto-lib]
AVR-CRYPTO-LIB, "AVR-CRYPTO-LIB", September 2015, Das Labor, "AVR-Crypto-Lib", February 2014,
<http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>. <http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>.
[avr-cryptolib] [avr-cryptolib]
Van der Laan, E., "AVR CRYPTOLIB", September 2015, "AVRCryptoLib", <http://www.emsign.nl/>.
<http://www.emsign.nl/>.
[avrora] Titzer, Ben., "Avrora", September 2015, [avrora] Avora, "The AVR Simulation and Analysis Framework",
<http://compilers.cs.ucla.edu/avrora/>. <http://compilers.cs.ucla.edu/avrora/>.
[freescale] [CoAP-BROKER]
NXP, "Freescale FRDM-KL25Z", June 2017, Koster, M., Keranen, A., and J. Jimenez, "Publish-
<https://developer.mbed.org/platforms/KL25Z/>. Subscribe Broker for the Constrained Application Protocol
(CoAP)", Work in Progress, draft-ietf-core-coap-pubsub-04,
[hahmos] Hahm, O., Baccelli, E., Petersen, H., and N. Tsiftes, March 2018.
"Operating systems for low-end devices in the internet of
things: a survey", IEEE Internet of Things Journal , 2016.
[huang] Huang, C., "Low-overhead freshness transmission in sensor
networks", 2008.
[I-D.arkko-core-security-arch] [CoAP-SECURITY]
Arkko, J. and A. Keranen, "CoAP Security Architecture", Arkko, J. and A. Keranen, "CoAP Security Architecture",
draft-arkko-core-security-arch-00 (work in progress), July Work n Progress, draft-arkko-core-security-arch-00, July
2011. 2011.
[I-D.arkko-core-sleepy-sensors] [CoAP-SENSORS]
Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- Novo, "Implementing Tiny COAP Sensors", Wok in Progress,
sleepy-sensors-01 (work in progress), July 2011. draft-arkko-core-sleepy-sensors-01, July 2011.
[I-D.daniel-6lowpan-security-analysis]
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.
[I-D.ietf-core-coap-pubsub] [CoRE-RD] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Koster, M., Keranen, A., and J. Jimenez, "Publish- Amsuess, "CoRE Resource Directory", Work in Progress,
Subscribe Broker for the Constrained Application Protocol draft-ietf-core-resource-directory-13, March 2018.
(CoAP)", draft-ietf-core-coap-pubsub-03 (work in
progress), February 2018.
[I-D.ietf-core-resource-directory] [freescale]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. ARM Mbed, "FRDM-KL25Z",
Amsuess, "CoRE Resource Directory", draft-ietf-core- <https://developer.mbed.org/platforms/KL25Z/>.
resource-directory-12 (work in progress), October 2017.
[I-D.ietf-core-senml] [hahmos] Hahm, O., Baccelli, E., Petersen, H., and N. Tsiftes,
Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. "Operating systems for low-end devices in the internet of
Bormann, "Media Types for Sensor Measurement Lists things: a survey", IEEE Internet of Things Journal,
(SenML)", draft-ietf-core-senml-12 (work in progress), Vol. 3, Issue 5, DOI 10.1109/JIOT.2015.2505901, October
December 2017. 2016.
[I-D.irtf-t2trg-iot-seccons] [HIP-DEX] Moskowitz, R., Ed. and R. Hummen, "HIP Diet EXchange
Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- (DEX)", Work in Progress, draft-ietf-hip-dex-06, December
the-Art and Challenges for the Internet of Things 2017.
Security", draft-irtf-t2trg-iot-seccons-11 (work in
progress), February 2018.
[I-D.moskowitz-hip-dex] [huang] Huang, C., "LOFT: Low-overhead freshness transmission in
Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", sensor networks", IEEE, DOI 10.1109/SUTC.2008.38, June
draft-moskowitz-hip-dex-05 (work in progress), January 2008.
2016.
[I-D.sarikaya-t2trg-sbootstrapping] [IoT-BOOTSTRAPPING]
Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT
Bootstrapping: A Survey", draft-sarikaya-t2trg- Bootstrapping: A Survey", Work in Progress,
sbootstrapping-03 (work in progress), February 2017. draft-sarikaya-t2trg-sbootstrapping-03, February 2017.
[IoT-SECURITY]
Garcia-Morchon, O., Kumar, S., and M. Sethi,
"State-of-the-Art and Challenges for the Internet of
Things Security", Work in Progress,
draft-irtf-t2trg-iot-seccons-14, April 2018.
[IPV6-LOWPAN-SEC]
Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J.
Laganier, "IPv6 over Low Power WPAN Security Analysis",
Work in Progress, draft-daniel-6lowpan-security-
analysis-05, March 2011.
[matrix-ssl] [matrix-ssl]
PeerSec Networks, "Matrix SSL", September 2015, Inside Secure, "GUARD TLS Toolkit (formerly Matrix SSL)",
<http://www.matrixssl.org/>. <http://www.matrixssl.org/>.
[mbed] ARM, "mbed TLS", May 2017, [mbed] ARM Mbed, "Mbed TLS",
<https://www.mbed.com/en/technologies/security/mbed-tls/>. <https://www.mbed.com/en/technologies/security/mbed-tls/>.
[micronacl] [micronacl]
MicroNaCl, "The Networking and Cryptography library for MicroNaCl, "The Networking and Cryptography library for
microcontrollers", <http://munacl.cryptojedi.org/>. microcontrollers", <http://munacl.cryptojedi.org/>.
[mosdorf] Mosdorf, M. and W. Zabolotny, "Implementation of elliptic [mosdorf] Mosdorf, M. and W. Zabolotny, "Implementation of elliptic
curve cryptography for 8 bit and 32 bit embedded systems curve cryptography for 8-bit and 32-bit embedded systems -
time efficiency and power consumption analysis", Pomiary time efficiency and power consumption analysis", Pomiary
Automatyka Kontrola , 2010. Automatyka Kontrola, 2010.
[MT-SenML] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Sensor Measurement Lists (SenML)", Work in
Progress, draft-ietf-core-senml-15, May 2018.
[nacl] NaCl, "Networking and Cryptography library", [nacl] NaCl, "Networking and Cryptography library",
<http://nacl.cr.yp.to/>. <http://nacl.cr.yp.to/>.
[naclavr] Hutter, M. and P. Schwabe, "NaCl on 8-Bit AVR [naclavr] Hutter, M. and P. Schwabe, "NaCl on 8-Bit AVR
Microcontrollers", International Conference on Cryptology Microcontrollers", International Conference on
in Africa , Springer Berlin Heidelberg , 2013. Cryptology in Africa, Computer Science, Vol. 7918, pp.
156-172, February 2013,
<https://doi.org/10.1007/978-3-642-38553-7_9>.
[nesC] Gay, D., Levis, P., von Behren, R., Welsh, M., Brewer, E., [nesC] Gay, D., Levis, P., von Behren, R., Welsh, M., Brewer, E.,
and D. Culler, "The nesC language: A holistic approach to and D. Culler, "The nesC language: A holistic approach to
networked embedded systems", ACM SIGPLAN Notices , 2014. networked embedded systems", ACM SIGPLAN Notices, Vol. 38,
Issue 5, DOI 10.1145/781131.781133, 2003.
[nordic] Nordic Semiconductor, "nRF52832 Product Specification", [nordic] Nordic Semiconductor, "nRF52832 Product Specification
June 2017, <http://infocenter.nordicsemi.com/pdf/ v1.3", March 2017, <http://infocenter.nordicsemi.com/pdf/
nRF52832_PS_v1.3.pdf>. nRF52832_PS_v1.3.pdf>.
[relic-toolkit] [relic-toolkit]
Aranha, D. and C. Gouv, "Relic Toolkit", September 2015, "relic", March 2017,
<http://code.google.com/p/relic-toolkit/>. <https://github.com/relic-toolkit/relic>.
[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>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>. <https://www.rfc-editor.org/info/rfc3972>.
skipping to change at page 32, line 19 skipping to change at page 32, line 23
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[rsa-8bit] [rsa-8bit] Gura, N., Patel, A., Wander, A., Eberle, H., and S.
Gura, N., Patel, A., Wander, A., Eberle, H., and S.
Shantz, "Comparing Elliptic Curve Cryptography and RSA on Shantz, "Comparing Elliptic Curve Cryptography and RSA on
8-bit CPUs", 2010. 8-bit CPUs", DOI 10.1007/978-3-540-28632-5_9, 2004.
[rsa-high-speed] [rsa-high-speed]
Koc, C., "High-Speed RSA Implementation", November 1994, Koc, C., "High-Speed RSA Implementation", November 1994,
<http://cs.ucsb.edu/~koc/docs/r01.pdf>. <http://storage.jak-stik.ac.id/rsasecurity/tr201.pdf>.
[sec2ecc] Certicom Research, "SEC 2: Recommended Elliptic Curve [sec2ecc] Certicom Research, "SEC 2: Recommended Elliptic Curve
Domain Parameters", 2000. Domain Parameters", Version 2.0, January 2010.
[stnucleo] [stnucleo] STMicroelectronics, "NUCLEO-F091RC",
STMicroelectronics, "NUCLEO-F091RC", June 2017,
<http://www.st.com/en/evaluation-tools/ <http://www.st.com/en/evaluation-tools/
nucleo-f091rc.html/>. nucleo-f091rc.html/>.
[tinyecc] North Carolina State University and North Carolina State [tinyecc] Liu, A. and P. Nig, "TinyECC: A Configurable Library for
University, "TinyECC", 2008, Elliptic Curve Cryptography in Wireless Sensor Networks
<http://discovery.csc.ncsu.edu/software/TinyECC/>. (Version 2.0)", NCSU College of Engineering, February
2011, <http://discovery.csc.ncsu.edu/software/TinyECC/>.
[wiman] Margi, C., Oliveira, B., Sousa, G., Simplicio, M., Paulo, [wiman] Margi, C., Oliveira, B., Sousa, G., Simplicio, M., Paulo,
S., Carvalho, T., Naslund, M., and R. Gold, "Impact of S., Carvalho, T., Naslund, M., and R. Gold, "Impact of
Operating Systems on Wireless Sensor Networks (Security) Operating Systems on Wireless Sensor Networks (Security)
Applications and Testbeds", International Conference on Applications and Testbeds", Proceedings of the 19th
Computer Communication Networks (ICCCN'2010) / IEEE International Conference on Computer Communciations and
International Workshop on Wireless Mesh and Ad Hoc Networks, DOI 10.1109/ICCCN.2010.5560028, 2010.
Networks (WiMAN 2010) , 2010.
[wiselib] Baumgartner, T., Chatzigiannakis, I., Fekete, S., Koninis,
C., Kroller, A., and A. Pyrgelis, "Wiselib", 2010,
<www.wiselib.org/>.
[Withings] [wiselib] "wiselib", February 2015,
Withings, "The Withings scale", February 2012, <https://github.com/ibr-alg/wiselib>.
<http://www.withings.com/en/bodyscale>.
Appendix A. Acknowledgments Acknowledgments
The authors would like to thank Mats Naslund, Salvatore Loreto, Bob The authors would like to thank Mats Naslund, Salvatore Loreto, Bob
Moskowitz, Oscar Novo, Vlasios Tsiatsis, Daoyuan Li, Muhammad Waqas, Moskowitz, Oscar Novo, Vlasios Tsiatsis, Daoyuan Li, Muhammad Waqas,
Eric Rescorla and Tero Kivinen for interesting discussions in this Eric Rescorla, and Tero Kivinen for interesting discussions in this
problem space. The authors would also like to thank Diego Aranha for problem space. The authors would also like to thank Diego Aranha for
helping with the relic-toolkit configurations and Tobias Baumgartner helping with the relic-toolkit configurations and Tobias Baumgartner
for helping with questions regarding wiselib. for helping with questions regarding wiselib.
Tim Chown, Samita Chakrabarti, Christian Huitema, Dan Romascanu, Eric Tim Chown, Samita Chakrabarti, Christian Huitema, Dan Romascanu, Eric
Vyncke, and Emmanuel Baccelli provided valuable comments that helped Vyncke, and Emmanuel Baccelli provided valuable comments that helped
us improve the final version of this document. us improve this document.
Authors' Addresses Authors' Addresses
Mohit Sethi Mohit Sethi
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: mohit@piuha.net Email: mohit@piuha.net
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Ari Keranen Ari Keranen
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: ari.keranen@ericsson.com Email: ari.keranen@ericsson.com
Heidi-Maria Back Heidi-Maria Back
Nokia Nokia
Helsinki 00181 Helsinki 00181
Finland Finland
EMail: heidi.back@nokia.com Email: heidi.back@nokia.com
 End of changes. 212 change blocks. 
615 lines changed or deleted 583 lines changed or added

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