6lowapp R. Struik Internet Draft Certicom Corp. Intended status: Informational October 19, 2009 Expires: April 21, 2010 Security Architectural Design Considerations for Low-Power Wireless Sensor Networks draft-struik-6lowapp-security-considerations-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 19, 2010. Struik Expires April 21, 2010 [Page 1] Internet-Draft Security Considerations October 19, 2009 Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract We discuss security architectural design considerations for general-purpose multi-hop ad-hoc networks. The security architecture fits extremely constrained wireless environments, such as sensor networks, while remaining uniform and general enough to fit any wireless network. The design is tailored towards low overall implementation cost, supports semi-automatic lifecycle management, including ease of installation and configuration, scalability, survivability, mobility, and is adaptable towards network topology changes and towards different trust models underlying network operations. Table of Contents 1. Introduction...................................................3 1.1. Market Potential..........................................3 1.2. Need for Security.........................................4 1.3. Current Industrial Practice and Unmet Need for Security...4 1.4. Contributions of this document............................5 2. Security and Usability Aspects.................................6 2.1. Security Architectural Aspects............................8 2.2. Implementation Aspects....................................8 3. Assumptions....................................................9 3.1. Security Assumptions and Consequences.....................9 3.2. Feasibility of Cryptographic Technology on Low-Cost Devices11 4. Security Architectural Design.................................11 4.1. Technical Discussion.....................................12 4.1.1. Security Policy and Trust Model.....................12 4.1.2. Configuration and Installation......................14 4.1.3. Key Identification and Key Usage....................15 5. Conclusions...................................................15 6. Future work...................................................16 Struik Expires April 21, 2010 [Page 2] Internet-Draft Security Considerations October 19, 2009 7. Security Considerations.......................................16 8. IANA Considerations...........................................16 9. Acknowledgements..............................................16 10. References...................................................16 10.1. Normative References....................................16 10.2. Informative References..................................17 1. Introduction 1.1. Market Potential Wireless sensor networks have tremendous potential. Studies by the ZigBee Alliance [41]suggested the market for wireless sensor networks to reach over 3 billion devices by 2007, applications ranging from toys and games, consumer electronics and PC peripherals, and home automation, to building automation, health care, automotive, and industrial and commercial. Figures released by the IEEE 802.15.4a Task Group [23](a group tasked with drafting ultra wide band extensions of the IEEE 802.15.4 standard) suggested a market potential of 600-1400 million sensor nodes for 2007, excluding potentially billions of nodes that could provide highly accurate localization information, such as for supply chain management, asset tracking, and locating people (e.g., emergency personnel and military). Furthermore, this document quoted estimates from Forrester that suggest the market for 'invisible mobile' to be over 30 times as big as that for 'visible mobile' (20-200 billion vs. 0.1-1 billion devices). While these predictions have not been realized in the originally anticipated time frame, it seems only a matter of time for the 'Internet of things' to come to full fruition. According to a 2002 study by the US Department of Energy [37], the deployment of wireless sensor networks in industry could improve production efficiency by 10 percent and reduce emissions by more than 25%. Furthermore, it could dramatically reduce installation and 'wiring' cost, currently ranging from USD 50-100 per foot up to USD 2,000 per foot for hazardous environments (including labor). To illustrate the latter, 2001 market data provided by the Wireless Industrial Networking Alliance (WINA)[40] suggest wiring costs of over USD 100 billion in a sensor market of USD 11 billion. For home automation, the introduction of wireless controls could dramatically lower installation cost, as the removal of wires could make home networking a do-it-yourself (DIY) experience. As case in point, consider the prospects for wireless switches, which could be glued on any object, without the need for physical wiring. For building automation, the introduction of intelligent networks involving room thermostats and motion sensors has shown potential climate control (HVAC) cost savings for hotels of over 40%. Numerous other examples Struik Expires April 21, 2010 [Page 3] Internet-Draft Security Considerations October 19, 2009 exist, such as smart clothing, medical diagnostics, wastewater treatment, earthquake detection, preventive maintenance, securing sea containers, and Homeland Security applications. 1.2. Need for Security The examples above illustrate the vast potential of low-cost wireless sensor networks. Large-scale deployment of these networks critically depends on robustness and security features. As a minimum, security should provide for network separation, such as to avoid, e.g., networks in neighboring houses to remotely control each other's lights, TVs, and other home peripherals. Usually, the need for security is more profound and includes the requirement for confidentiality and authentication of all network traffic, such as to avoid the execution of unauthorized commands and inadvertent disclosure of private information. End-user studies by the Wireless Industrial Networking Alliance and the US Department of Energy consistently express addressing of security issues, such as jamming, spoofing, hacking, and eavesdropping, as a high priority. One should note that the implementation of proper security measures would also facilitate the addressing of concerns as to network reliability and robustness, flexibility and scalability of deployed networks, and ease-of installation and configuration. It is, therefore, clear that security has an important role in facilitating wide-scale deployment of wireless sensor networks. 1.3. Current Industrial Practice and Unmet Need for Security Wireless adhoc networking is still a nascent technology. Currently deployed wireless networks either do not lend themselves to true adhoc networking (such as with IEEE 802.11 WLAN, for which adhoc extensions are being investigated only now) or provide for some adhoc networking, but do not meet the low implementation cost, low power, and high flexibility requirements for sensor and control networks (such as with Bluetooth, which has a 100+ kbytes code size, and for which a Bluetooth-`Lite' version is still in the design phase). Nevertheless, some experimental adhoc networks show promise for sensor and control applications, including the smart mote project of the University of California at Berkeley and the so-called smart dust project. The latter projects explicitly aim at providing adhoc- networking facilities for extremely mundane applications. The security architecture TinySec envisioned for these experimental projects is quite limited, though, since it does not provide sufficient facilities for key life-cycle key management, nor seems to envision it. Thus, it would be difficult to deploy smart mote networks in a flexible and scalable, yet secure way, conditio sine qua non for large-scale industrial deployment. The same analysis Struik Expires April 21, 2010 [Page 4] Internet-Draft Security Considerations October 19, 2009 applies to proprietary home control and building automation standards, such as X10 and CABA, which all inadequately address security at best or simply ignore it. Thus, there is a clear unmet need for securing adhoc wireless sensor networks. This being said, several recent international standardization efforts aimed at sensor- like monitoring and control applications do take security considerations into account in their design, such as the IEEE 802.15.4 family of MAC/PHY standards, the ZigBee standard, the ISA SP100.11a industrial monitoring and control standard, and, e.g., Wireless HART; for those, it is generally too early to tell whether security lifecycle aspects are adequately being addressed. 1.4. Contributions of this document This document discusses security architectural design considerations for general-purpose, self-organizing, multihop ad-hoc networks. Communications between static and moving devices in these networks are based on radio transmissions, typically operating in unlicensed frequency bands, e.g., 868/915 MHz and 2.4 GHz, and might involve single-hop or multi-hop message routing. From a security perspective, wireless ad-hoc networks are no other than 802.11 WLAN or any other wireless network, in that these are vulnerable to passive eavesdropping attacks. The very nature of ad-hoc networks and cost objectives for these impose additional security constraints, however, which perhaps make these networks the most difficult environments to secure: devices are low-cost devices with limited capabilities, in terms of computing power, available storage, and power-drain, and cannot be assumed to have a trusted computing base aboard, nor a high quality random number generator; communications cannot rely on the online availability of a fixed infrastructure and might involve short-term relationships between devices that may never have met before - - so-called promiscuous behavior. These constraints severely limit the choice of cryptographic algorithms and protocols and do influence the design of the security architecture, since the establishment and maintenance of trust relationships between devices needs to be addressed with care. In addition, battery lifetime and cost constraints put severe limits on the security overhead these networks can tolerate, something that is of far less concern with higher bandwidth networks, such as 802.11 WLAN. We present a security architecture that (we believe) fits extremely constrained wireless environments, such as sensor networks, while remaining uniform and general enough to fit any wireless network (including enterprise environments and wireless broadband scenarios). The design is tailored towards low overall implementation cost, adaptable towards different trust models underlying network operations, and supports semi-automatic lifecycle management, including ease-of-installation Struik Expires April 21, 2010 [Page 5] Internet-Draft Security Considerations October 19, 2009 and ease-of-use, scalability, survivability, mobility, and network topology changes. The document is organized as follows. In Section 2, we discuss security and usability aspects relevant to the security design, while Section 3 describes underlying assumptions hereof. In Section 4, we sketch components of the actual security design. Summary conclusions appear in Section 5. 2. Security and Usability Aspects The security architectural design should facilitate infrastructure security, as well as application level security, for multi-hop adhoc networks. The implementation of this design should meet the low implementation cost, low power, and high flexibility requirements for constrained applications, such as with sensor and control networks. The design should allow flexibility, such as to allow adaptability to the actual deployment scenario at hand. As an example, the following design considerations should be taken into account: 1. Security design and procurement scenarios. The security design should not assume alignment and coordination of production processes. In particular, it should facilitate 'mix-and-match' procurement and deployment scenarios, including procurement of nodes from multiple vendors or service providers, procurement of node components (e.g., radio, embedded processor) from multiple sources, procurement of the entire system via an intermediary, installer, or service provider, re-cycling or re-use of an industrial network or a component hereof elsewhere, and merging of networks of several industrial facilities. 2. Security topology vs. network topology. The security design should try and minimize assumptions on the network topology, including wireless field devices, routers, gateway, and back-end servers. In particular, it should not assume a wireless network with online connectivity to wired infrastructure (both locally and globally, e.g., to a manufacturer or service provider network) and should not assume that devices do not move (since this would, e.g., preclude deployment of a sensor node on a forklift).The security design would benefit from the design principle of 'separation of concern', where one tries and avoid unnecessary dependencies between the security design and other aspects of system design, such as communication aspects and network topology. Here, one should bear Struik Expires April 21, 2010 [Page 6] Internet-Draft Security Considerations October 19, 2009 in mind that the security design is concerned with logical relationships amongst entities, rather than physical ones, thus allowing considerable design flexibility. 3. Security roles vs. network roles. The security design should not assume fixed device types (e.g., wireless field device, router, gateway, back-end server, configuration tool, security manager), with roles cast in stone, since this would suggest that device types are static, whilst in reality these often may not be. It may be beneficial here, instead, to think in terms of device roles and mapping of roles to devices, where the assignment of roles to devices may be delayed to the provisioning stage (thus, reducing this to a provisioning/commissioning task) or may change during the system's lifecycle. This would facilitate deployment scenarios, including, e.g., replacement of a malfunctioning device, initial configuration of devices by multiple installation crews using PDA- based tools followed by hand-over of control to the network owner afterwards, and resale of a manufacturing plant to a competitor - - where one does not want to have one's competitor having dangling keys to one's own infrastructure, 4. Security design and ease-of-use. The security design should be based on a comprehensive list of security objectives (inspired by threat analysis), but should also fully capture usability aspects, such as flexible deployment, ease-of-use, scalability, and adaptability towards network topology changes and towards changes in trust relationships. This should include trust lifecycle management support, including security policies underlying both initial device and network configuration and set-up and on-going network management, and security policies underlying changes to keying material, trusted routines, and other security-relevant information, such as authorization information. Obviously, actual requirements highly depend on the deployment scenario at hand. As an example, with small residential networks one may very well simply install pre-configured nodes bundled in a package (a so-called 'blister-pack'), whereas with commercial and industrial networks one may be faced with large networks comprising thousands of nodes, where network installation follows an elaborate 'wiring' blueprint and where configuration of each single device potentially involves hundreds of parameters per and where changes to the network and its functions over the system's lifecycle must be Struik Expires April 21, 2010 [Page 7] Internet-Draft Security Considerations October 19, 2009 anticipated and accommodated for. Any general-purpose security architectural design should anticipate and facilitate a broad range of deployment scenarios, where adaptation to a particular deployment scenario may be realized by instantiating the generic design via appropriate configuration settings. This suggests the need for a general-purpose security stack-architecture for wireless monitoring and control networks with standardized application interfaces, since (as with any standard) the latter promises to deliver economies of scale, to dramatically reduce costs for the development and implementation of secured wireless applications, both by mass production of the underlying (chip) platform and by allowing the development of applications with a common platform interface. The security design should consider the following aspects: 2.1. Security Architectural Aspects The security architecture should fit extremely constrained wireless environments, such as sensor networks, while remaining uniform and general enough to allow seamless operation with any wired or wireless network (including enterprise environments and wireless broadband scenarios). In particular, the following requirements need to be addressed: o Support for secure data transport in peer-to-peer, broadcast, and multicast settings. o Scalability, network survivability, device mobility, and support for network topology changes. o Ease and flexibility of installation and configuration ('ease of use'). o Semi-automatic lifecycle management, with minimum human intervention. o Flexibility and adaptability towards different trust models underlying network operations (allowing, e.g., both centralized and distributed trust management). 2.2. Implementation Aspects The design should work in a low-cost, low-speed wireless environment, such as, e.g., standards built on top of the IEEE 802.15.4 Low-Rate WPAN standard. This necessitates addressing the following requirements: Struik Expires April 21, 2010 [Page 8] Internet-Draft Security Considerations October 19, 2009 o Integrated design of security functionality, such as to allow re- use of cryptographic components and exploiting commonality in message flows (and, thereby, saving on implementation cost). o Low communication overhead, such as to minimize impact security on power drain. o Low-cost implementation, in terms of power consumption, latency requirements, RAM/ROM use, and gate counts (taking into account trade-offs hardware/software and space/time tradeoffs). It should be noted that wireless sensors typically have a very low duty cycle (typically around 1%) and are highly constrained devices with low clock frequency (typically, 4-16 MHz), limited storage (typically, 64-128kB of ROM, 4-16 kB of RAM) and, possibly, no non- volatile storage, such as flash memory. This exemplifies that security design for sensor networks is a daunting task indeed! 3. Assumptions 3.1. Security Assumptions and Consequences The security services provided by the security design depend on the security of the symmetric and public keys the security mechanisms operate upon and on the secure implementation of the cryptographic mechanisms and associated security policies. Thus, trust in the security architecture ultimately reduces to trust in the secure initialization and installation of keying material and other security-relevant parameters and to trust in the secure processing and storage hereof. We assume that the actual implementation of the security design does not inadvertently leak keying material, nor allows manipulation of security-relevant parameters. Thus, we assume that a device will not intentionally or inadvertently transmit its keying material to other devices, unless the keying material is protected, such as during key transport. We assume that the security software and hardware operates as expected. Thus, implementations of security schemes, such as key establishment, properly execute the complete protocol and do not leave out any steps hereof. We do realize the following caveat in these assumptions: due to the low-cost nature of ad hoc network devices, we cannot generally Struik Expires April 21, 2010 [Page 9] Internet-Draft Security Considerations October 19, 2009 assume the availability of tamper-resistant hardware. Hence, physical access to a device may yield access to secret keying material and other privileged information and access to the security software and hardware. Due to the cost constraints of devices, we have to assume that different applications using the same device radio are not logically separated via a firewall, sandbox, or otherwise. In addition, from the perspective of a given device it is not even not possible (barring certification) to verify whether cryptographic separation between different applications on another device, or even between different layers of the communication stack hereof, is indeed properly implemented. Hence, we have to assume that separate applications using the same radio implicitly trust each other and that higher layers of the communication stack (e.g., transport and application layer) have full access to lower layers (e.g., MAC layer and network layer). These assumptions lead to an open trust model for a device: the security services provided by the security design cryptographically protect the interfaces between different devices only, separation of the interfaces between different communication stack layers or within the same layer within the same device being arranged non-cryptographically only, via proper design of interfaces to security services (i.e., service access points). This open trust model for a device has far-reaching consequences, since it allows the following design flexibility: 1. Sharing of keying material across layers. The same key may be used to protect messages, no matter whether these originate at the MAC layer, the network layer, or, e.g., at the application layer. Thus, keying material may be organized on a device-to-device basis, irrespective of the internal composition of devices, thereby reducing key storage cost and simplifying key management. 2. Delegation of security processing. The originator of a message may delegate security processing to a lower layer and the recipient(s) of this message may process incoming protected messages accordingly at this layer. As an example, this allows implementation of all single-hop security processing at the MAC layer and implementation of all multi-hop security processing at the transport layer. Struik Expires April 21, 2010 [Page 10] Internet-Draft Security Considerations October 19, 2009 3.2. Feasibility of Cryptographic Technology on Low-Cost Devices Economical deployment of sensor networks is extremely sensitive to implementation cost, low power, and high flexibility requirements for constrained applications. Conventional wisdom has long suggested that symmetric-key functionality, let alone public-key functionality, is prohibitively expensive for these devices and infeasible without dedicated hardware support. Recent results challenge this assumption: a cost estimate has shown that implementing suitable cryptographic building blocks that would allow for a flexible security architecture would be quite feasible for all but the most mundane devices in constrained sensor and control networks. In fact, one can show that the hardware implementation cost of the symmetric-key block cipher AES-128 and that of Elliptic Curve Cryptography (ECC) are comparable (typically, 2-5 cents on 0.33u CMOS technology) and that execution speed is less than 1 second for ECC- based authentication. Additionally, one should consider overall trust lifecycle management cost and not just the cost of cryptographic primitives (since the latter constitute only a small portion of total implementation cost). For studies on suitability of public-key technology with sensor and control applications, see, e.g., [13],[19],[24],[28],[39]. As a result, we contend that the security design may assume that basic symmetric-key and public-key cryptographic building blocks, such as AES-128 and ECC technologies, are indeed feasible in sensor and control applications and do not provide a cost hurdle. 4. Security Architectural Design The main mechanisms of the security architecture are as follows: 1. Key establishment scheme. This scheme facilitates the establishment of a link key between two devices, based on authentic public keys of both parties, including evidence on whom this link key is shared with. This cryptographic mechanism is sometimes complemented by a non-cryptographic mechanism, to determine whether one actually wishes to communicate with this explicitly identified party (e.g., via an access control list). 2. Key transport scheme. This scheme facilitates the secure and authentic transfer of keying material from one device to other(s), based on keying material shared between sender and recipient(s). Keying material may constitute, e.g., a peer-to-peer key (link Struik Expires April 21, 2010 [Page 11] Internet-Draft Security Considerations October 19, 2009 key), a group key, or a network-wide key. This mechanism is sometimes complemented by a non-cryptographic mechanism, to determine whether the transported key originated from a trusted source ('security manager'). 3. Data transport scheme. This scheme facilitates the secure and authentic transfer of ordinary data from one device to other(s), based on keying material shared between the sender and recipient(s). This mechanism is sometimes complemented by a non- cryptographic mechanism, to determine whether one indeed wishes to communicate with the purported originator of the received message (the so-called 'source address filtering'). 4. Trust management mechanisms. These schemes handle initial bootstrapping of the device (e.g., at manufacturing or personalization), management of device roles and corresponding authorizations, key management, including regular 'aliveness' checks of devices, checks on validity of keying material in the data key repository, security events, and security exception handling. 4.1. Technical Discussion In what follows, we briefly discuss the following aspects of the security design: security policy and trust model (Section 4.1.1), configuration and installation (Section 4.1.2), and key identification and key usage (Section 4.1.3). 4.1.1. Security Policy and Trust Model The main objectives of network security are to provide for infrastructure security and application security. Infrastructure security deals with controlling admission to networks. The objective here is to restrict access to scarce network resources to authorized resources only, such as to ensure proper bandwidth allocation, protection of commands (such as those regulating network membership and exchange of status information), and, e.g., power drain savings. Application security deals with controlling access to actual information. The objective here is to restrict access to information shared between members of a group of network devices to precisely these group members, such as to prevent external parties from learning the contents of exchanged messages and from modifying message traffic or injecting their own messages in an undetected way. Struik Expires April 21, 2010 [Page 12] Internet-Draft Security Considerations October 19, 2009 Infrastructure security and application security have different underlying trust requirements. With infrastructure security, the network owner may have an interest in restricting access to his network to privileged devices only, based on specific criteria, such as device subscription to the network or charging for airtime/bandwidth, whereas network devices might not care who the actual network coordinator is, as long as access to bandwidth is satisfactory. With application security, devices that exchange information may have a vested interest in keeping their communications private, also from the network owner. Both types of security involve the management of groups of devices, either for controlling network membership (by a network coordinator) or for restricting access to information to specific groups (by a security manager). Separation of the role of network coordinator and that of security manager allows charging models that differentiate between airtime/bandwidth cost & content/subscription cost. These charging models might be operated by different entities. Managing security and trust relationships comes down to the management of groups of devices that may gain access to information, no matter whether this is administered by a network coordinator or a security manager. In particular, this leads to the following security invariant and security policy: o Security Invariant: At any given moment of time, access to information shared between members of a group is restricted to precisely these group members. o Security Rule: Changes to the group structure shall invoke a change of keys. The main challenge is how this security policy should be enforced throughout the lifetime of the system. Conceptually, at any given moment in time, the security manager must provide each device in the group it secures with complete and authentic information on the current composition of the membership and each device must regularly check that its security manager is still 'alive'. In reality, this check cannot be performed real-time, but has to be performed at regular time intervals. Thus, trade-offs between security overhead and granularity of security guarantees are to be made. The design is based on a detailed security model, involving the identification of a plethora of device roles, such as network coordinator, security manager, trust manager, configuration manager, ordinary device, and some corresponding meta-roles (devices that are Struik Expires April 21, 2010 [Page 13] Internet-Draft Security Considerations October 19, 2009 allowed to change or allocate device roles to another device). These roles are then to be mapped on devices. Using this model, it is possible to describe security events and their impact on system security and model both centralized trust (with one central node trusted by all network devices) and distributed trust (where each device decides for itself whom it trusts to assume specific roles). Main point is that the mapping between device roles and devices themselves can be determined by each individual device, rather than having roles and implied trust imposed from above. 4.1.2. Configuration and Installation Configuration and installation aims at putting the system into the proper initial, i.e., pre-operational state. This involves the distribution of information on which devices are supposed to communicate with which other device(s), or - - more generally - - which applications running on a device are supposed to communicate with which applications running on another device or other devices. From a security perspective, one would like to have the guarantee that devices are hooked up properly, such as to prevent scenarios, such as switches operating improper lamps, the motion detector from one's neighbour to set off the alarm of one self, and the installation of spy-ware devices. This configuration also involves the installation of keying material with thus defined groups, to bootstrap the security relationships prior to operational use. Re-configuration extends this scenario to events where one has to replace a device by another one or where roles change (e.g., change of network coordinator). Practical key initialization in ad-hoc networks is an unsolved problem to date, due to the fact that one may have to set up a trust relationship among devices that have never met before. Thus, devices may not have access to shared keys yet and, even if they would, this would only partially solve the initialization problem, since some human (non-cryptographic) decision element is required: consider the event where one would like to securely configure 2 devices taken at random out of a box with 100 such (indistinguishable) devices. There is no way these 2 devices can determine by themselves that these should communicate with each other, unless some human intervention or guidance is provided. For random networks the actual topology might not matter; for practical home and building control and industrial constellations, it does though. We found a secure, yet practical mechanism to solve this bootstrapping problem (details of which are outside scope of this document). Struik Expires April 21, 2010 [Page 14] Internet-Draft Security Considerations October 19, 2009 4.1.3. Key Identification and Key Usage Security management requires the initialization and maintenance of keying relationships with groups of network devices. Depending on the network topology and the group communications patterns, this might involve the handling and storage of a few or many keying relationships. Since the cost of sensor networks are quite sensitive to the amount of required RAM/ROM, the storage requirements for keying material and other security-relevant information could become a bottleneck. Hence, the need for techniques to limit storage requirements for security material. As case in point, consider secure network routing scenarios. Potentially, a node might have to communicate with each other individual node of the network. If it would have to maintain a separate key for each such peer-to-peer communication link, sheer key storage cost might make network security prohibitively expensive. One approach to limit key storage cost in this setting would be to use broadcast keys (network-wide keys) for peer-to-peer communications as well. This approach can be generalized towards allowing group keys to be re-used for communications among a proper subgroup hereof. Note, that this 'improper' key re-use relies on the assumption that one trusts each device within the larger group to turn a blind eye to communications in a subgroup of which it is not a member. Thus, security is only guaranteed against 'outsider attacks' and not against insiders from the group. The design is based on a refinement of these techniques to limit key storage cost, while avoiding our reasoning model on systems trust from falling apart. Here, again, implementing some real-life scenarios and estimating the implementation cost provided valuable guidance and allowed refining the key use model successively. 5. Conclusions We presented a general-purpose security design for multihop ad-hoc networks that (we believe) fits extremely constrained wireless environments, such as sensor networks, while remaining uniform and general enough to fit any wireless network. The design is tailored towards low overall implementation cost, supports semi-automatic lifecycle management, including ease of installation and configuration, scalability, survivability, mobility, and is adaptable towards network topology changes and towards different trust models underlying network operations. The security design uses well-studied and standardized cryptographic building blocks, such as the symmetric-key block cipher AES-128 and the elliptic curve (ECC) public-key technologies and careful trust models, thus showcasing Struik Expires April 21, 2010 [Page 15] Internet-Draft Security Considerations October 19, 2009 feasibility of a well-rounded security design that marries security functionality with ease-of-use for sensor and control applications - - the ultimate design challenge for embedded security design. 6. Future work As for now, the security architectural framework and design considerations do not pay great detail to communication stack layering. Moreover, assumptions and design considerations need to be validated with 6lowapp charter and may result in work emanating work that may find a home in different IETF groups. 7. Security Considerations This document reflects upon security assumptions and security and ease of use requirements underlying the described security architectural framework and design considerations presented. 8. IANA Considerations This document contains no request to IANA. 9. Acknowledgements 10. References 10.1. Normative References [1] ANSI X9.63-2001, Public Key Cryptography for the Financial Services Industry - Key Agreement and Key Transport Using Elliptic Curve Cryptography, American Bankers Association, November 20, 2001. Available from http://www.ansi.org. [2] FIPS Pub 186-2, Digital Signature Standard (DSS), Federal Information Processing Standards Publication 186-2, US Department of Commerce/National Institute of Standards and Technology, Gaithersburg, Maryland, USA, January 27, 2000. (Includes change notice, October 5, 2001.) [3] FIPS Pub 197, Advanced Encryption Standard (AES), Federal Information Processing Standards Publication 197, US Department of Commerce/N.I.S.T., Springfield, Virginia, November 26, 2001. Available from: http://csrc.nist.gov/. [4] Institute of Electrical and Electronics Engineers, Inc., IEEE Std. 802.15.4-2006, IEEE Standard for Information Technology - Struik Expires April 21, 2010 [Page 16] Internet-Draft Security Considerations October 19, 2009 Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks - Specific Requirements - Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (WPANs), New York: IEEE Press, 2006. (Revision of IEEE Std 802.15.4-2006.) [5] NIST Pub 800-38C, Recommendation for Block Cipher Modes of Operation - The CCM Mode for Authentication and Confidentiality, NIST Special Publication 800-38C, US Department of Commerce/N.I.S.T., Springfield, Virginia, May 2004. Available from http://csrc.nist.gov/. [6] NIST Pub 800-56a, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, NIST Special Publication 800-56, US Department of Commerce/N.I.S.T., Springfield, Virginia, March 2006. Available from http://csrc.nist.gov/CryptoToolkit/kms/keyschemes-Jan03.pdf. [7] NIST Pub 800-57, Recommendation for Key Management - Part 1: General (Revised), NIST Special Publication 800-57, US Department of Commerce/N.I.S.T., Springfield, Virginia, May 2006. Available from http://csrc.nist.gov/encryption/kms/guideline-1.pdf. [8] NIST Pub 800-57, Key Management Guideline - Part 2: Best Practices for Key Management Organization, US Department of Commerce/N.I.S.T., Springfield, Virginia, May 2006. Available from http://csrc.nist.gov/encryption/kms/guideline-2.pdf. 10.2. Informative References [9] A. Antipa, D. Brown, A. Menezes, R. Struik, S. Vanstone, ''Validation of Elliptic Curve Public Keys,'' in Proceedings of Public Key Cryptography 2003 - PKC 2003, Y. G. Desmedt, Ed., Lecture Notes in Computer Science, Vol. 2567, pp. 211-223, Berlin: Springer, 2003. [10] A. Antipa, D.R. Brown, R. Gallant, R. Lambert, R. Struik, S.A. Vanstone, ''Accelerated Verification of ECDSA Signatures,'' in Proceedings of Selected Areas in Cryptography .SAC2005, B. Preneel, S. Tavares, Eds., Lecture Notes in Computer Science, Vol. 3897, pp. 307-318, New York: Springer, 2006. [11] D. Balfanz, D.K. Smetters, P. Stewart, H.C. Wong, ''Talking to Strangers: Authentication in Ad-Hoc Wireless Networks,'' in Struik Expires April 21, 2010 [Page 17] Internet-Draft Security Considerations October 19, 2009 Proceedings of the 9th Annual Network and Distributed System Security Symposium (NDSS), 2002. [12] D. Balfanz, G. Durfee, R.E. Grinter, D.K. Smetters, P. Stewart, ''Network-in-a-Box: How to Set Up a Secure Wireless Network in under a Minute,'' in Proceedings of the 13th USENIX Security Symposium, August 9-13, 2004. [13] L. Batina, J. Guajardo, T. Kerins, N. Mentens, P. Tuyls, I. Verbauwhede, ''An Elliptic Curve Processor for RFID-Tags,'' International Association for Cryptologic Research, IACR ePrint 2006-227, 2006. [14] D.R.L. Brown, R. Gallant, S.A. Vanstone, ''Provably Secure Implicit Certificate Schemes,'' in Proceedings of Financial Cryptography 2001, P.F. Syverson, Ed., Lecture Notes in Computer Science, Vol. 2339, pp. 156-165, Berlin: Springer-Verlag, 2002. [15] For information on CABA, see www.caba.org. [16] E. Callaway, T.S. Messerges, J. Cukier, T.A.M. Kevenaar, L. Puhl, R. Struik, ''A Security Design for a General Purpose, Self- Organizing, Multihop Ad Hoc Wireless Network, in Proceedings of the 2003 ACM Workshop on Security of Adhoc and Sensor Networks (SASN), George Mason University, Fairfax, VA, October 31, 2003. [17] L.F. Cranor, S. Garfinkel, Eds., Security and Usability: Designing Secure Systems That People Can Use, Cambridge: O'Reilly, 2005. [18] J. Daemen, V. Rijmen, ''AES Proposal - The Rijndael Block Cipher,'' Document version 2, March 9, 1999. Available from http://csrc.nist.gov. [19] V. Gupta, M. Millard, S. Fung, Y. Zhu, N. Gura, H. Eberle, S.C. Shant, ''Sizzle: A Standards-based end-to-end Security Architecture for the Embedded Internet,'' in Proceedings of the Third IEEE International Conference on Pervasive Computing - PerCom 2005, 2005. [20] T. Hasegawa, J. Nakajima, M. Matsui, ''A Small and Fast Software Implementation of Elliptic Curve Cryptosystems over GF(p) on a 16- Bit Microcomputer,'' IEICE Trans.Fundamentals, vol. E82-A, No. 1, pp. 98-106, January 1999. [21] D.R. Hankerson, A.J. Menezes, S.A. Vanstone, Guide to Elliptic Curve Cryptography, New York: Springer, 2003. Struik Expires April 21, 2010 [Page 18] Internet-Draft Security Considerations October 19, 2009 [22] J.H. Hoekman, ''The Ephemeral Pairing Problem,'' in Proceedings of Financial Cryptography, February 9-12, Key West, FL, 2004. [23] P. Houghton, 'Low-Power, Location-Aware Radio Market,' IEEE 15-04- 0029-00-004a, January 13, 2004. [24] Q. Huang, J. Cukier, H. Kobayashi, B. Liu, J. Zhang, ''Fast Authenticated Key Agreement for Self-Organizing Sensor Networks,'' 2nd ACM International Workshop on Wireless Sensor Networks and Applications, WSNA 2003, September 19, 2003. [25] C. Karlof, D. Wagner, ''Secure Routing in Wireless Sensor Networks: Attacks and Countermeasures,'' in Proceedings of the First IEEE International Workshop on Sensor Network Protocols and Applications (SNPA), May 11, 2003. [26] C. Karlof, N. Sastry, D. Wagner, ''TinySec: A Link Layer Security Architecture for Wireless Sensor Networks,'' in Proceedings of the Second ACM Conference on Embedded Networked Sensor Systems - SenSys 2004, November 2004. [27] G. Keating, ''Performance Analysis of AES Candidates on the 6805 CPU Core,'' Public Comments on AES Candidate Algorithms - Round 1, Available from http://csrc.nist.gov/CryptoToolkit/aes/round1/comments/990415- gkeating.pdf. [28] S.S. Kumar, C. Paar, ''Are Standards Compliant Elliptic Curve Cryptosystems Feasible on RFID?,'' presented at the Workshop on RFID Security, July 2006. [29] L. Law, A.J. Menezes, M. Qu, J. Solinas, S.A. Vanstone, ''An Efficient Protocol for Authenticated Key Agreement,'' Technical Report CORR 1998-05, CACR, University of Waterloo, 1998. Available from http://www.cacr.math.uwaterloo.ca. [30] A.K. Lenstra, ''Unbelievable Security: Matching AES Security using Public Key Systems'', in Proceedings of Advances in Cryptology - ASIACRYPT 2001, Lecture Notes in Computer Science, Vol. 2248, pp. 67-86, December 9-13, 2001. [31] S. M. Matyas, C. H. Meyer, and J. Oseas, ''Generating Strong One-Way Functions with Cryptographic Algorithm,'' IBM Tech. Disclosure Bull., Vol. 27, No. 10A, pp. 5658-5659, 1985. [32] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of Applied Cryptography, Boca Raton: CRC Press, 1997. Struik Expires April 21, 2010 [Page 19] Internet-Draft Security Considerations October 19, 2009 [33] L.A. Pintsov, S.A. Vanstone, ''Postal Revenue Collection in the Digital Age,'' Technical Report CORR 2000-43, CACR, University of Waterloo, 2000. Available from http://www.cacr.math.uwaterloo.ca. [34] N. Sastry, U. Shankar, D. Wagner, ''Secure Verification of Location Claims,'' in Proceedings of ACM Workshop on Wireless Security, WiSe 2003, September 19, 2003. [35] F. Stajano, R. Anderson, ''The Resurrecting Duckling: Security Issues in Ad-Hoc Wireless networks,'' in Proceedings of the Seventh International Workshop on Security Protocols, B. Christianson, B. Crispo, J.A. Malcolm, and M. Roe, Eds., Lecture Notes in Computer Science, Vol. 1796, Berlin: Springer-Verlag, 1999. [36] F. Stajano, ''The Resurrecting Duckling: What Next?,'' in Proceedings of the Eighth International Workshop on Security Protocols, B. Crispo, M. Roe, and B. Criso, Eds., , Lecture Notes in Computer Science, Vol. 2133, Berlin: Springer-Verlag, April 2000. [37] U.S. Department of Energy, Industrial Wireless Technology for the 21st Century, December 2002. Available from http://www.oit.doe.gov/sens_cont/pdfs/wireless_technology.pdf [38] D. Wagner, ''Security for Sensor Networks: Cryptography and Beyond,'' in Proceedings of the 2003 ACM Workshop on Security of Adhoc and Sensor Networks (SASN), George Mason University, Fairfax, VA, October 31, 2003. [39] A.S. Wander, N. Gura, H. Eberle, V. Gupta, S.C. Shantz, ''Energy Analysis of Public-Key Cryptography for Wireless Sensor Networks,'' in Proceedings of the Third IEEE International Conference on Pervasive Computing - - PerCom 2005, 2005. [40] For information on the Wireless Industrial Networking Alliance, see http://www.wireless4industrial.org/. [41] ZigBee Alliance, 'ZigBee General MRD,' ZigBee document 03/143r0ZB, June 24, 2003. Struik Expires April 21, 2010 [Page 20] Internet-Draft Security Considerations October 19, 2009 Author's address: R. Struik Certicom Corp. 5520 Explorer Drive, 4th Floor Mississauga, ON Canada L4W 5L1 Phone: +1 (905) 501-6083 Email: rstruik@certicom.com Struik Expires April 21, 2010 [Page 21]