idnits 2.17.1 draft-ietf-lwig-crypto-sensors-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 26, 2018) is 2251 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-03 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-12 == Outdated reference: A later version (-16) exists of draft-ietf-core-senml-12 == Outdated reference: A later version (-16) exists of draft-irtf-t2trg-iot-seccons-11 == Outdated reference: A later version (-11) exists of draft-sarikaya-t2trg-sbootstrapping-03 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Light-Weight Implementation Guidance M. Sethi 3 Internet-Draft J. Arkko 4 Intended status: Informational A. Keranen 5 Expires: August 30, 2018 Ericsson 6 H. Back 7 Nokia 8 February 26, 2018 10 Practical Considerations and Implementation Experiences in Securing 11 Smart Object Networks 12 draft-ietf-lwig-crypto-sensors-06 14 Abstract 16 This memo describes challenges associated with securing resource- 17 constrained smart object devices. The memo describes a possible 18 deployment model where resource-constrained devices sign message 19 objects, discusses the availability of cryptographic libraries for 20 resource-constrained devices and presents some preliminary 21 experiences with those libraries for message signing on resource- 22 constrained devices. Lastly, the memo discusses trade-offs involving 23 different types of security approaches. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 30, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 6 63 4.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. Protocol Architecture . . . . . . . . . . . . . . . . . . 9 65 5. Code Availability . . . . . . . . . . . . . . . . . . . . . . 10 66 6. Implementation Experiences . . . . . . . . . . . . . . . . . 11 67 7. Example Application . . . . . . . . . . . . . . . . . . . . . 18 68 8. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21 69 8.1. Feasibility . . . . . . . . . . . . . . . . . . . . . . . 21 70 8.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 22 71 8.3. Layering . . . . . . . . . . . . . . . . . . . . . . . . 24 72 8.4. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . 26 73 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 76 12. Informative references . . . . . . . . . . . . . . . . . . . 27 77 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 34 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 80 1. Introduction 82 This memo describes challenges associated with securing smart object 83 devices in constrained implementations and environments. In 84 Section 3 we specifically discuss three challenges: the 85 implementation difficulties encountered on resource-constrained 86 platforms, the problem of provisioning keys and making the choice of 87 implementing security at the appropriate layer. 89 Section 4 discusses a potential deployment model for constrained 90 environments. The model requires minimal amount of configuration, 91 and we believe it is a natural fit with the typical communication 92 practices in smart object networking environments. 94 Section 5 discusses the availability of cryptographic libraries. 95 Section 6 presents some experiences in implementing cryptography on 96 resource-constrained devices using those libraries, including 97 information about achievable code sizes and speeds on typical 98 hardware. 100 Finally, Section 8 discusses trade-offs involving different types of 101 security approaches. 103 2. Related Work 105 Constrained Application Protocol (CoAP) [RFC7252] is a light-weight 106 protocol designed to be used in machine-to-machine applications such 107 as smart energy and building automation. Our discussion uses this 108 protocol as an example, but the conclusions may apply to other 109 similar protocols. The CoAP base specification [RFC7252] outlines 110 how to use DTLS [RFC6347] and IPsec [RFC4303] for securing the 111 protocol. DTLS can be applied with pairwise shared keys, raw public 112 keys or with certificates. The security model in all cases is mutual 113 authentication, so while there is some commonality to HTTP [RFC7230] 114 in verifying the server identity, in practice the models are quite 115 different. The use of IPsec with CoAP is described with regards to 116 the protocol requirements, noting that lightweight implementations of 117 IKEv2 exist [RFC7815]. However, the CoAP specification is silent on 118 policy and other aspects that are normally necessary in order to 119 implement interoperable use of IPsec in any environment [RFC5406]. 121 [I-D.irtf-t2trg-iot-seccons] documents the different stages in the 122 lifecycle of a smart object. Next, it highlights the security 123 threats for smart objects and the challenges that one might face to 124 protect against these threats. The document also looks at various 125 security protocols available, including IKEv2/IPsec [RFC7296], TLS/ 126 SSL [RFC5246], DTLS [RFC6347], HIP [RFC7401], 127 [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP [RFC3748]. Lastly, 128 [I-D.sarikaya-t2trg-sbootstrapping] discusses bootstrapping 129 mechanisms available for resource-constrained IoT devices. 131 [RFC6574] gives an overview of the security discussions at the March 132 2011 IAB workshop on smart objects. The workshop recommended that 133 additional work should be undertaken in developing suitable 134 credential management mechanisms (perhaps something similar to the 135 Bluetooth pairing mechanism), understanding the implementability of 136 standard security mechanisms in resource-constrained devices, and 137 additional research in the area of lightweight cryptographic 138 primitives. 140 [I-D.moskowitz-hip-dex] defines a light-weight version of the HIP 141 protocol for low-power nodes. This version uses a fixed set of 142 algorithms, Elliptic Curve Cryptography (ECC), and eliminates hash 143 functions. The protocol still operates based on host identities, and 144 runs end-to-end between hosts, protecting all IP layer 145 communications. [RFC6078] describes an extension of HIP that can be 146 used to send upper layer protocol messages without running the usual 147 HIP base exchange at all. 149 [I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis 150 of security issues related to 6LoWPAN networks, but its findings also 151 apply more generally for all low-powered networks. Some of the 152 issues this document discusses include the need to minimize the 153 number of transmitted bits and simplify implementations, threats in 154 the smart object networking environments, and the suitability of 155 6LoWPAN security mechanisms, IPsec, and key management protocols for 156 implementation in these environments. 158 3. Challenges 160 This section discusses three challenges: 1) implementation 161 difficulties, 2) practical provisioning problems, 3) layering and 162 communication models. 164 One of the most often discussed issues in the security for the 165 Internet of Things relate to implementation difficulties. The desire 166 to build resource-constrained, battery-operated, and inexpensive 167 devices drives the creation of devices with a limited protocol and 168 application suite. Some of the typical limitations include running 169 CoAP instead of HTTP, limited support for security mechanisms, 170 limited processing power for long key lengths, sleep schedule that 171 does not allow communication at all times, and so on. In addition, 172 the devices typically have very limited support for configuration, 173 making it hard to set up secrets and trust anchors. 175 The implementation difficulties are important, but they should not be 176 overemphasized. It is important to select the right security 177 mechanisms and avoid duplicated or unnecessary functionality. But at 178 the end of the day, if strong cryptographic security is needed, the 179 implementations have to support that. It is important for developers 180 and product designers to determine what security threats they want to 181 tackle and the resulting security requirements before selecting the 182 hardware. Often, development work in the wild happens in the wrong 183 order: a particular platform with a resource-constrained 184 microcontroller is chosen first, and then the security features that 185 can fit on it are decided. Also, the use of the most lightweight 186 algorithms and cryptographic primitives is useful, but should not be 187 the only consideration in the design and development. 188 Interoperability is also important, and often other parts of the 189 system, such as key management protocols or certificate formats are 190 heavier to implement than the algorithms themselves. 192 The second challenge relates to practical provisioning problems. 193 This is perhaps the most fundamental and difficult issue, and 194 unfortunately often neglected in the design. There are several 195 problems in the provisioning and management of smart object networks: 197 o Resource-constrained devices have no natural user interface for 198 configuration that would be required for the installation of 199 shared secrets and other security-related parameters. Typically, 200 there is no keyboard, no display, and there may not even be 201 buttons to press. Some devices may only have one interface, the 202 interface to the network. 204 o Manual configuration is rarely, if at all, possible, as the 205 necessary skills are missing in typical installation environments 206 (such as in family homes). 208 o There may be a large number of devices. Configuration tasks that 209 may be acceptable when performed for one device may become 210 unacceptable with dozens or hundreds of devices. 212 o Smart object networks may rely on different radio technologies. 213 Provisioning methods that rely on specific link-layer features may 214 not work with other radio technologies in a heterogeneous network. 216 o Network configurations evolve over the lifetime of the devices, as 217 additional devices are introduced or addresses change. Various 218 central nodes may also receive more frequent updates than 219 individual devices such as sensors embedded in building materials. 221 In light of the above challenges, resource-constrained devices are 222 often shipped with a single static identity. In many cases, it is a 223 single raw public key. These long-term static identities makes it 224 easy to track the devices (and their owners) when they move. The 225 static identities may also allow an attacker to track these devices 226 across ownership changes. 228 Finally, layering and communication models present difficulties for 229 straightforward use of the most obvious security mechanisms. Smart 230 object networks typically pass information through multiple 231 participating nodes [I-D.arkko-core-sleepy-sensors] and end-to-end 232 security for IP or transport layers may not fit such communication 233 models very well. The primary reasons for needing middleboxes 234 relates to the need to accommodate for sleeping nodes as well to 235 enable the implementation of nodes that store or aggregate 236 information. 238 4. Proposed Deployment Model 240 [I-D.arkko-core-security-arch] recognizes the provisioning model as 241 the driver of what kind of security architecture is useful. This 242 section re-introduces this model briefly here in order to facilitate 243 the discussion of the various design alternatives later. 245 The basis of the proposed architecture are self-generated secure 246 identities, similar to Cryptographically Generated Addresses (CGAs) 247 [RFC3972] or Host Identity Tags (HITs) [RFC7401]. That is, we assume 248 the following holds: 250 I = h(P|O) 252 where I is the secure identity of the device, h is a hash function, P 253 is the public key from a key pair generated by the device, and O is 254 optional other information. | here denotes the concatenation 255 operator. 257 4.1. Provisioning 259 As it is difficult to provision security credentials, shared secrets, 260 and policy information, the provisioning model is based only on the 261 secure identities. A typical network installation involves physical 262 placement of a number of devices while noting the identities of these 263 devices. This list of short identifiers can then be fed to a central 264 server as a list of authorized devices. Secure communications can 265 then commence with the devices, at least as far as information from 266 from the devices to the server is concerned, which is what is needed 267 for sensor networks. 269 The above architecture is a perfect fit for sensor networks where 270 information flows from large number of devices to small number of 271 servers. But it is not sufficient alone for other types of 272 applications. For instance, in actuator applications a large number 273 of devices need to take commands from somewhere else. In such 274 applications it is necessary to secure that the commands come from an 275 authorized source. 277 This can be supported, with some additional provisioning effort and 278 optional pairing protocols. The basic provisioning approach is as 279 described earlier, but in addition there must be something that 280 informs the devices of the identity of the trusted server(s). There 281 are multiple ways to provide this information. One simple approach 282 is to feed the identities of the trusted server(s) to devices at 283 installation time. This requires either a separate user interface, 284 local connection (such as USB), or using the network interface of the 285 device for configuration. In any case, as with sensor networks the 286 amount of configuration information is minimized: just one short 287 identity value needs to be fed in (not both an identity and 288 certificate or shared secrets that must be kept confidential). An 289 even simpler provisioning approach is that the devices in the device 290 group trust each other. Then no configuration is needed at 291 installation time. 293 Once both the parties interested in communicating know the expected 294 cryptographic identity of the other off-line, secure communications 295 can commence. Alternatively, various pairing schemes can be 296 employed. Note that these schemes can benefit from the already 297 secure identifiers on the device side. For instance, the server can 298 send a pairing message to each device after their initial power-on 299 and before they have been paired with anyone, encrypted with the 300 public key of the device. As with all pairing schemes that do not 301 employ a shared secret or the secure identity of both parties, there 302 are some remaining vulnerabilities that may or may not be acceptable 303 for the application in question. For example, many leap-of-faith or 304 trust-on-first-use based pairing methods assume that the attacker is 305 not present during the initial setup. Therefore, they are vulnerable 306 to eavesdropping or man-in-the-middle (MitM) attacks. 308 In any case, the secure identities help again in ensuring that the 309 operations are as simple as possible. Only identities need to be 310 communicated to the devices, not certificates, not shared secrets or 311 e.g. IPsec policy rules. 313 Where necessary, the information collected at installation time may 314 also include other parameters relevant to the application, such as 315 the location or purpose of the devices. This would enable the server 316 to know, for instance, that a particular device is the temperature 317 sensor for the kitchen. 319 Collecting the identity information at installation time can be 320 arranged in a number of ways. One simple but not completely secure 321 method where the last few digits of the identity are printed on a 322 tiny device just a few millimeters across. Alternatively, the 323 packaging for the device may include the full identity (typically 32 324 hex digits), retrieved from the device at manufacturing time. This 325 identity can be read, for instance, by a bar code reader carried by 326 the installation personnel. (Note that the identities are not 327 secret, the security of the system is not dependent on the identity 328 information leaking to others. The real owner of an identity can 329 always prove its ownership with the private key which never leaves 330 the device.) Finally, the device may use its wired network interface 331 or proximity-based communications, such as Near-Field Communications 332 (NFC) or Radio-Frequency Identity tags (RFIDs). Such interfaces 333 allow secure communication of the device identity to an information 334 gathering device at installation time. 336 No matter what the method of information collection is, this 337 provisioning model minimizes the effort required to set up the 338 security. Each device generates its own identity in a random, secure 339 key generation process. The identities are self-securing in the 340 sense that if you know the identity of the peer you want to 341 communicate with, messages from the peer can be signed by the peer's 342 private key and it is trivial to verify that the message came from 343 the expected peer. There is no need to configure an identity and 344 certificate of that identity separately. There is no need to 345 configure a group secret or a shared secret. There is no need to 346 configure a trust anchor. In addition, the identities are typically 347 collected anyway for application purposes (such as identifying which 348 sensor is in which room). Under most circumstances there is actually 349 no additional configuration effort from provisioning security. 351 As discussed in the previous section, long-term static identities 352 negatively affect the privacy of the devices and their owners. 353 Therefore, it is beneficial for devices to generate new identities at 354 appropriate times during their lifecycle. For example, after a 355 factory reset or an ownership handover. Thus, in our proposed 356 deployment model, the devices would generate a new asymmetric key 357 pair and use the new public-key P' to generate the new identity I'. 358 It is also desirable that these identities are only used during the 359 provisioning stage. Temporary identities (such as dynamic IPv6 360 addresses) can be used for network communication protocols once the 361 device is operational. 363 Groups of devices can be managed through single identifiers as well. 364 In these deployment cases it is also possible to configure the 365 identity of an entire group of devices, rather than registering the 366 individual devices. For instance, many installations employ a kit of 367 devices bought from the same manufacturer in one package. It is easy 368 to provide an identity for such a set of devices as follows: 370 Idev = h(Pdev|Potherdev1|Potherdev2|...|Potherdevn) 372 Igrp = h(Pdev1|Pdev2|...|Pdevm) 374 where Idev is the identity of an individual device, Pdev is the 375 public key of that device, and Potherdevi are the public keys of 376 other devices in the group, n is all the devices in the group except 377 the device with Pdev as its public key, and m is the total number of 378 devices in the group. Now, we can define the secure identity of the 379 group (Igrp) as a hash of all the public keys of the devices in the 380 group (Pdevi). 382 The installation personnel can scan the identity of the group from 383 the box that the kit came in, and this identity can be stored in a 384 server that is expected to receive information from the nodes. Later 385 when the individual devices contact this server, they will be able to 386 show that they are part of the group, as they can reveal their own 387 public key and the public keys of the other devices. Devices that do 388 not belong to the kit can not claim to be in the group, because the 389 group identity would change if any new keys were added to the 390 identity of the group (Igrp). 392 4.2. Protocol Architecture 394 As noted above, the starting point of the architecture is that nodes 395 self-generate secure identities which are then communicated out-of- 396 band to the peers that need to know what devices to trust. To 397 support this model in a protocol architecture, we also need to use 398 these secure identities to implement secure messaging between the 399 peers, explain how the system can respond to different types of 400 attacks such as replay attempts, and decide at what protocol layer 401 and endpoints the architecture should use. 403 The deployment itself is suitable for a variety of design choices 404 regarding layering and protocol mechanisms. 405 [I-D.arkko-core-security-arch] was mostly focused on employing end- 406 to-end data object security as opposed to hop-by-hop security. But 407 other approaches are possible. For instance, HIP in its 408 opportunistic mode could be used to implement largely the same 409 functionality at the IP layer. However, it is our belief that the 410 right layer for this solution is at the application layer. More 411 specifically, in the data formats transported in the payload part of 412 CoAP. This approach provides the following benefits: 414 o Ability for intermediaries to act as caches to support different 415 sleep schedules, without the security model being impacted. 417 o Ability for intermediaries to be built to perform aggregation, 418 filtering, storage and other actions, again without impacting the 419 security of the data being transmitted or stored. 421 o Ability to operate in the presence of traditional middleboxes, 422 such as a protocol translators or even NATs (not that we recommend 423 their use in these environments). 425 However, as we will see later there are also some technical 426 implications, namely that link, network, and transport layer 427 solutions are more likely to be able to benefit from sessions where 428 the cost of expensive operations can be amortized over multiple data 429 transmissions. While this is not impossible in data object security 430 solutions, it is generally not the typical arrangement. 432 5. Code Availability 434 For implementing public key cryptography on resource constrained 435 environments, we chose Arduino Uno board [arduino-uno] as the test 436 platform. Arduino Uno has an ATmega328 microcontroller, an 8-bit 437 processor with a clock speed of 16 MHz, 2 kB of RAM, and 32 kB of 438 flash memory. Our choice of a 8-bit platform may seem surprising 439 since cheaper and more energy-efficient 32-bit platforms are 440 available. However, our intention was to evaluate the performance of 441 public-key cryptography on the most resource-constrained platforms 442 available. It is reasonable to expect better performance results 443 from 32-bit microcontrollers. 445 For selecting potential asymmetric cryptographic libraries, we 446 surveyed and came up with a set of possible code sources, and 447 performed an initial analysis of how well they fit the Arduino 448 environment. Note that the results are preliminary, and could easily 449 be affected in any direction by implementation bugs, configuration 450 errors, and other mistakes. It is advisable to verify the numbers 451 before relying on them for building something. No significant effort 452 was done to optimize ROM memory usage beyond what the libraries 453 provided themselves, so those numbers should be taken as upper 454 limits. 456 Here is the set of libraries we found: 458 o AvrCryptolib [avr-cryptolib]: This library provides symmetric key 459 algorithms such as AES. It provides RSA as an asymmetric key 460 algorithm. Parts of the library were written in AVR-8 bit 461 assembly language to reduce the size and optimize the performance. 463 o Relic-Toolkit [relic-toolkit]: This library is written entirely in 464 C and provides a highly flexible and customizable implementation 465 of a large variety of cryptographic algorithms. This not only 466 includes RSA and ECC, but also pairing based asymmetric 467 cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures. 468 The library has also added support for curve25519 (for elliptic 469 curve Diffie-Hellman key exchange) [RFC7748] and edwards25519 (for 470 elliptic curve digital signatures) [RFC8032]. The toolkit 471 provides an option to build only the desired components for the 472 required platform. 474 o TinyECC [tinyecc]: TinyECC was designed for using elliptic curve 475 based public key cryptography on sensor networks. It is written 476 in the nesC programming language [nesC] and as such is designed 477 for specific use on TinyOS. However, the library can be ported to 478 standard C either with tool-chains or manually rewriting parts of 479 the code. It also has one of the smallest memory footprints among 480 the set of elliptic curve libraries surveyed so far. 482 o Wiselib [wiselib]: Wiselib is a generic library written for sensor 483 networks containing a wide variety of algorithms. While the 484 stable version contains algorithms for routing only, the test 485 version includes many more algorithms including algorithms for 486 cryptography, localization, topology management and many more. 487 The library was designed with the idea of making it easy to 488 interface the library with operating systems like iSense and 489 Contiki. However, since the library is written entirely in C++ 490 with a template based model similar to Boost/CGAL, it can be used 491 on any platform directly without using any of the operating system 492 interfaces provided. This approach was taken to test the code on 493 Arduino Uno. 495 o MatrixSSL [matrix-ssl]: This library provides a low footprint 496 implementation of several cryptographic algorithms including RSA 497 and ECC (with a commercial license). The library in the original 498 form takes about 50 kB of ROM and is intended for 32-bit 499 platforms. 501 This is by no ways an exhaustive list and there exist other 502 cryptographic libraries targeting resource-constrained devices. 504 There are also a number of operating systems that are specifically 505 targeted for resource-constrained devices. These operating systems 506 may included libraries and code for security. Hahm et al.[hahmos] 507 conduct a survey of such operating systems. The ARM mbed OS [mbed] 508 is one such operating system that provides various cryptographic 509 primitives that are necessary for SSL/TLS protocol implementation as 510 well as X509 certificate handling. The library provides an API for 511 developer with a minimal code footprint. It is intended for various 512 ARM platforms such as ARM Cortex M0, ARM Cortex M0+ and ARM Cortex 513 M3. 515 6. Implementation Experiences 517 While evaluating the implementation experiences, we were particularly 518 interested in the signature generation operation. This was because 519 our example application discussed in Section 7 required only the 520 signature generation operation on the resource-constrained platforms. 521 We have summarized the initial results of RSA private key 522 exponentiation performance using AvrCryptolib [avr-crypto-lib] in 523 Table 1. All results are from a single run since repeating the test 524 did not change (or had only minimal impact on) the results. The 525 execution time for a key size of 2048 bits was inordinately long and 526 would be a deterrent in real-world deployments. 528 +--------------+------------------------+---------------------------+ 529 | Key length | Execution time (ms); | Memory footprint (bytes); | 530 | (bits) | key in RAM | key in RAM | 531 +--------------+------------------------+---------------------------+ 532 | 2048 | 1587567 | 1280 | 533 +--------------+------------------------+---------------------------+ 535 RSA private key operation performance 537 Table 1 539 The code size was about 3.6 kB with potential for further reduction. 540 It is also worth noting that the implementation performs basic 541 exponentiation and multiplication operations without using any 542 mathematical optimizations such as Montgomery multiplication, 543 optimized squaring, etc. as described in [rsa-high-speed]. With more 544 RAM, we believe that 2048-bit operations can be performed in much 545 less time as has been shown in [rsa-8bit]. 547 In Table 2 we present the results obtained by manually porting 548 TinyECC into C99 standard and running the Elliptic Curve Digital 549 Signature Algorithm (ECDSA) on the Arduino Uno board. TinyECC 550 supports a variety of SEC 2 recommended Elliptic Curve domain 551 parameters [sec2ecc]. The execution time and memory footprint are 552 shown next to each of the curve parameters. These results were 553 obtained by turning on all the optimizations and using assembly code 554 where available. 556 The results from the performance evaluation of ECDSA in the following 557 tables also contains a column stating the approximate comparable RSA 558 key length as documented in [sec2ecc]. It is clearly observable that 559 for similar security levels, Elliptic Curve public key cryptography 560 outperforms RSA. 562 +-------------+---------------+-----------------+-------------------+ 563 | Curve | Execution | Memory | Comparable RSA | 564 | parameters | time (ms) | Footprint | key length | 565 | | | (bytes) | | 566 +-------------+---------------+-----------------+-------------------+ 567 | secp160k1 | 2228 | 892 | 1024 | 568 | secp160r1 | 2250 | 892 | 1024 | 569 | secp160r2 | 2467 | 892 | 1024 | 570 | secp192k1 | 3425 | 1008 | 1536 | 571 | secp192r1 | 3578 | 1008 | 1536 | 572 +-------------+---------------+-----------------+-------------------+ 574 Performance of ECDSA sign operation with TinyECC 576 Table 2 578 We also performed experiments by removing the assembly optimization 579 and using a C only form of the library. This gives us an idea of the 580 performance that can be achieved with TinyECC on any platform 581 regardless of what kind of OS and assembly instruction set available. 582 The memory footprint remains the same with or without assembly code. 583 The tables contain the maximum RAM that is used when all the possible 584 optimizations are on. If however, the amount of RAM available is 585 smaller in size, some of the optimizations can be turned off to 586 reduce the memory consumption accordingly. 588 +-------------+---------------+-----------------+-------------------+ 589 | Curve | Execution | Memory | Comparable RSA | 590 | parameters | time (ms) | Footprint | key length | 591 | | | (bytes) | | 592 +-------------+---------------+-----------------+-------------------+ 593 | secp160k1 | 3795 | 892 | 1024 | 594 | secp160r1 | 3841 | 892 | 1024 | 595 | secp160r2 | 4118 | 892 | 1024 | 596 | secp192k1 | 6091 | 1008 | 1536 | 597 | secp192r1 | 6217 | 1008 | 1536 | 598 +-------------+---------------+-----------------+-------------------+ 600 Performance of ECDSA sign operation with TinyECC (No assembly 601 optimizations) 603 Table 3 605 Table 4 documents the performance of Wiselib. Since there were no 606 optimizations that could be turned on or off, we have only one set of 607 results. By default Wiselib only supports some of the standard SEC 2 608 Elliptic curves, but it is easy to change the domain parameters and 609 obtain results for all the 128, 160 and 192-bit SEC 2 Elliptic 610 curves. The ROM size for all the experiments was less than 16 kB. 612 +-------------+---------------+-----------------+-------------------+ 613 | Curve | Execution | Memory | Comparable RSA | 614 | parameters | time (ms) | Footprint | key length | 615 | | | (bytes) | | 616 +-------------+---------------+-----------------+-------------------+ 617 | secp160k1 | 10957 | 842 | 1024 | 618 | secp160r1 | 10972 | 842 | 1024 | 619 | secp160r2 | 10971 | 842 | 1024 | 620 | secp192k1 | 18814 | 952 | 1536 | 621 | secp192r1 | 18825 | 952 | 1536 | 622 +-------------+---------------+-----------------+-------------------+ 624 Performance ECDSA sign operation with Wiselib 626 Table 4 628 For testing the relic-toolkit we used a different board because it 629 required more RAM/ROM and we were unable to perform experiments with 630 it on Arduino Uno. Arduino Mega has the same 8-bit architecture like 631 the Arduino Uno but has a much larger RAM/ROM. We used Arduino Mega 632 for experimenting with the relic-toolkit. Again, it is important to 633 mention that we used Arduino as it is a convenient prototyping 634 platform. Our intention was to demonstrate the feasibility of the 635 entire architecture with public key cryptography on an 8-bit 636 microcontroller. However it is important to state that 32-bit 637 microcontrollers are much more easily available, at lower costs and 638 are more power efficient. Therefore, real deployments are better off 639 using 32-bit microcontrollers that allow developers to include the 640 necessary cryptographic libraries. There is no good reason to choose 641 platforms that do not provide sufficient computing power to run the 642 necessary cryptographic operations. 644 The relic-toolkit supports Koblitz curves over prime as well as 645 binary fields. We have experimented with Koblitz curves over binary 646 fields only. We do not run our experiments with all the curves 647 available in the library since the aim of this work is not prove 648 which curves perform the fastest, and rather show that asymmetric 649 cryptography is possible on resource-constrained devices. 651 The results from relic-toolkit are documented in two separate tables 652 shown in Table 5 and Table 6. The first set of results were 653 performed with the library configured for high speed performance with 654 no consideration given to the amount of memory used. For the second 655 set, the library was configured for low memory usage irrespective of 656 the execution time required by different curves. By turning on/off 657 optimizations included in the library, a trade-off between memory and 658 execution time between these values can be achieved. 660 +-----------------+--------------+----------------+-----------------+ 661 | Curve | Execution | Memory | Comparable RSA | 662 | parameters | time (ms) | Footprint | key length | 663 | | | (bytes) | | 664 +-----------------+--------------+----------------+-----------------+ 665 | sect163k1 | 261 | 2804 | 1024 | 666 | (assembly math) | | | | 667 | sect163k1 | 932 | 2750 | 1024 | 668 | sect163r2 | 2243 | 2444 | 1024 | 669 | sect233k1 | 1736 | 3675 | 2048 | 670 | sect233r1 | 4471 | 3261 | 2048 | 671 +-----------------+--------------+----------------+-----------------+ 673 Performance of ECDSA sign operation with relic-toolkit (Fast) 675 Table 5 677 +-----------------+--------------+----------------+-----------------+ 678 | Curve | Execution | Memory | Comparable RSA | 679 | parameters | time (ms) | Footprint | key length | 680 | | | (bytes) | | 681 +-----------------+--------------+----------------+-----------------+ 682 | sect163k1 | 592 | 2087 | 1024 | 683 | (assembly math) | | | | 684 | sect163k1 | 2950 | 2215 | 1024 | 685 | sect163r2 | 3213 | 2071 | 1024 | 686 | sect233k1 | 6450 | 2935 | 2048 | 687 | sect233r1 | 6100 | 2737 | 2048 | 688 +-----------------+--------------+----------------+-----------------+ 690 Performance of ECDSA sign operation with relic-toolkit (Low Memory) 692 Table 6 694 It is important to note the following points about the elliptic curve 695 measurements: 697 o Some boards (e.g. Arduino Uno) do not provide a hardware random 698 number generator. On such boards, obtaining cryptographic-quality 699 randomness is a challenge. Real-world deployments must rely on a 700 hardware random number generator for cryptographic operations such 701 as generating a public-private key pair. The Nordic nRF52832 702 board [nordic] for example provides a hardware random number 703 generator. A detailed discussion on requirements and best 704 practices for cryptographic-quality randomness is documented in 705 [RFC4086] 707 o For measuring the memory footprint of all the ECC libraries, we 708 used the Avrora simulator [avrora]. Only stack memory was used to 709 easily track the RAM consumption. 711 Tschofenig and Pegourie-Gonnard [armecdsa] have also evaluated the 712 performance of Elliptic Curve Cryptography (ECC) on ARM Coretex 713 platform. The results for ECDSA sign operation shown in Table 7 are 714 performed on a Freescale FRDM-KL25Z board [freescale] that has a ARM 715 Cortex-M0+ 48MHz microcontroller with 128kB of flash memory and 16kB 716 of RAM. The sliding window technique for efficient exponentiation 717 was used with a window size of 2. All other optimizations were 718 disabled for these measurements. 720 +------------------+---------------------+--------------------------+ 721 | Curve parameters | Execution time (ms) | Comparable RSA key | 722 | | | length | 723 +------------------+---------------------+--------------------------+ 724 | secp192r1 | 2165 | 1536 | 725 | secp224r1 | 3014 | 2048 | 726 | secp256r1 | 3649 | 2048 | 727 +------------------+---------------------+--------------------------+ 729 Performance of ECDSA sign operation with ARM mbed TLS stack on 730 Freescale FRDM-KL25Z 732 Table 7 734 Tschofenig and Pegourie-Gonnard [armecdsa] also measured the 735 performance of curves on a ST Nucleo F091 (STM32F091RCT6) board 736 [stnucleo] that has a ARM Cortex-M0 48MHz microcontroller with 256 kB 737 of flash memory and 32kB of RAM. The execution time for ECDSA sign 738 operation with different curves is shown in Table 8. The sliding 739 window technique for efficient exponentiation was used with a window 740 size of 7. Fixed point optimization and NIST curve specific 741 optimizations were used for these measurements. 743 +------------------+---------------------+--------------------------+ 744 | Curve parameters | Execution time (ms) | Comparable RSA key | 745 | | | length | 746 +------------------+---------------------+--------------------------+ 747 | secp192k1 | 291 | 1536 | 748 | secp192r1 | 225 | 1536 | 749 | secp224k1 | 375 | 2048 | 750 | secp224r1 | 307 | 2048 | 751 | secp256k1 | 486 | 2048 | 752 | secp256r1 | 459 | 2048 | 753 | secp384r1 | 811 | 7680 | 754 | secp521r1 | 1602 | 15360 | 755 +------------------+---------------------+--------------------------+ 757 ECDSA signature performance with ARM mbed TLS stack on ST Nucleo F091 758 (STM32F091RCT6) 760 Table 8 762 Finally, Tschofenig and Pegourie-Gonnard [armecdsa] also measured the 763 RAM consumption by calculating the heap consumed for the 764 cryptographic operations using a custom memory allocation handler. 765 They did not measure the minimal stack memory consumption. Depending 766 on the curve and the different optimizations enable or disabled, the 767 memory consumption for the ECDSA sign operation varied from 1500 768 bytes to 15000 bytes. 770 At the time of performing these measurements and study, it was 771 unclear which exact elliptic curve(s) would be selected by the IETF 772 community for use with resource-constrained devices. However now, 773 [RFC7748] defines two elliptic curves over prime fields (Curve25519 774 and Curve448) that offer a high level of practical security for 775 Diffie-Hellman key exchange. Correspondingly, there is ongoing work 776 to specify elliptic curve signature schemes with Edwards-curve 777 Digital Signature Algorithm (EdDSA). [RFC8032] specifies the 778 recommended parameters for the edwards25519 and edwards448 curves. 779 From these, curve25519 (for elliptic curve Diffie-Hellman key 780 exchange) and edwards25519 (for elliptic curve digital signatures) 781 are especially suitable for resource-constrained devices. 783 We found that the NaCl [nacl] and MicoNaCl [micronacl] libraries 784 provide highly efficient implementations of Diffie-Hellman key 785 exchange with curve25519. The results have shown that these 786 libraries with curve25519 outperform other elliptic curves that 787 provide similar levels of security. Hutter and Schwabe [naclavr] 788 also show that signing of data using the curve Ed25519 from the NaCl 789 library needs only 23216241 cycles on the same microcontroller that 790 we used for our evaluations (Arduino Mega ATmega2560). This 791 corresponds to about 1451 milliseconds of execution time. When 792 compared to the results for other curves and libraries that offer 793 similar level of security (such as NIST B233, NIST K233), this 794 implementation far outperforms all others. As such, it is recommend 795 that the IETF community uses these curves for protocol specification 796 and implementations. 798 A summary library flash memory use is shown in Table 9. 800 +------------------------+------------------------------------+ 801 | Library | Flash memory Footprint (Kilobytes) | 802 +------------------------+------------------------------------+ 803 | AvrCryptolib | 3.6 | 804 | Wiselib | 16 | 805 | TinyECC | 18 | 806 | Relic-toolkit | 29 | 807 | NaCl Ed25519 [naclavr] | 17-29 | 808 +------------------------+------------------------------------+ 810 Summary of library flash memory consumption 812 Table 9 814 All the measurements here are only provided as an example to show 815 that asymmetric-key cryptography (particularly, digital signatures) 816 is possible on resource-constrained devices. These numbers by no way 817 are the final source for measurements and some curves presented here 818 may not be acceptable for real in-the-wild deployments anymore. For 819 example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also 820 document performance of ECDSA on similar resource-constrained 821 devices. 823 7. Example Application 825 We developed an example application on the Arduino platform to use 826 public key crypto mechanisms, data object security, and an easy 827 provisioning model. Our application was originally developed to test 828 different approaches to supporting communications to "always off" 829 sensor nodes. These battery-operated or energy scavenging nodes do 830 not have enough power to stay on at all times. They wake up 831 periodically and transmit their readings. 833 Such sensor nodes can be supported in various ways. 834 [I-D.arkko-core-sleepy-sensors] was an early multicast-based 835 approach. In the current application we have switched to using 836 resource directories [I-D.ietf-core-resource-directory] and publish- 837 subscribe brokers [I-D.ietf-core-coap-pubsub] instead. 838 Architecturally, the idea is that sensors can delegate a part of 839 their role to a node in the network. Such a network node could be 840 either a local resource or something in the Internet. In the case of 841 CoAP publish-subscribe brokers, the network node agrees to hold the 842 web resources on behalf of the sensor, while the sensor is asleep. 843 The only role that the sensor has is to register itself at the 844 publish-subscribe broker, and periodically update the readings. All 845 queries from the rest of the world go to the publish-subscribe 846 broker. 848 We constructed a system with four entities: 850 Sensor 852 This is an Arduino-based device that runs a CoAP publish-subscribe 853 broker client and Relic-toolkit. Relic takes 29 Kbytes of flash 854 memory, and the simple CoAP client roughly 3 kilobytes. 856 Publish-Subscribe Broker 858 This is a publish-subscribe broker that holds resources on the 859 sensor's behalf. The sensor registers itself to this node. 861 Resource Directory 863 While physically in the same node in our implementation, a 864 resource directory is a logical function that allows sensors and 865 publish-subscribe brokers to register resources in the directory. 866 These resources can be queried by applications. 868 Application 870 This is a simple application that runs on a general purpose 871 computer and can retrieve both registrations from the resource 872 directory and most recent sensor readings from the publish- 873 subscribe broker. 875 The security of this system relies on an SSH-like approach. In Step 876 1, upon first boot, sensors generate keys and register themselves in 877 the publish-subscribe broker. Their public key is submitted along 878 with the registration as an attribute in the CORE Link Format data 879 [RFC6690]. 881 In Step 2, when the sensor makes a measurement, it sends an update to 882 the publish-subscribe broker and signs the message contents with a 883 JOSE signature on the used JSON/SENML payload [RFC7515] 884 [I-D.ietf-core-senml]. The sensor can also alternatively use CBOR 885 Object Signing and Encryption (COSE) [RFC8152] for signing the sensor 886 measurement. 888 In Step 3, any other device in the network -- including the publish- 889 subscribe broker, resource directory and the application -- can check 890 that the public key from the registration corresponds to the private 891 key used to make the signature in the data update. 893 Note that checks can be done at any time and there is no need for the 894 sensor and the checking node to be awake at the same time. In our 895 implementation, the checking is done in the application node. This 896 demonstrates how it is possible to implement end-to-end security even 897 with the presence of assisting middleboxes. 899 To verify the feasibility of our architecture we developed a proof- 900 of-concept prototype. In our prototype, the sensor was implemented 901 using the Arduino Ethernet shield over an Arduino Mega board. Our 902 implementation uses the standard C99 programming language on the 903 Arduino Mega board. In this prototype, the publish-subscribe broker 904 and the Resource Directory (RD) reside on the same physical host. A 905 64-bit x86 linux machine serves as the broker and the RD, while a 906 similar but physically distinct 64-bit x86 linux machine serves as 907 the client that requests data from the sensor. We chose the Relic 908 library version 0.3.1 for our sample prototype as it can be easily 909 compiled for different bit-length processors. Therefore, we were 910 able to use it on the 8-bit processor of the Arduino Mega, as well as 911 on the 64-bit processor of the x86 client. We used ECDSA to sign and 912 verify data updates with the standard NIST-K163 curve parameters. 913 While compiling Relic for our prototype, we used the fast 914 configuration without any assembly optimizations. 916 The gateway implements the CoAP base specification in the Java 917 programming language and extends it to add support for publish- 918 subscribe broker and Resource Directory REST interfaces. We also 919 developed a minimalistic CoAP C-library for the Arduino sensor and 920 for the client requesting data updates for a resource. The library 921 has small RAM requirements and uses stack-based allocation only. It 922 is interoperable with the Java implementation of CoAP running on the 923 gateway. The location of the resource directory was configured into 924 the smart object sensor by hardcoding the IP address. A real 925 implementation based on this prototype would instead use the domain 926 name system for obtaining the location of the resource directory. 928 Our intention was to demonstrate that it is possible to implement the 929 entire architecture with public-key cryptography on an 8-bit 930 microcontroller. The stated values can be improved further by a 931 considerable amount. For example, the flash memory and RAM 932 consumption is relatively high because some of the Arduino libraries 933 were used out-of-the-box and there are several functions which can be 934 removed. Similarly we used the fast version of the Relic library in 935 the prototype instead of the low memory version. However, it is 936 important to note that this was only a research prototype to verify 937 the feasibility of this architecture and as stated elsewhere, most 938 modern development boards have a 32-bit microcontroller since they 939 are more economical and have better energy efficiency. 941 8. Design Trade-Offs 943 This section attempts to make some early conclusions regarding trade- 944 offs in the design space, based on deployment considerations for 945 various mechanisms and the relative ease or difficulty of 946 implementing them. In particular, this analysis looks at layering, 947 freshness and the choice of symmetric vs. asymmetric cryptography. 949 8.1. Feasibility 951 The first question is whether using cryptographic security and 952 asymmetric cryptography in particular is feasible at all on resource- 953 constrained devices. The numbers above give a mixed message. 954 Clearly, an implementation of a significant cryptographic operation 955 such as public key signing can be done in surprisingly small amount 956 of code space. It could even be argued that our chosen prototype 957 platform was unnecessarily restrictive in the amount of code space it 958 allows: we chose this platform on purpose to demonstrate something 959 that is as resource-constrained and difficult as possible. 961 A recent trend in microcontrollers is the introduction of 32-bit CPUs 962 that are becoming cheaper and more easily available than 8-bit CPUs, 963 in addition to being more easily programmable. The flash memory size 964 is probably easier to grow than other parameters in microcontrollers. 965 Flash memory size is not expected to be the most significant limiting 966 factor. Before picking a platform, developers should also plan for 967 firmware updates. This would essentially mean that the platform 968 should at least have a flash memory size of the total code size * 2, 969 plus some space for buffer. 971 The situation is less clear with regards to the amount of CPU power 972 needed to run the algorithms. The demonstrated speeds are sufficient 973 for many applications. For instance, a sensor that wakes up every 974 now and then can likely spend a fraction of a second, or even spend 975 multiple seconds in some cases, for the computation of a signature 976 for the message that it is about to send. Most applications that use 977 protocols such as DTLS that use public key cryptography only at the 978 beginning of the session would also be fine with any of these 979 execution times. 981 Yet, with reasonably long key sizes the execution times are in the 982 seconds, dozens of seconds, or even longer. For some applications 983 this is too long. Nevertheless, these algorithms can successfully be 984 employed in resource-constrained devices for the following reasons: 986 o With the right selection of algorithms and libraries, the 987 execution times can actually be very small (less than 500 ms). 989 o As discussed in [wiman], in general the power requirements 990 necessary to turn the radio on/off and sending or receiving 991 messages are far bigger than those needed to execute cryptographic 992 operations. While there are newer radios that significantly lower 993 the energy consumption of sending and receiving messages, there is 994 no good reason to choose platforms that do not provide sufficient 995 computing power to run the necessary cryptographic operations. 997 o Commercial libraries and the use of full potential for various 998 optimizations will provide a better result than what we arrived at 999 in this memo. 1001 o Using public-key cryptography only at the beginning of a session 1002 will reduce the per-packet processing times significantly. 1004 While we did not do an exhaustive performance evaluation of 1005 asymmetric key pair generation on resource-constrained devices, we 1006 did note that it is possible for such devices to generate a new key 1007 pair. Given that this operation would only occur in rare 1008 circumstances (such as a factory reset or ownership change) and its 1009 potential privacy benefits, developers should provide mechanisms for 1010 generating new identities. It is however extremely important to note 1011 that the security of this operation relies on access to 1012 cryptographic-quality randomness. 1014 8.2. Freshness 1016 In our architecture, if implemented as described thus far, messages 1017 along with their signatures sent from the sensors to the publish- 1018 subscribe broker can be recorded and replayed by an eavesdropper. 1019 The publish-subscribe broker has no mechanism to distinguish 1020 previously received packets from those that are retransmitted by the 1021 sender or replayed by an eavesdropper. Therefore, it is essential 1022 for the smart objects to ensure that data updates include a freshness 1023 indicator. However, ensuring freshness on constrained devices can be 1024 non-trivial because of several reasons which include: 1026 o Communication is mostly unidirectional to save energy. 1028 o Internal clocks might not be accurate and may be reset several 1029 times during the operational phase of the smart object. 1031 o Network time synchronization protocols such as Network Time 1032 Protocol (NTP) [RFC5905] are resource intensive and therefore may 1033 be undesirable in many smart object networks. 1035 There are several different methods that can be used in our 1036 architecture for replay protection. The selection of the appropriate 1037 choice depends on the actual deployment scenario. 1039 Including sequence numbers in signed messages can provide an 1040 effective method of replay protection. The publish-subscribe broker 1041 should verify the sequence number of each incoming message and accept 1042 it only if it is greater than the highest previously seen sequence 1043 number. The publish-subscribe broker drops any packet with a 1044 sequence number that has already been received or if the received 1045 sequence number is greater than the highest previously seen sequence 1046 number by an amount larger than the preset threshold. 1048 Sequence numbers can wrap around at their maximum value and, 1049 therefore, it is essential to ensure that sequence numbers are 1050 sufficiently long. However, including long sequence numbers in 1051 packets can increase the network traffic originating from the sensor 1052 and can thus decrease its energy efficiency. To overcome the problem 1053 of long sequence numbers, we can use a scheme similar to that of 1054 Huang [huang], where the sender and receiver maintain and sign long 1055 sequence numbers of equal bit-lengths but they transmit only the 1056 least significant bits. 1058 It is important for the smart object to write the sequence number 1059 into the permanent flash memory after each increment and before it is 1060 included in the message to be transmitted. This ensures that the 1061 sensor can obtain the last sequence number it had intended to send in 1062 case of a reset or a power failure. However, the sensor and the 1063 publish-subscribe broker can still end up in a discordant state where 1064 the sequence number received by the publish-subscribe broker exceeds 1065 the expected sequence number by an amount greater than the preset 1066 threshold. This may happen because of a prolonged network outage or 1067 if the publish-subscribe broker experiences a power failure for some 1068 reason. Therefore it is essential for sensors that normally send 1069 Non-Confirmable data updates to send some Confirmable updates and re- 1070 synchronize with the publish-subscribe broker if a reset message is 1071 received. The sensors re-synchronize by sending a new registration 1072 message with the current sequence number. 1074 Although sequence numbers protect the system from replay attacks, a 1075 publish-subscribe broker has no mechanism to determine the time at 1076 which updates were created by the sensor. Moreover, if sequence 1077 numbers are the only freshness indicator used, a malicious 1078 eavesdropper can induce inordinate delays to the communication of 1079 signed updates by buffering messages. It may be important in certain 1080 smart object networks for sensors to send data updates which include 1081 timestamps to allow the publish-subscribe broker to determine the 1082 time when the update was created. For example, when the publish- 1083 subscribe broker is collecting temperature data, it may be necessary 1084 to know when exactly the temperature measurement was made by the 1085 sensor. A simple solution to this problem is for the publish- 1086 subscribe broker to assume that the data object was created when it 1087 receives the update. In a relatively reliable network with low RTT, 1088 it can be acceptable to make such an assumption. However most 1089 networks are susceptible to packet loss and hostile attacks making 1090 this assumption unsustainable. 1092 Depending on the hardware used by the smart objects, they may have 1093 access to accurate hardware clocks which can be used to include 1094 timestamps in the signed updates. These timestamps are included in 1095 addition to sequence numbers. The clock time in the smart objects 1096 can be set by the manufacturer or the current time can be 1097 communicated by the publish-subscribe broker during the registration 1098 phase. However, these approaches require the smart objects to either 1099 rely on the long-term accuracy of the clock set by the manufacturer 1100 or to trust the publish-subscribe broker thereby increasing the 1101 potential vulnerability of the system. The smart objects could also 1102 obtain the current time from NTP, but this may consume additional 1103 energy and give rise to security issues discussed in [RFC5905]. The 1104 smart objects could also have access to a mobile network or the 1105 Global Positioning System (GPS), and they can be used obtain the 1106 current time. Finally, if the sensors need to co-ordinate their 1107 sleep cycles, or if the publish-subscribe broker computes an average 1108 or mean of updates collected from multiple smart objects, it is 1109 important for the network nodes to synchronize the time among them. 1110 This can be done by using existing synchronization schemes. 1112 8.3. Layering 1114 It would be useful to select just one layer where security is 1115 provided at. Otherwise a simple device needs to implement multiple 1116 security mechanisms. While some code can probably be shared across 1117 such implementations (like algorithms), it is likely that most of the 1118 code involving the actual protocol machinery cannot. Looking at the 1119 different layers, here are the choices and their implications: 1121 link layer 1123 This is probably the most common solution today. The biggest 1124 benefits of this choice of layer are that security services are 1125 commonly available (WLAN secrets, cellular SIM cards, etc.) and 1126 that their application protects the entire communications. 1128 The main drawback is that there is no security beyond the first 1129 hop. This can be problematic, e.g., in many devices that 1130 communicate to a server in the Internet. A Withings scale 1131 [Withings], for instance, can support WLAN security but without 1132 some level of end-to-end security, it would be difficult to 1133 prevent fraudulent data submissions to the servers. 1135 Another drawback is that some commonly implemented link layer 1136 security designs use group secrets. This allows any device within 1137 the local network (e.g., an infected laptop) to attack the 1138 communications. 1140 network layer 1142 There are a number of solutions in this space, and many new ones 1143 and variations thereof being proposed: IPsec, PANA, and so on. In 1144 general, these solutions have similar characteristics to those in 1145 the transport layer: they work across forwarding hops but only as 1146 far as to the next middlebox or application entity. There is 1147 plenty of existing solutions and designs. 1149 Experience has shown that it is difficult to control IP layer 1150 entities from an application process. While this is theoretically 1151 easy, in practice the necessary APIs do not exist. For instance, 1152 most IPsec software has been built for the VPN use case, and is 1153 difficult or impossible to tweak to be used on a per-application 1154 basis. As a result, the authors are not particularly enthusiastic 1155 about recommending these solutions. 1157 transport and application layer 1159 This is another popular solution along with link layer designs. 1160 TLS with HTTP (HTTPS) and DTLS with CoAP are examples of solutions 1161 in this space, and have been proven to work well. These solutions 1162 are typically easy to take into use in an application, without 1163 assuming anything from the underlying OS, and they are easy to 1164 control as needed by the applications. The main drawback is that 1165 generally speaking, these solutions only run as far as the next 1166 application level entity. And even for this case, HTTPS can be 1167 made to work through proxies, so this limit is not unsolvable. 1168 Another drawback is that attacks on link layer, network layer and 1169 in some cases, transport layer, can not be protected against. 1170 However, if the upper layers have been protected, such attacks can 1171 at most result in a denial-of-service. Since denial-of-service 1172 can often be caused anyway, it is not clear if this is a real 1173 drawback. 1175 data object layer 1176 This solution does not protect any of the protocol layers, but 1177 protects individual data elements being sent. It works 1178 particularly well when there are multiple application layer 1179 entities on the path of the data. Smart object networks are 1180 likely to employ such entities for storage, filtering, aggregation 1181 and other reasons, and as such, an end-to-end solution is the only 1182 one that can protect the actual data. 1184 The downside is that the lower layers are not protected. But 1185 again, as long as the data is protected and checked upon every 1186 time it passes through an application level entity, it is not 1187 clear that there are attacks beyond denial-of-service. 1189 The main question mark is whether this type of a solution provides 1190 sufficient advantages over the more commonly implemented transport 1191 and application layer solutions. 1193 8.4. Symmetric vs. Asymmetric Crypto 1195 The second trade-off that is worth discussing is the use of plain 1196 asymmetric cryptographic mechanisms, plain symmetric cryptographic 1197 mechanisms, or some mixture thereof. 1199 Contrary to popular cryptographic community beliefs, a symmetric 1200 cryptographic solution can be deployed in large scale. In fact, one 1201 of the largest deployment of cryptographic security, the cellular 1202 network authentication system, uses SIM cards that are based on 1203 symmetric secrets. In contrast, public key systems have yet to show 1204 ability to scale to hundreds of millions of devices, let alone 1205 billions. But the authors do not believe scaling is an important 1206 differentiator when comparing the solutions. 1208 As can be seen from the Section 6, the time needed to calculate some 1209 of the asymmetric cryptographic operations with reasonable key 1210 lengths can be significant. There are two contrary observations that 1211 can be made from this. First, recent wisdom indicates that computing 1212 power on resource-constrained devices is far cheaper than 1213 transmission power [wiman], and keeps on becoming more efficient very 1214 quickly. From this we can conclude that the sufficient CPU is or at 1215 least will be easily available. 1217 But the other observation is that when there are very costly 1218 asymmetric operations, doing a key exchange followed by the use of 1219 generated symmetric keys would make sense. This model works very 1220 well for DTLS and other transport layer solutions, but works less 1221 well for data object security, particularly when the number of 1222 communicating entities is not exactly two. 1224 9. Summary 1226 This document makes several security recommendations based on our 1227 implementation experience. We summarize some of the important ones 1228 here: 1230 o Developers and product designers should choose the hardware after 1231 determining the security requirements for their application 1232 scenario. 1234 o Elliptic Curve Cryptography (ECC) outperforms RSA based operations 1235 and therefore it is recommended for resource-constrained devices. 1237 o Cryptographic-quality randomness is needed for many security 1238 protocols. Developers and vendors should ensure that the 1239 sufficient randomness is available for security critical tasks. 1241 o 32-bit microcontrollers are much more easily available, at lower 1242 costs and are more power efficient. Therefore, real-world 1243 deployments are better off using 32-bit microcontrollers. 1245 o Developers should provide mechanisms for devices to generate new 1246 identities at appropriate times during their lifecycle. For 1247 example, after a factory reset or an ownership handover. 1249 o Planning for firmware updates is important. The hardware platform 1250 chosen should at least have a flash memory size of the total code 1251 size * 2, plus some space for buffer. 1253 10. Security Considerations 1255 This entire memo deals with security issues. 1257 11. IANA Considerations 1259 There are no IANA impacts in this memo. 1261 12. Informative references 1263 [arduino-uno] 1264 Arduino, "Arduino Uno", September 2015, 1265 . 1267 [armecdsa] 1268 Tschofenig, H. and M. Pegourie-Gonnard, "Performance 1269 Investigations", March 2015, 1270 . 1273 [avr-crypto-lib] 1274 AVR-CRYPTO-LIB, "AVR-CRYPTO-LIB", September 2015, 1275 . 1277 [avr-cryptolib] 1278 Van der Laan, E., "AVR CRYPTOLIB", September 2015, 1279 . 1281 [avrora] Titzer, Ben., "Avrora", September 2015, 1282 . 1284 [freescale] 1285 NXP, "Freescale FRDM-KL25Z", June 2017, 1286 . 1288 [hahmos] Hahm, O., Baccelli, E., Petersen, H., and N. Tsiftes, 1289 "Operating systems for low-end devices in the internet of 1290 things: a survey", IEEE Internet of Things Journal , 2016. 1292 [huang] Huang, C., "Low-overhead freshness transmission in sensor 1293 networks", 2008. 1295 [I-D.arkko-core-security-arch] 1296 Arkko, J. and A. Keranen, "CoAP Security Architecture", 1297 draft-arkko-core-security-arch-00 (work in progress), July 1298 2011. 1300 [I-D.arkko-core-sleepy-sensors] 1301 Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. 1302 Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- 1303 sleepy-sensors-01 (work in progress), July 2011. 1305 [I-D.daniel-6lowpan-security-analysis] 1306 Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. 1307 Laganier, "IPv6 over Low Power WPAN Security Analysis", 1308 draft-daniel-6lowpan-security-analysis-05 (work in 1309 progress), March 2011. 1311 [I-D.ietf-core-coap-pubsub] 1312 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1313 Subscribe Broker for the Constrained Application Protocol 1314 (CoAP)", draft-ietf-core-coap-pubsub-03 (work in 1315 progress), February 2018. 1317 [I-D.ietf-core-resource-directory] 1318 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1319 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1320 resource-directory-12 (work in progress), October 2017. 1322 [I-D.ietf-core-senml] 1323 Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 1324 Bormann, "Media Types for Sensor Measurement Lists 1325 (SenML)", draft-ietf-core-senml-12 (work in progress), 1326 December 2017. 1328 [I-D.irtf-t2trg-iot-seccons] 1329 Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- 1330 the-Art and Challenges for the Internet of Things 1331 Security", draft-irtf-t2trg-iot-seccons-11 (work in 1332 progress), February 2018. 1334 [I-D.moskowitz-hip-dex] 1335 Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", 1336 draft-moskowitz-hip-dex-05 (work in progress), January 1337 2016. 1339 [I-D.sarikaya-t2trg-sbootstrapping] 1340 Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT 1341 Bootstrapping: A Survey", draft-sarikaya-t2trg- 1342 sbootstrapping-03 (work in progress), February 2017. 1344 [matrix-ssl] 1345 PeerSec Networks, "Matrix SSL", September 2015, 1346 . 1348 [mbed] ARM, "mbed TLS", May 2017, 1349 . 1351 [micronacl] 1352 MicroNaCl, "The Networking and Cryptography library for 1353 microcontrollers", . 1355 [mosdorf] Mosdorf, M. and W. Zabolotny, "Implementation of elliptic 1356 curve cryptography for 8 bit and 32 bit embedded systems 1357 time efficiency and power consumption analysis", Pomiary 1358 Automatyka Kontrola , 2010. 1360 [nacl] NaCl, "Networking and Cryptography library", 1361 . 1363 [naclavr] Hutter, M. and P. Schwabe, "NaCl on 8-Bit AVR 1364 Microcontrollers", International Conference on Cryptology 1365 in Africa , Springer Berlin Heidelberg , 2013. 1367 [nesC] Gay, D., Levis, P., von Behren, R., Welsh, M., Brewer, E., 1368 and D. Culler, "The nesC language: A holistic approach to 1369 networked embedded systems", ACM SIGPLAN Notices , 2014. 1371 [nordic] Nordic Semiconductor, "nRF52832 Product Specification", 1372 June 2017, . 1375 [relic-toolkit] 1376 Aranha, D. and C. Gouv, "Relic Toolkit", September 2015, 1377 . 1379 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1380 Levkowetz, Ed., "Extensible Authentication Protocol 1381 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1382 . 1384 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1385 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1386 . 1388 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1389 "Randomness Requirements for Security", BCP 106, RFC 4086, 1390 DOI 10.17487/RFC4086, June 2005, 1391 . 1393 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1394 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1395 . 1397 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1398 and A. Yegin, "Protocol for Carrying Authentication for 1399 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1400 May 2008, . 1402 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1403 (TLS) Protocol Version 1.2", RFC 5246, 1404 DOI 10.17487/RFC5246, August 2008, 1405 . 1407 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 1408 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 1409 February 2009, . 1411 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1412 "Network Time Protocol Version 4: Protocol and Algorithms 1413 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1414 . 1416 [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) 1417 Immediate Carriage and Conveyance of Upper-Layer Protocol 1418 Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078, 1419 January 2011, . 1421 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1422 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1423 January 2012, . 1425 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 1426 Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, 1427 . 1429 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1430 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1431 . 1433 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1434 Protocol (HTTP/1.1): Message Syntax and Routing", 1435 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1436 . 1438 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1439 Application Protocol (CoAP)", RFC 7252, 1440 DOI 10.17487/RFC7252, June 2014, 1441 . 1443 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1444 Kivinen, "Internet Key Exchange Protocol Version 2 1445 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1446 2014, . 1448 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1449 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1450 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1451 . 1453 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1454 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1455 2015, . 1457 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1458 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1459 2016, . 1461 [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 1462 (IKEv2) Initiator Implementation", RFC 7815, 1463 DOI 10.17487/RFC7815, March 2016, 1464 . 1466 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1467 Signature Algorithm (EdDSA)", RFC 8032, 1468 DOI 10.17487/RFC8032, January 2017, 1469 . 1471 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1472 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1473 . 1475 [rsa-8bit] 1476 Gura, N., Patel, A., Wander, A., Eberle, H., and S. 1477 Shantz, "Comparing Elliptic Curve Cryptography and RSA on 1478 8-bit CPUs", 2010. 1480 [rsa-high-speed] 1481 Koc, C., "High-Speed RSA Implementation", November 1994, 1482 . 1484 [sec2ecc] Certicom Research, "SEC 2: Recommended Elliptic Curve 1485 Domain Parameters", 2000. 1487 [stnucleo] 1488 STMicroelectronics, "NUCLEO-F091RC", June 2017, 1489 . 1492 [tinyecc] North Carolina State University and North Carolina State 1493 University, "TinyECC", 2008, 1494 . 1496 [wiman] Margi, C., Oliveira, B., Sousa, G., Simplicio, M., Paulo, 1497 S., Carvalho, T., Naslund, M., and R. Gold, "Impact of 1498 Operating Systems on Wireless Sensor Networks (Security) 1499 Applications and Testbeds", International Conference on 1500 Computer Communication Networks (ICCCN'2010) / IEEE 1501 International Workshop on Wireless Mesh and Ad Hoc 1502 Networks (WiMAN 2010) , 2010. 1504 [wiselib] Baumgartner, T., Chatzigiannakis, I., Fekete, S., Koninis, 1505 C., Kroller, A., and A. Pyrgelis, "Wiselib", 2010, 1506 . 1508 [Withings] 1509 Withings, "The Withings scale", February 2012, 1510 . 1512 Appendix A. Acknowledgments 1514 The authors would like to thank Mats Naslund, Salvatore Loreto, Bob 1515 Moskowitz, Oscar Novo, Vlasios Tsiatsis, Daoyuan Li, Muhammad Waqas, 1516 Eric Rescorla and Tero Kivinen for interesting discussions in this 1517 problem space. The authors would also like to thank Diego Aranha for 1518 helping with the relic-toolkit configurations and Tobias Baumgartner 1519 for helping with questions regarding wiselib. 1521 Tim Chown, Samita Chakrabarti, Christian Huitema, Dan Romascanu, Eric 1522 Vyncke, and Emmanuel Baccelli provided valuable comments that helped 1523 us improve the final version of this document. 1525 Authors' Addresses 1527 Mohit Sethi 1528 Ericsson 1529 Jorvas 02420 1530 Finland 1532 EMail: mohit@piuha.net 1534 Jari Arkko 1535 Ericsson 1536 Jorvas 02420 1537 Finland 1539 EMail: jari.arkko@piuha.net 1541 Ari Keranen 1542 Ericsson 1543 Jorvas 02420 1544 Finland 1546 EMail: ari.keranen@ericsson.com 1548 Heidi-Maria Back 1549 Nokia 1550 Helsinki 00181 1551 Finland 1553 EMail: heidi.back@nokia.com