Internet DRAFT - draft-urien-coinrg-iose

draft-urien-coinrg-iose




    

  Internet Draft                                               P. Urien 
  Intended status: Experimental                           Telecom Paris 
  Expires: August 2024                                    February 2024 
                                                                        
 
 
                       Internet of Secure Elements 
                      draft-urien-coinrg-iose-08.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 August 2024 
    
    







   Urien                      Expires August 2024             [Page 1] 
    

Copyright Notice 
    
   Copyright (c) 2024 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 August 2024              [page 2] 
 
  Internet of Secure Elements                          February 2024 
 
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 Attestation Procedure............................................ 9 
      8.1 Service Request............................................ 11 
      8.2 SE-App Downloading......................................... 11 
      8.3 SE-App Certificate......................................... 11 
      8.4 User Notification.......................................... 12 
      8.5 User Enrollment............................................ 12 
   9 IANA Considerations............................................. 12 
   10 Security Considerations........................................ 12 
   11 References..................................................... 12 
      11.1 Normative References...................................... 12 
      11.2 Informative References.................................... 13 
   12 Authors' Addresses............................................. 13 
 



























   Urien                   Expires August 2024              [Page 3] 
 
  Internet of Secure Elements                          February 2024 
 
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 August 2024              [Page 4] 
 
  Internet of Secure Elements                          February 2024 
 
   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. The open project [IOSE-
   CODE] is a demonstrator for Internet of Secure Elements. 
    
   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. 
    


   Urien                   Expires August 2024              [Page 5] 
 
  Internet of Secure Elements                          February 2024 
 
   - The [RACS] IETF draft describes Grid of Secure Elements (GoSE), 
   and introduces Secure Element Identifier (SEID) as unique identifier 
   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 August 2024              [Page 6] 
 
  Internet of Secure Elements                          February 2024 
 
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 August 2024              [Page 7] 
 
  Internet of Secure Elements                          February 2024 
 
6 Overview of Internet Of Secure Elements Framework 
    
    
       +---------------------------------+ 
       |         User Application        | 
       +---------------------------------+ 
       |              APIs               | 
       +---------------------------------+ 
       |          TCP/IP Client          | 
       +---------------------------------+   +----------------+ 
       |          TCP/IP Server          |<--|                | 
       +---------------------------------+   | Administration | 
       |   Secure Element Application    |<--|     (RACS)     | 
       +---------------------------------+   +----------------+ 
       |     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 August 2024              [Page 8] 
 
  Internet of Secure Elements                          February 2024 
 
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 (AP) designs software, using IOSE 
   infrastructure. 
    
   - The Service Provider (SP) manages a cloud infrastructure, and all 
   facilities needed to setup secure element applications. An 
   attestation mechanism MUST be available in order to prove SE 
   application authenticity. 
    
   - The Infrastructure Provider (IP) provides secure element servers. 
    
   - The SE-App Provider (SE-AppP) designs secure and trusted software 
   (SE-App) for secure elements. 
    
8 Attestation Procedure 
    
   The goal of the attestation procedure is to allocate a secure 
   element, and to prove to its user the exclusive access to a genuine 
   secure element. 
    
    
    

   Urien                   Expires August 2024              [Page 9] 
 
  Internet of Secure Elements                          February 2024 
 
    
    SE-App Provider    Infrastructure   Secure    
       Provider           Provider      Element   
         |                    |            |      
         | RACS: Download --->|----------->|Private and Public Key 
         | TLS-PSK App in SE  |            |Generation 
         | With PSK-Provider  |            |TLS-PSK Ready 
         | <--------------Done|<-------Done|  
         |                    |            |  
         | RACS: Link  ------>|            |  
         | SEN to SEID        |            |  
         | <--------------Done|            |  
         |                    |            |  
         | TLS-PSK:  ---------|----------->|  
         | Read Public Key    |            |  
         | <------------------|--------Done|  
         |                    |            |  
         | Generate           |            |  
         | Certificate        |            |  
         |                    |            |  
         | TLS-PSK:    -------|----------->|  
         | Write Certificate  |            |  
         | <------------------|------- Done|  
         | 
         | SEND ------------------------------------------------->| 
         | PSK-Provider & SEN                                     | 
                                        Secure                  User 
                                        Element                   | 
                                           |<---------Open TLS-PSK| 
                                           |Compute        Compute| 
                                           |HS                  HS| 
                                           |<---TLS-PSK Opened--->| 
                                           |                      | 
                                           |<------Read Public Key| 
                                           |Done----------------->| 
                                           |                      | 
                                           |<-----Read Certificate| 
                                           |Done----------------->| 
                                           |                      | 
                                           |     Check Certificate| 
                                           |                      | 
                                           |<-------------Send rnd| 
                                           |Compute               | 
                                           |Sign(HS | rnd)        | 
                                           |Send Sign------------>| 
                                           |                      | 
                                           |            Check Sign| 
                                           |                      | 
                                           |<-------Write PSK-User| 
                                           |Done----------------->| 
    

   Urien                   Expires August 2024              [Page 10] 
 
  Internet of Secure Elements                          February 2024 
 
