Internet of Secure Elements
draft-urien-coinrg-iose-02

Document Type Active Internet-Draft (individual)
Author Pascal Urien 
Last updated 2021-06-02
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Research Task Force (IRTF)                          P. Urien 
  Internet Draft                                          Telecom Paris 
  Intended status: Experimental                             June 2 2021 
  Expires: December 2021                                                
 
 
                       Internet of Secure Elements 
                      draft-urien-coinrg-iose-02.txt 
    
    
Abstract 
    
   This draft defines an infrastructure for secure elements over 
   internet, and features needed for their secure remote use. 
   It describes a network architecture based on the TLS 1.3 protocol, 
   which enables remote calls of cryptographic procedures, identified 
   by Unified Resource Identifier (URI) such as 
   schemeS://sen@server.com:443/?query 
   The Internet of Secure Element (IoSE) is a set of secure elements 
   providing TLS servers, communication interfaces, and identified by 
   their name (Secure Element Name, sen). 
    
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 2021. 
    
   . 

   Urien                 Expires December 2021             [Page 1] 


Copyright Notice 
    
   Copyright (c) 2021 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 2021              [page 2] 

 
  Internet of Secure Elements                            June 2021 
 
Table of Contents 
   Abstract........................................................... 1 
   Requirements Language.............................................. 1 
   Status of this Memo................................................ 1 
   Copyright Notice................................................... 2 
   1 Overview......................................................... 4 
   2. About Secure Elements........................................... 5 
   3. Network Architecture............................................ 6 
   4 Unified Resource Identifier (URI)................................ 7 
   5 URI Example...................................................... 7 
   6 Overview of Internet Of Secure Elements Framework................ 8 
   7 Functional Entities.............................................. 9 
   8 IANA Considerations.............................................. 9 
   9 Security Considerations.......................................... 9 
   10 References..................................................... 10 
      10.1 Normative References...................................... 10 
      10.2 Informative References.................................... 10 
   11 Authors' Addresses............................................. 11 
 

   Urien              Expires December 2021              [Page 3] 

 
  Internet of Secure Elements                            June 2021 
 
1 Overview 
    
   This draft defines an infrastructure for the deployment of secure 
   elements over internet, and features needed for their secure remote 
   use. 
    
   Secure elements [ISO7816] are tamper resistant micro-controllers, 
   whose security Evaluation Assurance Levels (EAL) are in the range 
   EAL5+/EAL6+ according to Common Criteria standards [CC], which 
   define up to 7 levels. 
    
   This draft describes a network architecture based on the TLS 1.3 
   [RFC8446] protocol, which enables remote calls of cryptographic 
   procedures, identified by Unified Resource Identifier (URI) 
   [RFC3986]. 
    
   We believe that internet should provide to its users open computing 
   resources, with high security and trust levels. Many applications, 
   such as blockchain, require on-line trusted computing resources, 
   running cryptographic algorithms. 
    
    
                         TLS SNI                       SEN 
                       +--------+               +----------------+ 
                       | TCP/IP | Communication |   Application  | 
      server.com:443---+ Server +---------------+      TLS       | 
      SNI=SEN          |        |   Interface   | Secure Element | 
                       +--------+               +----------------+ 
                       server.com                   TLS Server 
    
                        schemeS://sen@server.com:port/?query 
    
   The network architecture comprises the following elements: 
   - Secure elements, identified by their name (Secure Element Name, 
   SEN) running embedded TLS servers and applications. 
   - TCP/IP servers, able to parse TLS ClientHello message, in order to 
   extract SNI (Server Name Indication) extension [RFC6066]. If the SNI 
   value matches the SEN value, the TLS packets are routed toward the 
   selected secure element. 
    
   The secure element URI [RFC3986] is 
   schemeS://sen@server.com:443/?query, in which: 
    
   - scheme indicates the application data interchange format, 
   - S means secured by TLS, 
   - sen is the secure element name included in the TLS SNI extension, 
   - server.com:port is a TCP/IP node and associated port 
   - query is the command to be executed by the secure element 
    

   Urien              Expires December 2021              [Page 4] 

 
  Internet of Secure Elements                            June 2021 
 
   TLS sessions MUST use mutual authentication between client and 
   server, either based either on pre-shared-key (PSK) or X509 
   certificates. 
    
   The TCP/IP server MAY manage multiple secure elements. As an 
   illustration, according to the IETF draft [RACS] a grid of Secure 
   Elements (GoSE) is a server hosting a set of secure elements. 
    
   In summary the Internet of Secure Element (IoSE) is a set of secure 
   elements providing TLS servers, communication interfaces, and 
   identified by their SEN name. 
    
