idnits 2.17.1 draft-ietf-lwig-crypto-sensors-01.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 (October 31, 2016) is 2731 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-08 == Outdated reference: A later version (-16) exists of draft-irtf-t2trg-iot-seccons-00 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: May 4, 2017 Ericsson 6 H. Back 7 Comptel 8 October 31, 2016 10 Practical Considerations and Implementation Experiences in Securing 11 Smart Object Networks 12 draft-ietf-lwig-crypto-sensors-01 14 Abstract 16 This memo describes challenges associated with securing smart object 17 devices in constrained implementations and environments. The memo 18 describes a possible deployment model suitable for these 19 environments, discusses the availability of cryptographic libraries 20 for small devices, presents some preliminary experiences in 21 implementing small devices using those libraries, and discusses 22 trade-offs involving different types of 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 May 4, 2017. 41 Copyright Notice 43 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . 11 66 9. Example Application . . . . . . . . . . . . . . . . . . . . . 17 67 10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21 68 11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 21 69 12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 22 70 13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 24 71 14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 26 72 15. Security Considerations . . . . . . . . . . . . . . . . . . . 26 73 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 74 17. Informative references . . . . . . . . . . . . . . . . . . . 26 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 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 Secondly, 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 Thirdly, Section 7 discusses the availability of cryptographic 94 libraries. Section 8 presents some experiences in implementing 95 cryptography on small devices using those libraries, including 96 information about achievable code sizes and speeds on typical 97 hardware. 99 Finally, Section 10 discusses trade-offs involving different types of 100 security approaches. 102 2. Related Work 104 Constrained Application Protocol (CoAP) [RFC7252] is a light-weight 105 protocol designed to be used in machine-to-machine applications such 106 as smart energy and building automation. Our discussion uses this 107 protocol as an example, but the conclusions may apply to other 108 similar protocols. CoAP base specification [RFC7252] outlines how to 109 use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol. 110 DTLS can be applied with pairwise shared keys, raw public keys or 111 with certificates. The security model in all cases is mutual 112 authentication, so while there is some commonality to HTTP in 113 verifying the server identity, in practice the models are quite 114 different. The CoAP specification says little about how DTLS keys 115 are managed. 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 [RFC6574] gives an overview of the security discussions at the March 122 2011 IAB workshop on smart objects. The workshop recommended that 123 additional work is needed in developing suitable credential 124 management mechanisms (perhaps something similar to the Bluetooth 125 pairing mechanism), understanding the implementability of standard 126 security mechanisms in small devices and additional research in the 127 area of lightweight cryptographic primitives. 129 [I-D.moskowitz-hip-dex] defines a light-weight version of the HIP 130 protocol for low-power nodes. This version uses a fixed set of 131 algorithms, Elliptic Curve Cryptography (ECC), and eliminates hash 132 functions. The protocol still operates based on host identities, and 133 runs end-to-end between hosts, protecting IP layer communications. 134 [RFC6078] describes an extension of HIP that can be used to send 135 upper layer protocol messages without running the usual HIP base 136 exchange at all. 138 [I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis 139 of security issues related to 6LoWPAN networks, but its findings also 140 apply more generally for all low-powered networks. Some of the 141 issues this document discusses include the need to minimize the 142 number of transmitted bits and simplify implementations, threats in 143 the smart object networking environments, and the suitability of 144 6LoWPAN security mechanisms, IPsec, and key management protocols for 145 implementation in these environments. 147 [I-D.irtf-t2trg-iot-seccons] discusses the overall security problem 148 for Internet of Things devices. It also discusses various solutions, 149 including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347], 150 HIP [RFC7401] [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP 151 [RFC3748]. The draft also discusses various operational scenarios, 152 bootstrapping mechanisms, and challenges associated with implementing 153 security mechanisms in these environments. 155 3. Challenges 157 This section discusses three challenges: implementation difficulties, 158 practical provisioning problems, and layering and communication 159 models. 161 The most often discussed issues in the security for the Internet of 162 Things relate to implementation difficulties. The desire to build 163 small, battery-operated, and inexpensive devices drives the creation 164 of devices with a limited protocol and application suite. Some of 165 the typical limitations include running CoAP instead of HTTP, limited 166 support for security mechanisms, limited processing power for long 167 key lengths, sleep schedule that does not allow communication at all 168 times, and so on. In addition, the devices typically have very 169 limited support for configuration, making it hard to set up secrets 170 and trust anchors. 172 The implementation difficulties are important, but they should not be 173 overemphasized. It is important to select the right security 174 mechanisms and avoid duplicated or unnecessary functionality. But at 175 the end of the day, if strong cryptographic security is needed, the 176 implementations have to support that. Also, the use of the most 177 lightweight algorithms and cryptographic primitives is useful, but 178 should not be the only consideration in the design. Interoperability 179 is also important, and often other parts of the system, such as key 180 management protocols or certificate formats are heavier to implement 181 than the algorithms themselves. 183 The second challenge relates to practical provisioning problems. 184 These are perhaps the most fundamental and difficult issue, and 185 unfortunately often neglected in the design. There are several 186 problems in the provisioning and management of smart object networks: 188 o Small devices have no natural user interface for configuration 189 that would be required for the installation of shared secrets and 190 other security-related parameters. Typically, there is no 191 keyboard, no display, and there may not even be buttons to press. 193 Some devices may only have one interface, the interface to the 194 network. 196 o Manual configuration is rarely, if at all, possible, as the 197 necessary skills are missing in typical installation environments 198 (such as in family homes). 200 o There may be a large number of devices. Configuration tasks that 201 may be acceptable when performed for one device may become 202 unacceptable with dozens or hundreds of devices. 204 o Network configurations evolve over the lifetime of the devices, as 205 additional devices are introduced or addresses change. Various 206 central nodes may also receive more frequent updates than 207 individual devices such as sensors embedded in building materials. 209 Finally, layering and communication models present difficulties for 210 straightforward use of the most obvious security mechanisms. Smart 211 object networks typically pass information through multiple 212 participating nodes [I-D.arkko-core-sleepy-sensors] and end-to-end 213 security for IP or transport layers may not fit such communication 214 models very well. The primary reasons for needing middleboxes 215 relates to the need to accommodate for sleeping nodes as well to 216 enable the implementation of nodes that store or aggregate 217 information. 219 4. Proposed Deployment Model 221 [I-D.arkko-core-security-arch] recognizes the provisioning model as 222 the driver of what kind of security architecture is useful. This 223 section re-introduces this model briefly here in order to facilitate 224 the discussion of the various design alternatives later. 226 The basis of the proposed architecture are self-generated secure 227 identities, similar to Cryptographically Generated Addresses (CGAs) 228 [RFC3972] or Host Identity Tags (HITs) [RFC7401]. That is, we assume 229 the following holds: 231 I = h(P|O) 233 where I is the secure identity of the device, h is a hash function, P 234 is the public key from a key pair generated by the device, and O is 235 optional other information. | here denotes the concatenation 236 operator. 238 5. Provisioning 240 As it is difficult to provision security credentials, shared secrets, 241 and policy information, the provisioning model is based only on the 242 secure identities. A typical network installation involves physical 243 placement of a number of devices while noting the identities of these 244 devices. This list of short identifiers can then be fed to a central 245 server as a list of authorized devices. Secure communications can 246 then commence with the devices, at least as far as information from 247 from the devices to the server is concerned, which is what is needed 248 for sensor networks. 250 The above architecture is a perfect fit for sensor networks where 251 information flows from large number of devices to small number of 252 servers. But it is not sufficient alone for other types of 253 applications. For instance, in actuator applications a large number 254 of devices need to take commands from somewhere else. In such 255 applications it is necessary to secure that the commands come from an 256 authorized source. This can be supported, with some additional 257 provisioning effort and optional pairing protocols. The basic 258 provisioning approach is as described earlier, but in addition there 259 must be something that informs the devices of the identity of the 260 trusted server(s). There are multiple ways to provide this 261 information. One simple approach is to feed the identities of the 262 trusted server(s) to devices at installation time. This requires 263 either a separate user interface, local connection (such as USB), or 264 using the network interface of the device for configuration. In any 265 case, as with sensor networks the amount of configuration information 266 is minimized: just one short identity value needs to be fed in. Not 267 both an identity and a certificate. Not shared secrets that must be 268 kept confidential. An even simpler provisioning approach is that the 269 devices in the device group trust each other. Then no configuration 270 is needed at installation time. When both peers know the expected 271 cryptographic identity of the other peer off-line, secure 272 communications can commence. Alternatively, various pairing schemes 273 can be employed. Note that these schemes can benefit from the 274 already secure identifiers on the device side. For instance, the 275 server can send a pairing message to each device after their initial 276 power-on and before they have been paired with anyone, encrypted with 277 the public key of the device. As with all pairing schemes that do 278 not employ a shared secret or the secure dentity of both parties, 279 there are some remaining vulnerabilities that may or may not be 280 acceptable for the application in question. In any case, the secure 281 identities help again in ensuring that the operations are as simple 282 as possible. Only identities need to be communicated to the devices, 283 not certificates, not shared secrets or IPsec policy rules. 285 Where necessary, the information collected at installation time may 286 also include other parameters relevant to the application, such as 287 the location or purpose of the devices. This would enable the server 288 to know, for instance, that a particular device is the temperature 289 sensor for the kitchen. 291 Collecting the identity information at installation time can be 292 arranged in a number of ways. The authors have employed a simple but 293 not completely secure method where the last few digits of the 294 identity are printed on a tiny device just a few millimeters across. 295 Alternatively, the packaging for the device may include the full 296 identity (typically 32 hex digits), retrieved from the device at 297 manufacturing time. This identity can be read, for instance, by a 298 bar code reader carried by the installation personnel. (Note that 299 the identities are not secret, the security of the system is not 300 dependent on the identity information leaking to others. The real 301 owner of an identity can always prove its ownership with the private 302 key which never leaves the device.) Finally, the device may use its 303 wired network interface or proximity-based communications, such as 304 Near-Field Communications (NFC) or Radio-Frequency Identity tags 305 (RFIDs). Such interfaces allow secure communication of the device 306 identity to an information gathering device at installation time. 308 No matter what the method of information collection is, this 309 provisioning model minimizes the effort required to set up the 310 security. Each device generates its own identity in a random, secure 311 key generation process. The identities are self-securing in the 312 sense that if you know the identity of the peer you want to 313 communicate with, messages from the peer can be signed by the peer's 314 private key and it is trivial to verify that the message came from 315 the expected peer. There is no need to configure an identity and 316 certificate of that identity separately. There is no need to 317 configure a group secret or a shared secret. There is no need to 318 configure a trust anchor. In addition, the identities are typically 319 collected anyway for application purposes (such as identifying which 320 sensor is in which room). Under most circumstances there is actually 321 no additional configuration effort from provisioning security. 323 Groups of devices can be managed through single identifiers as well. 324 In these deployment cases it is also possible to configure the 325 identity of an entire group of devices, rather than registering the 326 individual devices. For instance, many installations employ a kit of 327 devices bought from the same manufacturer in one package. It is easy 328 to provide an identity for such a set of devices as follows: 330 Idev = h(Pdev|Potherdev1|Potherdev2|...|Potherdevn) 332 Igrp = h(Pdev1|Pdev2|...|Pdevm) 334 where Idev is the identity of an individual device, Pdev is the 335 public key of that device, and Potherdevi are the public keys of 336 other devices in the group. Now, we can define the secure identity 337 of the group (Igrp) as a hash of all the public keys of the devices 338 in the group (Pdevi). 340 The installation personnel can scan the identity of the group from 341 the box that the kit came in, and this identity can be stored in a 342 server that is expected to receive information from the nodes. Later 343 when the individual devices contact this server, they will be able to 344 show that they are part of the group, as they can reveal their own 345 public key and the public keys of the other devices. Devices that do 346 not belong to the kit can not claim to be in the group, because the 347 group identity would change if any new keys were added to Igrp. 349 6. Protocol Architecture 351 As noted above, the starting point of the architecture is that nodes 352 self-generate secure identities which are then communicated out-of- 353 band to the peers that need to know what devices to trust. To 354 support this model in a protocol architecture, we also need to use 355 these secure identities to implement secure messaging between the 356 peers, explain how the system can respond to different types of 357 attacks such as replay attempts, and decide at what protocol layer 358 and endpoints the architecture should use. 360 The deployment itself is suitable for a variety of design choices 361 regarding layering and protocol mechanisms. 362 [I-D.arkko-core-security-arch] was mostly focused on employing end- 363 to-end data object security as opposed to hop-by-hop security. But 364 other approaches are possible. For instance, HIP in its 365 opportunistic mode could be used to implement largely the same 366 functionality at the IP layer. However, it is our belief that the 367 right layer for this solution is at the application layer. More 368 specifically, in the data formats transported in the payload part of 369 CoAP. This approach provides the following benefits: 371 o Ability for intermediaries to act as caches to support different 372 sleep schedules, without the security model being impacted. 374 o Ability for intermediaries to be built to perform aggregation, 375 filtering, storage and other actions, again without impacting the 376 security of the data being transmitted or stored. 378 o Ability to operate in the presence of traditional middleboxes, 379 such as a protocol translators or even NATs (not that we recommend 380 their use in these environments). 382 However, as we will see later there are also some technical 383 implications, namely that link, network, and transport layer 384 solutions are more likely to be able to benefit from sessions where 385 the cost of expensive operations can be amortized over multiple data 386 transmissions. While this is not impossible in data object security 387 solutions either, it is not the typical arrangement either. 389 7. Code Availability 391 For implementing public key cryptography on resource constrained 392 environments, we chose Arduino Uno board [arduino-uno] as the test 393 platform. Arduino Uno has an ATmega328 microcontroller, an 8-bit 394 processor with a clock speed of 16 MHz, 2 kB of SRAM, and 32 kB of 395 flash memory. 397 For selecting potential asymmetric cryptographic libraries, we did an 398 extensive survey and came up with a set of possible code sources, and 399 performed an initial analysis of how well they fit the Arduino 400 environment. Note that the results are preliminary, and could easily 401 be affected in any direction by implementation bugs, configuration 402 errors, and other mistakes. Please verify the numbers before relying 403 on them for building something. No significant effort was done to 404 optimize ROM memory usage beyond what the libraries provided 405 themselves, so those numbers should be taken as upper limits. 407 Here is the set of libraries we found: 409 o AvrCryptolib [avr-cryptolib]: This library provides a variety of 410 different symmetric key algorithms such as AES and RSA as an 411 asymmetric key algorithm. We stripped down the library to use 412 only the required RSA components and used a separate SHA-256 413 implementation from the original AvrCrypto-Lib library 414 [avr-crypto-lib]. Parts of SHA-256 and RSA algorithm 415 implementations were written in AVR-8 bit assembly language to 416 reduce the size and optimize the performance. The library also 417 takes advantage of the fact that Arduino boards allow the 418 programmer to directly address the flash memory to access constant 419 data which can save the amount of SRAM used during execution. 421 o Relic-Toolkit [relic-toolkit]: This library is written entirely in 422 C and provides a highly flexible and customizable implementation 423 of a large variety of cryptographic algorithms. This not only 424 includes RSA and ECC, but also pairing based asymmetric 425 cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures 426 and many more. The toolkit provides an option to build only the 427 desired components for the required platform. While building the 428 library, it is possible to select a variety mathematical 429 optimizations that can be combined to obtain the desired 430 performance (as a general thumb rule, faster implementations 431 require more SRAM and flash). It includes a multi precision 432 integer math module which can be customized to use different bit- 433 length words. 435 o TinyECC [tinyecc]: TinyECC was designed for using Elliptic Curve 436 based public key cryptography on sensor networks. It is written 437 in nesC programming language and as such is designed for specific 438 use on TinyOS. However, the library can be ported to standard C99 439 either with hacked tool-chains or manually rewriting parts of the 440 code. This allows for the library to be used on platforms that do 441 not have TinyOS running on them. The library includes a wide 442 variety of mathematical optimizations such as sliding window, 443 Barrett reduction for verification, precomputation, etc. It also 444 has one of the smallest memory footprints among the set of 445 Elliptic Curve libraries surveyed so far. However, an advantage 446 of Relic over TinyECC is that it can do curves over binary fields 447 in addition to prime fields. 449 o Wiselib [wiselib]: Wiselib is a generic library written for sensor 450 networks containing a wide variety of algorithms. While the 451 stable version contains algorithms for routing only, the test 452 version includes many more algorithms including algorithms for 453 cryptography, localization , topology management and many more. 454 The library was designed with the idea of making it easy to 455 interface the library with operating systems like iSense and 456 Contiki. However, since the library is written entirely in C++ 457 with a template based model similar to Boost/CGAL, it can be used 458 on any platform directly without using any of the operating system 459 interfaces provided. This approach was taken by the authors to 460 test the code on Arduino Uno. The structure of the code is similar 461 to TinyECC and like TinyECC it implements elliptic curves over 462 prime fields only. In order to make the code platform 463 independent, no assembly level optimizations were incorporated. 464 Since efficiency was not an important goal for the authors of the 465 library while designing, many well known theoretical performance 466 enhancement features were also not incorporated. Like the relic- 467 toolkit, Wiselib is also Lesser GPL licensed. 469 o MatrixSSL [matrix-ssl]: This library provides a low footprint 470 implementation of several cryptographic algorithms including RSA 471 and ECC (with a commercial license). However, the library in the 472 original form takes about 50 kB of ROM which is not suitable for 473 our hardware requirements. Moreover, it is intended for 32-bit 474 systems and the API includes functions for SSL communication 475 rather than just signing data with private keys. 477 This is by no ways an exhaustive list and there exist other 478 cryptographic libraries targeting resource-constrained devices. 480 8. Implementation Experiences 482 While evaluating the implementation experiences, we were particularly 483 interested in the signature generation operation. This was because 484 our example application discussed in Section 9 required only the 485 signature generation operation on the resource-constrained platforms. 486 We have summarized the initial results of RSA private key performance 487 using AvrCryptolib in Table 1. All results are from a single run 488 since repeating the test did not change (or had only minimal impact 489 on) the results. The keys were generated separately and were hard 490 coded into the program. All keys were generated with the value of 491 the public exponent as 3. The performance of signing with private 492 key was faster for smaller key lengths as was expected. However the 493 increase in the execution time was considerable when the key size was 494 2048 bits. It is important to note that two different sets of 495 experiments were performed for each key length. In the first case, 496 the keys were loaded into the SRAM from the ROM (flash) before they 497 were used by any of the functions. However, in the second case, the 498 keys were addressed directly in the ROM. As was expected, the second 499 case used less SRAM but lead to longer execution time. 501 More importantly, any RSA key size less than 2,048-bit should be 502 considered legacy and insecure. The performance measurements for 503 these keys are provided here for reference only. 505 +--------+--------------+--------------+-------------+--------------+ 506 | Key | Execution | Memory | Execution | Memory | 507 | length | time (ms); | footprint | time (ms); | footprint | 508 | (bits) | key in SRAM | (bytes); key | key in ROM | (bytes); key | 509 | | | in SRAM | | in ROM | 510 +--------+--------------+--------------+-------------+--------------+ 511 | 64 | 64 | 40 | 69 | 32 | 512 | 128 | 434 | 80 | 460 | 64 | 513 | 512 | 25,076 | 320 | 27348 | 256 | 514 | 1,024 | 199688 | 640 | 218367 | 512 | 515 | 2,048 | 1587567 | 1,280 | 1740258 | 1,024 | 516 +--------+--------------+--------------+-------------+--------------+ 518 RSA private key operation performance 520 Table 1 522 The code size was less than 3.6 kB for all the test cases with scope 523 for further reduction. It is also worth noting that the 524 implementation performs basic exponentiation and multiplication 525 operations without using any mathematical optimizations such as 526 Montgomery multiplication, optimized squaring, etc. as described in 527 [rsa-high-speed]. With more SRAM, we believe that 1024/2048-bit 528 operations can be performed in much less time as has been shown in 529 [rsa-8bit]. 2048-bit RSA is nonetheless possible with about 1 kB of 530 SRAM as is seen in Table 1. 532 In Table 2 we present the results obtained by manually porting 533 TinyECC into C99 standard and running ECDSA signature algorithm on 534 the Arduino Uno board. TinyECC supports a variety of SEC 2 535 recommended Elliptic Curve domain parameters. The execution time and 536 memory footprint are shown next to each of the curve parameters. 537 SHA-1 hashing algorithm included in the library was used in each of 538 the cases. The measurements reflect the performance of elliptic 539 curve signing only and not the SHA-1 hashing algorithm. SHA-1 is now 540 known to be insecure and should not be used in real deployments. It 541 is clearly observable that for similar security levels, Elliptic 542 Curve public key cryptography outperforms RSA. These results were 543 obtained by turning on all the optimizations. These optimizations 544 include - Curve Specific Optimizations for modular reduction (NIST 545 and SEC 2 field primes were chosen as pseudo-Mersenne primes), 546 Sliding Window for faster scalar multiplication, Hybrid squaring 547 procedure written in assembly and Weighted projective Coordinate 548 system for efficient scalar point addition, doubling and 549 multiplication. We did not use optimizations like Shamir Trick and 550 Sliding Window as they are only useful for signature verification and 551 tend to slow down the signature generation by precomputing values (we 552 were only interested in fast signature generation). There is still 553 some scope for optimization as not all the assembly code provided 554 with the library could be ported to Arduino directly. Re-writing 555 these procedures in compatible assembly would further enhance the 556 performance. 558 +-------------+---------------+-----------------+-------------------+ 559 | Curve | Execution | Memory | Comparable RSA | 560 | parameters | time (ms) | Footprint | key length | 561 | | | (bytes) | | 562 +-------------+---------------+-----------------+-------------------+ 563 | 128r1 | 1858 | 776 | 704 | 564 | 128r2 | 2002 | 776 | 704 | 565 | 160k1 | 2228 | 892 | 1024 | 566 | 160r1 | 2250 | 892 | 1024 | 567 | 160r2 | 2467 | 892 | 1024 | 568 | 192k1 | 3425 | 1008 | 1536 | 569 | 192r1 | 3578 | 1008 | 1536 | 570 +-------------+---------------+-----------------+-------------------+ 572 ECDSA signature performance with TinyECC 574 Table 2 576 We also performed experiments by removing the assembly code for 577 hybrid multiplication and squaring thus using a C only form of the 578 library. This gives us an idea of the performance that can be 579 achieved with TinyECC on any platform regardless of what kind of OS 580 and assembly instruction set available. The memory footprint remains 581 the same with our without assembly code. The tables contain the 582 maximum RAM that is used when all the possible optimizations are on. 583 If however, the amount of RAM available is smaller in size, some of 584 the optimizations can be turned off to reduce the memory consumption 585 accordingly. 587 +-------------+---------------+-----------------+-------------------+ 588 | Curve | Execution | Memory | Comparable RSA | 589 | parameters | time (ms) | Footprint | key length | 590 | | | (bytes) | | 591 +-------------+---------------+-----------------+-------------------+ 592 | 128r1 | 2741 | 776 | 704 | 593 | 128r2 | 3086 | 776 | 704 | 594 | 160k1 | 3795 | 892 | 1024 | 595 | 160r1 | 3841 | 892 | 1024 | 596 | 160r2 | 4118 | 892 | 1024 | 597 | 192k1 | 6091 | 1008 | 1536 | 598 | 192r1 | 6217 | 1008 | 1536 | 599 +-------------+---------------+-----------------+-------------------+ 601 ECDSA signature performance with TinyECC (No assembly optimizations) 603 Table 3 605 Table 4 documents the performance of Wiselib. Since there were no 606 optimizations that could be turned on or off, we have only one set of 607 results. By default Wiselib only supports some of the standard SEC 2 608 Elliptic curves. But it is easy to change the domain parameters and 609 obtain results for for all the 128, 160 and 192-bit SEC 2 Elliptic 610 curves. SHA-1 algorithm provided in the library was used. The 611 measurements reflect the performance of elliptic curve signing only 612 and not the SHA-1 hashing algorithm. SHA-1 is now known to be 613 insecure and should not be used in real deployments. The ROM size 614 for all the experiments was less than 16 kB. 616 +-------------+---------------+-----------------+-------------------+ 617 | Curve | Execution | Memory | Comparable RSA | 618 | parameters | time (ms) | Footprint | key length | 619 | | | (bytes) | | 620 +-------------+---------------+-----------------+-------------------+ 621 | 128r1 | 5615 | 732 | 704 | 622 | 128r2 | 5615 | 732 | 704 | 623 | 160k1 | 10957 | 842 | 1024 | 624 | 160r1 | 10972 | 842 | 1024 | 625 | 160r2 | 10971 | 842 | 1024 | 626 | 192k1 | 18814 | 952 | 1536 | 627 | 192r1 | 18825 | 952 | 1536 | 628 +-------------+---------------+-----------------+-------------------+ 630 ECDSA signature performance with Wiselib 632 Table 4 634 For testing the relic-toolkit we used a different board because it 635 required more RAM/ROM and we were unable to perform experiments with 636 it on Arduino Uno. We decided to use the Arduino Mega which has the 637 same 8-bit architecture like the Arduino Uno but has a much larger 638 RAM/ROM for testing relic-toolkit. Again, SHA-1 hashing algorithm 639 included in the library was used in each of the cases. The 640 measurements reflect the performance of elliptic curve signing only 641 and not the SHA-1 hashing algorithm. SHA-1 is now known to be 642 insecure and should not be used in real deployments. The library 643 does provide several alternatives with such as SHA-256. 645 The relic-toolkit supports Koblitz curves over prime as well as 646 binary fields. We have experimented with Koblitz curves over binary 647 fields only. We do not run our experiments with all the curves 648 available in the library since the aim of this work is not prove 649 which curves perform the fastest, and rather show that asymmetric 650 crypto is possible on resource-constrained devices. 652 The results from relic-toolkit are documented in two separate tables 653 shown in Table 5 and Table 6. The first set of results were 654 performed with the library configured for high speed performance with 655 no consideration given to the amount of memory used. For the second 656 set, the library was configured for low memory usage irrespective of 657 the execution time required by different curves. By turning on/off 658 optimizations included in the library, a trade-off between memory and 659 execution time between these values can be achieved. 661 +-----------------+--------------+----------------+-----------------+ 662 | Curve | Execution | Memory | Comparable RSA | 663 | parameters | time (ms) | Footprint | key length | 664 | | | (bytes) | | 665 +-----------------+--------------+----------------+-----------------+ 666 | NIST K163 | 261 | 2,804 | 1024 | 667 | (assembly math) | | | | 668 | NIST K163 | 932 | 2750 | 1024 | 669 | NIST B163 | 2243 | 2444 | 1024 | 670 | NIST K233 | 1736 | 3675 | 2048 | 671 | NIST B233 | 4471 | 3261 | 2048 | 672 +-----------------+--------------+----------------+-----------------+ 674 ECDSA signature performance with relic-toolkit (Fast) 676 Table 5 678 +-----------------+--------------+----------------+-----------------+ 679 | Curve | Execution | Memory | Comparable RSA | 680 | parameters | time (ms) | Footprint | key length | 681 | | | (bytes) | | 682 +-----------------+--------------+----------------+-----------------+ 683 | NIST K163 | 592 | 2087 | 1024 | 684 | (assembly math) | | | | 685 | NIST K163 | 2950 | 2215 | 1024 | 686 | NIST B163 | 3213 | 2071 | 1024 | 687 | NIST K233 | 6450 | 2935 | 2048 | 688 | NIST B233 | 6100 | 2737 | 2048 | 689 +-----------------+--------------+----------------+-----------------+ 691 ECDSA signature performance with relic-toolkit (Low Memory) 693 Table 6 695 It is important to note the following points about the elliptic curve 696 measurements: 698 o As with the RSA measurements, curves giving less that 112-bit 699 security are insecure and considered as legacy. The measurements 700 are only provided for reference. 702 o The arduino board only provides pseudo random numbers with the 703 random() function call. In order to create private keys with a 704 better quality of random number, we can use a true random number 705 generator like the one provided by TrueRandom library 706 [truerandom], or create the keys separately on a system with a 707 true random number generator and then use them directly in the 708 code. 710 o For measuring the memory footprint of all the ECC libraries, we 711 used the Avrora simulator [avrora]. Only stack memory was used to 712 easily track the RAM consumption. 714 At the time of performing these measurements and study, it was 715 unclear which exact elliptic curve(s) would be selected by the IETF 716 community for use with resource-constrained devices. However now, 717 [RFC7748] defines two elliptic curves over prime fields (Curve25519 718 and Curve448) that offer a high level of practical security for 719 Diffie-Hellman key exchange. Correspondingly, there is ongoing work 720 to specify elliptic curve signature schemes with Edwards-curve 721 Digital Signature Algorithm (EdDSA). [I-D.irtf-cfrg-eddsa] specifies 722 the recommended parameters for the edwards25519 and edwards448 723 curves. From these, curve25519 (for elliptic curve Diffie-Hellman 724 key exchange) and edwards25519 (for elliptic curve digital 725 signatures) are especially suitable for resource-constrained devices. 727 We found that the NaCl [nacl] and MicoNaCl [micronacl] libraries 728 provide highly efficient implementations of Diffie-Hellman key 729 exchange with curve25519. The results have shown that these 730 libraries with curve25519 outperform other elliptic curves that 731 provide similar levels of security. Hutter and Schwabe [naclavr] 732 also show that signing of data using the curve Ed25519 from the NaCl 733 library needs only 23,216,241 cycles on the same microcontroller that 734 we used for our evaluations (Arduino Mega ATmega2560). This 735 corresponds to about 1,4510 milliseconds of execution time. When 736 compared to the results for other curves and libraries that offer 737 similar level of security (such as NIST B233, NIST K233), this 738 implementation far outperforms all others. As such, it is recommend 739 that the IETF community uses these curves for protocol specification 740 and implementations. 742 A summary library ROM use is shown in Table 7. 744 +-------------------------+---------------------------+ 745 | Library | ROM Footprint (Kilobytes) | 746 +-------------------------+---------------------------+ 747 | AvrCryptolib | 3.6 | 748 | Wiselib | 16 | 749 | TinyECC | 18 | 750 | Relic-toolkit | 29 | 751 | NaCl Ed25519 [naclavr] | 17-29 | 752 +-------------------------+---------------------------+ 754 Summary of library ROM needs 756 Table 7 758 All the measurements here are only provided as an example to show 759 that asymmetric-key cryptography (particularly, digital signatures) 760 is possible on resource-constrained devices. These numbers by no way 761 are the final source for measurements and some curves presented here 762 may not be acceptable for real in-the-wild deployments anymore. For 763 example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also 764 document performance of ECDSA on similar resource-constrained 765 devices. 767 9. Example Application 769 We developed an example application on the Arduino platform to use 770 public key crypto mechanisms, data object security, and an easy 771 provisioning model. Our application was originally developed to test 772 different approaches to supporting communications to "always off" 773 sensor nodes. These battery-operated or energy scavenging nodes do 774 not have enough power to be stay on at all times. They wake up 775 periodically and transmit their readings. 777 Such sensor nodes can be supported in various ways. 778 [I-D.arkko-core-sleepy-sensors] was an early multicast-based 779 approach. In the current application we have switched to using 780 resource directories [I-D.ietf-core-resource-directory] and mirror 781 proxies [I-D.vial-core-mirror-proxy] instead. Architecturally, the 782 idea is that sensors can delegate a part of their role to a node in 783 the network. Such a network node could be either a local resource or 784 something in the Internet. In the case of CoAP mirror proxies, the 785 network node agrees to hold the web resources on behalf of the 786 sensor, while the sensor is asleep. The only role that the sensor 787 has is to register itself at the mirror proxy, and periodically 788 update the readings. All queries from the rest of the world go to 789 the mirror proxy. 791 We constructed a system with four entities: 793 Sensor 795 This is an Arduino-based device that runs a CoAP mirror proxy 796 client and Relic-toolkit. Relic takes 29 Kbytes of ROM, and the 797 simple CoAP client roughly 3 kilobytes. 799 Mirror Proxy 801 This is a mirror proxy that holds resources on the sensor's 802 behalf. The sensor registers itself to this node. 804 Resource Directory 806 While physically in the same node in our implementation, a 807 resource directory is a logical function that allows sensors and 808 mirror proxies to register resources in the directory. These 809 resources can be queried by applications. 811 Application 813 This is a simple application that runs on a general purpose 814 computer and can retrieve both registrations from the resource 815 directory and most recent sensor readings from the mirror proxy. 817 The security of this system relies on an SSH-like approach. In Step 818 1, upon first boot, sensors generate keys and register themselves in 819 the mirror proxy. Their public key is submitted along with the 820 registration as an attribute in the CORE Link Format data [RFC6690]. 822 In Step 2, when the sensor makes a sensor reading update to the 823 mirror proxy it signs the message contents with a JOSE signature on 824 the used JSON/SENML payload [RFC7515] [I-D.jennings-core-senml]. 826 In Step 3, any other device in the network -- including the mirror 827 proxy, resource directory and the application -- can check that the 828 public key from the registration corresponds to the private key used 829 to make the signature in the data update. 831 Note that checks can be done at any time and there is no need for the 832 sensor and the checking node to be awake at the same time. In our 833 implementation, the checking is done in the application node. This 834 demonstrates how it is possible to implement end-to-end security even 835 with the presence of assisting middleboxes. 837 To verify the feasibility of our architecture we developed a proof- 838 of-concept prototype. In our prototype, the sensor was implemented 839 using the Arduino Ethernet shield over an Arduino Mega board. Our 840 implementation uses the standard C99 programming language on the 841 Arduino Mega board. In this prototype, the Mirror Proxy (MP) and the 842 Resource Directory (RD) reside on the same physical host. A 64-bit 843 x86 linux machine serves as the MP and the RD, while a similar but 844 physically different 64-bit x86 linux machine serves as the client 845 that requests data from the sensor. We chose the Relic library 846 version 0.3.1 for our sample prototype as it can be easily compiled 847 for different bit-length processors. Therefore, we were able to use 848 it on the 8-bit processor of the Arduino Mega, as well as on the 849 64-bit processor of the x86 client. We used ECDSA to sign and verify 850 data updates with the standard NIST-K163 curve parameters (163-bit 851 Koblitz curve over binary field). While compiling Relic for our 852 prototype, we used the fast configuration without any assembly 853 optimizations. 855 The gateway implements the CoAP base specification in the Java 856 programming language and extends it to add support for Mirror Proxy 857 and Resource Directory REST interfaces. We also developed a 858 minimalistic CoAP C-library for the Arduino sensor and for the client 859 requesting data updates for a resource. The library has small SRAM 860 requirements and uses stack-based allocation only. It is inter- 861 operable with the Java implementation of CoAP running on the gateway. 862 The location of the mirror proxy was pre-configured into the smart 863 object sensor by hardcoding the IP address. We used an IPv4 network 864 with public IP addresses obtained from a DHCP server. 866 Some important statistics of this prototype are listed in table 867 Table 8. Our straw man analysis of the performance of this prototype 868 is preliminary. Our intention was to demonstrate the feasibility of 869 the entire architecture with public-key cryptography on an 8-bit 870 microcontroller. The stated values can be improved further by a 871 considerable amount. For example, the flash memory and SRAM 872 consumption is relatively high because some of the Arduino libraries 873 were used out-of-the- box and there are several functions which can 874 be removed. Similarly we used the fast version of the Relic library 875 in the prototype instead of the low memory version. 877 +-----------------------------------------------------------+-------+ 878 | Flash memory consumption (for the entire prototype | 51 kB | 879 | including Relic crypto + CoAP + Arduino UDP, Ethernet and | | 880 | DHCP Libraries) | | 881 | | | 882 | SRAM consumption (for the entire prototype including DHCP | 4678 | 883 | client + key generation + signing the hash of message + | bytes | 884 | COAP + UDP + Ethernet) | | 885 | | | 886 | Execution time for creating the key pair + sending | 2030 | 887 | registration message + time spent waiting for acknowl- | ms | 888 | edgement | | 889 | | | 890 | Execution time for signing the hash of message + sending | 987 | 891 | update | ms | 892 | | | 893 | Signature overhead | 42 | 894 | | bytes | 895 +-----------------------------------------------------------+-------+ 897 Prototype Performance 899 Table 8 901 To demonstrate the efficacy of this communication model we compare it 902 with a scenario where the smart objects do not transition into the 903 energy saving sleep mode and directly serve temperature data to 904 clients. As an example, we assume that in our architecture, the 905 smart objects wake up once every minute to report the signed 906 temperature data to the caching MP. If we calculate the energy 907 consumption using the formula W = U * I * t (where U is the operating 908 voltage, I is the current drawn and t is the execution time), and use 909 the voltage and current values from the datasheets of the ATmega2560 910 (20mA-active mode and 5.4mA-sleep mode) and W5100 (183mA) chips used 911 in the architecture, then in a one minute period, the Arduino board 912 would consume 60.9 Joules of energy if it directly serves data and 913 does not sleep. On the other hand, in our architecture it would only 914 consume 2.6 Joules if it wakes up once a minute to update the MP with 915 signed data. Therefore, a typical Li-ion battery that provides about 916 1800 milliamps per hour (mAh) at 5V would have a lifetime of 9 hours 917 in the unsecured always-on scenario, whereas it would have a lifetime 918 of about 8.5 days in the secured sleepy architecture presented. 919 These lifetimes appear to be low because the Arduino board in the 920 prototype uses Ethernet which is not energy efficient. The values 921 presented only provide an estimate (ignoring the energy required to 922 transition in and out of the sleep mode) and would vary depending on 923 the hardware and MAC protocol used. Nonetheless, it is evident that 924 our architecture can increase the life of smart objects by allowing 925 them to sleep and can ensure security at the same time. 927 10. Design Trade-Offs 929 This section attempts to make some early conclusions regarding trade- 930 offs in the design space, based on deployment considerations for 931 various mechanisms and the relative ease or difficulty of 932 implementing them. This analysis looks at layering and the choice of 933 symmetric vs. asymmetric cryptography. 935 11. Feasibility 937 The first question is whether using cryptographic security and 938 asymmetric cryptography in particular is feasible at all on small 939 devices. The numbers above give a mixed message. Clearly, an 940 implementation of a significant cryptographic operation such as 941 public key signing can be done in surprisingly small amount of code 942 space. It could even be argued that our chosen prototype platform 943 was unnecessarily restrictive in the amount of code space it allows: 944 we chose this platform on purpose to demonstrate something that is as 945 small and difficult as possible. 947 In reality, ROM memory size is probably easier to grow than other 948 parameters in microcontrollers. A recent trend in microcontrollers 949 is the introduction of 32-bit CPUs that are becoming cheaper and more 950 easily available than 8-bit CPUs, in addition to being more easily 951 programmable. In short, the authors do not expect the code size to 952 be a significant limiting factor, both because of the small amount of 953 code that is needed and because available memory space is growing 954 rapidly. 956 The situation is less clear with regards to the amount of CPU power 957 needed to run the algorithms. The demonstrated speeds are sufficient 958 for many applications. For instance, a sensor that wakes up every 959 now and then can likely spend a fraction of a second for the 960 computation of a signature for the message that it is about to send. 961 Or even spend multiple seconds in some cases. Most applications that 962 use protocols such as DTLS that use public key cryptography only at 963 the beginning of the session would also be fine with any of these 964 execution times. 966 Yet, with reasonably long key sizes the execution times are in the 967 seconds, dozens of seconds, or even longer. For some applications 968 this is too long. Nevertheless, the authors believe that these 969 algorithms can successfully be employed in small devices for the 970 following reasons: 972 o With the right selection of algorithms and libraries, the 973 execution times can actually be smaller. Using the Relic-toolkit 974 with the NIST K163 algorithm (roughly equivalent to RSA at 1024 975 bits) at 0.3 seconds is a good example of this. 977 o As discussed in [wiman], in general the power requirements 978 necessary to send or receive messages are far bigger than those 979 needed to execute cryptographic operations. There is no good 980 reason to choose platforms that do not provide sufficient 981 computing power to run the necessary operations. 983 o Commercial libraries and the use of full potential for various 984 optimizations will provide a better result than what we arrived at 985 in this paper. 987 o Using public key cryptography only at the beginning of a session 988 will reduce the per-packet processing times significantly. 990 12. Freshness 992 In our architecture, if implemented as described thus far, messages 993 along with their signatures sent from the sensors to the mirror proxy 994 can be recorded and replayed by an eavesdropper. The mirror proxy 995 has no mechanism to distinguish previously received packets from 996 those that are retransmitted by the sender or replayed by an 997 eavesdropper. Therefore, it is essential for the smart objects to 998 ensure that data updates include a freshness indicator. However, 999 ensuring freshness on constrained devices can be non-trivial because 1000 of several reasons which include: 1002 o Communication is mostly unidirectional to save energy. 1004 o Internal clocks might not be accurate and may be reset several 1005 times during the operational phase of the smart object. 1007 o Network time synchronization protocols such as Network Time 1008 Protocol (NTP) [RFC5905] are resource intensive and therefore may 1009 be undesirable in many smart object networks. 1011 There are several different methods that can be used in our 1012 architecture for replay protection. The selection of the appropriate 1013 choice depends on the actual deployment scenario. 1015 Including sequence numbers in signed messages can provide an 1016 effective method of replay protection. The mirror proxy should 1017 verify the sequence number of each incoming message and accept it 1018 only if it is greater than the highest previously seen sequence 1019 number. The mirror proxy drops any packet with a sequence number 1020 that has already been received or if the received sequence number is 1021 greater than the highest previously seen sequence number by an amount 1022 larger than the preset threshold. 1024 Sequence numbers can wrap-around at their maximum value and, 1025 therefore, it is essential to ensure that sequence numbers are 1026 sufficiently long. However, including long sequence numbers in 1027 packets can increase the network traffic originating from the sensor 1028 and can thus decrease its energy efficiency. To overcome the problem 1029 of long sequence numbers, we can use a scheme similar to that of 1030 Huang [huang], where the sender and receiver maintain and sign long 1031 sequence numbers of equal bit-lengths but they transmit only the 1032 least significant bits. 1034 It is important for the smart object to write the sequence number 1035 into the permanent flash memory after each increment and before it is 1036 included in the message to be transmitted. This ensures that the 1037 sensor can obtain the last sequence number it had intended to send in 1038 case of a reset or a power failure. However, the sensor and the 1039 mirror proxy can still end up in a discordant state where the 1040 sequence number received by the mirror proxy exceeds the expected 1041 sequence number by an amount greater than the preset threshold. This 1042 may happen because of a prolonged network outage or if the mirror 1043 proxy experiences a power failure for some reason. Therefore it is 1044 essential for sensors that normally send Non-Confirmable data updates 1045 to send some Confirmable updates and re-synchronize with the mirror 1046 proxy if a reset message is received. The sensors re-synchronize by 1047 sending a new registration message with the current sequence number. 1049 Although sequence numbers protect the system from replay attacks, a 1050 mirror proxy has no mechanism to determine the time at which updates 1051 were created by the sensor. Moreover, if sequence numbers are the 1052 only freshness indicator used, a malicious eavesdropper can induce 1053 inordinate delays to the communication of signed updates by buffering 1054 messages. It may be important in certain smart object networks for 1055 sensors to send data updates which include timestamps to allow the 1056 mirror proxy to determine the time when the update was created. For 1057 example, when the mirror proxy is collecting temperature data, it may 1058 be necessary to know when exactly the temperature measurement was 1059 made by the sensor. A simple solution to this problem is for the 1060 mirror proxy to assume that the data object was created when it 1061 receives the update. In a relatively reliable network with low RTT, 1062 it can be acceptable to make such an assumption. However most 1063 networks are susceptible to packet loss and hostile attacks making 1064 this assumption unsustainable. 1066 Depending on the hardware used by the smart objects, they may have 1067 access to accurate hardware clocks which can be used to include 1068 timestamps in the signed updates. These timestamps are included in 1069 addition to sequence numbers. The clock time in the smart objects 1070 can be set by the manufacturer or the current time can be 1071 communicated by the mirror proxy during the registration phase. 1072 However, these approaches require the smart objects to either rely on 1073 the long-term accuracy of the clock set by the manufacturer or to 1074 trust the mirror proxy thereby increasing the potential vulnerability 1075 of the system. The smart objects could also obtain the current time 1076 from NTP, but this may consume additional energy and give rise to 1077 security issues discussed in [RFC5905]. The smart objects could also 1078 have access to a GSM network or the Global Positioning System (GPS), 1079 and they can be used obtain the current time. Finally, if the 1080 sensors need to co-ordinate their sleep cycles, or if the mirror 1081 proxy computes an average or mean of updates collected from multiple 1082 smart objects, it is important for the network nodes to synchronize 1083 the time among them. This can be done by using existing 1084 synchronization schemes. 1086 13. Layering 1088 It would be useful to select just one layer where security is 1089 provided at. Otherwise a simple device needs to implement multiple 1090 security mechanisms. While some code can probably be shared across 1091 such implementations (like algorithms), it is likely that most of the 1092 code involving the actual protocol machinery cannot. Looking at the 1093 different layers, here are the choices and their implications: 1095 link layer 1097 This is probably the most common solution today. The biggest 1098 benefits of this choice of layer are that security services are 1099 commonly available (WLAN secrets, cellular SIM cards, etc.) and 1100 that their application protects the entire communications. 1102 The main drawback is that there is no security beyond the first 1103 hop. This can be problematic, e.g., in many devices that 1104 communicate to a server in the Internet. A Withings scale 1105 [Withings], for instance, can support WLAN security but without 1106 some level of end-to-end security, it would be difficult to 1107 prevent fraudulent data submissions to the servers. 1109 Another drawback is that some commonly implemented link layer 1110 security designs use group secrets. This allows any device within 1111 the local network (e.g., an infected laptop) to attack the 1112 communications. 1114 network layer 1115 There are a number of solutions in this space, and many new ones 1116 and variations thereof being proposed: IPsec, PANA, and so on. In 1117 general, these solutions have similar characteristics to those in 1118 the transport layer: they work across forwarding hops but only as 1119 far as to the next middlebox or application entity. There is 1120 plenty of existing solutions and designs. 1122 Experience has shown that it is difficult to control IP layer 1123 entities from an application process. While this is theoretically 1124 easy, in practice the necessary APIs do not exist. For instance, 1125 most IPsec software has been built for the VPN use case, and is 1126 difficult or impossible to tweak to be used on a per-application 1127 basis. As a result, the authors are not particularly enthusiastic 1128 about recommending these solutions. 1130 transport and application layer 1132 This is another popular solution along with link layer designs. 1133 TLS with HTTP (HTTPS) and DTLS with CoAP are examples of solutions 1134 in this space, and have been proven to work well. These solutions 1135 are typically easy to take into use in an application, without 1136 assuming anything from the underlying OS, and they are easy to 1137 control as needed by the applications. The main drawback is that 1138 generally speaking, these solutions only run as far as the next 1139 application level entity. And even for this case, HTTPS can be 1140 made to work through proxies, so this limit is not unsolvable. 1141 Another drawback is that attacks on link layer, network layer and 1142 in some cases, transport layer, can not be protected against. 1143 However, if the upper layers have been protected, such attacks can 1144 at most result in a denial-of-service. Since denial-of-service 1145 can often be caused anyway, it is not clear if this is a real 1146 drawback. 1148 data object layer 1150 This solution does not protect any of the protocol layers, but 1151 protects individual data elements being sent. It works 1152 particularly well when there are multiple application layer 1153 entities on the path of the data. The authors believe smart 1154 object networks are likely to employ such entities for storage, 1155 filtering, aggregation and other reasons, and as such, an end-to- 1156 end solution is the only one that can protect the actual data. 1158 The downside is that the lower layers are not protected. But 1159 again, as long as the data is protected and checked upon every 1160 time it passes through an application level entity, it is not 1161 clear that there are attacks beyond denial-of-service. 1163 The main question mark is whether this type of a solution provides 1164 sufficient advantages over the more commonly implemented transport 1165 and application layer solutions. 1167 14. Symmetric vs. Asymmetric Crypto 1169 The second trade-off that is worth discussing is the use of plain 1170 asymmetric cryptographic mechanisms, plain symmetric cryptographic 1171 mechanisms, or some mixture thereof. 1173 Contrary to popular cryptographic community beliefs, a symmetric 1174 crypto solution can be deployed in large scale. In fact, one of the 1175 largest deployment of cryptographic security, the cellular network 1176 authentication system, uses SIM cards that are based on symmetric 1177 secrets. In contrast, public key systems have yet to show ability to 1178 scale to hundreds of millions of devices, let alone billions. But 1179 the authors do not believe scaling is an important differentiator 1180 when comparing the solutions. 1182 As can be seen from the Section 8, the time needed to calculate some 1183 of the asymmetric crypto operations with reasonable key lengths can 1184 be significant. There are two contrary observations that can be made 1185 from this. First, recent wisdom indicates that computing power on 1186 small devices is far cheaper than transmission power [wiman], and 1187 keeps on becoming more efficient very quickly. From this we can 1188 conclude that the sufficient CPU is or at least will be easily 1189 available. 1191 But the other observation is that when there are very costly 1192 asymmetric operations, doing a key exchange followed by the use of 1193 generated symmetric keys would make sense. This model works very 1194 well for DTLS and other transport layer solutions, but works less 1195 well for data object security, particularly when the number of 1196 communicating entities is not exactly two. 1198 15. Security Considerations 1200 This entire memo deals with security issues. 1202 16. IANA Considerations 1204 There are no IANA impacts in this memo. 1206 17. Informative references 1208 [arduino-uno] 1209 Arduino, "Arduino Uno", September 2015, 1210 . 1212 [avr-crypto-lib] 1213 AVR-CRYPTO-LIB, "AVR-CRYPTO-LIB", September 2015, 1214 . 1216 [avr-cryptolib] 1217 Van der Laan, E., "AVR CRYPTOLIB", September 2015, 1218 . 1220 [avrora] Titzer, Ben., "Avrora", September 2015, 1221 . 1223 [huang] Huang, C., "Low-overhead freshness transmission in sensor 1224 networks", 2008. 1226 [I-D.arkko-core-security-arch] 1227 Arkko, J. and A. Keranen, "CoAP Security Architecture", 1228 draft-arkko-core-security-arch-00 (work in progress), July 1229 2011. 1231 [I-D.arkko-core-sleepy-sensors] 1232 Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. 1233 Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- 1234 sleepy-sensors-01 (work in progress), July 2011. 1236 [I-D.daniel-6lowpan-security-analysis] 1237 Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. 1238 Laganier, "IPv6 over Low Power WPAN Security Analysis", 1239 draft-daniel-6lowpan-security-analysis-05 (work in 1240 progress), March 2011. 1242 [I-D.ietf-core-resource-directory] 1243 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 1244 Resource Directory", draft-ietf-core-resource-directory-08 1245 (work in progress), July 2016. 1247 [I-D.irtf-cfrg-eddsa] 1248 Josefsson, S. and I. Liusvaara, "Edwards-curve Digital 1249 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08 1250 (work in progress), August 2016. 1252 [I-D.irtf-t2trg-iot-seccons] 1253 Garcia-Morchon, O., Kumar, S., and M. Sethi, "Security 1254 Considerations in the IP-based Internet of Things", draft- 1255 irtf-t2trg-iot-seccons-00 (work in progress), October 1256 2016. 1258 [I-D.jennings-core-senml] 1259 Jennings, C., Shelby, Z., Arkko, J., and A. Keranen, 1260 "Media Types for Sensor Markup Language (SenML)", draft- 1261 jennings-core-senml-06 (work in progress), April 2016. 1263 [I-D.moskowitz-hip-dex] 1264 Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", 1265 draft-moskowitz-hip-dex-05 (work in progress), January 1266 2016. 1268 [I-D.vial-core-mirror-proxy] 1269 Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- 1270 proxy-01 (work in progress), July 2012. 1272 [matrix-ssl] 1273 PeerSec Networks, "Matrix SSL", September 2015, 1274 . 1276 [micronacl] 1277 MicroNaCl, "The Networking and Cryptography library for 1278 microcontrollers", . 1280 [mosdorf] Mosdorf, M. and W. Zabolotny, "Implementation of elliptic 1281 curve cryptography for 8 bit and 32 bit embedded systems 1282 time efficiency and power consumption analysis", 2010. 1284 [nacl] NaCl, "Networking and Cryptography library", 1285 . 1287 [naclavr] Hutter, M. and P. Schwabe, "NaCl on 8-Bit AVR 1288 Microcontrollers", International Conference on Cryptology 1289 in Africa , Springer Berlin Heidelberg , 2013. 1291 [relic-toolkit] 1292 Aranha, D. and C. Gouv, "Relic Toolkit", September 2015, 1293 . 1295 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1296 Levkowetz, Ed., "Extensible Authentication Protocol 1297 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1298 . 1300 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1301 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1302 . 1304 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1305 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1306 . 1308 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1309 and A. Yegin, "Protocol for Carrying Authentication for 1310 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1311 May 2008, . 1313 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1314 (TLS) Protocol Version 1.2", RFC 5246, 1315 DOI 10.17487/RFC5246, August 2008, 1316 . 1318 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 1319 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 1320 February 2009, . 1322 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1323 "Network Time Protocol Version 4: Protocol and Algorithms 1324 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1325 . 1327 [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) 1328 Immediate Carriage and Conveyance of Upper-Layer Protocol 1329 Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078, 1330 January 2011, . 1332 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1333 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1334 January 2012, . 1336 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 1337 Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, 1338 . 1340 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1341 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1342 . 1344 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1345 Application Protocol (CoAP)", RFC 7252, 1346 DOI 10.17487/RFC7252, June 2014, 1347 . 1349 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1350 Kivinen, "Internet Key Exchange Protocol Version 2 1351 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1352 2014, . 1354 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1355 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1356 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1357 . 1359 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1360 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1361 2015, . 1363 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1364 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1365 2016, . 1367 [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 1368 (IKEv2) Initiator Implementation", RFC 7815, 1369 DOI 10.17487/RFC7815, March 2016, 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 [tinyecc] North Carolina State University and North Carolina State 1382 University, "TinyECC", 2008, 1383 . 1385 [truerandom] 1386 Drow, C., "Truerandom", September 2015, 1387 . 1389 [wiman] Margi, C., Oliveira, B., Sousa, G., Simplicio, M., Paulo, 1390 S., Carvalho, T., Naslund, M., and R. Gold, "Impact of 1391 Operating Systems on Wireless Sensor Networks (Security) 1392 Applications and Testbeds. In International Conference on 1393 Computer Communication Networks (ICCCN'2010) / IEEE 1394 International Workshop on Wireless Mesh and Ad Hoc 1395 Networks (WiMAN 2010), 2010, Zurich. Proceedings of 1396 ICCCN'2010/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