[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
ACE Working Group                                           Namhi Kang
Internet Draft                              Duksung Women's University
Intended status: Informational                            Jaeduck Choi
Expires: April 22, 2015                                          NSRI
                                                        Seungwook Jung
                                                          Souhwan Jung
                                                          Younghan Kim
                                                   Soongsil University
                                                       October 23, 2014

        Security Key configuration for resource constrained devices


   This document presents a secure method to configure/reconfigure a key
   for a resource constrained node when it initially joins to network
   that is currently in operation. The method is suited for a scenario,
   where resource constrained nodes are interconnected with each other
   and thus form a network called Internet of Things. It is assumed that
   communications for all nodes are based on TCP/IP protocols and the
   nodes use the constrained application protocol (CoAP). The presented
   method does not cover all operations of secure bootstrapping for IoT
   networks, but it is intended to securely support self-reconfiguration
   of the pre-installed temporary key of joined node.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

N. Kang.               Expires April 22, 2015                 [Page 1]

Internet-Draft           Secure configuration            February 2014

   This Internet-Draft will expire on April 22, 2015.

Copyright 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.

N. Kang.               Expires April 22, 2015                 [Page 2]

Internet-Draft           Secure configuration            February 2014

Table of Contents

   1. Introduction ................................................ 4
   2. Terminology ................................................. 5
   3. System Architecture ......................................... 7
   4. Process Flow ................................................ 9
   5. Security Considerations..................................... 11
   6. IANA Considerations ........................................ 11
   7. Acknowledgments ............................................ 11
   8. References ................................................. 12
      8.1. Normative References................................... 12
      8.2. Informative References................................. 12

N. Kang.               Expires April 22, 2015                 [Page 3]

Internet-Draft           Secure configuration            February 2014

1. Introduction

   A rapidly growing number and various types of devices including smart
   small things such as sensors and actuators are trying to connect to
   the Internet as time goes by. This draft presents a simple but
   efficient approach to reconfigure a security key for resource
   constrained small things that are often defined as network nodes
   having 8 bit processing microcontrollers with limited amounts of
   memory. The network is also constrained one (e.g. 6LoWPAN having high
   packet error rates and a typical throughput of 10s of kbit/s)

   Pre-shared key (PSK) based secure schemes are well known and widely
   used for various security services in Internet. All such schemes
   strictly assume that the PSK is only known to the two communication
   entities involved in current security service. Consequently, the
   security of the schemes are compromised if the assumption is broken.

   However, it is still not clear how PSK of resource constrained node
   can be initially configured in a secure manner in Internet of things
   (IoT). Typically, things used for IoT might be manufactured and
   installed by different subjects (simply person) [SecCons]. That is,
   in general situation, a system administrator may make orders to
   several different installers. After that, each of the installers
   purchases one or more different set of things from one or more
   different manufacturers. It is also unlikely that a single subject
   installs all nodes used for a large application domain (e.g. all
   nodes in huge building).

   This draft considers a scenario, where nodes are initially configured
   by an installer (or a manufacturer in some cases) during enrolment
   phase (or manufacturing/factory configuration phase). If secure
   credential including PSK is required to be configured in this phase,
   the trust between installer (or manufacturer) and system
   administrator is extremely important. However, this is not easy
   process because manufacturer, installer and service provider do not
   share a tight and trust relationships in general cases. Even if the
   case is properly settled, there might be several secure threats and
   vulnerabilities to be handled.

   As a conceptual solution, this draft presents an initial setup method
   that might be a part of secure bootstrapping scheme. The basic idea
   of the method specified in this document is motivated from a lock of

N. Kang.               Expires April 22, 2015                 [Page 4]

Internet-Draft           Secure configuration            February 2014

   suitcase. Simple and default password such as '0000' or '1234' is
   initially setup on a lock of suitcase in selling. Owner can change
   the password after purchasing. In our method, similarly, initial key
   of a node is configured by installer during bootstrapping phase. When
   the node join to an existing network, the key (i.e. PSK) can be
   securely reconfigured.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119] when they appear in ALL CAPS. These words may also appear
   in this document in lower case as plain English words, absent their
   normative meanings.

   This draft uses notations and abbreviations as follows.


       Shorten abbreviation of a secure bootstrapping initiator i (i.e.
       new node required to be reconfigured); it is a constrained device
       having poor input/output interfaces.


       Shorten abbreviation of a secure bootstrapping respondent c; it
       is generally regarded as a controller (not highly constrained) of
       a service domain.


       Shorten abbreviation of a secure bootstrapping server s; it can
       be an authenticated register or authentication server.


       Denoting 32bits identifier (ID) of entity A.


       Denoting network ID used for access to communication entity A; it
       can be a socket ID (i.e. IPv4 or IPv6 address and port number).


