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