idnits 2.17.1 draft-aks-crypto-sensors-02.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 17 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2012) is 4412 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-02 == Outdated reference: A later version (-10) exists of draft-iab-smart-object-workshop-01 == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc5201-bis-06 == 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 == Outdated reference: A later version (-01) exists of draft-vial-core-mirror-proxy-00 == Outdated reference: A later version (-05) exists of draft-shelby-core-resource-directory-00 == Outdated reference: A later version (-41) exists of draft-ietf-jose-json-web-signature-01 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-11 == Outdated reference: A later version (-10) exists of draft-jennings-senml-05 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Sethi 3 Internet-Draft Aalto / Ericsson Research 4 Intended status: Informational J. Arkko 5 Expires: September 27, 2012 A. Keranen 6 H. Rissanen 7 Ericsson 8 March 27, 2012 10 Practical Considerations and Implementation Experiences in Securing 11 Smart Object Networks 12 draft-aks-crypto-sensors-02 14 Abstract 16 This memo describes challenges associated with securing smart object 17 devices in constrained implementations and environments. The memo 18 describes a possible deployment model suitable for these 19 environments, discusses the availability of cryptographic libraries 20 for small devices, presents some preliminary experiences in 21 implementing small devices using those libraries, and discusses 22 trade-offs involving different types of approaches. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 20, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5 62 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.2. Protocol Architecture . . . . . . . . . . . . . . . . . . 7 64 4. Code Availability . . . . . . . . . . . . . . . . . . . . . . 8 65 5. Implementation Experiences . . . . . . . . . . . . . . . . . . 10 66 6. Example Application . . . . . . . . . . . . . . . . . . . . . 15 67 7. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 16 68 7.1. Feasibility . . . . . . . . . . . . . . . . . . . . . . . 17 69 7.2. Layering . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 7.3. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . 19 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 76 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 24 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 79 1. Introduction 81 This memo describes challenges associated with securing smart object 82 devices in constrained implementations and environments (see 83 Section 2). 85 Secondly, Section 3 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 4 discusses the availability of cryptographic 91 libraries. Section 5 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 7 discusses trade-offs involving different types of 96 security approaches. 98 1.1. Related Work 100 Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a 101 light-weight protocol designed to be used in machine-to-machine 102 applications such as smart energy and building automation. Our 103 discussion uses this protocol as an example, but the conclusions may 104 apply to other similar protocols. CoAP base specification 105 [I-D.ietf-core-coap] outlines how to use DTLS [RFC5238] and IPsec 106 [RFC4306] for securing the protocol. DTLS can be applied with group 107 keys, pairwise shared keys, or with certificates. The security model 108 in all cases is mutual authentication, so while there is some 109 commonality to HTTP in verifying the server identity, in practice the 110 models are quite different. The specification says little about how 111 DTLS keys are managed. The IPsec mode is described with regards to 112 the protocol requirements, noting that small implementations of IKEv2 113 exist [I-D.kivinen-ipsecme-ikev2-minimal]. However, the 114 specification is silent on policy and other aspects that are normally 115 necessary in order to implement interoperable use of IPsec in any 116 environment [RFC5406]. 118 [I-D.iab-smart-object-workshop] gives an overview of the security 119 discussions at the March 2011 IAB workshop on smart objects. The 120 workshop recommended that additional work is needed in developing 121 suitable credential management mechanisms (perhaps something similar 122 to the Bluetooth pairing mechanism), understanding the 123 implementability of standard security mechanisms in small devices and 124 additional research in the area of lightweight cryptographic 125 primitives. 127 [I-D.moskowitz-hip-rg-dex] defines a light-weight version of the HIP 128 protocol for low-power nodes. This version uses a fixed set of 129 algorithms, Elliptic Curve Cryptography (ECC), and eliminates hash 130 functions. The protocol still operates based on host identities, and 131 runs end-to-end between hosts, protecting IP layer communications. 132 [RFC6078] describes an extension of HIP that can be used to send 133 upper layer protocol messages without running the usual HIP base 134 exchange at all. 136 [I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis 137 of security issues related to 6LoWPAN networks, but its findings also 138 apply more generally for all low-powered networks. Some of the 139 issues this document discusses include the need to minimize the 140 number of transmitted bits and simplify implementations, threats in 141 the smart object networking environments, and the suitability of 142 6LoWPAN security mechanisms, IPsec, and key management protocols for 143 implementation in these environments. 145 [I-D.garcia-core-security] discusses the overall security problem for 146 Internet of Things devices. It also discusses various solutions, 147 including IKEv2/IPsec [RFC4306], TLS/SSL [RFC5246], DTLS [RFC5238], 148 HIP [RFC5201] [I-D.ietf-hip-rfc5201-bis] [I-D.moskowitz-hip-rg-dex], 149 PANA [RFC5191], and EAP [RFC3748]. The draft also discusses various 150 operational scenarios, bootstrapping mechanisms, and challenges 151 associated with implementing security mechanisms in these 152 environments. 154 2. Challenges 156 This section discusses three challenges: implementation difficulties, 157 practical provisioning problems, and layering and communication 158 models. 160 The most often discussed issues in the security for the Internet of 161 Things relate to implementation difficulties. The desire to build 162 small, battery-operated, and inexpensive devices drives the creation 163 of devices with a limited protocol and application suite. Some of 164 the typical limitations include running CoAP instead of HTTP, limited 165 support for security mechanisms, limited processing power for long 166 key lengths, sleep schedule that does not allow communication at all 167 times, and so on. In addition, the devices typically have very 168 limited support for configuration, making it hard to set up secrets 169 and trust anchors. 171 The implementation difficulties are important, but they should not be 172 overemphasized. It is important to select the right security 173 mechanisms and avoid duplicated or unnecessary functionality. But at 174 the end of the day, if strong cryptographic security is needed, the 175 implementations have to support that. Also, the use of the most 176 lightweight algorithms and cryptographic primitives is useful, but 177 should not be the only consideration in the design. Interoperability 178 is also important, and often other parts of the system, such as key 179 management protocols or certificate formats are heavier to implement 180 than the algorithms themselves. 182 The second challenge relates to practical provisioning problems. 183 These are perhaps the most fundamental and difficult issue, and 184 unfortunately often neglected in the design. There are several 185 problems in the provisioning and management of smart object networks: 187 o Small devices have no natural user interface for configuration 188 that would be required for the installation of shared secrets and 189 other security-related parameters. Typically, there is no 190 keyboard, no display, and there may not even be buttons to press. 191 Some devices may only have one interface, the interface to the 192 network. 194 o Manual configuration is rarely, if at all, possible, as the 195 necessary skills are missing in typical installation environments 196 (such as in family homes). 198 o There may be a large number of devices. Configuration tasks that 199 may be acceptable when performed for one device may become 200 unacceptable with dozens or hundreds of devices. 202 o Network configurations evolve over the lifetime of the devices, as 203 additional devices are introduced or addresses change. Various 204 central nodes may also receive more frequent updates than 205 individual devices such as sensors embedded in building materials. 207 Finally, layering and communication models present difficulties for 208 straightforward use of the most obvious security mechanisms. Smart 209 object networks typically pass information through multiple 210 participating nodes [I-D.arkko-core-sleepy-sensors] and end-to-end 211 security for IP or transport layers may not fit such communication 212 models very well. The primary reasons for needing middleboxes 213 relates to the need to accommodate for sleeping nodes as well to 214 enable the implementation of nodes that store or aggregate 215 information. 217 3. Proposed Deployment Model 219 [I-D.arkko-core-security-arch] recognizes the provisioning model as 220 the driver of what kind of security architecture is useful. This 221 section re-introduces this model briefly here in order to facilitate 222 the discussion of the various design alternatives later. 224 The basis of the proposed architecture are self-generated secure 225 identities, similar to Cryptographically Generated Addresses (CGAs) 226 [RFC3972] or Host Identity Tags (HITs) [RFC5201]. That is, we assume 227 the following holds: 229 I = h(P|O) 231 where I is the secure identity of the device, h is a hash function, P 232 is the public key from a key pair generated by the device, and O is 233 optional other information. 235 3.1. Provisioning 237 As provisioning security credentials, shared secrets, and policy 238 information is difficult, the provisioning model is based only on the 239 secure identities. A typical network installation involves physical 240 placement of a number of devices while noting the identities of these 241 devices. This list of short identifiers can then be fed to a central 242 server as a list of authorized devices. Secure communications can 243 then commence with the devices, at least as far as information from 244 from the devices to the server is concerned, which is what is needed 245 for sensor networks. Actuator networks and server-to-device 246 communication is covered in Section 4.4 of 247 [I-D.arkko-core-security-arch]. 249 Where necessary, the information collected at installation time may 250 also include other parameters relevant to the application, such as 251 the location or purpose of the devices. This would enable the server 252 to know, for instance, that a particular device is the temperature 253 sensor for the kitchen. 255 Collecting the identity information at installation time can be 256 arranged in a number of ways. The authors have employed a simple but 257 not completely secure method where the last few digits of the 258 identity are printed on a tiny device just a few millimeters across. 259 Alternatively, the packaging for the device may include the full 260 identity (typically 32 hex digits), retrieved from the device at 261 manufacturing time. This identity can be read, for instance, by a 262 bar code reader carried by the installation personnel. (Note that 263 the identities are not secret, the security of the system is not 264 dependent on the identity information leaking to others. The real 265 owner of an identity can always prove its ownership with the private 266 key which never leaves the device.) Finally, the device may use its 267 wired network interface or proximity-based communications, such as 268 Near-Field Communications (NFC) or Radio-Frequency Identity tags 269 (RFIDs). Such interfaces allow secure communication of the device 270 identity to an information gathering device at installation time. 272 No matter what the method of information collection is, this 273 provisioning model minimizes the effort required to set up the 274 security. Each device generates its own identity in a random, secure 275 key generation process. The identities are self-securing in the 276 sense that if you know the identity of the peer you want to 277 communicate with, messages from the peer can be signed by the peer's 278 private key and it is trivial to verify that the message came from 279 the expected peer. There is no need to configure an identity and 280 certificate of that identity separately. There is no need to 281 configure a group secret or a shared secret. There is no need to 282 configure a trust anchor. In addition, the identities are typically 283 collected anyway for application purposes (such as identifying which 284 sensor is in which room). Under most circumstances there is actually 285 no additional configuration effort from provisioning security. 287 Groups of devices can be managed through single identifiers as well. 288 See Section 4.2 in [I-D.arkko-core-security-arch] for further 289 information. 291 3.2. Protocol Architecture 293 As noted above, the starting point of the architecture is that nodes 294 self-generate secure identities which are then communicated out-of- 295 band to the peers that need to know what devices to trust. To 296 support this model in a protocol architecture, we also need to use 297 these secure identities to implement secure messaging between the 298 peers, explain how the system can respond to different types of 299 attacks such as replay attempts, and decide at what protocol layer 300 and endpoints the architecture should use. 302 The deployment itself is suitable for a variety of design choices 303 regarding layering and protocol mechanisms. 304 [I-D.arkko-core-security-arch] was mostly focused on employing end- 305 to-end data object security as opposed to hop-by-hop security. But 306 other approaches are possible. For instance, HIP in its 307 opportunistic mode could be used to implement largely the same 308 functionality at the IP layer. However, it is our belief that the 309 right layer for this solution is at the application layer. More 310 specifically, in the data formats transported in the payload part of 311 CoAP. This approach provides the following benefits: 313 o Ability for intermediaries to act as caches to support different 314 sleep schedules, without the security model being impacted. 316 o Ability for intermediaries to be built to perform aggregation, 317 filtering, storage and other actions, again without impacting the 318 security of the data being transmitted or stored. 320 o Ability to operate in the presence of traditional middleboxes, 321 such as a protocol translators or even NATs (not that we recommend 322 their use in these environments). 324 However, as we will see later there are also some technical 325 implications, namely that link, network, and transport layer 326 solutions are more likely to be able to benefit from sessions where 327 the cost of expensive operations can be amortized over multiple data 328 transmissions. While this is not impossible in data object security 329 solutions either, it is not the typical arrangement either. 331 4. Code Availability 333 For implementing public key cryptography on resource constrained 334 environments, we chose Arduino Uno board [arduino-uno] as the test 335 platform. Arduino Uno has an ATmega328 microcontroller, an 8-bit 336 processor with a clock speed of 16 MHz, 2 kB of SRAM, and 32 kB of 337 flash memory. 339 For selecting potential asymmetric cryptographic libraries, we did an 340 extensive survey and came up with a set of possible code sources, and 341 performed an initial analysis of how well they fit the Arduino 342 environment. Note that the results are preliminary, and could easily 343 be affected in any direction by implementation bugs, configuration 344 errors, and other mistakes. Please verify the numbers before relying 345 on them for building something. No significant effort was done to 346 optimize ROM memory usage beyond what the libraries provided 347 themselves, so those numbers should be taken as upper limits. 349 Here is the set of libraries we found: 351 o AvrCryptolib [avr-cryptolib]: This library provides a variety of 352 different symmetric key algorithms such as DES/Triple DES/AES etc. 353 and RSA as an asymmetric key algorithm. We stripped down the 354 library to use only the required RSA components and used a 355 separate SHA-256 implementation from the original AvrCrypto-Lib 356 library [avr-crypto-lib]. Parts of SHA-256 and RSA algorithm 357 implementations were written in AVR-8 bit assembly language to 358 reduce the size and optimize the performance. The library also 359 takes advantage of the fact that Arduino boards allow the 360 programmer to directly address the flash memory to access constant 361 data which can save the amount of SRAM used during execution. 363 o Relic-Toolkit [relic-toolkit]: This library is written entirely in 364 C and provides a highly flexible and customizable implementation 365 of a large variety of cryptographic algorithms. This not only 366 includes RSA and ECC, but also pairing based asymmetric 367 cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures 368 and many more. The toolkit provides an option to build only the 369 desired components for the required platform. While building the 370 library, it is possible to select a variety mathematical 371 optimizations that can be combined to obtain the desired 372 performance (as a general thumb rule, faster implementations 373 require more SRAM and flash). It includes a multi precision 374 integer math module which can be customized to use different bit- 375 length words. 377 o TinyECC [tinyecc]: TinyECC was designed for using Elliptic Curve 378 based public key cryptography on sensor networks. It is written 379 in nesC programming language and as such is designed for specific 380 use on TinyOS. However, the library can be ported to standard C99 381 either with hacked tool-chains or manually rewriting parts of the 382 code. This allows for the library to be used on platforms that do 383 not have TinyOS running on them. The library includes a wide 384 variety of mathematical optimizations such as sliding window, 385 Barrett reduction for verification, precomputation, etc. It also 386 has one of the smallest memory footprints among the set of 387 Elliptic Curve libraries surveyed so far. However, an advantage 388 of Relic over TinyECC is that it can do curves over binary fields 389 in addition to prime fields. 391 o Wiselib [wiselib]: Wiselib is a generic library written for sensor 392 networks containing a wide variety of algorithms. While the 393 stable version contains algorithms for routing only, the test 394 version includes many more algorithms including algorithms for 395 cryptography, localization , topology management and many more. 396 The library was designed with the idea of making it easy to 397 interface the library with operating systems like iSense and 398 Contiki. However, since the library is written entirely in C++ 399 with a template based model similar to Boost/CGAL, it can be used 400 on any platform directly without using any of the operating system 401 interfaces provided. This approach was taken by the authors to 402 test the code on Arduino Uno. The structure of the code is similar 403 to TinyECC and like TinyECC it implements elliptic curves over 404 prime fields only. In order to make the code platform 405 independent, no assembly level optimizations were incorporated. 406 Since efficiency was not an important goal for the authors of the 407 library while designing, many well known theoretical performance 408 enhancement features were also not incorporated. Like the relic- 409 toolkit, Wiselib is also Lesser GPL licensed. 411 o MatrixSSL [matrix-ssl]: This library provides a low footprint 412 implementation of several cryptographic algorithms including RSA 413 and ECC (with a commercial license). However, the library in the 414 original form takes about 50 kB of ROM which is not suitable for 415 our hardware requirements. Moreover, it is intended for 32-bit 416 systems and the API includes functions for SSL communication 417 rather than just signing data with private keys. 419 5. Implementation Experiences 421 We have summarized the initial results of RSA private key performance 422 using AvrCryptolib in Table 1. All results are from a single run 423 since repeating the test did not change (or had only minimal impact 424 on) the results. The keys were generated separately and were hard 425 coded into the program. All keys were generated with the value of 426 the public exponent as 3. The performance of encryption with private 427 key was faster for smaller key lengths as was expected. However the 428 increase in the execution time was considerable when the key size was 429 2048 bits. It is important to note that two different sets of 430 experiments were performed for each key length. In the first case, 431 the keys were loaded into the SRAM from the ROM (flash) before they 432 were used by any of the functions. However, in the second case, the 433 keys were addressed directly in the ROM. As was expected, the second 434 case used less SRAM but lead to longer execution time. 436 +--------+--------------+--------------+-------------+--------------+ 437 | Key | Execution | Memory | Execution | Memory | 438 | length | time (ms); | footprint | time (ms); | footprint | 439 | (bits) | key in SRAM | (bytes); key | key in ROM | (bytes); key | 440 | | | in SRAM | | in ROM | 441 +--------+--------------+--------------+-------------+--------------+ 442 | 64 | 66 | 40 | 70 | 32 | 443 | 128 | 124 | 80 | 459 | 64 | 444 | 512 | 25,089 | 320 | 27,348 | 256 | 445 | 1,024 | 199,666 | 640 | 218,367 | 512 | 446 | 2,048 | 1,587,559 | 1,280 | 1,740,267 | 1,024 | 447 +--------+--------------+--------------+-------------+--------------+ 449 RSA private key operation performance 451 Table 1 453 The code size was less than 3.6 kB for all the test cases with scope 454 for further reduction. It is also worth noting that the 455 implementation performs basic exponentiation and multiplication 456 operations without using any mathematical optimizations such as 457 Montgomery multiplication, optimized squaring, etc. as described in 459 [rsa-high-speed]. With more SRAM, we believe that 1024/2048-bit 460 operations can be performed in much less time as has been shown in 461 [rsa-8bit]. 2048-bit RSA is nonetheless possible with about 1 kB of 462 SRAM as is seen in Table 1. 464 In Table 2 we present the results obtained by manually porting 465 TinyECC into C99 standard and running ECDSA signature algorithm on 466 the Arduino Uno board. TinyECC supports a variety of SEC 2 467 recommended Elliptic Curve domain parameters. The execution time and 468 memory footprint are shown next to each of the curve parameters. 469 SHA-1 hashing algorithm included in the library was used in each of 470 the cases. It is clearly observable that for similar security 471 levels, Elliptic Curve public key cryptography outperforms RSA. 472 These results were obtained by turning on all the optimizations. 473 These optimizations include - Curve Specific Optimizations for 474 modular reduction (NIST and SEC 2 field primes were chosen as pseudo- 475 Mersenne primes), Sliding Window for faster scalar multiplication, 476 Hybrid squaring procedure written in assembly and Weighted projective 477 Co-ordinate system for efficient scalar point addition, doubling and 478 multiplication. We did not use optimizations like Shamir Trick and 479 Sliding Window as they are only useful for signature verification and 480 tend to slow down the signature generation by precomputing values (we 481 were only interested in fast signature generation). There is still 482 some scope for optimization as not all the assembly code provided 483 with the library could be ported to Arduino directly. Re-writing 484 these procedures in compatible assembly would further enhance the 485 performance. 487 +-------------+---------------+-----------------+-------------------+ 488 | Curve | Execution | Memory | Comparable RSA | 489 | parameters | time (ms) | Footprint | key length | 490 | | | (bytes) | | 491 +-------------+---------------+-----------------+-------------------+ 492 | 128r1 | 1,858 | 776 | 704 | 493 | 128r2 | 2,002 | 776 | 704 | 494 | 160k1 | 2,228 | 892 | 1,024 | 495 | 160r1 | 2,250 | 892 | 1,024 | 496 | 160r2 | 2,467 | 892 | 1,024 | 497 | 192k1 | 3,425 | 1008 | 1,536 | 498 | 192r1 | 3,578 | 1008 | 1,536 | 499 +-------------+---------------+-----------------+-------------------+ 501 ECDSA signature performance with TinyECC 503 Table 2 505 We also performed experiments by removing the assembly code for 506 hybrid multiplication and squaring thus using a C only form of the 507 library. This gives us an idea of the performance that can be 508 achieved with TinyECC on any platform regardless of what kind of OS 509 and assembly instruction set available. The memory footprint remains 510 the same with our without assembly code. The tables contain the 511 maximum RAM that is used when all the possible optimizations are on. 512 If however, the amount of RAM available is smaller in size, some of 513 the optimizations can be turned off to reduce the memory consumption 514 accordingly. 516 +-------------+---------------+-----------------+-------------------+ 517 | Curve | Execution | Memory | Comparable RSA | 518 | parameters | time (ms) | Footprint | key length | 519 | | | (bytes) | | 520 +-------------+---------------+-----------------+-------------------+ 521 | 128r1 | 2,741 | 776 | 704 | 522 | 128r2 | 3,086 | 776 | 704 | 523 | 160k1 | 3,795 | 892 | 1,024 | 524 | 160r1 | 3,841 | 892 | 1,024 | 525 | 160r2 | 4,118 | 892 | 1,024 | 526 | 192k1 | 6,091 | 1008 | 1,536 | 527 | 192r1 | 6,217 | 1008 | 1,536 | 528 +-------------+---------------+-----------------+-------------------+ 530 ECDSA signature performance with TinyECC (No assembly optimizations) 532 Table 3 534 Table 4 documents the performance of Wiselib. Since there were no 535 optimizations that could be turned on or off, we have only one set of 536 results. By default Wiselib only supports some of the standard SEC 2 537 Elliptic curves. But it is easy to change the domain parameters and 538 obtain results for for all the 128, 160 and 192-bit SEC 2 Elliptic 539 curves. SHA-1 algorithm provided in the library was used. The ROM 540 size for all the experiments was less than 16 kB. 542 +-------------+---------------+-----------------+-------------------+ 543 | Curve | Execution | Memory | Comparable RSA | 544 | parameters | time (ms) | Footprint | key length | 545 | | | (bytes) | | 546 +-------------+---------------+-----------------+-------------------+ 547 | 128r1 | 10,744 | 732 | 704 | 548 | 128r2 | 10,615 | 732 | 704 | 549 | 160k1 | 20,164 | 842 | 1,024 | 550 | 160r1 | 20,231 | 842 | 1,024 | 551 | 160r2 | 20,231 | 842 | 1,024 | 552 | 192k1 | 34,486 | 952 | 1,536 | 553 | 192r1 | 34,558 | 952 | 1,536 | 554 +-------------+---------------+-----------------+-------------------+ 556 ECDSA signature performance with Wiselib 558 Table 4 560 For testing the relic-toolkit we used a different board because it 561 required more RAM/ROM and we were unable to perform experiments with 562 it on Arduino Uno. We decided to use the Arduino Mega which has the 563 same 8-bit architecture like the Arduino Uno but has a much larger 564 RAM/ROM for testing relic-toolkit. The relic-toolkit supports curves 565 over prime as well as binary fields. Since it is shown in 566 [binary-prime] that Kolobitz curves perform better over binary fields 567 than prime fields, we have experimented with curves over binary 568 fields only. We leave the comparison of ordinary curves over prime 569 and binary fields on 8-bit platforms as future work. The results 570 from relic-toolkit are documented in two separate tables shown in 571 Table 5 and Table 6. The first set of results were performed with 572 the library configured for high speed performance with no 573 consideration given to the amount of memory used. For the second 574 set, the library was configured for low memory usage irrespective of 575 the execution time required by different curves. By turning on/off 576 optimizations included in the library, a trade-off between memory and 577 execution time between these values can be achieved. 579 +-----------------+--------------+----------------+-----------------+ 580 | Curve | Execution | Memory | Comparable RSA | 581 | parameters | time (ms) | Footprint | key length | 582 | | | (bytes) | | 583 +-----------------+--------------+----------------+-----------------+ 584 | NIST K163 | 300 | 2,804 | 1024 | 585 | (assembly math) | | | | 586 | NIST K163 | 966 | 2,750 | 1024 | 587 | NIST B163 | 2,408 | 2,444 | 1024 | 588 | NIST K233 | 1,828 | 3,675 | 2,048 | 589 | NIST B233 | 4,834 | 3,261 | 2,048 | 590 +-----------------+--------------+----------------+-----------------+ 592 ECDSA signature performance with relic-toolkit (Fast) 594 Table 5 596 +-----------------+--------------+----------------+-----------------+ 597 | Curve | Execution | Memory | Comparable RSA | 598 | parameters | time (ms) | Footprint | key length | 599 | | | (bytes) | | 600 +-----------------+--------------+----------------+-----------------+ 601 | NIST K163 | 1,128 | 2,087 | 1024 | 602 | (assembly math) | | | | 603 | NIST K163 | 3,178 | 2,215 | 1024 | 604 | NIST B163 | 3,464 | 2,071 | 1024 | 605 | NIST K233 | 6,995 | 2,935 | 2,048 | 606 | NIST B233 | 6,535 | 2,737 | 2,048 | 607 +-----------------+--------------+----------------+-----------------+ 609 ECDSA signature performance with relic-toolkit (Low Memory) 611 Table 6 613 It is important to note the following points about the elliptic curve 614 measurements: 616 o The arduino board only provides pseudo random numbers with the 617 random() function call. In order to create private keys with a 618 better quality of random number, we can use a true random number 619 generator like the one provided by TrueRandom library 620 [truerandom], or create the keys separately on a system with a 621 true random number generator and then use them directly in the 622 code. 624 o For measuring the memory footprint of all the ECC libraries, we 625 used the Avrora simulator [avrora]. Only stack memory was used to 626 easily track the RAM consumption. 628 A summary library ROM use is shown in Table 7. 630 +---------------+---------------------------+ 631 | Library | ROM Footprint (Kilobytes) | 632 +---------------+---------------------------+ 633 | AvrCryptolib | 3.6 | 634 | Wiselib | 16 | 635 | TinyECC | 18 | 636 | Relic-toolkit | 29 | 637 +---------------+---------------------------+ 639 Summary of library ROM needs 641 Table 7 643 6. Example Application 645 We developed an example application on the Arduino platform to use 646 public key crypto mechanisms, data object security, and an easy 647 provisioning model. Our application was originally developed to test 648 different approaches to supporting communications to "always off" 649 sensor nodes. These battery-operated or energy scavenging nodes do 650 not have enough power to be stay on at all times. They wake up 651 periodically and transmit their readings. 653 Such sensor nodes can be supported in various ways. 654 [I-D.arkko-core-sleepy-sensors] was an early multicast-based 655 approach. In the current application we have switched to using 656 resource directories [I-D.shelby-core-resource-directory] and mirror 657 proxies [I-D.vial-core-mirror-proxy] instead. Architecturally, the 658 idea is that sensors can delegate a part of their role to a node in 659 the network. Such a network node could be either a local resource or 660 something in the Internet. In the case of CoAP mirror proxies, the 661 network node agress to hold the web resources on behalf of the 662 sensor, while the sensor is asleep. The only role that the sensor 663 has is to register itself at the mirror proxy, and periodically 664 update the readings. All queries from the rest of the world go to 665 the mirror proxy. 667 We constructed a system with four entities: 669 Sensor 671 This is an Arduino-based device that runs a CoAP mirror proxy 672 client and Relic-toolkit. Relic takes 29 Kbytes of ROM, and the 673 simple CoAP client roughly 3 kilobytes. 675 Mirror Proxy 677 This is a mirror proxy that holds resources on the sensor's 678 behalf. The sensor registers itself to this node. 680 Resource Directory 682 While physically in the same node in our implementation, a 683 resource directory is a logical function that allows sensors and 684 mirror proxies to register resources in the directory. These 685 resources can be queried by applications. 687 Application 689 This is a simple application that runs on a general purpose 690 computer and can retrieve both registrations from the resource 691 directory and most recent sensor readings from the mirror proxy. 693 The security of this system relies on an SSH-like approach. In Step 694 1, upon first boot, sensors generate keys and register themselves in 695 the mirror proxy. Their public key is submitted along with the 696 registration as an attribute in the CORE Link Format data 697 [I-D.ietf-core-link-format]. 699 In Step 2, when the sensor makes a sensor reading update to the 700 mirror proxy it signs the message contents with a JOSE signature on 701 the used JSON/SENML payload [I-D.ietf-jose-json-web-signature] 702 [I-D.jennings-senml]. 704 In Step 3, any other device in the network -- including the mirror 705 proxy, resource directory and the application -- can check that the 706 public key from the registration corresponds to the private key used 707 to make the signature in the data update. 709 Note that checks can be done at any time and there is no need for the 710 sensor and the checking node to be awake at the same time. In our 711 implementation, the checking is done in the application node. This 712 demonstrates how it is possible to implement end-to-end security even 713 with the presence of assisting middleboxes. 715 7. Design Trade-Offs 717 This section attempts to make some early conclusions regarding trade- 718 offs in the design space, based on deployment considerations for 719 various mechanisms and the relative ease or difficulty of 720 implementing them. This analysis looks at layering and the choice of 721 symmetric vs. asymmetric cryptography. 723 7.1. Feasibility 725 The first question is whether using cryptographic security and 726 asymmetric cryptography in particular is feasible at all on small 727 devices. The numbers above give a mixed message. Clearly, an 728 implementation of a significant cryptographic operation such as 729 public key signing can be done in surprisingly small amount of code 730 space. It could even be argued that our chosen prototype platform 731 was unnecessarily restrictive in the amount of code space it allows: 732 we chose this platform on purpose to demonstrate something that is as 733 small and difficult as possible. 735 In reality, ROM memory size is probably easier to grow than other 736 parameters in microcontrollers. A recent trend in microcontrollers 737 is the introduction of 32-bit CPUs that are becoming cheaper and more 738 easily available than 8-bit CPUs, in addition to being more easily 739 programmable. In short, the authors do not expect the code size to 740 be a significant limiting factor, both because of the small amount of 741 code that is needed and because available memory space is growing 742 rapidly. 744 The situation is less clear with regards to the amount of CPU power 745 needed to run the algorithms. The demonstrated speeds are sufficient 746 for many applications. For instance, a sensor that wakes up every 747 now and then can likely spend a fraction of a second for the 748 computation of a signature for the message that it is about to send. 749 Or even spend multiple seconds in some cases. Most applications that 750 use protocols such as DTLS that use public key cryptography only at 751 the beginning of the session would also be fine with any of these 752 execution times. 754 Yet, with reasonably long key sizes the execution times are in the 755 seconds, dozens of seconds, or even longer. For some applications 756 this is too long. Nevertheless, the authors believe that these 757 algorithms can successfully be employed in small devices for the 758 following reasons: 760 o With the right selection of algorithms and libraries, the 761 execution times can actually be smaller. Using the Relic-toolkit 762 with the NIST K163 algorithm (roughly equivalent to RSA at 1024 763 bits) at 0.3 seconds is a good example of this. 765 o As discussed in [wiman], in general the power requirements 766 necessary to send or receive messages are far bigger than those 767 needed to execute cryptographic operations. There is no good 768 reason to choose platforms that do not provide sufficient 769 computing power to run the necessary operations. 771 o Commercial libraries and the use of full potential for various 772 optimizations will provide a better result than what we arrived at 773 in this paper. 775 o Using public key cryptography only at the beginning of a session 776 will reduce the per-packet processing times significantly. 778 7.2. Layering 780 It would be useful to select just one layer where security is 781 provided at. Otherwise a simple device needs to implement multiple 782 security mechanisms. While some code can probably be shared across 783 such implementations (like algorithms), it is likely that most of the 784 code involving the actual protocol machinery cannot. Looking at the 785 different layers, here are the choices and their implications: 787 link layer 789 This is probably the most common solution today. The biggest 790 benefits of this choice of layer are that security services are 791 commonly available (WLAN secrets, cellular SIM cards, etc.) and 792 that their application protects the entire communications. 794 The main drawback is that there is no security beyond the first 795 hop. This can be problematic, e.g., in many devices that 796 communicate to a server in the Internet. A Withings scale 797 [Withings], for instance, can support WLAN security but without 798 some level of end-to-end security, it would be difficult to 799 prevent fraudulent data submissions to the servers. 801 Another drawback is that some commonly implemented link layer 802 security designs use group secrets. This allows any device within 803 the local network (e.g., an infected laptop) to attack the 804 communications. 806 network layer 808 There are a number of solutions in this space, and many new ones 809 and variations thereof being proposed: IPsec, PANA, and so on. In 810 general, these solutions have similar characteristics to those in 811 the transport layer: they work across forwarding hops but only as 812 far as to the next middlebox or application entity. There is 813 plenty of existing solutions and designs. 815 Experience has shown that it is difficult to control IP layer 816 entities from an application process. While this is theoretically 817 easy, in practice the necessary APIs do not exist. For instance, 818 most IPsec software has been built for the VPN use case, and is 819 difficult or impossible to tweak to be used on a per-application 820 basis. As a result, the authors are not particularly enthusiastic 821 about recommending these solutions. 823 transport and application layer 825 This is another popular solution along with link layer designs. 826 SSL, TLS, DTLS, and HTTPS are examples of solutions in this space, 827 and have been proven to work well. These solutions are typically 828 easy to take into use in an application, without assuming anything 829 from the underlying OS, and they are easy to control as needed by 830 the applications. The main drawback is that generally speaking, 831 these solutions only run as far as the next application level 832 entity. And even for this case, HTTPS can be made to work through 833 proxies, so this limit is not unsolvable. Another drawback is 834 that attacks on link layer, network layer and in some cases, 835 transport layer, can not be protected against. However, if the 836 upper layers have been protected, such attacks can at most result 837 in a denial-of-service. Since denial-of-service can often be 838 caused anyway, it is not clear if this is a real drawback. 840 data object layer 842 This solution does not protect any of the protocol layers, but 843 protects individual data elements being sent. It works 844 particularly well when there are multiple application layer 845 entities on the path of the data. The authors believe smart 846 object networks are likely to employ such entities for storage, 847 filtering, aggregation and other reasons, and as such, an end-to- 848 end solution is the only one that can protect the actual data. 850 The downside is that the lower layers are not protected. But 851 again, as long as the data is protected and checked upon every 852 time it passes through an application level entity, it is not 853 clear that there are attacks beyond denial-of-service. 855 The main question mark is whether this type of a solution provides 856 sufficient advantages over the more commonly implemented transport 857 and application layer solutions. 859 7.3. Symmetric vs. Asymmetric Crypto 861 The second trade-off that is worth discussing is the use of plain 862 asymmetric cryptographic mechanisms, plain symmetric cryptographic 863 mechanisms, or some mixture thereof. 865 Contrary to popular cryptographic community beliefs, a symmetric 866 crypto solution can be deployed in large scale. In fact, the largest 867 deployment of cryptographic security, the cellular network 868 authentication system, uses SIM cards that are based on symmetric 869 secrets. In contrast, public key systems have yet to show ability to 870 scale to hundreds of millions of devices, let alone billions. But 871 the authors do not believe scaling is an important differentiator 872 when comparing the solutions. 874 As can be seen from the Section 5, the time needed to calculate some 875 of the asymmetric crypto operations with reasonable key lengths can 876 be significant. There are two contrary observations that can be made 877 from this. First, recent wisdom indicates that computing power on 878 small devices is far cheaper than transmission power [wiman], and 879 keeps on becoming more efficient very quickly. From this we can 880 conclude that the sufficient CPU is or at least will be easily 881 available. 883 But the other observation is that when there are very costly 884 asymmetric operations, doing a key exchange followed by the use of 885 generated symmetric keys would make sense. This model works very 886 well for DTLS and other transport layer solutions, but works less 887 well for data object security, particularly when the number of 888 communicating entities is not exactly two. 890 8. Security Considerations 892 This entire memo deals with security issues. 894 9. IANA Considerations 896 There are no IANA impacts in this memo. 898 10. References 900 10.1. Normative References 902 [I-D.ietf-core-coap] 903 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 904 "Constrained Application Protocol (CoAP)", 905 draft-ietf-core-coap-06 (work in progress), May 2011. 907 [arduino-uno] 908 "Arduino Uno", 909 . 911 [relic-toolkit] 912 "Relic Toolkit", 913 . 915 [avr-crypto-lib] 916 "AVR-CRYPTO-LIB", 917 . 919 [avr-cryptolib] 920 "AVR CRYPTOLIB", . 922 [avrora] "AVR CRYPTOLIB", . 924 [truerandom] 925 "AVR CRYPTOLIB", 926 . 928 [wiselib] "", . 930 [tinyecc] North Carolina State University and North Carolina State 931 University, "TinyECC", 932 . 934 [matrix-ssl] 935 PeerSec Networks, "Matrix SSL", 936 . 938 [rsa-high-speed] 939 RSA Labs, "High-Speed RSA Implementation", 940 . 942 [binary-prime] 943 University of Waterloo, Auburn University, University of 944 Valle, and Certicom Research, "High-Speed RSA 945 Implementation", . 947 [rsa-8bit] 948 Sun Microsystems, "Comparing Elliptic Curve Cryptography 949 and RSA on 8-bit CPUs". 951 10.2. Informative References 953 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 954 Levkowetz, "Extensible Authentication Protocol (EAP)", 955 RFC 3748, June 2004. 957 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 958 RFC 3972, March 2005. 960 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 961 RFC 4306, December 2005. 963 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 964 Yegin, "Protocol for Carrying Authentication for Network 965 Access (PANA)", RFC 5191, May 2008. 967 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 968 "Host Identity Protocol", RFC 5201, April 2008. 970 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 971 the Datagram Congestion Control Protocol (DCCP)", 972 RFC 5238, May 2008. 974 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 975 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 977 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 978 Version 2", BCP 146, RFC 5406, February 2009. 980 [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) 981 Immediate Carriage and Conveyance of Upper-Layer Protocol 982 Signaling (HICCUPS)", RFC 6078, January 2011. 984 [I-D.arkko-core-sleepy-sensors] 985 Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. 986 Novo, "Implementing Tiny COAP Sensors", 987 draft-arkko-core-sleepy-sensors-01 (work in progress), 988 July 2011. 990 [I-D.arkko-core-security-arch] 991 Arkko, J. and A. Keranen, "CoAP Security Architecture", 992 draft-arkko-core-security-arch-00 (work in progress), 993 July 2011. 995 [I-D.daniel-6lowpan-security-analysis] 996 Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. 997 Laganier, "IPv6 over Low Power WPAN Security Analysis", 998 draft-daniel-6lowpan-security-analysis-05 (work in 999 progress), March 2011. 1001 [I-D.garcia-core-security] 1002 Garcia-Morchon, O., Keoh, S., Kumar, S., Hummen, R., and 1003 R. Struik, "Security Considerations in the IP-based 1004 Internet of Things", draft-garcia-core-security-02 (work 1005 in progress), July 2011. 1007 [I-D.iab-smart-object-workshop] 1008 Tschofenig, H. and J. Arkko, "Report from the 1009 'Interconnecting Smart Objects with the Internet' 1010 Workshop, 25th March 2011, Prague", 1011 draft-iab-smart-object-workshop-01 (work in progress), 1012 July 2011. 1014 [I-D.ietf-hip-rfc5201-bis] 1015 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 1016 "Host Identity Protocol Version 2 (HIPv2)", 1017 draft-ietf-hip-rfc5201-bis-06 (work in progress), 1018 July 2011. 1020 [I-D.kivinen-ipsecme-ikev2-minimal] 1021 Kivinen, T., "Minimal IKEv2", 1022 draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress), 1023 February 2011. 1025 [I-D.moskowitz-hip-rg-dex] 1026 Moskowitz, R., "HIP Diet EXchange (DEX)", 1027 draft-moskowitz-hip-rg-dex-05 (work in progress), 1028 March 2011. 1030 [I-D.vial-core-mirror-proxy] 1031 Vial, M., "CoRE Mirror Proxy", 1032 draft-vial-core-mirror-proxy-00 (work in progress), 1033 March 2012. 1035 [I-D.shelby-core-resource-directory] 1036 Shelby, Z. and S. Krco, "CoRE Resource Directory", 1037 draft-shelby-core-resource-directory-00 (work in 1038 progress), June 2011. 1040 [I-D.ietf-jose-json-web-signature] 1041 Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1042 Signature (JWS)", draft-ietf-jose-json-web-signature-01 1043 (work in progress), March 2012. 1045 [I-D.ietf-core-link-format] 1046 Shelby, Z., "CoRE Link Format", 1047 draft-ietf-core-link-format-11 (work in progress), 1048 January 2012. 1050 [I-D.jennings-senml] 1051 Jennings, C., "Media Type for Sensor Markup Language 1052 (SENML)", draft-jennings-senml-05 (work in progress), 1053 March 2011. 1055 [Withings] 1056 Withings, "The Withings scale", February 2012, 1057 . 1059 [wiman] "Impact of Operating Systems on Wireless Sensor Networks 1060 (Security) Applications and Testbeds. In International 1061 Conference on Computer Communication Networks (ICCCN'2010) 1062 / IEEE International Workshop on Wireless Mesh and Ad Hoc 1063 Networks (WiMAN 2010), 2010, Zuerich. Proceedings of 1064 ICCCN'2010/WiMAN'2010", 2010. 1066 Appendix A. Acknowledgments 1068 The authors would like to thank Mats Naslund, Salvatore Loreto, Bob 1069 Moskowitz, Oscar Novo, Vlasios Tsiatsis, Daoyuan Li, Muhammad Waqas, 1070 Eric Rescorla and Tero Kivinen for interesting discussions in this 1071 problem space. The authors would also like to thank Diego Aranha for 1072 helping with the relic-toolkit configurations and Tobias Baumgartner 1073 for helping with questions regarding wiselib. 1075 Authors' Addresses 1077 Mohit Sethi 1078 Aalto / Ericsson Research 1079 Ericsson: 02420 Jorvas, Finland 1080 Aalto: Tietotekniikan laitos, Tietoliikenneohjelmistot, PL 15400, 00076 Aalto, Finland 1082 Email: mohit.sethi@aalto.fi / mohit.m.sethi@ericsson.com 1084 Jari Arkko 1085 Ericsson 1086 Jorvas 02420 1087 Finland 1089 Email: jari.arkko@piuha.net 1091 Ari Keranen 1092 Ericsson 1093 Jorvas 02420 1094 Finland 1096 Email: ari.keranen@ericsson.com 1097 Heidi-Maria Rissanen 1098 Ericsson 1099 Jorvas 02420 1100 Finland 1102 Email: heidi-maria.rissanen@ericsson.com