N. Kang.               Expires April 22, 2015                 [Page 5]

Internet-Draft           Secure configuration            February 2014

       Denoting 128bits integer used for a secure random number
       generated by entity A; for example, a random number generated by
       SBI is referred to as RN_i.


       Denoting 128bits symmetric key pre-installed by installer or
       manufacturer for node N; the key is used for a partial
       transaction of mutual authentication and derivation of PSK (see
       section 4 in detail).


       Shorten abbreviation of a 128bits pre-shared key derived from the
       IK. The PSK is a shared key between a node and authenticated
       register (or authentication server) in a specific service domain.


       Shorten abbreviation of a 128bits session key for i^th session. A
       PSK can be used to derive session keys for various security
       protocols designed by service administrator (see [RFC4764] for


       Denoting 128bits symmetric key generated by authentication server
       (i.e. SBS(s) in this draft) or system administrator to protect
       the PSK stored in node N.


       Denoting time stamp of operation; it enables sender (TS
       generator) to inform timeliness and uniqueness to receiver.


       Denoting a 128bits symmetric key shared between entity c and s.


       Notation used to denote concatenation of data.


       Notation used to denote a logical operator Exclusive OR.

N. Kang.               Expires April 22, 2015                 [Page 6]

Internet-Draft           Secure configuration            February 2014

   E(M, SK)

       Denoting a function to encrypt a plain text 'M' by using a
       symmetric key SK.

   D(C, SK)

       Denoting a function to decrypt a cipher text 'C' by using a
       symmetric key SK.

   Other security related terminologies used in this document are based
   on [RFC4949].

3. System Architecture

   Secure bootstrapping is regarded as a difficult problem in Internet
   of Things. This is mainly because lots of things connected to
   Internet are resource constrained. Especially, user-device interfaces
   they have are not enough for doing configurations manually by person
   (i.e. inadequate or even no input/output equipment such as display or

   As one of solutions, this document proposes a method which allows a
   node to reconfigure a symmetric key (i.e. pre-installed key in
   enrolment phase) automatically upon joining to existing network.
   After the secure configuration phase, an installer (or manufacturer)
   cannot read/modify/insert any communication data even though he did
   initial pre-setup of secure credential of communicating nodes.

   The following figure illustrates simplified lifecycle of a
   constrained nodes.

                  |Re-Ownership|          |Re-Bootstrap|

                         |                      |

                         V                      V

   |Manufacture| --> |Install| --> |Bootstrapping| --> |Operation|

   <--- Enrolment Phase ---->      <-- Handled by System Admin ->

           Figure 1. Simplified lifecycle of a constrained nodes

N. Kang.               Expires April 22, 2015                 [Page 7]

Internet-Draft           Secure configuration            February 2014

   The method of this document is based on a straightforward scenario,
   where resource constrained things such as sensors or actuators are
   generally designed and manufactured according to their own specific
   tasks in advance. Also, a pre-defined controller covers and
   communicates with his associated things according to his roles (or
   policy) defined in a service domain. For example, a thermostat, which
   can be a controller, manages and communicates several temperature
   sensors, humidity sensors, window handle devices, heating controller,
   air conditioner, and more.

   This document does not assume that a system administrator trusts an
   installer (or manufacturer) even though he makes orders for the
   installer. This is because trust and responsibility of installer, who
   buys and install devices, are different from those of system

   In this scenario, the following transactions MUST be done prior to
   the secure key reconfiguration (i.e. procedures in enrolment Phase).

      1. System administrator makes orders and requests initial setup of
         devices to an installer. Pre-setup information is a set of
         values that include ID and NID of controller for each of the
         devices, and a temporary key used as an initial key (i.e. IK_N).
         Note that, all devices handled by a single installer may share
         the same IK_N. This concept is similar to the default password
         for all suitcases manufactured by a single company.

      2. System administrator also stores the same initial information
         for each of nodes in authentication server (or authenticated
         register). The administrator may utilize procedures (e.g. web
         based registration) managed by manufacturer to get the
         information. Note that a controller can also perform operations
         of an authentication server in case of a small network.

      3. Installer purchases devices and then configures the information
         requested by the administrator in doing installation phase (a
         part of enrolment phase). Some of the information for a node
         may be pre-configured by manufacturer.

      4. When a node joins to network, it knows NID of its associated
         controller with which he can communicate. Also, authentication
         server has lists including node ID and pre-installed key for
         new nodes.

      5. PSK reconfiguration phase can be then started.

N. Kang.               Expires April 22, 2015                 [Page 8]

Internet-Draft           Secure configuration            February 2014

   In order to make a practical and efficient method, the proposed
   method requires only a single cryptographic primitive that is AES
   with 128bits length of key [AES]. All cryptographic primitives cannot
   be installed on resource restricted devices, mainly because of
   limited size of flash or RAM. For this reason, CoAP also does not
   consider all modes of cryptographic operations in DTLS which is a
   recommended secure protocol for CoAP applications. In case of
   establishing a CoAP session using a pre-shared key mod of DTLS,
   implementation of cipher suite TLS_PSK_WITH_AES_128_CCM_8 specified
   in [RFC6655] is mandatory.

4. Process Flow

   There are three message exchanges between a new node SBI(i) and
   network node(s) (i.e. SBR(c) and SBS(s)). A controller SBR(c) may
   include functions of both SBR(c) and SBS(s) depending on the size of
   application domain or the ability of SBR (i.e. computing power and
   memory). Mutual authentication and PSK reconfiguration procedures are
   shown in Figure 2.

   -------                       ------                          ------
    SBI(i)                        SBR(c)                          SBS(s)
   -------                       ------                          ------
     |                             |                                |
     |         ID_i, RN_i          |                                |
     | --------------------------->|                                |
     |                             |ID_i, ID_c, RN_i, RN_c, TS, TID |
     |                             |------------------------------->|
     |                             |                                |
     |                             |                                |
     |                             | E(IK_i||ID_i||TID||AK_i, SK_cs)|
     |                             |<-------------------------------|
     |                             |                                |
     |                             |                                |
     |ID_c,E(RN_i||RN_c||AK_i,IK_i)|                                |
     |<--------------------------- |                                |
     |                             |                                |
     |                             |                                |
     |       E(RN_c, PSK)          |                                |
     | --------------------------->|                                |
     |                             |                                |
     |                             |                                |

             Figure 2. Message Exchange for PSK Reconfiguration

N. Kang.               Expires April 22, 2015                 [Page 9]

Internet-Draft           Secure configuration            February 2014

   When a new node SBI(i) joins an existing network, he generates a
   random number RN_i and sends it with his identifier ID_i to his
   controller SBR(c). The NID_of SBR(c) (i.e. IP address and port
   number) has been pre-configured by installer of the SBI(i) in the
   enrolment phase as specified in section 3 of this draft.

   Upon receiving the message, SBR(c) generates a random number RN_c and
   a sequence number used as a transaction ID (i.e. TID). Then he sends
   the two values with his ID_c, time stamp (TS) and the message
   received from SBI(i) to the authentication server SBS(s). TS allows
   SBR(s) to derive the valid time of key and verify the freshness of
   the arrived message. Specific period of the expiration of key (i.e.
   PSK) is out of scope of this document.

   The authentication server SBS(s) first discovers the IK_i for node
   ID_i in his secure repository. SBS(s) now can derive a new PSK for
   the node SBI(i) and replace the IK_i with the PSK, where the PSK for
   SBI(i) is derived as follows.

       PSK_i = E(RN_i V RN_c, IK_i)

   After the reconfiguration of PSK for node SBI(i), SBS(s) generates a
   AK_i which is a secret key (or password). The AK_i is used for
   protecting PSK_i to be stored in constrained Node i. All nodes
   covered by SBS(s) can share a single AK_i or SBS(s) can generate a
   key for each of the nodes depending on service or security policy.
   Finally, SBS(s) encrypts the concatenation value of IK_i, ID_i, TID
   and AK_i with the symmetric key SK_cs which is a shared key between
   SBS(s) and SBR(c). This is because SBR(c) does not have the key IK_i
   at this moment. SBS(s) then sends the encrypted value to SBR(c).

   On receiving the encrypted value from SBS(s), SBR(c) can know the key
   IK_i thereby calculating PSK. SBR(c) encrypts the concatenation value
   of RN_i, RN_c and AK_i with the key IK_i. Then it sends both the
   encrypted value and his ID_c to SBI(i). Note that, SBR(c) MUST not
   transmit the derived PSK over the public network.

   SBI(i) can verify the authenticity of SBR(c) by using the decrypted
   RN_i value from the received message. Finally, SBI(i) can configure
   his PSK thereafter sending the encryption value of RN_c with the new
   key PSK to SBR(c) for the authenticity validation. SBI(i) derives a
   session key SK_i from the PSK and then reconfigures his secure
   credential as follows.

       IK_i <-- E(PSK, AK_i)

N. Kang.               Expires April 22, 2015                [Page 10]

Internet-Draft           Secure configuration            February 2014

   After that, SBI(i) deletes AK_i which is only stored in SBS(s). This
   is because small device is generally more vulnerable to various
   physical attacks such as theft and forgery than SBS(s). When a node
   needs to reconfigure such secure parameters, SBS(s) must send the
   encrypted AK_i.

5. Security Considerations

   The method of this draft uses a single cryptographic primitive AES
   [AES] which is used for secure bootstrapping (exactly in the PSK
   reconfiguration phase). Single cryptographic primitive implementation
   is rationally suited for the scenario where applications or services
   require a secure session (confidentiality and integrity of data) in
   IoT. Because small devices with low computing power and little
   storage are major entities in IoT. According to a full bootstrapping
   policy, the PSK can be used for mechanisms of session key derivation
   and/or entity authentication.

   As discussed in ESP-PSK [RFC4764], it goes without saying that a
   single cryptographic primitive may not support extensible security
   services such as identity protection, perfect forward secrecy and
   others. However, small devices consisting of Internet of Things might
   not support all of security services inherently. Service developer
   should therefore define a scope of his service strictly and consider
   trade-off between capability and security.

   Security analysis and evaluation of various aspects of the method
   remain to be done.

6. IANA Considerations

   This memo includes no request to IANA

7. Acknowledgments


N. Kang.               Expires April 22, 2015                [Page 11]

Internet-Draft           Secure configuration            February 2014

8. References

       8.1. Normative References

   [RFC4764] F. Bersani, H. Tschofenig, "The EAP-PSK Protocol: A Pre-
             Shared Key Extensible Authentication Protocol (EAP) Method",
             RFC 4764, January 2007.

   [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
             4949, August 2007.

   [RFC6655]  McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
             Transport Layer Security (TLS)", RFC 6655, July 2012.

   [RFC7252] Shelby, Z., Hartke, K., and Bormann, C., "The Constrained
             Application Protocol (CoAP)", RFC 7252, June 2014.

   [SecCons] O. Garcia-Morchon, S. Kumar, S. Keoh, R. Hummen, R. Struik,
             "Security Considerations in the IP-based Internet of
             Things", Internet draft (draft-garcia-core-security-06),
             September 2013.

   [AES] National Institute of Standards and Technology, "Specification
             for the Advanced Encryption Standard (AES)", Federal
             Information Processing Standards (FIPS) 197, November 2001.

       8.2. Informative References

   [RFC2119] S. Brander, "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

N. Kang.               Expires April 22, 2015                [Page 12]

Internet-Draft           Secure configuration            February 2014

Author's Addresses

   Namhi Kang
   Duksung Women's University
   Seoul Korea
   Email: kang@duksung.ac.kr
   URI:  http://www.duksung.ac.kr

   Jaeduck Choi
   NSRI (National Security Research Institute)
   Daejeon, Korea
   Email: cjduck@ensec.re.kr

   Seungwook Jung
   Soongsil University
   Seoul Korea
   Email: seungwookj@ssu.ac.kr

   Souhwan Jung
   Soongsil University
   Seoul Korea
   Email: souhwanj@ssu.ac.kr

   Younghan Kim
   Soongsil University
   Seoul Korea
   Email: younghak@ssu.ac.kr

N. Kang.               Expires April 22, 2015                [Page 13]