Light-Weight Implementation Guidance M. Sethi
Internet-Draft J. Arkko
Intended status: Informational A. Keranen
Expires: January 26, 2018 Ericsson
H. Back
Comptel
July 25, 2017
Practical Considerations and Implementation Experiences in Securing
Smart Object Networks
draft-ietf-lwig-crypto-sensors-03
Abstract
This memo describes challenges associated with securing resource-
constrained smart object devices. The memo describes a possible
deployment model suitable for these environments, discusses the
availability of cryptographic libraries for small devices, and
presents some preliminary experiences in implementing cryptography on
small devices using those libraries. Lastly, the memo discusses
trade-offs involving different types of security approaches.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 26, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Sethi, et al. Expires January 26, 2018 [Page 1]
Internet-Draft Smart Object Security Experiences July 2017
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5
5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8
7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 9
8. Implementation Experiences . . . . . . . . . . . . . . . . . 10
9. Example Application . . . . . . . . . . . . . . . . . . . . . 17
10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 20
11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 20
12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 21
13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 23
14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 25
15. Security Considerations . . . . . . . . . . . . . . . . . . . 25
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
17. Informative references . . . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
This memo describes challenges associated with securing smart object
devices in constrained implementations and environments. In
Section 3 we specifically discuss three challenges: the
implementation difficulties encountered on resource-constrained
platforms, the problem of provisioning keys and making the choice of
implementing security at the appropriate layer.
Section 4 discusses a deployment model that the authors are
considering for constrained environments. The model requires minimal
amount of configuration, and we believe it is a natural fit with the
typical communication practices in smart object networking
environments.
Section 7 discusses the availability of cryptographic libraries.
Section 8 presents some experiences in implementing cryptography on
small devices using those libraries, including information about
achievable code sizes and speeds on typical hardware.
Sethi, et al. Expires January 26, 2018 [Page 2]
Internet-Draft Smart Object Security Experiences July 2017
Finally, Section 10 discusses trade-offs involving different types of
security approaches.
2. Related Work
Constrained Application Protocol (CoAP) [RFC7252] is a light-weight
protocol designed to be used in machine-to-machine applications such
as smart energy and building automation. Our discussion uses this
protocol as an example, but the conclusions may apply to other
similar protocols. CoAP base specification [RFC7252] outlines how to
use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol.
DTLS can be applied with pairwise shared keys, raw public keys or
with certificates. The security model in all cases is mutual
authentication, so while there is some commonality to HTTP [RFC7230]
in verifying the server identity, in practice the models are quite
different. The use of IPsec with CoAP is described with regards to
the protocol requirements, noting that small implementations of IKEv2
exist [RFC7815]. However, the CoAP specification is silent on policy
and other aspects that are normally necessary in order to implement
interoperable use of IPsec in any environment [RFC5406].
[RFC6574] gives an overview of the security discussions at the March
2011 IAB workshop on smart objects. The workshop recommended that
additional work is needed in developing suitable credential
management mechanisms (perhaps something similar to the Bluetooth
pairing mechanism), understanding the implementability of standard
security mechanisms in small devices, and additional research in the
area of lightweight cryptographic primitives.
[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
algorithms, Elliptic Curve Cryptography (ECC), and eliminates hash
functions. The protocol still operates based on host identities, and
runs end-to-end between hosts, protecting all IP layer
communications. [RFC6078] describes an extension of HIP that can be
used to send upper layer protocol messages without running the usual
HIP base exchange at all.
[I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis
of security issues related to 6LoWPAN networks, but its findings also
apply more generally for all low-powered networks. Some of the
issues this document discusses include the need to minimize the
number of transmitted bits and simplify implementations, threats in
the smart object networking environments, and the suitability of
6LoWPAN security mechanisms, IPsec, and key management protocols for
implementation in these environments.
Sethi, et al. Expires January 26, 2018 [Page 3]
Internet-Draft Smart Object Security Experiences July 2017
[I-D.irtf-t2trg-iot-seccons] discusses the overall security problem
for Internet of Things devices. It also discusses various solutions,
including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347],
HIP [RFC7401] [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP
[RFC3748]. The draft also discusses various operational scenarios,
and challenges associated with implementing security mechanisms in
these environments.
[I-D.sarikaya-t2trg-sbootstrapping] discusses bootstrapping
mechanisms available for resource-constrained IoT devices.
3. Challenges
This section discusses three challenges: 1) implementation
difficulties, 2) practical provisioning problems, 3) layering and
communication models.
One of the most often discussed issues in the security for the
Internet of Things relate to implementation difficulties. The desire
to build small, battery-operated, and inexpensive devices drives the
creation of devices with a limited protocol and application suite.
Some of the typical limitations include running CoAP instead of HTTP,
limited support for security mechanisms, limited processing power for
long key lengths, sleep schedule that does not allow communication at
all times, and so on. In addition, the devices typically have very
limited support for configuration, making it hard to set up secrets
and trust anchors.
The implementation difficulties are important, but they should not be
overemphasized. It is important to select the right security
mechanisms and avoid duplicated or unnecessary functionality. But at
the end of the day, if strong cryptographic security is needed, the
implementations have to support that. It is important for developers
and product designers to determine what security threats they want to
tackle and the resulting security requirements before selecting the
hardware. Often, development work in the wild happens in the wrong
order: a particular platform with a resource-constrained
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.
These are perhaps the most fundamental and difficult issue, and
Sethi, et al. Expires January 26, 2018 [Page 4]
Internet-Draft Smart Object Security Experiences July 2017
unfortunately often neglected in the design. There are several
problems in the provisioning and management of smart object networks:
o Small devices have no natural user interface for configuration
that would be required for the installation of shared secrets and
other security-related parameters. Typically, there is no
keyboard, no display, and there may not even be buttons to press.
Some devices may only have one interface, the interface to the
network.
o Manual configuration is rarely, if at all, possible, as the
necessary skills are missing in typical installation environments
(such as in family homes).
o There may be a large number of devices. Configuration tasks that
may be acceptable when performed for one device may become
unacceptable with dozens or hundreds of devices.
o Network configurations evolve over the lifetime of the devices, as
additional devices are introduced or addresses change. Various
central nodes may also receive more frequent updates than
individual devices such as sensors embedded in building materials.
Finally, layering and communication models present difficulties for
straightforward use of the most obvious security mechanisms. Smart
object networks typically pass information through multiple
participating nodes [I-D.arkko-core-sleepy-sensors] and end-to-end
security for IP or transport layers may not fit such communication
models very well. The primary reasons for needing middleboxes
relates to the need to accommodate for sleeping nodes as well to
enable the implementation of nodes that store or aggregate
information.
4. Proposed Deployment Model
[I-D.arkko-core-security-arch] recognizes the provisioning model as
the driver of what kind of security architecture is useful. This
section re-introduces this model briefly here in order to facilitate
the discussion of the various design alternatives later.
The basis of the proposed architecture are self-generated secure
identities, similar to Cryptographically Generated Addresses (CGAs)
[RFC3972] or Host Identity Tags (HITs) [RFC7401]. That is, we assume
the following holds:
I = h(P|O)
Sethi, et al. Expires January 26, 2018 [Page 5]
Internet-Draft Smart Object Security Experiences July 2017
where I is the secure identity of the device, h is a hash function, P
is the public key from a key pair generated by the device, and O is
optional other information. | here denotes the concatenation
operator.
5. Provisioning
As it is difficult to provision security credentials, shared secrets,
and policy information, the provisioning model is based only on the
secure identities. A typical network installation involves physical
placement of a number of devices while noting the identities of these
devices. This list of short identifiers can then be fed to a central
server as a list of authorized devices. Secure communications can
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
for sensor networks.
The above architecture is a perfect fit for sensor networks where
information flows from large number of devices to small number of
servers. But it is not sufficient alone for other types of
applications. For instance, in actuator applications a large number
of devices need to take commands from somewhere else. In such
applications it is necessary to secure that the commands come from an
authorized source.
This can be supported, with some additional provisioning effort and
optional pairing protocols. The basic provisioning approach is as
described earlier, but in addition there must be something that
informs the devices of the identity of the trusted server(s). There
are multiple ways to provide this information. One simple approach
is to feed the identities of the trusted server(s) to devices at
installation time. This requires either a separate user interface,
local connection (such as USB), or using the network interface of the
device for configuration. In any case, as with sensor networks the
amount of configuration information is minimized: just one short
identity value needs to be fed in. Not both an identity and a
certificate. Not shared secrets that must be kept confidential. An
even simpler provisioning approach is that the devices in the device
group trust each other. Then no configuration is needed at
installation time.
When both peers know the expected cryptographic identity of the other
peer off-line, secure communications can commence. Alternatively,
various pairing schemes can be employed. Note that these schemes can
benefit from the already secure identifiers on the device side. For
instance, the server can send a pairing message to each device after
their initial power-on and before they have been paired with anyone,
encrypted with the public key of the device. As with all pairing
Sethi, et al. Expires January 26, 2018 [Page 6]
Internet-Draft Smart Object Security Experiences July 2017
schemes that do not employ a shared secret or the secure identity of
both parties, there are some remaining vulnerabilities that may or
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
also include other parameters relevant to the application, such as
the location or purpose of the devices. This would enable the server
to know, for instance, that a particular device is the temperature
sensor for the kitchen.
Collecting the identity information at installation time can be
arranged in a number of ways. The authors have employed a simple but
not completely secure method where the last few digits of the
identity are printed on a tiny device just a few millimeters across.
Alternatively, the packaging for the device may include the full
identity (typically 32 hex digits), retrieved from the device at
manufacturing time. This identity can be read, for instance, by a
bar code reader carried by the installation personnel. (Note that
the identities are not secret, the security of the system is not
dependent on the identity information leaking to others. The real
owner of an identity can always prove its ownership with the private
key which never leaves the device.) Finally, the device may use its
wired network interface or proximity-based communications, such as
Near-Field Communications (NFC) or Radio-Frequency Identity tags
(RFIDs). Such interfaces allow secure communication of the device
identity to an information gathering device at installation time.
No matter what the method of information collection is, this
provisioning model minimizes the effort required to set up the
security. Each device generates its own identity in a random, secure
key generation process. The identities are self-securing in the
sense that if you know the identity of the peer you want to
communicate with, messages from the peer can be signed by the peer's
private key and it is trivial to verify that the message came from
the expected peer. There is no need to configure an identity and
certificate of that identity separately. There is no need to
configure a group secret or a shared secret. There is no need to
configure a trust anchor. In addition, the identities are typically
collected anyway for application purposes (such as identifying which
sensor is in which room). Under most circumstances there is actually
no additional configuration effort from provisioning security.
Sethi, et al. Expires January 26, 2018 [Page 7]
Internet-Draft Smart Object Security Experiences July 2017
Groups of devices can be managed through single identifiers as well.
In these deployment cases it is also possible to configure the
identity of an entire group of devices, rather than registering the
individual devices. For instance, many installations employ a kit of
devices bought from the same manufacturer in one package. It is easy
to provide an identity for such a set of devices as follows:
Idev = h(Pdev|Potherdev1|Potherdev2|...|Potherdevn)
Igrp = h(Pdev1|Pdev2|...|Pdevm)
where Idev is the identity of an individual device, Pdev is the
public key of that device, and Potherdevi are the public keys of
other devices in the group. Now, we can define the secure identity
of the group (Igrp) as a hash of all the public keys of the devices
in the group (Pdevi).
The installation personnel can scan the identity of the group from
the box that the kit came in, and this identity can be stored in a
server that is expected to receive information from the nodes. Later
when the individual devices contact this server, they will be able to
show that they are part of the group, as they can reveal their own
public key and the public keys of the other devices. Devices that do
not belong to the kit can not claim to be in the group, because the
group identity would change if any new keys were added to Igrp.
6. Protocol Architecture
As noted above, the starting point of the architecture is that nodes
self-generate secure identities which are then communicated out-of-
band to the peers that need to know what devices to trust. To
support this model in a protocol architecture, we also need to use
these secure identities to implement secure messaging between the
peers, explain how the system can respond to different types of
attacks such as replay attempts, and decide at what protocol layer
and endpoints the architecture should use.
The deployment itself is suitable for a variety of design choices
regarding layering and protocol mechanisms.
[I-D.arkko-core-security-arch] was mostly focused on employing end-
to-end data object security as opposed to hop-by-hop security. But
other approaches are possible. For instance, HIP in its
opportunistic mode could be used to implement largely the same
functionality at the IP layer. However, it is our belief that the
right layer for this solution is at the application layer. More
specifically, in the data formats transported in the payload part of
CoAP. This approach provides the following benefits:
Sethi, et al. Expires January 26, 2018 [Page 8]
Internet-Draft Smart Object Security Experiences July 2017
o Ability for intermediaries to act as caches to support different
sleep schedules, without the security model being impacted.
o Ability for intermediaries to be built to perform aggregation,
filtering, storage and other actions, again without impacting the
security of the data being transmitted or stored.
o Ability to operate in the presence of traditional middleboxes,
such as a protocol translators or even NATs (not that we recommend
their use in these environments).
However, as we will see later there are also some technical
implications, namely that link, network, and transport layer
solutions are more likely to be able to benefit from sessions where
the cost of expensive operations can be amortized over multiple data
transmissions. While this is not impossible in data object security
solutions either, it is not the typical arrangement either.
7. Code Availability
For implementing public key cryptography on resource constrained
environments, we chose Arduino Uno board [arduino-uno] as the test
platform. Arduino Uno has an ATmega328 microcontroller, an 8-bit
processor with a clock speed of 16 MHz, 2 kB of RAM, and 32 kB of
flash memory. Our choice of 8-bit platform may be surprising since
it.
For selecting potential asymmetric cryptographic libraries, we
surveyed and came up with a set of possible code sources, and
performed an initial analysis of how well they fit the Arduino
environment. Note that the results are preliminary, and could easily
be affected in any direction by implementation bugs, configuration
errors, and other mistakes. It is advisable to verify the numbers
before relying on them for building something. No significant effort
was done to optimize ROM memory usage beyond what the libraries
provided themselves, so those numbers should be taken as upper
limits.
Here is the set of libraries we found:
o AvrCryptolib [avr-cryptolib]: This library provides a variety of
different symmetric key algorithms such as AES, triple DES and
SkipJack. It provides RSA as an asymmetric key algorithm. Parts
of the library were written in AVR-8 bit assembly language to
reduce the size and optimize the performance.
o Relic-Toolkit [relic-toolkit]: This library is written entirely in
C and provides a highly flexible and customizable implementation
Sethi, et al. Expires January 26, 2018 [Page 9]
Internet-Draft Smart Object Security Experiences July 2017
of a large variety of cryptographic algorithms. This not only
includes RSA and ECC, but also pairing based asymmetric
cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures
and many more. The toolkit provides an option to build only the
desired components for the required platform.
o TinyECC [tinyecc]: TinyECC was designed for using elliptic curve
based public key cryptography on sensor networks. It is written
in nesC programming language and as such is designed for specific
use on TinyOS. However, the library can be ported to standard C
either with tool-chains or manually rewriting parts of the code.
It also has one of the smallest memory footprints among the set of
elliptic curve libraries surveyed so far.
o Wiselib [wiselib]: Wiselib is a generic library written for sensor
networks containing a wide variety of algorithms. While the
stable version contains algorithms for routing only, the test
version includes many more algorithms including algorithms for
cryptography, localization, topology management and many more.
The library was designed with the idea of making it easy to
interface the library with operating systems like iSense and
Contiki. However, since the library is written entirely in C++
with a template based model similar to Boost/CGAL, it can be used
on any platform directly without using any of the operating system
interfaces provided. This approach was taken by the authors to
test the code on Arduino Uno.
o MatrixSSL [matrix-ssl]: This library provides a low footprint
implementation of several cryptographic algorithms including RSA
and ECC (with a commercial license). The library in the original
form takes about 50 kB of ROM and is intended for 32-bit
platforms.
o ARM mbed OS [mbed]: The ARM mbed operating system provides various
cryptographic primitives that are necessary for SSL/TLS protocol
implementation as well as X509 certificate handling. The library
provides an intuitive API for developer with a minimal code
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
cryptographic libraries targeting resource-constrained devices.
8. Implementation Experiences
While evaluating the implementation experiences, we were particularly
interested in the signature generation operation. This was because
our example application discussed in Section 9 required only the
Sethi, et al. Expires January 26, 2018 [Page 10]
Internet-Draft Smart Object Security Experiences July 2017
signature generation operation on the resource-constrained platforms.
We have summarized the initial results of RSA private key
exponentiation performance using AvrCryptolib [avr-crypto-lib] in
Table 1. All results are from a single run since repeating the test
did not change (or had only minimal impact on) the results. The
execution time for a key size of 2048 bits was inordinately long and
would be a deterrent in real-world deployments.
+--------------+------------------------+---------------------------+
| Key length | Execution time (ms); | Memory footprint (bytes); |
| (bits) | key in RAM | key in RAM |
+--------------+------------------------+---------------------------+
| 2048 | 1587567 | 1,280 |
+--------------+------------------------+---------------------------+
RSA private key operation performance
Table 1
The code size was about 3.6 kB with potential for further reduction.
It is also worth noting that the implementation performs basic
exponentiation and multiplication operations without using any
mathematical optimizations such as Montgomery multiplication,
optimized squaring, etc. as described in [rsa-high-speed]. With more
RAM, we believe that 2048-bit operations can be performed in much
less time as has been shown in [rsa-8bit].
In Table 2 we present the results obtained by manually porting
TinyECC into C99 standard and running ECDSA signature algorithm on
the Arduino Uno board. TinyECC supports a variety of SEC 2
recommended Elliptic Curve domain parameters. The execution time and
memory footprint are shown next to each of the curve parameters.
These results were obtained by turning on all the optimizations and
using assembly code where available. It is clearly observable that
for similar security levels, Elliptic Curve public key cryptography
outperforms RSA.
Sethi, et al. Expires January 26, 2018 [Page 11]
Internet-Draft Smart Object Security Experiences July 2017
+-------------+---------------+-----------------+-------------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | Footprint | key length |
| | | (bytes) | |
+-------------+---------------+-----------------+-------------------+
| secp160k1 | 2228 | 892 | 1024 |
| secp160r1 | 2250 | 892 | 1024 |
| secp160r2 | 2467 | 892 | 1024 |
| secp192k1 | 3425 | 1008 | 1536 |
| secp192r1 | 3578 | 1008 | 1536 |
+-------------+---------------+-----------------+-------------------+
Performance of ECDSA sign operation with TinyECC
Table 2
We also performed experiments by removing the assembly optimization
and using a C only form of the library. This gives us an idea of the
performance that can be achieved with TinyECC on any platform
regardless of what kind of OS and assembly instruction set available.
The memory footprint remains the same with or without assembly code.
The tables contain the maximum RAM that is used when all the possible
optimizations are on. If however, the amount of RAM available is
smaller in size, some of the optimizations can be turned off to
reduce the memory consumption accordingly.
+-------------+---------------+-----------------+-------------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | Footprint | key length |
| | | (bytes) | |
+-------------+---------------+-----------------+-------------------+
| secp160k1 | 3795 | 892 | 1024 |
| secp160r1 | 3841 | 892 | 1024 |
| secp160r2 | 4118 | 892 | 1024 |
| secp192k1 | 6091 | 1008 | 1536 |
| secp192r1 | 6217 | 1008 | 1536 |
+-------------+---------------+-----------------+-------------------+
Performance of ECDSA sign operation with TinyECC (No assembly
optimizations)
Table 3
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
results. By default Wiselib only supports some of the standard SEC 2
Elliptic curves, but it is easy to change the domain parameters and
Sethi, et al. Expires January 26, 2018 [Page 12]
Internet-Draft Smart Object Security Experiences July 2017
obtain results for for all the 128, 160 and 192-bit SEC 2 Elliptic
curves. The ROM size for all the experiments was less than 16 kB.
+-------------+---------------+-----------------+-------------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | Footprint | key length |
| | | (bytes) | |
+-------------+---------------+-----------------+-------------------+
| secp160k1 | 10957 | 842 | 1024 |
| secp160r1 | 10972 | 842 | 1024 |
| secp160r2 | 10971 | 842 | 1024 |
| secp192k1 | 18814 | 952 | 1536 |
| secp192r1 | 18825 | 952 | 1536 |
+-------------+---------------+-----------------+-------------------+
Performance ECDSA sign operation with Wiselib
Table 4
For testing the relic-toolkit we used a different board because it
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
same 8-bit architecture like the Arduino Uno but has a much larger
RAM/ROM for testing relic-toolkit. Again, it is important to mention
that we used Arduino as it is a convenient prototyping platform. Our
intention was to demonstrate the feasibility of the entire
architecture with public key cryptography on an 8-bit
microcontroller. However it is important to state that 32-bit
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
binary fields. We have experimented with Koblitz curves over binary
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
which curves perform the fastest, and rather show that asymmetric
cryptography is possible on resource-constrained devices.
The results from relic-toolkit are documented in two separate tables
shown in Table 5 and Table 6. The first set of results were
performed with the library configured for high speed performance with
no consideration given to the amount of memory used. For the second
set, the library was configured for low memory usage irrespective of
the execution time required by different curves. By turning on/off
Sethi, et al. Expires January 26, 2018 [Page 13]
Internet-Draft Smart Object Security Experiences July 2017
optimizations included in the library, a trade-off between memory and
execution time between these values can be achieved.
+-----------------+--------------+----------------+-----------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | Footprint | key length |
| | | (bytes) | |
+-----------------+--------------+----------------+-----------------+
| NIST K163 | 261 | 2,804 | 1024 |
| (assembly math) | | | |
| NIST K163 | 932 | 2750 | 1024 |
| NIST B163 | 2243 | 2444 | 1024 |
| NIST K233 | 1736 | 3675 | 2048 |
| NIST B233 | 4471 | 3261 | 2048 |
+-----------------+--------------+----------------+-----------------+
Performance of ECDSA sign operation with relic-toolkit (Fast)
Table 5
+-----------------+--------------+----------------+-----------------+
| Curve | Execution | Memory | Comparable RSA |
| parameters | time (ms) | Footprint | key length |
| | | (bytes) | |
+-----------------+--------------+----------------+-----------------+
| NIST K163 | 592 | 2087 | 1024 |
| (assembly math) | | | |
| NIST K163 | 2950 | 2215 | 1024 |
| NIST B163 | 3213 | 2071 | 1024 |
| NIST K233 | 6450 | 2935 | 2048 |
| NIST B233 | 6100 | 2737 | 2048 |
+-----------------+--------------+----------------+-----------------+
Performance of ECDSA sign operation with relic-toolkit (Low Memory)
Table 6
It is important to note the following points about the elliptic curve
measurements:
o The Arduino board only provides pseudo random numbers with the
random() function call. Real-world deployments must rely on a
hardware random number generator for cryptographic operations such
as generating a public-private key pair. The Nordic nRF52832
board [nordic] for example provides a hardware random number
generator.
Sethi, et al. Expires January 26, 2018 [Page 14]
Internet-Draft Smart Object Security Experiences July 2017
o For measuring the memory footprint of all the ECC libraries, we
used the Avrora simulator [avrora]. Only stack memory was used to
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.
Sethi, et al. Expires January 26, 2018 [Page 15]
Internet-Draft Smart Object Security Experiences July 2017
+------------------+---------------------+--------------------------+
| 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
unclear which exact elliptic curve(s) would be selected by the IETF
community for use with resource-constrained devices. However now,
[RFC7748] defines two elliptic curves over prime fields (Curve25519
and Curve448) that offer a high level of practical security for
Diffie-Hellman key exchange. Correspondingly, there is ongoing work
to specify elliptic curve signature schemes with Edwards-curve
Digital Signature Algorithm (EdDSA). [RFC8032] specifies the
recommended parameters for the edwards25519 and edwards448 curves.
From these, curve25519 (for elliptic curve Diffie-Hellman key
exchange) and edwards25519 (for elliptic curve digital signatures)
are especially suitable for resource-constrained devices.
We found that the NaCl [nacl] and MicoNaCl [micronacl] libraries
provide highly efficient implementations of Diffie-Hellman key
exchange with curve25519. The results have shown that these
libraries with curve25519 outperform other elliptic curves that
provide similar levels of security. Hutter and Schwabe [naclavr]
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
we used for our evaluations (Arduino Mega ATmega2560). This
corresponds to about 14510 milliseconds of execution time. When
Sethi, et al. Expires January 26, 2018 [Page 16]
Internet-Draft Smart Object Security Experiences July 2017
compared to the results for other curves and libraries that offer
similar level of security (such as NIST B233, NIST K233), this
implementation far outperforms all others. As such, it is recommend
that the IETF community uses these curves for protocol specification
and implementations.
A summary library flash memory use is shown in Table 9.
+------------------------+------------------------------------+
| Library | Flash memory Footprint (Kilobytes) |
+------------------------+------------------------------------+
| AvrCryptolib | 3.6 |
| Wiselib | 16 |
| TinyECC | 18 |
| Relic-toolkit | 29 |
| NaCl Ed25519 [naclavr] | 17-29 |
+------------------------+------------------------------------+
Summary of library flash memory consumption
Table 9
All the measurements here are only provided as an example to show
that asymmetric-key cryptography (particularly, digital signatures)
is possible on resource-constrained devices. These numbers by no way
are the final source for measurements and some curves presented here
may not be acceptable for real in-the-wild deployments anymore. For
example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also
document performance of ECDSA on similar resource-constrained
devices.
9. Example Application
We developed an example application on the Arduino platform to use
public key crypto mechanisms, data object security, and an easy
provisioning model. Our application was originally developed to test
different approaches to supporting communications to "always off"
sensor nodes. These battery-operated or energy scavenging nodes do
not have enough power to be stay on at all times. They wake up
periodically and transmit their readings.
Such sensor nodes can be supported in various ways.
[I-D.arkko-core-sleepy-sensors] was an early multicast-based
approach. In the current application we have switched to using
resource directories [I-D.ietf-core-resource-directory] and publish-
subscribe brokers [I-D.ietf-core-coap-pubsub] instead.
Architecturally, the idea is that sensors can delegate a part of
their role to a node in the network. Such a network node could be
Sethi, et al. Expires January 26, 2018 [Page 17]
Internet-Draft Smart Object Security Experiences July 2017
either a local resource or something in the Internet. In the case of
CoAP publish-subscribe brokers, the network node agrees to hold the
web resources on behalf of the sensor, while the sensor is asleep.
The only role that the sensor has is to register itself at the
publish-subscribe broker, and periodically update the readings. All
queries from the rest of the world go to the publish-subscribe
broker.
We constructed a system with four entities:
Sensor
This is an Arduino-based device that runs a CoAP publish-subscribe
broker client and Relic-toolkit. Relic takes 29 Kbytes of flash
memory, and the simple CoAP client roughly 3 kilobytes.
Publish-Subscribe Broker
This is a publish-subscribe broker that holds resources on the
sensor's behalf. The sensor registers itself to this node.
Resource Directory
While physically in the same node in our implementation, a
resource directory is a logical function that allows sensors and
publish-subscribe brokers to register resources in the directory.
These resources can be queried by applications.
Application
This is a simple application that runs on a general purpose
computer and can retrieve both registrations from the resource
directory and most recent sensor readings from the publish-
subscribe broker.
The security of this system relies on an SSH-like approach. In Step
1, upon first boot, sensors generate keys and register themselves in
the publish-subscribe broker. Their public key is submitted along
with the registration as an attribute in the CORE Link Format data
[RFC6690].
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
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) [RFC8152] for signing the sensor
measurement.
Sethi, et al. Expires January 26, 2018 [Page 18]
Internet-Draft Smart Object Security Experiences July 2017
In Step 3, any other device in the network -- including the publish-
subscribe broker, resource directory and the application -- can check
that the public key from the registration corresponds to the private
key used to make the signature in the data update.
Note that checks can be done at any time and there is no need for the
sensor and the checking node to be awake at the same time. In our
implementation, the checking is done in the application node. This
demonstrates how it is possible to implement end-to-end security even
with the presence of assisting middleboxes.
To verify the feasibility of our architecture we developed a proof-
of-concept prototype. In our prototype, the sensor was implemented
using the Arduino Ethernet shield over an Arduino Mega board. Our
implementation uses the standard C99 programming language on the
Arduino Mega board. In this prototype, the publish-subscribe broker
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
similar but physically different 64-bit x86 linux machine serves as
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
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
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.
While compiling Relic for our prototype, we used the fast
configuration without any assembly optimizations.
The gateway implements the CoAP base specification in the Java
programming language and extends it to add support for publish-
subscribe broker and Resource Directory REST interfaces. We also
developed a minimalistic CoAP C-library for the Arduino sensor and
for the client requesting data updates for a resource. The library
has small RAM requirements and uses stack-based allocation only. It
is interoperable with the Java implementation of CoAP running on the
gateway. The location of the publish-subscribe broker was configured
into the smart object sensor by hardcoding the IP address.
Our intention was to demonstrate that it is possible to implement the
entire architecture with public-key cryptography on an 8-bit
microcontroller. The stated values can be improved further by a
considerable amount. For example, the flash memory and RAM
consumption is relatively high because some of the Arduino libraries
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
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
Sethi, et al. Expires January 26, 2018 [Page 19]
Internet-Draft Smart Object Security Experiences July 2017
modern development boards have a 32-bit microcontroller since they
are more economical and have better energy efficiency.
10. Design Trade-Offs
This section attempts to make some early conclusions regarding trade-
offs in the design space, based on deployment considerations for
various mechanisms and the relative ease or difficulty of
implementing them. This analysis looks at layering and the choice of
symmetric vs. asymmetric cryptography.
11. Feasibility
The first question is whether using cryptographic security and
asymmetric cryptography in particular is feasible at all on small
devices. The numbers above give a mixed message. Clearly, an
implementation of a significant cryptographic operation such as
public key signing can be done in surprisingly small amount of code
space. It could even be argued that our chosen prototype platform
was unnecessarily restrictive in the amount of code space it allows:
we chose this platform on purpose to demonstrate something that is as
small and difficult as possible.
A recent trend in microcontrollers is the introduction of 32-bit CPUs
that are becoming cheaper and more easily available than 8-bit CPUs,
in addition to being more easily programmable. The flash memory size
is probably easier to grow than other parameters in microcontrollers.
The authors do not expect the flash memory size to be the most
significant limiting factor. Before picking a platform, developers
should also plan for firmware updates. This would essentially mean
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
needed to run the algorithms. The demonstrated speeds are sufficient
for many applications. For instance, a sensor that wakes up every
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.
Or even spend multiple seconds in some cases. Most applications that
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
execution times.
Yet, with reasonably long key sizes the execution times are in the
seconds, dozens of seconds, or even longer. For some applications
this is too long. Nevertheless, the authors believe that these
algorithms can successfully be employed in small devices for the
following reasons:
Sethi, et al. Expires January 26, 2018 [Page 20]
Internet-Draft Smart Object Security Experiences July 2017
o With the right selection of algorithms and libraries, the
execution times can actually be very small (less than 500 ms).
o As discussed in [wiman], in general the power requirements
necessary to send or receive messages are far bigger than those
needed to execute cryptographic operations. While there are newer
radios that significantly lower the energy consumption of sending
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
optimizations will provide a better result than what we arrived at
in this memo.
o Using public key cryptography only at the beginning of a session
will reduce the per-packet processing times significantly.
12. Freshness
In our architecture, if implemented as described thus far, messages
along with their signatures sent from the sensors to the publish-
subscribe broker can be recorded and replayed by an eavesdropper.
The publish-subscribe broker has no mechanism to distinguish
previously received packets from those that are retransmitted by the
sender or replayed by an eavesdropper. Therefore, it is essential
for the smart objects to ensure that data updates include a freshness
indicator. However, ensuring freshness on constrained devices can be
non-trivial because of several reasons which include:
o Communication is mostly unidirectional to save energy.
o Internal clocks might not be accurate and may be reset several
times during the operational phase of the smart object.
o Network time synchronization protocols such as Network Time
Protocol (NTP) [RFC5905] are resource intensive and therefore may
be undesirable in many smart object networks.
There are several different methods that can be used in our
architecture for replay protection. The selection of the appropriate
choice depends on the actual deployment scenario.
Including sequence numbers in signed messages can provide an
effective method of replay protection. The publish-subscribe broker
should verify the sequence number of each incoming message and accept
it only if it is greater than the highest previously seen sequence
number. The publish-subscribe broker drops any packet with a
Sethi, et al. Expires January 26, 2018 [Page 21]
Internet-Draft Smart Object Security Experiences July 2017
sequence number that has already been received or if the received
sequence number is greater than the highest previously seen sequence
number by an amount larger than the preset threshold.
Sequence numbers can wrap-around at their maximum value and,
therefore, it is essential to ensure that sequence numbers are
sufficiently long. However, including long sequence numbers in
packets can increase the network traffic originating from the sensor
and can thus decrease its energy efficiency. To overcome the problem
of long sequence numbers, we can use a scheme similar to that of
Huang [huang], where the sender and receiver maintain and sign long
sequence numbers of equal bit-lengths but they transmit only the
least significant bits.
It is important for the smart object to write the sequence number
into the permanent flash memory after each increment and before it is
included in the message to be transmitted. This ensures that the
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
publish-subscribe broker can still end up in a discordant state where
the sequence number received by the publish-subscribe broker exceeds
the expected sequence number by an amount greater than the preset
threshold. This may happen because of a prolonged network outage or
if the publish-subscribe broker experiences a power failure for some
reason. Therefore it is essential for sensors that normally send
Non-Confirmable data updates to send some Confirmable updates and re-
synchronize with the publish-subscribe broker if a reset message is
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
publish-subscribe broker has no mechanism to determine the time at
which updates were created by the sensor. Moreover, if sequence
numbers are the only freshness indicator used, a malicious
eavesdropper can induce inordinate delays to the communication of
signed updates by buffering messages. It may be important in certain
smart object networks for sensors to send data updates which include
timestamps to allow the publish-subscribe broker to determine the
time when the update was created. For example, when the publish-
subscribe broker is collecting temperature data, it may be necessary
to know when exactly the temperature measurement was made by the
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,
it can be acceptable to make such an assumption. However most
networks are susceptible to packet loss and hostile attacks making
this assumption unsustainable.
Sethi, et al. Expires January 26, 2018 [Page 22]
Internet-Draft Smart Object Security Experiences July 2017
Depending on the hardware used by the smart objects, they may have
access to accurate hardware clocks which can be used to include
timestamps in the signed updates. These timestamps are included in
addition to sequence numbers. The clock time in the smart objects
can be set by the manufacturer or the current time can be
communicated by the publish-subscribe broker during the registration
phase. However, these approaches require the smart objects to either
rely on the long-term accuracy of the clock set by the manufacturer
or to trust the publish-subscribe broker thereby increasing the
potential vulnerability of the system. The smart objects could also
obtain the current time from NTP, but this may consume additional
energy and give rise to security issues discussed in [RFC5905]. The
smart objects could also have access to a mobile network or the
Global Positioning System (GPS), and they can be used obtain the
current time. Finally, if the sensors need to co-ordinate their
sleep cycles, or if the publish-subscribe broker computes an average
or mean of updates collected from multiple smart objects, it is
important for the network nodes to synchronize the time among them.
This can be done by using existing synchronization schemes.
13. Layering
It would be useful to select just one layer where security is
provided at. Otherwise a simple device needs to implement multiple
security mechanisms. While some code can probably be shared across
such implementations (like algorithms), it is likely that most of the
code involving the actual protocol machinery cannot. Looking at the
different layers, here are the choices and their implications:
link layer
This is probably the most common solution today. The biggest
benefits of this choice of layer are that security services are
commonly available (WLAN secrets, cellular SIM cards, etc.) and
that their application protects the entire communications.
The main drawback is that there is no security beyond the first
hop. This can be problematic, e.g., in many devices that
communicate to a server in the Internet. A Withings scale
[Withings], for instance, can support WLAN security but without
some level of end-to-end security, it would be difficult to
prevent fraudulent data submissions to the servers.
Another drawback is that some commonly implemented link layer
security designs use group secrets. This allows any device within
the local network (e.g., an infected laptop) to attack the
communications.
Sethi, et al. Expires January 26, 2018 [Page 23]
Internet-Draft Smart Object Security Experiences July 2017
network layer
There are a number of solutions in this space, and many new ones
and variations thereof being proposed: IPsec, PANA, and so on. In
general, these solutions have similar characteristics to those in
the transport layer: they work across forwarding hops but only as
far as to the next middlebox or application entity. There is
plenty of existing solutions and designs.
Experience has shown that it is difficult to control IP layer
entities from an application process. While this is theoretically
easy, in practice the necessary APIs do not exist. For instance,
most IPsec software has been built for the VPN use case, and is
difficult or impossible to tweak to be used on a per-application
basis. As a result, the authors are not particularly enthusiastic
about recommending these solutions.
transport and application layer
This is another popular solution along with link layer designs.
TLS with HTTP (HTTPS) and DTLS with CoAP are examples of solutions
in this space, and have been proven to work well. These solutions
are typically easy to take into use in an application, without
assuming anything from the underlying OS, and they are easy to
control as needed by the applications. The main drawback is that
generally speaking, these solutions only run as far as the next
application level entity. And even for this case, HTTPS can be
made to work through proxies, so this limit is not unsolvable.
Another drawback is that attacks on link layer, network layer and
in some cases, transport layer, can not be protected against.
However, if the upper layers have been protected, such attacks can
at most result in a denial-of-service. Since denial-of-service
can often be caused anyway, it is not clear if this is a real
drawback.
data object layer
This solution does not protect any of the protocol layers, but
protects individual data elements being sent. It works
particularly well when there are multiple application layer
entities on the path of the data. The authors believe smart
object networks are likely to employ such entities for storage,
filtering, aggregation and other reasons, and as such, an end-to-
end solution is the only one that can protect the actual data.
The downside is that the lower layers are not protected. But
again, as long as the data is protected and checked upon every
Sethi, et al. Expires January 26, 2018 [Page 24]
Internet-Draft Smart Object Security Experiences July 2017
time it passes through an application level entity, it is not
clear that there are attacks beyond denial-of-service.
The main question mark is whether this type of a solution provides
sufficient advantages over the more commonly implemented transport
and application layer solutions.
14. Symmetric vs. Asymmetric Crypto
The second trade-off that is worth discussing is the use of plain
asymmetric cryptographic mechanisms, plain symmetric cryptographic
mechanisms, or some mixture thereof.
Contrary to popular cryptographic community beliefs, a symmetric
cryptographic solution can be deployed in large scale. In fact, one
of the largest deployment of cryptographic security, the cellular
network authentication system, uses SIM cards that are based on
symmetric secrets. In contrast, public key systems have yet to show
ability to scale to hundreds of millions of devices, let alone
billions. But the authors do not believe scaling is an important
differentiator when comparing the solutions.
As can be seen from the Section 8, the time needed to calculate some
of the asymmetric cryptographic operations with reasonable key
lengths can be significant. There are two contrary observations that
can be made from this. First, recent wisdom indicates that computing
power on small devices is far cheaper than transmission power
[wiman], and keeps on becoming more efficient very quickly. From
this we can conclude that the sufficient CPU is or at least will be
easily available.
But the other observation is that when there are very costly
asymmetric operations, doing a key exchange followed by the use of
generated symmetric keys would make sense. This model works very
well for DTLS and other transport layer solutions, but works less
well for data object security, particularly when the number of
communicating entities is not exactly two.
15. Security Considerations
This entire memo deals with security issues.
16. IANA Considerations
There are no IANA impacts in this memo.
Sethi, et al. Expires January 26, 2018 [Page 25]
Internet-Draft Smart Object Security Experiences July 2017
17. Informative references
[arduino-uno]
Arduino, "Arduino Uno", September 2015,
<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", September 2015,
<http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>.
[avr-cryptolib]
Van der Laan, E., "AVR CRYPTOLIB", September 2015,
<http://www.emsign.nl/>.
[avrora] Titzer, Ben., "Avrora", September 2015,
<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
networks", 2008.
[I-D.arkko-core-security-arch]
Arkko, J. and A. Keranen, "CoAP Security Architecture",
draft-arkko-core-security-arch-00 (work in progress), July
2011.
[I-D.arkko-core-sleepy-sensors]
Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
Novo, "Implementing Tiny COAP Sensors", draft-arkko-core-
sleepy-sensors-01 (work in progress), July 2011.
[I-D.daniel-6lowpan-security-analysis]
Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J.
Laganier, "IPv6 over Low Power WPAN Security Analysis",
draft-daniel-6lowpan-security-analysis-05 (work in
progress), March 2011.
Sethi, et al. Expires January 26, 2018 [Page 26]
Internet-Draft Smart Object Security Experiences July 2017
[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-02 (work in
progress), July 2017.
[I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-11 (work in progress), July 2017.
[I-D.ietf-core-senml]
Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Media Types for Sensor Measurement Lists
(SenML)", draft-ietf-core-senml-10 (work in progress),
July 2017.
[I-D.irtf-t2trg-iot-seccons]
Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of-
the-Art and Challenges for the Internet of Things
Security", draft-irtf-t2trg-iot-seccons-04 (work in
progress), June 2017.
[I-D.moskowitz-hip-dex]
Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)",
draft-moskowitz-hip-dex-05 (work in progress), January
2016.
[I-D.sarikaya-t2trg-sbootstrapping]
Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT
Bootstrapping: A Survey", draft-sarikaya-t2trg-
sbootstrapping-03 (work in progress), February 2017.
[matrix-ssl]
PeerSec Networks, "Matrix SSL", September 2015,
<http://www.matrixssl.org/>.
[mbed] ARM, "mbed TLS", May 2017,
<https://www.mbed.com/en/technologies/security/mbed-tls/>.
[micronacl]
MicroNaCl, "The Networking and Cryptography library for
microcontrollers", <http://munacl.cryptojedi.org/>.
[mosdorf] Mosdorf, M. and W. Zabolotny, "Implementation of elliptic
curve cryptography for 8 bit and 32 bit embedded systems
time efficiency and power consumption analysis", Pomiary
Automatyka Kontrola , 2010.
Sethi, et al. Expires January 26, 2018 [Page 27]
Internet-Draft Smart Object Security Experiences July 2017
[nacl] NaCl, "Networking and Cryptography library",
<http://nacl.cr.yp.to/>.
[naclavr] Hutter, M. and P. Schwabe, "NaCl on 8-Bit AVR
Microcontrollers", International Conference on Cryptology
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]
Aranha, D. and C. Gouv, "Relic Toolkit", September 2015,
<http://code.google.com/p/relic-toolkit/>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <http://www.rfc-editor.org/info/rfc5191>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec
Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406,
February 2009, <http://www.rfc-editor.org/info/rfc5406>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
Sethi, et al. Expires January 26, 2018 [Page 28]
Internet-Draft Smart Object Security Experiences July 2017
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP)
Immediate Carriage and Conveyance of Upper-Layer Protocol
Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078,
January 2011, <http://www.rfc-editor.org/info/rfc6078>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object
Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012,
<http://www.rfc-editor.org/info/rfc6574>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<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
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <http://www.rfc-editor.org/info/rfc7515>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <http://www.rfc-editor.org/info/rfc7748>.
Sethi, et al. Expires January 26, 2018 [Page 29]
Internet-Draft Smart Object Security Experiences July 2017
[RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2
(IKEv2) Initiator Implementation", RFC 7815,
DOI 10.17487/RFC7815, March 2016,
<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>.
[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]
Gura, N., Patel, A., Wander, A., Eberle, H., and S.
Shantz, "Comparing Elliptic Curve Cryptography and RSA on
8-bit CPUs", 2010.
[rsa-high-speed]
Koc, C., "High-Speed RSA Implementation", November 1994,
<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
University, "TinyECC", 2008,
<http://discovery.csc.ncsu.edu/software/TinyECC/>.
[wiman] Margi, C., Oliveira, B., Sousa, G., Simplicio, M., Paulo,
S., Carvalho, T., Naslund, M., and R. Gold, "Impact of
Operating Systems on Wireless Sensor Networks (Security)
Applications and Testbeds.", International Conference on
Computer Communication Networks (ICCCN'2010) / IEEE
International Workshop on Wireless Mesh and Ad Hoc
Networks (WiMAN 2010) , 2010.
[wiselib] Baumgartner, T., Chatzigiannakis, I., Fekete, S., Koninis,
C., Kroller, A., and A. Pyrgelis, "Wiselib", 2010,
<www.wiselib.org/>.
[Withings]
Withings, "The Withings scale", February 2012,
<http://www.withings.com/en/bodyscale>.
Sethi, et al. Expires January 26, 2018 [Page 30]
Internet-Draft Smart Object Security Experiences July 2017
Appendix A. Acknowledgments
The authors would like to thank Mats Naslund, Salvatore Loreto, Bob
Moskowitz, Oscar Novo, Vlasios Tsiatsis, Daoyuan Li, Muhammad Waqas,
Eric Rescorla and Tero Kivinen for interesting discussions in this
problem space. The authors would also like to thank Diego Aranha for
helping with the relic-toolkit configurations and Tobias Baumgartner
for helping with questions regarding wiselib.
Authors' Addresses
Mohit Sethi
Ericsson
Jorvas 02420
Finland
EMail: mohit@piuha.net
Jari Arkko
Ericsson
Jorvas 02420
Finland
EMail: jari.arkko@piuha.net
Ari Keranen
Ericsson
Jorvas 02420
Finland
EMail: ari.keranen@ericsson.com
Heidi-Maria Back
Comptel
Helsinki 00181
Finland
EMail: heidi.back@comptel.com
Sethi, et al. Expires January 26, 2018 [Page 31]
