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