draft-ietf-lwig-crypto-sensors-01.txt   draft-ietf-lwig-crypto-sensors-02.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: May 4, 2017 Ericsson Expires: August 14, 2017 Ericsson
H. Back H. Back
Comptel Comptel
October 31, 2016 February 10, 2017
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-01 draft-ietf-lwig-crypto-sensors-02
Abstract Abstract
This memo describes challenges associated with securing smart object This memo describes challenges associated with securing smart object
devices in constrained implementations and environments. The memo devices in constrained implementations and environments. The memo
describes a possible deployment model suitable for these describes a possible deployment model suitable for these
environments, discusses the availability of cryptographic libraries environments, discusses the availability of cryptographic libraries
for small devices, presents some preliminary experiences in for small devices, presents some preliminary experiences in
implementing small devices using those libraries, and discusses implementing cryptography on small devices using those libraries, and
trade-offs involving different types of approaches. discusses trade-offs involving different types of 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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 May 4, 2017. This Internet-Draft will expire on August 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 27 skipping to change at page 2, line 27
5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8 6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8
7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 9 7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 9
8. Implementation Experiences . . . . . . . . . . . . . . . . . 11 8. Implementation Experiences . . . . . . . . . . . . . . . . . 11
9. Example Application . . . . . . . . . . . . . . . . . . . . . 17 9. Example Application . . . . . . . . . . . . . . . . . . . . . 17
10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21 10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21
11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 22
13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 24 13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 26 14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 26
15. Security Considerations . . . . . . . . . . . . . . . . . . . 26 15. Security Considerations . . . . . . . . . . . . . . . . . . . 27
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
17. Informative references . . . . . . . . . . . . . . . . . . . 26 17. Informative references . . . . . . . . . . . . . . . . . . . 27
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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.
Secondly, Section 4 discusses a deployment model that the authors are Secondly, Section 4 discusses a deployment model that the authors are
considering for constrained environments. The model requires minimal considering for constrained environments. The model requires minimal
amount of configuration, and we believe it is a natural fit with the amount of configuration, and we believe it is a natural fit with the
typical communication practices in smart object networking typical communication practices in smart object networking
environments. environments.
skipping to change at page 3, line 25 skipping to change at page 3, line 25
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. CoAP base specification [RFC7252] outlines how to
use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol. use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol.
DTLS can be applied with pairwise shared keys, raw public keys or DTLS can be applied with pairwise shared keys, raw public keys or
with certificates. The security model in all cases is mutual with certificates. The security model in all cases is mutual
authentication, so while there is some commonality to HTTP in authentication, so while there is some commonality to HTTP in
verifying the server identity, in practice the models are quite verifying the server identity, in practice the models are quite
different. The CoAP specification says little about how DTLS keys different. The CoAP specification says little about how DTLS keys
are managed. The use of IPsec with CoAP is described with regards to are managed. 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 small implementations of IKEv2
exist [RFC7815]. However, the CoAP specification is silent on policy exist [RFC7815] . However, the CoAP specification is silent on policy
and other aspects that are normally necessary in order to implement and other aspects that are normally necessary in order to implement
interoperable use of IPsec in any environment [RFC5406]. interoperable use of IPsec in any environment [RFC5406].
[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 is needed in developing suitable credential
management mechanisms (perhaps something similar to the Bluetooth management mechanisms (perhaps something similar to the Bluetooth
pairing mechanism), understanding the implementability of standard pairing mechanism), understanding the implementability of standard
security mechanisms in small devices and additional research in the security mechanisms in small devices, and additional research in the
area of lightweight cryptographic primitives. 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 IP layer communications. runs end-to-end between hosts, protecting all IP layer
[RFC6078] describes an extension of HIP that can be used to send communications. [RFC6078] describes an extension of HIP that can be
upper layer protocol messages without running the usual HIP base used to send upper layer protocol messages without running the usual
exchange at all. HIP base exchange at all.
[I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis [I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis
of security issues related to 6LoWPAN networks, but its findings also of security issues related to 6LoWPAN networks, but its findings also
apply more generally for all low-powered networks. Some of the apply more generally for all low-powered networks. Some of the
issues this document discusses include the need to minimize the issues this document discusses include the need to minimize the
number of transmitted bits and simplify implementations, threats in number of transmitted bits and simplify implementations, threats in
the smart object networking environments, and the suitability of the smart object networking environments, and the suitability of
6LoWPAN security mechanisms, IPsec, and key management protocols for 6LoWPAN security mechanisms, IPsec, and key management protocols for
implementation in these environments. implementation in these environments.
[I-D.irtf-t2trg-iot-seccons] discusses the overall security problem [I-D.irtf-t2trg-iot-seccons] discusses the overall security problem
for Internet of Things devices. It also discusses various solutions, for Internet of Things devices. It also discusses various solutions,
including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347], including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347],
HIP [RFC7401] [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP HIP [RFC7401] [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP
[RFC3748]. The draft also discusses various operational scenarios, [RFC3748]. The draft also discusses various operational scenarios,
bootstrapping mechanisms, and challenges associated with implementing and challenges associated with implementing security mechanisms in
security mechanisms in these environments. these environments.
[I-D.sarikaya-t2trg-sbootstrapping] discusses bootstrapping
mechanisms available for resource-constrained IoT devices.
3. Challenges 3. Challenges
This section discusses three challenges: implementation difficulties, This section discusses three challenges: 1) implementation
practical provisioning problems, and layering and communication difficulties, 2) practical provisioning problems, 3) layering and
models. communication models.
The most often discussed issues in the security for the Internet of One of the most often discussed issues in the security for the
Things relate to implementation difficulties. The desire to build Internet of Things relate to implementation difficulties. The desire
small, battery-operated, and inexpensive devices drives the creation to build small, battery-operated, and inexpensive devices drives the
of devices with a limited protocol and application suite. Some of creation of devices with a limited protocol and application suite.
the typical limitations include running CoAP instead of HTTP, limited Some of the typical limitations include running CoAP instead of HTTP,
support for security mechanisms, limited processing power for long limited support for security mechanisms, limited processing power for
key lengths, sleep schedule that does not allow communication at all long key lengths, sleep schedule that does not allow communication at
times, and so on. In addition, the devices typically have very all times, and so on. In addition, the devices typically have very
limited support for configuration, making it hard to set up secrets limited support for configuration, making it hard to set up secrets
and trust anchors. 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. Also, the use of the most implementations have to support that. Also, the use of the most
lightweight algorithms and cryptographic primitives is useful, but lightweight algorithms and cryptographic primitives is useful, but
should not be the only consideration in the design. Interoperability should not be the only consideration in the design. Interoperability
skipping to change at page 6, line 23 skipping to change at page 6, line 23
then commence with the devices, at least as far as information from then commence with the devices, at least as far as information from
from the devices to the server is concerned, which is what is needed from the devices to the server is concerned, which is what is needed
for sensor networks. for sensor networks.
The above architecture is a perfect fit for sensor networks where The above architecture is a perfect fit for sensor networks where
information flows from large number of devices to small number of information flows from large number of devices to small number of
servers. But it is not sufficient alone for other types of servers. But it is not sufficient alone for other types of
applications. For instance, in actuator applications a large number applications. For instance, in actuator applications a large number
of devices need to take commands from somewhere else. In such of devices need to take commands from somewhere else. In such
applications it is necessary to secure that the commands come from an applications it is necessary to secure that the commands come from an
authorized source. This can be supported, with some additional authorized source.
provisioning effort and optional pairing protocols. The basic
provisioning approach is as described earlier, but in addition there This can be supported, with some additional provisioning effort and
must be something that informs the devices of the identity of the optional pairing protocols. The basic provisioning approach is as
trusted server(s). There are multiple ways to provide this described earlier, but in addition there must be something that
information. One simple approach is to feed the identities of the informs the devices of the identity of the trusted server(s). There
trusted server(s) to devices at installation time. This requires are multiple ways to provide this information. One simple approach
either a separate user interface, local connection (such as USB), or is to feed the identities of the trusted server(s) to devices at
using the network interface of the device for configuration. In any installation time. This requires either a separate user interface,
case, as with sensor networks the amount of configuration information local connection (such as USB), or using the network interface of the
is minimized: just one short identity value needs to be fed in. Not device for configuration. In any case, as with sensor networks the
both an identity and a certificate. Not shared secrets that must be amount of configuration information is minimized: just one short
kept confidential. An even simpler provisioning approach is that the identity value needs to be fed in. Not both an identity and a
devices in the device group trust each other. Then no configuration certificate. Not shared secrets that must be kept confidential. An
is needed at installation time. When both peers know the expected even simpler provisioning approach is that the devices in the device
cryptographic identity of the other peer off-line, secure group trust each other. Then no configuration is needed at
communications can commence. Alternatively, various pairing schemes installation time.
can be employed. Note that these schemes can benefit from the
already secure identifiers on the device side. For instance, the When both peers know the expected cryptographic identity of the other
server can send a pairing message to each device after their initial peer off-line, secure communications can commence. Alternatively,
power-on and before they have been paired with anyone, encrypted with various pairing schemes can be employed. Note that these schemes can
the public key of the device. As with all pairing schemes that do benefit from the already secure identifiers on the device side. For
not employ a shared secret or the secure dentity of both parties, instance, the server can send a pairing message to each device after
there are some remaining vulnerabilities that may or may not be their initial power-on and before they have been paired with anyone,
acceptable for the application in question. In any case, the secure encrypted with the public key of the device. As with all pairing
identities help again in ensuring that the operations are as simple schemes that do not employ a shared secret or the secure identity of
as possible. Only identities need to be communicated to the devices, both parties, there are some remaining vulnerabilities that may or
not certificates, not shared secrets or IPsec policy rules. may not be acceptable for the application in question.
In any case, the secure identities help again in ensuring that the
operations are as simple as possible. Only identities need to be
communicated to the devices, not certificates, not shared secrets or
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. The authors have employed a simple but
not completely secure method where the last few digits of the not completely secure method where the last few digits of the
skipping to change at page 9, line 20 skipping to change at page 9, line 28
solutions either, it is not the typical arrangement either. solutions either, it is not the typical arrangement either.
7. Code Availability 7. 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 SRAM, and 32 kB of processor with a clock speed of 16 MHz, 2 kB of SRAM, and 32 kB of
flash memory. flash memory.
For selecting potential asymmetric cryptographic libraries, we did an For selecting potential asymmetric cryptographic libraries, we
extensive survey 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. Please verify the numbers before relying errors, and other mistakes. It is advisable to verify the numbers
on them for building something. No significant effort was done to before relying on them for building something. No significant effort
optimize ROM memory usage beyond what the libraries provided was done to optimize ROM memory usage beyond what the libraries
themselves, so those numbers should be taken as upper limits. provided themselves, so those numbers should be taken as upper
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 a variety of
different symmetric key algorithms such as AES and RSA as an different symmetric key algorithms such as AES and RSA as an
asymmetric key algorithm. We stripped down the library to use asymmetric key algorithm. We stripped down the library to use
only the required RSA components and used a separate SHA-256 only the required RSA components and used a separate SHA-256
implementation from the original AvrCrypto-Lib library implementation from the original AvrCrypto-Lib library
[avr-crypto-lib]. Parts of SHA-256 and RSA algorithm [avr-crypto-lib]. Parts of SHA-256 and RSA algorithm
implementations were written in AVR-8 bit assembly language to implementations were written in AVR-8 bit assembly language to
skipping to change at page 9, line 51 skipping to change at page 10, line 12
programmer to directly address the flash memory to access constant programmer to directly address the flash memory to access constant
data which can save the amount of SRAM used during execution. data which can save the amount of SRAM used during execution.
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 and many more. The toolkit provides an option to build only the
desired components for the required platform. While building the desired components for the required platform. While building the
library, it is possible to select a variety mathematical library, it is possible to select a variety of mathematical
optimizations that can be combined to obtain the desired optimizations that can be combined to obtain the desired
performance (as a general thumb rule, faster implementations performance (as a general thumb rule, faster implementations
require more SRAM and flash). It includes a multi precision require more SRAM and flash). It includes a multi precision
integer math module which can be customized to use different bit- integer math module which can be customized to use different bit-
length words. length words.
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 nesC programming language and as such is designed for specific
use on TinyOS. However, the library can be ported to standard C99 use on TinyOS. However, the library can be ported to standard C99
skipping to change at page 10, line 27 skipping to change at page 10, line 37
Barrett reduction for verification, precomputation, etc. It also Barrett reduction for verification, precomputation, etc. It also
has one of the smallest memory footprints among the set of has one of the smallest memory footprints among the set of
Elliptic Curve libraries surveyed so far. However, an advantage Elliptic Curve libraries surveyed so far. However, an advantage
of Relic over TinyECC is that it can do curves over binary fields of Relic over TinyECC is that it can do curves over binary fields
in addition to prime fields. in addition to prime fields.
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 by the authors to
test the code on Arduino Uno. The structure of the code is similar test the code on Arduino Uno. The structure of the code is similar
to TinyECC and like TinyECC it implements elliptic curves over to TinyECC and like TinyECC it implements elliptic curves over
prime fields only. In order to make the code platform prime fields only. In order to make the code platform
independent, no assembly level optimizations were incorporated. independent, no assembly level optimizations were incorporated.
skipping to change at page 11, line 6 skipping to change at page 11, line 14
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). However, the library in the and ECC (with a commercial license). However, the library in the
original form takes about 50 kB of ROM which is not suitable for original form takes about 50 kB of ROM which is not suitable for
our hardware requirements. Moreover, it is intended for 32-bit our hardware requirements. Moreover, it is intended for 32-bit
systems and the API includes functions for SSL communication systems and the API includes functions for SSL communication
rather than just signing data with private keys. rather than just signing data with private keys.
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
8. Implementation Experiences 8. 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 9 required only the our example application discussed in Section 9 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 performance We have summarized the initial results of RSA private key performance
using AvrCryptolib in Table 1. All results are from a single run using AvrCryptolib in Table 1. All results are from a single run
since repeating the test did not change (or had only minimal impact since repeating the test did not change (or had only minimal impact
skipping to change at page 11, line 41 skipping to change at page 12, line 13
these keys are provided here for reference only. these keys are provided here for reference only.
+--------+--------------+--------------+-------------+--------------+ +--------+--------------+--------------+-------------+--------------+
| Key | Execution | Memory | Execution | Memory | | Key | Execution | Memory | Execution | Memory |
| length | time (ms); | footprint | time (ms); | footprint | | length | time (ms); | footprint | time (ms); | footprint |
| (bits) | key in SRAM | (bytes); key | key in ROM | (bytes); key | | (bits) | key in SRAM | (bytes); key | key in ROM | (bytes); key |
| | | in SRAM | | in ROM | | | | in SRAM | | in ROM |
+--------+--------------+--------------+-------------+--------------+ +--------+--------------+--------------+-------------+--------------+
| 64 | 64 | 40 | 69 | 32 | | 64 | 64 | 40 | 69 | 32 |
| 128 | 434 | 80 | 460 | 64 | | 128 | 434 | 80 | 460 | 64 |
| 512 | 25,076 | 320 | 27348 | 256 | | 512 | 25076 | 320 | 27348 | 256 |
| 1,024 | 199688 | 640 | 218367 | 512 | | 1024 | 199688 | 640 | 218367 | 512 |
| 2,048 | 1587567 | 1,280 | 1740258 | 1,024 | | 2048 | 1587567 | 1,280 | 1740258 | 1024 |
+--------+--------------+--------------+-------------+--------------+ +--------+--------------+--------------+-------------+--------------+
RSA private key operation performance RSA private key operation performance
Table 1 Table 1
The code size was less than 3.6 kB for all the test cases with scope The code size was less than 3.6 kB for all the test cases with
for further reduction. It is also worth noting that the potential for further reduction. It is also worth noting that the
implementation performs basic exponentiation and multiplication implementation performs basic exponentiation and multiplication
operations without using any mathematical optimizations such as operations without using any mathematical optimizations such as
Montgomery multiplication, optimized squaring, etc. as described in Montgomery multiplication, optimized squaring, etc. as described in
[rsa-high-speed]. With more SRAM, we believe that 1024/2048-bit [rsa-high-speed]. With more SRAM, we believe that 1024/2048-bit
operations can be performed in much less time as has been shown in operations can be performed in much less time as has been shown in
[rsa-8bit]. 2048-bit RSA is nonetheless possible with about 1 kB of [rsa-8bit]. 2048-bit RSA is nonetheless possible with about 1 kB of
SRAM as is seen in Table 1. SRAM as is seen in Table 1.
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 ECDSA signature algorithm on
the Arduino Uno board. TinyECC supports a variety of SEC 2 the Arduino Uno board. TinyECC supports a variety of SEC 2
recommended Elliptic Curve domain parameters. The execution time and recommended Elliptic Curve domain parameters. The execution time and
memory footprint are shown next to each of the curve parameters. memory footprint are shown next to each of the curve parameters.
SHA-1 hashing algorithm included in the library was used in each of SHA-1 hashing algorithm included in the library was used in each of
the cases. The measurements reflect the performance of elliptic the cases. The measurements reflect the performance of elliptic
curve signing only and not the SHA-1 hashing algorithm. SHA-1 is now curve signing only and not the SHA-1 hashing algorithm. SHA-1 is now
known to be insecure and should not be used in real deployments. It known to be insecure and should not be used in live deployments. It
is clearly observable that for similar security levels, Elliptic is clearly observable that for similar security levels, Elliptic
Curve public key cryptography outperforms RSA. These results were Curve public key cryptography outperforms RSA. These results were
obtained by turning on all the optimizations. These optimizations obtained by turning on all the optimizations. These optimizations
include - Curve Specific Optimizations for modular reduction (NIST include - Curve Specific Optimizations for modular reduction (NIST
and SEC 2 field primes were chosen as pseudo-Mersenne primes), and SEC 2 field primes were chosen as pseudo-Mersenne primes),
Sliding Window for faster scalar multiplication, Hybrid squaring Sliding Window for faster scalar multiplication, Hybrid squaring
procedure written in assembly and Weighted projective Coordinate procedure written in assembly and Weighted projective Coordinate
system for efficient scalar point addition, doubling and system for efficient scalar point addition, doubling and
multiplication. We did not use optimizations like Shamir Trick and multiplication. We did not use optimizations like Shamir Trick and
Sliding Window as they are only useful for signature verification and Sliding Window as they are only useful for signature verification and
skipping to change at page 14, line 8 skipping to change at page 14, line 26
| 192r1 | 6217 | 1008 | 1536 | | 192r1 | 6217 | 1008 | 1536 |
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
ECDSA signature performance with TinyECC (No assembly optimizations) ECDSA signature performance with TinyECC (No assembly 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 for all the 128, 160 and 192-bit SEC 2 Elliptic
curves. SHA-1 algorithm provided in the library was used. The curves. SHA-1 algorithm provided in the library was used. The
measurements reflect the performance of elliptic curve signing only measurements reflect the performance of elliptic curve signing only
and not the SHA-1 hashing algorithm. SHA-1 is now known to be and not the SHA-1 hashing algorithm. SHA-1 is now known to be
insecure and should not be used in real deployments. The ROM size insecure and should not be used in real deployments. The ROM size
for all the experiments was less than 16 kB. 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 |
skipping to change at page 14, line 50 skipping to change at page 15, line 21
measurements reflect the performance of elliptic curve signing only measurements reflect the performance of elliptic curve signing only
and not the SHA-1 hashing algorithm. SHA-1 is now known to be and not the SHA-1 hashing algorithm. SHA-1 is now known to be
insecure and should not be used in real deployments. The library insecure and should not be used in real deployments. The library
does provide several alternatives with such as SHA-256. does provide several alternatives with such as SHA-256.
The relic-toolkit supports Koblitz curves over prime as well as The relic-toolkit supports Koblitz curves over prime as well as
binary fields. We have experimented with Koblitz curves over binary binary fields. We have experimented with Koblitz curves over binary
fields only. We do not run our experiments with all the curves fields only. We do not run our experiments with all the curves
available in the library since the aim of this work is not prove available in the library since the aim of this work is not prove
which curves perform the fastest, and rather show that asymmetric which curves perform the fastest, and rather show that asymmetric
crypto is possible on resource-constrained devices. cryptography is possible on resource-constrained devices.
The results from relic-toolkit are documented in two separate tables The results from relic-toolkit are documented in two separate tables
shown in Table 5 and Table 6. The first set of results were shown in Table 5 and Table 6. The first set of results were
performed with the library configured for high speed performance with performed with the library configured for high speed performance with
no consideration given to the amount of memory used. For the second no consideration given to the amount of memory used. For the second
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.
skipping to change at page 16, line 9 skipping to change at page 16, line 29
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 As with the RSA measurements, curves giving less that 112-bit o As with the RSA measurements, curves giving less that 112-bit
security are insecure and considered as legacy. The measurements security are insecure and considered as legacy. The measurements
are only provided for reference. are only provided for reference.
o The arduino board only provides pseudo random numbers with the o The Arduino board only provides pseudo random numbers with the
random() function call. In order to create private keys with a random() function call. In order to create private keys with a
better quality of random number, we can use a true random number better quality of random number, we can use a true random number
generator like the one provided by TrueRandom library generator like the one provided by TrueRandom library
[truerandom], or create the keys separately on a system with a [truerandom], or create the keys separately on a system with a
true random number generator and then use them directly in the true random number generator and then use them directly in the
code. code.
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.
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). [I-D.irtf-cfrg-eddsa] specifies Digital Signature Algorithm (EdDSA). [RFC8032] specifies the
the recommended parameters for the edwards25519 and edwards448 recommended parameters for the edwards25519 and edwards448 curves.
curves. From these, curve25519 (for elliptic curve Diffie-Hellman From these, curve25519 (for elliptic curve Diffie-Hellman key
key exchange) and edwards25519 (for elliptic curve digital exchange) and edwards25519 (for elliptic curve digital signatures)
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 23,216,241 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 1,4510 milliseconds of execution time. When corresponds to about 14510 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 ROM use is shown in Table 7. A summary library ROM use is shown in Table 7.
+-------------------------+---------------------------+ +------------------------+---------------------------+
| Library | ROM Footprint (Kilobytes) | | Library | ROM Footprint (Kilobytes) |
+-------------------------+---------------------------+ +------------------------+---------------------------+
| AvrCryptolib | 3.6 | | AvrCryptolib | 3.6 |
| Wiselib | 16 | | Wiselib | 16 |
| TinyECC | 18 | | TinyECC | 18 |
| Relic-toolkit | 29 | | Relic-toolkit | 29 |
| NaCl Ed25519 [naclavr] | 17-29 | | NaCl Ed25519 [naclavr] | 17-29 |
+-------------------------+---------------------------+ +------------------------+---------------------------+
Summary of library ROM needs Summary of library ROM needs
Table 7 Table 7
All the measurements here are only provided as an example to show All the measurements here are only provided as an example to show
that asymmetric-key cryptography (particularly, digital signatures) that asymmetric-key cryptography (particularly, digital signatures)
is possible on resource-constrained devices. These numbers by no way is possible on resource-constrained devices. These numbers by no way
are the final source for measurements and some curves presented here are the final source for measurements and some curves presented here
may not be acceptable for real in-the-wild deployments anymore. For may not be acceptable for real in-the-wild deployments anymore. For
skipping to change at page 17, line 41 skipping to change at page 18, line 10
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 be 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 mirror resource directories [I-D.ietf-core-resource-directory] and publish-
proxies [I-D.vial-core-mirror-proxy] instead. Architecturally, the subscribe brokers [I-D.ietf-core-coap-pubsub] instead.
idea is that sensors can delegate a part of their role to a node in Architecturally, the idea is that sensors can delegate a part of
the network. Such a network node could be either a local resource or their role to a node in the network. Such a network node could be
something in the Internet. In the case of CoAP mirror proxies, the either a local resource or something in the Internet. In the case of
network node agrees to hold the web resources on behalf of the CoAP publish-subscribe brokers, the network node agrees to hold the
sensor, while the sensor is asleep. The only role that the sensor web resources on behalf of the sensor, while the sensor is asleep.
has is to register itself at the mirror proxy, and periodically The only role that the sensor has is to register itself at the
update the readings. All queries from the rest of the world go to publish-subscribe broker, and periodically update the readings. All
the mirror proxy. queries from the rest of the world go to the publish-subscribe
broker.
We constructed a system with four entities: We constructed a system with four entities:
Sensor Sensor
This is an Arduino-based device that runs a CoAP mirror proxy This is an Arduino-based device that runs a CoAP publish-subscribe
client and Relic-toolkit. Relic takes 29 Kbytes of ROM, and the broker client and Relic-toolkit. Relic takes 29 Kbytes of ROM,
simple CoAP client roughly 3 kilobytes. and the simple CoAP client roughly 3 kilobytes.
Mirror Proxy Publish-Subscribe Broker
This is a mirror proxy that holds resources on the sensor's This is a publish-subscribe broker that holds resources on the
behalf. The sensor registers itself to this node. sensor's behalf. The sensor registers itself to this node.
Resource Directory Resource Directory
While physically in the same node in our implementation, a While physically in the same node in our implementation, a
resource directory is a logical function that allows sensors and resource directory is a logical function that allows sensors and
mirror proxies to register resources in the directory. These publish-subscribe brokers to register resources in the directory.
resources can be queried by applications. These resources can be queried by applications.
Application Application
This is a simple application that runs on a general purpose This is a simple application that runs on a general purpose
computer and can retrieve both registrations from the resource computer and can retrieve both registrations from the resource
directory and most recent sensor readings from the mirror proxy. directory and most recent sensor readings from the publish-
subscribe broker.
The security of this system relies on an SSH-like approach. In Step The security of this system relies on an SSH-like approach. In Step
1, upon first boot, sensors generate keys and register themselves in 1, upon first boot, sensors generate keys and register themselves in
the mirror proxy. Their public key is submitted along with the the publish-subscribe broker. Their public key is submitted along
registration as an attribute in the CORE Link Format data [RFC6690]. with the registration as an attribute in the CORE Link Format data
[RFC6690].
In Step 2, when the sensor makes a sensor reading update to the In Step 2, when the sensor makes a measurement, it sends an update to
mirror proxy it signs the message contents with a JOSE signature on the publish-subscribe broker and signs the message contents with a
the used JSON/SENML payload [RFC7515] [I-D.jennings-core-senml]. JOSE signature on the used JSON/SENML payload [RFC7515]
[I-D.ietf-core-senml]. The sensor can also alternatively use CBOR
Object Signing and Encryption (COSE) [I-D.ietf-cose-msg] for signing
the sensor measurement.
In Step 3, any other device in the network -- including the mirror In Step 3, any other device in the network -- including the publish-
proxy, resource directory and the application -- can check that the subscribe broker, resource directory and the application -- can check
public key from the registration corresponds to the private key used that the public key from the registration corresponds to the private
to make the signature in the data update. key used to make the signature in the data update.
Note that checks can be done at any time and there is no need for the Note that checks can be done at any time and there is no need for the
sensor and the checking node to be awake at the same time. In our sensor and the checking node to be awake at the same time. In our
implementation, the checking is done in the application node. This implementation, the checking is done in the application node. This
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 Mirror Proxy (MP) and the Arduino Mega board. In this prototype, the publish-subscribe broker
Resource Directory (RD) reside on the same physical host. A 64-bit and the Resource Directory (RD) reside on the same physical host. A
x86 linux machine serves as the MP and the RD, while a similar but 64-bit x86 linux machine serves as the broker and the RD, while a
physically different 64-bit x86 linux machine serves as the client similar but physically different 64-bit x86 linux machine serves as
that requests data from the sensor. We chose the Relic library the client that requests data from the sensor. We chose the Relic
version 0.3.1 for our sample prototype as it can be easily compiled library version 0.3.1 for our sample prototype as it can be easily
for different bit-length processors. Therefore, we were able to use compiled for different bit-length processors. Therefore, we were
it on the 8-bit processor of the Arduino Mega, as well as on the able to use it on the 8-bit processor of the Arduino Mega, as well as
64-bit processor of the x86 client. We used ECDSA to sign and verify on the 64-bit processor of the x86 client. We used ECDSA to sign and
data updates with the standard NIST-K163 curve parameters (163-bit verify data updates with the standard NIST-K163 curve parameters
Koblitz curve over binary field). While compiling Relic for our (163-bit Koblitz curve over binary field). While compiling Relic for
prototype, we used the fast configuration without any assembly our prototype, we used the fast configuration without any assembly
optimizations. 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 Mirror Proxy programming language and extends it to add support for publish-
and Resource Directory REST interfaces. We also developed a subscribe broker and Resource Directory REST interfaces. We also
minimalistic CoAP C-library for the Arduino sensor and for the client developed a minimalistic CoAP C-library for the Arduino sensor and
requesting data updates for a resource. The library has small SRAM for the client requesting data updates for a resource. The library
requirements and uses stack-based allocation only. It is inter- has small SRAM requirements and uses stack-based allocation only. It
operable with the Java implementation of CoAP running on the gateway. is interoperable with the Java implementation of CoAP running on the
The location of the mirror proxy was pre-configured into the smart gateway. The location of the publish-subscribe broker was configured
object sensor by hardcoding the IP address. We used an IPv4 network into the smart object sensor by hardcoding the IP address. We used
with public IP addresses obtained from a DHCP server. an IPv4 network with public IP addresses obtained from a DHCP server.
Some important statistics of this prototype are listed in table Some important statistics of this prototype are listed in table
Table 8. Our straw man analysis of the performance of this prototype Table 8. Our straw man analysis of the performance of this prototype
is preliminary. Our intention was to demonstrate the feasibility of is preliminary. Our intention was to demonstrate the feasibility of
the entire architecture with public-key cryptography on an 8-bit the 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 SRAM considerable amount. For example, the flash memory and SRAM
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 were used out-of-the-box and there are several functions which can be
be removed. Similarly we used the fast version of the Relic library removed. Similarly we used the fast version of the Relic library in
in the prototype instead of the low memory version. the prototype instead of the low memory version.
+-----------------------------------------------------------+-------+ +-----------------------------------------------------------+-------+
| Flash memory consumption (for the entire prototype | 51 kB | | Flash memory consumption (for the entire prototype | 51 kB |
| including Relic crypto + CoAP + Arduino UDP, Ethernet and | | | including Relic library + CoAP + Arduino UDP) | |
| DHCP Libraries) | |
| | | | | |
| SRAM consumption (for the entire prototype including DHCP | 4678 | | SRAM consumption (for the entire prototype including key | 4678 |
| client + key generation + signing the hash of message + | bytes | | generation + signing the hash of message + COAP + UDP + | bytes |
| COAP + UDP + Ethernet) | | | Ethernet) | |
| | | | | |
| Execution time for creating the key pair + sending | 2030 | | Execution time for creating the key pair + sending | 2030 |
| registration message + time spent waiting for acknowl- | ms | | registration message + time spent waiting for | ms |
| edgement | | | acknowledgement | |
| | | | | |
| Execution time for signing the hash of message + sending | 987 | | Execution time for signing the hash of message + sending | 987 |
| update | ms | | update | ms |
| | | | | |
| Signature overhead | 42 | | Signature overhead | 42 |
| | bytes | | | bytes |
+-----------------------------------------------------------+-------+ +-----------------------------------------------------------+-------+
Prototype Performance Prototype Performance
Table 8 Table 8
To demonstrate the efficacy of this communication model we compare it To demonstrate the efficacy of this communication model we compare it
with a scenario where the smart objects do not transition into the with a scenario where the smart objects do not transition into the
energy saving sleep mode and directly serve temperature data to energy saving sleep mode and directly serve temperature data to
clients. As an example, we assume that in our architecture, the clients. As an example, we assume that in our architecture, the
smart objects wake up once every minute to report the signed smart objects wake up once every minute to report the signed
temperature data to the caching MP. If we calculate the energy temperature data to the caching broker. If we calculate the energy
consumption using the formula W = U * I * t (where U is the operating consumption using the formula W = U * I * t (where U is the operating
voltage, I is the current drawn and t is the execution time), and use voltage, I is the current drawn and t is the execution time), and use
the voltage and current values from the datasheets of the ATmega2560 the voltage and current values from the datasheets of the ATmega2560
(20mA-active mode and 5.4mA-sleep mode) and W5100 (183mA) chips used (20mA-active mode and 5.4mA-sleep mode) and W5100 (183mA) chips used
in the architecture, then in a one minute period, the Arduino board in the architecture, then in a one minute period, the Arduino board
would consume 60.9 Joules of energy if it directly serves data and would consume 60.9 Joules of energy if it directly serves data and
does not sleep. On the other hand, in our architecture it would only does not sleep. On the other hand, in our architecture it would only
consume 2.6 Joules if it wakes up once a minute to update the MP with consume 2.6 Joules if it wakes up once a minute to update the broker
signed data. Therefore, a typical Li-ion battery that provides about with signed data. Therefore, a typical Li-ion battery that provides
1800 milliamps per hour (mAh) at 5V would have a lifetime of 9 hours about 1800 milliamps per hour (mAh) at 5V would have a lifetime of 9
in the unsecured always-on scenario, whereas it would have a lifetime hours in the unsecured always-on scenario, whereas it would have a
of about 8.5 days in the secured sleepy architecture presented. lifetime of about 8.5 days in the secured sleepy architecture
These lifetimes appear to be low because the Arduino board in the presented. These lifetimes appear to be low because the Arduino
prototype uses Ethernet which is not energy efficient. The values board in the prototype uses Ethernet which is not energy efficient.
presented only provide an estimate (ignoring the energy required to The values presented only provide an estimate (ignoring the energy
transition in and out of the sleep mode) and would vary depending on required to transition in and out of the sleep mode) and would vary
the hardware and MAC protocol used. Nonetheless, it is evident that depending on the hardware and MAC protocol used. Nonetheless, it is
our architecture can increase the life of smart objects by allowing evident that our architecture can increase the life of smart objects
them to sleep and can ensure security at the same time. by allowing them to sleep and can ensure security at the same time.
10. Design Trade-Offs 10. Design Trade-Offs
This section attempts to make some early conclusions regarding trade- This section attempts to make some early conclusions regarding trade-
offs in the design space, based on deployment considerations for offs in the design space, based on deployment considerations for
various mechanisms and the relative ease or difficulty of various mechanisms and the relative ease or difficulty of
implementing them. This analysis looks at layering and the choice of implementing them. This analysis looks at layering and the choice of
symmetric vs. asymmetric cryptography. symmetric vs. asymmetric cryptography.
11. Feasibility 11. Feasibility
skipping to change at page 22, line 6 skipping to change at page 22, line 17
the beginning of the session would also be fine with any of these the 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, the authors believe that these
algorithms can successfully be employed in small devices for the algorithms can successfully be employed in small 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 smaller. Using the Relic-toolkit execution times can actually be very small (less than 500 ms).
with the NIST K163 algorithm (roughly equivalent to RSA at 1024
bits) at 0.3 seconds is a good example of this.
o As discussed in [wiman], in general the power requirements o As discussed in [wiman], in general the power requirements
necessary to send or receive messages are far bigger than those necessary to send or receive messages are far bigger than those
needed to execute cryptographic operations. There is no good needed to execute cryptographic operations. While there are newer
reason to choose platforms that do not provide sufficient radios that significantly lower the energy consumption of sending
computing power to run the necessary operations. and receiving messages, there is no good reason to choose
platforms that do not provide sufficient computing power to run
the necessary cryptographic operations.
o Commercial libraries and the use of full potential for various o Commercial libraries and the use of full potential for various
optimizations will provide a better result than what we arrived at optimizations will provide a better result than what we arrived at
in this paper. in this memo.
o Using public key cryptography only at the beginning of a session o Using public key cryptography only at the beginning of a session
will reduce the per-packet processing times significantly. will reduce the per-packet processing times significantly.
12. Freshness 12. Freshness
In our architecture, if implemented as described thus far, messages In our architecture, if implemented as described thus far, messages
along with their signatures sent from the sensors to the mirror proxy along with their signatures sent from the sensors to the publish-
can be recorded and replayed by an eavesdropper. The mirror proxy subscribe broker can be recorded and replayed by an eavesdropper.
has no mechanism to distinguish previously received packets from The publish-subscribe broker has no mechanism to distinguish
those that are retransmitted by the sender or replayed by an previously received packets from those that are retransmitted by the
eavesdropper. Therefore, it is essential for the smart objects to sender or replayed by an eavesdropper. Therefore, it is essential
ensure that data updates include a freshness indicator. However, for the smart objects to ensure that data updates include a freshness
ensuring freshness on constrained devices can be non-trivial because indicator. However, ensuring freshness on constrained devices can be
of several reasons which include: non-trivial because of several reasons which include:
o Communication is mostly unidirectional to save energy. o Communication is mostly unidirectional to save energy.
o Internal clocks might not be accurate and may be reset several o Internal clocks might not be accurate and may be reset several
times during the operational phase of the smart object. times during the operational phase of the smart object.
o Network time synchronization protocols such as Network Time o Network time synchronization protocols such as Network Time
Protocol (NTP) [RFC5905] are resource intensive and therefore may Protocol (NTP) [RFC5905] are resource intensive and therefore may
be undesirable in many smart object networks. be undesirable in many smart object networks.
There are several different methods that can be used in our There are several different methods that can be used in our
architecture for replay protection. The selection of the appropriate architecture for replay protection. The selection of the appropriate
choice depends on the actual deployment scenario. choice depends on the actual deployment scenario.
Including sequence numbers in signed messages can provide an Including sequence numbers in signed messages can provide an
effective method of replay protection. The mirror proxy should effective method of replay protection. The publish-subscribe broker
verify the sequence number of each incoming message and accept it should verify the sequence number of each incoming message and accept
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 mirror proxy drops any packet with a sequence number number. The publish-subscribe broker drops any packet with a
that has already been received or if the received sequence number is sequence number that has already been received or if the received
greater than the highest previously seen sequence number by an amount sequence number is greater than the highest previously seen sequence
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
into the permanent flash memory after each increment and before it is into the permanent flash memory after each increment and before it is
included in the message to be transmitted. This ensures that the included in the message to be transmitted. This ensures that the
sensor can obtain the last sequence number it had intended to send in sensor can obtain the last sequence number it had intended to send in
case of a reset or a power failure. However, the sensor and the case of a reset or a power failure. However, the sensor and the
mirror proxy can still end up in a discordant state where the publish-subscribe broker can still end up in a discordant state where
sequence number received by the mirror proxy exceeds the expected the sequence number received by the publish-subscribe broker exceeds
sequence number by an amount greater than the preset threshold. This the expected sequence number by an amount greater than the preset
may happen because of a prolonged network outage or if the mirror threshold. This may happen because of a prolonged network outage or
proxy experiences a power failure for some reason. Therefore it is if the publish-subscribe broker experiences a power failure for some
essential for sensors that normally send Non-Confirmable data updates reason. Therefore it is essential for sensors that normally send
to send some Confirmable updates and re-synchronize with the mirror Non-Confirmable data updates to send some Confirmable updates and re-
proxy if a reset message is received. The sensors re-synchronize by synchronize with the publish-subscribe broker if a reset message is
sending a new registration message with the current sequence number. received. The sensors re-synchronize by sending a new registration
message with the current sequence number.
Although sequence numbers protect the system from replay attacks, a Although sequence numbers protect the system from replay attacks, a
mirror proxy has no mechanism to determine the time at which updates publish-subscribe broker has no mechanism to determine the time at
were created by the sensor. Moreover, if sequence numbers are the which updates were created by the sensor. Moreover, if sequence
only freshness indicator used, a malicious eavesdropper can induce numbers are the only freshness indicator used, a malicious
inordinate delays to the communication of signed updates by buffering eavesdropper can induce inordinate delays to the communication of
messages. It may be important in certain smart object networks for signed updates by buffering messages. It may be important in certain
sensors to send data updates which include timestamps to allow the smart object networks for sensors to send data updates which include
mirror proxy to determine the time when the update was created. For timestamps to allow the publish-subscribe broker to determine the
example, when the mirror proxy is collecting temperature data, it may time when the update was created. For example, when the publish-
be necessary to know when exactly the temperature measurement was subscribe broker is collecting temperature data, it may be necessary
made by the sensor. A simple solution to this problem is for the to know when exactly the temperature measurement was made by the
mirror proxy to assume that the data object was created when it sensor. A simple solution to this problem is for the publish-
subscribe broker to assume that the data object was created when it
receives the update. In a relatively reliable network with low RTT, receives the update. In a relatively reliable network with low RTT,
it can be acceptable to make such an assumption. However most it can be acceptable to make such an assumption. However most
networks are susceptible to packet loss and hostile attacks making networks are susceptible to packet loss and hostile attacks making
this assumption unsustainable. this assumption unsustainable.
Depending on the hardware used by the smart objects, they may have Depending on the hardware used by the smart objects, they may have
access to accurate hardware clocks which can be used to include access to accurate hardware clocks which can be used to include
timestamps in the signed updates. These timestamps are included in timestamps in the signed updates. These timestamps are included in
addition to sequence numbers. The clock time in the smart objects addition to sequence numbers. The clock time in the smart objects
can be set by the manufacturer or the current time can be can be set by the manufacturer or the current time can be
communicated by the mirror proxy during the registration phase. communicated by the publish-subscribe broker during the registration
However, these approaches require the smart objects to either rely on phase. However, these approaches require the smart objects to either
the long-term accuracy of the clock set by the manufacturer or to rely on the long-term accuracy of the clock set by the manufacturer
trust the mirror proxy thereby increasing the potential vulnerability or to trust the publish-subscribe broker thereby increasing the
of the system. The smart objects could also obtain the current time potential vulnerability of the system. The smart objects could also
from NTP, but this may consume additional energy and give rise to obtain the current time from NTP, but this may consume additional
security issues discussed in [RFC5905]. The smart objects could also energy and give rise to security issues discussed in [RFC5905]. The
have access to a GSM network or the Global Positioning System (GPS), smart objects could also have access to a mobile network or the
and they can be used obtain the current time. Finally, if the Global Positioning System (GPS), and they can be used obtain the
sensors need to co-ordinate their sleep cycles, or if the mirror current time. Finally, if the sensors need to co-ordinate their
proxy computes an average or mean of updates collected from multiple sleep cycles, or if the publish-subscribe broker computes an average
smart objects, it is important for the network nodes to synchronize or mean of updates collected from multiple smart objects, it is
the time among them. This can be done by using existing important for the network nodes to synchronize the time among them.
synchronization schemes. This can be done by using existing synchronization schemes.
13. Layering 13. Layering
It would be useful to select just one layer where security is It would be useful to select just one layer where security is
provided at. Otherwise a simple device needs to implement multiple provided at. Otherwise a simple device needs to implement multiple
security mechanisms. While some code can probably be shared across security mechanisms. While some code can probably be shared across
such implementations (like algorithms), it is likely that most of the such implementations (like algorithms), it is likely that most of the
code involving the actual protocol machinery cannot. Looking at the code involving the actual protocol machinery cannot. Looking at the
different layers, here are the choices and their implications: different layers, here are the choices and their implications:
skipping to change at page 27, line 35 skipping to change at page 28, line 5
Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- Novo, "Implementing Tiny COAP Sensors", draft-arkko-core-
sleepy-sensors-01 (work in progress), July 2011. sleepy-sensors-01 (work in progress), July 2011.
[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]
Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-00 (work in
progress), October 2016.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
Resource Directory", draft-ietf-core-resource-directory-08 Resource Directory", draft-ietf-core-resource-directory-09
(work in progress), July 2016. (work in progress), October 2016.
[I-D.irtf-cfrg-eddsa] [I-D.ietf-core-senml]
Josefsson, S. and I. Liusvaara, "Edwards-curve Digital Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08 Bormann, "Media Types for Sensor Measurement Lists
(work in progress), August 2016. (SenML)", draft-ietf-core-senml-04 (work in progress),
October 2016.
[I-D.ietf-cose-msg]
Schaad, J., "CBOR Object Signing and Encryption (COSE)",
draft-ietf-cose-msg-24 (work in progress), November 2016.
[I-D.irtf-t2trg-iot-seccons] [I-D.irtf-t2trg-iot-seccons]
Garcia-Morchon, O., Kumar, S., and M. Sethi, "Security Garcia-Morchon, O., Kumar, S., and M. Sethi, "Security
Considerations in the IP-based Internet of Things", draft- Considerations in the IP-based Internet of Things", draft-
irtf-t2trg-iot-seccons-00 (work in progress), October irtf-t2trg-iot-seccons-00 (work in progress), October
2016. 2016.
[I-D.jennings-core-senml]
Jennings, C., Shelby, Z., Arkko, J., and A. Keranen,
"Media Types for Sensor Markup Language (SenML)", draft-
jennings-core-senml-06 (work in progress), April 2016.
[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.vial-core-mirror-proxy] [I-D.sarikaya-t2trg-sbootstrapping]
Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT
proxy-01 (work in progress), July 2012. Bootstrapping: A Survey", draft-sarikaya-t2trg-
sbootstrapping-03 (work in progress), February 2017.
[matrix-ssl] [matrix-ssl]
PeerSec Networks, "Matrix SSL", September 2015, PeerSec Networks, "Matrix SSL", September 2015,
<http://www.matrixssl.org/>. <http://www.matrixssl.org/>.
[micronacl] [micronacl]
MicroNaCl, "The Networking and Cryptography library for MicroNaCl, "The Networking and Cryptography library for
microcontrollers", <http://munacl.cryptojedi.org/>. microcontrollers", <http://munacl.cryptojedi.org/>.
[mosdorf] Mosdorf, M. and W. Zabolotny, "Implementation of elliptic [mosdorf] Mosdorf, M. and W. Zabolotny, "Implementation of elliptic
curve cryptography for 8 bit and 32 bit embedded systems curve cryptography for 8 bit and 32 bit embedded systems
time efficiency and power consumption analysis", 2010. time efficiency and power consumption analysis", Pomiary
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.
[relic-toolkit] [relic-toolkit]
Aranha, D. and C. Gouv, "Relic Toolkit", September 2015, Aranha, D. and C. Gouv, "Relic Toolkit", September 2015,
skipping to change at page 30, line 28 skipping to change at page 31, line 5
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <http://www.rfc-editor.org/info/rfc7748>. 2016, <http://www.rfc-editor.org/info/rfc7748>.
[RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2
(IKEv2) Initiator Implementation", RFC 7815, (IKEv2) Initiator Implementation", RFC 7815,
DOI 10.17487/RFC7815, March 2016, DOI 10.17487/RFC7815, March 2016,
<http://www.rfc-editor.org/info/rfc7815>. <http://www.rfc-editor.org/info/rfc7815>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<http://www.rfc-editor.org/info/rfc8032>.
[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>.
[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/>.
[truerandom] [truerandom]
Drow, C., "Truerandom", September 2015, Drow, C., "Truerandom", September 2015,
<http://code.google.com/p/tinkerit/wiki/TrueRandom>. <http://code.google.com/p/tinkerit/wiki/TrueRandom>.
[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. In 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, Zurich. Proceedings of Networks (WiMAN 2010) , 2010.
ICCCN'2010/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,
<http://www.withings.com/en/bodyscale>. <http://www.withings.com/en/bodyscale>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
 End of changes. 63 change blocks. 
237 lines changed or deleted 265 lines changed or added

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