Network Working Group J. Arkko Internet-Draft A. Keranen Intended status: Informational M. Sethi Expires: August 24, 2012 Ericsson February 21, 2012 Practical Considerations and Implementation Experiences in Securing Smart Object Networks draft-aks-crypto-sensors-00 Abstract This memo describes challenges associated with securing smart object devices in constrained implementations and environments. The memo describes a possible deployment model suitable for these environments, discusses the availability of cryptographic libraries for small devices, presents some experiences in implementing small devices using those libraries, and discusses trade-offs involving different types of approaches. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 24, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Arkko, et al. Expires August 24, 2012 [Page 1] Internet-Draft Smart Object Security Experiences February 2012 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . . 3 2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Protocol Architecture . . . . . . . . . . . . . . . . . . 7 4. Code Availability . . . . . . . . . . . . . . . . . . . . . . 8 5. Implementation Experiences . . . . . . . . . . . . . . . . . . 9 6. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Feasibility . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Layering . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Arkko, et al. Expires August 24, 2012 [Page 2] Internet-Draft Smart Object Security Experiences February 2012 1. Introduction This memo describes challenges associated with securing smart object devices in constrained implementations and environments (see Section 2). Secondly, Section 3 discusses a deployment model that the authors are considering for constrained environments. The model requires minimal amount of configuration, and we believe it is a natural fit with the typical communication practices smart object networking environments. Thirdly, Section 4 discusses the availability of cryptographic libraries. Section 5 presents some experiences in implementing small devices using those libraries, including information about achievable code sizes and speeds on typical hardware. Finally, Section 6 discusses trade-offs involving different types of security approaches. 1.1. Related Work Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a light-weight protocol designed to be used in machine-to-machine applications such as smart energy and building automation. Our discussion uses this protocol as an example, but the conclusions may apply to other similar protocols. CoAP base specification [I-D.ietf-core-coap] outlines how to use DTLS [RFC5238] and IPsec [RFC4306] for securing the protocol. DTLS can be applied with group keys, pairwise shared keys, or with certificates. The security model in all cases is mutual authentication, so while there is some commonality to HTTP in verifying the server identity, in practice the models are quite different. The specification says little about how DTLS keys are managed. The IPsec mode is described with regards to the protocol requirements, noting that small implementations of IKEv2 exist [I-D.kivinen-ipsecme-ikev2-minimal]. However, the specification is silent on policy and other aspects that are normally necessary in order to implement interoperable use of IPsec in any environment [RFC5406]. [I-D.iab-smart-object-workshop] gives an overview of the security discussions at the March 2011 IAB workshop on smart objects. The workshop recommended that additional work is needed in developing suitable credential management mechanisms (perhaps something similar to the Bluetooth pairing mechanism), understanding the implementability of standard security mechanisms in small devices and additional research in the area of lightweight cryptographic primitives. Arkko, et al. Expires August 24, 2012 [Page 3] Internet-Draft Smart Object Security Experiences February 2012 [I-D.moskowitz-hip-rg-dex] defines a light-weight version of the HIP protocol for low-power nodes. This version uses a fixed set of algorithms, Elliptic Curve Cryptography (ECC), and eliminates hash functions. The protocol still operates based on host identities, and runs end-to-end between hosts, protecting IP layer communications. [RFC6078] describes an extension of HIP that can be used to send upper layer protocol messages without running the usual HIP base exchange at all. [I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis of security issues related to 6LoWPAN networks, but its findings also apply more generally for all low-powered networks. Some of the issues this document discusses include the need to minimize the number of transmitted bits and simplify implementations, threats in the smart object networking environments, and the suitability of 6LoWPAN security mechanisms, IPsec, and key management protocols for implementation in these environments. [I-D.garcia-core-security] discusses the overall security problem for Internet of Things devices. It also discusses various solutions, including IKEv2/IPsec [RFC4306], TLS/SSL [RFC5246], DTLS [RFC5238], HIP [RFC5201] [I-D.ietf-hip-rfc5201-bis] [I-D.moskowitz-hip-rg-dex], PANA [RFC5191], and EAP [RFC3748]. The draft also discusses various operational scenarios, bootstrapping mechanisms, and challenges associated with implementing security mechanisms in these environments. 2. Challenges This section discusses three challenges: implementation difficulties, practical provisioning problems, and layering and communication models. The most often discussed issues in the security for the Internet of Things relate to implementation difficulties. The desire to build small, battery-operated, and inexpensive devices drives the creation of devices with a limited protocol and application suite. Some of the typical limitations include running CoAP instead of HTTP, limited support for security mechanisms, limited processing power for long key lengths, sleep schedule that does not allow communication at all times, and so on. In addition, the devices typically have very limited support for configuration, making it hard to set up secrets and trust anchors. The implementation difficulties are important, but they should not be overemphasized. It is important to select the right security mechanisms and avoid duplicated or unnecessary functionality. But at Arkko, et al. Expires August 24, 2012 [Page 4] Internet-Draft Smart Object Security Experiences February 2012 the end of the day, if strong cryptographic security is needed, the implementations have to support that. Also, the use of the most lightweight algorithms and cryptographic primitives is useful, but should not be the only consideration in the design. Interoperability is also important, and often other parts of the system, such as key management protocols or certificate formats are heavier to implement than the algorithms themselves. The second challenge relates to practical provisioning problems. These are perhaps the most fundamental and difficult issue, and unfortunately often neglected in the design. There are several problems in the provisioning and management of smart object networks: o Small devices have no natural user interface for configuration that would be required for the installation of shared secrets and other security-related parameters. Typically, there is no keyboard, no display, and there may not even be buttons to press. Some devices may only have one interface, the interface to the network. o Manual configuration is rarely, if at all, possible, as the necessary skills are missing in typical installation environments (such as in family homes). o There may be a large number of devices. Configuration tasks that may be acceptable when performed for one device may become unacceptable with dozens or hundreds of devices. o Network configurations evolve over the lifetime of the devices, as additional devices are introduced or addresses change. Various central nodes may also receive more frequent updates than individual devices such as sensors embedded in building materials. Finally, layering and communication models present difficulties for straightforward use of the most obvious security mechanisms. Smart object networks typically pass information through multiple participating nodes [I-D.arkko-core-sleepy-sensors] and end-to-end security for IP or transport layers may not fit such communication models very well. The primary reasons for needing middleboxes relates to the need to accommodate for sleeping nodes as well to enable the implementation of nodes that store or aggregate information. 3. Proposed Deployment Model [I-D.arkko-core-security-arch] recognizes the provisioning model as the driver of what kind of security architecture is useful. This Arkko, et al. Expires August 24, 2012 [Page 5] Internet-Draft Smart Object Security Experiences February 2012 section re-introduces this model briefly here in order to facilitate the discussion of the various design alternatives later. The basis of the proposed architecture are self-generated secure identities, similar to Cryptographically Generated Addresses (CGAs) [RFC3972] or Host Identity Tags (HITs) [RFC5201]. That is, we assume the following holds: I = h(P|O) where I is the secure identity of the device, h is a hash function, P is the public key from a key pair generated by the device, and O is optional other information. 3.1. Provisioning As provisioning security credentials, shared secrets, and policy information is difficult, the provisioning model is based only on the secure identities. A typical network installation involves physical placement of a number of devices while noting the identities of these devices. This list of short identifiers can then be fed to a central server as a list of authorized devices. Secure communications can then commence with the devices, at least as far as information from from the devices to the server is concerned, which is what is needed for sensor networks. Actuator networks and server-to-device communication is covered in Section 4.4 of [I-D.arkko-core-security-arch]. Where necessary, the information collected at installation time may also include other parameters relevant to the application, such as the location or purpose of the devices. This would enable the server to know, for instance, that a particular device is the temperature sensor for the kitchen. Collecting the identity information at installation time can be arranged in a number of ways. The authors have employed a simple but not completely secure method where the last few digits of the identity are printed on a tiny device just a few millimeters across. Alternatively, the packaging for the device may include the full identity (typically 32 hex digits), retrieved from the device at manufacturing time. This identity can be read, for instance, by a bar code reader carried by the installation personnel. (Note that the identities are not secret, the security of the system is not dependent on the identity information leaking to others. The real owner of an identity can always prove its ownership with the private key which never leaves the device.) Finally, the device may use its wired network interface or proximity-based communications, such as Near-Field Communications (NFC) or Radio-Frequency Identity tags Arkko, et al. Expires August 24, 2012 [Page 6] Internet-Draft Smart Object Security Experiences February 2012 (RFIDs). Such interfaces allow secure communication of the device identity to an information gathering device at installation time. No matter what the method of information collection is, this provisioning model minimizes the effort required to set up the security. Each device generates its own identity in a random, secure key generation process. The identities are self-securing in the sense that if you know the identity of the peer you want to communicate with, messages from the peer can be signed by the peer's private key and it is trivial to verify that the message came from the expected peer. There is no need to configure an identity and certificate of that identity separately. There is no need to configure a group secret or a shared secret. There is no need to configure a trust anchor. In addition, the identities are typically collected anyway for application purposes (such as identifying which sensor is in which room). Under most circumstances there is actually no additional configuration effort from provisioning security. Groups of devices can be managed through single identifiers as well. See Section 4.2 in [I-D.arkko-core-security-arch] for further information. 3.2. Protocol Architecture As noted above, the starting point of the architecture is that nodes self-generate secure identities which are then communicated out-of- band to the peers that need to know what devices to trust. To support this model in a protocol architecture, we also need to use these secure identities to implement secure messaging between the peers, explain how the system can respond to different types of attacks such as replay attempts, and decide at what protocol layer and endpoints the architecture should use. The deployment itself is suitable for a variety of design choices regarding layering and protocol mechanisms. [I-D.arkko-core-security-arch] was mostly focused on employing end- to-end data object security as opposed to hop-by-hop security. But other approaches are possible. For instance, HIP in its opportunistic mode could be used to implement largely the same functionality at the IP layer. However, it is our belief that the right layer for this solution is at the application layer. More specifically, in the data formats transported in the payload part of CoAP. This approach provides the following benefits: o Ability for intermediaries to act as caches to support different sleep schedules, without the security model being impacted. Arkko, et al. Expires August 24, 2012 [Page 7] Internet-Draft Smart Object Security Experiences February 2012 o Ability for intermediaries to be built to perform aggregation, filtering, storage and other actions, again without impacting the security of the data being transmitted or stored. o Ability to operate in the presence of traditional middleboxes, such as a protocol translators or even NATs (not that we recommend their use in these environments). However, as we will see later there are also some technical implications, namely that link, network, and transport layer solutions are more likely to be able to benefit from sessions where the cost of expensive operations can be amortized over multiple data transmissions. While this is not impossible in data object security solutions either, it is not the typical arrangement either. 4. Code Availability For implementing public key cryptography on resource constrained environments, we chose Arduino Uno board [arduino-uno] as the test platform. Arduino Uno has an ATmega328 microcontroller with a clock speed of 16 MHz, 2 kB of SRAM, and 32 kB of flash memory. For selecting potential asymmetric cryptographic libraries, we did an extensive survey and came up with an initial set of possible code sources: o AvrCryptolib [avr-cryptolib]: This library provides a variety of different symmetric key algorithms such as DES/Triple DES/AES etc. and RSA as an asymmetric key algorithm. We stripped down the library to use only the required RSA components and used a separate SHA-256 implementation from the original AvrCrypto-Lib library [avr-crypto-lib]. Parts of SHA-256 and RSA algorithm implementations were written in AVR-8 bit assembly language to reduce the size and optimize the performance. The library also takes advantage of the fact that Arduino boards allow the programmer to directly address the flash memory to access constant data which can save the amount of SRAM used during execution. o Relic-Toolkit [relic-toolkit]: This library is written entirely in C and provides a highly flexible and customizable implementation of a large variety of cryptographic algorithms. This not only includes RSA and ECC, but also pairing based asymmetric cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures and many more. The toolkit provides an option to build only the desired components for the required platform. While building the library, it is possible to select a variety mathematical optimizations that can be combined to obtain the desired performance (as a general thumb rule, faster implementations Arkko, et al. Expires August 24, 2012 [Page 8] Internet-Draft Smart Object Security Experiences February 2012 require more SRAM and flash). It includes a multi precision integer math module which can be customized to use different bit- length words. o TinyECC [tinyecc]: TinyECC was designed for using Elliptic Curve based public key cryptography on sensor networks. It is written in nesC programming language and as such is designed for specific use on TinyOS. However, the library can be ported to standard C99 either with hacked tool-chains or manually rewriting parts of the code. This allows for the library to be used on platforms that do not have TinyOS running on them. The library includes a wide variety of mathematical optimizations such as sliding window, Barrett reduction for verification, precomputation, etc. It also has one of the smallest memory footprints among the set of Elliptic Curve libraries surveyed so far. However, an advantage of Relic over TinyECC is that it can do curves over binary fields in addition to prime fields. o MatrixSSL [matrix-ssl]: This library provides a low footprint implementation of several cryptographic algorithms including RSA and ECC (with a commercial license). However, the library in the original form takes about 50 kB of ROM which is not suitable for our hardware requirements. Moreover, it is intended for 32-bit systems and the API includes functions for SSL communication rather than just signing data with private keys. 5. Implementation Experiences We have summarized the initial results of RSA private key performance using AvrCryptolib in Table 1. All results are from a single run since repeating the test did not change (or had only minimal impact on) the results. The keys were generated separately and were hard coded into the program. All keys were generated with the value of the public exponent as 3. The performance of encryption with private key was faster for smaller key lengths as was expected. However the increase in the execution time was considerable when the key size was 2048 bits. It is important to note that two different sets of experiments were performed for each key length. In the first case, the keys were loaded into the SRAM from the ROM (flash) before they were used by any of the functions. However, in the second case, the keys were addressed directly in the ROM. As was expected, the second case used less SRAM but lead to longer execution time. Arkko, et al. Expires August 24, 2012 [Page 9] Internet-Draft Smart Object Security Experiences February 2012 +--------+--------------+--------------+-------------+--------------+ | Key | Execution | Memory | Execution | Memory | | length | time (ms); | footprint | time (ms); | footprint | | (bits) | key in SRAM | (bytes); key | key in ROM | (bytes); key | | | | in SRAM | | in ROM | +--------+--------------+--------------+-------------+--------------+ | 64 | 66 | 40 | 70 | 32 | | 128 | 124 | 80 | 459 | 64 | | 512 | 25,089 | 320 | 27,348 | 256 | | 1,024 | 199,666 | 640 | 218,367 | 512 | | 2,048 | 1,587,559 | 1,280 | 1,740,267 | 1,024 | +--------+--------------+--------------+-------------+--------------+ RSA private key operation performance Table 1 The code size was less than 3.6 kB for all the test cases with scope for further reduction. It is also worth noting that the implementation performs basic exponentiation and multiplication operations without using any mathematical optimizations such as Montgomery multiplication, optimized squaring, etc. as described in [rsa-high-speed]. With more SRAM, we believe that 1024/2048-bit operations can be performed in much less time as has been shown in [rsa-8bit]. 2048-bit RSA is nonetheless possible with about 1 kB of SRAM as is seen in Table 1. In Table 2 we present the initial set of results obtained by manually porting TinyECC into C99 standard and running ECDSA signature algorithm on the Arduino Uno board. TinyECC supports a variety of SEC 2 recommended Elliptic Curve domain parameters. The execution time and memory footprint are shown next to each of the curve parameters. SHA-1 hashing algorithm included in the library was used in each of the cases. It is clearly observable that for similar security levels, Elliptic Curve public key cryptography outperforms RSA. These were an initial set of experiments and there are further test cases that need to be analyzed to correctly benchmark the library. Several optimizations like optimized modular reduction, sliding window and Barrett reduction for signature verification have not been tested and remains as future work for the authors. Arkko, et al. Expires August 24, 2012 [Page 10] Internet-Draft Smart Object Security Experiences February 2012 +-------------+---------------+-----------------+-------------------+ | Curve | Execution | Memory | Comparable RSA | | parameters | time (ms) | Footprint | key length | | | | (bytes) | | +-------------+---------------+-----------------+-------------------+ | 128r1 | 2,919 | 390 | 704 | | 128r2 | 3,315 | 390 | 704 | | 160k1 | 4,631 | 438 | 1,024 | | 160r1 | 4,990 | 438 | 1,024 | | 160r2 | 4,992 | 438 | 1,024 | | 192k1 | 7,817 | 486 | 1,536 | | 192r1 | 8,071 | 486 | 1,536 | +-------------+---------------+-----------------+-------------------+ ECDSA signing performance Table 2 6. Design Trade-Offs This section attempts to make some early conclusions regarding trade- offs in the design space, based on deployment considerations for various mechanisms and the relative ease or difficulty of implementing them. This analysis looks at layering and the choice of symmetric vs. asymmetric cryptography. 6.1. Feasibility The first question is whether using cryptographic security and asymmetric cryptography in particular is feasible at all on small devices. The numbers above give a mixed message. Clearly, an implementation of a significant cryptographic operation such as public key signing can be done in surprisingly small amount of code space. It could even be argued that our chosen prototype platform was unnecessarily restrictive in the amount of code space it allows: we chose this platform on purpose to demonstrate something that is as small and difficult as possible. In reality, ROM memory size is probably easier to grow than other parameters in microcontrollers. A recent trend in microcontrollers is the introduction of 32-bit CPUs that are becoming cheaper and more easily available than 8-bit CPUs, in addition to being more easily programmable. In short, the authors do not expect the code size to be a significant limiting factor, both because of the small amount of code that is needed and because available memory space is growing rapidly. Arkko, et al. Expires August 24, 2012 [Page 11] Internet-Draft Smart Object Security Experiences February 2012 The situation is less clear with regards to the amount of CPU power needed to run the algorithms. The demonstrated speeds are sufficient for many applications. For instance, a sensor that wakes up every now and then can likely spend a fraction of a second for the computation of a signature for the message that it is about to send. Or even spend multiple seconds in some cases. Most applications that use protocols such as DTLS that use public key cryptography only at the beginning of the session would also be fine with any of these execution times. Yet, with reasonably long key sizes the execution times are in the seconds, dozens of seconds, or even longer. For some applications this is too long. Nevertheless, the authors believe that these algorithms can successfully be employed in small devices for the following reasons: o As discussed in [wiman], in general the power requirements necessary to send or receive messages are far bigger than those needed to execute cryptographic operations. There is no good reason to choose platforms that do not provide sufficient computing power to run the necessary operations. o Commercial libraries and the use of full potential for various optimizations will provide a better result than what we arrived at in this paper. o Using public key cryptography only at the beginning of a session will reduce the per-packet processing times significantly. 6.2. Layering It would be useful to select just one layer where security is provided at. Otherwise a simple device needs to implement multiple security mechanisms. While some code can probably be shared across such implementations (like algorithms), it is likely that most of the code involving the actual protocol machinery cannot. Looking at the different layers, here are the choices and their implications: link layer This is probably the most common solution today. The biggest benefits of this choice of layer are that security services are commonly available (WLAN secrets, cellular SIM cards, etc.) and that their application protects the entire communications. The main drawback is that there is no security beyond the first hop. This can be problematic, e.g., in many devices that communicate to a server in the Internet. A Withings scale Arkko, et al. Expires August 24, 2012 [Page 12] Internet-Draft Smart Object Security Experiences February 2012 [Withings], for instance, can support WLAN security but without some level of end-to-end security, it would be difficult to prevent fraudulent data submissions to the servers. Another drawback is that some commonly implemented link layer security designs use group secrets. This allows any device within the local network (e.g., an infected laptop) to attack the communications. network layer There are a number of solutions in this space, and many new ones and variations thereof being proposed: IPsec, PANA, and so on. In general, these solutions have similar characteristics to those in the transport layer: they work across forwarding hops but only as far as to the next middlebox or application entity. There is plenty of existing solutions and designs. Experience has shown that it is difficult to control IP layer entities from an application process. While this is theoretically easy, in practice the necessary APIs do not exist. For instance, most IPsec software has been built for the VPN use case, and is difficult or impossible to tweak to be used on a per-application basis. As a result, the authors are not particularly enthusiastic about recommending these solutions. transport and application layer This is another popular solution along with link layer designs. SSL, TLS, DTLS, and HTTPS are examples of solutions in this space, and have been proven to work well. These solutions are typically easy to take into use in an application, without assuming anything from the underlying OS, and they are easy to control as needed by the applications. The main drawback is that generally speaking, these solutions only run as far as the next application level entity. And even for this case, HTTPS can be made to work through proxies, so this limit is not unsolvable. Another drawback is that attacks on link layer, network layer and in some cases, transport layer, can not be protected against. However, if the upper layers have been protected, such attacks can at most result in a denial-of-service. Since denial-of-service can often be caused anyway, it is not clear if this is a real drawback. data object layer This solution does not protect any of the protocol layers, but protects individual data elements being sent. It works particularly well when there are multiple application layer Arkko, et al. Expires August 24, 2012 [Page 13] Internet-Draft Smart Object Security Experiences February 2012 entities on the path of the data. The authors believe smart object networks are likely to employ such entities for storage, filtering, aggregation and other reasons, and as such, an end-to- end solution is the only one that can protect the actual data. The downside is that the lower layers are not protected. But again, as long as the data is protected and checked upon every time it passes through an application level entity, it is not clear that there are attacks beyond denial-of-service. The main question mark is whether this type of a solution provides sufficient advantages over the more commonly implemented transport and application layer solutions. 6.3. Symmetric vs. Asymmetric Crypto The second trade-off that is worth discussing is the use of plain asymmetric cryptographic mechanisms, plain symmetric cryptographic mechanisms, or some mixture thereof. Contrary to popular cryptographic community beliefs, a symmetric crypto solution can be deployed in large scale. In fact, the largest deployment of cryptographic security, the cellular network authentication system, uses SIM cards that are based on symmetric secrets. In contrast, public key systems have yet to show ability to scale to hundreds of millions of devices, let alone billions. But the authors do not believe scaling is an important differentiator when comparing the solutions. As can be seen from the Section 5, the time needed to calculate some of the asymmetric crypto operations with reasonable key lengths can be significant. There are two contrary observations that can be made from this. First, recent wisdom indicates that computing power on small devices is far cheaper than transmission power [wiman], and keeps on becoming more efficient very quickly. From this we can conclude that the sufficient CPU is or at least will be easily available. But the other observation is that when there are very costly asymmetric operations, doing a key exchange followed by the use of generated symmetric keys would make sense. This model works very well for DTLS and other transport layer solutions, but works less well for data object security, particularly when the number of communicating entities is not exactly two. Arkko, et al. Expires August 24, 2012 [Page 14] Internet-Draft Smart Object Security Experiences February 2012 7. Security Considerations This entire memo deals with security issues. 8. IANA Considerations There are no IANA impacts in this memo. 9. References 9.1. Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-06 (work in progress), May 2011. [arduino-uno] "Arduino Uno", . [relic-toolkit] "Relic Toolkit", . [avr-crypto-lib] Das Labor, "AVR-CRYPTO-LIB", . [avr-cryptolib] "AVR CRYPTOLIB", . [tinyecc] North Carolina State University and North Carolina State University, "TinyECC", . [matrix-ssl] PeerSec Networks, "Matrix SSL", . [rsa-high-speed] RSA Labs, "High-Speed RSA Implementation", . [rsa-8bit] Sun Microsystems, "Comparing Elliptic Curve Cryptography Arkko, et al. Expires August 24, 2012 [Page 15] Internet-Draft Smart Object Security Experiences February 2012 and RSA on 8-bit CPUs". 9.2. Informative References [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008. [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, February 2009. [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)", RFC 6078, January 2011. [I-D.arkko-core-sleepy-sensors] Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Novo, "Implementing Tiny COAP Sensors", draft-arkko-core-sleepy-sensors-01 (work in progress), July 2011. [I-D.arkko-core-security-arch] Arkko, J. and A. Keranen, "CoAP Security Architecture", draft-arkko-core-security-arch-00 (work in progress), July 2011. [I-D.daniel-6lowpan-security-analysis] Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. Arkko, et al. Expires August 24, 2012 [Page 16] Internet-Draft Smart Object Security Experiences February 2012 Laganier, "IPv6 over Low Power WPAN Security Analysis", draft-daniel-6lowpan-security-analysis-05 (work in progress), March 2011. [I-D.garcia-core-security] Garcia-Morchon, O., Keoh, S., Kumar, S., Hummen, R., and R. Struik, "Security Considerations in the IP-based Internet of Things", draft-garcia-core-security-03 (work in progress), October 2011. [I-D.iab-smart-object-workshop] Tschofenig, H. and J. Arkko, "Report from the 'Interconnecting Smart Objects with the Internet' Workshop, 25th March 2011, Prague", draft-iab-smart-object-workshop-10 (work in progress), January 2012. [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-hip-rfc5201-bis-07 (work in progress), October 2011. [I-D.kivinen-ipsecme-ikev2-minimal] Kivinen, T., "Minimal IKEv2", draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress), February 2011. [I-D.moskowitz-hip-rg-dex] Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz-hip-rg-dex-05 (work in progress), March 2011. [Withings] Withings, "The Withings scale", February 2012, . [wiman] "Impact of Operating Systems on Wireless Sensor Networks (Security) Applications and Testbeds. In International Conference on Computer Communication Networks (ICCCN'2010) / IEEE International Workshop on Wireless Mesh and Ad Hoc Networks (WiMAN 2010), 2010, Zuerich. Proceedings of ICCCN'2010/WiMAN'2010", 2010. Appendix A. Acknowledgments The authors would like to thank Mats Naslund, Salvatore Loreto, Bob Arkko, et al. Expires August 24, 2012 [Page 17] Internet-Draft Smart Object Security Experiences February 2012 Moskowitz, Oscar Novo, Heidi-Maria Rissanen, Vlasios Tsiatsis, Eric Rescorla and Tero Kivinen for interesting discussions in this problem space. Authors' Addresses Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@piuha.net Ari Keranen Ericsson Jorvas 02420 Finland Email: ari.keranen@ericsson.com Mohit Sethi Ericsson Jorvas 02420 Finland Email: mohit.m.sethi@ericsson.com Arkko, et al. Expires August 24, 2012 [Page 18]