A standard compliant security framework for Low-power and Lossy Networks
draft-piro-6tisch-security-issues-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | G. Piro, Gennaro Boggia , Luigi Alfredo Grieco | ||
| Last updated | 2013-12-14 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-piro-6tisch-security-issues-01
6TiSCH G. Piro
INTERNET-DRAFT (Politecnico di Bari)
Intended Status: Informational G. Boggia
Expires: June 17, 2014 (Politecnico di Bari)
L. A. Grieco
(Politecnico di Bari)
December 14, 2013
A standard compliant security framework for Low-power and Lossy Networks
draft-piro-6tisch-security-issues-01
Abstract
The aim of this Internet Draft is to define a standard compliant
security framework for Low-power and Lossy Networks, in order to
enable message encryption and authentication at the MAC layer. The
framework is fully compatible with both IEEE 802.15.4 and IEEE
802.15.4e standards and supports a wide range of security features to
network architectures developed within the 6TiSCH Working Group. In
particular, it defines different kinds of security configurations
and, for each of them, proposes lightweight mechanisms for the
setting-up of a secure IEEE 802.15.4 domain and the negotiation of
link keys among devices.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
G. Piro, et al Expires June 17, 2014 [Page 1]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
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 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Security in IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . 7
4 Definition of the secured domain . . . . . . . . . . . . . . . 9
5 Security Configurations . . . . . . . . . . . . . . . . . . . . 10
5.1 Minimum security requirements . . . . . . . . . . . . . . . 11
6 Initialization of a secured domain in a 6TiSCH network . . . . 13
6.1 Setting-up phase . . . . . . . . . . . . . . . . . . . . . 14
6.1.1 The role of the MasterKey . . . . . . . . . . . . . . . 15
6.1.2 The role of the GlobalSecurityLevelsTable . . . . . . . 16
6.1.3 The role of the PrimeNumbersTable . . . . . . . . . . . 16
6.1.4 The role of the public key of the authority . . . . . . 17
6.2 Bootstrap phase . . . . . . . . . . . . . . . . . . . . . . 17
6.2.1 Bootstrap phase for the PAN coordinator . . . . . . . . 17
6.2.2 Bootstrap phase for a mote in a Beacon-enabled
network . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2.3 Bootstrap phase for a mote in a not-Beacon-enabled
network . . . . . . . . . . . . . . . . . . . . . . . . 23
6.3 Key Negotiation Phase . . . . . . . . . . . . . . . . . . . 25
6.3.1 The new command MAC frame . . . . . . . . . . . . . . . 26
6.3.2 New 6top commands . . . . . . . . . . . . . . . . . . . 28
6.3.3 KMP implementation when the anonymous DH scheme is
used . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3.4 KMP implementation when the certified DH scheme is
used . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.3.5 Generation of the LinkKey . . . . . . . . . . . . . . . 40
6.3.6 Update of MAC security attributes for the PAN
coordinator after the generation of the LinkKey . . . . 40
6.3.7 Update of MAC security attributes for the remote mote
G. Piro, et al Expires June 17, 2014 [Page 2]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
after the generation of the LinkKey . . . . . . . . . . 41
7 Additional features . . . . . . . . . . . . . . . . . . . . . . 42
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 43
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 43
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.1 Normative References . . . . . . . . . . . . . . . . . . . 43
10.2 Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. DH protocol . . . . . . . . . . . . . . . . . . . . . 45
A.1 Security considerations about the DH protocol . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
G. Piro, et al Expires June 17, 2014 [Page 3]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
1 Acronyms
In addition to the acronyms defined in [I-D.palattella-6tisch-
terminology], the following acronyms are used in this document:
DH Diffie Hellman
DEX Diet EXchange
DTLS Datagram Transport Layer
HIP Host Identity Protocol
PKI Public Key Infrastructure
2 Introduction
The IEEE 802.15.4 standard [IEEE802154] is widely recognized as one
of the most successful enabling technologies for short-range low-rate
wireless communications. It covers all the details related to the
Medium Access Control (MAC) and physical layers of the protocol stack
and supports the possibility to protect MAC packets by means of
symmetric-key cryptography techniques with several security options.
However, the IEEE 802.15.4 standard does not explain how handling the
initialization of a secure IEEE 802.15.4 domain, the generation and
the exchange of keys, and the management of joining operations in a
secure 802.15.4 network already configured in the past, thus
delegating the upper layers to orchestrate, enable, configure, and
negotiate security services.
The IEEE 802.15.4e [IEEE802154e] standard introduces some amendments
to the IEEE 802.15.4 standard. Among its key features there is the
Time-slotted Channel Hopping (TSCH), i.e., a novel MAC protocol,
which better supports multi-hop communications in emerging industrial
applications.
Since the IEEE 802.15.4e amendment focuses only on link-layer
aspects, the 6TiSCH WG was born to define open standards in support
of the adoption of IPv6 over the TSCH mode of the IEEE802.15.4e
standard, thus covering all facets related to the management of
network communications in complex (and eventually distributed) Low-
Power and Lossy Networks (LLNs) [I-D.watteyne-6tisch-tsch] [I-D.wang-
6tisch-6top].
G. Piro, et al Expires June 17, 2014 [Page 4]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
Security aspects represent an important issue that need to be
considered in a 6TiSCH network. TSCH defines mechanisms to encrypt
and authenticate MAC frames but it does not define how this keying
material is generated [IEEE802154]. For this reason, the 6TiSCH WG
needs to (i) define the keying material and authentication mechanism
needed by a new mote to join an existing network; (ii) define a
mechanism to allow for the secure transfer of application data
between neighbor motes; and (iii) define a mechanism to allow for the
secure transfer of signaling data between motes and 6TiSCH [I-
D.watteyne-6tisch-tsch].
In literature, several security strategies have been proposed for
wireless sensor networks. Most of them exploits key negotiation
algorithms and key management architectures summarized in
[Camtepe2005], [Wang2006], and [Cayirci2007]. However, all of these
works focus on a specific issue without embracing all the security
features presented in [I-D.watteyne-6tisch-tsch].
Definitively, despite the high number of solutions focusing on
security issues for LLNs, there is the lack of a complete and
effective framework enabling security services in 6TiSCH compliant
networks. Hence, the design of a one-size-fits-all solution is still
an ambitious goal for researchers working in this area.
A first step in this direction has been moved by ZigBee IP
specifications, i.e., a suite of high level communication protocols
sitting on top of the IEEE 802.15.4 MAC [ZIGBEEIP]. ZigBee IP
supports end-to-end and link-layer security and a public key
infrastructure based on X.509 certificates. It imposes the adoption
of the same link-key (shared among all nodes) to protect packets
belonging to any kind of services (i.e., only a single security level
is allowed). This makes the network highly sensible to the presence
of compromised devices. Moreover, the cost needed to update the key
in all devices increases with the size of the network. Finally,
ZigBee does not support TSCH at the MAC layer. According to that
considerations, the security architecture defined in ZigBee IP is not
well suitable for 6TiSCH environments.
In the IEFT area, there are three main proposals on this topic: [I-
D.garcia-core-security], [I-D.roll-security-framework], and [I-
D.ohba-6tisch-security]. In [I-D.garcia-core-security] a set of
security profiles in different network environments (e.g., network
without security requirements, home, managed home, industrial, and
advanced industrial) have been presented. For each of them, a number
of security threats, as well as a list of well-known protocols and
algorithms able to fixing these issues, have been also identified. In
[I-D.roll-security-framework] is presented an accurate analysis on
security threats at different point of the proto of a LLN, together
G. Piro, et al Expires June 17, 2014 [Page 5]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
with the presentation of possible countermeasures to these dangers.
In [I-D.ohba-6tisch-security] is presented a secure and scalable key
management framework to adopt in 6TiSCH networks, as well as a set of
requirements that a key management protocols should satisfy in that
framework. All these IETF's proposals does not focus the attention on
the design of a specific Key Management Protocol (KMP) for LLNs.
Indeed, they relay on well-known approaches (i.e., like PANA
[RFC5191], HIP DEX [HIPDEX], DTLS [RFC6347]) and to solutions based
on the adoption of Public Key Infrastructure (PKI) to manage both
node authentication and key negotiation procedures.
Nodes in a LLN have very limited storage, energy, and computational
capabilities. For example, the LPC platform, which is the most
powerful among those described in [Watteyne2012], have just 64 KB
RAM, 512 KB program flash memory, and a 120 MHz ARM Cortex M3 micro-
controller. Cryptography operations conducted for a single data
packet generate, per se, a not neglectable computational overhead and
energy consumption [Altolini2013]. On the other hand, the
implementation and the management of complex security protocols (such
as PAN, HIP DEX, and DTLS) and PKI infrastructure could not be
suitable in LLNs because of the generation of a very large amount of
signaling messages and the need for additional (and massive)
computational loads and energy consumptions [Riaz2009]. Hence, all
the available proposals cannot be easily applied in the 6TiSCH
context: the design of simpler solutions, able to cover all the
security aspects highlighted in [I-D.watteyne-6tisch-tsch] and able
to be fully compatible with IEEE 802.15.4 and IEEE 802.15.4e
specifications, is still an uncovered task.
The aim of this Internet Draft is to design a complete, simple, and
standard compliant framework supporting a number of security features
for the TSCH MAC layer. This work is complementary with respect to
[I-D.ohba-6tisch-security] and, at the same time, it is fully
integrated within the whole 6TiSCH architecture. Moreover, is has
been designed in order to ensure an easy and effective implementation
on real devices.
The main goals of this proposal have been summarized in the sequel:
- identify potential security configurations that could be
supported by a 6TiSCH network;
- define a framework covering all the security issues (i.e.,
confidentiality and integrity protection, mote bootstrap, key
negotiation and maintenance) presented in [I-D.watteyne-6tisch-
tsch];
- propose an efficient mechanism, handled by the 6top adaptation
layer, to configure a secured 6TiSCH network;
G. Piro, et al Expires June 17, 2014 [Page 6]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
- propose a lightweight KMP to generate link keys that will be
used to protect, at the MAC layer, unicast communications;
- explain the interaction between 6top and TSCH MAC layer during
the configuration of the secured 6TiSCH network.
3 Security in IEEE 802.15.4
This section summarizes security features defined within the standard
[IEEE802154], thus simplifying the comprehension of the remaining part
of this Internet Draft.
The IEEE 802.15.4 standard defines eight security levels to protect MAC
frames, as summarized in Fig. 1. The standard imposes the adoption of
the CCM* algorithm to perform encryption and description procedures. It
requires a key of 128 bit.
+----------+-------------+-----------+----------------+
| Security | Security | Data | Data |
| level | attribute | Integrity | Confidentiality|
+----------+-------------+-----------+----------------+
| 0 | None | No | No |
+----------+-------------+-----------+----------------+
| 1 | MIC-32 | Yes | No |
+----------+-------------+-----------+----------------+
| 2 | MIC-64 | Yes | No |
+----------+-------------+-----------+----------------+
| 3 | MIC-128 | Yes | No |
+----------+-------------+-----------+----------------+
| 4 | ENC | No | Yes |
+----------+-------------+-----------+----------------+
| 5 | ENC-MIC-32 | Yes | Yes |
+----------+-------------+-----------+----------------+
| 6 | ENC-MIC-64 | Yes | Yes |
+----------+-------------+-----------+----------------+
| 7 | ENC-MIC-128 | Yes | Yes |
+----------+-------------+-----------+----------------+
Figure 1. Security levels available for a IEEE 802.15.4 network.
At the MAC layer, encryption and decryption functionalities are
implemented within the "outgoing frame security" and the "incoming frame
security" procedures, respectively. They exploits a number of security
attributes, summarized in what follows:
- macKeyTable: it is composed by a set of KeyDescriptor elements.
G. Piro, et al Expires June 17, 2014 [Page 7]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
A specific KeyDescriptor element is created for each key, composed
by (see Tab. 61 of the IEEE 802.15.4 standard for more details
[IEEE802154]):
- The KeyIdLookupList, which is a list of
KeyIdLookupDescriptor entries. A KeyIdLookupDescriptor is
composed by a set of parameters (see Tab. 65 of the IEEE
802.15.4 standard for more details [IEEE802154]), i.e.,
KeyIdMode, KeySource, KeyIndex, DeviceAddMode, DevicePANId,
and DeviceAddress, that are used to identify the key within
the macKeyTable.
- The DeviceDescriptorHandleList, which contains pointers to
DeviceDescriptor elements stored within the macDeviceTable.
It is used to identify which devices may use the key.
- The KeyUsageList, which is a list of KeyUsageDescriptor
elements. A KeyUsageDescriptor is composed by the FrameType
and the CommandFrameIdentifies fields that indicate the
frame type with which the considered key may be used (see
Tab. 62 of the IEEE 802.15.4 standard for more details
[IEEE802154]).
- The Key.
- macDeviceTable: it is composed by a set of DeviceDescriptor
elements, providing some information about remote devices which
the node can establish a secure communication with. A dedicated
DeviceDescriptor element is associated to each remote device. It
is composed by a number of fields, i.e., PANId, ShortAddress,
ExtAddress, FrameCounter, and Extemp, which collect information
related to a specific remote device (see Tab. 64 of the IEEE
802.15.4 standard for more details [IEEE802154]).
- macSecurityLevelTable: it is made by a set of
SecurityLevelDescriptor elements, which store details about the
security level required for each MAC frame type and subtype.
Fields belonging to the SecurityLevelDescriptor data structure
are: FrameType, ComamndFrameIdentifier, SecurityMinimum,
DeviceOverrideSecurityMinimum, and AllowedSecurityLevels (see Tab.
63 of the IEEE 802.15.4 standard for more details [IEEE802154]).
- macFrameCounter: it is an integer value storing the outgoing
frame counter for the considered device.
- macAutoRequestSecurityLevel: it is an integer value providing
the security level used for automatic data requests.
G. Piro, et al Expires June 17, 2014 [Page 8]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
- macAutoRequestKeyIdMode: it is an integer value indicating the
key identifier mode used for automatic data requests. It is not
valid if the macAutoRequestSecurityLevel attribute is set to 0x00.
- macAutoRequestKeySource: it represents a short or extended IEEE
802.15.4 MAC address, indicating the originator of the key used
for automatic data requests. This attribute is not valid if the
macAutoRequestKeyIdMode element is not valid or set to 0x00.
- macAutoRequestKeyIndex: it is an integer value storing the index
of the key used for automatic data requests. It is not valid if
the macAutoRequestKeyIdMode attribute is not valid or set to
0x00.
- macDefaultKeySource: it is the extended IEEE 802.15.4 MAC
address of the originator of the default key used for key
identifier mode 0x01.
During the outgoing security procedure, the high layer uses the
KeyIdMode parameter to select a specific key in the macKeyTable to be
used for protecting the MAC frame.
The KeyIdMode is set to 00, 01, 10, and 11 in the case the key can be
derived implicitly by both sender and the receiver and its is not
specified in the message, the key is determined explicitly by the
KeyIndex parameter stored into the MAC header and the
macDefaultKeySource, the key can be derived by considering KeyIndex and
KeySource fields stored into the MAC header (with KeySource representing
the short address of the device that has generated the key), and the key
can be derived by considering KeyIndex and KeySource fields stored into
the MAC header (with KeySource representing the IEEE extended address of
the device that has generated the key), respectively.
Both IEEE 802.15.4 and IEEE 802.15.4e standards do not provide any
guideline to create (and or negotiate) keys, as well as to configure the
aforementioned security MAC attributes.
4 Definition of the secured domain
In this document, the "secured domain" concept refers to the portion of
a 6TiSCH network where procedures and techniques described in this
proposal must be performed in order to configure and maintain secured
communications.
In a 6TiSCH network, nodes can be arranged in both peer-to-peer and star
G. Piro, et al Expires June 17, 2014 [Page 9]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
topologies. In general, they can be organized through a Direction
Oriented Directed Acyclic Graph (DODAG), which is initialized by the PAN
coordinator. From the beginning, the PAN coordinator is in charge of
generating initial advertising messages and handling joining procedures
of neighbors. During the construction of the DODAG, a mote can become a
reference node for its neighbors and, for this reason, it can handle the
generation of advertisement and the management of joining procedure
[PalattellaSurvey].
A cluster represents the portion of a 6TiSCH network where the
distribution of radio resources and the management of TSCH frames is
handled by a given mote, namely cluster head or coordinator.
A secured domain coincides with the cluster's concept.
This means that the secured framework presented in this draft is in
charge of configuring and managing security capabilities in each cluster
in a 6TiSCH network. It is hence highly scalable because its complexity
does not depend from the network size but only by the number of motes
forming a specific cluster.
Just to simplify the description of all the security procedures and
mechanisms, the rest of the document will focus the attention on a
6TiSCH network with only one cluster, which is composed by a PAN
coordinator and a number of remote motes.
5 Security Configurations
The following network configurations are defined to support different
security features within a 6TiSCH network.
- Fully Secured network: all the IEEE 802.15.4 devices forming the
network are configured to fully support security services. It
represents the most secured configuration: all packets,
independently from the message they carry, are encrypted and
authenticated. Nodes that do not support security capabilities (or
that are not in posses of all the information to joining the
network, such as key materials and encryption and decryption
algorithms) are not allowed to join the network.
- Unsecured network: security services are not supported. Even if
in possession of security capabilities, any pair of nodes is not
allowed to establish a secured communication. Differently for the
Fully Secured scheme, this is the lowest security level. Since the
data encryption, the message integrity, and the peer
authentication are not implemented, all the MAC frames are
G. Piro, et al Expires June 17, 2014 [Page 10]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
exchanged in clear. Hence, the setup and the maintaining of the
network are described by the standard and no further upgrades are
required.
- Partial Secured network: only the integrity of message is
supported.
- Hybrid Secured network: the network can be composed by
heterogeneous nodes that could or could not support security
features. As default, the network is created in an unsecured
manner. All the non-unicast control messages sent by the
coordinator should be transmitted in clear. In this way, in fact,
it is ensured that all the devices are able to read the content of
packets. A RFD node with security capabilities, that intends to
exchange encrypted and/or authenticated packets with the
coordinator, could negotiate a set of link key with its reference
FFD.
- Flexible Secured network: as default, the network is setup with
the Fully Secured configuration and all packets are encrypted and
authenticated. If there is at least one node that have not
security capabilities, the coordinator could decides to switch to
the Hybrid Secured configuration.
The implementation of each of these network configurations is fully
supported by the secured architecture devised within the IEEE 802.15.4
and the IEEE 802.15.4e standard [IEEE802154]. This means that the
proposal presented in this Internet Draft does not introduces any
changes to the standard but it just introduces techniques and procedures
able to accomplish those aspects that have been left opened by IEEE
specifications.
5.1 Minimum security requirements
The IEEE 802.15.4 standard imposes to specify, for each kind of MAC
packet, minimum security levels that should be guaranteed. These
restrictions must be detailed for each remote device.
To this end, SecurityMinimum, DeviceOverrideSecurityMinimum, and
AllowedSecurityLevels parameters are stored into the DeviceDescriptor
element (see Sec. 3) to define the minimum security level (i.e., one of
those reported in Fig.1), the possibility to override the minimum
security level (i.e., DeviceOverrideSecurityMinimum is just a boolean
flag), and the list of allowed security levels in the case the minimum
one could be overridden, respectively.
G. Piro, et al Expires June 17, 2014 [Page 11]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
With reference to secure network configurations presented in Sec. 3.1,
these parameters must be set as reported in Fig. 2.
+------------------------------------------------------------------+
| Attribute | Secured Network Configurations |
| |Unsecured| Fully | Partial | Hybrid |Flexible |
+----------------+---------+---------+---------+---------+---------+
| SecurityMinimum|0 | from 5 | from 1 | 0 | from 1 |
| | | to 7 | to 4 | | to 7 |
+----------------+---------+---------+---------+---------+---------+
| DeviceOverride-| FALSE | FALSE | FALSE | FALSE | TRUE |
| SecurityMinimum| | | | | |
+----------------+---------+---------+---------+---------+---------+
| AllowedSecuri- | 0 | from 5 | from 1 | from 0 | from 0 |
| tyLevelsvels | | to 7 | to 4 | to 7 | to 7 |
+----------------+---------+---------+---------+---------+---------+
Figure 2. Setting of security attributes of the DeviceDescriptor element
in each proposed secure network configuration.
The Unsecured network configuration does not support any security
features. Hence, both minimum and allowable security levels are set to 0
for all the MAC frames and the possibility to override such constraints
is disabled for all devices.
If the Fully Secured configuration is enabled, the minimum security
level must be chosen in the range [5,7], thus allowing the possibility
to support the encryption and the authentication of messages. The
manufacturer must set the default value to 7; it can be updated by the
network administrator. The minimum security level must not be overridden
by any devices and, as a consequence, the field AllowedSecurityLevels
should contain only one value, equal to the minimum security level.
If the Partial Secured configuration is enabled, the minimum security
level must be chosen in the range [1,4], thus allowing the possibility
to support the authentication of messages. The manufacturer must set the
default value to 4; it can be updated by the network administrator. The
minimum security level must not be overridden by any devices and, as a
consequence, the field AllowedSecurityLevels should contain only one
value, equal to the minimum security level.
If the Hybrid Secured configuration is enabled, the minimum security
level must be set to 0, thus supporting the joining of devices having
different security capabilities. All the security levels could be
allowed and the network administrator could decide to enable only a
subset of them according to the network design.
If the Flexible Secured configuration is enabled, the minimum security
level must be set to 1. The joining of nodes without (or with limited)
G. Piro, et al Expires June 17, 2014 [Page 12]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
security capabilities is permitted by setting the
DeviceOverrideSecurityMinimum variable to TRUE and by including lower
security levels in the list of AllowedSecurityLevels.
6 Initialization of a secured domain in a 6TiSCH network
The secured framework builds a secured domain (the definition of a
secured domain is provided in Sec. 4) through the execution of three
consecutive phases: Setting-up, Bootstrapping, and Key Negotiation (see
the framework architecture in Fig. 3.
The Setting-up Phase is used to store into the device all the secrets
required to initialize a secured domain. The Bootstrap Phase is used to
initialize the secured domain and to compute a key that will be adopted
to protect broadcast messages at the MAC layer. The Key Negotiation
Phase handles the KMP and it is used to negotiate the key between a
couple of nodes in a cluster.
These phases are not always mandatory for all the secured network
configurations listed in Sec. 5. In particular, when both Unsecured and
Partial Secured Configurations are used, it is not necessary to
implement none of aforementioned phases because there is not the need to
compute any key. On the contrary, the Fully Secured Configuration, and
as a consequence also the Flexible Secured Configuration, requires the
implementation of all the phases. For the Hybrid Secured Configuration,
instead, the Bootstrap Phase is not mandatory because broadcast messages
are always sent in clear.
The need to implement or not Setting-up, Bootstrap, and Key Negotiation
Phases in each envisaged secured configuration is highlighted in Fig. 4.
G. Piro, et al Expires June 17, 2014 [Page 13]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
+-----------------------+
| | Installation of
| Setting-up Phase | --> initial secretes
| | in each device
+-----------------------+
|
V
+-----------------------+
| | Initialization of the secured domain
| Bootstrap Phase | --> and computation of the key for
| | broadcast messages
+-----------------------+
|
V
+-----------------------+
| | Management of the KMP
| Key Negotiation Phase | --> and negotiation of
| | link keys
+-----------------------+
Figure 3. Summary of the proposed framework.
+------------------------------------------------------------------+
| Phase | Secured Network Configurations |
| |Unsecured| Fully | Partial | Hybrid |Flexible |
+----------------+---------+---------+---------+---------+---------+
| Setting-up | NO | YES | NO | YES | YES |
+----------------+---------+---------+---------+---------+---------+
| Bootstrap | NO | YES | NO | NO | YES |
+----------------+---------+---------+---------+---------+---------+
| Key Negotiation| NO | YES | NO | YES | YES |
+----------------+---------+---------+---------+---------+---------+
Figure 4. Implementation of Setting-up, Bootstrap, and Ken Negotiation
Phases for each envisaged secured configuration.
6.1 Setting-up phase
The setting-up phase is used to properly configure the device that will
join to a secured 6TiSCH networks. It consists in storing, within the
device, parameters and initial secrets (i.e., the masterKey), which will
be used by secure algorithms and procedure to setup the secure domain.
They include. (i) the MasterKey, (ii) the PrimeNumbersTable, (iii) the
GlobalSecurityLevelsTable, and (iv) the public key of a certification
authority.
This operation may be performed by the manufacturer or by the network
G. Piro, et al Expires June 17, 2014 [Page 14]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
administrator.
6.1.1 The role of the MasterKey
The MasterKey is an initial secret, which is shared among all the
motes.
The MasterKey is used to generate the DefaultKey that will be exploited
to to protect broadcast messages (such as the beacon frame) in a given
cluster.
A security approach based on preloaded key is widely adopted, especially
in the case motes need to compute a common secret without relaying on
preliminary negotiation steps [Camtepe2005], [Wang2006], [Cayirci2007].
This is the case of the Fully Secured Configuration. When this
configuration is enabled, in fact, all the packets, including the beacon
message, must be encrypted from the beginning. This means that any mote
that wants to join to the network must compute the key adopted to
protect the beacon message autonomously. Otherwise it will not be able
to complete the join process because it will not be able to correctly
extract information from the beacon message.
The MasterKey is not directly used to encrypt and decrypt broadcast
messages. Another key, i.e., the DefaultKey, is instead computed
starting from the MasterKey and other time-varying parameters
From one side, the MasterKey is unique for the whole 6TiSCH network and
it may potentially remain the same for the whole life of the network.
From another hand, each cluster will compute its specific the
DefaultKey, which may potentially have a limited life time.
By using a time-varying key, we improve the resilience of the network to
known-plaintext attack [StallingsSecurityBook], through which an
attacker computes a key starting from the knowledge of group of
clear/encrypted messages. In fact, even if an attacker will be able to
obtain, through cryptanalysis techniques, the DefaultKey, it will be
able to compromise only a specific cluster of the network and for a
limited amount of time.
A mote can be subjected to any kind of tamper attacks. Without any
further shrewdness, an attacker that may physically access to the mote
could extract the MasterKey, thus compromising the security of the whole
6TiSCH network. Hence, it is very important to ensure the protection to
that tampering attacks by using specific software-based and/or hardware-
based mechanisms [Walters07][Becher2006].
G. Piro, et al Expires June 17, 2014 [Page 15]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
6.1.2 The role of the GlobalSecurityLevelsTable
The GlobalSecurityLevelsTable, that has been reported in Fig. 5, is used
to store the minimum security level and the list of allowed security
levels that must be adopted for each kind of MAC frame and for each
security configuration defined in Sec. 5. The table reported in Fig. 5
does not consider ACK messages because they must not be protected (as
imposed by the IEEE 802.15.4 standard [IEEE802154]).
Both the minimum security level and the list of allowed security levels
must be chosen by the manufacturer or by the network administrator,
according to restrictions reported in Fig. 2.
+-------------+------------+---------------------------------------+
| Attribute | Frame Type | Secured Network Configurations |
| | | Fully | Partial | Hybrid |Flexible |
+-------------+------------+---------+---------+---------+---------+
| Security | Beacon | | | | |
| Minimum | | | | | |
+-------------+------------+---------+---------+---------+---------+
| Security | Data | | | | |
| Minimum | | | | | |
+-------------+------------+---------+---------+---------+---------+
| Security | Command MAC| | | | |
| Minimum | | | | | |
+-------------+------------+---------+---------+---------+---------+
| AllowedSe- | Beacon | | | | |
| curityLevels| | | | | |
+-------------+------------+---------+---------+---------+---------+
| AllowedSe- | Data | | | | |
| curityLevels| | | | | |
+-------------+------------+---------+---------+---------+---------+
| AllowedSe- | Command MAC| | | | |
| curityLevels| | | | | |
+-------------+------------+---------+---------+---------+---------+
Figure 5. Structure of the GlobalSecurityLevelsTable.
6.1.3 The role of the PrimeNumbersTable
The PrimeNumbersTable stores a set of N prime numbers and their
respective primitive roots, which are used during the Key Negotiation
Phase. Its implementation is reported in Fig. 6.
These prime numbers are not the keys to protect MAC frames but are just
numbers that will be exploited to generate keys according to the DH
algorithm [DH].
G. Piro, et al Expires June 17, 2014 [Page 16]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
+----------------+--------------+----------------+
| PrimeNumberId | Prime Number | Primitive Root |
+----------------+--------------+----------------+
| 1 | p1 | g1 |
+----------------+--------------+----------------+
| 2 | p2 | g2 |
+----------------+--------------+----------------+
: :
+----------------+--------------+----------------+
| N | pN | gN |
+----------------+--------------+----------------+
Figure 6. Structure of the PimeNumbersTable.
As described in Appendix A.1, the security level of the proposed
approach does not depend from the size of the PrimeNumbersTable but it
is only influenced by the length of each prime number.
6.1.4 The role of the public key of the authority
The Key Negotiation Phase exploits a KMP based on the DH algorithm. The
possibility to authenticate motes through public certificates is also
supported.
6.2 Bootstrap phase
The implementation of the Bootstrap Phase is different for both PAN
coordinator and remote mote. Moreover, for a remote mote, two different
procedure has been conceived for both the not-beacon-enabled and the
beacon-enabled networks.
6.2.1 Bootstrap phase for the PAN coordinator
A 6TiSCH network is initialized by a FFD node that will become the PAN
coordinator. As described in [IEEE802154], at the end of this phase the
PAN coordinator has chosen both the identification number for the PAN,
i.e., the PAN_ID, and the short MAC address of the IEEE 802.15.4
network, i.e., shortMACaddress.
Once such task has been finished, the 6top adaptation layer computes the
DefaultKey, D_k, and configures a set of security MAC attributes through
specific commands (they have been introduced in [I-D.wang-6tisch-6top]).
In particular, it executes the following operations:
G. Piro, et al Expires June 17, 2014 [Page 17]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
a) A CONFIGURE.security command is generated by the 6top layer and
sent to the MAC entity to initialize security attributes (as
discussed in [I-D.wang-6tisch-6top], in Sec. 2.4.9.1). The set of
parameters handled by this command are set as in the sequel:
a.1) enable = true;
a.2) macAutoRequestSecurityLevel = security level expected
for the beacon message and stored within the
GlobalSecurityLevelsTable;
a.3) macAutoRequestKeyIdMode = 0x03;
a.4) macAutoRequestKeySource = MAC address of the PAN
coordinator;
a.5) macAutoRequestKeyIndex = 1;
a.6) macDefaultKeySource = MAC address of the PAN
coordinator;
b) CONFIGURE.security.macSecurityLevelTable command is generated
by the 6top layer and sent to the MAC entity to initialize
macSecurityLevelTable (as discussed in [I-D.wang-6tisch-6top], in
Sec. 2.4.9.3). Parameters stored into this command are taken from
the GlobalSecurityLevelsTable.
c) The DefaultKey, D_k, is obtained from the MasterKey, M_k, by
using a 128-bit hash function, H_128(.)
D_k= H_128(PAN_ID | shortMACaddress | M_k).
d) A new KeyIdLookupList data structure is created. A
KeyIdLookupDescriptor is generated and stored into the
KeyIdLookupList data structure. The KeyIdMode, the KeySource, and
the KeyIndex variables of this KeyIdLookupDescriptor are set to
0x03, the MAC address of the device, and 1, respectively. Instead,
DeviceAddrMode, DevicePANId, and DeviceAddress are not set due to
the selected KeyIdMode (see Tab. 65 of the IEEE 802.15.4 standard
for more details [IEEE802154]).
e) A KeyUsageList data structure is created. One
KeyUsageDescriptor for each kind of broadcast messages is create
and stored into the KeyUsageList data structure.
f) An empty DeviceDescriptorHandleList is created. No data are
stored within this list because the PAN coordinator does not yet
know the list of devices that may use this key.
G. Piro, et al Expires June 17, 2014 [Page 18]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
Then, the 6top layer deliver the DefaultKey, the KeyIdLookupList,
the KeyUsageList, and the DeviceDescriptorHandleList to the MAC
layer by using the CONFIGURE.security.macKeyTable primitive (as
discussed in [I-D.wang-6tisch-6top], in Sec. 2.4.9.2).
Triggered by the CONFIGURE.security.macKeyTable command, the MAC
layer will create a KeyDescriptor associated to the DefaultKey,
D_k,in which storing all the parameters received by the 6top
layer, and and will store it within the macKeyTable.
The Bootstrap phase for the PAN coordinator has been summarized in
Fig. 7.
G. Piro, et al Expires June 17, 2014 [Page 19]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
6top MAC
| |
| CONFIGURE.security |
|-----------------------------------------> |
| initialize
| security MAC
| attributes
| |
| CONFIGURE.security.macSecurityLevelTable |
|-----------------------------------------> |
| initialize
| minimum security
| levels
compute |
DefaultKey |
| |
| CONFIGURE.security.macKeyTable |
|-----------------------------------------> |
| create the KeyDescriptor
| associated to the
| DefaultKey
| |
V V
Figure 7. Bootstrap Phase for the PAN coordinator.
6.2.2 Bootstrap phase for a mote in a Beacon-enabled network
To join the network, a mote should associate with the coordinator.
The Next Higher Layer sends to the MAC entity the MLME-
ASSOCIATE.request primitive, starting the association procedure.
As for the PAN coordinator, in this phase the 6top adaptation
layer should initialize security MAC attributes, compute the
DefaultKey, D_k, and updates MAC security attributes accordingly.
To this end, after the reception of the beacon message, the
following operations are executed:
a) The PAN_ID, the MAC address of the coordinator, and the
FrameCounter are extracted from the header of the beacon message.
b) A CONFIGURE.security primitive is generated by the 6top layer
and sent to the MAC entity to initialize security attributes (as
discussed in [I-D.wang-6tisch-6top], in Sec. 2.4.9.1). The set of
parameters handled by this primitive are set as in the sequel:
G. Piro, et al Expires June 17, 2014 [Page 20]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
b.1) enable = true;
b.2) macAutoRequestSecurityLevel = security level expected
for the beacon message and stored within the
GlobalSecurityLevelsTable;
b.3) macAutoRequestKeyIdMode = 0x03;
b.4) macAutoRequestKeySource = MAC address of the PAN
coordinator;
b.5) macAutoRequestKeyIndex = 1;
b.6) macDefaultKeySource = MAC address of the PAN
coordinator;
c) CONFIGURE.security.macSecurityLevelTable primitive is generated
by the 6top layer and sent to the MAC entity to initialize
macSecurityLevelTable (as discussed in [I-D.wang-6tisch-6top], in
Sec. 2.4.9.3). Parameters stored into this command are taken from
the GlobalSecurityLevelsTable.
d) The DefaultKey, D_k, is obtained from the MasterKey, M_k, by
using a 128-bit hash function, H_128(.)
D_k= H_128(PAN_ID | shortMACaddress | M_k).
e) A new KeyIdLookupList data structure is created. A
KeyIdLookupDescriptor is generated and stored into the
KeyIdLookupList data structure. The KeyIdMode, the KeySource, and
the KeyIndex variables of this KeyIdLookupDescriptor are set to
0x03, the MAC address of the PAN coordinator, and 1, respectively.
Instead, DeviceAddrMode, DevicePANId, and DeviceAddress are not
set due to the selected KeyIdMode (see Tab. 65 of the IEEE
802.15.4 standard for more details [IEEE802154]).
f) A KeyUsageList data structure is created. One
KeyUsageDescriptor for each kind of broadcast messages is create
and stored into the KeyUsageList data structure.
g) A new DeviceDescriptor element, associated to the PAN
coordinator (i.e., the FFD node that sent the Beacon message) is
created and stored into the macDeviceTable. It is built
considering these specifications (see Tab. 64 of the IEEE 802.15.4
standard [IEEE802154] for more details):
g.1) The PANId variable is associated to the PAN_ID value
extracted from the Beacon message.
G. Piro, et al Expires June 17, 2014 [Page 21]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
g.2) The ShortAddress is set to the MAC address of the
coordinator whenever the short addressing mode is used. This
parameter is set to 0xfffe if only the extended addressing
mode is used. If its value is unknown, the ShortAddress
parameter is set to 0xfff.
g.3) The ExtAddress is set to the IEEE MAC address of the
coordinator.
g.4) The FrameCounter parameter is set to the FrameCounter
value extracted from the Beacon message.
g.5) The Extempt boolean flag is set to the allowed value of
the DeviceOverriddeSecurityMinimum variable described in
Fig. 2.
h) The DeviceDescriptorHandleList is created and populated with
the DeviceDescriptor created at the previous step.
i) A KeyUsageList data structure is created and stored within the
KeyDescriptor element. One KeyUsageDescriptor for each broadcast
message is create and stored into the KeyUsageList data
structure.
Then, the 6top layer deliver the DefaultKey, the KeyIdLookupList, the
KeyUsageList, and the DeviceDescriptorHandleList to the MAC layer by
using the CONFIGURE.security.macKeyTable primitive (as discussed in [I-
D.wang-6tisch-6top], in Sec. 2.4.9.2).
Triggered by the CONFIGURE.security.macKeyTable primitive, the MAC layer
will create a KeyDescriptor associated to the DefaultKey, D_k, in which
storing all the parameters received by the 6top layer, and and will
store it within the macKeyTable.
The Bootstrap Phase for a remote mote in a beacon-enabled network has
been summarized in Fig. 8.
G. Piro, et al Expires June 17, 2014 [Page 22]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
remote mote remote mote PAN coordinator
6top MAC MAC
| | |
| | Beacon |
| | <-----------------|
| extract PAN_ID |
| and macShortAddress |
| | |
| CONFIGURE.security | |
|----------------------------> | |
| initialize |
| security MAC |
| attributes |
| | |
| CONFIGURE.security. | |
| macSecurityLevelTable | |
|----------------------------> | |
| initialize |
| minimum security |
| levels |
compute | |
DefaultKey | |
| | |
| CONFIGURE.security. | |
| macKeyTable | |
|----------------------------> | |
| create the KeyDescriptor |
| associated to the |
| DefaultKey |
| | |
V V V
Figure 8. Bootstrap Phase for the remote mote in an enabled-beacon
network.
6.2.3 Bootstrap phase for a mote in a not-Beacon-enabled network
In the case the not-beacon-enabled scheme is enabled, the mote must
explicitly requests its generation to the coordinator. The payload of
the Beacon Request packet must be protected using an ephemeral key,
phi_k, obtained from the MasterKey, M_k, and the source address of the
device, srcMACaddrMote, as
phi_k = H_128(srcMACaddrMote | M_K).
The KeyIdMode of the Beacon Request packet is set to 00, thus enabling
the PAN coordinator to implicitly obtain the ephemeral key.
G. Piro, et al Expires June 17, 2014 [Page 23]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
Once received the Beacon frame, the remote mote will execute all the
steps described in Sec. 6.3.
The Bootstrap Phase for a remote mote in a not-beacon-enabled network
has been summarized in Fig. 9.
G. Piro, et al Expires June 17, 2014 [Page 24]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
remote mote remote mote PAN coordinator
6top MAC MAC
| | |
| compute phi_k |
| | |
| | Beacon Request |
| |-----------------> |
| | |
| | Beacon |
| | <-----------------|
| | |
| extract PAN_ID |
| and macShortAddress |
| | |
| CONFIGURE.security | |
|----------------------------> | |
| initialize |
| security MAC |
| attributes |
| | |
| CONFIGURE.security. | |
| macSecurityLevelTable | |
|----------------------------> | |
| initialize |
| minimum security |
levels |
compute | |
DefaultKey | |
| | |
| CONFIGURE.security. | |
| macKeyTable | |
|----------------------------> | |
| create the KeyDescriptor |
| associated to the |
| DefaultKey |
| | |
V V V
Figure 9. Bootstrap Phase for the remote mote in an not-enabled-beacon
network.
6.3 Key Negotiation Phase
Since resource-constrained devices are unable to perform complex
algorithms and protocols [Altolini2013][Riaz2009], a simple key
agreement protocol is adopted during the execution of the key
negotiation phase.
G. Piro, et al Expires June 17, 2014 [Page 25]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
The KMP adopted by the secured framework presented in this draft is
based on both DH algorithm [DH] and Station-To-Station protocol
[StsProtocol].
Both anonymous and certified DH schemes are supported. The former one
does not require that a mote will deliver its public key through a
certificate and, for this reason, it doe snot support the node
authentication. The latter one, instead, supports the use of
certificates to authenticate the public key of each mote. With the
anonymous DH scheme, a mote is able to deliver its public key by means
of only one packet. When the certified DH scheme is used, instead, the
public key will be delivered through multiple packets because of the
high size of certificate (i.e., the key material generated by the mote
needs to be fragmented).
To handle the Key Negotiation Phase, a new command MAC frame and two new
6top commands have been defined.
6.3.1 The new command MAC frame
A new command MAC frame, which is identified with a
CommandFrameIdentifier set to 0xAA, has been introduced.
It is composed by four different fields: KeyGenControlField, Rand,
KeyMaterial, and AuthenticationField.
The structure of the new command MAC frame has been reported in Fig. 10.
The structure of the KeyGenControlField, instead, are shown in Fig. 11.
The introduction of these new fields respects the constraints imposed by
the standard about the maximum packet size.
G. Piro, et al Expires June 17, 2014 [Page 26]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
+--------------+--------------+--------------+----------------+
| Octects: 2 | 0/2 | 0/S | 0/16 |
+--------------+--------------+--------------+----------------+
| KeyGen | Rand | Key | Authentication |
| ControlFiled | | Material | Field |
+--------------+--------------+--------------+----------------+
Figure 10. A new command MAC frame adopted during the key negotiation
phase.
+--------+--------+--------+--------+--------+--------+--------+
| Bits: 2| 2 | 1 | 1 | 5 | 1 | 3 |
+--------+--------+--------+--------+--------+--------+--------+
| Message| KeyGen | Key | Auth | Key | Frag | Frag |
| Type | Mode | Flag | Flag | Size | Enabled| Number |
+--------+--------+--------+--------+--------+--------+--------+
Figure 11. KeyGenControlField of the new command MAC frame adopted
during the key negotiation phase.
The KeyGenControlField (2 bytes long) stores details about the content
of the message. It is composed by the following fields:
- the MessageType (2 bits long), which identifies the type of
message exchanged during the procedure. It may assume these
values:
- MessageType=00 identifies a message storing key materials
(i.e., DH parameters).
- MessageType=01 identifies final messages belonging to the
Key Negotiation Phase that are used to verify the mutual
authentication of nodes.
- MessageType=10 and MessageType=11 are reserved for future
upgrades.
- the KeyGenMode (2 bits long), which describes the algorithm
adopted for key generation. It is set to 00 and 01 when the key is
computed through the anonymous DH and the certified DH algorithms,
respectively. Other values, i.e., 10 and 11, are reserved and can
be used for future upgrades.
- the boolean KeyFlag (1 bit long), which is set to TRUE in the
case the message delivers key materials or to FALSE otherwise.
- the boolean AuthFlag (1 bit long) ), which is set to TRUE in the
case the message delivers an authentication field or to FALSE
otherwise.
G. Piro, et al Expires June 17, 2014 [Page 27]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
- the KeySize (5 bits long), which indicates the size of the
transported key material, expressed in bytes. Its value is set to
0 in the case the message does not contain any key materials.
- the boolean FragEnabled (1 bit long), which is set to TRUE when
the key material contains a fragment of the certificate storing
the public key of a mote;
- the FragNumber (3 bit long), which indicates the fragment number
associated to the key material field.
The Rand field (0/2 bytes long) contains a random value used for
generating the PreLinkKey, P_k, and for verifying the authenticity of
the remote device. It is present only if MessageType is equal to 00 or
01.
The KeyMaterial field (0/S bytes long, where S is the size of the prime
number) contains key materials, such as DH parameters. It is present
only if MessageType is equal to 00 or 01.
AuthenticationField field (0/16 bytes long) is used to verify the
authenticity of the remote device. It is present only if MessageType is
equal to 10.
6.3.2 New 6top commands
The following 6top commands have been designed to perform the KMP:
- CONFIGURE.security.startKMP: it is used to send the initial key
material that will be exploited by the DH protocol to generate the
key. The command requires:
- KeyGenMode, which represents the algorithm adopted to
negotiate the key;
- KeyMaterial, which represent the public key or a
certificate storing the public key;
- Rand, which is a random number exploited during the mutual
authentication process.
- CONFIGURE.security.completeKMP: it is used to complete the KMP
by handling the mutual authentication between motes according to
the Station-To-Station protocol. The command requires:
- KeyGenMode, which represents the algorithm adopted to
negotiate the key;
G. Piro, et al Expires June 17, 2014 [Page 28]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
- AuthenticationField, which is used to verify the mutual
authentication.
6.3.3 KMP implementation when the anonymous DH scheme is used
The KPM is initialized by the 6top adaptation layer of the remote device
connected to the coordinator, that has already completed the joining
procedure and that wants to establish a secured link with the PAN
coordinator.
The procedure assumes that both motes store into the PrimeNumbersTable
the same set of N prime numbers and their primitive roots, each one
having size equal to S (see Sec. 6.1 for more details).
The number of bits needed to identify each prime number of the
PrimeNumbersTable, i.e., P_bits, is equal to
P_bits = log2 (N).
We note that the security level of the proposed approach does not depend
from P_bits, but it is only influenced by the length of each prime
number, S. See Appendix A.1 for more details.
The KMP is performed through the execution of these operations:
a) The 6top adaptation layer of the remote mote performs the
following steps:
a.1) a prime number, P, and the corresponding primitive
root, g, are identified in the PrimeNumbersTableby by
extracting the latest P_bits bits from the output of the
following hash function:
H_128(PAN_ID | D_k).
a.2) two random numbers are generated: the former one
represents its private key, i.e., PVK_remoteMote; the latter
one is used for the mutual authentication, i.e.,
RAND_remoteMote.
a.3) the public key, i.e., PBK_remoteMote, is generated
according to the DH algorithm:
PBK_remoteMote = g^PVK_remoteMote * mod P
G. Piro, et al Expires June 17, 2014 [Page 29]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
a.4) A CONFIGURE.security.startKMP command is released and
delivered to the MAC layer. KeyGenMode, KeyMaterial, and
Rand parameters of this command are ser to 00,
PBK_remoteMote, and RAND_remoteMote, respectively.
b) Triggered by the CONFIGURE.security.startKMP command, the MAC
layer of the remote mote generates a command MAC frame, which is
composed by the following fields: MessageType=00, KeyGenMode=00,
KeyFalg=TRUE, AuthFlag=FALSE, KeySize=S, Rand=RAND_remoteMote, and
KeyMaterial=PBK_remoteMote. In the case the Fully Secured
Configuration is enabled, this message is encrypted with the
DefaultKey, D_k. Otherwise it is sent in clear.
c) The 6top adaptation layer of the PAN coordinator performs the
following steps:
c.1) a prime number, P, and the corresponding primitive
root, g, are identified in the PrimeNumbersTableby by
extracting the latest P_bits bits from the output of the
following hash function:
H_128(PAN_ID | D_k).
c.2) two random numbers are generated: the former one
represents its private key, i.e., PVK_coordinator; the
latter one is used for the mutual authentication, i.e.,
RAND_coordinator.
c.3) the public key, i.e., PBK_coordinator, is generated
according to the DH algorithm:
PBK_coordinator = g^PVK_coordinator * mod P
c.4) A CONFIGURE.security.startKMP command is released and
delivered to the MAC layer. KeyGenMode, KeyMaterial, and
Rand parameters of this command are ser to 00,
PBK_coordinator, and RAND_coordinator, respectively.
d) Triggered by the CONFIGURE.security.startKMP command, the MAC
layer of the remote mote generates a command MAC frame, which is
composed by the following fields: MessageType=00, KeyGenMode=00,
KeyFalg=TRUE, AuthFlag=FALSE, KeySize=S, Rand=RAND_coordinator,
and KeyMaterial=PBK_coordinator. In the case the Fully Secured
Configuration is enabled, this message is encrypted with the
DefaultKey, D_k. Otherwise it is sent in clear.
e) The 6top adaptation layer of the remote mote computes the
PreLinkKey, P_k
G. Piro, et al Expires June 17, 2014 [Page 30]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
P_k = PBK_coordinator^PVK_remoteMote * mod P.
f) The 6top adaptation layer of the PAN coordinator computes the
PreLinkKey, P_k,
P_k = PBK_remoteMote^PVK_coordinator * mod P.
g) Both remote motes and PAN coordinator compute the LinkKey by
using the procedure described in Sec. 6.3.5.
h) The 6top adaptation layer of the remote mote computes the
authentication parameter, AUTH_remoteMote, through the 128-bit
hash function, H_128(.), as in the sequel
AUTH_remoteMote=H_128(P_k || RAND_coordinator || RAND_remoteMote).
Then, it releases a CONFIGURE.security.completeKMP command with
KeyGenMode and AuthenticationField set to 00 and AUTH_remoteMote,
respectively.
i) The MAC layer of the remote mote sends to the coordinator a new
MAC command message to complete the mutual authentication. This
message is composed by the following fields: MessageType=10,
KeyGenMode=00, KeyFalg=FALSE, AuthFlag=TRUE, KeySize=0, and
AuthenticationField=AUTH_remoteMote. This message is protected by
using the LinkKey computed before.
j) The 6top adaptation layer of the PAN coordinator verifies the
validity of the received AUTH_remoteMote parameter. In affirmative
case, it computes the authentication parameter, AUTH_coordinator,
through the 128-bit hash function, H_128(.), as in the sequel:
AUTH_coordinator=H_128(P_k || RAND_remoteMote || RAND_coordinator).
Then, it releases a CONFIGURE.security.completeKMP command with
KeyGenMode and AuthenticationField set to 00 and AUTH_coordinator,
respectively.
k) The MAC layer of the PAN coordinator sends to the remote mote a
new MAC command message to complete the mutual authentication.
This message is composed by the following fields: MessageType=10,
KeyGenMode=00, KeyFalg=FALSE, AuthFlag=TRUE, KeySize=0, and
AuthenticationField=AUTH_coordinator. This message is protected by
using the LinkKey computed before.
l) The remote motes verifies the validity of the received
AUTH_coordinator parameter.
G. Piro, et al Expires June 17, 2014 [Page 31]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
m) PAN coordinator and remote mote update MAC security attributes
according to procedures described in Sec. 6.3.6 and Sec 6.3.7,
respectively.
The aforediscussed KMP has been summarized in Fig. 12.
G. Piro, et al Expires June 17, 2014 [Page 32]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
G. Piro, et al Expires June 17, 2014 [Page 33]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
6top MAC MAC 6top
remote mote remote mote coordinator coordinator
| | | |
| | | |
Identify p, g | | |
Compute PVK_remoteMote, | | |
RAND_remoteMote, and | | |
PBK_remoteMote | | |
| | | |
| CONFIGURE.security.| | |
| startKMP | | |
|------------------> | command MAC | |
| | ------------------>| ------------------>|
| | | |
| | | Identify p, g
| | |Compute PVK_remoteMote,
| | | RAND_remoteMote, and
| | | PBK_remoteMote
| | | |
| | | CONFIGURE.security.|
| | | startKMP |
| | command MAC | <------------------|
| <------------------| <------------------| |
| | | |
compute P_k | | compute P_k
| | | |
compute AUTH_remoteMote | | |
| | | |
| CONFIGURE.security.| | |
| compleyeKMP | | |
|------------------> | command MAC | |
| | ------------------>| ------------------>|
| | | |
| | | verify AUTH_remoteMote
| | | |
| | | compute | | | AUTH_coordinator
| | | |
| | | CONFIGURE.security.|
| | | completeKMP |
| | command MAC | <------------------|
| <------------------| <------------------| |
| | | |
verify AUTH_remoteMote | | |
| | | |
update security | | update security
attributes | | attributes
| | | |
V V V V
G. Piro, et al Expires June 17, 2014 [Page 34]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
Figure 12. KMP implementation when the anonymous DH scheme is used
6.3.4 KMP implementation when the certified DH scheme is used
When the certified DH scheme is used, is is assumed that all devices
have its certificate in which is stored its public key.
Let CERT_remoteMote, CERT_coordinator, PBK_remoteMote, PBK_coordinator
be the certificate of the remote mote, the certificate of the
coordinator, the public key of the remote mote, and the public key of
the coordinator, respectively.
The KMP is performed through the execution of these operations:
a) The 6top adaptation layer of the remote mote extracts a random
number, RAND_remoteMote, that will be used to complete the mutual
authentication procedure. Then, it releases a
CONFIGURE.security.startKMP command and delivers it to the MAC
layer. KeyGenMode, KeyMaterial, and Rand parameters of this
command are ser to 00, CERT_remoteMote, and RAND_remoteMote,
respectively.
b) Triggered by the CONFIGURE.security.startKMP command, the MAC
layer generates Z fragments of the certificate, with size T. For
each i-th fragment, it generates a command MAC frame, which is
composed by the following fields: MessageType=00, KeyGenMode=01,
KeyFalg=TRUE, AuthFlag=FALSE, KeySize=T,, FlagEnabled=TRUE,
FragNumber=i, Rand=RAND_remoteMote, and KeyMaterial=fragment_i. In
the case the Fully Secured Configuration is enabled, this message
is encrypted with the DefaultKey, D_k. Otherwise it is sent in
clear.
c) The 6top adaptation layer of the PAN coordinator extracts a
random number, RAND_coordinator, that will be used to complete the
mutual authentication procedure. Then, it releases a
CONFIGURE.security.startKMP command and delivers it to the MAC
layer. KeyGenMode, KeyMaterial, and Rand parameters of this
command are ser to 00, CERT_coordinator, and RAND_coordinator,
respectively.
d) Triggered by the CONFIGURE.security.startKMP command, the MAC
layer generates Z fragments of the certificate, with size T. For
each i-th fragment, it generates a command MAC frame, which is
composed by the following fields: MessageType=00, KeyGenMode=01,
KeyFalg=TRUE, AuthFlag=FALSE, KeySize=T, FlagEnabled=TRUE,
FragNumber=i, Rand=RAND_coordinator, and KeyMaterial=fragment_i.
G. Piro, et al Expires June 17, 2014 [Page 35]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
In the case the Fully Secured Configuration is enabled, this
message is encrypted with the DefaultKey, D_k. Otherwise it is
sent in clear.
e) The 6top adaptation layer of the remote mote extracts the
public key of the PAN coordinator from its certificate and
computes the PreLinkKey, P_k
P_k = PBK_coordinator^PVK_remoteMote * mod P.
f) The 6top adaptation layer of the PAN coordinator extracts the
public key of the remote mote and computes the PreLinkKey, P_k,
P_k = PBK_remoteMote^PVK_coordinator * mod P.
g) Both remote motes and PAN coordinator compute the LinkKey by
using the procedure described in Sec. 6.3.4.
h) The 6top adaptation layer of the remote mote computes the
authentication parameter, AUTH_remoteMote, by following these
steps:
h.1) generate an authenticator message:
authMsg_remoteMote = P_k || RAND_coordinator || RAND_remoteMote
h.2) sign with the private key the 128-hash function of the
authenticator message:
sign=S(PVK_remoteMote, H_128(authMsg_remoteMote))
h.3) obtain AUTH_remoteMote by encrypting with the
preLinkKey, P_k, the sign computed before:
AUTH_remoteMote=E(P_k, sign)
Then, it releases a CONFIGURE.security.completeKMP command with
KeyGenMode and AuthenticationField set to 00 and AUTH_remoteMote,
respectively.
i) The MAC layer of the remote mote sends to the coordinator a new
MAC command message to complete the mutual authentication. This
message is composed by the following fields: MessageType=10,
KeyGenMode=01, KeyFalg=FALSE, AuthFlag=TRUE, KeySize=0, and
AuthenticationField=AUTH_remoteMote. This message is protected by
using the LinkKey computed before.
j) The 6top adaptation layer of the PAN coordinator verifies the
G. Piro, et al Expires June 17, 2014 [Page 36]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
validity of the received AUTH_remoteMote parameter. In affirmative
case, it computes the authentication parameter, AUTH_coordinator,
by following these steps:
j.1) generate an authenticator message:
authMsg = P_k || RAND_remoteMote || RAND_coordinator
j.2) sign with the private key the 128-hash function of the
authenticator message:
sign=S(PVK_remoteMote, H_128(authMsg))
j.3) obtain AUTH_remoteMote by encrypting with the
preLinkKey, P_k, the sign computed before:
AUTH_coordinator=E(P_k, sign)
Then, it releases a CONFIGURE.security.completeKMP command with
KeyGenMode and AuthenticationField set to 00 and AUTH_coordinator,
respectively.
k) The MAC layer of the PAN coordinator sends to the remote mote a
new MAC command message to complete the mutual authentication.
This message is composed by the following fields: MessageType=10,
KeyGenMode=01, KeyFalg=FALSE, AuthFlag=TRUE, KeySize=0, and
AuthenticationField=AUTH_coordinator. This message is protected by
using the LinkKey computed before.
l) The remote motes verifies the validity of the received
AUTH_coordinator parameter.
m) PAN coordinator and remote mote update MAC security attributes
according to procedures described in Sec. 6.3.6 and Sec 6.3.7,
respectively.
The aforediscussed KMP has been summarized in Fig. 13.
G. Piro, et al Expires June 17, 2014 [Page 37]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
G. Piro, et al Expires June 17, 2014 [Page 38]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
6top MAC MAC 6top
remote mote remote mote coordinator coordinator
| | | |
| | | |
Compute RAND_remoteMote | | |
| | | |
| CONFIGURE.security.| | |
| startKMP | | |
|------------------> | command MAC | |
| | ------------------>| |
| | ------------------>| |
| | ------------------>| |
| | | |
| | | Compute
| | | RAND_remoteMote
| | | |
| | | CONFIGURE.security.|
| | | startKMP |
| | command MAC | <------------------|
| | <------------------| |
| | <------------------| |
| <------------------| <------------------| |
| | | |
compute P_k | | compute P_k
| | | |
compute AUTH_remoteMote | | |
| | | |
| CONFIGURE.security.| | |
| compleyeKMP | | |
|------------------> | command MAC | |
| | ------------------>| ------------------>|
| | | |
| | | verify AUTH_remoteMote
| | | |
| | | compute
| | | AUTH_coordinator
| | | |
| | | CONFIGURE.security.|
| | | completeKMP |
| | command MAC | <------------------|
| <------------------| <------------------| |
| | | |
verify AUTH_remoteMote | | |
| | | |
update security | | update security
attributes | | attributes
| | | |
V V V V
G. Piro, et al Expires June 17, 2014 [Page 39]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
Figure 13. KMP implementation when the certified DH scheme is used
6.3.5 Generation of the LinkKey
The standard imposes to use the CCM* algorithm and a 128-bit key to
protect MAC frames. At the same time, the CCM* algorithm assumes that
each key must be used for a specific number of block ciphers
[IEEE802154].
For each i-th group of block ciphers, the LinkKey, L_k, is computed as
in the following:
L_k = H_128 (i | PAN_ID | P_k).
6.3.6 Update of MAC security attributes for the PAN coordinator after
the generation of the LinkKey
After the calculation of the i-th LinkKey, the 6top adaptation layer of
the PAN coordinator updates its MAC security attributes as described in
what follows.
a) If i=1, a new DeviceDescriptor element, associated to the
remote mote with which it has negotiated a link key, is created.
It is composed by:
a.1) the PANId, which is set to the PAN_ID value.
a.2) The ShortAddress, which is set to the MAC address of
the RFD node whenever the short addressing mode is used.
This parameter is set to 0xfffe if only the extended
addressing mode is used. In the case its value is unknown,
this parameter is set to 0xfff.
a.3) The ExtAddress, which is set to the IEEE MAC address of
the RFD node.
a.4) The FrameCounter, which is set to the FrameCounter
value extracted from the latest packet received by the RFD
node.
a.5) The Extempt boolean flag, which is set to the allowed
value of the DeviceOverriddeSecurityMinimum variable
described in Fig. 2.
G. Piro, et al Expires June 17, 2014 [Page 40]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
b) A new KeyIdLookupList data structure is created. A
KeyIdLookupDescriptor is generated and stored into the
KeyIdLookupList data structure. The KeyIdMode, the KeySource, and
the KeyIndex variables of this KeyIdLookupDescriptor are set to
0x03, the MAC address of the remote mote that initialized the Key
Negotiation Phase, and 1, respectively. DeviceAddrMode,
DevicePANId, and DeviceAddress are not set because of the selected
KeyIdMode (see Tab. 65 of the IEEE 802.15.4 standard for more
details [IEEE802154]).
c) A KeyUsageList data structure is created and stored within the
KeyDescriptor element. One KeyUsageDescriptor associated to data
MAC frames is created and stored into the KeyUsageList data
structure.
d) A DeviceDescriptorHandleList is created and populated with the
pointer to the DeviceDescriptor created at the point a).
Then, the 6top layer delivers the LinkKey, the KeyIdLookupList,
the KeyUsageList, and the DeviceDescriptorHandleList to the MAC
layer by using the CONFIGURE.security.macKeyTable command (as
discussed in [I-D.wang-6tisch-6top], in Sec. 2.4.9.2).
Triggered by the CONFIGURE.security.macKeyTable command, the MAC
layer will create a KeyDescriptor associated to the LinkKey,
L_k,in which storing all the parameters received by the 6top
layer, and and will store it within the macKeyTable.
6.3.7 Update of MAC security attributes for the remote mote after the
generation of the LinkKey
After the calculation of the i-th LinkKey, the 6top adaptation
layer of the remote mote updates its MAC security attributes as
described in what follows.
a) A new KeyIdLookupList data structure is created. A
KeyIdLookupDescriptor is generated and stored into the
KeyIdLookupList data structure. The KeyIdMode, the KeySource, and
the KeyIndex variables of this KeyIdLookupDescriptor are set to
0x03, the MAC address of the PAN coordinator that initialized the
Key Negotiation Phase, and 1, respectively. DeviceAddrMode,
DevicePANId, and DeviceAddress are not set because of the selected
KeyIdMode (see Tab. 65 of the IEEE 802.15.4 standard for more
details [IEEE802154]).
b) A KeyUsageList data structure is created and stored within the
G. Piro, et al Expires June 17, 2014 [Page 41]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
KeyDescriptor element. One KeyUsageDescriptor associated to data
MAC frames is created and stored into the KeyUsageList data
structure.
c) A DeviceDescriptorHandleList is created and populated with the
pointer to the DeviceDescriptor associated to the PAN coordinator
and created during the Bootstrap Phase.
Then, the 6top layer delivers the LinkKey, the KeyIdLookupList, the
KeyUsageList, and the DeviceDescriptorHandleList to the MAC layer by
using the CONFIGURE.security.macKeyTable command (as discussed in [I-
D.wang-6tisch-6top], in Sec. 2.4.9.2).
Triggered by the CONFIGURE.security.macKeyTable command, the MAC layer
will create a KeyDescriptor associated to the LinkKey, L_k,in which
storing all the parameters received by the 6top layer, and and will
store it within the macKeyTable.
7 Additional features
There is the possibility to switch from the Flexible Secured to the
Hybrid Secure configuration.
To this aim, during the join process, a mote without security
capabilities sends to the PAN coordinator a Beacon Request message with
the SecurityEnabled flag set to FALSE.
The PAN coordinator, if properly configures, switches to the Hybrid
Secure configuration and update all the MAC security attributes
accordingly.
From this moment on, the coordinator will send broadcast messages in
clear.
G. Piro, et al Expires June 17, 2014 [Page 42]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
8 Security Considerations
There are no security considerations for this document.
9 IANA Considerations
There is no IANA action required for this document.
10 References
10.1 Normative References
[I-D.watteyne-6tisch-tsch] Watteyne, T., "Using IEEE802.15.4e TSCH in
an LLN context: Overview, Problem Statement and Goals",
Internet-Draft draft-watteyne-6tisch-tsch-00, (work in
progress) October 2013.
[I-D.wang-6tisch-6top] Wang, Q., Vilajosana, X. and T. Watteyne,
"6TiSCH Operation Sublayer (6top)", Internet-Draft draft-
wang-6tisch-6top-00, (work in progress) October 2013.
[I-D.draft-palattella-6tisch-terminology] Palattella, MR., Ed.,
Thubert, P., Watteyne, T., and Q. Wang, "Terminology in
IPv6 over Time Slotted Channel Hopping". Internet Draft
draft-palattella-6tisch-terminology-00, (work in
progress) October 2013.
[DH] W. Diffie and M. Hellman, "New directions in cryptography," IEEE
Trans. Inf. Theor. 22, 6 Sep., 2006.
[StsProtocol] Whitfield Diffie, Paul C. van Oorschot and Michael J,
"Wiener, Authentication and authenticated key exchange",
Designs, Codes, and Cryptography, 1987.
10.2 Informative References
[IEEE802154e] IEEE standard for Information Technology, "IEEE std.
802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendament 1: MAC sublayer", April
2012.
[IEEE802154] IEEE standard for Information Technology, "IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks", June 2011.
G. Piro, et al Expires June 17, 2014 [Page 43]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
[ZIGBEEIP] ZigBee Public Document 15-002r00, "ZigBee IP
Specification", 2013.
[Camtepe2005] Seyit A. Camtepe and Bulent Yener, "Key Distribution
Mechanisms for Wireless Sensor Networks: a Survey",
Technical Report 2005.
[Walters07] John Paul Walters, Zhengqiang Liang, Weisong Shi, and
Vipin Chaudhary, "Wireless sensor network security: A
survey," in book chapter of Security", Proc. of
Distributed, Grid, and Pervasive Computing, CRC Press,
2007.
[Wang2006] Yong Wang, Garhan Attebury, and Byrav Ramamurthy, "A
survey of security issues in wireless sensor networks",
IEEE Communications Surveys & Tutorials, 2006
[Cayirci2007] Security in Wireless Ad Hoc and Sensor Networks. John
Wiley & Sons, 2007.
[I-D.roll-security-framework] Tzeta Tsao, Roger Alexander, Mischa
Dohler, Vanesa Daza, and Angel Lozano, "A Security
Framework for Routing over Low Power and Lossy Networks",
Internet Draft draft-ietf-roll-security-framework-07, Jan
2013.
[I-D.garcia-core-security] O. Garcia-Morchon, S. Keoh, S. Kumar, R.
Hummen, and R. Struik, "Security Considerations in the IP-
based Internet of Things," IETF, Internet Draft, Sep.
2013.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[HIPDEX] Moskowitz, R., "HIP Diet EXchange (DEX)", draft-
moskowitzhip-rg-dex-06 (work in progress), May 2012.
[PalattellaSurvey] Maria Rita Palattella, Nicola Accettura, Xavier
Vilajosana, Thomas Watteyne, Luigi Alfredo Grieco, Gennaro
Boggia, and Mischa Dohler," Standardized Protocol Stack
For The Internet Of (Important) Things", IEEE
Communications Surveys & Tutorials, December, 2012
[StallingsSecurityBooks] William Stallings: Cryptography and network
G. Piro, et al Expires June 17, 2014 [Page 44]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
security - principles and practice. Prentice Hall 2010.
[Becher2006] Alexander Becher, Zinaida Benenson, and Maximillian
Dornseif, "Tampering with motes: real-world physical
attacks on wireless sensor networks", In Proc. of conf.
on Security in Pervasive Computing (SPC), Berlin, 2006
[TELOSB] "Crossbow Technology, TelosB Datasheet." [Online].
Available: http://www.willow.co.uk/TelosB_Datasheet.pdf
[Riaz2009] Riaz, R.; Ki-Hyung Kim; Ahmed, H.F., "Security analysis
survey and framework design for IP connected LoWPANs,"
Autonomous Decentralized Systems, 2009. ISADS '09.
International Symposium on , vol., no., pp.1,6, 23-25
March 2009
[Altolini2013] Altolini, D.; Lakkundi, V.; Bui, N.; Tapparello, C.;
Rossi, M., "Low power link layer security for IoT:
Implementation and performance analysis," Wireless
Communications and Mobile Computing Conference (IWCMC),
2013 9th International , vol., no., pp.919,925, 1-5 July
2013
[Watteyne2012] Thomas Watteyne, Xavier Vilajosana, Branko Kerkez,
Fabien Chraim, Kevin Weekly, Qin Wang, Steven D. Glaser,
Kris Pister: OpenWSN: a standards-based low-power wireless
development environment. Trans. Emerging
Telecommunications Technologies 23(5): 480-493 (2012)
Appendix A. DH protocol
A.1 Security considerations about the DH protocol
As discussed in Sec. 6.5.5, the CCM* transformation requires a 128-bit
key.
According to the DH algorithm, and considering properties of the modular
arithmetic [DH], the length of both the public key of a mote and the
prime number used for its generation must be at least equal to 128
bits.
The security level of the proposed approach does not depend from the
number of prime numbers stored into the PrimeNumberTable (because these
numbers are not the keys), but it coincides with the security level of
the DH protocol. hence, it is strictly related to length of prime
numbers, S.
G. Piro, et al Expires June 17, 2014 [Page 45]
INTERNET DRAFT draft-piro-6tisch-security-issues-01 December 14, 2013
In particular, the total number of keys that a mote can use during the
Key Negotiation Phase are equal to 2^S. Supposing to have S >= 128, the
total number of keys is higher than 3*10^38. This should guarantee a
very high resilience to any kind of brute force attack.
Authors' Addresses
G. Piro
DEI, Dep. of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4, 70125, Bari, ITALY
Phone: +39 0805963301
Email: g.piro@poliba.it
G. Boggia
DEI, Dep. of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4, 70125, Bari, ITALY
Phone: +39 0805963913
Email: g.boggia@poliba.it
L.A. Grieco
DEI, Dep. of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4, 70125, Bari, ITALY
Phone: +39 0805963911
Email: a.grieco@poliba.it
G. Piro, et al Expires June 17, 2014 [Page 46]