CoRE Working Group Namhi Kang
Internet Draft Duksung Women's University
Intended status: Standard Track Seung-Hun Oh
Expires: August 11, 2014 Shimkwon Yoon
ETRI
February 11, 2014
Secure initial-key reconfiguration for resource constrained devices
draft-kang-core-secure-reconfiguration-01
Abstract
This document presents a secure method to configure 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."
This Internet-Draft will expire on August 11, 2014.
N. Kang. Expires August 11, 2014 [Page 1]
Internet-Draft Secure Reconfiguration February 2014
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 August 11, 2014 [Page 2]
Internet-Draft Secure Reconfiguration February 2014
Table of Contents
1. Introduction ................................................ 4
2. Terminology ................................................. 5
3. System Architecture ......................................... 7
4. Process Flow ................................................ 8
5. Security Considerations .................................... 10
6. IANA Considerations ........................................ 10
7. Acknowledgments ............................................ 11
8. References ................................................. 11
8.1. Normative References................................... 11
8.2. Informative References................................. 11
N. Kang. Expires August 11, 2014 [Page 3]
Internet-Draft Secure Reconfiguration 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 with
Internet as time goes by. This draft presents a simple but efficient
approach to reconfigure a secure 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) [CoAP].
Pre-shared key (PSK) based secure schemes are well known and
frequently used for various security services in Internet. All such
schemes strictly assume that the PSK is only known to two 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
bootstrapping 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
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
N. Kang. Expires August 11, 2014 [Page 4]
Internet-Draft Secure Reconfiguration February 2014
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"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.
SBI(i)
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.
SBR(c)
Shorten abbreviation of a secure bootstrapping respondent c; it
is generally regarded as a controller (not highly constrained) of
a service domain.
SBS(s)
Shorten abbreviation of a secure bootstrapping server s; it can
be an authenticated register or authentication server.
ID_A
Denoting 32bits identifier (ID) of entity A.
NID_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).
RN_A
N. Kang. Expires August 11, 2014 [Page 5]
Internet-Draft Secure Reconfiguration 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.
IK_N
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).
PSK
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.
A PSK can be used to derive session keys for various security
protocols designed by service administrator (see [RFC4764] for
example).
TS
Denoting time stamp of operation; it enables sender (TS
generator) to inform timeliness and uniqueness to receiver.
SK_cs
Denoting a 128bits symmetric key shared between entity c and s.
||
Notation used to denote concatenation of data.
V
Notation used to denote a logical operator Exclusive OR.
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.
N. Kang. Expires August 11, 2014 [Page 6]
Internet-Draft Secure Reconfiguration February 2014
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
keyboard).
As one of solutions, this document proposes a method which allows a
node to reconfigure a symmetric key (i.e. PSK) automatically upon
joining to existing network. After the reconfiguration 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 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 rolls
defined in a service domain. For example, a thermostat, which is 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 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 administrator.
In this scenario, the following transactions MUST be done prior to
the secure key reconfiguration.
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 can share
N. Kang. Expires August 11, 2014 [Page 7]
Internet-Draft Secure Reconfiguration February 2014
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). 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.
Some of the information for a node may be pre-configured by
manufacturer.
4. When a node joins to network, it knows NID of his associated
controller with which he can communicate. Also, authentication
server has lists of IDs for new nodes.
5. PSK reconfiguration phase is then started.
In order to make a practical and reasonable 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
regarded 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 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 1.
N. Kang. Expires August 11, 2014 [Page 8]
Internet-Draft Secure Reconfiguration February 2014
------- ------ ------
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, SK_cs) |
| |<-------------------------------|
| | |
| | |
| ID_c, E(RN_i || RN_c, IK_i)| |
|<---------------------------| |
| | |
| | |
| E(RN_c, PSK) | |
| -------------------------->| |
| | |
| | |
Figure 1 Message Exchange for PSK Reconfiguration
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). NID_SBR(c) has been pre-configured by installer of
the SBI(i) at the initial setup phase as specified in section 3 of
this draft.
Upon receiving the message, SBR(c) generates a random number RN_c and
a serial 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) does not covered in 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)
N. Kang. Expires August 11, 2014 [Page 9]
Internet-Draft Secure Reconfiguration February 2014
After reconfiguration of the PSK for node SBI(i), SBS(s) encrypts the
concatenation value of IK_i, ID_i and TID 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 and RN_c with key IK_i. Then it sends the encryption value
and his ID_c to SBI(i). Note that, SBR(c) does not transmit PSK over
the network.
SBI(i) can verify the SBR(c) by using the decrypted RN_i value from
the received message. Finally, SBI(i) can reconfigure his PSK
thereafter sending the encryption value of RN_c with the new key PSK
to SBR(c) for authenticity validation.
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 of data) in IoT. Because
small devices with low computing power and little storage are major
entities. 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
N. Kang. Expires August 11, 2014 [Page 10]
Internet-Draft Secure Reconfiguration February 2014
7. Acknowledgments
(TBD)
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.
[CoAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)", draft-ietf-core-
coap-18 (work in progress), June 2013.
[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 August 11, 2014 [Page 11]
Internet-Draft Secure Reconfiguration February 2014
Author's Addresses
Namhi Kang
Duksung Women's University
Seoul Korea
Email: kang@duksung.ac.kr
URI: http://www.duksung.ac.kr
Seung-Hun Oh
ETRI
1000-6 Oryong-dong, Buk-gu, Gwangju, 500-480,
Korea
Phone: +82-62-970-6655
Email: osh93@etri.re.kr
Shimkwon Yoon
ETRI
1000-6 Oryong-dong, Buk-gu, Gwangju, 500-480,
Korea
Phone: +82-62-970-6655
Email: skyoon@etri.re.kr
N. Kang. Expires August 11, 2014 [Page 12]