draft-ietf-lwig-crypto-sensors-05.txt   draft-ietf-lwig-crypto-sensors-06.txt 
Light-Weight Implementation Guidance M. Sethi Light-Weight Implementation Guidance M. Sethi
Internet-Draft J. Arkko Internet-Draft J. Arkko
Intended status: Informational A. Keranen Intended status: Informational A. Keranen
Expires: June 27, 2018 Ericsson Expires: August 30, 2018 Ericsson
H. Back H. Back
Comptel Nokia
December 24, 2017 February 26, 2018
Practical Considerations and Implementation Experiences in Securing Practical Considerations and Implementation Experiences in Securing
Smart Object Networks Smart Object Networks
draft-ietf-lwig-crypto-sensors-05 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
small devices and presents some preliminary experiences with those resource-constrained devices and presents some preliminary
libraries for message signing on small devices. Lastly, the memo experiences with those libraries for message signing on resource-
discusses trade-offs involving different types of security constrained devices. Lastly, the memo discusses trade-offs involving
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 27, 2018. This Internet-Draft will expire on August 30, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . 11
7. Example Application . . . . . . . . . . . . . . . . . . . . . 18 7. Example Application . . . . . . . . . . . . . . . . . . . . . 18
8. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 20 8. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Feasibility . . . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . 25 8.4. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . 26
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . 33 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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 deployment model that the authors are Section 4 discusses a potential deployment model for constrained
considering for constrained environments. The model requires minimal environments. The model requires minimal amount of configuration,
amount of configuration, and we believe it is a natural fit with the and we believe it is a natural fit with the typical communication
typical communication practices in smart object networking practices in smart object networking environments.
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
small devices using those libraries, including information about resource-constrained devices using those libraries, including
achievable code sizes and speeds on typical hardware. information about achievable code sizes and speeds on typical
hardware.
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 Constrained Application Protocol (CoAP) [RFC7252] is a light-weight
protocol designed to be used in machine-to-machine applications such protocol designed to be used in machine-to-machine applications such
as smart energy and building automation. Our discussion uses this as smart energy and building automation. Our discussion uses this
protocol as an example, but the conclusions may apply to other protocol as an example, but the conclusions may apply to other
similar protocols. CoAP base specification [RFC7252] outlines how to similar protocols. The CoAP base specification [RFC7252] outlines
use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol. how to use DTLS [RFC6347] and IPsec [RFC4303] for securing the
DTLS can be applied with pairwise shared keys, raw public keys or protocol. DTLS can be applied with pairwise shared keys, raw public
with certificates. The security model in all cases is mutual keys or with certificates. The security model in all cases is mutual
authentication, so while there is some commonality to HTTP [RFC7230] authentication, so while there is some commonality to HTTP [RFC7230]
in verifying the server identity, in practice the models are quite in verifying the server identity, in practice the models are quite
different. The use of IPsec with CoAP is described with regards to different. The use of IPsec with CoAP is described with regards to
the protocol requirements, noting that small implementations of IKEv2 the protocol requirements, noting that lightweight implementations of
exist [RFC7815]. However, the CoAP specification is silent on policy IKEv2 exist [RFC7815]. However, the CoAP specification is silent on
and other aspects that are normally necessary in order to implement policy and other aspects that are normally necessary in order to
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 [I-D.irtf-t2trg-iot-seccons] documents the different stages in the
lifecycle of a smart object. Next, it highlights the security lifecycle of a smart object. Next, it highlights the security
threats for smart objects and the challenges that one might face to threats for smart objects and the challenges that one might face to
protect against these threats. The document also looks at various protect against these threats. The document also looks at various
security protocols available, including IKEv2/IPsec [RFC7296], TLS/ security protocols available, including IKEv2/IPsec [RFC7296], TLS/
SSL [RFC5246], DTLS [RFC6347], HIP [RFC7401], SSL [RFC5246], DTLS [RFC6347], HIP [RFC7401],
[I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP [RFC3748]. Lastly, [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP [RFC3748]. Lastly,
[I-D.sarikaya-t2trg-sbootstrapping] discusses bootstrapping [I-D.sarikaya-t2trg-sbootstrapping] discusses bootstrapping
mechanisms available for resource-constrained IoT devices. mechanisms available for resource-constrained 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 is needed in developing suitable credential additional work should be undertaken in developing suitable
management mechanisms (perhaps something similar to the Bluetooth credential management mechanisms (perhaps something similar to the
pairing mechanism), understanding the implementability of standard Bluetooth pairing mechanism), understanding the implementability of
security mechanisms in small devices, and additional research in the standard security mechanisms in resource-constrained devices, and
area of lightweight cryptographic primitives. additional research in the area of lightweight cryptographic
primitives.
[I-D.moskowitz-hip-dex] defines a light-weight version of the HIP [I-D.moskowitz-hip-dex] defines a light-weight version of the HIP
protocol for low-power nodes. This version uses a fixed set of protocol for low-power nodes. This version uses a fixed set of
algorithms, Elliptic Curve Cryptography (ECC), and eliminates hash algorithms, Elliptic Curve Cryptography (ECC), and eliminates hash
functions. The protocol still operates based on host identities, and functions. The protocol still operates based on host identities, and
runs end-to-end between hosts, protecting all IP layer runs end-to-end between hosts, protecting all IP layer
communications. [RFC6078] describes an extension of HIP that can be communications. [RFC6078] describes an extension of HIP that can be
used to send upper layer protocol messages without running the usual used to send upper layer protocol messages without running the usual
HIP base exchange at all. HIP base exchange at all.
skipping to change at page 4, line 24 skipping to change at page 4, line 25
implementation in these environments. 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, 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 small, battery-operated, and inexpensive devices drives the to build resource-constrained, battery-operated, and inexpensive
creation of devices with a limited protocol and application suite. devices drives the creation of devices with a limited protocol and
Some of the typical limitations include running CoAP instead of HTTP, application suite. Some of the typical limitations include running
limited support for security mechanisms, limited processing power for CoAP instead of HTTP, limited support for security mechanisms,
long key lengths, sleep schedule that does not allow communication at limited processing power for long key lengths, sleep schedule that
all times, and so on. In addition, the devices typically have very does not allow communication at all times, and so on. In addition,
limited support for configuration, making it hard to set up secrets the devices typically have very limited support for configuration,
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
skipping to change at page 5, line 7 skipping to change at page 5, line 10
the only consideration in the design and development. the only consideration in the design and development.
Interoperability is also important, and often other parts of the Interoperability is also important, and often other parts of the
system, such as key management protocols or certificate formats are system, such as key management protocols or certificate formats are
heavier to implement than the algorithms themselves. heavier to implement 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
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 Small devices have no natural user interface for configuration o Resource-constrained devices have no natural user interface for
that would be required for the installation of shared secrets and configuration that would be required for the installation of
other security-related parameters. Typically, there is no shared secrets and other security-related parameters. Typically,
keyboard, no display, and there may not even be buttons to press. there is no keyboard, no display, and there may not even be
Some devices may only have one interface, the interface to the buttons to press. Some devices may only have one interface, the
network. interface 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.
Provisioning methods that rely on specific link-layer features may Provisioning methods that rely on specific link-layer features may
not work with other radio technologies in a heterogeneous network. not work with other radio technologies in a heterogeneous network.
o Network configurations evolve over the lifetime of the devices, as o Network configurations evolve over the lifetime of the devices, as
additional devices are introduced or addresses change. Various additional devices are introduced or addresses change. Various
central nodes may also receive more frequent updates than central nodes may also receive more frequent updates than
individual devices such as sensors embedded in building materials. individual devices such as sensors embedded in building materials.
In light of the above challenges, small resource-constrained devices In light of the above challenges, resource-constrained devices are
are often shipped with a single static identity. In many cases, it often shipped with a single static identity. In many cases, it is a
is a single raw public key. These long-term static identities makes single raw public key. These long-term static identities makes it
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 [I-D.arkko-core-sleepy-sensors] and end-to-end
security for IP or transport layers may not fit such communication security for IP or transport layers may not fit such communication
models very well. The primary reasons for needing middleboxes models very well. The primary reasons for needing middleboxes
relates to the need to accommodate for sleeping nodes as well to relates to the need to accommodate for sleeping nodes as well to
skipping to change at page 7, line 5 skipping to change at page 7, line 5
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, but 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 either a separate user interface,
local connection (such as USB), or using the network interface of the local connection (such as USB), or using 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 a identity value needs to be fed in (not both an identity and
certificate. Not 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 peers know the expected cryptographic identity of the other Once both the parties interested in communicating know the expected
peer off-line, secure communications can commence. Alternatively, cryptographic identity of the other off-line, secure communications
various pairing schemes can be employed. Note that these schemes can can commence. Alternatively, various pairing schemes can be
benefit from the already secure identifiers on the device side. For employed. Note that these schemes can benefit from the already
instance, the server can send a pairing message to each device after secure identifiers on the device side. For instance, the server can
their initial power-on and before they have been paired with anyone, send a pairing message to each device after their initial power-on
encrypted with the public key of the device. As with all pairing and before they have been paired with anyone, encrypted with the
schemes that do not employ a shared secret or the secure identity of public key of the device. As with all pairing schemes that do not
both parties, there are some remaining vulnerabilities that may or employ a shared secret or the secure identity of both parties, there
may not be acceptable for the application in question. For example, are some remaining vulnerabilities that may or may not be acceptable
leap-of-faith or trust-on-first-use based pairing methods assume that for the application in question. For example, many leap-of-faith or
the attacker is not present during the initial setup and are trust-on-first-use based pairing methods assume that the attacker is
vulnerable to eavesdropping or man-in-the-middle (MitM) attacks. not present during the initial setup. Therefore, they 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, not 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. The authors have employed a simple but arranged in a number of ways. One simple but not completely secure
not completely secure method where the last few digits of the method where the last few digits of the identity are printed on a
identity are printed on a tiny device just a few millimeters across. tiny device just a few millimeters across. Alternatively, the
Alternatively, the packaging for the device may include the full packaging for the device may include the full identity (typically 32
identity (typically 32 hex digits), retrieved from the device at hex digits), retrieved from the device at manufacturing time. This
manufacturing time. This identity can be read, for instance, by a identity can be read, for instance, by a bar code reader carried by
bar code reader carried by the installation personnel. (Note that the installation personnel. (Note that the identities are not
the identities are not secret, the security of the system is not secret, the security of the system is not dependent on the identity
dependent on the identity information leaking to others. The real information leaking to others. The real owner of an identity can
owner of an identity can always prove its ownership with the private always prove its ownership with the private key which never leaves
key which never leaves the device.) Finally, the device may use its the device.) Finally, the device may use its wired network interface
wired network interface or proximity-based communications, such as or proximity-based communications, such as Near-Field Communications
Near-Field Communications (NFC) or Radio-Frequency Identity tags (NFC) or Radio-Frequency Identity tags (RFIDs). Such interfaces
(RFIDs). Such interfaces allow secure communication of the device allow secure communication of the device identity to an information
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
skipping to change at page 8, line 28 skipping to change at page 8, line 30
no additional configuration effort from provisioning security. no additional configuration effort from 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 lifecycle. For example, 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 IPv6 addresses) provisioning stage. Temporary identities (such as dynamic IPv6
can be used for network communication protocols once the device is addresses) can be used for network communication protocols once the
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, and Potherdevi are the public keys of
other devices in the group. Now, we can define the secure identity other devices in the group, n is all the devices in the group except
of the group (Igrp) as a hash of all the public keys of the devices the device with Pdev as its public key, and m is the total number of
in the group (Pdevi). 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 (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 can not claim to be in the group, because the
group identity would change if any new keys were added to Igrp. group identity would change if any new keys were added to the
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 at what protocol layer
skipping to change at page 9, line 47 skipping to change at page 10, line 5
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 either, it is not the typical arrangement either. 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 Arduino Uno board [arduino-uno] as the test
platform. Arduino Uno has an ATmega328 microcontroller, an 8-bit platform. Arduino Uno has an ATmega328 microcontroller, an 8-bit
processor with a clock speed of 16 MHz, 2 kB of RAM, and 32 kB of processor with a clock speed of 16 MHz, 2 kB of RAM, and 32 kB of
flash memory. Our choice of a 8-bit platform may seem surprising flash memory. Our choice of a 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 smallest platforms available. It is public-key cryptography on the most resource-constrained platforms
reasonable to expect better performance results from 32-bit available. It is reasonable to expect better performance results
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 a variety of o AvrCryptolib [avr-cryptolib]: This library provides symmetric key
different symmetric key algorithms such as AES, triple DES and algorithms such as AES. It provides RSA as an asymmetric key
SkipJack. It provides RSA as an asymmetric key algorithm. Parts algorithm. Parts of the library were written in AVR-8 bit
of the library were written in AVR-8 bit assembly language to assembly language to reduce the size and optimize the performance.
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-Schacham, Boneh-Boyen short signatures.
and many more. The toolkit provides an option to build only the The library has also added support for curve25519 (for elliptic
desired components for the required platform. curve Diffie-Hellman key exchange) [RFC7748] and edwards25519 (for
elliptic curve digital signatures) [RFC8032]. The toolkit
provides an option to build only the desired 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 nesC programming language and as such is designed for specific in the nesC programming language [nesC] and as such is designed
use on TinyOS. However, the library can be ported to standard C for specific use on TinyOS. However, the library can be ported to
either with tool-chains or manually rewriting parts of the code. standard C either with tool-chains or manually rewriting parts of
It also has one of the smallest memory footprints among the set of the code. It also has one of the smallest memory footprints among
elliptic curve libraries surveyed so far. 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 many more algorithms including algorithms for
cryptography, localization, topology management and many more. cryptography, localization, topology management and many more.
The library was designed with the idea of making it easy to The library was designed with the idea of making it easy to
interface the library with operating systems like iSense and interface the library with operating systems like iSense and
Contiki. However, since the library is written entirely in C++ Contiki. However, since the library is written entirely in C++
with a template based model similar to Boost/CGAL, it can be used with a template based model similar to Boost/CGAL, it can be used
on any platform directly without using any of the operating system on any platform directly without using any of the operating system
interfaces provided. This approach was taken by the authors to interfaces provided. This approach was taken to test the code on
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.
o ARM mbed OS [mbed]: The ARM mbed operating system provides various
cryptographic primitives that are necessary for SSL/TLS protocol
implementation as well as X509 certificate handling. The library
provides an intuitive API for developer with a minimal code
footprint. It is intended for various ARM platforms such as ARM
Cortex M0, ARM Cortex M0+ and ARM Cortex M3.
This is by no ways an exhaustive list and there exist other This is by no ways an exhaustive list and there exist other
cryptographic libraries targeting resource-constrained devices. cryptographic libraries targeting resource-constrained devices.
There are also a number of operating systems that are specifically
targeted for resource-constrained devices. These operating systems
may included libraries and code for security. Hahm et al.[hahmos]
conduct a survey of such operating systems. The ARM mbed OS [mbed]
is one such operating system that provides various cryptographic
primitives that are necessary for SSL/TLS protocol implementation as
well as X509 certificate handling. The library provides an API for
developer with a minimal code footprint. It is intended for various
ARM platforms such as ARM Cortex M0, ARM Cortex M0+ and ARM Cortex
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 | 1,280 | | 2048 | 1587567 | 1280 |
+--------------+------------------------+---------------------------+ +--------------+------------------------+---------------------------+
RSA private key operation performance RSA private key operation performance
Table 1 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 more
RAM, we believe that 2048-bit operations can be performed in much RAM, we believe that 2048-bit operations can be performed in much
less time as has been shown in [rsa-8bit]. 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 ECDSA signature algorithm on TinyECC into C99 standard and running the Elliptic Curve Digital
the Arduino Uno board. TinyECC supports a variety of SEC 2 Signature Algorithm (ECDSA) on the Arduino Uno board. TinyECC
recommended Elliptic Curve domain parameters. The execution time and supports a variety of SEC 2 recommended Elliptic Curve domain
memory footprint are shown next to each of the curve parameters. parameters [sec2ecc]. The execution time and memory footprint are
These results were obtained by turning on all the optimizations and shown next to each of the curve parameters. These results were
using assembly code where available. It is clearly observable that obtained by turning on all the optimizations and using assembly code
where available.
The results from the performance evaluation of ECDSA in the following
tables also contains a column stating the approximate comparable RSA
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 |
skipping to change at page 13, line 32 skipping to change at page 14, line 4
Performance of ECDSA sign operation with TinyECC (No assembly Performance of ECDSA sign operation with TinyECC (No assembly
optimizations) optimizations)
Table 3 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 2
Elliptic curves, but it is easy to change the domain parameters and Elliptic curves, but it is easy to change the domain parameters and
obtain results for 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 Performance ECDSA sign operation with Wiselib
Table 4 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. We decided to use the Arduino Mega which has the it on Arduino Uno. Arduino Mega has the same 8-bit architecture like
same 8-bit architecture like the Arduino Uno but has a much larger the Arduino Uno but has a much larger RAM/ROM. We used Arduino Mega
RAM/ROM for testing relic-toolkit. Again, it is important to mention for experimenting with the relic-toolkit. Again, it is important to
that we used Arduino as it is a convenient prototyping platform. Our mention that we used Arduino as it is a convenient prototyping
intention was to demonstrate the feasibility of the entire platform. Our intention was to demonstrate the feasibility of the
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
skipping to change at page 14, line 42 skipping to change at page 15, line 12
set, the library was configured for low memory usage irrespective of set, the library was configured for low memory usage irrespective of
the execution time required by different curves. By turning on/off the execution time required by different curves. By turning on/off
optimizations included in the library, a trade-off between memory and optimizations included in the library, a trade-off between memory and
execution time between these values can be achieved. execution 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) | |
+-----------------+--------------+----------------+-----------------+ +-----------------+--------------+----------------+-----------------+
| NIST K163 | 261 | 2,804 | 1024 | | sect163k1 | 261 | 2804 | 1024 |
| (assembly math) | | | | | (assembly math) | | | |
| NIST K163 | 932 | 2750 | 1024 | | sect163k1 | 932 | 2750 | 1024 |
| NIST B163 | 2243 | 2444 | 1024 | | sect163r2 | 2243 | 2444 | 1024 |
| NIST K233 | 1736 | 3675 | 2048 | | sect233k1 | 1736 | 3675 | 2048 |
| NIST B233 | 4471 | 3261 | 2048 | | sect233r1 | 4471 | 3261 | 2048 |
+-----------------+--------------+----------------+-----------------+ +-----------------+--------------+----------------+-----------------+
Performance of ECDSA sign operation with relic-toolkit (Fast) Performance of ECDSA sign operation with relic-toolkit (Fast)
Table 5 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) | |
+-----------------+--------------+----------------+-----------------+ +-----------------+--------------+----------------+-----------------+
| NIST K163 | 592 | 2087 | 1024 | | sect163k1 | 592 | 2087 | 1024 |
| (assembly math) | | | | | (assembly math) | | | |
| NIST K163 | 2950 | 2215 | 1024 | | sect163k1 | 2950 | 2215 | 1024 |
| NIST B163 | 3213 | 2071 | 1024 | | sect163r2 | 3213 | 2071 | 1024 |
| NIST K233 | 6450 | 2935 | 2048 | | sect233k1 | 6450 | 2935 | 2048 |
| NIST B233 | 6100 | 2737 | 2048 | | sect233r1 | 6100 | 2737 | 2048 |
+-----------------+--------------+----------------+-----------------+ +-----------------+--------------+----------------+-----------------+
Performance of ECDSA sign operation with relic-toolkit (Low Memory) Performance of ECDSA sign operation with relic-toolkit (Low Memory)
Table 6 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 The Arduino board only provides pseudo random numbers with the o Some boards (e.g. Arduino Uno) do not provide a hardware random
random() function call. Real-world deployments must rely on a number generator. On such boards, obtaining cryptographic-quality
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.
skipping to change at page 16, line 19 skipping to change at page 16, line 34
| 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 Performance of ECDSA sign operation with ARM mbed TLS stack on
Freescale FRDM-KL25Z Freescale FRDM-KL25Z
Table 7 Table 7
The authors also measured the performance of curves on a ST Nucleo Tschofenig and Pegourie-Gonnard [armecdsa] also measured the
F091 (STM32F091RCT6) board [stnucleo] that has a ARM Cortex-M0 48MHz performance of curves on a ST Nucleo F091 (STM32F091RCT6) board
microcontroller with 256 kB of flash memory and 32kB of RAM. The [stnucleo] that has a ARM Cortex-M0 48MHz microcontroller with 256 kB
execution time for ECDSA sign operation with different curves is of flash memory and 32kB of RAM. The execution time for ECDSA sign
shown in Table 8. The sliding window technique for efficient operation with different curves is shown in Table 8. The sliding
exponentiation was used with a window size of 7. Fixed point window technique for efficient exponentiation was used with a window
optimization and NIST curve specific optimizations were used for size of 7. Fixed point optimization and NIST curve specific
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 ECDSA signature performance with ARM mbed TLS stack on ST Nucleo F091
(STM32F091RCT6) (STM32F091RCT6)
Table 8 Table 8
The authors also measured the RAM consumption by calculating the heap Finally, Tschofenig and Pegourie-Gonnard [armecdsa] also measured the
consumed for the cryptographic operations using a custom memory RAM consumption by calculating the heap consumed for the
allocation handler. The authors did not measure the minimal stack cryptographic operations using a custom memory allocation handler.
memory consumption. Depending on the curve and the different They did not measure the minimal stack memory consumption. Depending
optimizations enable or disabled, the memory consumption for the on the curve and the different optimizations enable or disabled, the
ECDSA sign operation varied from 1500 bytes to 15000 bytes. memory consumption for the ECDSA sign operation varied from 1500
bytes to 15000 bytes.
At the time of performing these measurements and study, it was At the time of performing these measurements and 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 now,
[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 signing of data using the curve Ed25519 from the NaCl
library needs only 23,216,241 cycles on the same microcontroller that library needs only 23216241 cycles on the same microcontroller that
we used for our evaluations (Arduino Mega ATmega2560). This we used for our evaluations (Arduino Mega ATmega2560). This
corresponds to about 14510 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
similar level of security (such as NIST B233, NIST K233), this similar level of security (such as NIST B233, NIST K233), this
implementation far outperforms all others. As such, it is recommend implementation far outperforms all others. As such, it is recommend
that the IETF community uses these curves for protocol specification that the IETF community uses these curves for protocol specification
and implementations. 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) |
skipping to change at page 18, line 16 skipping to change at page 18, line 43
document performance of ECDSA on similar resource-constrained document 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 crypto mechanisms, 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 be 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.
[I-D.arkko-core-sleepy-sensors] was an early multicast-based [I-D.arkko-core-sleepy-sensors] was an early multicast-based
approach. In the current application we have switched to using approach. In the current application we have switched to using
resource directories [I-D.ietf-core-resource-directory] and publish- resource directories [I-D.ietf-core-resource-directory] and publish-
subscribe brokers [I-D.ietf-core-coap-pubsub] instead. subscribe brokers [I-D.ietf-core-coap-pubsub] instead.
Architecturally, the idea is that sensors can delegate a part of Architecturally, the idea is that sensors can delegate a part of
their role to a node in the network. Such a network node could be their role to a node in the network. Such a network node could be
either a local resource or something in the Internet. In the case of either a local resource or something in the Internet. In the case of
skipping to change at page 19, line 45 skipping to change at page 20, line 23
demonstrates how it is possible to implement end-to-end security even demonstrates how it is possible to implement end-to-end security even
with the presence of assisting middleboxes. 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 proof-
of-concept prototype. In our prototype, the sensor was implemented of-concept prototype. In our prototype, the sensor was implemented
using the Arduino Ethernet shield over an Arduino Mega board. Our using the Arduino Ethernet shield over an Arduino Mega board. Our
implementation uses the standard C99 programming language on the implementation uses the standard C99 programming language on the
Arduino Mega board. In this prototype, the publish-subscribe broker Arduino Mega board. In this prototype, the publish-subscribe broker
and the Resource Directory (RD) reside on the same physical host. A and the Resource Directory (RD) reside on the same physical host. A
64-bit x86 linux machine serves as the broker and the RD, while a 64-bit x86 linux machine serves as the broker and the RD, while a
similar but physically different 64-bit x86 linux machine serves as similar but physically distinct 64-bit x86 linux machine serves as
the client that requests data from the sensor. We chose the Relic the client that requests data from the sensor. We chose the Relic
library version 0.3.1 for our sample prototype as it can be easily library version 0.3.1 for our sample prototype as it can be easily
compiled for different bit-length processors. Therefore, we were compiled for different bit-length processors. Therefore, we were
able to use it on the 8-bit processor of the Arduino Mega, as well as able to use it on the 8-bit processor of the Arduino Mega, as well as
on the 64-bit processor of the x86 client. We used ECDSA to sign and on the 64-bit processor of the x86 client. We used ECDSA to sign and
verify data updates with the standard NIST-K163 curve parameters. verify data updates with the standard NIST-K163 curve parameters.
While compiling Relic for our prototype, we used the fast While compiling Relic for our prototype, we used the fast
configuration without any assembly optimizations. 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 REST interfaces. We also
developed a minimalistic CoAP C-library for the Arduino sensor and developed a minimalistic CoAP C-library for the Arduino sensor and
for the client requesting data updates for a resource. The library for the client requesting data updates for a resource. The library
has small RAM requirements and uses stack-based allocation only. It has small RAM requirements and uses stack-based allocation only. It
is interoperable with the Java implementation of CoAP running on the is interoperable with the Java implementation of CoAP running on the
skipping to change at page 20, line 16 skipping to change at page 20, line 41
configuration without any assembly optimizations. 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 REST interfaces. We also
developed a minimalistic CoAP C-library for the Arduino sensor and developed a minimalistic CoAP C-library for the Arduino sensor and
for the client requesting data updates for a resource. The library for the client requesting data updates for a resource. The library
has small RAM requirements and uses stack-based allocation only. It has small RAM requirements and uses stack-based allocation only. It
is interoperable with the Java implementation of CoAP running on the is interoperable with the Java implementation of CoAP running on the
gateway. The location of the resource directory was configured into gateway. The location of the resource directory was configured into
the smart object sensor by hardcoding the IP address. the smart object sensor by hardcoding the IP address. A real
implementation based on this 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 which 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
skipping to change at page 20, line 42 skipping to change at page 21, line 20
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 small asymmetric cryptography in particular is feasible at all on resource-
devices. The numbers above give a mixed message. Clearly, an constrained devices. The numbers above give a mixed message.
implementation of a significant cryptographic operation such as Clearly, an implementation of a significant cryptographic operation
public key signing can be done in surprisingly small amount of code such as public key signing can be done in surprisingly small amount
space. It could even be argued that our chosen prototype platform of code space. It could even be argued that our chosen prototype
was unnecessarily restrictive in the amount of code space it allows: platform was unnecessarily restrictive in the amount of code space it
we chose this platform on purpose to demonstrate something that is as allows: we chose this platform on purpose to demonstrate something
small 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.
The authors do not expect the flash memory size to be the most Flash memory size is not expected to be the most significant limiting
significant limiting factor. Before picking a platform, developers factor. Before picking a platform, developers should also plan for
should also plan for firmware updates. This would essentially mean firmware updates. This would essentially mean that the platform
that the platform should at least have a flash memory size of the should at least have a flash memory size of the total code size * 2,
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 for the now and then can likely spend a fraction of a second, or even spend
computation of a signature for the message that it is about to send. multiple seconds in some cases, for the computation of a signature
Or even spend multiple seconds in some cases. Most applications that for the message that it is about to send. Most applications that use
use protocols such as DTLS that use public key cryptography only at protocols such as DTLS that use public key cryptography only at the
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, the authors believe that these this is too long. Nevertheless, these algorithms can successfully be
algorithms can successfully be employed in small devices for the employed in resource-constrained devices for the following reasons:
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
skipping to change at page 22, line 42 skipping to change at page 23, line 22
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 and,
therefore, it is essential to ensure that sequence numbers are therefore, it is essential to ensure that sequence numbers are
sufficiently long. However, including long sequence numbers in sufficiently long. However, including long sequence numbers in
packets can increase the network traffic originating from the sensor packets can increase the network traffic originating from the sensor
and can thus decrease its energy efficiency. To overcome the problem and can thus decrease its energy efficiency. To overcome the problem
of long sequence numbers, we can use a scheme similar to that of of long sequence numbers, we can use a scheme similar to that of
Huang [huang], where the sender and receiver maintain and sign long Huang [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
skipping to change at page 25, line 26 skipping to change at page 26, line 4
application level entity. And even for this case, HTTPS can be application level entity. And even for this case, HTTPS can be
made to work through proxies, so this limit is not unsolvable. made to work through proxies, so this limit is not unsolvable.
Another drawback is that attacks on link layer, network layer and Another drawback is that attacks on link layer, network layer and
in some cases, transport layer, can not be protected against. in some cases, transport layer, can not be protected against.
However, if the upper layers have been protected, such attacks can However, if the upper layers have been protected, such attacks can
at most result in a denial-of-service. Since denial-of-service at most result in a denial-of-service. Since denial-of-service
can often be caused anyway, it is not clear if this is a real can often be caused anyway, it is not clear if this is a real
drawback. drawback.
data object layer data object layer
This solution does not protect any of the protocol layers, but This solution does not protect any of the protocol layers, but
protects individual data elements being sent. It works protects individual data elements being sent. It works
particularly well when there are multiple application layer particularly well when there are multiple application layer
entities on the path of the data. The authors believe smart entities on the path of the data. Smart object networks are
object networks are likely to employ such entities for storage, likely to employ such entities for storage, filtering, aggregation
filtering, aggregation and other reasons, and as such, an end-to- and other reasons, and as such, an end-to-end solution is the only
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.
skipping to change at page 26, line 15 skipping to change at page 26, line 40
network authentication system, uses SIM cards that are based on network authentication system, uses SIM cards that are based on
symmetric secrets. In contrast, public key systems have yet to show symmetric secrets. In contrast, public key systems have yet to show
ability to scale to hundreds of millions of devices, let alone ability to scale to hundreds of millions of devices, let alone
billions. But the authors do not believe scaling is an important billions. But the authors do not believe scaling is an important
differentiator when comparing the solutions. differentiator when comparing the solutions.
As can be seen from the Section 6, the time needed to calculate some As can be seen from the Section 6, the time needed to calculate some
of the asymmetric cryptographic operations with reasonable key of the asymmetric cryptographic operations with reasonable key
lengths can be significant. There are two contrary observations that lengths can be significant. There are two contrary observations that
can be made from this. First, recent wisdom indicates that computing can be made from this. First, recent wisdom indicates that computing
power on small devices is far cheaper than transmission power power on resource-constrained devices is far cheaper than
[wiman], and keeps on becoming more efficient very quickly. From transmission power [wiman], and keeps on becoming more efficient very
this we can conclude that the sufficient CPU is or at least will be quickly. From this we can conclude that the sufficient CPU is or at
easily available. least will 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 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
skipping to change at page 26, line 48 skipping to change at page 27, line 26
and therefore it is recommended for resource-constrained devices. and therefore it is recommended 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
identities at appropriate times during their lifecycle. For
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
skipping to change at page 27, line 40 skipping to change at page 28, line 20
Van der Laan, E., "AVR CRYPTOLIB", September 2015, Van der Laan, E., "AVR CRYPTOLIB", September 2015,
<http://www.emsign.nl/>. <http://www.emsign.nl/>.
[avrora] Titzer, Ben., "Avrora", September 2015, [avrora] Titzer, Ben., "Avrora", September 2015,
<http://compilers.cs.ucla.edu/avrora/>. <http://compilers.cs.ucla.edu/avrora/>.
[freescale] [freescale]
NXP, "Freescale FRDM-KL25Z", June 2017, NXP, "Freescale FRDM-KL25Z", June 2017,
<https://developer.mbed.org/platforms/KL25Z/>. <https://developer.mbed.org/platforms/KL25Z/>.
[hahmos] Hahm, O., Baccelli, E., Petersen, H., and N. Tsiftes,
"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 [huang] Huang, C., "Low-overhead freshness transmission in sensor
networks", 2008. networks", 2008.
[I-D.arkko-core-security-arch] [I-D.arkko-core-security-arch]
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 draft-arkko-core-security-arch-00 (work in progress), July
2011. 2011.
[I-D.arkko-core-sleepy-sensors] [I-D.arkko-core-sleepy-sensors]
Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
skipping to change at page 28, line 14 skipping to change at page 28, line 46
[I-D.daniel-6lowpan-security-analysis] [I-D.daniel-6lowpan-security-analysis]
Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J.
Laganier, "IPv6 over Low Power WPAN Security Analysis", Laganier, "IPv6 over Low Power WPAN Security Analysis",
draft-daniel-6lowpan-security-analysis-05 (work in draft-daniel-6lowpan-security-analysis-05 (work in
progress), March 2011. progress), March 2011.
[I-D.ietf-core-coap-pubsub] [I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-02 (work in (CoAP)", draft-ietf-core-coap-pubsub-03 (work in
progress), July 2017. progress), February 2018.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core- Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-12 (work in progress), October 2017. resource-directory-12 (work in progress), October 2017.
[I-D.ietf-core-senml] [I-D.ietf-core-senml]
Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Media Types for Sensor Measurement Lists Bormann, "Media Types for Sensor Measurement Lists
(SenML)", draft-ietf-core-senml-12 (work in progress), (SenML)", draft-ietf-core-senml-12 (work in progress),
December 2017. December 2017.
[I-D.irtf-t2trg-iot-seccons] [I-D.irtf-t2trg-iot-seccons]
Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of-
the-Art and Challenges for the Internet of Things the-Art and Challenges for the Internet of Things
Security", draft-irtf-t2trg-iot-seccons-09 (work in Security", draft-irtf-t2trg-iot-seccons-11 (work in
progress), December 2017. progress), February 2018.
[I-D.moskowitz-hip-dex] [I-D.moskowitz-hip-dex]
Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)",
draft-moskowitz-hip-dex-05 (work in progress), January draft-moskowitz-hip-dex-05 (work in progress), January
2016. 2016.
[I-D.sarikaya-t2trg-sbootstrapping] [I-D.sarikaya-t2trg-sbootstrapping]
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", draft-sarikaya-t2trg-
sbootstrapping-03 (work in progress), February 2017. sbootstrapping-03 (work in progress), February 2017.
skipping to change at page 29, line 21 skipping to change at page 29, line 50
time efficiency and power consumption analysis", Pomiary time efficiency and power consumption analysis", Pomiary
Automatyka Kontrola , 2010. Automatyka Kontrola , 2010.
[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 Cryptology
in Africa , Springer Berlin Heidelberg , 2013. in Africa , Springer Berlin Heidelberg , 2013.
[nesC] Gay, D., Levis, P., von Behren, R., Welsh, M., Brewer, E.,
and D. Culler, "The nesC language: A holistic approach to
networked embedded systems", ACM SIGPLAN Notices , 2014.
[nordic] Nordic Semiconductor, "nRF52832 Product Specification", [nordic] Nordic Semiconductor, "nRF52832 Product Specification",
June 2017, <http://infocenter.nordicsemi.com/pdf/ June 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, Aranha, D. and C. Gouv, "Relic Toolkit", September 2015,
<http://code.google.com/p/relic-toolkit/>. <http://code.google.com/p/relic-toolkit/>.
[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
skipping to change at page 31, line 41 skipping to change at page 32, line 28
[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", 2010.
[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://cs.ucsb.edu/~koc/docs/r01.pdf>.
[sec2ecc] Certicom Research, "SEC 2: Recommended Elliptic Curve
Domain Parameters", 2000.
[stnucleo] [stnucleo]
STMicroelectronics, "NUCLEO-F091RC", June 2017, 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] North Carolina State University and North Carolina State
University, "TinyECC", 2008, University, "TinyECC", 2008,
<http://discovery.csc.ncsu.edu/software/TinyECC/>. <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", International Conference on
Computer Communication Networks (ICCCN'2010) / IEEE Computer Communication Networks (ICCCN'2010) / IEEE
International Workshop on Wireless Mesh and Ad Hoc International Workshop on Wireless Mesh and Ad Hoc
Networks (WiMAN 2010) , 2010. Networks (WiMAN 2010) , 2010.
[wiselib] Baumgartner, T., Chatzigiannakis, I., Fekete, S., Koninis, [wiselib] Baumgartner, T., Chatzigiannakis, I., Fekete, S., Koninis,
C., Kroller, A., and A. Pyrgelis, "Wiselib", 2010, C., Kroller, A., and A. Pyrgelis, "Wiselib", 2010,
<www.wiselib.org/>. <www.wiselib.org/>.
[Withings] [Withings]
Withings, "The Withings scale", February 2012, Withings, "The Withings scale", February 2012,
skipping to change at page 33, line 14 skipping to change at page 34, line 14
Appendix A. Acknowledgments Appendix A. 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
Vyncke, and Emmanuel Baccelli provided valuable comments that helped
us improve the final version of 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
skipping to change at page 33, line 38 skipping to change at page 34, line 42
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
Comptel Nokia
Helsinki 00181 Helsinki 00181
Finland Finland
EMail: heidi.back@comptel.com EMail: heidi.back@nokia.com
 End of changes. 66 change blocks. 
200 lines changed or deleted 236 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/