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

Versions: 00 01 02

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]


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