[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/