Light-Weight Implementation Guidance M. Sethi
Internet-Draft J. Arkko
Intended status: Informational A. Keranen
Expires: June 28, 2018 Ericsson
H. Back
December 25, 2017

Practical Considerations and Implementation Experiences in Securing Smart Object Networks


This memo describes challenges associated with securing resource-constrained smart object devices. The memo describes a possible deployment model where resource-constrained devices sign message objects, discusses the availability of cryptographic libraries for small devices and presents some preliminary experiences with those libraries for message signing on small devices. 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

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 June 28, 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 ( in effect on the date of 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

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 5 discusses the availability of cryptographic libraries. Section 6 presents some experiences in implementing cryptography on small devices using those libraries, including information about achievable code sizes and speeds on typical hardware.

Finally, Section 8 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].

[I-D.irtf-t2trg-iot-seccons] documents the different stages in the lifecycle of a smart object. Next, it highlights the security threats for smart objects and the challenges that one might face to protect against these threats. The document also looks at various security protocols available, including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347], HIP [RFC7401], [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP [RFC3748]. Lastly, [I-D.sarikaya-t2trg-sbootstrapping] discusses bootstrapping mechanisms available for resource-constrained IoT devices.

[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.

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. This is perhaps the most fundamental and difficult issue, and unfortunately often neglected in the design. There are several problems in the provisioning and management of smart object networks:

In light of the above challenges, small resource-constrained devices are often shipped with a single static identity. In many cases, it is a single raw public key. These long-term static identities makes it easy to track the devices (and their owners) when they move. The static identities may also allow an attacker to track these devices across ownership changes.

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:

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.

4.1. 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.

Once 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 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. For example, leap-of-faith or trust-on-first-use based pairing methods assume that the attacker is not present during the initial setup and are vulnerable to eavesdropping or man-in-the-middle (MitM) attacks.

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.

As discussed in the previous section, long-term static identities negatively affect the privacy of the devices and their owners. Therefore, it is beneficial for devices to generate new identities at appropriate times during their lifecycle. For example, after a factory reset or an ownership handover. Thus, in our proposed deployment model, the devices would generate a new asymmetric key pair and use the new public-key P' to generate the new identity I'. It is also desirable that these identities are only used during the provisioning stage. Temporary identities (such as IPv6 addresses) can be used for network communication protocols once the device is operational.

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:

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.

4.2. 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:

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.

5. 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 a 8-bit platform may seem surprising since cheaper and more energy-efficient 32-bit platforms are available. However, our intention was to evaluate the performance of public-key cryptography on the smallest platforms available. It is reasonable to expect better performance results from 32-bit microcontrollers.

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:

This is by no ways an exhaustive list and there exist other cryptographic libraries targeting resource-constrained devices.

6. 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 7 required only the 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 (bits) Execution time (ms); key in RAM Memory footprint (bytes); key in RAM
2048 1587567 1,280

RSA private key operation performance

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.

Curve parameters Execution time (ms) Memory Footprint (bytes) Comparable RSA key length
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

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 parameters Execution time (ms) Memory Footprint (bytes) Comparable RSA key length
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 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 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 parameters Execution time (ms) Memory Footprint (bytes) Comparable RSA key length
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

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 optimizations included in the library, a trade-off between memory and execution time between these values can be achieved.

Curve parameters Execution time (ms) Memory Footprint (bytes) Comparable RSA key length
NIST K163 (assembly math) 261 2,804 1024
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)

Curve parameters Execution time (ms) Memory Footprint (bytes) Comparable RSA key length
NIST K163 (assembly math) 592 2087 1024
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)

It is important to note the following points about the elliptic curve measurements:

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

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)

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 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

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.

7. 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 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:


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.

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.

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 resource directory 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 modern development boards have a 32-bit microcontroller since they are more economical and have better energy efficiency.

8. 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. In particular, this analysis looks at layering, freshness and the choice of symmetric vs. asymmetric cryptography.

8.1. 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:

While we did not do an exhaustive performance evaluation of asymmetric key pair generation on resource-constrained devices, we did note that it is possible for such devices to generate a new key pair. Given that this operation would only occur in rare circumstances (such as a factory reset or ownership change) and its potential privacy benefits, developers should provide mechanisms for generating new identities. It is however extremely important to note that the security of this operation relies on access to cryptographic-quality randomness.

