Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8387

Practical Considerations and Implementation Experiences in Securing Smart Object Networks

Pages: 33
Informational
Part 1 of 2 – Pages 1 to 18
None   None   Next

Top   ToC   RFC8387 - Page 1
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.
Top   ToC   RFC8387 - Page 2
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
Top   ToC   RFC8387 - Page 3

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
Top   ToC   RFC8387 - Page 4
   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,
Top   ToC   RFC8387 - Page 5
   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.
Top   ToC   RFC8387 - Page 6
   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
Top   ToC   RFC8387 - Page 7
   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.
Top   ToC   RFC8387 - Page 8
   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
Top   ToC   RFC8387 - Page 9
   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
Top   ToC   RFC8387 - Page 10
   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.
Top   ToC   RFC8387 - Page 11
   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.
Top   ToC   RFC8387 - Page 12
   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
Top   ToC   RFC8387 - Page 13
   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)
Top   ToC   RFC8387 - Page 14
   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
Top   ToC   RFC8387 - Page 15
   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)
Top   ToC   RFC8387 - Page 16
   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.
Top   ToC   RFC8387 - Page 17
   +------------------+---------------------+--------------------------+
   | 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
Top   ToC   RFC8387 - Page 18
   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.



(page 18 continued on part 2)

Next Section