diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc8387.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc8387.txt')
| -rw-r--r-- | doc/rfc/rfc8387.txt | 1851 |
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc8387.txt b/doc/rfc/rfc8387.txt new file mode 100644 index 0000000..f6e91d4 --- /dev/null +++ b/doc/rfc/rfc8387.txt @@ -0,0 +1,1851 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Sethi +Request for Comments: 8387 J. Arkko +Category: Informational A. Keranen +ISSN: 2070-1721 Ericsson + H. Back + Nokia + May 2018 + + + Practical Considerations and Implementation Experiences in + Securing Smart Object Networks + +Abstract + + 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 + resource-constrained devices, and presents some preliminary + experiences with those libraries for message signing on resource- + constrained devices. Lastly, the memo discusses trade-offs involving + different types of security approaches. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8387. + + + + + + + + + + + + + +Sethi, et al. Informational [Page 1] + +RFC 8387 Smart Object Security Experiences May 2018 + + +Copyright Notice + + Copyright (c) 2018 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 + (https://trustee.ietf.org/license-info) 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 6 + 4.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 6 + 4.2. Protocol Architecture . . . . . . . . . . . . . . . . . . 9 + 5. Code Availability . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Implementation Experiences . . . . . . . . . . . . . . . . . 12 + 7. Example Application . . . . . . . . . . . . . . . . . . . . . 18 + 8. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21 + 8.1. Feasibility . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 22 + 8.3. Layering . . . . . . . . . . . . . . . . . . . . . . . . 24 + 8.4. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . 26 + 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 12. Informative References . . . . . . . . . . . . . . . . . . . 27 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 + + + + + + + + + + + + + + +Sethi, et al. Informational [Page 2] + +RFC 8387 Smart Object Security Experiences May 2018 + + +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 potential deployment model for constrained + environments. The model requires a 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 + resource-constrained devices using those libraries, including + information about achievable code sizes and speeds on typical + hardware. Section 7 describes an example proof-of-concept prototype + implementation that uses public-key cryptography on resource- + constrained devices to provide end-to-end data authenticity and + integrity protection. + + Finally, Section 8 discusses trade-offs involving different types of + security approaches. + +2. Related Work + + The Constrained Application Protocol (CoAP) [RFC7252] is a + lightweight 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. The 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 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 lightweight + implementations of the Internet Key Exchange Protocol Version 2 + (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]. + + [IoT-SECURITY] documents the different stages in the life cycle of a + smart object. Next, it highlights the security threats for smart + objects and the challenges that one might face to protect against + + + +Sethi, et al. Informational [Page 3] + +RFC 8387 Smart Object Security Experiences May 2018 + + + these threats. The document also looks at various security protocols + available, including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS + [RFC6347], the Host Identity Protocol (HIP) [RFC7401], HIP Diet + EXchange [HIP-DEX], a Protocol for Carrying Authentication for + Network Access (PANA) [RFC5191], and the Extensible Authentication + Protocol (EAP) [RFC3748]. Lastly, [IoT-BOOTSTRAPPING] discusses + bootstrapping mechanisms available for resource-constrained Internet + of Things (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 should be undertaken in developing suitable + credential management mechanisms (perhaps something similar to the + Bluetooth pairing mechanism), understanding the implementability of + standard security mechanisms in resource-constrained devices, and + conducting additional research in the area of lightweight + cryptographic primitives. + + [HIP-DEX] defines a lightweight 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. + + [IPV6-LOWPAN-SEC] makes a comprehensive analysis of security issues + related to IPv6 over Low-Power Wireless Personal Area Network + (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, and 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 resource-constrained, 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, + + + +Sethi, et al. Informational [Page 4] + +RFC 8387 Smart Object Security Experiences May 2018 + + + limited processing power for long key lengths, a 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 most lightweight algorithms and + cryptographic primitives are 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 is + unfortunately often neglected in the design. There are several + problems in the provisioning and management of smart object networks: + + o Resource-constrained 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 or 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 Smart object networks may rely on different radio technologies. + Provisioning methods that rely on specific link-layer features may + not work with other radio technologies in a heterogeneous network. + + + + + + +Sethi, et al. Informational [Page 5] + +RFC 8387 Smart Object Security Experiences May 2018 + + + 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. + + In light of the above challenges, 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 [CoAP-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 relate 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 + + [CoAP-SECURITY] recognizes the provisioning model as the driver of + what kind of security architecture is useful. This section + reintroduces 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) + + 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. "|" (vertical bar) 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 + + + +Sethi, et al. Informational [Page 6] + +RFC 8387 Smart Object Security Experiences May 2018 + + + then commence with the devices, at least as far as information 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 a large number of devices to a 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; however, 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 a separate user interface, a local + connection (such as USB), or use of 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 + certificate or 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 the parties interested in communicating know the expected + cryptographic identity of the other offline, 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, many pairing methods + based on "leap of faith" or "trust on first use" assume that the + attacker is not present during the initial setup. Therefore, they + are vulnerable to eavesdropping or man-in-the-middle (MitM) attacks. + + In any case, the secure identities help again in ensuring that the + operations are as simple as possible. Only identities need to be + communicated to the devices, not certificates, shared secrets, or, + e.g., IPsec policy rules. + + + + +Sethi, et al. Informational [Page 7] + +RFC 8387 Smart Object Security Experiences May 2018 + + + 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. One simple but not completely secure + method is 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 (RFID) tags. 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 needed for 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 life cycle; an example is 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 dynamic IPv6 + + + +Sethi, et al. Informational [Page 8] + +RFC 8387 Smart Object Security Experiences May 2018 + + + 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: + + 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, Potherdevi are the public keys of other + devices in the group, n is all the devices in the group except the + device with Pdev as its public key, and m is the total number of + 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 cannot claim to be in the group, because the + group identity would change if any new keys were added to the + identity of the group (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 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. [CoAP-SECURITY] 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 + + + +Sethi, et al. Informational [Page 9] + +RFC 8387 Smart Object Security Experiences May 2018 + + + 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, and more specifically, in the data formats + transported in the payload part of CoAP. This approach provides the + following benefits: + + 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, it is generally not the typical arrangement. + +5. Code Availability + + For implementing public-key cryptography on resource-constrained + environments, we chose the 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 an 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 most resource-constrained 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. + + + + +Sethi, et al. Informational [Page 10] + +RFC 8387 Smart Object Security Experiences May 2018 + + + Here is the set of libraries we found: + + o AVRCryptoLib [avr-cryptolib]: This library provides symmetric key + algorithms such as AES. 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 + of a large variety of cryptographic algorithms. This not only + includes RSA and ECC but also pairing-based asymmetric + cryptography, Boneh-Lynn-Shacham signatures, and Boneh-Boyen short + signatures. The library has also added support for curve25519 + (for Elliptic Curve Diffie-Hellman key exchange) [RFC7748] and + edwards25519 (for elliptic curve digital signatures) [RFC8032]. + The toolkit provides an option to build only the desired + components for the required platform. + + o TinyECC [tinyecc]: TinyECC was designed for using elliptic-curve- + based public-key cryptography on sensor networks. It is written + in the nesC programming language [nesC] and as such is designed + for specific use on TinyOS. However, the library can be ported to + standard C either with tool chains or by 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 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 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. + + This is by no means an exhaustive list, and there exists other + cryptographic libraries targeting resource-constrained devices. + + + + + +Sethi, et al. Informational [Page 11] + +RFC 8387 Smart Object Security Experiences May 2018 + + + There are also a number of operating systems that are specifically + targeted for resource-constrained devices. These operating systems + may include libraries and code for security. Hahm et al. [hahmos] + conducted a survey of such operating systems. The ARM Mbed OS [mbed] + is one such operating system that provides various cryptographic + primitives that are necessary for SSL/TLS protocol implementation as + well as X509 certificate handling. The library provides an API for + developers with a minimal code footprint. It is intended for various + ARM platforms such as ARM Cortex M0, ARM Cortex M0+, and ARM Cortex + M3. + +6. Implementation Experiences + + 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 | Execution time (ms); | Memory footprint (bytes); | + | (bits) | key in RAM | key in RAM | + +--------------+------------------------+---------------------------+ + | 2048 | 1587567 | 1280 | + +--------------+------------------------+---------------------------+ + + Table 1: 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 the C99 standard and running the Elliptic Curve Digital + Signature Algorithm (ECDSA) on the Arduino Uno board. TinyECC + supports a variety of SEC-2-recommended elliptic curve domain + parameters [sec2ecc]. The execution time and memory footprint are + + + + + +Sethi, et al. Informational [Page 12] + +RFC 8387 Smart Object Security Experiences May 2018 + + + shown next to each of the curve parameters. These results were + obtained by turning on all the optimizations and using assembly code + where available. + + The results from the performance evaluation of ECDSA in the following + tables also contain a column stating the approximate comparable RSA + key length as documented in [sec2ecc]. It is clearly observable that + for similar security levels, elliptic curve public-key cryptography + outperforms RSA. + + +-------------+---------------+-----------------+-------------------+ + | 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 | + +-------------+---------------+-----------------+-------------------+ + + Table 2: 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 is + 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. However, if 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 | + +-------------+---------------+-----------------+-------------------+ + + Table 3: Performance of ECDSA Sign Operation with TinyECC + (No Assembly Optimizations) + + + +Sethi, et al. Informational [Page 13] + +RFC 8387 Smart Object Security Experiences May 2018 + + + 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 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 | + +-------------+---------------+-----------------+-------------------+ + + Table 4: 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. Arduino Mega has the same 8-bit architecture as + Arduino Uno, but it has a much larger RAM/ROM. We used Arduino Mega + for experimenting with the 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 to prove + which curves perform the fastest but rather to show that asymmetric + cryptography is possible on resource-constrained devices. + + The results from relic-toolkit are documented separately in Tables 5 + and 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 + + + +Sethi, et al. Informational [Page 14] + +RFC 8387 Smart Object Security Experiences May 2018 + + + 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 | Execution | Memory | Comparable RSA | + | parameters | time (ms) | footprint | key length | + | | | (bytes) | | + +-----------------+--------------+----------------+-----------------+ + | sect163k1 | 261 | 2804 | 1024 | + | (assembly math) | | | | + | sect163k1 | 932 | 2750 | 1024 | + | sect163r2 | 2243 | 2444 | 1024 | + | sect233k1 | 1736 | 3675 | 2048 | + | sect233r1 | 4471 | 3261 | 2048 | + +-----------------+--------------+----------------+-----------------+ + + Table 5: Performance of ECDSA Sign Operation with + relic-toolkit (Fast) + + +-----------------+--------------+----------------+-----------------+ + | Curve | Execution | Memory | Comparable RSA | + | parameters | time (ms) | footprint | key length | + | | | (bytes) | | + +-----------------+--------------+----------------+-----------------+ + | sect163k1 | 592 | 2087 | 1024 | + | (assembly math) | | | | + | sect163k1 | 2950 | 2215 | 1024 | + | sect163r2 | 3213 | 2071 | 1024 | + | sect233k1 | 6450 | 2935 | 2048 | + | sect233r1 | 6100 | 2737 | 2048 | + +-----------------+--------------+----------------+-----------------+ + + Table 6: Performance of ECDSA Sign Operation with relic-toolkit + (Low Memory) + + + + + + + + + + + + + + + +Sethi, et al. Informational [Page 15] + +RFC 8387 Smart Object Security Experiences May 2018 + + + It is important to note the following points about the elliptic curve + measurements: + + o Some boards (e.g., Arduino Uno) do not provide a hardware random + number generator. On such boards, obtaining cryptographic-quality + randomness is a challenge. Real-world deployments must rely on a + hardware random number generator for cryptographic operations such + as generating a public-private key pair. The Nordic nRF52832 + board [nordic], for example, provides a hardware random number + generator. A detailed discussion on requirements and best + practices for cryptographic-quality randomness is documented in + [RFC4086] + + 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 ECC on an ARM Coretex platform. The results for the + ECDSA sign operation shown in Table 7 are performed on a Freescale + FRDM-KL25Z board [freescale] that has an ARM Cortex-M0+ 48MHz + microcontroller with 128 kB of flash memory and 16 kB 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 | + +------------------+---------------------+--------------------------+ + + Table 7: Performance of ECDSA Sign Operation with an ARM Mbed TLS + Stack on Freescale FRDM-KL25Z + + Tschofenig and Pegourie-Gonnard [armecdsa] also measured the + performance of curves on an ST Nucleo F091 (STM32F091RCT6) board + [stnucleo] that has an ARM Cortex-M0 48 MHz microcontroller with 256 + kB of flash memory and 32 kB of RAM. The execution time for the + 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. Informational [Page 16] + +RFC 8387 Smart Object Security Experiences May 2018 + + + +------------------+---------------------+--------------------------+ + | 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 | + +------------------+---------------------+--------------------------+ + + Table 8: ECDSA Signature Performance with an ARM Mbed TLS Stack on ST + Nucleo F091 (STM32F091RCT6) + + Finally, Tschofenig and Pegourie-Gonnard [armecdsa] also measured the + RAM consumption by calculating the heap consumed for the + cryptographic operations using a custom memory allocation handler. + They 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 this study, it was + unclear which exact elliptic curve(s) would be selected by the IETF + community for use with resource-constrained devices. However, + [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 the signing of data using the curve Ed25519 from the + NaCl library needs only 23216241 cycles on the same microcontroller + that we used for our evaluations (Arduino Mega ATmega2560). This + corresponds to about 1451 milliseconds of execution time. When + compared to the results for other curves and libraries that offer a + + + +Sethi, et al. Informational [Page 17] + +RFC 8387 Smart Object Security Experiences May 2018 + + + similar level of security (such as sect233r1 and sect233k1), this + implementation far outperforms all others. As such, it is + recommended that the IETF community use 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 | + +------------------------+------------------------------------+ + + Table 9: 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. By no means are these + numbers the final source for measurements, and some curves presented + here may no longer be acceptable for real in-the-wild deployments. + For example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also + document the performance of ECDSA on similar resource-constrained + devices. + +7. Example Application + + We developed an example application on the Arduino platform to use + public-key cryptography, 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 stay on at all times. They wake up + periodically and transmit their readings. + + Such sensor nodes can be supported in various ways. [CoAP-SENSORS] + was an early multicast-based approach. In the current application, + we have switched to using resource directories [CoRE-RD] and publish- + subscribe brokers [CoAP-BROKER] 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 + + + +Sethi, et al. Informational [Page 18] + +RFC 8387 Smart Object Security Experiences May 2018 + + + 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 kB of + flash memory, and the simple CoAP client takes roughly 3 kB. + + 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 a secure-shell-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 + JSON Object Signing and Encryption (JOSE) signature on the used JSON + [RFC7515] and Sensor Measurement List (SenML) payload [MT-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. + + + + + +Sethi, et al. Informational [Page 19] + +RFC 8387 Smart Object Security Experiences May 2018 + + + 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 distinct 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 sect163k1 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 Representational State + Transfer (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. A real implementation based on this + prototype would instead use the domain name system for obtaining the + location of the resource directory. + + Our intention was to demonstrate that it is possible to implement the + 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 that 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. + + + + + + + + + +Sethi, et al. Informational [Page 20] + +RFC 8387 Smart Object Security Experiences May 2018 + + +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 resource- + constrained 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 a 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 resource constrained 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. + Flash memory size is not expected 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, or even spend + multiple seconds in some cases, for the computation of a signature + for the message that it is about to send. 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, these algorithms can successfully be + employed in resource-constrained devices for the following reasons: + + o With the right selection of algorithms and libraries, the + execution times can actually be very small (less than 500 ms). + + + + +Sethi, et al. Informational [Page 21] + +RFC 8387 Smart Object Security Experiences May 2018 + + + o As discussed in [wiman], in general, the power requirements + necessary to turn the radio on/off and sending or receiving + 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. + + 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. However, it is 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: + + 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 the Network Time + Protocol (NTP) [RFC5905] are resource intensive and therefore may + be undesirable in many smart object networks. + + + + + + +Sethi, et al. Informational [Page 22] + +RFC 8387 Smart Object Security Experiences May 2018 + + + 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; 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 + resynchronize with the publish-subscribe broker if a reset message is + received. The sensors resynchronize 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 that include + timestamps to allow the publish-subscribe broker to determine the + time when the update was created. For example, when the publish- + + + +Sethi, et al. Informational [Page 23] + +RFC 8387 Smart Object Security Experiences May 2018 + + + 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 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 coordinate 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 + primary 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 smart home weighing + scale, for instance, can support WLAN security, but without some + + + +Sethi, et al. Informational [Page 24] + +RFC 8387 Smart Object Security Experiences May 2018 + + + 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 the link layer, network layer, and in some cases, transport + layer, cannot 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. 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. + + + + +Sethi, et al. Informational [Page 25] + +RFC 8387 Smart Object Security Experiences May 2018 + + + 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 deployments of cryptographic security, the cellular + network authentication system, uses Subscriber Identification Module + (SIM) cards that are based on symmetric secrets. In contrast, + public-key systems have yet to show an 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 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 resource-constrained devices is far cheaper than transmission + power [wiman], and it 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 it works less + well for data-object security, particularly when the number of + communicating entities is not exactly two. + + + + + + + + + + + +Sethi, et al. Informational [Page 26] + +RFC 8387 Smart Object Security Experiences May 2018 + + +9. Summary + + This document makes several security recommendations based on our + implementation experience. We summarize some of the important ones + here: + + o Developers and product designers should choose the hardware after + determining the security requirements for their application + scenario. + + o ECC outperforms RSA-based operations; therefore, it is recommended + for resource-constrained devices. + + o Cryptographic-quality randomness is needed for many security + protocols. Developers and vendors should ensure that the + sufficient randomness is available for security critical tasks. + + o 32-bit microcontrollers are much more easily available, at lower + costs, and are more power efficient. Therefore, real-world + deployments are better off using 32-bit microcontrollers. + + o Developers should provide mechanisms for devices to generate new + identities at appropriate times during their life cycle, for + example, after a factory reset or an ownership handover. + + o Planning for firmware updates is important. The hardware platform + chosen should at least have a flash memory size of the total code + size * 2, plus some space for buffer. + +10. Security Considerations + + This entire memo deals with security issues. + +11. IANA Considerations + + This document has no IANA actions. + +12. Informative References + + [arduino-uno] + Arduino, "Arduino Uno REV3", + <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>. + + + + +Sethi, et al. Informational [Page 27] + +RFC 8387 Smart Object Security Experiences May 2018 + + + [avr-crypto-lib] + Das Labor, "AVR-Crypto-Lib", February 2014, + <http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>. + + [avr-cryptolib] + "AVRCryptoLib", <http://www.emsign.nl/>. + + [avrora] Avora, "The AVR Simulation and Analysis Framework", + <http://compilers.cs.ucla.edu/avrora/>. + + [CoAP-BROKER] + Koster, M., Keranen, A., and J. Jimenez, "Publish- + Subscribe Broker for the Constrained Application Protocol + (CoAP)", Work in Progress, draft-ietf-core-coap-pubsub-04, + March 2018. + + [CoAP-SECURITY] + Arkko, J. and A. Keranen, "CoAP Security Architecture", + Work n Progress, draft-arkko-core-security-arch-00, July + 2011. + + [CoAP-SENSORS] + Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. + Novo, "Implementing Tiny COAP Sensors", Wok in Progress, + draft-arkko-core-sleepy-sensors-01, July 2011. + + [CoRE-RD] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. + Amsuess, "CoRE Resource Directory", Work in Progress, + draft-ietf-core-resource-directory-13, March 2018. + + [freescale] + ARM Mbed, "FRDM-KL25Z", + <https://developer.mbed.org/platforms/KL25Z/>. + + [hahmos] Hahm, O., Baccelli, E., Petersen, H., and N. Tsiftes, + "Operating systems for low-end devices in the internet of + things: a survey", IEEE Internet of Things Journal, + Vol. 3, Issue 5, DOI 10.1109/JIOT.2015.2505901, October + 2016. + + [HIP-DEX] Moskowitz, R., Ed. and R. Hummen, "HIP Diet EXchange + (DEX)", Work in Progress, draft-ietf-hip-dex-06, December + 2017. + + [huang] Huang, C., "LOFT: Low-overhead freshness transmission in + sensor networks", IEEE, DOI 10.1109/SUTC.2008.38, June + 2008. + + + + +Sethi, et al. Informational [Page 28] + +RFC 8387 Smart Object Security Experiences May 2018 + + + [IoT-BOOTSTRAPPING] + Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT + Bootstrapping: A Survey", Work in Progress, + draft-sarikaya-t2trg-sbootstrapping-03, February 2017. + + [IoT-SECURITY] + Garcia-Morchon, O., Kumar, S., and M. Sethi, + "State-of-the-Art and Challenges for the Internet of + Things Security", Work in Progress, + draft-irtf-t2trg-iot-seccons-14, April 2018. + + [IPV6-LOWPAN-SEC] + Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. + Laganier, "IPv6 over Low Power WPAN Security Analysis", + Work in Progress, draft-daniel-6lowpan-security- + analysis-05, March 2011. + + [matrix-ssl] + Inside Secure, "GUARD TLS Toolkit (formerly Matrix SSL)", + <http://www.matrixssl.org/>. + + [mbed] ARM Mbed, "Mbed TLS", + <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. + + [MT-SenML] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. + Bormann, "Sensor Measurement Lists (SenML)", Work in + Progress, draft-ietf-core-senml-15, May 2018. + + [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, Computer Science, Vol. 7918, pp. + 156-172, February 2013, + <https://doi.org/10.1007/978-3-642-38553-7_9>. + + + + + + +Sethi, et al. Informational [Page 29] + +RFC 8387 Smart Object Security Experiences May 2018 + + + [nesC] Gay, D., Levis, P., von Behren, R., Welsh, M., Brewer, E., + and D. Culler, "The nesC language: A holistic approach to + networked embedded systems", ACM SIGPLAN Notices, Vol. 38, + Issue 5, DOI 10.1145/781131.781133, 2003. + + [nordic] Nordic Semiconductor, "nRF52832 Product Specification + v1.3", March 2017, <http://infocenter.nordicsemi.com/pdf/ + nRF52832_PS_v1.3.pdf>. + + [relic-toolkit] + "relic", March 2017, + <https://github.com/relic-toolkit/relic>. + + [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, + <https://www.rfc-editor.org/info/rfc3748>. + + [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, DOI 10.17487/RFC3972, March 2005, + <https://www.rfc-editor.org/info/rfc3972>. + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + <https://www.rfc-editor.org/info/rfc4086>. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, DOI 10.17487/RFC4303, December 2005, + <https://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, <https://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, + <https://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, <https://www.rfc-editor.org/info/rfc5406>. + + + + + + + +Sethi, et al. Informational [Page 30] + +RFC 8387 Smart Object Security Experiences May 2018 + + + [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, + <https://www.rfc-editor.org/info/rfc5905>. + + [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, <https://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, <https://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, + <https://www.rfc-editor.org/info/rfc6574>. + + [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link + Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, + <https://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, + <https://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, + <https://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, <https://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, + <https://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, <https://www.rfc-editor.org/info/rfc7515>. + + + + + + +Sethi, et al. Informational [Page 31] + +RFC 8387 Smart Object Security Experiences May 2018 + + + [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves + for Security", RFC 7748, DOI 10.17487/RFC7748, January + 2016, <https://www.rfc-editor.org/info/rfc7748>. + + [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 + (IKEv2) Initiator Implementation", RFC 7815, + DOI 10.17487/RFC7815, March 2016, + <https://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, + <https://www.rfc-editor.org/info/rfc8032>. + + [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", + RFC 8152, DOI 10.17487/RFC8152, July 2017, + <https://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", DOI 10.1007/978-3-540-28632-5_9, 2004. + + [rsa-high-speed] + Koc, C., "High-Speed RSA Implementation", November 1994, + <http://storage.jak-stik.ac.id/rsasecurity/tr201.pdf>. + + [sec2ecc] Certicom Research, "SEC 2: Recommended Elliptic Curve + Domain Parameters", Version 2.0, January 2010. + + [stnucleo] STMicroelectronics, "NUCLEO-F091RC", + <http://www.st.com/en/evaluation-tools/ + nucleo-f091rc.html/>. + + [tinyecc] Liu, A. and P. Nig, "TinyECC: A Configurable Library for + Elliptic Curve Cryptography in Wireless Sensor Networks + (Version 2.0)", NCSU College of Engineering, February + 2011, <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", Proceedings of the 19th + International Conference on Computer Communciations and + Networks, DOI 10.1109/ICCCN.2010.5560028, 2010. + + [wiselib] "wiselib", February 2015, + <https://github.com/ibr-alg/wiselib>. + + + + +Sethi, et al. Informational [Page 32] + +RFC 8387 Smart Object Security Experiences May 2018 + + +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. + + Tim Chown, Samita Chakrabarti, Christian Huitema, Dan Romascanu, Eric + Vyncke, and Emmanuel Baccelli provided valuable comments that helped + us improve this document. + +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 + Nokia + Helsinki 00181 + Finland + + Email: heidi.back@nokia.com + + + + + + +Sethi, et al. Informational [Page 33] + |