--- 1/draft-ietf-lwig-crypto-sensors-04.txt 2017-12-25 08:13:18.866199446 -0800 +++ 2/draft-ietf-lwig-crypto-sensors-05.txt 2017-12-25 08:13:18.934201041 -0800 @@ -1,129 +1,140 @@ Light-Weight Implementation Guidance M. Sethi Internet-Draft J. Arkko Intended status: Informational A. Keranen -Expires: February 9, 2018 Ericsson +Expires: June 27, 2018 Ericsson H. Back Comptel - August 8, 2017 + December 24, 2017 Practical Considerations and Implementation Experiences in Securing Smart Object Networks - draft-ietf-lwig-crypto-sensors-04 + draft-ietf-lwig-crypto-sensors-05 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 small devices and presents some preliminary experiences with those libraries for message signing on small devices. Lastly, the memo discusses trade-offs involving different types of security approaches. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. + Drafts is at https://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 February 9, 2018. + This Internet-Draft will expire on June 27, 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 + (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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5 - 5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 6 - 6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8 - 7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 9 - 8. Implementation Experiences . . . . . . . . . . . . . . . . . 10 - 9. Example Application . . . . . . . . . . . . . . . . . . . . . 17 - 10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 20 - 11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 25 - 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 - 17. Informative references . . . . . . . . . . . . . . . . . . . 26 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 31 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 + 4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 6 + 4.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 6 + 4.2. Protocol Architecture . . . . . . . . . . . . . . . . . . 9 + 5. Code Availability . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Implementation Experiences . . . . . . . . . . . . . . . . . 11 + 7. Example Application . . . . . . . . . . . . . . . . . . . . . 18 + 8. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 20 + 8.1. Feasibility . . . . . . . . . . . . . . . . . . . . . . . 20 + 8.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 22 + 8.3. Layering . . . . . . . . . . . . . . . . . . . . . . . . 24 + 8.4. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . 25 + 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 12. Informative references . . . . . . . . . . . . . . . . . . . 27 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 33 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction This memo describes challenges associated with securing smart object devices in constrained implementations and environments. In Section 3 we specifically discuss three challenges: the implementation difficulties encountered on resource-constrained platforms, the problem of provisioning keys and making the choice of implementing security at the appropriate layer. Section 4 discusses a deployment model that the authors are considering for constrained environments. The model requires minimal amount of configuration, and we believe it is a natural fit with the typical communication practices in smart object networking environments. - Section 7 discusses the availability of cryptographic libraries. - Section 8 presents some experiences in implementing cryptography on + Section 5 discusses the availability of cryptographic libraries. + Section 6 presents some experiences in implementing cryptography on small devices using those libraries, including information about achievable code sizes and speeds on typical hardware. - Finally, Section 10 discusses trade-offs involving different types of + Finally, Section 8 discusses trade-offs involving different types of security approaches. 2. Related Work Constrained Application Protocol (CoAP) [RFC7252] is a light-weight protocol designed to be used in machine-to-machine applications such as smart energy and building automation. Our discussion uses this protocol as an example, but the conclusions may apply to other similar protocols. CoAP base specification [RFC7252] outlines how to use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol. DTLS can be applied with pairwise shared keys, raw public keys or with certificates. The security model in all cases is mutual authentication, so while there is some commonality to HTTP [RFC7230] in verifying the server identity, in practice the models are quite different. The use of IPsec with CoAP is described with regards to the protocol requirements, noting that small implementations of IKEv2 exist [RFC7815]. However, the CoAP specification is silent on policy and other aspects that are normally necessary in order to implement interoperable use of IPsec in any environment [RFC5406]. + [I-D.irtf-t2trg-iot-seccons] documents the different stages in the + lifecycle of a smart object. Next, it highlights the security + threats for smart objects and the challenges that one might face to + protect against these threats. The document also looks at various + security protocols available, including IKEv2/IPsec [RFC7296], TLS/ + SSL [RFC5246], DTLS [RFC6347], HIP [RFC7401], + [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP [RFC3748]. Lastly, + [I-D.sarikaya-t2trg-sbootstrapping] discusses bootstrapping + mechanisms available for resource-constrained IoT devices. + [RFC6574] gives an overview of the security discussions at the March 2011 IAB workshop on smart objects. The workshop recommended that additional work is needed in developing suitable credential management mechanisms (perhaps something similar to the Bluetooth pairing mechanism), understanding the implementability of standard security mechanisms in small devices, and additional research in the area of lightweight cryptographic primitives. [I-D.moskowitz-hip-dex] defines a light-weight version of the HIP protocol for low-power nodes. This version uses a fixed set of @@ -136,31 +147,20 @@ [I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis of security issues related to 6LoWPAN networks, but its findings also apply more generally for all low-powered networks. Some of the issues this document discusses include the need to minimize the number of transmitted bits and simplify implementations, threats in the smart object networking environments, and the suitability of 6LoWPAN security mechanisms, IPsec, and key management protocols for implementation in these environments. - [I-D.irtf-t2trg-iot-seccons] discusses the overall security problem - for Internet of Things devices. It also discusses various solutions, - including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347], - HIP [RFC7401] [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP - [RFC3748]. The draft also discusses various operational scenarios, - and challenges associated with implementing security mechanisms in - these environments. - - [I-D.sarikaya-t2trg-sbootstrapping] discusses bootstrapping - mechanisms available for resource-constrained IoT devices. - 3. Challenges This section discusses three challenges: 1) implementation difficulties, 2) practical provisioning problems, 3) layering and communication models. One of the most often discussed issues in the security for the Internet of Things relate to implementation difficulties. The desire to build small, battery-operated, and inexpensive devices drives the creation of devices with a limited protocol and application suite. @@ -182,44 +182,55 @@ 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 + This is perhaps the most fundamental and difficult issue, and unfortunately often neglected in the design. There are several problems in the provisioning and management of smart object networks: o Small devices have no natural user interface for configuration that would be required for the installation of shared secrets and other security-related parameters. Typically, there is no keyboard, no display, and there may not even be buttons to press. Some devices may only have one interface, the interface to the network. o Manual configuration is rarely, if at all, possible, as the necessary skills are missing in typical installation environments (such as in family homes). o There may be a large number of devices. Configuration tasks that may be acceptable when performed for one device may become unacceptable with dozens or hundreds of devices. + o 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. + 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, small resource-constrained devices + are often shipped with a single static identity. In many cases, it + is a single raw public key. These long-term static identities makes + it easy to track the devices (and their owners) when they move. The + static identities may also allow an attacker to track these devices + across ownership changes. + Finally, layering and communication models present difficulties for straightforward use of the most obvious security mechanisms. Smart object networks typically pass information through multiple participating nodes [I-D.arkko-core-sleepy-sensors] and end-to-end security for IP or transport layers may not fit such communication models very well. The primary reasons for needing middleboxes relates to the need to accommodate for sleeping nodes as well to enable the implementation of nodes that store or aggregate information. @@ -235,21 +246,21 @@ [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. | here denotes the concatenation operator. -5. Provisioning +4.1. Provisioning As it is difficult to provision security credentials, shared secrets, and policy information, the provisioning model is based only on the secure identities. A typical network installation involves physical placement of a number of devices while noting the identities of these devices. This list of short identifiers can then be fed to a central server as a list of authorized devices. Secure communications can then commence with the devices, at least as far as information from from the devices to the server is concerned, which is what is needed for sensor networks. @@ -271,30 +282,33 @@ installation time. This requires either a separate user interface, local connection (such as USB), or using the network interface of the device for configuration. In any case, as with sensor networks the amount of configuration information is minimized: just one short identity value needs to be fed in. Not both an identity and a certificate. Not shared secrets that must be kept confidential. An even simpler provisioning approach is that the devices in the device group trust each other. Then no configuration is needed at installation time. - When both peers know the expected cryptographic identity of the other + Once both peers know the expected cryptographic identity of the other peer off-line, secure communications can commence. Alternatively, various pairing schemes can be employed. Note that these schemes can benefit from the already secure identifiers on the device side. For instance, the server can send a pairing message to each device after their initial power-on and before they have been paired with anyone, encrypted with the public key of the device. As with all pairing schemes that do not employ a shared secret or the secure identity of both parties, there are some remaining vulnerabilities that may or - may not be acceptable for the application in question. + may not be acceptable for the application in question. For example, + leap-of-faith or trust-on-first-use based pairing methods assume that + the attacker is not present during the initial setup and are + vulnerable to eavesdropping or man-in-the-middle (MitM) attacks. In any case, the secure identities help again in ensuring that the operations are as simple as possible. Only identities need to be communicated to the devices, not certificates, not shared secrets or e.g. IPsec policy rules. Where necessary, the information collected at installation time may also include other parameters relevant to the application, such as the location or purpose of the devices. This would enable the server to know, for instance, that a particular device is the temperature @@ -325,20 +339,32 @@ communicate with, messages from the peer can be signed by the peer's private key and it is trivial to verify that the message came from the expected peer. There is no need to configure an identity and certificate of that identity separately. There is no need to configure a group secret or a shared secret. There is no need to configure a trust anchor. In addition, the identities are typically collected anyway for application purposes (such as identifying which sensor is in which room). Under most circumstances there is actually no additional configuration effort from provisioning security. + As discussed in the previous section, long-term static identities + negatively affect the privacy of the devices and their owners. + Therefore, it is beneficial for devices to generate new identities at + appropriate times during their lifecycle. For example, after a + factory reset or an ownership handover. Thus, in our proposed + deployment model, the devices would generate a new asymmetric key + pair and use the new public-key P' to generate the new identity I'. + It is also desirable that these identities are only used during the + provisioning stage. Temporary identities (such as IPv6 addresses) + can be used for network communication protocols once the device is + operational. + Groups of devices can be managed through single identifiers as well. In these deployment cases it is also possible to configure the identity of an entire group of devices, rather than registering the individual devices. For instance, many installations employ a kit of devices bought from the same manufacturer in one package. It is easy to provide an identity for such a set of devices as follows: Idev = h(Pdev|Potherdev1|Potherdev2|...|Potherdevn) Igrp = h(Pdev1|Pdev2|...|Pdevm) @@ -351,21 +377,21 @@ The installation personnel can scan the identity of the group from the box that the kit came in, and this identity can be stored in a server that is expected to receive information from the nodes. Later when the individual devices contact this server, they will be able to show that they are part of the group, as they can reveal their own public key and the public keys of the other devices. Devices that do not belong to the kit can not claim to be in the group, because the group identity would change if any new keys were added to Igrp. -6. Protocol Architecture +4.2. Protocol Architecture As noted above, the starting point of the architecture is that nodes self-generate secure identities which are then communicated out-of- band to the peers that need to know what devices to trust. To support this model in a protocol architecture, we also need to use these secure identities to implement secure messaging between the peers, explain how the system can respond to different types of attacks such as replay attempts, and decide at what protocol layer and endpoints the architecture should use. @@ -391,28 +417,32 @@ such as a protocol translators or even NATs (not that we recommend their use in these environments). However, as we will see later there are also some technical implications, namely that link, network, and transport layer solutions are more likely to be able to benefit from sessions where the cost of expensive operations can be amortized over multiple data transmissions. While this is not impossible in data object security solutions either, it is not the typical arrangement either. -7. Code Availability +5. Code Availability For implementing public key cryptography on resource constrained environments, we chose Arduino Uno board [arduino-uno] as the test platform. Arduino Uno has an ATmega328 microcontroller, an 8-bit processor with a clock speed of 16 MHz, 2 kB of RAM, and 32 kB of - flash memory. Our choice of 8-bit platform may be surprising since - it. + flash memory. Our choice of a 8-bit platform may seem surprising + since cheaper and more energy-efficient 32-bit platforms are + available. However, our intention was to evaluate the performance of + public-key cryptography on the smallest platforms available. It is + reasonable to expect better performance results from 32-bit + microcontrollers. For selecting potential asymmetric cryptographic libraries, we surveyed and came up with a set of possible code sources, and performed an initial analysis of how well they fit the Arduino environment. Note that the results are preliminary, and could easily be affected in any direction by implementation bugs, configuration errors, and other mistakes. It is advisable to verify the numbers before relying on them for building something. No significant effort was done to optimize ROM memory usage beyond what the libraries provided themselves, so those numbers should be taken as upper @@ -458,31 +488,31 @@ o MatrixSSL [matrix-ssl]: This library provides a low footprint implementation of several cryptographic algorithms including RSA and ECC (with a commercial license). The library in the original form takes about 50 kB of ROM and is intended for 32-bit platforms. o ARM mbed OS [mbed]: The ARM mbed operating system provides various cryptographic primitives that are necessary for SSL/TLS protocol implementation as well as X509 certificate handling. The library provides an intuitive API for developer with a minimal code - foodprint. It is intended for various ARM platforms such as ARM + footprint. It is intended for various ARM platforms such as ARM Cortex M0, ARM Cortex M0+ and ARM Cortex M3. This is by no ways an exhaustive list and there exist other cryptographic libraries targeting resource-constrained devices. -8. Implementation Experiences +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 9 required only the + 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); | @@ -646,21 +676,23 @@ Table 6 It is important to note the following points about the elliptic curve measurements: o The Arduino board only provides pseudo random numbers with the random() function call. Real-world deployments must rely on a hardware random number generator for cryptographic operations such as generating a public-private key pair. The Nordic nRF52832 board [nordic] for example provides a hardware random number - generator. + 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 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 @@ -763,21 +795,21 @@ All the measurements here are only provided as an example to show that asymmetric-key cryptography (particularly, digital signatures) is possible on resource-constrained devices. These numbers by no way are the final source for measurements and some curves presented here may not be acceptable for real in-the-wild deployments anymore. For example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also document performance of ECDSA on similar resource-constrained devices. -9. Example Application +7. Example Application We developed an example application on the Arduino platform to use public key crypto mechanisms, data object security, and an easy provisioning model. Our application was originally developed to test different approaches to supporting communications to "always off" sensor nodes. These battery-operated or energy scavenging nodes do not have enough power to be stay on at all times. They wake up periodically and transmit their readings. Such sensor nodes can be supported in various ways. @@ -863,45 +896,45 @@ While compiling Relic for our prototype, we used the fast configuration without any assembly optimizations. The gateway implements the CoAP base specification in the Java programming language and extends it to add support for publish- subscribe broker and Resource Directory REST interfaces. We also developed a minimalistic CoAP C-library for the Arduino sensor and for the client requesting data updates for a resource. The library has small RAM requirements and uses stack-based allocation only. It is interoperable with the Java implementation of CoAP running on the - gateway. The location of the publish-subscribe broker was configured - into the smart object sensor by hardcoding the IP address. + gateway. The location of the resource directory was configured into + the smart object sensor by hardcoding the IP address. Our intention was to demonstrate that it is possible to implement the entire architecture with public-key cryptography on an 8-bit microcontroller. The stated values can be improved further by a considerable amount. For example, the flash memory and RAM consumption is relatively high because some of the Arduino libraries were used out-of-the-box and there are several functions which can be removed. Similarly we used the fast version of the Relic library in the prototype instead of the low memory version. However, it is important to note that this was only a research prototype to verify the feasibility of this architecture and as stated elsewhere, most modern development boards have a 32-bit microcontroller since they are more economical and have better energy efficiency. -10. Design Trade-Offs +8. Design Trade-Offs This section attempts to make some early conclusions regarding trade- offs in the design space, based on deployment considerations for various mechanisms and the relative ease or difficulty of - implementing them. This analysis looks at layering and the choice of - symmetric vs. asymmetric cryptography. + implementing them. In particular, this analysis looks at layering, + freshness and the choice of symmetric vs. asymmetric cryptography. -11. Feasibility +8.1. Feasibility The first question is whether using cryptographic security and asymmetric cryptography in particular is feasible at all on small devices. The numbers above give a mixed message. Clearly, an implementation of a significant cryptographic operation such as public key signing can be done in surprisingly small amount of code space. It could even be argued that our chosen prototype platform was unnecessarily restrictive in the amount of code space it allows: we chose this platform on purpose to demonstrate something that is as small and difficult as possible. @@ -929,35 +962,45 @@ Yet, with reasonably long key sizes the execution times are in the seconds, dozens of seconds, or even longer. For some applications this is too long. Nevertheless, the authors believe that these algorithms can successfully be employed in small devices for the following reasons: o With the right selection of algorithms and libraries, the execution times can actually be very small (less than 500 ms). o As discussed in [wiman], in general the power requirements - necessary to send or receive messages are far bigger than those - needed to execute cryptographic operations. While there are newer - radios that significantly lower the energy consumption of sending - and receiving messages, there is no good reason to choose - platforms that do not provide sufficient computing power to run - the necessary cryptographic operations. + necessary to turn the radio on/off and sending or receiving + messages are far bigger than those needed to execute cryptographic + operations. While there are newer radios that significantly lower + the energy consumption of sending and receiving messages, there is + no good reason to choose platforms that do not provide sufficient + computing power to run the necessary cryptographic operations. o Commercial libraries and the use of full potential for various optimizations will provide a better result than what we arrived at in this memo. - o Using public key cryptography only at the beginning of a session + o Using public-key cryptography only at the beginning of a session will reduce the per-packet processing times significantly. -12. Freshness + While we did not do an exhaustive performance evaluation of + asymmetric key pair generation on resource-constrained devices, we + did note that it is possible for such devices to generate a new key + pair. Given that this operation would only occur in rare + circumstances (such as a factory reset or ownership change) and its + potential privacy benefits, developers should provide mechanisms for + generating new identities. It is however extremely important to note + that the security of this operation relies on access to + cryptographic-quality randomness. + +8.2. Freshness In our architecture, if implemented as described thus far, messages along with their signatures sent from the sensors to the publish- subscribe broker can be recorded and replayed by an eavesdropper. The publish-subscribe broker has no mechanism to distinguish previously received packets from those that are retransmitted by the sender or replayed by an eavesdropper. Therefore, it is essential for the smart objects to ensure that data updates include a freshness indicator. However, ensuring freshness on constrained devices can be non-trivial because of several reasons which include: @@ -1041,21 +1084,21 @@ obtain the current time from NTP, but this may consume additional energy and give rise to security issues discussed in [RFC5905]. The smart objects could also have access to a mobile network or the Global Positioning System (GPS), and they can be used obtain the current time. Finally, if the sensors need to co-ordinate their sleep cycles, or if the publish-subscribe broker computes an average or mean of updates collected from multiple smart objects, it is important for the network nodes to synchronize the time among them. This can be done by using existing synchronization schemes. -13. Layering +8.3. Layering It would be useful to select just one layer where security is provided at. Otherwise a simple device needs to implement multiple security mechanisms. While some code can probably be shared across such implementations (like algorithms), it is likely that most of the code involving the actual protocol machinery cannot. Looking at the different layers, here are the choices and their implications: link layer @@ -1123,70 +1166,95 @@ The downside is that the lower layers are not protected. But again, as long as the data is protected and checked upon every time it passes through an application level entity, it is not clear that there are attacks beyond denial-of-service. The main question mark is whether this type of a solution provides sufficient advantages over the more commonly implemented transport and application layer solutions. -14. Symmetric vs. Asymmetric Crypto +8.4. Symmetric vs. Asymmetric Crypto The second trade-off that is worth discussing is the use of plain asymmetric cryptographic mechanisms, plain symmetric cryptographic mechanisms, or some mixture thereof. Contrary to popular cryptographic community beliefs, a symmetric cryptographic solution can be deployed in large scale. In fact, one of the largest deployment of cryptographic security, the cellular network authentication system, uses SIM cards that are based on symmetric secrets. In contrast, public key systems have yet to show ability to scale to hundreds of millions of devices, let alone billions. But the authors do not believe scaling is an important differentiator when comparing the solutions. - As can be seen from the Section 8, the time needed to calculate some + As can be seen from the Section 6, the time needed to calculate some of the asymmetric cryptographic operations with reasonable key lengths can be significant. There are two contrary observations that can be made from this. First, recent wisdom indicates that computing power on small devices is far cheaper than transmission power [wiman], and keeps on becoming more efficient very quickly. From this we can conclude that the sufficient CPU is or at least will be easily available. But the other observation is that when there are very costly asymmetric operations, doing a key exchange followed by the use of generated symmetric keys would make sense. This model works very well for DTLS and other transport layer solutions, but works less well for data object security, particularly when the number of communicating entities is not exactly two. -15. Security Considerations +9. Summary + + This document makes several security recommendations based on our + implementation experience. We summarize some of the important ones + here: + + o Developers and product designers should choose the hardware after + determining the security requirements for their application + scenario. + + o Elliptic Curve Cryptography (ECC) outperforms RSA based operations + and therefore it is recommended for resource-constrained devices. + + o Cryptographic-quality randomness is needed for many security + protocols. Developers and vendors should ensure that the + sufficient randomness is available for security critical tasks. + + o 32-bit microcontrollers are much more easily available, at lower + costs and are more power efficient. Therefore, real-world + deployments are better off using 32-bit microcontrollers. + + o Planning for firmware updates is important. The hardware platform + chosen should at least have a flash memory size of the total code + size * 2, plus some space for buffer. + +10. Security Considerations This entire memo deals with security issues. -16. IANA Considerations +11. IANA Considerations There are no IANA impacts in this memo. -17. Informative references +12. Informative references [arduino-uno] Arduino, "Arduino Uno", September 2015, . [armecdsa] Tschofenig, H. and M. Pegourie-Gonnard, "Performance Investigations", March 2015, - . + . [avr-crypto-lib] AVR-CRYPTO-LIB, "AVR-CRYPTO-LIB", September 2015, . [avr-cryptolib] Van der Laan, E., "AVR CRYPTOLIB", September 2015, . [avrora] Titzer, Ben., "Avrora", September 2015, @@ -1217,33 +1285,33 @@ [I-D.ietf-core-coap-pubsub] Koster, M., Keranen, A., and J. Jimenez, "Publish- Subscribe Broker for the Constrained Application Protocol (CoAP)", draft-ietf-core-coap-pubsub-02 (work in progress), July 2017. [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, "CoRE Resource Directory", draft-ietf-core- - resource-directory-11 (work in progress), July 2017. + resource-directory-12 (work in progress), October 2017. [I-D.ietf-core-senml] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Bormann, "Media Types for Sensor Measurement Lists - (SenML)", draft-ietf-core-senml-10 (work in progress), - July 2017. + (SenML)", draft-ietf-core-senml-12 (work in progress), + December 2017. [I-D.irtf-t2trg-iot-seccons] Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- the-Art and Challenges for the Internet of Things - Security", draft-irtf-t2trg-iot-seccons-04 (work in - progress), June 2017. + Security", draft-irtf-t2trg-iot-seccons-09 (work in + progress), December 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. @@ -1275,107 +1343,112 @@ 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)", RFC 3972, DOI 10.17487/RFC3972, March 2005, - . + . + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, - . + . [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, - May 2008, . + May 2008, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, - . + . [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, - February 2009, . + February 2009, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, - . + . [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078, - January 2011, . + January 2011, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, - January 2012, . + 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, . + 2014, . [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, - . + . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May - 2015, . + 2015, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January - 2016, . + 2016, . [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation", RFC 7815, DOI 10.17487/RFC7815, March 2016, - . + . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, - . + . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, - . + . [rsa-8bit] Gura, N., Patel, A., Wander, A., Eberle, H., and S. Shantz, "Comparing Elliptic Curve Cryptography and RSA on 8-bit CPUs", 2010. [rsa-high-speed] Koc, C., "High-Speed RSA Implementation", November 1994, .