CoRE O. Garcia-Morchon
Internet-Draft S. Keoh
Intended status: Informational S. Kumar
Expires: September 8, 2011 Philips Research
R. Hummen
RWTH Aachen
R. Struik
Struik Consultancy
March 7, 2011
Security Considerations in the IP-based Internet of Things
draft-garcia-core-security-00
Abstract
A direct interpretation of the Internet of Things concept refers to
the usage of standard Internet protocols to allow for human-to-thing
or thing-to-thing communication. Although the security needs are
well-recognized, it is still not fully clear how existing IP-based
security protocols can be applied to this new setting. This
Internet-Draft first provides an overview of security architecture,
its deployment model and general security needs in the context of the
lifecycle of a thing. Then, it presents challenges and requirements
for the successful roll-out of new applications and usage of standard
IP-based security protocols when applied to get a functional Internet
of Things.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Garcia-Morchon, et al. Expires September 8, 2011 [Page 1]
Internet-Draft Security Considerations for the IoTs March 2011
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Conventions and Terminology Used in this Document . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Thing Lifecycle and Architectural Considerations . . . . . 4
3.1. Security Aspects . . . . . . . . . . . . . . . . . . . . . 5
4. State of the Art . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. IP-based Security Solutions . . . . . . . . . . . . . . . 8
4.2. Wireless Sensor Network Security and Beyond . . . . . . . 10
5. Challenges for a Secure Internet of Things . . . . . . . . . . 11
5.1. Constraints and Heterogeneous Communication . . . . . . . 11
5.1.1. Tight Resource Constraints . . . . . . . . . . . . . . 11
5.1.2. Denial-of-Service Resistance . . . . . . . . . . . . . 13
5.1.3. Protocol Translation and End-to-End Security . . . . . 13
5.2. Bootstrapping of a Security Domain . . . . . . . . . . . . 15
5.2.1. Distributed vs. Centralized Architecture and
Operation . . . . . . . . . . . . . . . . . . . . . . 15
5.2.2. Bootstrapping a thing's identity and keying
materials . . . . . . . . . . . . . . . . . . . . . . 16
5.2.3. Privacy-aware Identification . . . . . . . . . . . . . 17
5.3. Operation . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.1. End-to-End Security . . . . . . . . . . . . . . . . . 18
5.3.2. Group Membership and Security . . . . . . . . . . . . 18
5.3.3. Mobility and IP Network Dynamics . . . . . . . . . . . 19
6. Next Steps towards a Flexible and Secure Internet of Things . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
10. Normative References . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Garcia-Morchon, et al. Expires September 8, 2011 [Page 2]
Internet-Draft Security Considerations for the IoTs March 2011
1. Conventions and Terminology Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119].
2. Introduction
The Internet of Things (IoT) denotes the interconnection of highly
heterogeneous networked entities and networks following a number of
communication patterns such as: human-to-human (H2H), human-to-thing
(H2T), thing-to-thing (T2T), or thing-to-things (T2Ts). The term IoT
was first coined by the Auto-ID center [AUTO-ID] in 1999. Since
then, the development of the underlying concepts has ever increased
its pace. Nowadays, the IoT presents a strong focus of research with
various initiatives working on the (re)design, application, and usage
of standard Internet technology in the IoT.
The introduction of IPv6 and web services as fundamental building
blocks for IoT applications [ID-KIM] promises to bring a number of
basic advantages including: (i) a homogeneous protocol ecosystem that
allows simple integration with Internet hosts; (ii) simplified
development of very different appliances; (iii) an unified interface
for applications, removing the need for application-level proxies.
Such features greatly simplify the deployment of the envisioned
scenarios ranging from building automation to production environments
to personal area networks, in which very different things such as a
temperature sensor, a luminaire, or an RFID tag might interact with
each other, with a human carrying a smart phone, or with backend
services.
This Internet Draft presents an overview of the security aspects of
the envisioned all-IP architecture as well as of the lifecycle of an
IoT device, a thing, within this architecture. In particular, we
review the most pressing aspects and functionalities that are
required for a secure all-IP solution.
With this, this Internet-Draft pursues several goals. First, we aim
at presenting a comprehensive view of the interactions and
relationships between an IoT application and security. Second, we
aim at describing challenges for a secure IoTs in the specific
context of the lifecycle of a resource-constrained device. The final
goal of this draft is to discuss the next steps towards a secure
IoTs.
The rest of the Internet-Draft is organized as follows. Section 3
Garcia-Morchon, et al. Expires September 8, 2011 [Page 3]
Internet-Draft Security Considerations for the IoTs March 2011
depicts the lifecycle of a thing and gives general definitions for
the main security aspects within the IoT domain. In Section 4, we
review existing protocols and work done in the area of security for
wireless sensor networks. Section 5 identifies general challenges
and needs for an IoT security protocol design and discusses existing
protocols and protocol proposals against the identified requirements.
Section 6 summarizes concrete steps towards a secure Internet of
Things. Section 7 includes final remarks and conclusions.
3. The Thing Lifecycle and Architectural Considerations
We consider the installation of a Building Automation and Control
(BAC) system to illustrate the lifecycle of a thing in a BAC
scenario. A BAC system consists of a network of interconnected nodes
that perform various functions in the domains of HVAC (Heating,
Ventilating, and Air Conditioning), lighting, safety etc. The nodes
vary in functionality and a majority of them represent resource
constrained devices such as sensors and luminaries. Some devices may
also be battery operated or battery-less nodes, demanding for a focus
on low energy consumption and on sleeping devices.
In our example, the life of a thing starts when it is manufactured.
Due to the different application areas (i.e., HVAC, lighting, safety)
nodes are tailored to a specific task. It is therefore unlikely that
one single manufacturer will create all nodes in a building. Hence,
interoperability as well as trust bootstrapping between nodes of
different vendors is important. The thing is later installed and
commissioned within a network by an installer during the
bootstrapping phase. Specifically, the device identity and the
secret keys used during normal operation are provided to the device
during this phase. Different subcontractors may install different
IoT devices for different purposes. Furthermore, the installation
and bootstrapping procedures may not be a defined event but may
stretch over an extended period of time. After being bootstrapped,
the device and the system of things are in operational mode and run
the functions of the BAC system. During this operational phase, the
device is under the control of the system owner. For devices with
lifetimes spanning several years, occasional maintenance cycles may
be required. During each maintenance phase, the software on the
device can be upgraded or applications running on the device can be
reconfigured. The maintenance tasks can thereby be performed either
locally or from a backend system. Depending on the operational
changes of the device, it may be required to re-bootstrap at the end
of a maintenance cycle. The device continues to loop through the
operational phase and the eventual maintenance phase until the device
is decommissioned at the end of its lifecycle. However, the end-of-
life of a device does not necessarily mean that it is defective but
Garcia-Morchon, et al. Expires September 8, 2011 [Page 4]
Internet-Draft Security Considerations for the IoTs March 2011
rather denotes a need to replace and upgrade the network to next-
generation devices in order to provide additional functionality.
Therefore the device can be removed and re-commissioned to be used in
a different network under a different owner by starting the lifecycle
over again. Figure 1 shows the generic lifecycle of a thing. This
generic lifecycle is also applicable for IoT scenarios other than BAC
systems.
At present, BAC systems use legacy building control standards such as
BACNet [BACNET] or DALI [DALI] with independent networks for each
subsystem (HVAC, lighting, etc.). However, this separation of
functionality adds further complexity and costs to the configuration
and maintenance of the different networks within the same building.
As a result, more recent building control networks employ IP-based
standards allowing seamless control over the various nodes with a
single management system. While allowing for easier integration,
this shift towards IP-based standards results in new requirements
regarding the implementation of IP security protocols on constrained
devices and the bootstrapping of security keys for devices across
multiple manufacturers.
_Manufactured _SW update _Decommissioned
/ / /
| _Installed | _ Application | _Removed &
| / | / reconfigured | / replaced
| | _Commissioned | | | |
| | / | | | | _Reownership &
| | | _Application | | _Application | | / recommissioned
| | | / running | | / running | | |
| | | | | | | | | | \\
+##+##+###+#############+##+##+#############+##+##+##############>>>
\/ \______________/ \/ \_____________/ \___/ time //
/ / \ \ \
Bootstrapping / Maintenance & \ Maintenance &
/ re-bootstrapping \ re-bootstrapping
Operational Operational
The lifecycle of a thing in the Internet of Things.
Figure 1
3.1. Security Aspects
The term security subsumes a wide range of different concepts. In
the first place, it refers to the basic provision of security
services including confidentiality, authentication, integrity,
authorization, non-repudiation, and availability. These security
services can be implemented by means of different cryptographic
Garcia-Morchon, et al. Expires September 8, 2011 [Page 5]
Internet-Draft Security Considerations for the IoTs March 2011
mechanisms, such as block ciphers, hash functions, or signature
algorithms. For each of these mechanisms, a solid key management
infrastructure is fundamental to handling the required cryptographic
keys.
In the context of the IoT, however, the security must not only focus
on the required security services, but also how these are realized in
the overall system and how the security functionalities are executed.
To this end, we use the following terminology to analyze and classify
security aspects in the IoT:
1 The security architecture refers to the system elements involved
in the management of the security relationships between things
and the way these security interactions are handled (e.g.,
centralized or distributed) during the lifecycle of a thing.
2 The security model of a node describes how the security
parameters, processes, and applications are managed in a thing.
This includes aspects such as process separation, secure storage
of keying materials, etc.
3 Security bootstrapping denotes the process by which a thing
securely joins the IoT at a given location and point in time.
Bootstrapping includes the authentication and authorization of a
device as well as the transfer of security parameters allowing
for its trusted operation in a given network.
4 Network security describes the mechanisms applied within a
network to ensure trusted operation of the IoT. Specifically, it
prevents attackers from endangering or modifying the expected
operation of networked things. Network security can include a
number of mechanisms ranging from secure routing to data link
layer and network layer security.
5 Application security guarantees that only trusted instances of an
application running in the IoT can communicate with each other,
while illegitimate instances cannot interfere.
Garcia-Morchon, et al. Expires September 8, 2011 [Page 6]
Internet-Draft Security Considerations for the IoTs March 2011
..........................
: +-----------+:
: *+*>|Application|*****
: *| +-----------+: *
: *| +-----------+: *
: *|->| Transport |: *
: * _*| +-----------+: *
: *| | +-----------+: *
: *| |->| Network |: *
: *| | +-----------+: *
: *| | +-----------+: * *** Bootstrapping
: *| +->| L2 |: * ~~~ Application Security
: *| +-----------+: *
:+--------+ : *
:|Security| Configuration: *
:|Service | Entity : *
:+--------+ : *
:........................: *
*
......................... * .........................
:+--------+ : * : +--------+:
:|Security| Node B : * : Node A |Security|:
:|Service | : * : |Service |:
:+--------+ : * : +--------+:
: | +-----------+: * :+-----------+ |* :
: | +->|Application|: ****|Application|<*+* |* :
: | | +-----------+: :+-----------+ |* |* :
: | | +-----------+: :+-----------+ |* |* :
: | |->| Transport |~~~~~~~~~~~~~~~~~~~~~| Transport |<-|* |* :
: |__| +-----------+: ................. :+-----------+ |*_|* :
: | +-----------+: : +-----------+ : :+-----------+ | * :
: |->| Network |: : | Network | : :| Network |<-| :
: | +-----------+: : +-----------+ : :+-----------+ | :
: | +-----------+: : +-----------+ : :+-----------+ | :
: +->| L2 |: : | L2 | : :| L2 |<-+ :
: +-----------+: : +-----------+ : :+-----------+ :
:.......................: :...............: :.......................:
Overview of Security Mechanisms.
Figure 2
We now discuss an exemplary security architecture relying on a
configuration entity for the management of the system with regard to
the introduced security aspects (see Figure 2). Inspired by the
security framework for routing over low power and lossy network
[ID-Tsao], we show an example of security model and illustrates how
different security concepts and the lifecycle phases map to the
Internet communication stack. Assume a centralized architecture in
Garcia-Morchon, et al. Expires September 8, 2011 [Page 7]
Internet-Draft Security Considerations for the IoTs March 2011
which a configuration entity stores and manages the identities of the
things associated with the system along with their cryptographic
keys. During the bootstrapping phase, each thing executes the
bootstrapping protocol with the configuration entity, thus obtaining
the required device identities and the keying material. The security
service on a thing in turn stores the received keying material for
the network layer and application security mechanisms for secure
communication. Things can then securely communicate with each other
during their operational phase by means of the employed network and
application security mechanisms.
4. State of the Art
Nowadays, there exists a multitude of control protocols for the IoT.
For BAC systems, the ZigBee standard [ZB], BACNet [BACNET], or DALI
[DALI] play key roles. Recent trends, however, focus on an all-IP
approach for system control.
In this setting, a number of IETF working groups are designing new
protocols for resource constrained networks of smart things. The
6LoWPAN working group [WG-6LoWPAN] concentrates on the definition of
methods and protocols for the efficient transmission and adaptation
of IPv6 packets over IEEE 802.15.4 networks [RFC4944]. The CoRE
working group [WG-CoRE] provides a framework for resource-oriented
applications intended to run on constrained IP network (6LoWPAN).
One of its main tasks is the definition of a lightweight version of
the HTTP protocol, the Constrained Application Protocol (CoAP)
[ID-CoAP], that runs over UDP and enables efficient application-level
communication for things.
4.1. IP-based Security Solutions
In the context of the IP-based IoT solutions, consideration of TCP/IP
security protocols is important as these protocols are designed to
fit the IP network ideology and technology. While a wide range of
specialized as well as general-purpose key exchange and security
solutions exist for the Internet domain, we discuss a number of
protocols and procedures that have been recently discussed in the
context of the above working groups. The considered protocols are
IKEv2/IPsec [RFC5282], TLS/SSL [RFC5878], DTLS [RFC5238], HIP
[RFC5201][ID-Moskowitz], PANA [RFC5191], and EAP [RFC3748] in this
Internet-Draft. Application layer solutions such as SSH [RFC4251]
also exist, however, these are currently not considered. Figure 3
depicts the relationships between the discussed protocols in the
context of the security terminology introduced in Section 3.1.
Garcia-Morchon, et al. Expires September 8, 2011 [Page 8]
Internet-Draft Security Considerations for the IoTs March 2011
..........................
: +-----------+:
: *+*>|Application|***** *** Bootstrapping
: *| +-----------+: * ### Application Security
: *| +-----------+: * === Network security
: *|->| Transport |: *
: * _*| +-----------+: *
: *| | +-----------+: *
: *| |->| Network |: *--> -PANA/EAP
: *| | +-----------+: * -HIP
: *| | +-----------+: *
: *| +->| L2 |: * ## DTLS
: *| +-----------+: * ##
:+--------+ : *
:|Security| Configuration: * [] HIP,IKEv2
:|Service | Entity : * [] ESP/AH
:+--------+ : *
:........................: *
*
......................... * .........................
:+--------+ : * : +--------+:
:|Security| Node B : * : Node A |Security|:
:|Service | : * : |Service |:
:+--------+ : Secure * : +--------+:
: | +-----------+: routing * :+-----------+ |* :
: | +->|Application|: framework ******|Application|<*+* |* :
: | | +----##-----+: | :+----##-----+ |* |* :
: | | +----##-----+: | :+----##-----+ |* |* :
: | |->| Transport |#########|#############| Transport |<-|* |* :
: |__| +----[]-----+: ......|.......... :+----[]-----+ |*_|* :
: | +====[]=====+=====+===========+=====+====[]=====+ | * :
: |->|| Network |: : | Network | : :| Network ||<-| :
: | +|----------+: : +-----------+ : :+----------|+ | :
: | +|----------+: : +-----------+ : :+----------|+ | :
: +->|| L2 |: : | L2 | : :| L2 ||<-+ :
: +===========+=====+===========+=====+===========+ :
:.......................: :...............: :.......................:
Relationships between IP-based security protocols.
Figure 3
The Internet Key Exchange (IKEv2)/IPsec and the Host Identity
protocol (HIP) reside at or above the network layer in the OSI model.
Both protocols are able to perform an authenticated key exchange and
set up the IPsec transforms for secure payload delivery. Currently,
there are also ongoing efforts to create a HIP variant coined Diet
HIP [ID-HIP] that takes lossy low-power networks into account at the
authentication and key exchange level.
Garcia-Morchon, et al. Expires September 8, 2011 [Page 9]
Internet-Draft Security Considerations for the IoTs March 2011
Transport Layer Security (TLS) and its datagram-oriented variant DTLS
secure transport-layer connections. TLS provides security for TCP
and requires a reliable transport, while DTLS secures and uses
datagram-oriented protocols such as UDP. Both protocols are
intentionally kept similar and share the same ideology and cipher
suites.
The Extensible Authentication Protocol (EAP) is an authentication
framework supporting multiple authentication methods. EAP runs
directly over the data link layer and, thus, does not require the
deployment of IP. It supports duplicate detection and
retransmission, but does not allow for packet fragmentation. The
Protocol for Carrying Authentication for Network Access (PANA) is a
network-layer transport for EAP that enables network access
authentication between clients and the network infrastructure. In
EAP terms, PANA is a UDP-based EAP lower layer that runs between the
EAP peer and the EAP authenticator.
4.2. Wireless Sensor Network Security and Beyond
A variety of key agreement and privacy protection protocols that are
tailored to IoT scenarios have been introduced in the literature.
For instance, random key pre-distribution schemes [PROC-Chan] or more
centralized solutions, such as SPINS [JOURNAL-Perrig], have been
proposed for key establishment in wireless sensor networks. The
ZigBee standard [ZB] for sensor networks defines a security
architecture based on an online trust center that is in charge of
handling the security relationships within a ZigBee network.
Personal privacy in ubiquitous computing has been studied
extensively, e.g., in [THESIS-Langheinrich]. Due to resource
constraints and the specialization to meet specific requirements,
these solutions often implement a collapsed cross layer optimized
communication stack (e.g., without task-specific network layers and
layered packet headers). Consequently, they cannot directly be
adapted to the requirements of the Internet due to the nature of
their design.
Despite important steps done by, e.g., Gupta et al. [PROC-Gupta], to
show the feasibility of an end-to-end standard security architecture
for the embedded Internet, the Internet and the IoT domain still do
not fit together easily. This is mainly due to the fact that IoT
security solutions are often tailored to the specific scenario
requirements without considering interoperability with Internet
protocols. On the other hand, the direct use of existing Internet
security protocols in the IoT might lead to inefficient or insecure
operation as we show in our discussion below.
Garcia-Morchon, et al. Expires September 8, 2011 [Page 10]
Internet-Draft Security Considerations for the IoTs March 2011
5. Challenges for a Secure Internet of Things
In this section, we take a closer look at the various security
challenges in the operational and technical features of the IoT and
then discuss how existing Internet security protocols cope with these
technical and conceptual challenges through the lifecycle of a thing.
Table 1 summarizes which requirements need to be met in the lifecycle
phases as well as the considered protocols. The structure of this
section follows the structure of the table. This discussion should
neither be understood as a comprehensive evaluation of all protocols,
nor can it cover all possible aspects of IoT security. Yet, it aims
at showing concrete limitations of existing Internet security
protocols in some areas rather than giving an abstract discussion
about general properties of the protocols. In this regard, the
discussion handles issues that are most important from the authors'
perspectives.
5.1. Constraints and Heterogeneous Communication
Coupling resource constrained networks and the powerful Internet is a
challenge because the resulting heterogeneity of both networks
complicates protocol design and system operation. In the following
we briefly discuss the resource constraints of IoT devices and the
consequences for the use of Internet Protocols in the IoT domain.
5.1.1. Tight Resource Constraints
The IoT is a resource-constrained network that relies on lossy and
low-bandwidth channels for communication between small nodes,
regarding CPU, memory, and energy budget. These characteristics
directly impact the threats to and the design of security protocols
for the IoT domain. First, the use of small packets, e.g., IEEE
802.15.4 supports 127-byte sized packets at the physical layer, may
result in fragmentation of larger packets of security protocols.
This may open new attack vectors for state exhaustion DoS attacks,
which is especially tragic, e.g., if the fragmentation is caused by
large key exchange messages of security protocols. Moreover, packet
fragmentation commonly downgrades the overall system performance due
to fragment losses and the need for retransmissions. For instance,
fate-sharing packet flight as implemented by DTLS might aggravate the
resulting performance loss.
Garcia-Morchon, et al. Expires September 8, 2011 [Page 11]
Internet-Draft Security Considerations for the IoTs March 2011
+--------------------------------------------------------+
| Bootstrapping phase | Operational Phase |
+------------+--------------------------------------------------------+
| |Incremental deployment |End-to-End security |
|Requirements|Identity and key management |Mobility support |
| |Privacy-aware identification|Group membership management|
| |Group creation | |
+------------+--------------------------------------------------------+
| |IKEv2 |IKEv2/MOBIKE |
|Protocols |TLS/DTLS |TLS/DTLS |
| |HIP/Diet-HIP |HIP/Diet-HIP |
| |PANA/EAP | |
+---------------------------------------------------------------------+
Relationships between IP-based security protocols.
Figure 4
The size and number of messages should be minimized to reduce memory
requirements and optimize bandwidth usage. In this context, layered
approaches involving a number of protocols might lead to worse
performance in resource-constrained devices since they combine the
headers of the different protocols. In some settings, protocol
negotiation can increase the number of exchanged messages. To
improve performance during basic procedures such as, e.g.,
bootstrapping, it might be a good strategy to perform those
procedures at a lower layer. This involves le
Small CPUs and scarce memory limit the usage of resource-expensive
cryptoprimitives such as public-key cryptography as used in most
Internet security standards. This is especially true, if the basic
cryptoblocks need to be frequently used or the underlying application
demands a low delay.
Independently from the development in the IoT domain, all discussed
security protocols show efforts to reduce the cryptographic cost of
the required public-key-based key exchanges and signatures with
ECC[RFC5246][RFC5903][ID-Moskowitz][ID-HIP]. Moreover, all protocols
have been revised in the last years to enable crypto agility, making
cryptographic primitives interchangeable. Diet HIP takes the
reduction of the cryptographic load one step further by focusing on
cryptographic primitives that are to be expected to be enabled in
hardware on IEEE 802.15.4 compliant devices. For example, Diet HIP
does not require cryptographic hash functions but uses a CMAC [NIST]
based mechanism, which can directly use the AES hardware available in
standard sensor platforms. However, these improvements are only a
first step in reducing the computation and communication overhead of
Internet protocols. The question remains if other approaches can be
Garcia-Morchon, et al. Expires September 8, 2011 [Page 12]
Internet-Draft Security Considerations for the IoTs March 2011
applied to leverage key agreement in these heavily resource-
constrained environments.
A further fundamental need refers to the limited energy budget
available to IoT nodes. Careful protocol (re)design and usage is
required to reduce not only the energy consumption during normal
operation, but also under DoS attacks. Since the energy consumption
of IoT devices differs from other device classes, judgments on the
energy consumption of a particular protocol cannot be made without
tailor-made IoT implementations.
5.1.2. Denial-of-Service Resistance
The tight memory and processing constraints of things naturally
alleviate resource exhaustion attacks. Especially in unattended T2T
communication, such attacks are difficult to notice before the
service becomes unavailable (e.g., because of battery or memory
exhaustion). As a DoS countermeasure, DTLS, IKEv2, HIP, and Diet HIP
implement return routability checks based on a cookie mechanism to
delay the establishment of state at the responding host until the
address of the initiating host is verified. The effectiveness of
these defenses strongly depends on the routing topology of the
network. Return routability checks are particularly effective if
hosts cannot receive packets addressed to other hosts and if IP
addresses present meaningful information as is the case in today's
Internet. However, they are less effective in broadcast media or
when attackers can influence the routing and addressing of hosts
(e.g., if hosts contribute to the routing infrastructure in ad-hoc
networks and meshes).
In addition, HIP implements a puzzle mechanism that can force the
initiator of a connection (and potential attacker) to solve
cryptographic puzzles with variable difficulties. Puzzle-based
defense mechanisms are less dependent on the network topology but
perform poorly if CPU resources in the network are heterogeneous
(e.g., if a powerful Internet host attacks a thing). Increasing the
puzzle difficulty under attack conditions can easily lead to
situations, where a powerful attacker can still solve the puzzle
while weak IoT clients cannot and are excluded from communicating
with the victim. Still, puzzle-based approaches are a viable option
for sheltering IoT devices against unintended overload caused by
misconfigured or malfunctioning things.
5.1.3. Protocol Translation and End-to-End Security
Even though 6LoWPAN and CoAP progress towards reducing the gap
between Internet protocols and the IoT, they do not target protocol
specifications that are identical to their Internet pendants due to
Garcia-Morchon, et al. Expires September 8, 2011 [Page 13]
Internet-Draft Security Considerations for the IoTs March 2011
performance reasons. Hence, more or less subtle differences between
IoT protocols and Internet protocols will remain. While these
differences can easily be bridged with protocol translators at
gateways, they become major obstacles if end-to-end security measures
between IoT devices and Internet hosts are used.
Cryptographic payload processing applies message authentication codes
or encryption to packets. These protection methods render the
protected parts of the packets immutable as rewriting is either not
possible because a) the relevant information is encrypted and
inaccessible to the gateway or b) rewriting integrity-protected parts
of the packet would invalidate the end-to-end integrity protection.
There are essentially four solutions for this problem:
1 Sharing symmetric keys with gateways enables gateways to
transform (e.g., de-compress, convert, etc.) packets and re-apply
the security measures after transformation. This method abandons
end-to-end security and is only applicable to simple scenarios
with a rudimentary security model.
2 Reusing the Internet wire format in the IoT makes conversion
between IoT and Internet protocols unnecessary. However, it
leads to poor performance because IoT specific optimizations
(e.g., stateful or stateless compression) are not possible.
3 Selectively protecting vital and immutable packet parts with a
MAC or with encryption requires a careful balance between
performance and security. Otherwise, this approach will either
result in poor performance (protect as much as possible) or poor
security (compress and transform as much as possible).
4 Message authentication codes that sustain transformation can be
realized by considering the order of transformation and
protection (e.g., by creating a signature before compression so
that the gateway can decompress the packet without recalculating
the signature). This enables IoT specific optimizations but is
more complex and may require application-specific transformations
before security is applied. Moreover, it cannot be used with
encrypted data because the lack of cleartext prevents gateways
from transforming packets.
To the best of our knowledge, none of the mentioned security
protocols provides a fully customizable solution in this problem
space. In fact, they usually offer an end-to-end secured connection.
An exception is the usage layered approach as might be PANA and EAP.
In such a case, this configuration (i) allows for a number of
configurations regarding the location of, e.g., the EAP authenticator
Garcia-Morchon, et al. Expires September 8, 2011 [Page 14]
Internet-Draft Security Considerations for the IoTs March 2011
and authentication server and (ii) the layered architecture might
allow for authentication at different places. The drawback of this
approach, however, lies in its high signaling traffic volume compared
to other approaches. Hence, future work is required to ensure
security, performance and interoperability between IoT and the
Internet.
5.2. Bootstrapping of a Security Domain
Creating a security domain from a set of previously unassociated IoT
devices is a key operation in the lifecycle of a thing and in the IoT
network. In this section, we discuss general forms of network
operation, how to communicate a thing's identity and the privacy
implications arising from the communication of this identity.
5.2.1. Distributed vs. Centralized Architecture and Operation
Most things might be required to support both centralized and
distributed operation patterns. Distributed thing-to-thing
communication might happen on demand, for instance, when two things
form an ad-hoc security domain to cooperatively fulfill a certain
task. Likewise, nodes may communicate with a backend service located
in the Internet without a central security manager. The same nodes
may also be part of a centralized architecture with a dedicated node
being responsible for the security management for group communication
between things in the IoT domain. In today's IoT, most common
architectures are fully centralized in the sense that all the
security relationships within a segment are handled by a central
party. In the ZigBee standard, this entity is the trust center.
Current proposals for 6LoWPAN/CoRE identify the 6LoWPAN Border Router
(6LBR) as such a device.
A centralized architecture allows for central management of devices
and keying materials as well as for the backup of cryptographic keys.
However, it also imposes some limitations. First, it represents a
single point of failure. This is a major drawback, e.g., when key
agreement between two devices requires online connectivity to the
central node. Second, it limits the possibility to create ad-hoc
security domains without dedicated security infrastructure.
Decentralized architectures, on the other hand, allow creating ad-hoc
security domains that might not require an online management entity
and are operative in a stand-alone manner. The ad-hoc security
domains can be added to a centralized architecture at a later point
in time, allowing for central or remote management.
Garcia-Morchon, et al. Expires September 8, 2011 [Page 15]
Internet-Draft Security Considerations for the IoTs March 2011
5.2.2. Bootstrapping a thing's identity and keying materials
Bootstrapping refers to the process by which a device is associated
to another one, to a network, or to a system. The way it is
performed depends upon the architecture: centralized or distributed.
In a distributed approach, a Diffie-Hellman type of handshake can
allow two peers to agree on a common secret. In general, IKEv2, HIP,
TLS, DTLS, can perform key exchanges and the setup of security
associations without online connections to a trust center. If we do
not consider the resource limitations of things, certificates and
certificate chains can be employed to securely communicate
capabilities in such a decentralized scenario. HIP and Diet HIP do
not directly use certificates for identifying a host, however
certificate handling capabilities exist for HIP and the same protocol
logic could be used for Diet HIP. It is noteworthy, that Diet HIP
does not require a host to implement cryptographic hashes. Hence,
some lightweight implementations of Diet HIP might not be able to
verify certificates unless a hash function is implemented by the
host.
In a centralized architecture, preconfigured keys or certificates
held by a thing can be used for the distribution of operational keys
in a given security domain. A current proposal [ID-O'Flynn] refers
to the use of PANA for the transport of EAP messages between the PANA
client (the joining thing) and the PANA Authentication Agent (PAA),
the 6LBR. EAP is thereby used to authenticate the identity of the
joining thing. After the successful authentication, the PANA PAA
provides the joining thing with fresh network and security
parameters.
IKEv2, HIP, TLS, and DTLS could be applied as well for the transfer
of configuration parameters in a centralized scenario. While HIP's
cryptographic secret identifies the thing, the other protocols do not
represent primary identifiers but are used instead to bind other
identifiers such as the operation keys to the public-key identities.
In addition to the protocols, operational aspects during
bootstrapping are of key importance as well. Many other standard
Internet protocols assume that the identity of a host is either
available by using secondary services like certificate authorities or
secure name resolution (e.g., DNSsec) or can be provided over a side
channel (entering passwords via screen and keyboard). While these
assumptions may hold in traditional networks, intermittent
connectivity, localized communication, and lack of input methods
complicate the situation for the IoT.
The order in which the things within a security domain are
Garcia-Morchon, et al. Expires September 8, 2011 [Page 16]
Internet-Draft Security Considerations for the IoTs March 2011
bootstrapped plays an important role as well. In [ID-Duffy], the
PANA relay element is introduced, relaying PANA messages between a
PaC (joining thing) and PAA of a segment [ID-O'Flynn]. This approach
forces commissioning based on distance to PAA, i.e., things can only
be bootstrapped hop-by-hop starting from those closer to the PAA, all
things that are 1-hop away are bootstrapped first, followed by those
that are 2-hop away, and so on. Such an approach might impose
important limitations on actual use cases in which, e.g., an
installer without technical background has to roll-out the system.
5.2.3. Privacy-aware Identification
During the last years, the introduction of RFID tags has raised
privacy concerns because anyone might access and track tags. As the
IoT involves not only passive devices, but also includes active and
sensing devices, the IoT might irrupt even deeper in people's privacy
spheres. Thus, IoT protocols should be designed to avoid these
privacy threats during bootstrapping and operation where deemed
necessary. In H2T and T2T interactions, privacy-aware identifiers
might be used to prevent unauthorized user tracking. Similarly,
authentication can be used to prove membership of a group without
revealing unnecessary individual information.
TLS and DTLS provide the option of only authenticating the responding
host. This way, the initiating host can stay anonymous. If
authentication for the initiating host is required as well, either
public-key certificates or authentication via the established
encrypted payload channel can be employed. Such a setup allows to
only reveal the responder's identity to possible eavesdroppers.
HIP and IKEv2 use public-key identities to authenticate the initiator
of a connection. These identities could easily be traced if no
additional protection were in place. IKEv2 transmits this
information in an encrypted packet. Likewise, HIP provides the
option to keep the identity of the initiator secret from
eavesdroppers by encrypting it with the symmetric key generated
during the handshake. However, Diet HIP cannot provide a similar
feature because the identity of the initiator simultaneously serves
as static Diffie-Hellman key. Note that all discussed solutions
could use anonymous public-key identities that change for each
communication. However, such identity cycling may require a
considerable computational effort for generating new asymmetric key
pairs. In addition to the built-in privacy features of the here
discussed protocols, a large body of anonymity research for key
exchange protocols exists. However, the comparison of these
protocols and protocol extensions is out of scope for this work.
Garcia-Morchon, et al. Expires September 8, 2011 [Page 17]
Internet-Draft Security Considerations for the IoTs March 2011
5.3. Operation
After the bootstrapping phase, the system enters the operational
phase. During the operational phase, things can relate to the state
information created during the bootstrapping phase in order to
exchange information securely and in an authenticated fashion. In
this section, we discuss aspects of communication patterns and
network dynamics during this phase.
5.3.1. End-to-End Security
Providing end-to-end security is of great importance to address and
secure individual T2T or H2T communication within one IoT domain.
Moreover, end-to-end security associations are an important measure
to bridge the gap between the IoT and the Internet. IKEv2 and HIP,
TLS and DTLS provide end-to end security services including peer
entity authentication, end-to-end encryption and integrity protection
above the network layer and the transport layer respectively. Once
bootstrapped, these functions can be carried out without online
connections to third parties, making the protocols applicable for
decentralized use in the IoT. However, protocol translation by
intermediary nodes may invalidate end-to-end protection measures (see
Section 5.1).
5.3.2. Group Membership and Security
In addition to end-to-end security, group key negotiation is an
important security service for the T2Ts and Ts2T communication
patterns in the IoT as efficient local broadcast and multicast relies
on symmetric group keys.
All discussed protocols only cover unicast communication and
therefore do not focus on group-key establishment. However, the
Diffie-Hellman keys that are used in IKEv2 and HIP could be used for
group Diffie-Hellman key-negotiations. Conceptually, solutions that
provide secure group communication at the network layer (IPsec/IKEv2,
HIP/Diet HIP) may have an advantage regarding the cryptographic
overhead compared to application-focused security solutions (TLS/
DTLS). This is due to the fact that application-focused solutions
require cryptographic operations per group application, whereas
network layer approaches may allow to share secure group associations
between multiple applications (e.g., for neighbor discovery and
routing or service discovery). Hence, implementing shared features
lower in the communication stack can avoid redundant security
measures.
A number of group key solutions have been developed in the context of
the IETF working group MSEC in the context of the MIKEY architecture
Garcia-Morchon, et al. Expires September 8, 2011 [Page 18]
Internet-Draft Security Considerations for the IoTs March 2011
[WG-MSEC][RFC4738]. These are specifically tailored for multicast
and group broadcast applications in the Internet and should also be
considered as candidate solutions for group key agreement in the IoT.
The MIKEY architecture describes a coordinator entity that
disseminates symmetric keys over pair-wise end-to-end secured
channels. However, such a centralized approach may not be applicable
in a distributed environment, where the choice of one or several
coordinators and the management of the group key is not trivial.
5.3.3. Mobility and IP Network Dynamics
It is expected that many things (e.g., wearable sensors, and user
devices) will be mobile in the sense that they are attached to
different networks during the lifetime of a security association.
Built-in mobility signaling can greatly reduce the overhead of the
cryptographic protocols because unnecessary and costly re-
establishments of the session (possibly including handshake and key
agreement) can be avoided. IKEv2 supports host mobility with the
MOBIKE [RFC4555][RFC4621] extension. MOBIKE refrains from applying
heavyweight cryptographic extensions for mobility. However, MOBIKE
mandates the use of IPsec tunnel mode which requires to transmit an
additional IP header in each packet. This additional overhead could
be alleviated by using header compression methods or the Bound End-
to-End Tunnel (BEET) mode [ID-Nikander], a hybrid of tunnel and
transport mode with smaller packet headers.
HIP offers a simple yet effective mobility management by allowing
hosts to signal changes to their associations [RFC5206]. However,
slight adjustments might be necessary to reduce the cryptographic
costs, for example, by making the public-key signatures in the
mobility messages optional. Diet HIP does not define mobility yet
but it is sufficiently similar to HIP to employ the same mechanisms.
TLS and DTLS do not have standards for mobility support, however,
work on DTLS mobility exists in the form of an Internet draft
[ID-Williams]. The specific need for IP-layer mobility mainly
depends on the scenario in which nodes operate. In many cases,
mobility support by means of a mobile gateway may suffice to enable
mobile IoT networks, such as body sensor networks. However, if
individual things change their point of network attachment while
communicating, mobility support may gain importance.
6. Next Steps towards a Flexible and Secure Internet of Things
Based on the discussions on the lifecycle of a thing and the existing
challenges for the Internet of Things, it is important to define
specific steps towards a feasibly secure IoTs, with special emphasis
on the security protocols. However, it is noteworthy that this goes
Garcia-Morchon, et al. Expires September 8, 2011 [Page 19]
Internet-Draft Security Considerations for the IoTs March 2011
beyond the protection of a specific protocol such as CoAP or any
particular protocol that will be used. The aim is to put together
different security aspects of IoT, making clear how the operational,
architectural, and technical aspects impact the protocol design and
choices. Next, we list the most important topics towards achieving
this goal.
1 Performance assessment of the existing IP-security protocols on
resource constrained devices. From the best of our knowledge,
the implementation feasibility of existing protocols on
constrained devices (e.g., 8-bit CPU and limited RAM budget) has
not been fully assessed so far. Their performance should be
analyzed in terms of CPU and communication overhead, energy
consumption, and memory requirements for a better understanding
of the impact of security on the rest of the protocols and
systems. By having a number of standard node platforms as the
reference for performance benchmarking, this would serve as a
good basis for designing a suitable security architecture for
IoT.
2 Definition of a flexible architecture matching the different
operational scenarios during the lifecycle of a thing. In
addition to a centralized architecture, devices can be paired
together initially without the need for a trusted third party to
create ad-hoc security domains comprising a number of nodes.
These ad-hoc security domains should be able to be added later to
the Internet when a central node is available. Thus, the IoT can
transparently and effortlessly move from an ad-hoc security
domain to a centrally-managed security domain and the other way
around.
3 Definition of a minimal and standard security suite (protocols
and keying materials) reusable for different phases in the
lifecycle of a thing and across layers ensuring system
interoperability. The link layer, the network layer, as well as
the application layer have distinct security requirements and
communication patterns. For small devices, resource limitations
make it challenging to secure all layers individually. Securing
only the application layer leaves the network open to attacks,
while security focused only at the network and link layer might
introduce possible inter-application security threats. Hence,
the limited resources of things may require sharing of keying
material and common security mechanisms between layers. It is
required that the data format of the keying material is
standardized to facilitate this. Such cross layer concepts
should be considered for an IoT-driven redesign of Internet
security protocols.
Garcia-Morchon, et al. Expires September 8, 2011 [Page 20]
Internet-Draft Security Considerations for the IoTs March 2011
4 Definition of a standard lightweight bootstrapping protocol for
commissioning of devices. A key challenge for secure
bootstrapping of a device in a centralized architecture is that
it is currently not feasible to commission a device when the
adjacent devices have not been commissioned yet. On the other
hand, such a standard bootstrapping protocol must also allow for
commissioning of devices from different manufacturers in both
centralized and ad-hoc scenarios. The bootstrapping protocol
should be reusable and lightweight to fit into small devices.
5 Definition of protocols with low fragmentation needs and
protection against DoS attacks. Many standard Internet protocols
have been designed for relatively big MTUs. For instance, EAP
assumes a minimum MTU in lower layers of 1020 B. However, IEEE
802.15.4 networks have physical packets of 127 B. Long messages
in security handshakes and protocols should be avoided to
prevent: (i) attackers from launching DoS attacks; (ii) high
resource needs regarding bandwidth or code.
7. Security Considerations
This document reflects upon the requirements and challenges of the
security architectural framework for Internet of Things.
8. IANA Considerations
This document contains no request to IANA.
9. Acknowledgements
We gratefully acknowledge feedback and fruitful discussion with
Tobias Heer and Robert Moskowitz.
10. Normative References
[AUTO-ID] "AUTO-ID LABS", Web http://www.autoidlabs.org/, Sept 2010.
[BACNET] "BACnet", Web http://www.bacnet.org/, Feb 2011.
[DALI] "DALI", Web http://www.dalibydesign.us/dali.html,
Feb 2011.
[ID-CoAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
Garcia-Morchon, et al. Expires September 8, 2011 [Page 21]
Internet-Draft Security Considerations for the IoTs March 2011
draft-ietf-core-coap-04 (work in progress), Jan 2011.
[ID-Duffy]
Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA) Relay Element", draft-ohba-pana-relay-03
(work in progress), Nov 2010.
[ID-HIP] Moskowitz, R., "HIP Diet EXchange (DEX)",
draft-moskowitz-hip-rg-dex-02 (work in progress),
Jul 2010.
[ID-KIM] Kim, E., Kaspar, D., and J. Vasseur, "Design and
Application Spaces for 6LoWPANs",
draft-ietf-6lowpan-usecases-09 (work in progress),
January 2011.
[ID-Moskowitz]
Moskowitz, R., Jokela, P., Henderson, T., and T. Heer,
"Host Identity Protocol Version 2",
draft-ietf-hip-rfc5201-bis-03 (work in progress),
Oct 2010.
[ID-Nikander]
Nikander, P. and J. Melen, "A Bound End-to-End Tunnel
(BEET) mode for ESP", Internet
Draft draft-nikander-esp-beet-mode-09, Feb 2009.
[ID-O'Flynn]
O'Flynn, C., Sarikaya, B., Ohba, Y., Cao, Z., and R.
Cragie, "Security Bootstrapping of Resource-Constrained
Devices", draft-oflynn-core-bootstrapping-03 (work in
progress), Nov 2010.
[ID-Tsao] Tsao, T., Alexander, R., Dohler, M., Daza, V., and A.
Lozano, "A Security Framework for Routing over Low Power
and Lossy Networks", Internet
Draft draft-ietf-roll-security-framework-04, Jan 2011.
[ID-Williams]
Williams, M. and J. Barrett, "Mobile DTLS", Internet
Draft draft-barrett-mobile-dtls-00, Sept 2009.
[JOURNAL-Perrig]
Perrig, A., Szewczyk, R., Wen, V., Culler, D., and J.
Tygar, "SPINS: Security protocols for Sensor Networks",
Journal Wireless Networks, Sept 2002.
Garcia-Morchon, et al. Expires September 8, 2011 [Page 22]
Internet-Draft Security Considerations for the IoTs March 2011
[NIST] Dworkin, M., "NIST Specification Publication 800-38B",
2005.
[PROC-Chan]
Chan, H., Perrig, A., and D. Song, "Random Key
Predistribution Schemes for Sensor Networks",
Proceedings IEEE Symposium on Security and Privacy, 2003.
[PROC-Gupta]
Gupta, V., Wurm, M., Zhu, Y., Millard, M., Fung, S., Gura,
N., Eberle, H., and S. Shantz, "Sizzle: A Standards-based
End-to-End Security Architecture for the Embedded
Internet", Proceedings Pervasive Computing and
Communications (PerCom), 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, Jan 2006.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, Jun 2006.
[RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2
Mobility and Multihoming (MOBIKE) Protocol", RFC 4621,
Aug 2006.
[RFC4738] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 4738,
Aug 2004.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, Sept 2007.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, Apr 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Garcia-Morchon, et al. Expires September 8, 2011 [Page 23]
Internet-Draft Security Considerations for the IoTs March 2011
Host Mobility and Multi-homing with the Host Identity
Protocol", RFC 5206, Aug 2006.
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
the Datagram Congestion Control Protocol (DCCP)",
RFC 5238, May 2008.
[RFC5246] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 5246, May 2006.
[RFC5282] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 5282, Dec 2005.
[RFC5878] Kaufman, C., "The Transport Layer Security (TLS) Protocol
version 1.2", RFC 5878, Aug 2008.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups Modulo a
Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
June 2010.
[THESIS-Langheinrich]
Langheinrich, M., "Personal Privacy in Ubiquitous
Computing", PhD Thesis ETH Zurich, 2005.
[WG-6LoWPAN]
"IETF 6LoWPAN Working Group",
Web http://tools.ietf.org/wg/6lowpan/, Feb 2011.
[WG-CoRE] "IETF Constrained RESTful Environment (CoRE) Working
Group", Web https://datatracker.ietf.org/wg/core/charter/,
Feb 2011.
[WG-MSEC] "MSEC Working Group",
Web http://datatracker.ietf.org/wg/msec/.
[ZB] "ZigBee Alliance", Web http://www.zigbee.org/, Feb 2011.
Garcia-Morchon, et al. Expires September 8, 2011 [Page 24]
Internet-Draft Security Considerations for the IoTs March 2011
Authors' Addresses
Oscar Garcia-Morchon
Philips Research
High Tech Campus
Eindhoven, 5656 AA
The Netherlands
Email: oscar.garcia@philips.com
Sye Loong Keoh
Philips Research
High Tech Campus
Eindhoven, 5656 AA
The Netherlands
Email: sye.loong.keoh@philips.com
Sandeep S. Kumar
Philips Research
High Tech Campus
Eindhoven, 5656 AA
The Netherlands
Email: sandeep.kumar@philips.com
Rene Hummen
RWTH Aachen University
Templergraben 55
Aachen, 52056
Germany
Email: rene.hummen@cs.rwth-aachen.de
Rene Struik
Struik Security Consultancy
Toronto,
Canada
Email: rstruik.ext@gmail.com
Garcia-Morchon, et al. Expires September 8, 2011 [Page 25]