2. About Secure Elements 
    
   Secure elements are defined according to [ISO7816] standards. Most 
   of them use 8 bits Micro Controller Unit (MCU) and embedded 
   cryptographic accelerator. Non volatile memory size is up to 100KB, 
   and RAM size is up to 10KB. Open software can be written thanks to 
   the JavaCard (JC) programming language, and associated API 
   frameworks such as JC3.04, JC3.05, JC3.1. 
    
   Secure elements are dedicated to cryptographic procedures; they are 
   available under multiples physical form factors, such as smartcard, 
   NFC chip, embedded SIM (eSIM), or surface-mount devices. 
    
   Secure elements have no network resources. They exchange small 
   messages (up to 256 bytes) over communication interfaces such as 
   ISO7816 (5 wires) [ISO7816], I2C (Inter-Integrated Circuit), or SPI 
   (Serial Peripheral Interface) [GP-SPI-I2C]. 
    
   Nevertheless they are able to process the TLS 1.3 protocol. For 
   example the IETF draft [TLS-SE] defines segmentation/reassembly 
   mechanisms over ISO7816, which enable exchange of TLS packets with 
   secure elements. The open project [TLS-SE-CODE] is an implementation 
   of [TLS-SE] for javacards. The open project [KEYSTORE-CODE] is an 
   implementation of secure element server. 
    
   Therefore secure element can be used as host, providing TLS server, 
   and communication interface. 
    
   They are several ways to provide a host name for a secure element 
   (i.e. a server name), which is referred as secure element name (SEN) 
   by this draft,: 
    
   - The [TLS-SE] draft uses historical bytes (up to 15 bytes) inserted 
   in the ISO7816 ATR (Answer To Reset), which is a response triggered 
   by a physical reset. A javacard application may define the value of 
   historical bytes. 
    
   - The [RACS] IETF draft describes Grid of Secure Elements (GoSE), 
   and introduces Secure Element Identifier (SEID) as unique identifier 

   Urien              Expires December 2021              [Page 5] 

 
  Internet of Secure Elements                            June 2021 
 
   indicating that a given SE is hosted by a GoSE. SEID also implicitly 
   refers the physical slot (SlotID) to which the secure element is 
   plugged. SEID MAY be used as SEN. 
    
    
3. Network Architecture 
    
   The network architecture is based on TLS1.3 servers and future 
   versions. 
    
   A TCP/IP node manages a server. According to [ESNI] TLS has two 
   working modes, shared and split. 
    
   - In Shared Mode, the provider is the origin server for all the 
   domains whose DNS records point to it. In this mode, the TLS 
   connection is terminated by the provider 
   - In Split Mode, the provider is not the origin server for private 
   domains.  Rather, the DNS records for private domains point to the 
   provider, and the provider's server relays the connection back to 
   the origin server, who terminates the TLS connection with the 
   client. 
    
   According to this terminology the secure element is the backend 
   server, identified by a server name (referred as SEN). 
    
   The client-facing server finds in the ClientHello message required 
   secure element name. Thereafter it performs segmentation/reassembly 
   operations in order to shuttle TLS packet over the communication 
   interface. 
    
   The client-facing server MAY also use encrypted server name 
   indication (ESNI) features in order to protect secure elements name. 
    
   The application-layer protocol negotiation extension (ALPN) 
   [RFC7301] MAY be used by secure element to select an internal 
   application. 
    
   TLS protocol MUST be used with mutual authentication between client 
   and secure element. PSK is a symmetric cryptographic scheme for one 
   client-to-one-secure-element, while PKI is an asymmetric 
   cryptographic scheme adapted to multiple-clients-to-one-secure-
   element. 
    
   Nevertheless it should be noticed that secure elements have not 
   clock and therefore are not able to check validity date or 
   certificate revocation. 
    
    
    
    
    

   Urien              Expires December 2021              [Page 6] 

 
  Internet of Secure Elements                            June 2021 
 
