CORE Working Group P. Urien
Internet Draft Telecom ParisTech
Intended status: Experimental
June 22 2017
Expires: December 2017
Identity Modules for CoAP
draft-urien-core-identity-module-coap-02.txt
Abstract
This document defines identity modules based on Secure Elements
processing DTLS/TLS stacks for CoAP devices. The expected benefits
of these secure microcontrollers are the following :
- Secure storage of pre-share keys or private keys
- Trusted simple or mutual authentication between CoAP devices and
CoAP clients.
- The device identity is enforced by a non cloneable chip.
- Trusted cryptographic support.
- Low power consumption for DTLS/TLS processing.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Status of this Memo
This Internet-Draft is submitted 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 December 2017.
.
Urien Expires June 2017 [Page 1]
Copyright Notice
Copyright (c) 2017 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.
Urien Expires December 2017 [page 2]
Identity Modules for CoAP June 2017
Table of Contents
Abstract........................................................... 1
Requirements Language.............................................. 1
Status of this Memo................................................ 1
Copyright Notice................................................... 2
1 Overview......................................................... 4
2 What is a Secure Element......................................... 4
3 Identity Module for CoAP......................................... 6
4 DTLS/TLS profile for CoAP security modules....................... 6
5 IANA Considerations.............................................. 6
6 References....................................................... 7
6.1 Normative References........................................ 7
6.2 Informative References...................................... 7
7 Authors' Addresses............................................... 7
Urien Expires December 2017 [Page 3]
Identity Modules for CoAP June 2017
1 Overview
The CoAP [CoAP] protocol MAY be secured by the DTLS protocol [DTLS]
over an UDP/IP stack; the TLS support [TLS] is also under definition
[CoAP-TLS] over a TCP/IP stack.
According to [CoAP] four security modes are available, NoSec,
PreSharedKey, RawPublicKey, and Certificate. When DTLS is used with
the PreShareKey or Certificate modes there is a need to store
secrets such as symmetric or asymmetric keys, which authenticate the
CoAP device.
In that case a Secure Element (SE) MAY be used in order to fully run
the DTLS or TLS protocol. According to the data throughput or other
security considerations the DTLS/TLS session MAY be exported from
the secure element after the exchange of the finished messages.
This class of Secure Element is referred by this draft as an
identity module (IdMod).
The expected benefits of identity modules are the following :
- Secure storage of pre-share keys or private keys
- Trusted simple or mutual authentication between the CoAP device
and the CoAP client.
- The device identity is enforced by a non cloneable identity
module.
- Trusted cryptographic support.
- Low power consumption for DTLS/TLS processing.
2 What is a Secure Element
A Secure Element (SE) is a tamper resistant microcontroller (see
figure 1) equipped with host interfaces such as [ISO7816], SPI
(Serial Peripheral Interface) or I2C (Inter Integrated Circuit).
The typical area size of these electronic chips is about 5x5 mm2.
They comprise CPU (8, 16, 32 bits), ROM (a few hundred KB), non
volatile memory (EEPROM, FLASH, a few hundred KB) and RAM (a few ten
KB). Security is enforced by multiple hardware and logical
countermeasures.
According to the [EUROSMART] association height billion of such
secure devices were shipped in 2013. Secure elements are widely
deployed for electronic payment (EMV cards), telecommunication (SIM
modules), identity (electronic passports), ticketing, and access
control (PKCS15 cards).
Most of secure elements include a Java Virtual Machine (JVM) and
therefore are able to execute embedded program written in the
JAVACARD language. Because these devices are dedicated to security
Urien Expires December 2017 [Page 4]
Identity Modules for CoAP June 2017
purposes they support numerous cryptographic resources such as
digest functions (MD5, SHA1, SHA2...), symmetric cipher (3xDES, AES)
or asymmetric procedures (RSA, ECC).
A set of Global Platform [GP] standards control the lifecycle of
embedded software, i.e. application downloading, activation and
deletion.
As an illustration a typical low cost Secure Element has the
following characteristics:
- JAVACARD operating system;
- Compliant with the GP (Global Platform) standards;
- 160 KB of ROM;
- 72 KB of EEPROM;
- 4KB of RAM;
- Embedded crypto-processor;
- 3xDES, AES, RSA, ECC;
- Certification according to Common Criteria (CC) EAL5+ level;
- Security Certificates from payment operators.
According to the state of art, TLS/DTLS stacks may run in secure
elements, for example written as a javacard applications.
+-----+ +-----+ +-----+ +---------------------+
ISO <=>| IO | | CPU | | ROM | | Non Volatile Memory |
7816 +--+--+ +--+--+ +--+--+ +----------+----------+
| | | |
======+===+=====+=========+================+=+==========
| | |
+------+------+ +-----+-----+ +-------+-------+
| Security | | Crypto | | Random Number |
| Register | | Processor | | Generator |
+-------------+ +-----------+ +---------------+
Figure 1. A typical hardware architecture of a Secure Element
Urien Expires December 2017 [Page 5]
Identity Modules for CoAP June 2017
3 Identity Module for CoAP
Open
Open | Decrypt(CoAP)
| Send-Flight | | Encrypt(CoAP)
| | Recv-Flight | | | Close Reset
| | | Close | | | | | Process
| | | | | | | | | |
+-V-V-V-V-+ +--V-V-V-V--+ EAP over +- V----V--+
TCP/ | Socket | DTLS/TLS | DTLS/TLS | ISO7816 | Identity |
UDP <=>| Agent | flights | ISO7816 | Messages | Module |
IP | | <======> | Agent | <=======> | |
+---------+ +-----------+ +----------+
Figure 2. CoAP Identity module framework
ISO7816 interface for Secure Elements providing TLS/DTLS stacks are
detailed in [DTLS/TLS-SM]. The Identity module MUST support two
commands Reset and Process.
TLS/DTLS packets are transported by the EAP protocol over ISO7816
messages. This mechanism previously detailed by [EAPSC] provides a
double segmentation procedure thanks to EAP and ISO7816 facilities.
A DTLS/TLS-ISO7816 software agent sends and receives DTLS/TLS
flights to/from sockets over EAP/ISO7816 messages to/from the
identity module. Conceptually this component interface SHOULD have
four procedures Open, Close, Encrypt and Decrypt.
A socket software agent extracts and send DTLS/TLS flights from/to
UDP/TCP packets. Conceptually this component interface SHOULD have
four procedures Open, Close, Recv-Flight, Send-Flight.
4 DTLS/TLS profile for CoAP security modules
To be done.
5 IANA Considerations
This draft does not require any action from IANA.
Urien Expires December 2017 [Page 6]
Identity Modules for CoAP June 2017
6 References
6.1 Normative References
[TLS] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 5746, August 2008
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014.
[CoAP-TLS] A TCP and TLS Transport for the Constrained Application
Protocol (CoAP), draft-ietf-core-coap-tcp-tls-02, April 2016.
[ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards
with Contacts", The International Organization for Standardization
(ISO).
6.2 Informative References
[GP] Global Platform Standards, http://www.globalplatform.org
[EUROSMART] The EUROSMART association, http://www.eurosmart.com
[DTLS/TLS-SM] Urien, P., "TLS and DTLS Security Modules", draft-
urien-uta-tls-dtls-security-module-03.txt, December 2016
[EAPSC] Urien, P., "EAP Support in Smartcard", draft-urien-eap-
smartcard-32.txt, December 2016
7 Authors' Addresses
Pascal Urien
Telecom ParisTech
23 avenue d'Italie
75013 Paris Phone: NA
France Email: Pascal.Urien@telecom-paristech.fr
Urien Expires December 2017 [Page 7]