idnits 2.17.1 draft-aks-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 (February 21, 2012) is 4448 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-06 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-06) exists of draft-garcia-core-security-03 == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc5201-bis-07 == Outdated reference: A later version (-01) exists of draft-kivinen-ipsecme-ikev2-minimal-00 == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-rg-dex-05 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft A. Keranen 4 Intended status: Informational M. Sethi 5 Expires: August 24, 2012 Ericsson 6 February 21, 2012 8 Practical Considerations and Implementation Experiences in Securing 9 Smart Object Networks 10 draft-aks-crypto-sensors-00 12 Abstract 14 This memo describes challenges associated with securing smart object 15 devices in constrained implementations and environments. The memo 16 describes a possible deployment model suitable for these 17 environments, discusses the availability of cryptographic libraries 18 for small devices, presents some experiences in implementing small 19 devices using those libraries, and discusses trade-offs involving 20 different types of approaches. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 24, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5 60 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Protocol Architecture . . . . . . . . . . . . . . . . . . 7 62 4. Code Availability . . . . . . . . . . . . . . . . . . . . . . 8 63 5. Implementation Experiences . . . . . . . . . . . . . . . . . . 9 64 6. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 11 65 6.1. Feasibility . . . . . . . . . . . . . . . . . . . . . . . 11 66 6.2. Layering . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 6.3. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . 14 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 76 1. Introduction 78 This memo describes challenges associated with securing smart object 79 devices in constrained implementations and environments (see 80 Section 2). 82 Secondly, Section 3 discusses a deployment model that the authors are 83 considering for constrained environments. The model requires minimal 84 amount of configuration, and we believe it is a natural fit with the 85 typical communication practices smart object networking environments. 87 Thirdly, Section 4 discusses the availability of cryptographic 88 libraries. Section 5 presents some experiences in implementing small 89 devices using those libraries, including information about achievable 90 code sizes and speeds on typical hardware. 92 Finally, Section 6 discusses trade-offs involving different types of 93 security approaches. 95 1.1. Related Work 97 Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a 98 light-weight protocol designed to be used in machine-to-machine 99 applications such as smart energy and building automation. Our 100 discussion uses this protocol as an example, but the conclusions may 101 apply to other similar protocols. CoAP base specification 102 [I-D.ietf-core-coap] outlines how to use DTLS [RFC5238] and IPsec 103 [RFC4306] for securing the protocol. DTLS can be applied with group 104 keys, pairwise shared keys, or with certificates. The security model 105 in all cases is mutual authentication, so while there is some 106 commonality to HTTP in verifying the server identity, in practice the 107 models are quite different. The specification says little about how 108 DTLS keys are managed. The IPsec mode is described with regards to 109 the protocol requirements, noting that small implementations of IKEv2 110 exist [I-D.kivinen-ipsecme-ikev2-minimal]. However, the 111 specification is silent on policy and other aspects that are normally 112 necessary in order to implement interoperable use of IPsec in any 113 environment [RFC5406]. 115 [I-D.iab-smart-object-workshop] gives an overview of the security 116 discussions at the March 2011 IAB workshop on smart objects. The 117 workshop recommended that additional work is needed in developing 118 suitable credential management mechanisms (perhaps something similar 119 to the Bluetooth pairing mechanism), understanding the 120 implementability of standard security mechanisms in small devices and 121 additional research in the area of lightweight cryptographic 122 primitives. 124 [I-D.moskowitz-hip-rg-dex] defines a light-weight version of the HIP 125 protocol for low-power nodes. This version uses a fixed set of 126 algorithms, Elliptic Curve Cryptography (ECC), and eliminates hash 127 functions. The protocol still operates based on host identities, and 128 runs end-to-end between hosts, protecting IP layer communications. 129 [RFC6078] describes an extension of HIP that can be used to send 130 upper layer protocol messages without running the usual HIP base 131 exchange at all. 133 [I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis 134 of security issues related to 6LoWPAN networks, but its findings also 135 apply more generally for all low-powered networks. Some of the 136 issues this document discusses include the need to minimize the 137 number of transmitted bits and simplify implementations, threats in 138 the smart object networking environments, and the suitability of 139 6LoWPAN security mechanisms, IPsec, and key management protocols for 140 implementation in these environments. 142 [I-D.garcia-core-security] discusses the overall security problem for 143 Internet of Things devices. It also discusses various solutions, 144 including IKEv2/IPsec [RFC4306], TLS/SSL [RFC5246], DTLS [RFC5238], 145 HIP [RFC5201] [I-D.ietf-hip-rfc5201-bis] [I-D.moskowitz-hip-rg-dex], 146 PANA [RFC5191], and EAP [RFC3748]. The draft also discusses various 147 operational scenarios, bootstrapping mechanisms, and challenges 148 associated with implementing security mechanisms in these 149 environments. 151 2. 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 3. 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 3.1. 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. Actuator networks and server-to-device 243 communication is covered in Section 4.4 of 244 [I-D.arkko-core-security-arch]. 246 Where necessary, the information collected at installation time may 247 also include other parameters relevant to the application, such as 248 the location or purpose of the devices. This would enable the server 249 to know, for instance, that a particular device is the temperature 250 sensor for the kitchen. 252 Collecting the identity information at installation time can be 253 arranged in a number of ways. The authors have employed a simple but 254 not completely secure method where the last few digits of the 255 identity are printed on a tiny device just a few millimeters across. 256 Alternatively, the packaging for the device may include the full 257 identity (typically 32 hex digits), retrieved from the device at 258 manufacturing time. This identity can be read, for instance, by a 259 bar code reader carried by the installation personnel. (Note that 260 the identities are not secret, the security of the system is not 261 dependent on the identity information leaking to others. The real 262 owner of an identity can always prove its ownership with the private 263 key which never leaves the device.) Finally, the device may use its 264 wired network interface or proximity-based communications, such as 265 Near-Field Communications (NFC) or Radio-Frequency Identity tags 266 (RFIDs). Such interfaces allow secure communication of the device 267 identity to an information gathering device at installation time. 269 No matter what the method of information collection is, this 270 provisioning model minimizes the effort required to set up the 271 security. Each device generates its own identity in a random, secure 272 key generation process. The identities are self-securing in the 273 sense that if you know the identity of the peer you want to 274 communicate with, messages from the peer can be signed by the peer's 275 private key and it is trivial to verify that the message came from 276 the expected peer. There is no need to configure an identity and 277 certificate of that identity separately. There is no need to 278 configure a group secret or a shared secret. There is no need to 279 configure a trust anchor. In addition, the identities are typically 280 collected anyway for application purposes (such as identifying which 281 sensor is in which room). Under most circumstances there is actually 282 no additional configuration effort from provisioning security. 284 Groups of devices can be managed through single identifiers as well. 285 See Section 4.2 in [I-D.arkko-core-security-arch] for further 286 information. 288 3.2. Protocol Architecture 290 As noted above, the starting point of the architecture is that nodes 291 self-generate secure identities which are then communicated out-of- 292 band to the peers that need to know what devices to trust. To 293 support this model in a protocol architecture, we also need to use 294 these secure identities to implement secure messaging between the 295 peers, explain how the system can respond to different types of 296 attacks such as replay attempts, and decide at what protocol layer 297 and endpoints the architecture should use. 299 The deployment itself is suitable for a variety of design choices 300 regarding layering and protocol mechanisms. 301 [I-D.arkko-core-security-arch] was mostly focused on employing end- 302 to-end data object security as opposed to hop-by-hop security. But 303 other approaches are possible. For instance, HIP in its 304 opportunistic mode could be used to implement largely the same 305 functionality at the IP layer. However, it is our belief that the 306 right layer for this solution is at the application layer. More 307 specifically, in the data formats transported in the payload part of 308 CoAP. This approach provides the following benefits: 310 o Ability for intermediaries to act as caches to support different 311 sleep schedules, without the security model being impacted. 313 o Ability for intermediaries to be built to perform aggregation, 314 filtering, storage and other actions, again without impacting the 315 security of the data being transmitted or stored. 317 o Ability to operate in the presence of traditional middleboxes, 318 such as a protocol translators or even NATs (not that we recommend 319 their use in these environments). 321 However, as we will see later there are also some technical 322 implications, namely that link, network, and transport layer 323 solutions are more likely to be able to benefit from sessions where 324 the cost of expensive operations can be amortized over multiple data 325 transmissions. While this is not impossible in data object security 326 solutions either, it is not the typical arrangement either. 328 4. Code Availability 330 For implementing public key cryptography on resource constrained 331 environments, we chose Arduino Uno board [arduino-uno] as the test 332 platform. Arduino Uno has an ATmega328 microcontroller with a clock 333 speed of 16 MHz, 2 kB of SRAM, and 32 kB of flash memory. For 334 selecting potential asymmetric cryptographic libraries, we did an 335 extensive survey and came up with an initial set of possible code 336 sources: 338 o AvrCryptolib [avr-cryptolib]: This library provides a variety of 339 different symmetric key algorithms such as DES/Triple DES/AES etc. 340 and RSA as an asymmetric key algorithm. We stripped down the 341 library to use only the required RSA components and used a 342 separate SHA-256 implementation from the original AvrCrypto-Lib 343 library [avr-crypto-lib]. Parts of SHA-256 and RSA algorithm 344 implementations were written in AVR-8 bit assembly language to 345 reduce the size and optimize the performance. The library also 346 takes advantage of the fact that Arduino boards allow the 347 programmer to directly address the flash memory to access constant 348 data which can save the amount of SRAM used during execution. 350 o Relic-Toolkit [relic-toolkit]: This library is written entirely in 351 C and provides a highly flexible and customizable implementation 352 of a large variety of cryptographic algorithms. This not only 353 includes RSA and ECC, but also pairing based asymmetric 354 cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures 355 and many more. The toolkit provides an option to build only the 356 desired components for the required platform. While building the 357 library, it is possible to select a variety mathematical 358 optimizations that can be combined to obtain the desired 359 performance (as a general thumb rule, faster implementations 360 require more SRAM and flash). It includes a multi precision 361 integer math module which can be customized to use different bit- 362 length words. 364 o TinyECC [tinyecc]: TinyECC was designed for using Elliptic Curve 365 based public key cryptography on sensor networks. It is written 366 in nesC programming language and as such is designed for specific 367 use on TinyOS. However, the library can be ported to standard C99 368 either with hacked tool-chains or manually rewriting parts of the 369 code. This allows for the library to be used on platforms that do 370 not have TinyOS running on them. The library includes a wide 371 variety of mathematical optimizations such as sliding window, 372 Barrett reduction for verification, precomputation, etc. It also 373 has one of the smallest memory footprints among the set of 374 Elliptic Curve libraries surveyed so far. However, an advantage 375 of Relic over TinyECC is that it can do curves over binary fields 376 in addition to prime fields. 378 o MatrixSSL [matrix-ssl]: This library provides a low footprint 379 implementation of several cryptographic algorithms including RSA 380 and ECC (with a commercial license). However, the library in the 381 original form takes about 50 kB of ROM which is not suitable for 382 our hardware requirements. Moreover, it is intended for 32-bit 383 systems and the API includes functions for SSL communication 384 rather than just signing data with private keys. 386 5. Implementation Experiences 388 We have summarized the initial results of RSA private key performance 389 using AvrCryptolib in Table 1. All results are from a single run 390 since repeating the test did not change (or had only minimal impact 391 on) the results. The keys were generated separately and were hard 392 coded into the program. All keys were generated with the value of 393 the public exponent as 3. The performance of encryption with private 394 key was faster for smaller key lengths as was expected. However the 395 increase in the execution time was considerable when the key size was 396 2048 bits. It is important to note that two different sets of 397 experiments were performed for each key length. In the first case, 398 the keys were loaded into the SRAM from the ROM (flash) before they 399 were used by any of the functions. However, in the second case, the 400 keys were addressed directly in the ROM. As was expected, the second 401 case used less SRAM but lead to longer execution time. 403 +--------+--------------+--------------+-------------+--------------+ 404 | Key | Execution | Memory | Execution | Memory | 405 | length | time (ms); | footprint | time (ms); | footprint | 406 | (bits) | key in SRAM | (bytes); key | key in ROM | (bytes); key | 407 | | | in SRAM | | in ROM | 408 +--------+--------------+--------------+-------------+--------------+ 409 | 64 | 66 | 40 | 70 | 32 | 410 | 128 | 124 | 80 | 459 | 64 | 411 | 512 | 25,089 | 320 | 27,348 | 256 | 412 | 1,024 | 199,666 | 640 | 218,367 | 512 | 413 | 2,048 | 1,587,559 | 1,280 | 1,740,267 | 1,024 | 414 +--------+--------------+--------------+-------------+--------------+ 416 RSA private key operation performance 418 Table 1 420 The code size was less than 3.6 kB for all the test cases with scope 421 for further reduction. It is also worth noting that the 422 implementation performs basic exponentiation and multiplication 423 operations without using any mathematical optimizations such as 424 Montgomery multiplication, optimized squaring, etc. as described in 425 [rsa-high-speed]. With more SRAM, we believe that 1024/2048-bit 426 operations can be performed in much less time as has been shown in 427 [rsa-8bit]. 2048-bit RSA is nonetheless possible with about 1 kB of 428 SRAM as is seen in Table 1. 430 In Table 2 we present the initial set of results obtained by manually 431 porting TinyECC into C99 standard and running ECDSA signature 432 algorithm on the Arduino Uno board. TinyECC supports a variety of 433 SEC 2 recommended Elliptic Curve domain parameters. The execution 434 time and memory footprint are shown next to each of the curve 435 parameters. SHA-1 hashing algorithm included in the library was used 436 in each of the cases. It is clearly observable that for similar 437 security levels, Elliptic Curve public key cryptography outperforms 438 RSA. These were an initial set of experiments and there are further 439 test cases that need to be analyzed to correctly benchmark the 440 library. Several optimizations like optimized modular reduction, 441 sliding window and Barrett reduction for signature verification have 442 not been tested and remains as future work for the authors. 444 +-------------+---------------+-----------------+-------------------+ 445 | Curve | Execution | Memory | Comparable RSA | 446 | parameters | time (ms) | Footprint | key length | 447 | | | (bytes) | | 448 +-------------+---------------+-----------------+-------------------+ 449 | 128r1 | 2,919 | 390 | 704 | 450 | 128r2 | 3,315 | 390 | 704 | 451 | 160k1 | 4,631 | 438 | 1,024 | 452 | 160r1 | 4,990 | 438 | 1,024 | 453 | 160r2 | 4,992 | 438 | 1,024 | 454 | 192k1 | 7,817 | 486 | 1,536 | 455 | 192r1 | 8,071 | 486 | 1,536 | 456 +-------------+---------------+-----------------+-------------------+ 458 ECDSA signing performance 460 Table 2 462 6. Design Trade-Offs 464 This section attempts to make some early conclusions regarding trade- 465 offs in the design space, based on deployment considerations for 466 various mechanisms and the relative ease or difficulty of 467 implementing them. This analysis looks at layering and the choice of 468 symmetric vs. asymmetric cryptography. 470 6.1. Feasibility 472 The first question is whether using cryptographic security and 473 asymmetric cryptography in particular is feasible at all on small 474 devices. The numbers above give a mixed message. Clearly, an 475 implementation of a significant cryptographic operation such as 476 public key signing can be done in surprisingly small amount of code 477 space. It could even be argued that our chosen prototype platform 478 was unnecessarily restrictive in the amount of code space it allows: 479 we chose this platform on purpose to demonstrate something that is as 480 small and difficult as possible. 482 In reality, ROM memory size is probably easier to grow than other 483 parameters in microcontrollers. A recent trend in microcontrollers 484 is the introduction of 32-bit CPUs that are becoming cheaper and more 485 easily available than 8-bit CPUs, in addition to being more easily 486 programmable. In short, the authors do not expect the code size to 487 be a significant limiting factor, both because of the small amount of 488 code that is needed and because available memory space is growing 489 rapidly. 491 The situation is less clear with regards to the amount of CPU power 492 needed to run the algorithms. The demonstrated speeds are sufficient 493 for many applications. For instance, a sensor that wakes up every 494 now and then can likely spend a fraction of a second for the 495 computation of a signature for the message that it is about to send. 496 Or even spend multiple seconds in some cases. Most applications that 497 use protocols such as DTLS that use public key cryptography only at 498 the beginning of the session would also be fine with any of these 499 execution times. 501 Yet, with reasonably long key sizes the execution times are in the 502 seconds, dozens of seconds, or even longer. For some applications 503 this is too long. Nevertheless, the authors believe that these 504 algorithms can successfully be employed in small devices for the 505 following reasons: 507 o As discussed in [wiman], in general the power requirements 508 necessary to send or receive messages are far bigger than those 509 needed to execute cryptographic operations. There is no good 510 reason to choose platforms that do not provide sufficient 511 computing power to run the necessary operations. 513 o Commercial libraries and the use of full potential for various 514 optimizations will provide a better result than what we arrived at 515 in this paper. 517 o Using public key cryptography only at the beginning of a session 518 will reduce the per-packet processing times significantly. 520 6.2. Layering 522 It would be useful to select just one layer where security is 523 provided at. Otherwise a simple device needs to implement multiple 524 security mechanisms. While some code can probably be shared across 525 such implementations (like algorithms), it is likely that most of the 526 code involving the actual protocol machinery cannot. Looking at the 527 different layers, here are the choices and their implications: 529 link layer 531 This is probably the most common solution today. The biggest 532 benefits of this choice of layer are that security services are 533 commonly available (WLAN secrets, cellular SIM cards, etc.) and 534 that their application protects the entire communications. 536 The main drawback is that there is no security beyond the first 537 hop. This can be problematic, e.g., in many devices that 538 communicate to a server in the Internet. A Withings scale 540 [Withings], for instance, can support WLAN security but without 541 some level of end-to-end security, it would be difficult to 542 prevent fraudulent data submissions to the servers. 544 Another drawback is that some commonly implemented link layer 545 security designs use group secrets. This allows any device within 546 the local network (e.g., an infected laptop) to attack the 547 communications. 549 network layer 551 There are a number of solutions in this space, and many new ones 552 and variations thereof being proposed: IPsec, PANA, and so on. In 553 general, these solutions have similar characteristics to those in 554 the transport layer: they work across forwarding hops but only as 555 far as to the next middlebox or application entity. There is 556 plenty of existing solutions and designs. 558 Experience has shown that it is difficult to control IP layer 559 entities from an application process. While this is theoretically 560 easy, in practice the necessary APIs do not exist. For instance, 561 most IPsec software has been built for the VPN use case, and is 562 difficult or impossible to tweak to be used on a per-application 563 basis. As a result, the authors are not particularly enthusiastic 564 about recommending these solutions. 566 transport and application layer 568 This is another popular solution along with link layer designs. 569 SSL, TLS, DTLS, and HTTPS are examples of solutions in this space, 570 and have been proven to work well. These solutions are typically 571 easy to take into use in an application, without assuming anything 572 from the underlying OS, and they are easy to control as needed by 573 the applications. The main drawback is that generally speaking, 574 these solutions only run as far as the next application level 575 entity. And even for this case, HTTPS can be made to work through 576 proxies, so this limit is not unsolvable. Another drawback is 577 that attacks on link layer, network layer and in some cases, 578 transport layer, can not be protected against. However, if the 579 upper layers have been protected, such attacks can at most result 580 in a denial-of-service. Since denial-of-service can often be 581 caused anyway, it is not clear if this is a real drawback. 583 data object layer 585 This solution does not protect any of the protocol layers, but 586 protects individual data elements being sent. It works 587 particularly well when there are multiple application layer 588 entities on the path of the data. The authors believe smart 589 object networks are likely to employ such entities for storage, 590 filtering, aggregation and other reasons, and as such, an end-to- 591 end solution is the only one that can protect the actual data. 593 The downside is that the lower layers are not protected. But 594 again, as long as the data is protected and checked upon every 595 time it passes through an application level entity, it is not 596 clear that there are attacks beyond denial-of-service. 598 The main question mark is whether this type of a solution provides 599 sufficient advantages over the more commonly implemented transport 600 and application layer solutions. 602 6.3. Symmetric vs. Asymmetric Crypto 604 The second trade-off that is worth discussing is the use of plain 605 asymmetric cryptographic mechanisms, plain symmetric cryptographic 606 mechanisms, or some mixture thereof. 608 Contrary to popular cryptographic community beliefs, a symmetric 609 crypto solution can be deployed in large scale. In fact, the largest 610 deployment of cryptographic security, the cellular network 611 authentication system, uses SIM cards that are based on symmetric 612 secrets. In contrast, public key systems have yet to show ability to 613 scale to hundreds of millions of devices, let alone billions. But 614 the authors do not believe scaling is an important differentiator 615 when comparing the solutions. 617 As can be seen from the Section 5, the time needed to calculate some 618 of the asymmetric crypto operations with reasonable key lengths can 619 be significant. There are two contrary observations that can be made 620 from this. First, recent wisdom indicates that computing power on 621 small devices is far cheaper than transmission power [wiman], and 622 keeps on becoming more efficient very quickly. From this we can 623 conclude that the sufficient CPU is or at least will be easily 624 available. 626 But the other observation is that when there are very costly 627 asymmetric operations, doing a key exchange followed by the use of 628 generated symmetric keys would make sense. This model works very 629 well for DTLS and other transport layer solutions, but works less 630 well for data object security, particularly when the number of 631 communicating entities is not exactly two. 633 7. Security Considerations 635 This entire memo deals with security issues. 637 8. IANA Considerations 639 There are no IANA impacts in this memo. 641 9. References 643 9.1. Normative References 645 [I-D.ietf-core-coap] 646 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 647 "Constrained Application Protocol (CoAP)", 648 draft-ietf-core-coap-06 (work in progress), May 2011. 650 [arduino-uno] 651 "Arduino Uno", 652 . 654 [relic-toolkit] 655 "Relic Toolkit", 656 . 658 [avr-crypto-lib] 659 Das Labor, "AVR-CRYPTO-LIB", 660 . 662 [avr-cryptolib] 663 "AVR CRYPTOLIB", . 665 [tinyecc] North Carolina State University and North Carolina State 666 University, "TinyECC", 667 . 669 [matrix-ssl] 670 PeerSec Networks, "Matrix SSL", 671 . 673 [rsa-high-speed] 674 RSA Labs, "High-Speed RSA Implementation", 675 . 677 [rsa-8bit] 678 Sun Microsystems, "Comparing Elliptic Curve Cryptography 679 and RSA on 8-bit CPUs". 681 9.2. Informative References 683 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 684 Levkowetz, "Extensible Authentication Protocol (EAP)", 685 RFC 3748, June 2004. 687 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 688 RFC 3972, March 2005. 690 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 691 RFC 4306, December 2005. 693 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 694 Yegin, "Protocol for Carrying Authentication for Network 695 Access (PANA)", RFC 5191, May 2008. 697 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 698 "Host Identity Protocol", RFC 5201, April 2008. 700 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 701 the Datagram Congestion Control Protocol (DCCP)", 702 RFC 5238, May 2008. 704 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 705 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 707 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 708 Version 2", BCP 146, RFC 5406, February 2009. 710 [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) 711 Immediate Carriage and Conveyance of Upper-Layer Protocol 712 Signaling (HICCUPS)", RFC 6078, January 2011. 714 [I-D.arkko-core-sleepy-sensors] 715 Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. 716 Novo, "Implementing Tiny COAP Sensors", 717 draft-arkko-core-sleepy-sensors-01 (work in progress), 718 July 2011. 720 [I-D.arkko-core-security-arch] 721 Arkko, J. and A. Keranen, "CoAP Security Architecture", 722 draft-arkko-core-security-arch-00 (work in progress), 723 July 2011. 725 [I-D.daniel-6lowpan-security-analysis] 726 Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. 728 Laganier, "IPv6 over Low Power WPAN Security Analysis", 729 draft-daniel-6lowpan-security-analysis-05 (work in 730 progress), March 2011. 732 [I-D.garcia-core-security] 733 Garcia-Morchon, O., Keoh, S., Kumar, S., Hummen, R., and 734 R. Struik, "Security Considerations in the IP-based 735 Internet of Things", draft-garcia-core-security-03 (work 736 in progress), October 2011. 738 [I-D.iab-smart-object-workshop] 739 Tschofenig, H. and J. Arkko, "Report from the 740 'Interconnecting Smart Objects with the Internet' 741 Workshop, 25th March 2011, Prague", 742 draft-iab-smart-object-workshop-10 (work in progress), 743 January 2012. 745 [I-D.ietf-hip-rfc5201-bis] 746 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 747 "Host Identity Protocol Version 2 (HIPv2)", 748 draft-ietf-hip-rfc5201-bis-07 (work in progress), 749 October 2011. 751 [I-D.kivinen-ipsecme-ikev2-minimal] 752 Kivinen, T., "Minimal IKEv2", 753 draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress), 754 February 2011. 756 [I-D.moskowitz-hip-rg-dex] 757 Moskowitz, R., "HIP Diet EXchange (DEX)", 758 draft-moskowitz-hip-rg-dex-05 (work in progress), 759 March 2011. 761 [Withings] 762 Withings, "The Withings scale", February 2012, 763 . 765 [wiman] "Impact of Operating Systems on Wireless Sensor Networks 766 (Security) Applications and Testbeds. In International 767 Conference on Computer Communication Networks (ICCCN'2010) 768 / IEEE International Workshop on Wireless Mesh and Ad Hoc 769 Networks (WiMAN 2010), 2010, Zuerich. Proceedings of 770 ICCCN'2010/WiMAN'2010", 2010. 772 Appendix A. Acknowledgments 774 The authors would like to thank Mats Naslund, Salvatore Loreto, Bob 775 Moskowitz, Oscar Novo, Heidi-Maria Rissanen, Vlasios Tsiatsis, Eric 776 Rescorla and Tero Kivinen for interesting discussions in this problem 777 space. 779 Authors' Addresses 781 Jari Arkko 782 Ericsson 783 Jorvas 02420 784 Finland 786 Email: jari.arkko@piuha.net 788 Ari Keranen 789 Ericsson 790 Jorvas 02420 791 Finland 793 Email: ari.keranen@ericsson.com 795 Mohit Sethi 796 Ericsson 797 Jorvas 02420 798 Finland 800 Email: mohit.m.sethi@ericsson.com