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