draft-ietf-lwig-crypto-sensors-02.txt   draft-ietf-lwig-crypto-sensors-03.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: August 14, 2017 Ericsson Expires: January 26, 2018 Ericsson
H. Back H. Back
Comptel Comptel
February 10, 2017 July 25, 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-02 draft-ietf-lwig-crypto-sensors-03
Abstract Abstract
This memo describes challenges associated with securing smart object This memo describes challenges associated with securing resource-
devices in constrained implementations and environments. The memo constrained smart object devices. The memo describes a possible
describes a possible deployment model suitable for these deployment model suitable for these environments, discusses the
environments, discusses the availability of cryptographic libraries availability of cryptographic libraries for small devices, and
for small devices, presents some preliminary experiences in presents some preliminary experiences in implementing cryptography on
implementing cryptography on small devices using those libraries, and small devices using those libraries. Lastly, the memo discusses
discusses trade-offs involving different types of approaches. trade-offs involving 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 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 August 14, 2017. This Internet-Draft will expire on January 26, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5 4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . 10
9. Example Application . . . . . . . . . . . . . . . . . . . . . 17 9. Example Application . . . . . . . . . . . . . . . . . . . . . 17
10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21 10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 20
11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 20
12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 21
13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 24 13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 23
14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 26 14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 25
15. Security Considerations . . . . . . . . . . . . . . . . . . . 27 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
17. Informative references . . . . . . . . . . . . . . . . . . . 27 17. Informative references . . . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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 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.
Thirdly, Section 7 discusses the availability of cryptographic Section 7 discusses the availability of cryptographic libraries.
libraries. Section 8 presents some experiences in implementing Section 8 presents some experiences in implementing cryptography on
cryptography on small devices using those libraries, including small devices using those libraries, including information about
information about achievable code sizes and speeds on typical achievable code sizes and speeds on typical hardware.
hardware.
Finally, Section 10 discusses trade-offs involving different types of Finally, Section 10 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. 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 [RFC7230]
verifying the server identity, in practice the models are quite in verifying the server identity, in practice the models are quite
different. The CoAP specification says little about how DTLS keys different. 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.
skipping to change at page 4, line 39 skipping to change at page 4, line 37
limited support for security mechanisms, limited processing power for limited support for security mechanisms, limited processing power for
long key lengths, sleep schedule that does not allow communication at long key lengths, sleep schedule that does not allow communication at
all 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. It is important for developers
lightweight algorithms and cryptographic primitives is useful, but and product designers to determine what security threats they want to
should not be the only consideration in the design. Interoperability tackle and the resulting security requirements before selecting the
is also important, and often other parts of the system, such as key hardware. Often, development work in the wild happens in the wrong
management protocols or certificate formats are heavier to implement order: a particular platform with a resource-constrained
than the algorithms themselves. microcontroller is chosen first, and then the security features that
can fit on it are decided. Also, the use of the most lightweight
algorithms and cryptographic primitives is useful, but should not be
the only consideration in the design and development.
Interoperability is also important, and often other parts of the
system, such as key management protocols or certificate formats are
heavier to implement than the algorithms themselves.
The second challenge relates to practical provisioning problems. The second challenge relates to practical provisioning problems.
These are perhaps the most fundamental and difficult issue, and These are 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 Small devices have no natural user interface for configuration
that would be required for the installation of shared secrets and that would be required for the installation of shared secrets and
other security-related parameters. Typically, there is no other security-related parameters. Typically, there is no
keyboard, no display, and there may not even be buttons to press. keyboard, no display, and there may not even be buttons to press.
skipping to change at page 9, line 25 skipping to change at page 9, line 28
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 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 RAM, and 32 kB of
flash memory. flash memory. Our choice of 8-bit platform may be surprising since
it.
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 a variety of
different symmetric key algorithms such as AES and RSA as an different symmetric key algorithms such as AES, triple DES and
asymmetric key algorithm. We stripped down the library to use SkipJack. It provides RSA as an asymmetric key algorithm. Parts
only the required RSA components and used a separate SHA-256 of the library were written in AVR-8 bit assembly language to
implementation from the original AvrCrypto-Lib library reduce the size and optimize the performance.
[avr-crypto-lib]. Parts of SHA-256 and RSA algorithm
implementations were written in AVR-8 bit assembly language to
reduce the size and optimize the performance. The library also
takes advantage of the fact that Arduino boards allow the
programmer to directly address the flash memory to access constant
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.
library, it is possible to select a variety of mathematical
optimizations that can be combined to obtain the desired
performance (as a general thumb rule, faster implementations
require more SRAM and flash). It includes a multi precision
integer math module which can be customized to use different bit-
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 C
either with hacked tool-chains or manually rewriting parts of the either with tool-chains or manually rewriting parts of the code.
code. This allows for the library to be used on platforms that do It also has one of the smallest memory footprints among the set of
not have TinyOS running on them. The library includes a wide elliptic curve libraries surveyed so far.
variety of mathematical optimizations such as sliding window,
Barrett reduction for verification, precomputation, etc. It also
has one of the smallest memory footprints among the set of
Elliptic Curve libraries surveyed so far. However, an advantage
of Relic over TinyECC is that it can do curves over binary 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.
to TinyECC and like TinyECC it implements elliptic curves over
prime fields only. In order to make the code platform
independent, no assembly level optimizations were incorporated.
Since efficiency was not an important goal for the authors of the
library while designing, many well known theoretical performance
enhancement features were also not incorporated. Like the relic-
toolkit, Wiselib is also Lesser GPL licensed.
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). The library in the original
original form takes about 50 kB of ROM which is not suitable for form takes about 50 kB of ROM and is intended for 32-bit
our hardware requirements. Moreover, it is intended for 32-bit platforms.
systems and the API includes functions for SSL communication
rather than just signing data with private keys. 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
foodprint. 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.
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
using AvrCryptolib in Table 1. All results are from a single run exponentiation performance using AvrCryptolib [avr-crypto-lib] in
since repeating the test did not change (or had only minimal impact Table 1. All results are from a single run since repeating the test
on) the results. The keys were generated separately and were hard did not change (or had only minimal impact on) the results. The
coded into the program. All keys were generated with the value of execution time for a key size of 2048 bits was inordinately long and
the public exponent as 3. The performance of signing with private would be a deterrent in real-world deployments.
key was faster for smaller key lengths as was expected. However the
increase in the execution time was considerable when the key size was
2048 bits. It is important to note that two different sets of
experiments were performed for each key length. In the first case,
the keys were loaded into the SRAM from the ROM (flash) before they
were used by any of the functions. However, in the second case, the
keys were addressed directly in the ROM. As was expected, the second
case used less SRAM but lead to longer execution time.
More importantly, any RSA key size less than 2,048-bit should be
considered legacy and insecure. The performance measurements for
these keys are provided here for reference only.
+--------+--------------+--------------+-------------+--------------+ +--------------+------------------------+---------------------------+
| Key | Execution | Memory | Execution | Memory | | Key length | Execution time (ms); | Memory footprint (bytes); |
| length | time (ms); | footprint | time (ms); | footprint | | (bits) | key in RAM | key in RAM |
| (bits) | key in SRAM | (bytes); key | key in ROM | (bytes); key | +--------------+------------------------+---------------------------+
| | | in SRAM | | in ROM | | 2048 | 1587567 | 1,280 |
+--------+--------------+--------------+-------------+--------------+ +--------------+------------------------+---------------------------+
| 64 | 64 | 40 | 69 | 32 |
| 128 | 434 | 80 | 460 | 64 |
| 512 | 25076 | 320 | 27348 | 256 |
| 1024 | 199688 | 640 | 218367 | 512 |
| 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 The code size was about 3.6 kB with potential for further reduction.
potential for further reduction. It is also worth noting that the It is also worth noting that the implementation performs basic
implementation performs basic exponentiation and multiplication exponentiation and multiplication operations without using any
operations without using any mathematical optimizations such as mathematical optimizations such as Montgomery multiplication,
Montgomery multiplication, optimized squaring, etc. as described in optimized squaring, etc. as described in [rsa-high-speed]. With more
[rsa-high-speed]. With more SRAM, we believe that 1024/2048-bit RAM, we believe that 2048-bit operations can be performed in much
operations can be performed in much less time as has been shown in less time as has been shown in [rsa-8bit].
[rsa-8bit]. 2048-bit RSA is nonetheless possible with about 1 kB of
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 These results were obtained by turning on all the optimizations and
the cases. The measurements reflect the performance of elliptic using assembly code where available. It is clearly observable that
curve signing only and not the SHA-1 hashing algorithm. SHA-1 is now for similar security levels, Elliptic Curve public key cryptography
known to be insecure and should not be used in live deployments. It outperforms RSA.
is clearly observable that for similar security levels, Elliptic
Curve public key cryptography outperforms RSA. These results were
obtained by turning on all the optimizations. These optimizations
include - Curve Specific Optimizations for modular reduction (NIST
and SEC 2 field primes were chosen as pseudo-Mersenne primes),
Sliding Window for faster scalar multiplication, Hybrid squaring
procedure written in assembly and Weighted projective Coordinate
system for efficient scalar point addition, doubling and
multiplication. We did not use optimizations like Shamir Trick and
Sliding Window as they are only useful for signature verification and
tend to slow down the signature generation by precomputing values (we
were only interested in fast signature generation). There is still
some scope for optimization as not all the assembly code provided
with the library could be ported to Arduino directly. Re-writing
these procedures in compatible assembly would further enhance the
performance.
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
| Curve | Execution | Memory | Comparable RSA | | Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | Footprint | key length | | parameters | time (ms) | Footprint | key length |
| | | (bytes) | | | | | (bytes) | |
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
| 128r1 | 1858 | 776 | 704 | | secp160k1 | 2228 | 892 | 1024 |
| 128r2 | 2002 | 776 | 704 | | secp160r1 | 2250 | 892 | 1024 |
| 160k1 | 2228 | 892 | 1024 | | secp160r2 | 2467 | 892 | 1024 |
| 160r1 | 2250 | 892 | 1024 | | secp192k1 | 3425 | 1008 | 1536 |
| 160r2 | 2467 | 892 | 1024 | | secp192r1 | 3578 | 1008 | 1536 |
| 192k1 | 3425 | 1008 | 1536 |
| 192r1 | 3578 | 1008 | 1536 |
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
ECDSA signature performance with TinyECC Performance of ECDSA sign operation with TinyECC
Table 2 Table 2
We also performed experiments by removing the assembly code for We also performed experiments by removing the assembly optimization
hybrid multiplication and squaring thus using a C only form of the and using a C only form of the library. This gives us an idea of the
library. This gives us an idea of the performance that can be performance that can be achieved with TinyECC on any platform
achieved with TinyECC on any platform regardless of what kind of OS regardless of what kind of OS and assembly instruction set available.
and assembly instruction set available. The memory footprint remains The memory footprint remains the same with or without assembly code.
the same with our without assembly code. The tables contain the The tables contain the maximum RAM that is used when all the possible
maximum RAM that is used when all the possible optimizations are on. optimizations are on. If however, the amount of RAM available is
If however, the amount of RAM available is smaller in size, some of smaller in size, some of the optimizations can be turned off to
the optimizations can be turned off to reduce the memory consumption reduce the memory consumption accordingly.
accordingly.
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
| Curve | Execution | Memory | Comparable RSA | | Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | Footprint | key length | | parameters | time (ms) | Footprint | key length |
| | | (bytes) | | | | | (bytes) | |
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
| 128r1 | 2741 | 776 | 704 | | secp160k1 | 3795 | 892 | 1024 |
| 128r2 | 3086 | 776 | 704 | | secp160r1 | 3841 | 892 | 1024 |
| 160k1 | 3795 | 892 | 1024 | | secp160r2 | 4118 | 892 | 1024 |
| 160r1 | 3841 | 892 | 1024 | | secp192k1 | 6091 | 1008 | 1536 |
| 160r2 | 4118 | 892 | 1024 | | secp192r1 | 6217 | 1008 | 1536 |
| 192k1 | 6091 | 1008 | 1536 |
| 192r1 | 6217 | 1008 | 1536 |
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
ECDSA signature performance with TinyECC (No assembly optimizations) Performance of ECDSA sign operation 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. The ROM size for all the experiments was less than 16 kB.
measurements reflect the performance of elliptic 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. 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) | |
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
| 128r1 | 5615 | 732 | 704 | | secp160k1 | 10957 | 842 | 1024 |
| 128r2 | 5615 | 732 | 704 | | secp160r1 | 10972 | 842 | 1024 |
| 160k1 | 10957 | 842 | 1024 | | secp160r2 | 10971 | 842 | 1024 |
| 160r1 | 10972 | 842 | 1024 | | secp192k1 | 18814 | 952 | 1536 |
| 160r2 | 10971 | 842 | 1024 | | secp192r1 | 18825 | 952 | 1536 |
| 192k1 | 18814 | 952 | 1536 |
| 192r1 | 18825 | 952 | 1536 |
+-------------+---------------+-----------------+-------------------+ +-------------+---------------+-----------------+-------------------+
ECDSA signature performance 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. We decided to use the Arduino Mega which has the
same 8-bit architecture like the Arduino Uno but has a much larger same 8-bit architecture like the Arduino Uno but has a much larger
RAM/ROM for testing relic-toolkit. Again, SHA-1 hashing algorithm RAM/ROM for testing relic-toolkit. Again, it is important to mention
included in the library was used in each of the cases. The that we used Arduino as it is a convenient prototyping platform. Our
measurements reflect the performance of elliptic curve signing only intention was to demonstrate the feasibility of the entire
and not the SHA-1 hashing algorithm. SHA-1 is now known to be architecture with public key cryptography on an 8-bit
insecure and should not be used in real deployments. The library microcontroller. However it is important to state that 32-bit
does provide several alternatives with such as SHA-256. microcontrollers are much more easily available, at lower costs and
are more power efficient. Therefore, real deployments are better off
using 32-bit microcontrollers that allow developers to include the
necessary cryptographic libraries. There is no good reason to choose
platforms that do not provide sufficient computing power to run the
necessary cryptographic operations.
The relic-toolkit supports Koblitz curves over prime as well as The relic-toolkit supports Koblitz curves over prime as well as
binary fields. We have experimented with Koblitz curves over binary binary fields. We have experimented with Koblitz curves over binary
fields only. We do not run our experiments with all the curves fields only. We do not run our experiments with all the curves
available in the library since the aim of this work is not prove available in the library since the aim of this work is not prove
which curves perform the fastest, and rather show that asymmetric which curves perform the fastest, and rather show that asymmetric
cryptography is possible on resource-constrained devices. cryptography is possible on resource-constrained devices.
The results from relic-toolkit are documented in two separate tables The results from relic-toolkit are documented 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
skipping to change at page 15, line 45 skipping to change at page 14, line 20
| | | (bytes) | | | | | (bytes) | |
+-----------------+--------------+----------------+-----------------+ +-----------------+--------------+----------------+-----------------+
| NIST K163 | 261 | 2,804 | 1024 | | NIST K163 | 261 | 2,804 | 1024 |
| (assembly math) | | | | | (assembly math) | | | |
| NIST K163 | 932 | 2750 | 1024 | | NIST K163 | 932 | 2750 | 1024 |
| NIST B163 | 2243 | 2444 | 1024 | | NIST B163 | 2243 | 2444 | 1024 |
| NIST K233 | 1736 | 3675 | 2048 | | NIST K233 | 1736 | 3675 | 2048 |
| NIST B233 | 4471 | 3261 | 2048 | | NIST B233 | 4471 | 3261 | 2048 |
+-----------------+--------------+----------------+-----------------+ +-----------------+--------------+----------------+-----------------+
ECDSA signature performance 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 | | NIST K163 | 592 | 2087 | 1024 |
| (assembly math) | | | | | (assembly math) | | | |
| NIST K163 | 2950 | 2215 | 1024 | | NIST K163 | 2950 | 2215 | 1024 |
| NIST B163 | 3213 | 2071 | 1024 | | NIST B163 | 3213 | 2071 | 1024 |
| NIST K233 | 6450 | 2935 | 2048 | | NIST K233 | 6450 | 2935 | 2048 |
| NIST B233 | 6100 | 2737 | 2048 | | NIST B233 | 6100 | 2737 | 2048 |
+-----------------+--------------+----------------+-----------------+ +-----------------+--------------+----------------+-----------------+
ECDSA signature performance 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 As with the RSA measurements, curves giving less that 112-bit
security are insecure and considered as legacy. The measurements
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. Real-world deployments must rely on a
better quality of random number, we can use a true random number hardware random number generator for cryptographic operations such
generator like the one provided by TrueRandom library as generating a public-private key pair. The Nordic nRF52832
[truerandom], or create the keys separately on a system with a board [nordic] for example provides a hardware random number
true random number generator and then use them directly in the generator.
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.
Tschofenig and Pegourie-Gonnard [armecdsa] have also evaluated the
performance of Elliptic Curve Cryptography (ECC) on ARM Coretex
platform. The results for ECDSA sign operation shown in Table 7 are
performed on a Freescale FRDM-KL25Z board [freescale] that has a ARM
Cortex-M0+ 48MHz microcontroller with 128kB of flash memory and 16kB
of RAM. The sliding window technique for efficient exponentiation
was used with a window size of 2. All other optimizations were
disabled for these measurements.
+------------------+---------------------+--------------------------+
| Curve parameters | Execution time (ms) | Comparable RSA key |
| | | length |
+------------------+---------------------+--------------------------+
| secp192r1 | 2165 | 1536 |
| secp224r1 | 3014 | 2048 |
| secp256r1 | 3649 | 2048 |
+------------------+---------------------+--------------------------+
Performance of ECDSA sign operation with ARM mbed TLS stack on
Freescale FRDM-KL25Z
Table 7
The authors also measured the performance of curves on a ST Nucleo
F091 (STM32F091RCT6) board [stnucleo] that has a ARM Cortex-M0 48MHz
microcontroller with 256 kB of flash memory and 32kB of RAM. The
execution time for ECDSA sign operation with different curves is
shown in Table 8. The sliding window technique for efficient
exponentiation was used with a window size of 7. Fixed point
optimization and NIST curve specific optimizations were used for
these measurements.
+------------------+---------------------+--------------------------+
| Curve parameters | Execution time (ms) | Comparable RSA key |
| | | length |
+------------------+---------------------+--------------------------+
| secp192k1 | 291 | 1536 |
| secp192r1 | 225 | 1536 |
| secp224k1 | 375 | 2048 |
| secp224r1 | 307 | 2048 |
| secp256k1 | 486 | 2048 |
| secp256r1 | 459 | 2048 |
| secp384r1 | 811 | 7680 |
| secp521r1 | 1602 | 15360 |
+------------------+---------------------+--------------------------+
ECDSA signature performance with ARM mbed TLS stack on ST Nucleo F091
(STM32F091RCT6)
Table 8
The authors also measured the RAM consumption by calculating the heap
consumed for the cryptographic operations using a custom memory
allocation handler. The authors did not measure the minimal stack
memory consumption. Depending on the curve and the different
optimizations enable or disabled, the 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
skipping to change at page 17, line 20 skipping to change at page 17, line 10
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 14510 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 flash memory use is shown in Table 9.
+------------------------+---------------------------+ +------------------------+------------------------------------+
| Library | ROM Footprint (Kilobytes) | | Library | Flash memory Footprint (Kilobytes) |
+------------------------+---------------------------+ +------------------------+------------------------------------+
| AvrCryptolib | 3.6 | | AvrCryptolib | 3.6 |
| Wiselib | 16 | | Wiselib | 16 |
| TinyECC | 18 | | TinyECC | 18 |
| Relic-toolkit | 29 | | Relic-toolkit | 29 |
| NaCl Ed25519 [naclavr] | 17-29 | | NaCl Ed25519 [naclavr] | 17-29 |
+------------------------+---------------------------+ +------------------------+------------------------------------+
Summary of library ROM needs Summary of library flash memory consumption
Table 7 Table 9
All the measurements here are only provided as an example to show All the measurements here are only provided as an example to show
that asymmetric-key cryptography (particularly, digital signatures) that asymmetric-key cryptography (particularly, digital signatures)
is possible on resource-constrained devices. These numbers by no way is possible on resource-constrained devices. 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
example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also
document performance of ECDSA on similar resource-constrained document performance of ECDSA on similar resource-constrained
devices. devices.
skipping to change at page 18, line 27 skipping to change at page 18, line 17
The only role that the sensor has is to register itself at the The only role that the sensor has is to register itself at the
publish-subscribe broker, and periodically update the readings. All publish-subscribe broker, and periodically update the readings. All
queries from the rest of the world go to the publish-subscribe queries from the rest of the world go to the publish-subscribe
broker. broker.
We constructed a system with four entities: We constructed a system with four entities:
Sensor Sensor
This is an Arduino-based device that runs a CoAP publish-subscribe This is an Arduino-based device that runs a CoAP publish-subscribe
broker client and Relic-toolkit. Relic takes 29 Kbytes of ROM, broker client and Relic-toolkit. Relic takes 29 Kbytes of flash
and the simple CoAP client roughly 3 kilobytes. memory, and the simple CoAP client roughly 3 kilobytes.
Publish-Subscribe Broker Publish-Subscribe Broker
This is a publish-subscribe broker that holds resources on the This is a publish-subscribe broker that holds resources on the
sensor's 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
skipping to change at page 19, line 11 skipping to change at page 18, line 49
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 publish-subscribe broker. Their public key is submitted along the publish-subscribe broker. Their public key is submitted along
with the registration as an attribute in the CORE Link Format data with the registration as an attribute in the CORE Link Format data
[RFC6690]. [RFC6690].
In Step 2, when the sensor makes a measurement, it sends an update to In Step 2, when the sensor makes a measurement, it sends an update to
the publish-subscribe broker and signs the message contents with a the publish-subscribe broker and signs the message contents with a
JOSE signature on the used JSON/SENML payload [RFC7515] JOSE signature on the used JSON/SENML payload [RFC7515]
[I-D.ietf-core-senml]. The sensor can also alternatively use CBOR [I-D.ietf-core-senml]. The sensor can also alternatively use CBOR
Object Signing and Encryption (COSE) [I-D.ietf-cose-msg] for signing Object Signing and Encryption (COSE) [RFC8152] for signing the sensor
the sensor measurement. measurement.
In Step 3, any other device in the network -- including the publish- In Step 3, any other device in the network -- including the publish-
subscribe broker, resource directory and the application -- can check subscribe broker, resource directory and the application -- can check
that the public key from the registration corresponds to the private that the public key from the registration corresponds to the private
key used 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
skipping to change at page 19, line 38 skipping to change at page 19, line 29
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 different 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.
(163-bit Koblitz curve over binary field). While compiling Relic for While compiling Relic for our prototype, we used the fast
our prototype, we used the fast configuration without any assembly 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 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 SRAM 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 publish-subscribe broker was configured gateway. The location of the publish-subscribe broker was configured
into the smart object sensor by hardcoding the IP address. We used into the smart object sensor by hardcoding the IP address.
an IPv4 network with public IP addresses obtained from a DHCP server.
Some important statistics of this prototype are listed in table Our intention was to demonstrate that it is possible to implement the
Table 8. Our straw man analysis of the performance of this prototype entire architecture with public-key cryptography on an 8-bit
is preliminary. Our intention was to demonstrate the feasibility of
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 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. the prototype instead of the low memory version. However, it is
important to note that this was only a research prototype to verify
+-----------------------------------------------------------+-------+ the feasibility of this architecture and as stated elsewhere, most
| Flash memory consumption (for the entire prototype | 51 kB | modern development boards have a 32-bit microcontroller since they
| including Relic library + CoAP + Arduino UDP) | | are more economical and have better energy efficiency.
| | |
| SRAM consumption (for the entire prototype including key | 4678 |
| generation + signing the hash of message + COAP + UDP + | bytes |
| Ethernet) | |
| | |
| Execution time for creating the key pair + sending | 2030 |
| registration message + time spent waiting for | ms |
| acknowledgement | |
| | |
| Execution time for signing the hash of message + sending | 987 |
| update | ms |
| | |
| Signature overhead | 42 |
| | bytes |
+-----------------------------------------------------------+-------+
Prototype Performance
Table 8
To demonstrate the efficacy of this communication model we compare it
with a scenario where the smart objects do not transition into the
energy saving sleep mode and directly serve temperature data to
clients. As an example, we assume that in our architecture, the
smart objects wake up once every minute to report the signed
temperature data to the caching broker. If we calculate the energy
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
the voltage and current values from the datasheets of the ATmega2560
(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
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
consume 2.6 Joules if it wakes up once a minute to update the broker
with signed data. Therefore, a typical Li-ion battery that provides
about 1800 milliamps per hour (mAh) at 5V would have a lifetime of 9
hours in the unsecured always-on scenario, whereas it would have a
lifetime of about 8.5 days in the secured sleepy architecture
presented. These lifetimes appear to be low because the Arduino
board in the prototype uses Ethernet which is not energy efficient.
The values presented only provide an estimate (ignoring the energy
required to transition in and out of the sleep mode) and would vary
depending on the hardware and MAC protocol used. Nonetheless, it is
evident that our architecture can increase the life of smart objects
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 21, line 39 skipping to change at page 20, line 27
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 small
devices. The numbers above give a mixed message. Clearly, an devices. The numbers above give a mixed message. Clearly, an
implementation of a significant cryptographic operation such as implementation of a significant cryptographic operation such as
public key signing can be done in surprisingly small amount of code public key signing can be done in surprisingly small amount of code
space. It could even be argued that our chosen prototype platform space. It could even be argued that our chosen prototype platform
was unnecessarily restrictive in the amount of code space it allows: was unnecessarily restrictive in the amount of code space it allows:
we chose this platform on purpose to demonstrate something that is as we chose this platform on purpose to demonstrate something that is as
small and difficult as possible. small and difficult as possible.
In reality, ROM memory size is probably easier to grow than other A recent trend in microcontrollers is the introduction of 32-bit CPUs
parameters in microcontrollers. A recent trend in microcontrollers that are becoming cheaper and more easily available than 8-bit CPUs,
is the introduction of 32-bit CPUs that are becoming cheaper and more in addition to being more easily programmable. The flash memory size
easily available than 8-bit CPUs, in addition to being more easily is probably easier to grow than other parameters in microcontrollers.
programmable. In short, the authors do not expect the code size to The authors do not expect the flash memory size to be the most
be a significant limiting factor, both because of the small amount of significant limiting factor. Before picking a platform, developers
code that is needed and because available memory space is growing should also plan for firmware updates. This would essentially mean
rapidly. that the platform should at least have a flash memory size of the
total code size * 2, 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 for the
computation of a signature for the message that it is about to send. computation of a signature for the message that it is about to send.
Or even spend multiple seconds in some cases. Most applications that Or even spend multiple seconds in some cases. Most applications that
use protocols such as DTLS that use public key cryptography only at use protocols such as DTLS that use public key cryptography only at
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.
skipping to change at page 26, line 28 skipping to change at page 25, line 18
sufficient advantages over the more commonly implemented transport sufficient advantages over the more commonly implemented transport
and application layer solutions. and application layer solutions.
14. Symmetric vs. Asymmetric Crypto 14. Symmetric vs. Asymmetric Crypto
The second trade-off that is worth discussing is the use of plain The second trade-off that is worth discussing is the use of plain
asymmetric cryptographic mechanisms, plain symmetric cryptographic asymmetric cryptographic mechanisms, plain symmetric cryptographic
mechanisms, or some mixture thereof. mechanisms, or some mixture thereof.
Contrary to popular cryptographic community beliefs, a symmetric Contrary to popular cryptographic community beliefs, a symmetric
crypto solution can be deployed in large scale. In fact, one of the cryptographic solution can be deployed in large scale. In fact, one
largest deployment of cryptographic security, the cellular network of the largest deployment of cryptographic security, the cellular
authentication system, uses SIM cards that are based on symmetric network authentication system, uses SIM cards that are based on
secrets. In contrast, public key systems have yet to show ability to symmetric secrets. In contrast, public key systems have yet to show
scale to hundreds of millions of devices, let alone billions. But ability to scale to hundreds of millions of devices, let alone
the authors do not believe scaling is an important differentiator billions. But the authors do not believe scaling is an important
when comparing the solutions. differentiator when comparing the solutions.
As can be seen from the Section 8, the time needed to calculate some As can be seen from the Section 8, the time needed to calculate some
of the asymmetric crypto operations with reasonable key lengths can of the asymmetric cryptographic operations with reasonable key
be significant. There are two contrary observations that can be made lengths can be significant. There are two contrary observations that
from this. First, recent wisdom indicates that computing power on can be made from this. First, recent wisdom indicates that computing
small devices is far cheaper than transmission power [wiman], and power on small devices is far cheaper than transmission power
keeps on becoming more efficient very quickly. From this we can [wiman], and keeps on becoming more efficient very quickly. From
conclude that the sufficient CPU is or at least will be easily this we can conclude that the sufficient CPU is or at least will be
available. 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.
15. Security Considerations 15. Security Considerations
skipping to change at page 27, line 19 skipping to change at page 26, line 11
16. IANA Considerations 16. IANA Considerations
There are no IANA impacts in this memo. There are no IANA impacts in this memo.
17. Informative references 17. Informative references
[arduino-uno] [arduino-uno]
Arduino, "Arduino Uno", September 2015, Arduino, "Arduino Uno", September 2015,
<http://arduino.cc/en/Main/arduinoBoardUno>. <http://arduino.cc/en/Main/arduinoBoardUno>.
[armecdsa]
Tschofenig, H. and M. Pegourie-Gonnard, "Performance
Investigations", March 2015,
<https://www.ietf.org/proceedings/92/slides/slides-92-
lwig-3.pdf>.
[avr-crypto-lib] [avr-crypto-lib]
AVR-CRYPTO-LIB, "AVR-CRYPTO-LIB", September 2015, AVR-CRYPTO-LIB, "AVR-CRYPTO-LIB", September 2015,
<http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>. <http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>.
[avr-cryptolib] [avr-cryptolib]
Van der Laan, E., "AVR CRYPTOLIB", September 2015, 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]
NXP, "Freescale FRDM-KL25Z", June 2017,
<https://developer.mbed.org/platforms/KL25Z/>.
[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 8 skipping to change at page 27, line 8
[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-00 (work in (CoAP)", draft-ietf-core-coap-pubsub-02 (work in
progress), October 2016. progress), July 2017.
[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., Stok, P., and C.
Resource Directory", draft-ietf-core-resource-directory-09 Amsuess, "CoRE Resource Directory", draft-ietf-core-
(work in progress), October 2016. resource-directory-11 (work in progress), July 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-04 (work in progress), (SenML)", draft-ietf-core-senml-10 (work in progress),
October 2016. July 2017.
[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, "State-of-
Considerations in the IP-based Internet of Things", draft- the-Art and Challenges for the Internet of Things
irtf-t2trg-iot-seccons-00 (work in progress), October Security", draft-irtf-t2trg-iot-seccons-04 (work in
2016. progress), June 2017.
[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.
[matrix-ssl] [matrix-ssl]
PeerSec Networks, "Matrix SSL", September 2015, PeerSec Networks, "Matrix SSL", September 2015,
<http://www.matrixssl.org/>. <http://www.matrixssl.org/>.
[mbed] ARM, "mbed TLS", May 2017,
<https://www.mbed.com/en/technologies/security/mbed-tls/>.
[micronacl] [micronacl]
MicroNaCl, "The Networking and Cryptography library for MicroNaCl, "The Networking and Cryptography library for
microcontrollers", <http://munacl.cryptojedi.org/>. microcontrollers", <http://munacl.cryptojedi.org/>.
[mosdorf] Mosdorf, M. and W. Zabolotny, "Implementation of elliptic [mosdorf] Mosdorf, M. and W. Zabolotny, "Implementation of elliptic
curve cryptography for 8 bit and 32 bit embedded systems curve cryptography for 8 bit and 32 bit embedded systems
time efficiency and power consumption analysis", Pomiary time efficiency and power consumption analysis", Pomiary
Automatyka Kontrola , 2010. Automatyka Kontrola , 2010.
[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.
[nordic] Nordic Semiconductor, "nRF52832 Product Specification",
June 2017, <http://infocenter.nordicsemi.com/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
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>. <http://www.rfc-editor.org/info/rfc3748>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
skipping to change at page 30, line 22 skipping to change at page 29, line 22
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object
Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012,
<http://www.rfc-editor.org/info/rfc6574>. <http://www.rfc-editor.org/info/rfc6574>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>. <http://www.rfc-editor.org/info/rfc6690>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <http://www.rfc-editor.org/info/rfc7252>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>. 2014, <http://www.rfc-editor.org/info/rfc7296>.
skipping to change at page 31, line 10 skipping to change at page 30, line 15
[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 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<http://www.rfc-editor.org/info/rfc8032>. <http://www.rfc-editor.org/info/rfc8032>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<http://www.rfc-editor.org/info/rfc8152>.
[rsa-8bit] [rsa-8bit]
Gura, N., Patel, A., Wander, A., Eberle, H., and S. Gura, N., Patel, A., Wander, A., Eberle, H., and S.
Shantz, "Comparing Elliptic Curve Cryptography and RSA on Shantz, "Comparing Elliptic Curve Cryptography and RSA on
8-bit CPUs", 2010. 8-bit CPUs", 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>.
[stnucleo]
STMicroelectronics, "NUCLEO-F091RC", June 2017,
<http://www.st.com/en/evaluation-tools/
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/>.
[truerandom]
Drow, C., "Truerandom", September 2015,
<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.", 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,
 End of changes. 65 change blocks. 
318 lines changed or deleted 290 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/