idnits 2.17.1 draft-urien-tls-se-01.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-03 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 September 25 2020 7 Expires: March 2021 9 Secure Element for TLS Version 1.3 10 draft-urien-tls-se-01.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 March 2021. 54 Copyright Notice 56 Copyright (c) 2020 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 Secure Element for TLS Version 1.3 September 2020 71 Table of Contents 72 Abstract........................................................... 1 73 Requirements Language.............................................. 1 74 Status of this Memo................................................ 1 75 Copyright Notice................................................... 2 76 1 Overview......................................................... 4 77 2 About Secure Elements............................................ 5 78 3 Software components for TLS-SE................................... 5 79 3.1 Cryptographic resources..................................... 6 80 3.2 Data exchange............................................... 6 81 3.2.1 Receiving Record Packet .............................. 6 82 3.2.2 Sending Record Packet ................................ 7 83 3.2.4 RECV and SEND procedure for open application AEAD .... 9 84 3.3 TLS state machine........................................... 9 85 3.4 TLS library................................................ 10 86 4 ISO7816 interface............................................... 11 87 5 ISO 7816 Use Case............................................... 12 88 5 TLS-SE Name..................................................... 14 89 6 Server Name Indication.......................................... 14 90 7 IANA Considerations............................................. 14 91 8 Security Considerations......................................... 14 92 9 References...................................................... 14 93 9.1 Normative References....................................... 14 94 9.2 Informative References..................................... 15 95 10 Authors' Addresses............................................. 15 96 Secure Element for TLS Version 1.3 September 2020 98 1 Overview 100 This draft presents ISO7816 interface for TLS1.3 stack running in 101 secure element (see Figure 1), it presents supported cipher suites 102 and key exchange modes, and describes embedded software 103 architecture. TLS 1.3 [RFC8446] is the de facto security stack for 104 emerging Internet of Things (IoT) devices. Some of them are 105 constraint nodes, with limited computing resources. Furthermore 106 cheap System on Chip (SOC) components don't usually provide tamper 107 resistant features, so private or pre shared keys are exposed to 108 hacking. The identity module (im) detailed in [IM] protects identity 109 credentials. The TLS identity module [IM] MAY be based on secure 110 element [ISO7816]. According to the technology state of art, some 111 secure elements are able to process TLS 1.3, but with a limited set 112 of cipher suites. There are two benefits for TLS-SE; first fully 113 tamper resistant processing of TLS protocol, which increases the 114 security level insurance; second embedded software component ready 115 for use, which relieves the software of the burden of cryptographic 116 libraries and associated attacks. 117 Multiple TLS-SE devices, embedding standalone applications, can be 118 hosted by an internet node. In this case SNI extension [RFC6066] MAY 119 be used in order to select the right secure element (see Figure 2). 121 +-----------+ recv +------------+ RECV +-----------+ 122 | IP + ---> | TCP/IP | ---> | TLS 1.3 | 123 | Network +------+ Constraint +------+ Secure | 124 | | <--- | Node | <--- | Element | 125 +-----------+ send +------------+ SEND +-----------+ 126 | | 127 Network Interface ISO7816 interface 129 Figure 1. TLS 1.3 Secure Element (TLS-SE) 130 +----------+ 131 | TLS-SE | 132 TLS-SE Name +---+ Secure | 133 | | Element | 134 | +----------+ 135 SNI= TLS-SE Name | 136 +-----------+ +------------+ | +----------+ 137 | IP + | TCP/IP | | | TLS-SE | 138 | Network +------+ Node +--+---+ Secure | 139 | | |SN Extension| | | Element | 140 +-----------+ +------------+ | +----------+ 141 | 142 | +----------+ 143 | | TLS-SE | 144 TLS-SE Name +---+ Secure | 145 | Element | 146 +----------+ 148 Figure 2. Routing procedure based on SNI for TLS-SE devices 149 Secure Element for TLS Version 1.3 September 2020 151 2 About Secure Elements 153 Secure elements are defined according to [ISO7816] standards. They 154 support hash functions (sha256, sha384, sha512) and associated HMAC 155 procedures. They also provide signatures and DH procedures in Z/pZ* 156 groups, or elliptic curves (for example secp256r1). Open software 157 can be released thanks to JavaCard (JC) standards, such as JC3.04, 158 or JC3.05. Most of secure elements use 8 bits Micro Controller Unit 159 (MCU) and embedded cryptographic accelerator. Non volatile memory 160 size is up to 100KB, and RAM size is up to 10KB. 162 Below is an illustration of binary encoding rules for secure element 163 according to the T=0 ISO7816 protocol. 164 An ISO7816 request is a set of bytes comprising a five byte header 165 and an optional payload (up to 255 bytes) 166 The header comprises the following five bytes: 167 - CLA, Class 168 - INS, Instruction code 169 - P1, P1 byte 170 - P2, P2 byte 171 - P3, length of the optional payload, or number of expected bytes 173 The response comprises an optional payload (up to 256 bytes) and a 174 two bytes status word (SW1, SW2), SW1=90, SW2=00 (SW=9000) meaning 175 successful operation. 177 The ISO7816 defines two main classes for data exchange (called 178 transport protocol), T=0, and T=1. 179 The T=0 transport protocol is a byte stream; a payload can be 180 included in request or response, but not in both. 181 The T=1 transport protocol is a frame stream; payload can be 182 included both in request and response. 184 3 Software components for TLS-SE 186 +--------+ 187 | Crypto +----------------+ 188 RECV +----------+ | Lib | | 189 ---> | Data | +--------+ +----------+----------+ 190 <--- | Exchange | +---------+ TLS Lib | 191 SEND +----+-----+ | | Make Record Packet | 192 | +-----+-----+ | Check Record Packet | 193 | | TLS State | +---------------------+ 194 +--------+ Machine | 195 +-----------+ 197 Figure 3. Software Components for TLS-SE 198 Secure Element for TLS Version 1.3 September 2020 200 3.1 Cryptographic resources 202 Many secure elements support hash functions sha256, sha384 and 203 sha512 used by TLS1.3. Associated HMAC, HKDF-Extract and Derive- 204 Secret, MUST be implemented by a dedicated cryptographic library. 206 Many secure elements support the secp256r1 elliptic curve. Diffie- 207 Hellman (DH )calculation are performed according to [IEEE1363] using 208 the ECKAS-DH1 scheme with the identity map as the key derivation 209 function, (KDF), so that the shared secret is the x-coordinate of 210 the ECDH shared secret elliptic curve point represented as an octet 211 string. ECDSA signature is also available for 256,384 and 512 hash 212 size. 214 AES-128 is usually implemented, by not AES-CCM. So this AEAD 215 algorithm SHOULD be implemented by a dedicated cryptographic 216 library. 218 In summary, according to the state of art TLS-SE supports the 219 secp256r1 EC group, associated ECDSA signature computing and 220 checking, and EC-DHE key establishment. It also implements the AES- 221 128-CCM-SHA256 cipher suite. 223 3.2 Data exchange 225 TLS record layer packets are received and sent from/to TCP/IP 226 network thanks to well known socket procedures. TLS-SE processes 227 these packets according to a dedicated state machine. 229 3.2.1 Receiving Record Packet 231 Dedicated ISO7816 requests (named RECV) push incoming record 232 messages in secure element. A fragmentation mechanism splits the 233 record packet in one a several ISO7816 requests, whose payload size 234 is less than 255 bytes. A 2 bits fragmentation-flag field indicates 235 the fragment status; bit F-First notifies the first fragment, and 236 bit F-Last notifies the last fragment. 238 The ISO7816 RECV request COULD be encoded as 239 CLA=00, INS=D8, P1=0, P2=fragmentation-flag, P3=fragment-length 240 F-First=b01, F-Last=b10, F-More=b00 242 When application AEAD is opened a two bits flag (F-Encrypt, F- 243 Decrypt) indicates the cryptographic operation: 244 - P2=b01= F-Decrypt, decryption 245 - P2=b10= F-Encrypt, encryption 246 - P2=b00= Standalone embedded application. 248 Secure Element for TLS Version 1.3 September 2020 250 If F-Last is not set, the ISO7816 response is always 9000 when no 251 error occurs. For the last fragment five cases may occur: 252 - sw-ok: no error, no record message returned, response = 9000. 253 - sw-open, no error, no record message returned, TLS application 254 AEAD is opened, for example response =9001. 255 - sw-close: no error, , no record message returned, TLS application 256 AEAD is closed, for example response =9002 257 - sw-error: error, no record message returned. 258 - sw-more(size): no error, a message or message fragment is ready. 259 For example sw-more(size)= 61xy, in which xy is the size of the 260 first fragment. 262 TCP/IP Node Secure Element 263 | | 264 |-RECV(F-First, Frag#1)-------->| 265 |<-------------------sw-ok 9000-| 266 |-RECV(F-More, Frag#i)-------->| 267 |<------------------sw-ok= 9000-| 268 |-RECV(F-Last, Frag#n)-------->| 269 |<------------------sw-ok= 9000-| 270 |<----------------sw-open= 9001-| 271 |<---------------sw-close= 9002-| 272 |<----------sw-more(size)= 61xy-| 274 Figure 4. Receiving record packet, segmentation mechanism. 276 3.2.2 Sending Record Packet 278 A sending procedure starts by the reception of a sw-more(size) 279 status, ending a response. This event may occur at the end of RECV 280 procedure (see figure 6) or after TLS state machine reset (see 281 figure 5). 283 A RECV(F-First, No-Frag) request resets the TLS state machine. For 284 TLS client a sw-more(size) status is returned. For TLS server the 285 sw-ok status is returned. 287 TCP/IP Node Secure Element 288 | | 289 |-RECV(F-First, No-Frag)------->|=> Reset State Machine 290 |<------------------sw-ok= 9000-| Server 291 |<----------sw-more(size)= 61xy-| Client 293 Figure 5. Starting the SEND procedure after RESET request. 295 TCP/IP Node Secure Element 296 | | 297 |-RECV(F-Last, Last-Fragment)-->| => End of Message 298 |<----------sw-more(size)= 61xy-| Client 300 Figure 6. Starting SEND procedure after the end of RECV procedure. 302 Secure Element for TLS Version 1.3 September 2020 304 The SEND(size) reads a record fragment, whose length is equal to 305 size. It MAY be necessary to adjust the SEND size (see figure 7). 306 Typically at the end of RECV procedure, the size indicated by the 307 sw-more(size) status is an expected fragment length. In that case 308 the status sw-retry status (for example 6Cxy) indicates the fragment 309 size. 311 TCP/IP Node Secure Element 312 | | 313 |-RECV(F-Last, Last-Frag)------>| => End of Message 314 |<----------sw-more(size)= 61xy-| 315 | SEND(size)------------------->| 316 | <------- sw-retry(size')=6Czt-| 317 | SEND(size')------------------>| 319 Figure 7. Adjusting SEND size. 321 The SEND(size) request is encoded as : 322 CLA=0, INS=C0, P1=0, P2=0, P3=size 324 The SEND procedure (see Figure 8) is a set of SEND requests, which 325 read record packet fragments. 327 TCP/IP Node Secure Element 328 | | 329 |<--------------- ---sw-more(size#1)= 61xy-| 330 |-SEND(size#1)---------------------------->| 331 |<---------------Frag#1 || sw-more(size#2)-| 332 |-SEND(size#i)---------------------------->| 333 |<-----------Frag#i || sw-more(size#[i+1])-| 334 |-SEND(size#n)---------------------------->| 335 |<------------------------Frag#n || sw-ok)-|=> SEND End 336 |<------------Frag#n || sw-more(next-size)-|=> SEND Continue 337 |<----------------------Frag#n || sw-open)-|=> Open 338 |<----------------------Frag#n || sw-close-|=> Close 340 Figure 8. The SEND procedure 342 At the end of SEND procedure four events MAY occur: 343 - End of SEND procedure (status = sw-ok). No more record packets are 344 available. 345 - SEND procedure to be continued (status = sw-more(size)). Another 346 record packet is available. 347 - End of SEND procedure, application AEAD is ready for use (status = 348 sw-open) 349 - End of SEND procedure, application AEAD is closed (status = sw- 350 close) 351 Secure Element for TLS Version 1.3 September 2020 353 3.2.4 RECV and SEND procedure for open application AEAD 355 When the application AEAD is opened RECV performs decryption and 356 encryption operations (see figure 9). 358 For decryption operation (RECV(F-Decrypt)) the RECV procedure pushes 359 the incoming record packet. The returned payload by the SEND 360 procedure is the decrypted message ended by the protocol byte. 362 For encryption operation (RECV(F-Encrypt)) the RECV procedure pushes 363 the content to encrypt ended by the associated protocol byte. The 364 returned payload by the SEND procedure is a record packet, including 365 the encrypted content. 367 TCP/IP Node Secure Element 368 | | 369 |-RECV(F-First, Frag#1)-------------------------->| 370 |<------------------------------------sw-ok= 9000-| 371 |-RECV(F-More, Frag#i)-------------------------->| 372 |<------------------------------------sw-ok= 9000-| 373 |-RECV(F-Decrypt/F-Encrypt, F-Last, Frag#n)------>| 374 |<--------------------------sw-more(size#1)= 61xy-| 375 |-SEND(size#1)----------------------------------->| 376 |<----------------------Frag#1 || sw-more(size#2)-| 377 |-SEND(size#i)----------------------------------->| 378 |<------------------Frag#i || sw-more(size#[i+1])-| 379 |-SEND(size#n)----------------------------------->| 380 |<-------------------------------Frag#n || sw-ok)-|=> SEND End 381 |<-----------------------------Frag#n || sw-close-|=> Close 383 Figure 9. Decryption/Encryption operations. 385 3.3 TLS state machine 387 The state machine manages TLS flights, it determines the next record 388 packet to be received and checked, and the next record packet to be 389 built and sent. The number of states and their order is dependent on 390 the TLS-SE role (client or server), and on the supported working 391 mode (pre shared key, server with certificate, server and client 392 with certificate). Figure 10 details an example of state machine for 393 TLS-SE server, using pre-shared key. The ordered list of states 394 comprises: S-Ready, S-Extensions, S-SFinished, S-ClientCCS, S- 395 CFinished and S-Open. 397 Secure Element for TLS Version 1.3 September 2020 399 TCP/IP Node Secure Element 400 | | 401 |-RESET------------------------>| 402 |<------------------------sw-ok-| state = S-Ready 403 Client |-RECV(F-First,Frag#1)--------->| 404 Hello |<------------------------sw-ok-| 405 |-RECV(F-Last,Frag#2)---------->| 406 | | Check-ClientHello 407 | | Make-ServerHello 408 |<----------------sw-more(size)-| state= S-Extensions 409 |-SEND(size)------------------->| 410 Server |<--------Packet||sw-more(size)-| 411 Hello | | 412 |-SEND(size)------------------->| Make-Extensions 413 Server |<--------Packet||sw-more(size)-| state= S-SFinished 414 Encrypted | | 415 Extension |-SEND(size)------------------->| 416 | | Make-ServerFinished 417 Server |<----------------Packet||sw-ok-| state= S-ClientCCS 418 Finished | | 419 | | 420 ClientCCS |-RECV(F-First,F-Last,Packet)-->| Check-ClientCCS 421 |<------------------------sw-ok-| state= S-CFinished 422 | | 423 | | 424 Client |-RECV(F-First,F-Last,Packet)->-| Check-CFinished 425 Finished |<----------------------sw-open-| state= S-Open 426 | | 427 Packet |-RECV(F-Decrypt,Packet)------->| Decrypt Packet 428 |<----------------sw-more(size)-| Clear Form Message 429 |-SEND(size)------------------->| 430 |<------ -Message||ptcol||sw-ok-| 431 | | 432 Message |-RECV(F-Encrypt,Message)------>| Encrypt 433 |<----------------sw-more(size)-| Record Packet 434 |-SEND(size)------------------->| 435 |<------ -Record Packet ||sw-ok-| 436 | | 438 Figure 10. TLS-SE server with pre-share key state machine 440 3.4 TLS library 442 The TLS-SE library is a set of procedures that check, according to 443 the state machine, incoming record packets and build outgoing record 444 packets. In figure 10 the TLS library comprises the following 445 elements: Check-ClientHello, Check-ClientCCS, Check-ClientFinished, 446 Make-ServerHello, Make-EncryptedExensions, and MakeServerFinished. 448 Secure Element for TLS Version 1.3 September 2020 450 4 ISO7816 interface 452 The RECV and SEND binary encoding is shown by figure 11 454 +------+-----+-----+-------------+-----------+----------+---------+ 455 + name | CLA | INS | P1 | P2 | P3 | Payload | 456 +------+-----+-----+-------------+-----------+----------+---------+ 457 | RECV | 00 | D8 | 01= Decrypt | 01= First | Fragment | | 458 | | | 02= Encrypt | 02= Last | Length | Yes | 459 | | | | | | 0= RESET | | 460 +------+-----+-----+-------------+-----------+----------+---------+ 461 | SEND | 00 | C0 | 00 | 00 | Incoming | No | 462 | | | | | | Length | | 463 +------+-----+-----+-------------+-----------+----------+---------+ 465 Figure 11. RECV and SEND ISO7816 requests binary encoding 467 The status word binary encoding is shown by figure 12. Two binary 468 encoding of sw-more MUST be supported. In the T=0 context, SE 469 operating system returns the 61xy status when a request including a 470 payload, induces a response with a payload. The status 9Fxy is 471 managed by the application in order to notify response size to be 472 returned. The TLS-SE application MAY use 61xy status, but this could 473 induce interoperability issues. 475 +----------------+-----+------+ 476 | name | SW1 | SW2 | 477 +----------------+-----+------+ 478 | sw-ok | 90 | 00 | 479 +----------------+-----+------+ 480 | sw-more(size) | 61 | size | 481 | | 9F | size | 482 +----------------+-----+------+ 483 | sw-retry(size) | 6C + size | 484 +----------------+-----+------+ 485 | sw-open | 90 | 01 | 486 +----------------+-----+------+ 487 | sw-close | 90 | 02 | 488 +----------------+-----+------+ 489 | sw-error | 6D |error | 490 | | 6F |number| 491 +----------------+-----+------+ 493 Figure 12. ISO7816 status word binary encoding 494 Secure Element for TLS Version 1.3 September 2020 496 5 ISO 7816 Use Case 498 Below is an illustration of TLS-SE server, using a pre-shared key 499 (PSK) with DHE over the secp256r1 curve, and the cipher suite AES- 500 128-CCM-SHA256. The time consumed by handshake is about 1.4s. 502 PSK= 503 0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F20 504 DHE= 505 037E6E633541EC03DB700A28E7DABB74F8E84D4A28E5F024B46F468A7821305D 507 RECV(Client Hello) 509 Tx: 00 D8 00 01 F0 16 03 03 00 F2 01 00 00 EE 03 03 510 4E 65 53 05 52 AB 3E 83 14 0B 2F 9C 2F D7 BC 16 511 F9 F5 C4 A9 86 CA 3F C8 8C 6E 8C D1 10 BB B1 57 512 00 00 02 13 04 01 00 00 C3 00 2D 00 03 02 00 01 513 00 2B 00 03 02 03 04 00 0D 00 1E 00 1C 06 03 05 514 03 04 03 02 03 08 06 08 0B 08 05 08 0A 08 04 08 515 09 06 01 05 01 04 01 02 01 00 33 00 47 00 45 00 516 17 00 41 04 9A 1E 0A D8 40 88 D4 21 D1 55 D7 F2 517 8F 78 4C 28 75 F5 19 CA 12 71 96 92 C4 07 8F B4 518 35 42 57 E7 64 24 C1 BC 5D 89 0E F4 08 FD 25 8D 519 24 F4 64 BB C3 F4 80 D3 BF 2C 23 A0 F9 2D A7 88 520 0C 5B 44 53 00 0A 00 06 00 04 00 18 00 17 00 29 521 00 3A 00 15 00 0F 43 6C 69 65 6E 74 5F 69 64 65 522 6E 74 69 74 79 00 00 00 00 00 21 20 CC 05 4A 9F 523 DE 70 E9 96 D6 01 69 61 F5 9A 78 20 D9 FC 6D ED 524 4C C6 0A 7B 0D 525 Rx: 90 00 [47 ms] 526 Tx: 00 D8 00 02 07 4B 68 8F 4E B9 B2 CA 528 Rx: 61 86 [879 ms] 530 SEND(Server Hello) 532 Tx: 00 C0 00 00 86 533 Rx: 16 03 03 00 81 02 00 00 7D 03 03 5C 78 A4 E1 93 534 34 D7 D9 64 B2 85 64 1B E4 76 63 94 39 1F 4A 15 535 27 0A A4 C6 A0 C6 93 D9 E2 16 4D 00 13 04 00 00 536 55 00 29 00 02 00 00 00 33 00 45 00 17 00 41 04 537 25 C9 16 94 8B 39 51 D2 8E 88 70 F7 F5 4E 6C 31 538 62 93 B1 65 55 2C 30 B2 5E 75 6C D8 FE AF DA A7 539 67 D8 AD A7 BE 68 54 EA 3E A0 0B 4D CC 62 93 96 540 38 07 68 29 3E D5 E6 0C 25 4A EA 12 C9 F8 99 7F 541 00 2B 00 02 03 04 9F 1C [32 ms] 542 Secure Element for TLS Version 1.3 September 2020 544 SEND(Server Encrypted Extensions) 546 Tx: 00 C0 00 00 1C 548 Rx: 17 03 03 00 17 E6 04 4A 52 1A 50 B5 54 D8 73 5E 549 00 F4 FD 66 BB B3 74 50 99 36 C8 08 9F 3A [78 ms] 551 SEND(Server Encrypted Finished) 553 Tx: 00 C0 00 00 3A 555 Rx: 17 03 03 00 35 CB CA 03 3E E4 34 7E D2 0C 7C 24 556 C1 8F 39 A2 74 39 24 47 78 BE 94 95 7A 31 EC 03 557 D5 0C A8 1C 46 04 05 F2 83 3E 99 0D AD D6 66 63 558 60 23 F8 5D 7B 77 0F 95 18 35 90 00 [185 ms] 560 RECV(Client Encrypted Finished) 562 Tx: 00 D8 00 03 3A 17 03 03 00 35 BC 29 18 D1 B8 4B 563 C0 3F 6F 81 79 D9 7E FD 58 E3 76 EA 61 13 9C 3E 564 40 0F 34 CD 94 CE C1 44 CB 76 70 7D DA 8A 54 69 565 41 D9 80 CD 5D 52 8F E5 38 D8 52 92 20 54 5E 566 Rx: 90 01 [389 ms] 568 TLS13 session is open 570 Decryption of incoming Record Packet 571 RECV(Decrypt, Packet) 572 Tx: 00 D8 01 03 24 17 03 03 00 1F 56 E2 D5 B5 C4 A6 573 E2 3E 54 56 5A C4 2D E9 99 F3 58 22 34 15 15 A7 574 96 FD 0E B0 61 60 4C 52 87 575 Rx: 61 0F [78 ms] 577 SEND(Message) 579 Tx: 00 C0 00 00 0F 581 Rx: 68 65 6C 6C 6F 20 77 6F 72 6C 64 21 0D 0A 17 90 582 00 [15 ms] 583 Rx: hello world! ptcol=17 585 Encryption of message 587 RECV(Encrypt,Message) 588 Tx: 00 D8 02 03 0F 68 65 6C 6C 6F 20 77 6F 72 6C 64 589 21 0D 0A 17 591 Rx: 61 24 [79 ms] 592 Secure Element for TLS Version 1.3 September 2020 594 SEND(Record Packet) 596 Tx: 00 C0 00 00 24 597 Rx: 17 03 03 00 1F 6F 78 FF 68 0F CA 9E 31 53 2C 96 598 B3 FA D7 B0 51 1B 92 81 35 3D DB FE E9 18 A7 DF 599 36 2F A5 27 90 00 [16 ms] 601 5 TLS-SE Name 603 According to ISO7816 standards, secure elements return upon reset a 604 set of bytes called Answer to Reset (ATR). ATR comprises at least 605 two bytes (TS, T0). The LSB nibble of T0 indicates the number of 606 historical bytes (ranging from 0 to 15). Historical bytes (HB) are 607 located at the end of ATR. Historical bytes can be programmed by 608 standardized API, and therefore MAY be used for secure element 609 naming. 611 6 Server Name Indication 613 According to [RFC6066] Server Name Indication extension is used to 614 route TLS packets toward a virtual host. 615 Multiple TLS-SE devices, embedding standalone applications, can be 616 hosted by an internet node. In this case SNI extension MAY be used 617 in order to select the right secure element, whose name, typically 618 stored in historical bytes, is determined from SNI. 620 7 IANA Considerations 622 This draft does not require any action from IANA. 624 8 Security Considerations 626 This entire document is about security. 628 9 References 630 9.1 Normative References 632 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 633 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 634 https://www.rfc-editor.org/info/rfc8446. 636 [RFC6066] Eastlake 3rd, D., "Transport Layer [RFC6066] Security 637 (TLS) Extensions: Extension Definitions", RFC 6066, DOI 638 10.17487/RFC6066, January 2011. 640 [ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards 641 with Contacts", The International Organization for Standardization 642 (ISO). 644 Secure Element for TLS Version 1.3 September 2020 646 [IEEE1363] IEEE, "IEEE Standard Specifications for Public Key 647 Cryptography", IEEE Std. 1363-2000, DOI 10.1109/IEEESTD.2000.92292. 649 9.2 Informative References 651 [IM] Urien, P., "Identity Module for TLS Version 1.3", draft-urien- 652 tls-im-03.txt, July 2020. 654 10 Authors' Addresses 656 Pascal Urien 657 Telecom Paris 658 19 place Marguerite Perey 659 91120 Palaiseau Phone: NA 660 France Email: Pascal.Urien@telecom-paris.fr