6TiSCH G. Piro INTERNET-DRAFT (Politecnico di Bari) Intended Status: Informational G. Boggia Expires: April 21, 2014 (Politecnico di Bari) L. A. Grieco (Politecnico di Bari) October 18, 2013 A standard compliant security framework for Low-power and Lossy Networks draft-piro-6tisch-security-issues-00 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 the possibility to encrypt and authenticate messages exchanged by nodes at the MAC layer. The framework is fully compatible with both IEEE 802.15.4 and IEEE 802.15.4e standards and offers a wide range of security features to network architectures developed within the 6TiSCH Working Group. In particular, it offers: (i) different kinds of security architectures; (ii) an efficient mechanism for initializing a secure IEEE 802.15.4 domain; and (iii) a lightweight mechanism to negotiate 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 April 21, 2014 [Page 1] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Security in IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . 5 4 Definition of the secured domain . . . . . . . . . . . . . . . 8 5 Security Configurations . . . . . . . . . . . . . . . . . . . . 8 5.1 Minimum security requirements . . . . . . . . . . . . . . . 9 6 Initialization of a secured IEEE 802.15.4 domain . . . . . . . 11 6.1 Setting-up phase . . . . . . . . . . . . . . . . . . . . . 11 6.2 Bootstrap phase for a FFD device . . . . . . . . . . . . . 13 6.3 Bootstrap phase for a RFD device in a Beacon-enabled network . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.4 Bootstrap phase for a RFD device in a not-Beacon-enabled network . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.5 Key negotiation phase . . . . . . . . . . . . . . . . . . . 16 6.5.1 Key exchange mechanism based on DH . . . . . . . . . . 18 6.5.2 Generation of the LinkKeys . . . . . . . . . . . . . . 21 6.5.3 Update of MAC security attribute for the FFD node after the generation of the LinkKey . . . . . . . . . . 21 6.5.4 Update of MAC security attribute for the RFD node after the generation of the LinkKey . . . . . . . . . . 23 7 Additional features . . . . . . . . . . . . . . . . . . . . . . 23 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 25 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 25 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.1 Normative References . . . . . . . . . . . . . . . . . . . 25 10.2 Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 G. Piro, et al Expires April 21, 2014 [Page 2] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 1 Acronyms The following acronyms are used in this document: DH Diffie Hellman DEX HIP Diet EXchange DTLS Datagram Transport Layer LLN Low-power and Lossy Network LBR LLN Border Routers FFD Full Function Device HIP Host Identity Protocol MAC Medium Access Control PAN Personal Area Network PANA Protocol for Carrying Authentication for Network Access PHY Physical RFD Reduced Function Device RSA Rivest-Shamir-Adleman TSCH Time-slotted Channel Hopping 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 (PHY) layers of the protocol stack and supports the possibility to protect MAC packets by means of symmetric-key cryptography techniques with several security options. This standard relies on upper layers to orchestrate, enable, configure, and negotiate security services, as well as to handle the creation and exchange of encryption keys. But it leaves open some aspects, such as the initialization of a secure IEEE 802.15.4 domain, the generation and the exchange of keys, the management of joining operations in a secure 802.15.4 network already configured in the G. Piro, et al Expires April 21, 2014 [Page 3] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 past. The IEEE 802.15.4e standard introduces some amendments to the IEEE 802.15.4 standard. The most important one 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 Working Group was born to suggest the adoption of IPv6 over the TSCH, thus covering all facets related to the schedule of network communications in complex (and eventually distributed) Low-Power and Lossy Networks (LLNs). In industrial environments, security issues are very important. Hence, a complete framework, which supports a wide range of security features, is highly required. In this context, the security in LLNs has been firstly addressed within 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 within the network could be high, especially for heavy loaded systems. Security aspects have been also faced in [6TSCH-SEC] and [GARCIA-SEC- IOT]. The work [6TSCH-SEC] introduces a simple security framework based on four consecutive phases (i.e., implanting, bootstrapping, link establishment, and operational phases) which allow the initialization of a secured IEEE 802.15.4 network. It exploits well- known approaches, like PANA [RFC5191], HIP DEX [HIPDEX], and DTLS [RFC6347], to authenticate nodes and to negotiate link keys. Instead, [GARCIA-SEC-IOT] defines a set of security profiles to guarantee in different scenarios (e.g., network without security requirements, home, managed home, industrial, and advanced industrial). For each scenario, it identifies a number of security threats and suggests how fixing them through well-known protocols and algorithms. Proposals presented in [6TSCH-SEC] and [GARCIA-SEC-IOT] do not provide a complete definition of a security framework for LLNs, which offers, at the same time, an accurate procedure for the network initialization, the support for different security configurations, and a fully compatibility with the standard. In addition, they do not guarantee the real possibility to implement conceived proposals in G. Piro, et al Expires April 21, 2014 [Page 4] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 devices, i.e., sensors with very limited computational, energy, and storage capabilities. This Internet Draft proposes a complete and standard compliant framework offering a number of security features at the MAC layer of LLNs. All aspects have been designed in order to ensure an easy and effectively implementation on real devices. In particular, the security framework described in this document introduces all the details required to enable the security for both IEEE 802.15.4 and IEEE 802.15.4e networks, as well as the possibility to encrypt and authenticate any kind of communications devised by the 6TiSCH Working Group. In summary, the security framework covers: (1) five different kinds of security configurations; (2) an efficient mechanism for initializing a secure IEEE 802.15.4 (or IEEE 802.15.4e) domain; (3) a lightweight mechanism to negotiate link keys among devices; (4) a very simple technique adopted to update link keys during the time. 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. +----------+-------------+-----------+----------------+ | 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 | +----------+-------------+-----------+----------------+ G. Piro, et al Expires April 21, 2014 [Page 5] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 | 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. 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]). G. Piro, et al Expires April 21, 2014 [Page 6] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 - 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. - 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. G. Piro, et al Expires April 21, 2014 [Page 7] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 The IEEE 802.15.4 standard does 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 LLN network where procedures and techniques described in this proposal must be performed in order to configure and maintain secured communications. Two types of network nodes, i.e., the Full Function Device (FFD) and the Reduced Function Device (RFD), can be found in an IEEE 802.15.4 network. They can be arranged in both peer-to-peer and star topologies. A FFD device has the highest computational capabilities and it works as the coordinator of the network (also called PAN coordinator), thus being a reference node for a group of other RFD devices. Instead, a RFD device has lower resource and communication capabilities and it is able to communicate only with its reference FFD. Whereas RFD nodes must be connected only to coordinator, FFD devices can connect among them forming more complex meshed network architectures. The concept of secured domain adopted in this Internet Draft coincides with the broadcast domain of an IEEE 802.15.4 network, which is composed by a number of RFD connected to a coordinator and the coordinator itself. The IEEE 802.15.4e amendment does not introduces any variations to the network architecture, thus the previous definition is still valid in this context. The same consideration can be done for network architectures and models designed within the 6TiSCH Working Group that, as explained before, are based on top of the IEEE 802.15.4e amendment. Definitively, to the sake of clarity, from this moment on, we will focus on the terminology related to the IEEE 802.14.5 standard, implying that the entire framework can be adopted also for IEEE 802.15.4e networks and 6TiSCH's proposals. 5 Security Configurations G. Piro, et al Expires April 21, 2014 [Page 8] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 The security framework described in this document supports five network configurations, which differ among them according to the offered security features. They are: - 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 offers the lowest security level. Since the data encryption, the message integrity, and the peer authentication are not implemented, all the MAC frames are 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. 5.1 Minimum security requirements G. Piro, et al Expires April 21, 2014 [Page 9] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 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. With reference to secured 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 G. Piro, et al Expires April 21, 2014 [Page 10] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 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) 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 IEEE 802.15.4 domain A secured 802.15.4 domain is created by means of three different phases: setting-up, bootstrapping, and key negotiation. 6.1 Setting-up phase The setting-up phase is used to properly configure the device that will operate in an IEEE 802.15.4 network. 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, and (iii) the GlobalSecurityLevelsTable. This operation may be performed by the manufacturer or by the network administrator. The MasterKey can be used to generate two different keys: - the DefaultKey, exploited to protect broadcast messages (i.e., the beacon frame); - the LinkKey, used to encrypt and authenticate unicast packets (i.e., those exchanged between only two specific nodes). The GlobalSecurityLevelsTable, that has been reported in Fig. 3, 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 G. Piro, et al Expires April 21, 2014 [Page 11] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 security configuration defined in Sec. 5. The table reported in Fig. 3 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 3. Structure of the GlobalSecurityLevelsTable. The PrimeNumbersTable stores a set of prime numbers and their respective primitive roots, which are used during the key negotiation procedure. Its implementation is reported in Fig. 4. +----------------+--------------+----------------+ | PrimeNumberId | Prime Number | Primitive Root | +----------------+--------------+----------------+ | 1 | p1 | g1 | +----------------+--------------+----------------+ | 2 | p2 | g2 | +----------------+--------------+----------------+ : : +----------------+--------------+----------------+ | N | pN | gN | G. Piro, et al Expires April 21, 2014 [Page 12] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 +----------------+--------------+----------------+ Figure 4. Structure of the PimeNumbersTable. 6.2 Bootstrap phase for a FFD device The PAN is initialized by a FFD node. The MAC entity of the FFD node starts scanning the channel (for discovering the presence of other active coordinators and identifying the portion of the spectrum which it could operate in) after the reception of the MLME-START.request primitive, generated by the so called Next Higher Layer. Then, it will answer with a MLME-START.confirm primitive reporting a SUCCESS status. From this moment on, the device behaves as the PAN coordinator and it is able to select the identification number for the PAN, i.e., the PAN_ID, and the short MAC address of the IEEE 802.15.4 network [IEEE802154]. In this phase, the FFD generates the DefaultKey, D_k, and updates MAC security attributes accordingly. The DefaultKey, D_k, will be used to encrypt/decrypt all the broadcast messages. To this end, the following tasks will be executed. a) 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 | M_k). b) The FFD creates the KeyDescriptor associated to the DefaultKey, D_k, by following these steps: b.1) A new KeyIdLookupList data structure is created and stored within the KeyDescriptor element. 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]). b.2) 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. b.3) The DeviceDescriptorHandleList is left blank because the FFD does not yet know the list of devices that may use G. Piro, et al Expires April 21, 2014 [Page 13] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 this key. b.4) The DefaultKey, D_k, is stored within the Key field. c) The KeyDescriptor created in the previous step is added to the macKeyTable. d) The macDefaultKeySource is set to the MAC address of the device. 6.3 Bootstrap phase for a RFD device in a Beacon-enabled network To join the network, the RFD device should associate with the coordinator. The Next Higher Layer sends to the MAC entity the MLME-ASSOCIATE.request primitive, starting the association procedure. In this phase, the FFD generates the DefaultKey, D_k, and updates MAC security attributes accordingly. The DefaultKey, D_k, will be used to encrypt/decrypt all the broadcast messages. To this end, the following tasks will be executed: a) The RFD node receives a Beacon messages sent by the coordinator and extracts from it the PAN_ID, the MAC address of the coordinator and the FrameCounter of the received frame. b) A new DeviceDescriptor element, associated to the 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): b.1) The PANId variable is associated to the PAN_ID value extracted from the Beacon message. b.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. b.3) The ExtAddress is set to the IEEE MAC address of the coordinator. b.4) The FrameCounter parameter is set to the FrameCounter value extracted from the Beacon message. G. Piro, et al Expires April 21, 2014 [Page 14] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 b.5) The Extempt boolean flag is set to the allowed value of the DeviceOverriddeSecurityMinimum variable described in Fig. 2. 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 | M_k). d) The RFD creates the keyDescriptor associated to the DefaultKey, D_k, by following these steps: d.1) a new KeyIdLookupList data structure is created and stored within the KeyDescriptor element. 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 coordinator that sent the Beacon frame, 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]). d.2) 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. d.3) The DeviceDescriptorHandleList is created and populated with the pointer to the DeviceDescriptor created at the point 2. d.4) The DefaultKey, D_k, is stored within the Key field. e) The KeyDescriptor created in the previous step is added to the macKeyTable. f) The macDefaultKeySource is set to the MAC address of the coordinator. 6.4 Bootstrap phase for a RFD device in a not-Beacon-enabled network In the case the not-beacon-enabled scheme is enabled, the RFD device must explicitly request 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 G. Piro, et al Expires April 21, 2014 [Page 15] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 RFD node, srcMACaddress, as phi_k = H_128(srcMACaddress | M_K). The KeyIdMode of the Beacon Request packet is set to 00, thus enabling the coordinator to implicitly obtain the ephemeral key. Once received the Beacon frame, the RFD node will execute all the steps described in Sec. 6.3. 6.5 Key negotiation phase Since resource-constrained devices are unable to perform complex algorithms and protocols, a simple key agreement protocol is adopted during the execution of the key negotiation phase. A new command message, which is identified with a CommandFrameIdentifier set to 0xAA, is used for this purpose. 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. 5. The structure of the KeyGenControlField, instead, are shown in Fig. 6. The introduction of these new fields respects the constraints imposed by the standard about the maximum packet size. +--------------+--------------+--------------+----------------+ | Octects: 2 | 0/2 | 0/S | 0/16 | +--------------+--------------+--------------+----------------+ | KeyGen | Rand | Key | Authentication | | ControlFiled | | Material | Filed | +--------------+--------------+--------------+----------------+ Figure 5. A new command MAC frame adopted during the key negotiation phase. +--------+--------+--------+--------+--------+ | Bits: 2| 2 | 1 | 1 | 10 | +--------+--------+--------+--------+--------+ | Message| KeyGen | Key | Auth | Key | | Type | Mode | Flag | Flag | Size | +--------+--------+--------+--------+--------+ Figure 6. 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 G. Piro, et al Expires April 21, 2014 [Page 16] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 values: - MessageType=00 identifies a message storing key materials (i.e., DH parameters). - MessageType=01 identifies a message storing key materials belonging to a different approach selected before by the remote node. This message can be generate only by the FFD in the case the key negotiation algorithm chosen by the RFD is not supported. - MessageType=10 identifies final messages belonging to the key negotiation phase that are used to verify the mutual authentication of nodes. - MessageType=11 is reserved for future upgrades. - the KeyGenMode (2 bits long), which describes the algorithm adopted for key generation. In this Internet draft we describe a key negotiation procedure based on the DH algorithm, which is identified by the code 00. Other values, i.e., 01, 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. - the KeySize (10 bits long), which indicates the size of the transported key material. Its value is set to 0 in the case the message does not contain any key materials. 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. G. Piro, et al Expires April 21, 2014 [Page 17] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 6.5.1 Key exchange mechanism based on DH The key exchange mechanism based on the DH algorithm is reported in Fig. 7. It is initialized by the RFD device that wants to establish a secure link with the remote FFD. The procedure assumes that both RFD and FFD devices 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). The key exchange mechanism is provides the execution of these operations: a) The RFD identifies in the PrimeNumbersTable a prime number, P, and the corresponding primitive root, g, by extracting the latest P_bits bits from the output of the following hash function H_128(PAN_ID | D_k). b) The RFD computes the private key and the public key, according to the DH algorithm. Hence, the private key, PVK_RFD, is extracted as a random number. Then, the public key, PBK_RFD, is created as: PBK_RFD = g^PVK_RFD * mod P c) The RFD extract another random number, RAND_1, that will be used for the mutual authentication. d) The RDF sends its public key, PBK_RFD, to the remote FFD through a specific MAC command frame, which is composed by the following fields (see Fig. 7): MessageType=00, KeyGenMode=01, KeyFalg=TRUE, AuthFlag=FALSE, KeySize=S, Rand=RAND_1, and KeyMaterial=PBK_RFD. This message is encrypted with the DefaultKey, D_k. e) Once received the aforementioned MAC command frame, the FFD node generates, in turn, its private and public key through the DH algorithm. Hence, it identifies in the PrimeNumbersTable a prime number, P, and the corresponding primitive root, g, by extracting the latest P_bits bits from the output of the following hash function G. Piro, et al Expires April 21, 2014 [Page 18] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 H_128 (PAN_ID | D_k). Then, it generates a random variable, PVK_FFD, which is the private key and computes the public key, PBK_FFD, as in the following: PBK_FFD = g^PVK_FFD * mod P. f) The FFD extract another random number, RAND_2, that will be used for the mutual authentication; f) The RDF sends its public key, PBK_FFD, to the remote RFD through a specific MAC command frame, which is composed by the following fields (see Fig. 7): MessageType=00, KeyGenMode=01, KeyFalg=TRUE, AuthFlag=FALSE, KeySize=S, Rand=RAND_2, and KeyMaterial=PBK_FFD. This message is encrypted with the DefaultKey, D_k. h) The RFD computes the PreLinkKey, P_k P_k = PBK_FFD^PVK_RDF * mod P. i) The FFD computes the PreLinkKey, P_k, P_k = PBK_RFD^PVK_FFD * mod P. j) Both RFD and FFD devices computes the LinkKey by using the procedure described in Sec. 6.5.2 and update MAC security attributes according to procedures described in Secs. 6.5.3 and 6.5.4. k) The RFD node computes the authentication parameters, AUTH_RFD, through the 128-bit hash function, H_128(.), AUTH_RFD=H_128(P_k || RAND_2 || RAND_1). Then, it sends to the coordinator a new MAC command message to demonstrate its authenticity. This message is composed by the following fields (see Fig. 7): MessageType=10, KeyGenMode=01, KeyFalg=FALSE, AuthFlag=TRUE, KeySize=0, Rand=RAND_2, and AuthenticationField=AUTH_RFD. This message is protected by using the LinkKey computed before. l) The FFD node computes the authentication parameters, AUTH_FFD, through the 128-bit hash function, H_128(.) AUTH_FFD=H_128 (P_k || RAND_1|| RAND_2). G. Piro, et al Expires April 21, 2014 [Page 19] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 Then, it sends to the RFD node a new MAC command message to demonstrate its authenticity. This message is composed by the following fields(see Fig. 7): MessageType=10, KeyGenMode=01, KeyFalg=FALSE, AuthFlag=TRUE, KeySize=0, Rand=RAND_2, and AuthenticationField=AUTH_FFD. This message is protected through the LinkKey computed before. m) Both RFD and FFD verify the authenticity of the remote. RFD Device FFD Device | | | | compute DH | parameters | | | +--------- | | | | [MessageType=00, KeyGenMode=00, keyFlag=1 | | | AuthFlag=0, keySize=S, | messages | KeyMaterial=PBK_RFD, Rand=RAND_1 ] | encrypted with |-----------------------------------------> | the DefaultKey | | | | compute DH | | parameters | | | | | [MessageType=00, KeyGenMode=00, keyFlag=1 | | | AuthFlag=0, KeySize=S, | | | KeyMaterial=PBK_FFD, Rand=RAND_2 ] | | | <---------------------------------------- | | | | +-------- | | compute P_k compute P_k and LinkKey and LinkKey | | | | +--------- | | | | [MessageType=11, KeyGenMode=00, keyFlag=0 | | | AuthFlag=1, keySize=0, | messages | AuthenticationField=AUTH_RFD ] | encrypted with |-----------------------------------------> | the LinkKey | | | | | | | [MessageType=11, KeyGenMode=00, keyFlag=0 | | | AuthFlag=1, KeySize=0, | | | AuthenticationField=AUTH_FFD ] | | | <---------------------------------------- | G. Piro, et al Expires April 21, 2014 [Page 20] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 | | | +-------- | | V V Figure 7. Key exchange mechanism based on DH. 6.5.2 Generation of the LinkKeys The standard imposes to use the CCM* algorithm and a 128-bit key to protect MAC frames. Independently from the size the PreLinkKey, both RFD and FFD must create a set of link keys, each one 128 bits long. Firstly, each node computes a NewPreLinkKey, NP_k128, through the 128-bit hash function, H_128(.): NP_k128 = H_128(PAN_ID | P_k). The NP_k128 key will be used to compute LinkKeys. The CCM* algorithm assumes that each key must be used for a specific number of block ciphers. 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). Finally, both FFD and RFD devices update their MAC security attributes by using the procedures described in Secs. 6.5.3 and 6.5.4, respectively. 6.5.3 Update of MAC security attribute for the FFD node after the generation of the LinkKey After the calculation of the i-th LinkKey, the FFD updates its MAC security attributes as described in what follows. a) If i=1, a new DeviceDescriptor element, associated to the RFD node with which it has negotiated a link key, is created and stored into the macDeviceTable. 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 G. Piro, et al Expires April 21, 2014 [Page 21] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 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. b) The FFD creates the keyDescriptor associated to the i-th LinkKey, L_k, by following these steps: b.1) A new KeyIdLookupList data structure is created and stored within the KeyDescriptor element. 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 RFD node 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.2) 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. b.3) The DeviceDescriptorHandleList is created and populated with the pointer to the DeviceDescriptor created before. b.4) The i-th portion of the LinkKey, L_k, is stored within the Key field. c) The KeyDescriptor created in the previous step is added to the macKeyTable. G. Piro, et al Expires April 21, 2014 [Page 22] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 6.5.4 Update of MAC security attribute for the RFD node after the generation of the LinkKey After the calculation of the i-th LinkKey, the RFD updates its MAC security attributes as described in what follows: a) A keyDescriptor associated to the i-th LinkKey, L_k, is created by following these steps: a.1) a new KeyIdLookupList data structure is created and stored within the KeyDescriptor element. 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 RFD node, 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]). a.2) 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. a.3) The DeviceDescriptorHandleList is created and populated with the pointer to the DeviceDescriptor associate dto the coordinator. a.4) The i-th portion of the LinkKey, L_k, is stored within the Key field. b) The KeyDescriptor created in the previous step is added to 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 association phase, a device without security capabilities sends to the coordinator a Beacon Request message with the SecurityEnabled flag set to FALSE. G. Piro, et al Expires April 21, 2014 [Page 23] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 The FFD device then switches to the Hybrid Secure configuration and update all the MAC security attributes accordingly. From this moment on, the coordinator sends control messages in clear. G. Piro, et al Expires April 21, 2014 [Page 24] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 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 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 1 1995. [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, April 1 1996. 10.2 Informative References [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 1 2003. [RFC5513] Farrel, A., "IANA Considerations for Three Letter Acronyms", RFC 5513, April 1 2009. [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 2009. 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. Piro, et al Expires April 21, 2014 [Page 25] INTERNET DRAFT draft-piro-6tisch-security-issues-00 October 18, 2013 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 April 21, 2014 [Page 26]