4 Unified Resource Identifier (URI) 
    
   According to [RFC3986] the URI comprises a scheme name ended by the 
   'S' character, the secure element name, the client-facing name and 
   port (server.com:port), and a query. 
    
   URI= schemeS://sen@server.com:port/?query 
    
   A client software entity able to process this URI, MUST retrieves 
   the PSK or the certificate chain to be used within the TLS protocol.  
    
   The secure element name MUST be included in the SNI extension. 
   The used scheme used by the query, MAY be included in the ALPN 
   extension. 
    
   For PSK it is possible, but not recommended for security reasons, to 
   include the PSK value in the URI: 
    
   schemeS://sen:psk@server.com:port/?query 
    
5 URI Example 
    
   A secure element implements a keystore, of which keys are identified 
   by an index. The secure element name is mykeystore 
    
   The secure element name is found in the historical bytes of the 
   ISO7816 ATR. 
    
   The client-facing server is server.com:443 
    
   The scheme used by the secure element is a shell, i.e. ASCII command 
   lines ended by line feed and carriage return characters. 
    
   The query 
   s010102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F20%
   0D%0A computes a signature command ('s' prefix) with key of index 
   01, over the 32 bytes value 0102...1920 
    
   The URI is: 
    
   shellS://mykeystore@server.com:443/?s010102030405060708090A0B0C0D0E0
   F101112131415161718191A1B1C1D1E1F20%0D%0A 
    
   The software client opens a TLS session with the server 
   server.com:443, with the name "mykeystore" inserted the SNI 
   extension. Upon success a TLS secure channel is established with the 
   secure element. The client sends the query, the secure element 
   computes the signature and returns its value encoded in hexadecimal 
   text. 
    
    

   Urien              Expires December 2021              [Page 7] 

 
  Internet of Secure Elements                            June 2021 
 
6 Overview of Internet Of Secure Elements Framework 
    
    
       +---------------------------------+ 
       |         User Application        | 
       +---------------------------------+ 
       |              APIs               | 
       +---------------------------------+ 
       |          TCP/IP Client          | 
       +---------------------------------+   +----------------+ 
       |          TCP/IP Server          |<--|                | 
       +---------------------------------+   | Administration | 
       |   Secure Element Application    |<--|                | 
       +---------------------------------+   +----------------+ 
       |     Secure Element Hardware     | 
       +---------------------------------+ 
    
    
   The goal of IOSE is to provide to internet users open computing 
   resources, with high security and trust levels. In order to reach 
   this objective, the IOSE framework comprises seven layers. 
    
   - The User Application layer uses secure resources hosted in the 
   internet 
   - The APIs layer provides software interface to virtual resources. 
   It SHOULD provide secure storage of credentials required by TLS 
   sessions. 
   - The TCP/IP client layer manages TLS session, according to profiles 
   compatible with secure element computing capacities. 
   - The TCP/IP server layer manages one or several secure elements. It 
   MAY provide privacy features such as server name encryption. 
   - The secure element application layer defines data interchange 
   format and available procedures 
   - The secure element hardware layer defines security profile 
   (according to common Criteria standards) and communication 
   interfaces 
   - The administration layer is in charge of secure elements 
   application deployment and lifetime. These operations are performed 
   locally or remotely (through the internet). 
    
    
    
    
    
    
    
    
    
    
    
    

   Urien              Expires December 2021              [Page 8] 

 
  Internet of Secure Elements                            June 2021 
 
