--- 1/draft-ietf-lwig-crypto-sensors-02.txt 2017-07-26 05:13:18.066664814 -0700 +++ 2/draft-ietf-lwig-crypto-sensors-03.txt 2017-07-26 05:13:18.138666528 -0700 @@ -1,49 +1,49 @@ Light-Weight Implementation Guidance M. Sethi Internet-Draft J. Arkko Intended status: Informational A. Keranen -Expires: August 14, 2017 Ericsson +Expires: January 26, 2018 Ericsson H. Back Comptel - February 10, 2017 + July 25, 2017 Practical Considerations and Implementation Experiences in Securing Smart Object Networks - draft-ietf-lwig-crypto-sensors-02 + draft-ietf-lwig-crypto-sensors-03 Abstract - This memo describes challenges associated with securing smart object - devices in constrained implementations and environments. The memo - describes a possible deployment model suitable for these - environments, discusses the availability of cryptographic libraries - for small devices, presents some preliminary experiences in - implementing cryptography on small devices using those libraries, and - discusses trade-offs involving different types of approaches. + This memo describes challenges associated with securing resource- + constrained smart object devices. The memo describes a possible + deployment model suitable for these environments, discusses the + availability of cryptographic libraries for small devices, and + presents some preliminary experiences in implementing cryptography on + small devices using those libraries. Lastly, the memo discusses + trade-offs involving different types of security approaches. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 14, 2017. + This Internet-Draft will expire on January 26, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -55,71 +55,69 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5 5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8 7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 9 - 8. Implementation Experiences . . . . . . . . . . . . . . . . . 11 + 8. Implementation Experiences . . . . . . . . . . . . . . . . . 10 9. Example Application . . . . . . . . . . . . . . . . . . . . . 17 - 10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21 - 11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 26 - 15. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 - 17. Informative references . . . . . . . . . . . . . . . . . . . 27 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 + 10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 20 + 11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 25 + 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 17. Informative references . . . . . . . . . . . . . . . . . . . 26 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction This memo describes challenges associated with securing smart object devices in constrained implementations and environments. In Section 3 we specifically discuss three challenges: the implementation difficulties encountered on resource-constrained platforms, the problem of provisioning keys and making the choice of implementing security at the appropriate layer. - Secondly, Section 4 discusses a deployment model that the authors are + Section 4 discusses a deployment model that the authors are considering for constrained environments. The model requires minimal amount of configuration, and we believe it is a natural fit with the typical communication practices in smart object networking environments. - Thirdly, Section 7 discusses the availability of cryptographic - libraries. Section 8 presents some experiences in implementing - cryptography on small devices using those libraries, including - information about achievable code sizes and speeds on typical - hardware. + Section 7 discusses the availability of cryptographic libraries. + Section 8 presents some experiences in implementing cryptography on + small devices using those libraries, including information about + achievable code sizes and speeds on typical hardware. Finally, Section 10 discusses trade-offs involving different types of security approaches. 2. Related Work Constrained Application Protocol (CoAP) [RFC7252] is a light-weight protocol designed to be used in machine-to-machine applications such as smart energy and building automation. Our discussion uses this protocol as an example, but the conclusions may apply to other similar protocols. CoAP base specification [RFC7252] outlines how to use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol. DTLS can be applied with pairwise shared keys, raw public keys or with certificates. The security model in all cases is mutual - authentication, so while there is some commonality to HTTP in - verifying the server identity, in practice the models are quite - different. The CoAP specification says little about how DTLS keys - are managed. The use of IPsec with CoAP is described with regards to + authentication, so while there is some commonality to HTTP [RFC7230] + in verifying the server identity, in practice the models are quite + different. The use of IPsec with CoAP is described with regards to the protocol requirements, noting that small implementations of IKEv2 exist [RFC7815] . However, the CoAP specification is silent on policy and other aspects that are normally necessary in order to implement interoperable use of IPsec in any environment [RFC5406]. [RFC6574] gives an overview of the security discussions at the March 2011 IAB workshop on smart objects. The workshop recommended that additional work is needed in developing suitable credential management mechanisms (perhaps something similar to the Bluetooth pairing mechanism), understanding the implementability of standard @@ -169,26 +167,32 @@ limited support for security mechanisms, limited processing power for long key lengths, sleep schedule that does not allow communication at all times, and so on. In addition, the devices typically have very limited support for configuration, making it hard to set up secrets and trust anchors. The implementation difficulties are important, but they should not be overemphasized. It is important to select the right security mechanisms and avoid duplicated or unnecessary functionality. But at the end of the day, if strong cryptographic security is needed, the - implementations have to support that. Also, the use of the most - lightweight algorithms and cryptographic primitives is useful, but - should not be the only consideration in the design. 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. + implementations have to support that. It is important for developers + and product designers to determine what security threats they want to + tackle and the resulting security requirements before selecting the + hardware. Often, development work in the wild happens in the wrong + order: a particular platform with a resource-constrained + microcontroller is chosen first, and then the security features that + can fit on it are decided. Also, the use of the most lightweight + algorithms and cryptographic primitives is useful, but should not be + the only consideration in the design and development. + Interoperability is also important, and often other parts of the + system, such as key management protocols or certificate formats are + heavier to implement than the algorithms themselves. The second challenge relates to practical provisioning problems. These are perhaps the most fundamental and difficult issue, and unfortunately often neglected in the design. There are several problems in the provisioning and management of smart object networks: o Small devices have no natural user interface for configuration that would be required for the installation of shared secrets and other security-related parameters. Typically, there is no keyboard, no display, and there may not even be buttons to press. @@ -391,271 +395,211 @@ solutions are more likely to be able to benefit from sessions where the cost of expensive operations can be amortized over multiple data transmissions. While this is not impossible in data object security solutions either, it is not the typical arrangement either. 7. Code Availability For implementing public key cryptography on resource constrained environments, we chose Arduino Uno board [arduino-uno] as the test platform. Arduino Uno has an ATmega328 microcontroller, an 8-bit - processor with a clock speed of 16 MHz, 2 kB of SRAM, and 32 kB of - flash memory. + processor with a clock speed of 16 MHz, 2 kB of RAM, and 32 kB of + flash memory. Our choice of 8-bit platform may be surprising since + it. For selecting potential asymmetric cryptographic libraries, we surveyed and came up with a set of possible code sources, and performed an initial analysis of how well they fit the Arduino environment. Note that the results are preliminary, and could easily be affected in any direction by implementation bugs, configuration errors, and other mistakes. It is advisable to verify the numbers before relying on them for building something. No significant effort was done to optimize ROM memory usage beyond what the libraries provided themselves, so those numbers should be taken as upper limits. Here is the set of libraries we found: o AvrCryptolib [avr-cryptolib]: This library provides a variety of - different symmetric key algorithms such as AES and RSA as an - asymmetric key algorithm. We stripped down the library to use - only the required RSA components and used a separate SHA-256 - implementation from the original AvrCrypto-Lib library - [avr-crypto-lib]. Parts of SHA-256 and RSA algorithm - implementations were written in AVR-8 bit assembly language to - reduce the size and optimize the performance. The library also - takes advantage of the fact that Arduino boards allow the - programmer to directly address the flash memory to access constant - data which can save the amount of SRAM used during execution. + different symmetric key algorithms such as AES, triple DES and + SkipJack. It provides RSA as an asymmetric key algorithm. Parts + of the library were written in AVR-8 bit assembly language to + reduce the size and optimize the performance. o Relic-Toolkit [relic-toolkit]: This library is written entirely in C and provides a highly flexible and customizable implementation of a large variety of cryptographic algorithms. This not only includes RSA and ECC, but also pairing based asymmetric cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures and many more. The toolkit provides an option to build only the - desired components for the required platform. While building the - library, it is possible to select a variety of mathematical - optimizations that can be combined to obtain the desired - performance (as a general thumb rule, faster implementations - require more SRAM and flash). It includes a multi precision - integer math module which can be customized to use different bit- - length words. + desired components for the required platform. - o TinyECC [tinyecc]: TinyECC was designed for using Elliptic Curve + o TinyECC [tinyecc]: TinyECC was designed for using elliptic curve based public key cryptography on sensor networks. It is written in nesC programming language and as such is designed for specific - use on TinyOS. However, the library can be ported to standard C99 - either with hacked tool-chains or manually rewriting parts of the - code. This allows for the library to be used on platforms that do - not have TinyOS running on them. The library includes a wide - variety of mathematical optimizations such as sliding window, - Barrett reduction for verification, precomputation, etc. It also - has one of the smallest memory footprints among the set of - Elliptic Curve libraries surveyed so far. However, an advantage - of Relic over TinyECC is that it can do curves over binary fields - in addition to prime fields. + use on TinyOS. However, the library can be ported to standard C + either with tool-chains or manually rewriting parts of the code. + It also has one of the smallest memory footprints among the set of + elliptic curve libraries surveyed so far. o Wiselib [wiselib]: Wiselib is a generic library written for sensor networks containing a wide variety of algorithms. While the stable version contains algorithms for routing only, the test version includes many more algorithms including algorithms for cryptography, localization, topology management and many more. The library was designed with the idea of making it easy to interface the library with operating systems like iSense and Contiki. However, since the library is written entirely in C++ with a template based model similar to Boost/CGAL, it can be used on any platform directly without using any of the operating system interfaces provided. This approach was taken by the authors to - test the code on Arduino Uno. The structure of the code is similar - to TinyECC and like TinyECC it implements elliptic curves over - prime fields only. In order to make the code platform - independent, no assembly level optimizations were incorporated. - Since efficiency was not an important goal for the authors of the - library while designing, many well known theoretical performance - enhancement features were also not incorporated. Like the relic- - toolkit, Wiselib is also Lesser GPL licensed. + 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). However, the library in the - original form takes about 50 kB of ROM which is not suitable for - our hardware requirements. Moreover, it is intended for 32-bit - systems and the API includes functions for SSL communication - rather than just signing data with private keys. + and ECC (with a commercial license). The library in the original + form takes about 50 kB of ROM and is intended for 32-bit + platforms. + + o ARM mbed OS [mbed]: The ARM mbed operating system provides various + cryptographic primitives that are necessary for SSL/TLS protocol + implementation as well as X509 certificate handling. The library + provides an intuitive API for developer with a minimal code + foodprint. It is intended for various ARM platforms such as ARM + Cortex M0, ARM Cortex M0+ and ARM Cortex M3. This is by no ways an exhaustive list and there exist other - cryptographic libraries targeting resource-constrained devices + cryptographic libraries targeting resource-constrained devices. 8. Implementation Experiences While evaluating the implementation experiences, we were particularly interested in the signature generation operation. This was because our example application discussed in Section 9 required only the signature generation operation on the resource-constrained platforms. - We have summarized the initial results of RSA private key performance - using AvrCryptolib 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 keys were generated separately and were hard - coded into the program. All keys were generated with the value of - the public exponent as 3. The performance of signing with private - key was faster for smaller key lengths as was expected. However the - increase in the execution time was considerable when the key size was - 2048 bits. It is important to note that two different sets of - experiments were performed for each key length. In the first case, - the keys were loaded into the SRAM from the ROM (flash) before they - were used by any of the functions. However, in the second case, the - keys were addressed directly in the ROM. As was expected, the second - case used less SRAM but lead to longer execution time. - - More importantly, any RSA key size less than 2,048-bit should be - considered legacy and insecure. The performance measurements for - these keys are provided here for reference only. + 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 | Execution | Memory | Execution | Memory | - | length | time (ms); | footprint | time (ms); | footprint | - | (bits) | key in SRAM | (bytes); key | key in ROM | (bytes); key | - | | | in SRAM | | in ROM | - +--------+--------------+--------------+-------------+--------------+ - | 64 | 64 | 40 | 69 | 32 | - | 128 | 434 | 80 | 460 | 64 | - | 512 | 25076 | 320 | 27348 | 256 | - | 1024 | 199688 | 640 | 218367 | 512 | - | 2048 | 1587567 | 1,280 | 1740258 | 1024 | - +--------+--------------+--------------+-------------+--------------+ + +--------------+------------------------+---------------------------+ + | Key length | Execution time (ms); | Memory footprint (bytes); | + | (bits) | key in RAM | key in RAM | + +--------------+------------------------+---------------------------+ + | 2048 | 1587567 | 1,280 | + +--------------+------------------------+---------------------------+ RSA private key operation performance Table 1 - The code size was less than 3.6 kB for all the test cases 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 SRAM, we believe that 1024/2048-bit - operations can be performed in much less time as has been shown in - [rsa-8bit]. 2048-bit RSA is nonetheless possible with about 1 kB of - SRAM as is seen in Table 1. + The code size was about 3.6 kB with potential for further reduction. + It is also worth noting that the implementation performs basic + exponentiation and multiplication operations without using any + mathematical optimizations such as Montgomery multiplication, + optimized squaring, etc. as described in [rsa-high-speed]. With more + RAM, we believe that 2048-bit operations can be performed in much + less time as has been shown in [rsa-8bit]. In Table 2 we present the results obtained by manually porting TinyECC into C99 standard and running ECDSA signature algorithm on the Arduino Uno board. TinyECC supports a variety of SEC 2 recommended Elliptic Curve domain parameters. The execution time and memory footprint are shown next to each of the curve parameters. - SHA-1 hashing algorithm included in the library was used in each of - the cases. The measurements reflect the performance of elliptic - curve signing only and not the SHA-1 hashing algorithm. SHA-1 is now - known to be insecure and should not be used in live deployments. It - is clearly observable that for similar security levels, Elliptic - Curve public key cryptography outperforms RSA. These results were - obtained by turning on all the optimizations. These optimizations - include - Curve Specific Optimizations for modular reduction (NIST - and SEC 2 field primes were chosen as pseudo-Mersenne primes), - Sliding Window for faster scalar multiplication, Hybrid squaring - procedure written in assembly and Weighted projective Coordinate - system for efficient scalar point addition, doubling and - multiplication. We did not use optimizations like Shamir Trick and - Sliding Window as they are only useful for signature verification and - tend to slow down the signature generation by precomputing values (we - were only interested in fast signature generation). There is still - some scope for optimization as not all the assembly code provided - with the library could be ported to Arduino directly. Re-writing - these procedures in compatible assembly would further enhance the - performance. + These results were obtained by turning on all the optimizations and + using assembly code where available. It is clearly observable that + for similar security levels, Elliptic Curve public key cryptography + outperforms RSA. +-------------+---------------+-----------------+-------------------+ | Curve | Execution | Memory | Comparable RSA | | parameters | time (ms) | Footprint | key length | | | | (bytes) | | +-------------+---------------+-----------------+-------------------+ - | 128r1 | 1858 | 776 | 704 | - | 128r2 | 2002 | 776 | 704 | - | 160k1 | 2228 | 892 | 1024 | - | 160r1 | 2250 | 892 | 1024 | - | 160r2 | 2467 | 892 | 1024 | - | 192k1 | 3425 | 1008 | 1536 | - | 192r1 | 3578 | 1008 | 1536 | + | secp160k1 | 2228 | 892 | 1024 | + | secp160r1 | 2250 | 892 | 1024 | + | secp160r2 | 2467 | 892 | 1024 | + | secp192k1 | 3425 | 1008 | 1536 | + | secp192r1 | 3578 | 1008 | 1536 | +-------------+---------------+-----------------+-------------------+ - ECDSA signature performance with TinyECC + Performance of ECDSA sign operation with TinyECC Table 2 - We also performed experiments by removing the assembly code for - hybrid multiplication and squaring thus using a C only form of the - library. This gives us an idea of the performance that can be - achieved with TinyECC on any platform regardless of what kind of OS - and assembly instruction set available. The memory footprint remains - the same with our without assembly code. The tables contain the - maximum RAM that is used when all the possible optimizations are on. - If however, the amount of RAM available is smaller in size, some of - the optimizations can be turned off to reduce the memory consumption - accordingly. + We also performed experiments by removing the assembly optimization + and using a C only form of the library. This gives us an idea of the + performance that can be achieved with TinyECC on any platform + regardless of what kind of OS and assembly instruction set available. + The memory footprint remains the same with or without assembly code. + The tables contain the maximum RAM that is used when all the possible + optimizations are on. If however, the amount of RAM available is + smaller in size, some of the optimizations can be turned off to + reduce the memory consumption accordingly. +-------------+---------------+-----------------+-------------------+ | Curve | Execution | Memory | Comparable RSA | | parameters | time (ms) | Footprint | key length | | | | (bytes) | | +-------------+---------------+-----------------+-------------------+ - | 128r1 | 2741 | 776 | 704 | - | 128r2 | 3086 | 776 | 704 | - | 160k1 | 3795 | 892 | 1024 | - | 160r1 | 3841 | 892 | 1024 | - | 160r2 | 4118 | 892 | 1024 | - | 192k1 | 6091 | 1008 | 1536 | - | 192r1 | 6217 | 1008 | 1536 | + | secp160k1 | 3795 | 892 | 1024 | + | secp160r1 | 3841 | 892 | 1024 | + | secp160r2 | 4118 | 892 | 1024 | + | secp192k1 | 6091 | 1008 | 1536 | + | secp192r1 | 6217 | 1008 | 1536 | +-------------+---------------+-----------------+-------------------+ - ECDSA signature performance with TinyECC (No assembly optimizations) + Performance of ECDSA sign operation with TinyECC (No assembly + optimizations) Table 3 Table 4 documents the performance of Wiselib. Since there were no optimizations that could be turned on or off, we have only one set of results. By default Wiselib only supports some of the standard SEC 2 Elliptic curves, but it is easy to change the domain parameters and obtain results for for all the 128, 160 and 192-bit SEC 2 Elliptic - curves. SHA-1 algorithm provided in the library was used. The - measurements reflect the performance of elliptic curve signing only - and not the SHA-1 hashing algorithm. SHA-1 is now known to be - insecure and should not be used in real deployments. The ROM size - for all the experiments was less than 16 kB. + 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) | | +-------------+---------------+-----------------+-------------------+ - | 128r1 | 5615 | 732 | 704 | - | 128r2 | 5615 | 732 | 704 | - | 160k1 | 10957 | 842 | 1024 | - | 160r1 | 10972 | 842 | 1024 | - | 160r2 | 10971 | 842 | 1024 | - | 192k1 | 18814 | 952 | 1536 | - | 192r1 | 18825 | 952 | 1536 | + | secp160k1 | 10957 | 842 | 1024 | + | secp160r1 | 10972 | 842 | 1024 | + | secp160r2 | 10971 | 842 | 1024 | + | secp192k1 | 18814 | 952 | 1536 | + | secp192r1 | 18825 | 952 | 1536 | +-------------+---------------+-----------------+-------------------+ - ECDSA signature performance with Wiselib + Performance ECDSA sign operation with Wiselib Table 4 For testing the relic-toolkit we used a different board because it required more RAM/ROM and we were unable to perform experiments with it on Arduino Uno. We decided to use the Arduino Mega which has the same 8-bit architecture like the Arduino Uno but has a much larger - RAM/ROM for testing relic-toolkit. Again, SHA-1 hashing algorithm - included in the library was used in each of the cases. The - measurements reflect the performance of elliptic curve signing only - and not the SHA-1 hashing algorithm. SHA-1 is now known to be - insecure and should not be used in real deployments. The library - does provide several alternatives with such as SHA-256. + RAM/ROM for testing relic-toolkit. Again, it is important to mention + that we used Arduino as it is a convenient prototyping platform. Our + intention was to demonstrate the feasibility of the entire + architecture with public key cryptography on an 8-bit + microcontroller. However it is important to state that 32-bit + microcontrollers are much more easily available, at lower costs and + are more power efficient. Therefore, real deployments are better off + using 32-bit microcontrollers that allow developers to include the + necessary cryptographic libraries. There is no good reason to choose + platforms that do not provide sufficient computing power to run the + necessary cryptographic operations. The relic-toolkit supports Koblitz curves over prime as well as binary fields. We have experimented with Koblitz curves over binary fields only. We do not run our experiments with all the curves available in the library since the aim of this work is not prove which curves perform the fastest, and rather show that asymmetric cryptography is possible on resource-constrained devices. The results from relic-toolkit are documented in two separate tables shown in Table 5 and Table 6. The first set of results were @@ -672,60 +616,113 @@ | | | (bytes) | | +-----------------+--------------+----------------+-----------------+ | NIST K163 | 261 | 2,804 | 1024 | | (assembly math) | | | | | NIST K163 | 932 | 2750 | 1024 | | NIST B163 | 2243 | 2444 | 1024 | | NIST K233 | 1736 | 3675 | 2048 | | NIST B233 | 4471 | 3261 | 2048 | +-----------------+--------------+----------------+-----------------+ - ECDSA signature performance with relic-toolkit (Fast) + Performance of ECDSA sign operation with relic-toolkit (Fast) Table 5 +-----------------+--------------+----------------+-----------------+ | Curve | Execution | Memory | Comparable RSA | | parameters | time (ms) | Footprint | key length | | | | (bytes) | | +-----------------+--------------+----------------+-----------------+ | NIST K163 | 592 | 2087 | 1024 | | (assembly math) | | | | | NIST K163 | 2950 | 2215 | 1024 | | NIST B163 | 3213 | 2071 | 1024 | | NIST K233 | 6450 | 2935 | 2048 | | NIST B233 | 6100 | 2737 | 2048 | +-----------------+--------------+----------------+-----------------+ - ECDSA signature performance with relic-toolkit (Low Memory) + Performance of ECDSA sign operation with relic-toolkit (Low Memory) Table 6 It is important to note the following points about the elliptic curve measurements: - o As with the RSA measurements, curves giving less that 112-bit - security are insecure and considered as legacy. The measurements - are only provided for reference. - o The Arduino board only provides pseudo random numbers with the - random() function call. In order to create private keys with a - better quality of random number, we can use a true random number - generator like the one provided by TrueRandom library - [truerandom], or create the keys separately on a system with a - true random number generator and then use them directly in the - code. + random() function call. Real-world deployments must rely on a + hardware random number generator for cryptographic operations such + as generating a public-private key pair. The Nordic nRF52832 + board [nordic] for example provides a hardware random number + generator. o For measuring the memory footprint of all the ECC libraries, we used the Avrora simulator [avrora]. Only stack memory was used to easily track the RAM consumption. + Tschofenig and Pegourie-Gonnard [armecdsa] have also evaluated the + performance of Elliptic Curve Cryptography (ECC) on ARM Coretex + platform. The results for ECDSA sign operation shown in Table 7 are + performed on a Freescale FRDM-KL25Z board [freescale] that has a ARM + Cortex-M0+ 48MHz microcontroller with 128kB of flash memory and 16kB + of RAM. The sliding window technique for efficient exponentiation + was used with a window size of 2. All other optimizations were + disabled for these measurements. + + +------------------+---------------------+--------------------------+ + | Curve parameters | Execution time (ms) | Comparable RSA key | + | | | length | + +------------------+---------------------+--------------------------+ + | secp192r1 | 2165 | 1536 | + | secp224r1 | 3014 | 2048 | + | secp256r1 | 3649 | 2048 | + +------------------+---------------------+--------------------------+ + + Performance of ECDSA sign operation with ARM mbed TLS stack on + Freescale FRDM-KL25Z + + Table 7 + + The authors also measured the performance of curves on a ST Nucleo + F091 (STM32F091RCT6) board [stnucleo] that has a ARM Cortex-M0 48MHz + microcontroller with 256 kB of flash memory and 32kB of RAM. The + execution time for ECDSA sign operation with different curves is + shown in Table 8. The sliding window technique for efficient + exponentiation was used with a window size of 7. Fixed point + optimization and NIST curve specific optimizations were used for + these measurements. + + +------------------+---------------------+--------------------------+ + | Curve parameters | Execution time (ms) | Comparable RSA key | + | | | length | + +------------------+---------------------+--------------------------+ + | secp192k1 | 291 | 1536 | + | secp192r1 | 225 | 1536 | + | secp224k1 | 375 | 2048 | + | secp224r1 | 307 | 2048 | + | secp256k1 | 486 | 2048 | + | secp256r1 | 459 | 2048 | + | secp384r1 | 811 | 7680 | + | secp521r1 | 1602 | 15360 | + +------------------+---------------------+--------------------------+ + + ECDSA signature performance with ARM mbed TLS stack on ST Nucleo F091 + (STM32F091RCT6) + + Table 8 + + The authors also measured the RAM consumption by calculating the heap + consumed for the cryptographic operations using a custom memory + allocation handler. The authors did not measure the minimal stack + memory consumption. Depending on the curve and the different + optimizations enable or disabled, the memory consumption for the + ECDSA sign operation varied from 1500 bytes to 15000 bytes. + At the time of performing these measurements and study, it was unclear which exact elliptic curve(s) would be selected by the IETF community for use with resource-constrained devices. However now, [RFC7748] defines two elliptic curves over prime fields (Curve25519 and Curve448) that offer a high level of practical security for Diffie-Hellman key exchange. Correspondingly, there is ongoing work to specify elliptic curve signature schemes with Edwards-curve Digital Signature Algorithm (EdDSA). [RFC8032] specifies the recommended parameters for the edwards25519 and edwards448 curves. From these, curve25519 (for elliptic curve Diffie-Hellman key @@ -740,35 +737,35 @@ also show that signing of data using the curve Ed25519 from the NaCl library needs only 23,216,241 cycles on the same microcontroller that we used for our evaluations (Arduino Mega ATmega2560). This corresponds to about 14510 milliseconds of execution time. When compared to the results for other curves and libraries that offer similar level of security (such as NIST B233, NIST K233), this implementation far outperforms all others. As such, it is recommend that the IETF community uses these curves for protocol specification and implementations. - A summary library ROM use is shown in Table 7. + A summary library flash memory use is shown in Table 9. - +------------------------+---------------------------+ - | Library | ROM Footprint (Kilobytes) | - +------------------------+---------------------------+ + +------------------------+------------------------------------+ + | Library | Flash memory Footprint (Kilobytes) | + +------------------------+------------------------------------+ | AvrCryptolib | 3.6 | | Wiselib | 16 | | TinyECC | 18 | | Relic-toolkit | 29 | | NaCl Ed25519 [naclavr] | 17-29 | - +------------------------+---------------------------+ + +------------------------+------------------------------------+ - Summary of library ROM needs + Summary of library flash memory consumption - Table 7 + Table 9 All the measurements here are only provided as an example to show that asymmetric-key cryptography (particularly, digital signatures) is possible on resource-constrained devices. These numbers by no way are the final source for measurements and some curves presented here may not be acceptable for real in-the-wild deployments anymore. For example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also document performance of ECDSA on similar resource-constrained devices. @@ -795,22 +792,22 @@ The only role that the sensor has is to register itself at the publish-subscribe broker, and periodically update the readings. All queries from the rest of the world go to the publish-subscribe broker. We constructed a system with four entities: Sensor This is an Arduino-based device that runs a CoAP publish-subscribe - broker client and Relic-toolkit. Relic takes 29 Kbytes of ROM, - and the simple CoAP client roughly 3 kilobytes. + broker client and Relic-toolkit. Relic takes 29 Kbytes of flash + memory, and the simple CoAP client roughly 3 kilobytes. Publish-Subscribe Broker This is a publish-subscribe broker that holds resources on the sensor's behalf. The sensor registers itself to this node. Resource Directory While physically in the same node in our implementation, a resource directory is a logical function that allows sensors and @@ -827,22 +824,22 @@ The security of this system relies on an SSH-like approach. In Step 1, upon first boot, sensors generate keys and register themselves in the publish-subscribe broker. Their public key is submitted along with the registration as an attribute in the CORE Link Format data [RFC6690]. In Step 2, when the sensor makes a measurement, it sends an update to the publish-subscribe broker and signs the message contents with a JOSE signature on the used JSON/SENML payload [RFC7515] [I-D.ietf-core-senml]. The sensor can also alternatively use CBOR - Object Signing and Encryption (COSE) [I-D.ietf-cose-msg] for signing - the sensor measurement. + 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 @@ -854,95 +851,46 @@ implementation uses the standard C99 programming language on the Arduino Mega board. In this prototype, the publish-subscribe broker and the Resource Directory (RD) reside on the same physical host. A 64-bit x86 linux machine serves as the broker and the RD, while a similar but physically different 64-bit x86 linux machine serves as the client that requests data from the sensor. We chose the Relic library version 0.3.1 for our sample prototype as it can be easily compiled for different bit-length processors. Therefore, we were able to use it on the 8-bit processor of the Arduino Mega, as well as on the 64-bit processor of the x86 client. We used ECDSA to sign and - verify data updates with the standard NIST-K163 curve parameters - (163-bit Koblitz curve over binary field). While compiling Relic for - our prototype, we used the fast configuration without any assembly - optimizations. + verify data updates with the standard NIST-K163 curve parameters. + While compiling Relic for our prototype, we used the fast + configuration without any assembly optimizations. The gateway implements the CoAP base specification in the Java programming language and extends it to add support for publish- subscribe broker and Resource Directory REST interfaces. We also developed a minimalistic CoAP C-library for the Arduino sensor and for the client requesting data updates for a resource. The library - has small SRAM requirements and uses stack-based allocation only. It + has small RAM requirements and uses stack-based allocation only. It is interoperable with the Java implementation of CoAP running on the gateway. The location of the publish-subscribe broker was configured - into the smart object sensor by hardcoding the IP address. We used - an IPv4 network with public IP addresses obtained from a DHCP server. + into the smart object sensor by hardcoding the IP address. - Some important statistics of this prototype are listed in table - Table 8. Our straw man analysis of the performance of this prototype - is preliminary. Our intention was to demonstrate the feasibility of - the entire architecture with public-key cryptography on an 8-bit + 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 SRAM + considerable amount. For example, the flash memory and RAM consumption is relatively high because some of the Arduino libraries were used out-of-the-box and there are several functions which can be removed. Similarly we used the fast version of the Relic library in - the prototype instead of the low memory version. - - +-----------------------------------------------------------+-------+ - | Flash memory consumption (for the entire prototype | 51 kB | - | including Relic library + CoAP + Arduino UDP) | | - | | | - | SRAM consumption (for the entire prototype including key | 4678 | - | generation + signing the hash of message + COAP + UDP + | bytes | - | Ethernet) | | - | | | - | Execution time for creating the key pair + sending | 2030 | - | registration message + time spent waiting for | ms | - | acknowledgement | | - | | | - | Execution time for signing the hash of message + sending | 987 | - | update | ms | - | | | - | Signature overhead | 42 | - | | bytes | - +-----------------------------------------------------------+-------+ - - Prototype Performance - - Table 8 - - To demonstrate the efficacy of this communication model we compare it - with a scenario where the smart objects do not transition into the - energy saving sleep mode and directly serve temperature data to - clients. As an example, we assume that in our architecture, the - smart objects wake up once every minute to report the signed - temperature data to the caching broker. If we calculate the energy - consumption using the formula W = U * I * t (where U is the operating - voltage, I is the current drawn and t is the execution time), and use - the voltage and current values from the datasheets of the ATmega2560 - (20mA-active mode and 5.4mA-sleep mode) and W5100 (183mA) chips used - in the architecture, then in a one minute period, the Arduino board - would consume 60.9 Joules of energy if it directly serves data and - does not sleep. On the other hand, in our architecture it would only - consume 2.6 Joules if it wakes up once a minute to update the broker - with signed data. Therefore, a typical Li-ion battery that provides - about 1800 milliamps per hour (mAh) at 5V would have a lifetime of 9 - hours in the unsecured always-on scenario, whereas it would have a - lifetime of about 8.5 days in the secured sleepy architecture - presented. These lifetimes appear to be low because the Arduino - board in the prototype uses Ethernet which is not energy efficient. - The values presented only provide an estimate (ignoring the energy - required to transition in and out of the sleep mode) and would vary - depending on the hardware and MAC protocol used. Nonetheless, it is - evident that our architecture can increase the life of smart objects - by allowing them to sleep and can ensure security at the same time. + 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. 10. Design Trade-Offs This section attempts to make some early conclusions regarding trade- offs in the design space, based on deployment considerations for various mechanisms and the relative ease or difficulty of implementing them. This analysis looks at layering and the choice of symmetric vs. asymmetric cryptography. 11. Feasibility @@ -950,28 +898,29 @@ The first question is whether using cryptographic security and asymmetric cryptography in particular is feasible at all on small devices. The numbers above give a mixed message. Clearly, an implementation of a significant cryptographic operation such as public key signing can be done in surprisingly small amount of code space. It could even be argued that our chosen prototype platform was unnecessarily restrictive in the amount of code space it allows: we chose this platform on purpose to demonstrate something that is as small and difficult as possible. - In reality, ROM memory size is probably easier to grow than other - parameters in microcontrollers. 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. In short, the authors do not expect the code size to - be a significant limiting factor, both because of the small amount of - code that is needed and because available memory space is growing - rapidly. + A recent trend in microcontrollers is the introduction of 32-bit CPUs + that are becoming cheaper and more easily available than 8-bit CPUs, + in addition to being more easily programmable. The flash memory size + is probably easier to grow than other parameters in microcontrollers. + The authors do not expect the flash memory size to be the most + significant limiting factor. Before picking a platform, developers + should also plan for firmware updates. This would essentially mean + that the platform should at least have a flash memory size of the + total code size * 2, plus some space for buffer. The situation is less clear with regards to the amount of CPU power needed to run the algorithms. The demonstrated speeds are sufficient for many applications. For instance, a sensor that wakes up every now and then can likely spend a fraction of a second for the computation of a signature for the message that it is about to send. Or even spend multiple seconds in some cases. Most applications that use protocols such as DTLS that use public key cryptography only at the beginning of the session would also be fine with any of these execution times. @@ -1179,36 +1129,36 @@ sufficient advantages over the more commonly implemented transport and application layer solutions. 14. Symmetric vs. Asymmetric Crypto The second trade-off that is worth discussing is the use of plain asymmetric cryptographic mechanisms, plain symmetric cryptographic mechanisms, or some mixture thereof. Contrary to popular cryptographic community beliefs, a symmetric - crypto solution can be deployed in large scale. In fact, one of the - largest deployment of cryptographic security, the cellular network - authentication system, uses SIM cards that are based on symmetric - secrets. In contrast, public key systems have yet to show ability to - scale to hundreds of millions of devices, let alone billions. But - the authors do not believe scaling is an important differentiator - when comparing the solutions. + cryptographic solution can be deployed in large scale. In fact, one + of the largest deployment of cryptographic security, the cellular + network authentication system, uses SIM cards that are based on + symmetric secrets. In contrast, public key systems have yet to show + ability to scale to hundreds of millions of devices, let alone + billions. But the authors do not believe scaling is an important + differentiator when comparing the solutions. As can be seen from the Section 8, the time needed to calculate some - of the asymmetric crypto operations with reasonable key lengths can - be significant. There are two contrary observations that can be made - from this. First, recent wisdom indicates that computing power on - small devices is far cheaper than transmission power [wiman], and - keeps on becoming more efficient very quickly. From this we can - conclude that the sufficient CPU is or at least will be easily - available. + of the asymmetric cryptographic operations with reasonable key + lengths can be significant. There are two contrary observations that + can be made from this. First, recent wisdom indicates that computing + power on small devices is far cheaper than transmission power + [wiman], and keeps on becoming more efficient very quickly. From + this we can conclude that the sufficient CPU is or at least will be + easily available. But the other observation is that when there are very costly asymmetric operations, doing a key exchange followed by the use of generated symmetric keys would make sense. This model works very well for DTLS and other transport layer solutions, but works less well for data object security, particularly when the number of communicating entities is not exactly two. 15. Security Considerations @@ -1217,31 +1167,41 @@ 16. IANA Considerations There are no IANA impacts in this memo. 17. Informative references [arduino-uno] Arduino, "Arduino Uno", September 2015, . + [armecdsa] + Tschofenig, H. and M. Pegourie-Gonnard, "Performance + Investigations", March 2015, + . + [avr-crypto-lib] AVR-CRYPTO-LIB, "AVR-CRYPTO-LIB", September 2015, . [avr-cryptolib] Van der Laan, E., "AVR CRYPTOLIB", September 2015, . [avrora] Titzer, Ben., "Avrora", September 2015, . + [freescale] + NXP, "Freescale FRDM-KL25Z", June 2017, + . + [huang] Huang, C., "Low-overhead freshness transmission in sensor networks", 2008. [I-D.arkko-core-security-arch] Arkko, J. and A. Keranen, "CoAP Security Architecture", draft-arkko-core-security-arch-00 (work in progress), July 2011. [I-D.arkko-core-sleepy-sensors] Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. @@ -1250,74 +1210,77 @@ [I-D.daniel-6lowpan-security-analysis] Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. Laganier, "IPv6 over Low Power WPAN Security Analysis", draft-daniel-6lowpan-security-analysis-05 (work in progress), March 2011. [I-D.ietf-core-coap-pubsub] Koster, M., Keranen, A., and J. Jimenez, "Publish- Subscribe Broker for the Constrained Application Protocol - (CoAP)", draft-ietf-core-coap-pubsub-00 (work in - progress), October 2016. + (CoAP)", draft-ietf-core-coap-pubsub-02 (work in + progress), July 2017. [I-D.ietf-core-resource-directory] - Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE - Resource Directory", draft-ietf-core-resource-directory-09 - (work in progress), October 2016. + Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. + Amsuess, "CoRE Resource Directory", draft-ietf-core- + resource-directory-11 (work in progress), July 2017. [I-D.ietf-core-senml] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Bormann, "Media Types for Sensor Measurement Lists - (SenML)", draft-ietf-core-senml-04 (work in progress), - October 2016. - - [I-D.ietf-cose-msg] - Schaad, J., "CBOR Object Signing and Encryption (COSE)", - draft-ietf-cose-msg-24 (work in progress), November 2016. + (SenML)", draft-ietf-core-senml-10 (work in progress), + July 2017. [I-D.irtf-t2trg-iot-seccons] - Garcia-Morchon, O., Kumar, S., and M. Sethi, "Security - Considerations in the IP-based Internet of Things", draft- - irtf-t2trg-iot-seccons-00 (work in progress), October - 2016. + Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- + the-Art and Challenges for the Internet of Things + Security", draft-irtf-t2trg-iot-seccons-04 (work in + progress), June 2017. [I-D.moskowitz-hip-dex] Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", draft-moskowitz-hip-dex-05 (work in progress), January 2016. [I-D.sarikaya-t2trg-sbootstrapping] Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT Bootstrapping: A Survey", draft-sarikaya-t2trg- sbootstrapping-03 (work in progress), February 2017. [matrix-ssl] PeerSec Networks, "Matrix SSL", September 2015, . + [mbed] ARM, "mbed TLS", May 2017, + . + [micronacl] MicroNaCl, "The Networking and Cryptography library for microcontrollers", . [mosdorf] Mosdorf, M. and W. Zabolotny, "Implementation of elliptic curve cryptography for 8 bit and 32 bit embedded systems time efficiency and power consumption analysis", Pomiary Automatyka Kontrola , 2010. [nacl] NaCl, "Networking and Cryptography library", . [naclavr] Hutter, M. and P. Schwabe, "NaCl on 8-Bit AVR Microcontrollers", International Conference on Cryptology in Africa , Springer Berlin Heidelberg , 2013. + [nordic] Nordic Semiconductor, "nRF52832 Product Specification", + June 2017, . + [relic-toolkit] Aranha, D. and C. Gouv, "Relic Toolkit", September 2015, . [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, . [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", @@ -1357,20 +1320,25 @@ January 2012, . [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + . + [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . @@ -1390,37 +1358,42 @@ [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation", RFC 7815, DOI 10.17487/RFC7815, March 2016, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . + [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", + RFC 8152, DOI 10.17487/RFC8152, July 2017, + . + [rsa-8bit] Gura, N., Patel, A., Wander, A., Eberle, H., and S. Shantz, "Comparing Elliptic Curve Cryptography and RSA on 8-bit CPUs", 2010. [rsa-high-speed] Koc, C., "High-Speed RSA Implementation", November 1994, . + [stnucleo] + STMicroelectronics, "NUCLEO-F091RC", June 2017, + . + [tinyecc] North Carolina State University and North Carolina State University, "TinyECC", 2008, . - [truerandom] - Drow, C., "Truerandom", September 2015, - . - [wiman] Margi, C., Oliveira, B., Sousa, G., Simplicio, M., Paulo, S., Carvalho, T., Naslund, M., and R. Gold, "Impact of Operating Systems on Wireless Sensor Networks (Security) Applications and Testbeds.", International Conference on Computer Communication Networks (ICCCN'2010) / IEEE International Workshop on Wireless Mesh and Ad Hoc Networks (WiMAN 2010) , 2010. [wiselib] Baumgartner, T., Chatzigiannakis, I., Fekete, S., Koninis, C., Kroller, A., and A. Pyrgelis, "Wiselib", 2010,