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

Versions: 00 01 02

  CORE Working Group                                           P. Urien
  Internet Draft                                      Telecom ParisTech
  Intended status: Experimental

                                                       December 22 2016
  Expires: June 2017

                           Identity Modules for CoAP
                   draft-urien-core-identity-module-coap-01.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 June 2017.

   .






   Urien                       Expires June 2017            [Page 1]


Copyright Notice

   Copyright (c) 2016 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 June 2017             [page 2]


                         Identity Modules for CoAP       December 2016

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 June 2017               [Page 3]


                         Identity Modules for CoAP       December 2016

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 June 2017               [Page 4]


                         Identity Modules for CoAP       December 2016

   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 June 2017               [Page 5]


                         Identity Modules for CoAP       December 2016


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 June 2017               [Page 6]


                         Identity Modules for CoAP       December 2016


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 June 2017               [Page 7]


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