7 Functional Entities 
    
           +---------------------------+    +-------------------+ 
           |                           |    |                   | 
           |  Infrastructure Provider  +----+  SE App Provider  | 
           |  (Secure Element Server)  |    |                   | 
           |                           |    +----------+--------+ 
           +------------+--------------+               | 
                        |                              | 
                        |                              | 
           +------------+--------------+               | 
           |                           |               | 
           |      Service Provider     +---------------+ 
           |   (Cloud Infrastructure)  | 
           |                           | 
           +------------+--------------+ 
                        | 
                        | 
           +------------+--------------+    +--------+ 
           |                           |    |        | 
           |    Application Provider   +----+  User  + 
           |                           |    |        | 
           +---------------------------+    +--------+ 
    
    
   The functional entities COULD involve five elements. 
    
   - The User is equipped with a connected device, executing an 
   application using IOSE services. 
    
   - The Application provider designs software, using IOSE 
   infrastructure. 
    
   - The Service Provider manages a cloud infrastructure, and all 
   facilities needed to setup secure element applications. An 
   attestation mechanism SHOULD be available in order to prove SE 
   application authenticity. 
    
   - The Infrastructure Provider provides secure element servers. 
    
   - The SE App Provider designs secure and trusted software for secure 
   elements. 
    
    
8 IANA Considerations 
    
   This draft does not require any action from IANA. 
    
9 Security Considerations 
    
   This entire document is about security. 

   Urien              Expires December 2021              [Page 9] 

 
  Internet of Secure Elements                            June 2021 
 
    
10 References 
    
10.1 Normative References 
    
   [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 
   Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 
   https://www.rfc-editor.org/info/rfc8446. 
    
   [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 
   Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, 
   January 2011. 
    
   [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 
   "Transport Layer Security (TLS) Application-Layer Protocol 
   Negotiation Extension", RFC 7301, July 2014 
    
   [RFC3986] Berners-Lee, Tim; Fielding, Roy T.; Masinter, Larry. 
   Uniform Resource Identifiers (URI): Generic Syntax. Internet 
   Engineering Task Force. doi:10.17487/RFC3986, January 2005 
    
   [ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards 
   with Contacts", The International Organization for Standardization 
   (ISO). 
    
   [CC] ISO/IEC 15408, "Common Criteria for Information Technology 
   Security Evaluation", The International Organization for 
   Standardization (ISO) 
    
   [GP-SPI-I2C] GlobalPlatform Technology, APDU Transport over SPI/I2C 
   Version 0.0.0.39", July 2019 
    
10.2 Informative References 
    
   [ESNI] "TLS Encrypted Client Hello", draft-ietf-tls-esni-10, 2021 
    
   [RACS] "Remote APDU Call Secure (RACS)",  draft-urien-core-racs-
   14.txt 
    
   [TLS-SE] IETF Draft, "Secure Element for TLS Version 1.3", draft-
   urien-tls-se-02.txt 
    
   [TLS-SE-CODE] "tls-se.java", https://github.com/purien/TLS-SE 
    
   [KEYSTORE-CODE] https://github.com/purien/keystore 
    
    
    
    
    
    

   Urien              Expires December 2021              [Page 10] 

 
  Internet of Secure Elements                            June 2021 
 
11 Authors' Addresses 
    
   Pascal Urien 
   Telecom Paris 
   19 place Marguerite Perey 
   23 avenue d'Italie 
   91120 Palaiseau           Phone: NA 
   France                    Email: Pascal.Urien@telecom-paris.fr 

   Urien              Expires December 2021              [Page 11]