idnits 2.17.1 draft-urien-tls-se-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-urien-tls-im-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group P. Urien 3 Internet Draft Telecom Paris 4 Intended status: Experimental 6 March 27 2021 7 Expires: September 2021 9 Secure Element for TLS Version 1.3 10 draft-urien-tls-se-02.txt 12 Abstract 14 This draft presents ISO7816 interface for TLS1.3 stack running in 15 secure element. It presents supported cipher suites and key exchange 16 modes, and describes embedded software architecture. TLS 1.3 is the 17 de facto security stack for emerging Internet of Things (IoT) 18 devices. Some of them are constraint nodes, with limited computing 19 resources. Furthermore cheap System on Chip (SoC) components usually 20 provide tamper resistant features, so private or pre shared keys are 21 exposed to hacking. According to the technology state of art, some 22 ISO7816 secure elements are able to process TLS 1.3, but with a 23 limited set of cipher suites. There are two benefits for TLS-SE; 24 first fully tamper resistant processing of TLS protocol, which 25 increases the security level insurance; second embedded software 26 component ready for use, which relieves the software of the burden 27 of cryptographic libraries and associated attacks. TLS-SE devices 28 may also embed standalone applications, which are accessed via 29 internet node, using a routing procedure based on SNI extension. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six 48 months and may be updated, replaced, or obsoleted by other documents 49 at any time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 2021. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with 64 respect to this document. Code Components extracted from this 65 document must include Simplified BSD License text as described in 66 Section 4.e of the Trust Legal Provisions and are provided without 67 warranty as described in the Simplified BSD License. 69 Table of Contents 70 Abstract........................................................... 1 71 Requirements Language.............................................. 1 72 Status of this Memo................................................ 1 73 Copyright Notice................................................... 2 74 1 Overview......................................................... 4 75 2 About Secure Elements............................................ 5 76 3 Software components for TLS-SE................................... 5 77 3.1 Cryptographic resources..................................... 6 78 3.2 Data exchange............................................... 6 79 3.2.1 Receiving Record Packet .............................. 6 80 3.2.2 Sending Record Packet ................................ 7 81 3.2.4 RECV and SEND procedure for open application AEAD .... 9 82 3.3 TLS state machine........................................... 9 83 3.4 TLS library................................................ 10 84 4 ISO7816 interface............................................... 11 85 5 ISO 7816 Use Case............................................... 12 86 5 TLS-SE Name..................................................... 14 87 6 Server Name Indication.......................................... 14 88 7 IANA Considerations............................................. 14 89 8 Security Considerations......................................... 14 90 9 References...................................................... 14 91 9.1 Normative References....................................... 14 92 9.2 Informative References..................................... 15 93 10 Authors' Addresses............................................. 15 94 1 Overview 96 This draft presents ISO7816 interface for TLS1.3 stack running in 97 secure element (see Figure 1), it presents supported cipher suites 98 and key exchange modes, and describes embedded software 99 architecture. TLS 1.3 [RFC8446] is the de facto security stack for 100 emerging Internet of Things (IoT) devices. Some of them are 101 constraint nodes, with limited computing resources. Furthermore 102 cheap System on Chip (SOC) components don't usually provide tamper 103 resistant features, so private or pre shared keys are exposed to 104 hacking. The identity module (im) detailed in [IM] protects identity 105 credentials. The TLS identity module [IM] MAY be based on secure 106 element [ISO7816]. According to the technology state of art, some 107 secure elements are able to process TLS 1.3, but with a limited set 108 of cipher suites. There are two benefits for TLS-SE; first fully 109 tamper resistant processing of TLS protocol, which increases the 110 security level insurance; second embedded software component ready 111 for use, which relieves the software of the burden of cryptographic 112 libraries and associated attacks. 113 Multiple TLS-SE devices, embedding standalone applications, can be 114 hosted by an internet node. In this case SNI extension [RFC6066] MAY 115 be used in order to select the right secure element (see Figure 2). 117 +-----------+ recv +------------+ RECV +-----------+ 118 | IP + ---> | TCP/IP | ---> | TLS 1.3 | 119 | Network +------+ Constraint +------+ Secure | 120 | | <--- | Node | <--- | Element | 121 +-----------+ send +------------+ SEND +-----------+ 122 | | 123 Network Interface ISO7816 interface 125 Figure 1. TLS 1.3 Secure Element (TLS-SE) 126 +----------+ 127 | TLS-SE | 128 TLS-SE Name +---+ Secure | 129 | | Element | 130 | +----------+ 131 SNI= TLS-SE Name | 132 +-----------+ +------------+ | +----------+ 133 | IP + | TCP/IP | | | TLS-SE | 134 | Network +------+ Node +--+---+ Secure | 135 | | |SN Extension| | | Element | 136 +-----------+ +------------+ | +----------+ 137 | 138 | +----------+ 139 | | TLS-SE | 140 TLS-SE Name +---+ Secure | 141 | Element | 142 +----------+ 144 Figure 2. Routing procedure based on SNI for TLS-SE devices 145 2 About Secure Elements 147 Secure elements are defined according to [ISO7816] standards. They 148 support hash functions (sha256, sha384, sha512) and associated HMAC 149 procedures. They also provide signatures and DH procedures in Z/pZ* 150 groups, or elliptic curves (for example secp256r1). Open software 151 can be released thanks to JavaCard (JC) standards, such as JC3.04, 152 or JC3.05. Most of secure elements use 8 bits Micro Controller Unit 153 (MCU) and embedded cryptographic accelerator. Non volatile memory 154 size is up to 100KB, and RAM size is up to 10KB. 156 Below is an illustration of binary encoding rules for secure element 157 according to the T=0 ISO7816 protocol. 158 An ISO7816 request is a set of bytes comprising a five byte header 159 and an optional payload (up to 255 bytes) 160 The header comprises the following five bytes: 161 - CLA, Class 162 - INS, Instruction code 163 - P1, P1 byte 164 - P2, P2 byte 165 - P3, length of the optional payload, or number of expected bytes 167 The response comprises an optional payload (up to 256 bytes) and a 168 two bytes status word (SW1, SW2), SW1=90, SW2=00 (SW=9000) meaning 169 successful operation. 171 The ISO7816 defines two main classes for data exchange (called 172 transport protocol), T=0, and T=1. 173 The T=0 transport protocol is a byte stream; a payload can be 174 included in request or response, but not in both. 175 The T=1 transport protocol is a frame stream; payload can be 176 included both in request and response. 178 3 Software components for TLS-SE 180 +--------+ 181 | Crypto +----------------+ 182 RECV +----------+ | Lib | | 183 ---> | Data | +--------+ +----------+----------+ 184 <--- | Exchange | +---------+ TLS Lib | 185 SEND +----+-----+ | | Make Record Packet | 186 | +-----+-----+ | Check Record Packet | 187 | | TLS State | +---------------------+ 188 +--------+ Machine | 189 +-----------+ 191 Figure 3. Software Components for TLS-SE 192 3.1 Cryptographic resources 194 Many secure elements support hash functions sha256, sha384 and 195 sha512 used by TLS1.3. Associated HMAC, HKDF-Extract and Derive- 196 Secret, MUST be implemented by a dedicated cryptographic library. 198 Many secure elements support the secp256r1 elliptic curve. Diffie- 199 Hellman (DH )calculation are performed according to [IEEE1363] using 200 the ECKAS-DH1 scheme with the identity map as the key derivation 201 function, (KDF), so that the shared secret is the x-coordinate of 202 the ECDH shared secret elliptic curve point represented as an octet 203 string. ECDSA signature is also available for 256,384 and 512 hash 204 size. 206 AES-128 is usually implemented, by not AES-CCM. So this AEAD 207 algorithm SHOULD be implemented by a dedicated cryptographic 208 library. 210 In summary, according to the state of art TLS-SE supports the 211 secp256r1 EC group, associated ECDSA signature computing and 212 checking, and EC-DHE key establishment. It also implements the AES- 213 128-CCM-SHA256 cipher suite. 215 3.2 Data exchange 217 TLS record layer packets are received and sent from/to TCP/IP 218 network thanks to well known socket procedures. TLS-SE processes 219 these packets according to a dedicated state machine. 221 3.2.1 Receiving Record Packet 223 Dedicated ISO7816 requests (named RECV) push incoming record 224 messages in secure element. A fragmentation mechanism splits the 225 record packet in one a several ISO7816 requests, whose payload size 226 is less than 255 bytes. A 2 bits fragmentation-flag field indicates 227 the fragment status; bit F-First notifies the first fragment, and 228 bit F-Last notifies the last fragment. 230 The ISO7816 RECV request COULD be encoded as 231 CLA=00, INS=D8, P1=0, P2=fragmentation-flag, P3=fragment-length 232 F-First=b01, F-Last=b10, F-More=b00 234 When application AEAD is opened a two bits flag (F-Encrypt, F- 235 Decrypt) indicates the cryptographic operation: 236 - P2=b01= F-Decrypt, decryption 237 - P2=b10= F-Encrypt, encryption 238 - P2=b00= Standalone embedded application. 240 If F-Last is not set, the ISO7816 response is always 9000 when no 241 error occurs. For the last fragment five cases may occur: 242 - sw-ok: no error, no record message returned, response = 9000. 243 - sw-open, no error, no record message returned, TLS application 244 AEAD is opened, for example response =9001. 245 - sw-close: no error, , no record message returned, TLS application 246 AEAD is closed, for example response =9002 247 - sw-error: error, no record message returned. 248 - sw-more(size): no error, a message or message fragment is ready. 249 For example sw-more(size)= 61xy, in which xy is the size of the 250 first fragment. 252 TCP/IP Node Secure Element 253 | | 254 |-RECV(F-First, Frag#1)-------->| 255 |<-------------------sw-ok 9000-| 256 |-RECV(F-More, Frag#i)-------->| 257 |<------------------sw-ok= 9000-| 258 |-RECV(F-Last, Frag#n)-------->| 259 |<------------------sw-ok= 9000-| 260 |<----------------sw-open= 9001-| 261 |<---------------sw-close= 9002-| 262 |<----------sw-more(size)= 61xy-| 264 Figure 4. Receiving record packet, segmentation mechanism. 266 3.2.2 Sending Record Packet 268 A sending procedure starts by the reception of a sw-more(size) 269 status, ending a response. This event may occur at the end of RECV 270 procedure (see figure 6) or after TLS state machine reset (see 271 figure 5). 273 A RECV(F-First, No-Frag) request resets the TLS state machine. For 274 TLS client a sw-more(size) status is returned. For TLS server the 275 sw-ok status is returned. 277 TCP/IP Node Secure Element 278 | | 279 |-RECV(F-First, No-Frag)------->|=> Reset State Machine 280 |<------------------sw-ok= 9000-| Server 281 |<----------sw-more(size)= 61xy-| Client 283 Figure 5. Starting the SEND procedure after RESET request. 285 TCP/IP Node Secure Element 286 | | 287 |-RECV(F-Last, Last-Fragment)-->| => End of Message 288 |<----------sw-more(size)= 61xy-| Client 290 Figure 6. Starting SEND procedure after the end of RECV procedure. 292 The SEND(size) reads a record fragment, whose length is equal to 293 size. It MAY be necessary to adjust the SEND size (see figure 7). 294 Typically at the end of RECV procedure, the size indicated by the 295 sw-more(size) status is an expected fragment length. In that case 296 the status sw-retry status (for example 6Cxy) indicates the fragment 297 size. 299 TCP/IP Node Secure Element 300 | | 301 |-RECV(F-Last, Last-Frag)------>| => End of Message 302 |<----------sw-more(size)= 61xy-| 303 | SEND(size)------------------->| 304 | <------- sw-retry(size')=6Czt-| 305 | SEND(size')------------------>| 307 Figure 7. Adjusting SEND size. 309 The SEND(size) request is encoded as : 310 CLA=0, INS=C0, P1=0, P2=0, P3=size 312 The SEND procedure (see Figure 8) is a set of SEND requests, which 313 read record packet fragments. 315 TCP/IP Node Secure Element 316 | | 317 |<--------------- ---sw-more(size#1)= 61xy-| 318 |-SEND(size#1)---------------------------->| 319 |<---------------Frag#1 || sw-more(size#2)-| 320 |-SEND(size#i)---------------------------->| 321 |<-----------Frag#i || sw-more(size#[i+1])-| 322 |-SEND(size#n)---------------------------->| 323 |<------------------------Frag#n || sw-ok)-|=> SEND End 324 |<------------Frag#n || sw-more(next-size)-|=> SEND Continue 325 |<----------------------Frag#n || sw-open)-|=> Open 326 |<----------------------Frag#n || sw-close-|=> Close 328 Figure 8. The SEND procedure 330 At the end of SEND procedure four events MAY occur: 331 - End of SEND procedure (status = sw-ok). No more record packets are 332 available. 333 - SEND procedure to be continued (status = sw-more(size)). Another 334 record packet is available. 335 - End of SEND procedure, application AEAD is ready for use (status = 336 sw-open) 337 - End of SEND procedure, application AEAD is closed (status = sw- 338 close) 339 3.2.4 RECV and SEND procedure for open application AEAD 341 When the application AEAD is opened RECV performs decryption and 342 encryption operations (see figure 9). 344 For decryption operation (RECV(F-Decrypt)) the RECV procedure pushes 345 the incoming record packet. The returned payload by the SEND 346 procedure is the decrypted message ended by the protocol byte. 348 For encryption operation (RECV(F-Encrypt)) the RECV procedure pushes 349 the content to encrypt ended by the associated protocol byte. The 350 returned payload by the SEND procedure is a record packet, including 351 the encrypted content. 353 TCP/IP Node Secure Element 354 | | 355 |-RECV(F-First, Frag#1)-------------------------->| 356 |<------------------------------------sw-ok= 9000-| 357 |-RECV(F-More, Frag#i)-------------------------->| 358 |<------------------------------------sw-ok= 9000-| 359 |-RECV(F-Decrypt/F-Encrypt, F-Last, Frag#n)------>| 360 |<--------------------------sw-more(size#1)= 61xy-| 361 |-SEND(size#1)----------------------------------->| 362 |<----------------------Frag#1 || sw-more(size#2)-| 363 |-SEND(size#i)----------------------------------->| 364 |<------------------Frag#i || sw-more(size#[i+1])-| 365 |-SEND(size#n)----------------------------------->| 366 |<-------------------------------Frag#n || sw-ok)-|=> SEND End 367 |<-----------------------------Frag#n || sw-close-|=> Close 369 Figure 9. Decryption/Encryption operations. 371 3.3 TLS state machine 373 The state machine manages TLS flights, it determines the next record 374 packet to be received and checked, and the next record packet to be 375 built and sent. The number of states and their order is dependent on 376 the TLS-SE role (client or server), and on the supported working 377 mode (pre shared key, server with certificate, server and client 378 with certificate). Figure 10 details an example of state machine for 379 TLS-SE server, using pre-shared key. The ordered list of states 380 comprises: S-Ready, S-Extensions, S-SFinished, S-ClientCCS, S- 381 CFinished and S-Open. 383 TCP/IP Node Secure Element 384 | | 385 |-RESET------------------------>| 386 |<------------------------sw-ok-| state = S-Ready 387 Client |-RECV(F-First,Frag#1)--------->| 388 Hello |<------------------------sw-ok-| 389 |-RECV(F-Last,Frag#2)---------->| 390 | | Check-ClientHello 391 | | Make-ServerHello 392 |<----------------sw-more(size)-| state= S-Extensions 393 |-SEND(size)------------------->| 394 Server |<--------Packet||sw-more(size)-| 395 Hello | | 396 |-SEND(size)------------------->| Make-Extensions 397 Server |<--------Packet||sw-more(size)-| state= S-SFinished 398 Encrypted | | 399 Extension |-SEND(size)------------------->| 400 | | Make-ServerFinished 401 Server |<----------------Packet||sw-ok-| state= S-ClientCCS 402 Finished | | 403 | | 404 ClientCCS |-RECV(F-First,F-Last,Packet)-->| Check-ClientCCS 405 |<------------------------sw-ok-| state= S-CFinished 406 | | 407 | | 408 Client |-RECV(F-First,F-Last,Packet)->-| Check-CFinished 409 Finished |<----------------------sw-open-| state= S-Open 410 | | 411 Packet |-RECV(F-Decrypt,Packet)------->| Decrypt Packet 412 |<----------------sw-more(size)-| Clear Form Message 413 |-SEND(size)------------------->| 414 |<------ -Message||ptcol||sw-ok-| 415 | | 416 Message |-RECV(F-Encrypt,Message)------>| Encrypt 417 |<----------------sw-more(size)-| Record Packet 418 |-SEND(size)------------------->| 419 |<------ -Record Packet ||sw-ok-| 420 | | 422 Figure 10. TLS-SE server with pre-share key state machine 424 3.4 TLS library 426 The TLS-SE library is a set of procedures that check, according to 427 the state machine, incoming record packets and build outgoing record 428 packets. In figure 10 the TLS library comprises the following 429 elements: Check-ClientHello, Check-ClientCCS, Check-ClientFinished, 430 Make-ServerHello, Make-EncryptedExensions, and MakeServerFinished. 432 4 ISO7816 interface 434 The RECV and SEND binary encoding is shown by figure 11 436 +------+-----+-----+-------------+-----------+----------+---------+ 437 + name | CLA | INS | P1 | P2 | P3 | Payload | 438 +------+-----+-----+-------------+-----------+----------+---------+ 439 | RECV | 00 | D8 | 01= Decrypt | 01= First | Fragment | | 440 | | | 02= Encrypt | 02= Last | Length | Yes | 441 | | | | | | 0= RESET | | 442 +------+-----+-----+-------------+-----------+----------+---------+ 443 | SEND | 00 | C0 | 00 | 00 | Incoming | No | 444 | | | | | | Length | | 445 +------+-----+-----+-------------+-----------+----------+---------+ 447 Figure 11. RECV and SEND ISO7816 requests binary encoding 449 The status word binary encoding is shown by figure 12. Two binary 450 encoding of sw-more MUST be supported. In the T=0 context, SE 451 operating system returns the 61xy status when a request including a 452 payload, induces a response with a payload. The status 9Fxy is 453 managed by the application in order to notify response size to be 454 returned. The TLS-SE application MAY use 61xy status, but this could 455 induce interoperability issues. 457 +----------------+-----+------+ 458 | name | SW1 | SW2 | 459 +----------------+-----+------+ 460 | sw-ok | 90 | 00 | 461 +----------------+-----+------+ 462 | sw-more(size) | 61 | size | 463 | | 9F | size | 464 +----------------+-----+------+ 465 | sw-retry(size) | 6C + size | 466 +----------------+-----+------+ 467 | sw-open | 90 | 01 | 468 +----------------+-----+------+ 469 | sw-close | 90 | 02 | 470 +----------------+-----+------+ 471 | sw-error | 6D |error | 472 | | 6F |number| 473 +----------------+-----+------+ 475 Figure 12. ISO7816 status word binary encoding 476 5 ISO 7816 Use Case 478 An open implementation is available at [TLS-SE]. 480 Below is an illustration of TLS-SE server, using a pre-shared key 481 (PSK) with DHE over the secp256r1 curve, and the cipher suite AES- 482 128-CCM-SHA256. The time consumed by handshake is about 1.4s. 484 PSK= 485 0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F20 486 DHE= 487 037E6E633541EC03DB700A28E7DABB74F8E84D4A28E5F024B46F468A7821305D 489 RECV(Client Hello) 491 Tx: 00 D8 00 01 F0 16 03 03 00 F2 01 00 00 EE 03 03 492 4E 65 53 05 52 AB 3E 83 14 0B 2F 9C 2F D7 BC 16 493 F9 F5 C4 A9 86 CA 3F C8 8C 6E 8C D1 10 BB B1 57 494 00 00 02 13 04 01 00 00 C3 00 2D 00 03 02 00 01 495 00 2B 00 03 02 03 04 00 0D 00 1E 00 1C 06 03 05 496 03 04 03 02 03 08 06 08 0B 08 05 08 0A 08 04 08 497 09 06 01 05 01 04 01 02 01 00 33 00 47 00 45 00 498 17 00 41 04 9A 1E 0A D8 40 88 D4 21 D1 55 D7 F2 499 8F 78 4C 28 75 F5 19 CA 12 71 96 92 C4 07 8F B4 500 35 42 57 E7 64 24 C1 BC 5D 89 0E F4 08 FD 25 8D 501 24 F4 64 BB C3 F4 80 D3 BF 2C 23 A0 F9 2D A7 88 502 0C 5B 44 53 00 0A 00 06 00 04 00 18 00 17 00 29 503 00 3A 00 15 00 0F 43 6C 69 65 6E 74 5F 69 64 65 504 6E 74 69 74 79 00 00 00 00 00 21 20 CC 05 4A 9F 505 DE 70 E9 96 D6 01 69 61 F5 9A 78 20 D9 FC 6D ED 506 4C C6 0A 7B 0D 507 Rx: 90 00 [47 ms] 508 Tx: 00 D8 00 02 07 4B 68 8F 4E B9 B2 CA 510 Rx: 61 86 [879 ms] 512 SEND(Server Hello) 514 Tx: 00 C0 00 00 86 515 Rx: 16 03 03 00 81 02 00 00 7D 03 03 5C 78 A4 E1 93 516 34 D7 D9 64 B2 85 64 1B E4 76 63 94 39 1F 4A 15 517 27 0A A4 C6 A0 C6 93 D9 E2 16 4D 00 13 04 00 00 518 55 00 29 00 02 00 00 00 33 00 45 00 17 00 41 04 519 25 C9 16 94 8B 39 51 D2 8E 88 70 F7 F5 4E 6C 31 520 62 93 B1 65 55 2C 30 B2 5E 75 6C D8 FE AF DA A7 521 67 D8 AD A7 BE 68 54 EA 3E A0 0B 4D CC 62 93 96 522 38 07 68 29 3E D5 E6 0C 25 4A EA 12 C9 F8 99 7F 523 00 2B 00 02 03 04 9F 1C [32 ms] 524 SEND(Server Encrypted Extensions) 526 Tx: 00 C0 00 00 1C 528 Rx: 17 03 03 00 17 E6 04 4A 52 1A 50 B5 54 D8 73 5E 529 00 F4 FD 66 BB B3 74 50 99 36 C8 08 9F 3A [78 ms] 531 SEND(Server Encrypted Finished) 533 Tx: 00 C0 00 00 3A 535 Rx: 17 03 03 00 35 CB CA 03 3E E4 34 7E D2 0C 7C 24 536 C1 8F 39 A2 74 39 24 47 78 BE 94 95 7A 31 EC 03 537 D5 0C A8 1C 46 04 05 F2 83 3E 99 0D AD D6 66 63 538 60 23 F8 5D 7B 77 0F 95 18 35 90 00 [185 ms] 540 RECV(Client Encrypted Finished) 542 Tx: 00 D8 00 03 3A 17 03 03 00 35 BC 29 18 D1 B8 4B 543 C0 3F 6F 81 79 D9 7E FD 58 E3 76 EA 61 13 9C 3E 544 40 0F 34 CD 94 CE C1 44 CB 76 70 7D DA 8A 54 69 545 41 D9 80 CD 5D 52 8F E5 38 D8 52 92 20 54 5E 546 Rx: 90 01 [389 ms] 548 TLS13 session is open 550 Decryption of incoming Record Packet 551 RECV(Decrypt, Packet) 552 Tx: 00 D8 01 03 24 17 03 03 00 1F 56 E2 D5 B5 C4 A6 553 E2 3E 54 56 5A C4 2D E9 99 F3 58 22 34 15 15 A7 554 96 FD 0E B0 61 60 4C 52 87 555 Rx: 61 0F [78 ms] 557 SEND(Message) 559 Tx: 00 C0 00 00 0F 561 Rx: 68 65 6C 6C 6F 20 77 6F 72 6C 64 21 0D 0A 17 90 562 00 [15 ms] 563 Rx: hello world! ptcol=17 565 Encryption of message 567 RECV(Encrypt,Message) 568 Tx: 00 D8 02 03 0F 68 65 6C 6C 6F 20 77 6F 72 6C 64 569 21 0D 0A 17 571 Rx: 61 24 [79 ms] 572 SEND(Record Packet) 574 Tx: 00 C0 00 00 24 575 Rx: 17 03 03 00 1F 6F 78 FF 68 0F CA 9E 31 53 2C 96 576 B3 FA D7 B0 51 1B 92 81 35 3D DB FE E9 18 A7 DF 577 36 2F A5 27 90 00 [16 ms] 579 5 TLS-SE Name 581 According to ISO7816 standards, secure elements return upon reset a 582 set of bytes called Answer to Reset (ATR). ATR comprises at least 583 two bytes (TS, T0). The LSB nibble of T0 indicates the number of 584 historical bytes (ranging from 0 to 15). Historical bytes (HB) are 585 located at the end of ATR. Historical bytes can be programmed by 586 standardized API, and therefore MAY be used for secure element 587 naming. 589 6 Server Name Indication 591 According to [RFC6066] Server Name Indication extension is used to 592 route TLS packets toward a virtual host. 593 Multiple TLS-SE devices, embedding standalone applications, can be 594 hosted by an internet node. In this case SNI extension MAY be used 595 in order to select the right secure element, whose name, typically 596 stored in historical bytes, is determined from SNI. 598 7 IANA Considerations 600 This draft does not require any action from IANA. 602 8 Security Considerations 604 This entire document is about security. 606 9 References 608 9.1 Normative References 610 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 611 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 612 https://www.rfc-editor.org/info/rfc8446. 614 [RFC6066] Eastlake 3rd, D., "Transport Layer [RFC6066] Security 615 (TLS) Extensions: Extension Definitions", RFC 6066, DOI 616 10.17487/RFC6066, January 2011. 618 [ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards 619 with Contacts", The International Organization for Standardization 620 (ISO). 622 [IEEE1363] IEEE, "IEEE Standard Specifications for Public Key 623 Cryptography", IEEE Std. 1363-2000, DOI 10.1109/IEEESTD.2000.92292. 625 9.2 Informative References 627 [IM] Urien, P., "Identity Module for TLS Version 1.3", draft-urien- 628 tls-im-04.txt, January 2021. 630 [TLS-SE] "tls-se.java", https://github.com/purien/TLS-SE 632 10 Authors' Addresses 634 Pascal Urien 635 Telecom Paris 636 19 place Marguerite Perey 637 91120 Palaiseau Phone: NA 638 France Email: Pascal.Urien@telecom-paris.fr