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