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]