8.1 Service Request 
    
   The User requests to an on-line Service Provider a secure element 
   for a specific application. 
    
8.2 SE-App Downloading 
    
   The Service Provider requests the SE-App Provider to download the 
   user's application in a secure element hosted by an Infrastructure 
   Provider. 
    
   The SE-App Provider downloads the selected application thanks to 
   protocols such as [RACS]. 
    
   There is a mutual authentication between SE-App Provider and 
   Infrastructure Provider. The SE-App Provider owns a set of secure 
   elements identified by their SEID (Secure Element Identifier). He 
   may erase their content and write binary image, but he can't read 
   binary images. 
    
   The SE-App includes a TLS 1.3 server with a pre shared key (PSK-App-
   Provider) and a server name (SEN). Upon instantiation, the 
   downloaded SE-App generates a pair of private key (SE-App-Priv-Key) 
   and public key (SE-App-Pub-key). 
    
   Thanks to a dedicated [RACS] command, the SE-APP provider notifies 
   to the Infrastructure Provider the SEN associated to the secure 
   element SEID. 
    
   At this step the secure element is on-line, and may process TLS 
   sessions, with the right server name (SEN), and authenticated by 
   PSK-App-Provider. 
    
   The PSK-App provider has the exclusive knowledge of the pre-shared-
   key, and consequently is the only entity able to communicate with 
   the secure element. 
    
    
8.3 SE-App Certificate 
    
   The SE-App Provider opens a TLS (with PSK= PSK-App-Provider) session 
   with the SEN secure element, reads its SE-App-Pub-key, and computes 
   a certificate (SE-Cert) for this public key. 
    
   The SE-Cert is remotely written in the secure element 
    
   The SE-App provider forwards the secure element URI and PSK-App-
   Provider to the Service Provider or to the User, according to pre-
   defined agreements. 
    


   Urien                   Expires August 2024              [Page 11] 
 
  Internet of Secure Elements                          February 2024 
 
8.4 User Notification 
    
   The User receives the secure element URI and pre-shared-key (i.e. 
   PSK-App-Provider). 
    
8.5 User Enrollment 
    
   A secure element only manages a unique TLS session at a given time. 
    
   The User opens a TLS session with the secure element (with PSK-App-
   Provider and SEN). According to [RFC8446] a TLS handshake secret 
   (HS) is computed from the Diffie-Hellman exchange. 
    
   He reads the secure element public key (SE-App-Pub-key) and its 
   certificate (SE-Cert) 
    
   He checks the certificate SE-Cert with the Infrastructure Provider 
   public key. 
    
   He performs the attestation procedure that sends a random value 
   (RND) to the secure element. The secure element returns a signature 
   of the concatenation of HS and RND values, computed with the private 
   key SE-App-Priv-key. 
    
   He checks the signature with the public key SE-App-Pub-key. 
    
   At this point the User has the proof that it shares an exclusive TLS 
   session with the secure element. 
    
   The user sets the pre-share-key value to new one: PSK-User-Provider. 
    
   At this step the User has the exclusive access to a genuine secure 
   element. 
    
    
9 IANA Considerations 
    
   This draft does not require any action from IANA. 
    
10 Security Considerations 
    
   This entire document is about security. 
    
11 References 
    
11.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. 
    

   Urien                   Expires August 2024              [Page 12] 
 
  Internet of Secure Elements                          February 2024 
 
   [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 
    
11.2 Informative References 
    
   [ESNI] "TLS Encrypted Client Hello", draft-ietf-tls-esni-17, 2023 
    
   [RACS] "Remote APDU Call Secure (RACS)", draft-urien-core-racs-
   19.txt, February 2024 
    
   [TLS-SE] IETF Draft, "Secure Element for TLS Version 1.3", draft-
   urien-tls-se-07.txt, October 2023 
    
   [TLS-SE-CODE] "tls-se.java", https://github.com/purien/TLS-SE 
    
   [KEYSTORE-CODE] https://github.com/purien/keystore 
    
   [IOSE-CODE] https://github.com/purien/iose 
    
12 Authors' Addresses 
    
   Pascal Urien 
   Telecom Paris 
   19 place Marguerite Perey 
   91120 Palaiseau           Phone: NA 
   France                    Email: Pascal.Urien@telecom-paris.fr 






   Urien                   Expires August 2024              [Page 13]