8.2. 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:

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 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.

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.

8.3. 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.
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 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.

8.4. 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 6, 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.

9. Summary

This document makes several security recommendations based on our implementation experience. We summarize some of the important ones here:

10. Security Considerations

This entire memo deals with security issues.

11. IANA Considerations

There are no IANA impacts in this memo.

12. Informative references

[arduino-uno] Arduino, "Arduino Uno", September 2015.
[armecdsa] Tschofenig, H. and M. Pegourie-Gonnard, "Performance Investigations", March 2015.
[avr-crypto-lib] AVR-CRYPTO-LIB, "AVR-CRYPTO-LIB", September 2015.
[avr-cryptolib] Van der Laan, E., "AVR CRYPTOLIB", September 2015.
[avrora] Titzer, Ben., "Avrora", September 2015.
[freescale] NXP, "Freescale FRDM-KL25Z", June 2017.
[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", Internet-Draft draft-arkko-core-security-arch-00, July 2011.
[I-D.arkko-core-sleepy-sensors] Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z. and O. Novo, "Implementing Tiny COAP Sensors", Internet-Draft draft-arkko-core-sleepy-sensors-01, July 2011.
[I-D.daniel-6lowpan-security-analysis] Park, S., Kim, K., Haddad, W., Chakrabarti, S. and J. Laganier, "IPv6 over Low Power WPAN Security Analysis", Internet-Draft draft-daniel-6lowpan-security-analysis-05, March 2011.
[I-D.ietf-core-coap-pubsub] Koster, M., Keranen, A. and J. Jimenez, "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Internet-Draft draft-ietf-core-coap-pubsub-02, July 2017.
[I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., Stok, P. and C. Amsuess, "CoRE Resource Directory", Internet-Draft draft-ietf-core-resource-directory-12, October 2017.
[I-D.ietf-core-senml] Jennings, C., Shelby, Z., Arkko, J., Keranen, A. and C. Bormann, "Media Types for Sensor Measurement Lists (SenML)", Internet-Draft draft-ietf-core-senml-12, December 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", Internet-Draft draft-irtf-t2trg-iot-seccons-09, December 2017.
[I-D.moskowitz-hip-dex] Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", Internet-Draft draft-moskowitz-hip-dex-05, January 2016.
[I-D.sarikaya-t2trg-sbootstrapping] Sarikaya, B., Sethi, M. and A. Sangi, "Secure IoT Bootstrapping: A Survey", Internet-Draft draft-sarikaya-t2trg-sbootstrapping-03, February 2017.
[matrix-ssl] PeerSec Networks, "Matrix SSL", September 2015.
[mbed] ARM, "mbed TLS", May 2017.
[micronacl] MicroNaCl, "The Networking and Cryptography library for microcontrollers"
[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.
[nacl] NaCl, "Networking and Cryptography library"
[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.
[relic-toolkit] Aranha, D. and C. Gouv, "Relic Toolkit", September 2015.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005.
[RFC4086] Eastlake 3rd, D., Schiller, J. and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008.
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, February 2009.
[RFC5905] Mills, D., Martin, J., Burbank, J. and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010.
[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.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012.
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014.
[RFC7252] Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014.
[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.
[RFC7401] Moskowitz, R., Heer, T., Jokela, P. and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015.
[RFC7515] Jones, M., Bradley, J. and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015.
[RFC7748] Langley, A., Hamburg, M. and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016.
[RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation", RFC 7815, DOI 10.17487/RFC7815, March 2016.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017.
[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.
[stnucleo] STMicroelectronics, "NUCLEO-F091RC", June 2017.
[tinyecc] North Carolina State University and North Carolina State University, "TinyECC", 2008.
[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.
[Withings] Withings, "The Withings scale", February 2012.

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:
Jari Arkko Ericsson Jorvas, 02420 Finland EMail:
Ari Keranen Ericsson Jorvas, 02420 Finland EMail:
Heidi-Maria Back Comptel Helsinki, 00181 Finland EMail: