idnits 2.17.1 draft-urien-tls-psk-emv-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 -- The document date (March 3, 2010) is 5166 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'TLS-EXT' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'EMV' is defined on line 550, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4346 (ref. 'TLS-EXT') (Obsoleted by RFC 5246) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group P. Urien 3 Internet Draft Telecom ParisTech 4 Intended status: Informational L.Cogneau and P. Martin 5 Expires: September 3, 2010 Xiring 6 March 3, 2010 8 EMV support for TLS-PSK 9 draft-urien-tls-psk-emv-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 3, 2010. 34 Abstract 36 This draft describes an authentication protocol based on TLS pre 37 shared key (TLS-PSK), RFC 4279. Identity and psk attributes, defined 38 in TLS-PSK are extracted from EMV chips, which are widely deployed 39 for payments transactions. The goal of this protocol is to provide a 40 strong mutual authentication transparent for the end users and 41 guarantying the confidentiality and the integrity of exchanged data 42 over Internet network. 43 This is a new step avoiding the use of static passwords for on-line 44 services, such as electronic banking or electronic payment. 46 Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC-2119. 52 Table of Contents 54 Abstract........................................................... 1 55 Conventions used in this document.................................. 1 56 1 Introduction..................................................... 3 57 1.1 The issuer.................................................. 3 58 1.2 The WEB site................................................ 4 59 1.3 The user.................................................... 4 60 2 About TLS-PSK.................................................... 4 61 2.1 The PSK mode................................................ 5 62 2.2 The DHE-PSK mode............................................ 5 63 2.3 The RSA-PSK mode............................................ 6 64 3 Overview of an EMV smart card.................................... 6 65 3.1 Definition of some EMV object............................... 6 66 3.1.1 PAN .................................................. 6 67 3.1.2 PSN .................................................. 6 68 3.1.3 Signed Static Application Data (SSAD) ................ 7 69 3.1.4 ICC Public Key Certificate (IPKC) .................... 7 70 3.1.5 CDOL1 ................................................ 7 71 3.1.6 CDOL2 ................................................ 7 72 3.2 Cryptogram generation....................................... 7 73 3.2.1 ARQC ................................................. 8 74 3.2.2 AAC .................................................. 8 75 4 EMV cards for TLS-PSK............................................ 8 76 4.1 Overview.................................................... 8 77 4.1.1 EMV-ID ............................................... 8 78 4.1.2 EMV-CPG .............................................. 8 79 4.1.3 EMV-PSK .............................................. 9 80 4.1.4 Authentication scheme selection ...................... 9 81 4.2 PSK calculations............................................ 9 82 4.2.1 psk .................................................. 9 83 4.2.2 psk-identity ......................................... 9 84 4.3 DHE-PSK calculations........................................ 9 85 4.3.1 psk .................................................. 9 86 4.3.2 psk-identity ......................................... 9 87 4.4 RSA-PSK calculations....................................... 10 88 4.4.1 psk ................................................. 10 89 4.4.2 psk-identity ........................................ 10 90 5 IANA Considerations............................................. 10 91 6 Security Considerations......................................... 10 92 6.1 Replay attack.............................................. 10 93 6.2 Man in Middle attack (MIM)................................. 11 94 6.3 Phishing attack............................................ 11 95 7 References...................................................... 11 96 7.1 Normative References....................................... 11 97 7.2 Informative References..................................... 12 98 Authors' Addresses................................................ 12 99 Full Copyright Statement.......................................... 12 100 1 Introduction 102 Millions of EMV cards, equipped with microprocessor chips (compliant 103 with ISO 7816-1/4 standard), are already deployed by banks and used 104 every day for payment transactions. These devices are equipped with 105 tamper resistant micro-controller and therefore have computing 106 resources. Each card is identified by a number (the PAN or Primary 107 Account Number) and stores a symmetric cryptographic key required 108 for cryptograms generation. The card contains at least one 109 certificate (RSA based) and its content is signed by its management 110 entity, usually refereed as the ISSUER. Optionally EMV cards hold 111 RSA private keys, used for authentication purposes according to a 112 mechanism called DDA (Dynamic Data authentication) 114 The goal of this protocol is to provide a strong and mutual 115 authentication method using EMV chip capabilities, and typically 116 used for on-line banking services. In order to avoid password 117 techniques which are vulnerable to social engineering based attacks 118 like Phishing or Man In The Middle, we suggest deploying TLS-PSK 119 [TLS-PSK] facilities; the needed parameters i.e. psk-identity and 120 psk, are stored and computed by standard EMV chips. In addition, 121 this authentication method does not require any decision-making from 122 an unaware end user. 124 The operational architecture deals with three entities, the issuer, 125 a registered WEB site, and the user. 127 +-----------+ TLS-PSK +-------------+ +----------+ 128 | |<------->| | (PAN,EMV-CTG) | ISSUER | 129 | USER | EMV-ID | WEB | ------------> | AUTH. | 130 | | EMV-CTG | SITE | OK | SERVER | 131 | | EMV-PSK | | <----------- | | 132 +----+------+ +------+------+ +-----+----+ 133 ! ! ! 134 +---v--+ ! DATABASE +--+--+ 135 | EMV | +--------+-----+-------+ | HSM | 136 |DEVICE| | EMV-ID | PAN | Other | +-----+ 137 +------+ +--------+-----+-------+ 139 Figure 1. Operational Architecture 141 1.1 The issuer. 143 The issuer authentication server checks cryptograms (EMV-CTG) 144 produced by EMV chip. These operations need the public information 145 of the EMV chip as PAN value and are usually performed thanks to a 146 security module controlled by he issuer. It could be, for example, 147 HSM (Hardware Secure Module) facilities controlled by the bank 148 issuer. 150 1.2 The WEB site. 152 The WEB site is able to indirectly authenticate EMV cryptograms, via 153 issuer services. It forwards (PAN, EMV-CTG) tuples, which are 154 checked by the issuer authentication center 156 This entity manages database that stores all useful public data 157 available in this customer EMV card. 159 We note EMV-ID a fix identifier used as an index (primary key) for 160 this database. EMV-ID is a digest of a set of public information 161 embedded in the EMV device; in order to avoid brute force attack its 162 entropy should be greater than 80 bits. 164 The psk-identity attribute includes EMV-ID, a cryptogram (EMV-CTG), 165 and additional values useful for its verification. 167 The psk attribute is deduced from the EMV device (EMV-PSK). 169 1.3 The user 171 The user is equipped with an EMV chip and a smart card reader. He 172 opens TLS-PSK sessions from its browser. 174 2 About TLS-PSK 176 The [TLS-PSK] describes a pre-shared key mechanism dedicated to the 177 TLS protocol. Two additional parameters are defined 178 - The PSK or pre-shared key. 179 - The PSK identity (psk-identity), an identifier associated to the 180 PSK value 182 The Client starts a TLS-PSK dialog by requesting specific 183 CipherSuites in its Hello message. Three set of Cipher-Suites are 184 supported 186 - The first set (PSK) uses only symmetric key operations for 187 authentication. 188 - The second set (DHE-PSK) uses a Diffie-Hellman exchange 189 authenticated with a pre-shared key, 190 - The third set (RSA-PSK) combines public key authentication of the 191 server with pre-shared key authentication of the client. 193 The Server chooses a CipherSuite and MAY select a particular psk- 194 identity scheme by inserting the parameter psk-identity-hint in its 195 ServerKeyExchange message 197 struct { 198 select (KeyExchangeAlgorithm) { 199 /* other cases for rsa, diffie_hellman, etc. */ 200 case psk: /* NEW */ 201 case diffie_hellman_psk: 202 case rsa-psk: 203 opaque psk-identity-hint<0..2^16-1>; 204 }; 205 } ServerKeyExchange; 207 2.1 The PSK mode 209 The client packs in the ClientKeyExchange its PSK identity (psk- 210 identity) 212 struct { 213 select (KeyExchangeAlgorithm) { 214 /* other cases for rsa, diffie_hellman, etc. */ 215 case psk: /* NEW */ 216 opaque psk-identity<0..2^16-1>; 217 } exchange_keys; 218 } ClientKeyExchange; 220 If the PSK is N octets, the premaster secret is formed by the 221 concatenation of 222 - A uint16 reflecting the N value, 223 - N zero octets, 224 - A uint16 reflecting the N value, 225 - The PSK value. 227 2.2 The DHE-PSK mode 229 The client packs in the ClientKeyExchange its PSK identity (psk- 230 identity) 232 struct { 233 select (KeyExchangeAlgorithm) { 234 /* other cases for rsa, diffie_hellman, etc. */ 235 case Diffie-hellman-psk: /* NEW */ 236 opaque psk-identity<0..2^16-1>; 237 ClientDiffieHellmanPublic public; 238 } exchange_keys; 239 } ClientKeyExchange; 241 If the PSK is N octets, the premaster secret is formed by the 242 concatenation of: 244 - A uint16 reflecting the Diffie Hellman value, 245 - The Diffie Hellman computed value (g**ab), 246 - A uint16 reflecting PSK length, 247 - The PSK value. 249 2.3 The RSA-PSK mode 251 The client packs in the ClientKeyExchange its PSK identity (psk- 252 identity) 254 struct { 255 select (KeyExchangeAlgorithm) { 256 /* other cases for rsa, diffie_hellman, etc. */ 257 case rsa_psk: /* NEW */ 258 opaque psk-identity<0..2^16-1>; 259 EncryptedPreMasterSecret; 260 } exchange_keys; 261 } ClientKeyExchange 263 "The EncryptedPreMasterSecret field sent from the client to the 264 server contains a 2-byte version number and a 46-byte random value, 265 encrypted using the server's RSA public key". If the PSK is N 266 octets, the actual premaster secret is formed by the concatenation 267 of: 269 - A uint16 reflecting the length of the RSA premaster secret (48 270 bytes). 271 - The RSA premaster secret, 2-byte version number and a 46-byte 272 random value. 273 - A uint16 reflecting PSK length, 274 - The PSK value. 276 3 Overview of an EMV smart card 278 An EMV smart card contains one or several EMV applications. 280 An EMV application manages a set of information that can be freely 281 read. These data are encoding according to the ASN.1 syntax. 283 An EMV application produces cryptograms that authenticate payment 284 transactions. 286 3.1 Definition of some EMV object 288 3.1.1 PAN 290 The Primary Account Number (PAN) is typically an 8 bytes value, 291 which represents the card number, coded according to a BCD format 292 (i.e. 16= 2x8 decimal digits). 294 The TAG associated to this object is 0x5A. 296 3.1.2 PSN 298 The PAN Sequence Number (PSN) represents an additional identifier 299 for the card; its typical value is 0x00. 301 The TAG associated to this object is 0x5F34. 303 3.1.3 Signed Static Application Data (SSAD) 305 This attribute is a signature for a set of information stored in the 306 card. 308 The TAG associated to this object is 0x93. 310 3.1.4 ICC Public Key Certificate (IPKC) 312 This optional attribute, is the certificate of the card public key 313 (if any). Generally the remainder of the public key is stored in an 314 additional object, the ICC Public Key Remainder (IPKR) 316 The TAG associated to the object ICC Public Key Certificate is 317 0x9F46. 319 The TAG associated to the object ICC Public Key Remainder is 0x9F46 321 3.1.5 CDOL1 323 The Card Risk Management Data 1 (CDOL1), is according to the EMV 324 terminology a Data Object List (DOL), i.e. a list of tuples TAG 325 value (one or two bytes) and object length (one byte) 327 CDOL1 is the list of objects required for the generation of a 328 transaction cryptogram. 330 The TAG associated to this attribute is 0x8C 332 3.1.6 CDOL2 334 The Card Risk Management Data 2 (CDOL2), is according to the EMV 335 terminology a Data Object List (DOL), i.e. a list of tuples TAG 336 value (one or two bytes) and the object length (one byte) 338 CDOL2 is the list of objects required for the completion of a 339 transaction. It is the concatenation of the Authorization Response 340 Code (TAG 8A, length 02) and the CDOL1 value. 342 The TAG associated to this attribute is 0x8D 344 3.2 Cryptogram generation 346 Cryptogram generation is handled by the GENERATE AC command, 347 associated with ARQC (Authorization Request Cryptogram) or AAC 348 (Application Authentication Cryptogram) parameters. 350 3.2.1 ARQC 352 The Authorization Request Cryptogram (ARQC) starts an EMV 353 transaction. A set of values, whose elements are listed by the CDOL1 354 object, and without TAG or length information, are pushed towards 355 the card. 357 The content of CDOL1 is noted xCDOL1 and the response to ARQC is 358 noted yCDOL1. 360 xCDOL1 comprises an Unpredictable Number (TAG 9F37, length 04), i.e. 361 a random value of 32 bits. The response yCDOL1, includes an 8 bytes 362 cryptogram and additional information. 364 3.2.2 AAC 366 The Application Authentication Cryptogram ends an EMV transaction. A 367 set of values, whose elements are listed by the CDOL2 object, and 368 without TAG or length information, are pushed towards the card. 370 The content of CDOL2 is noted xCDOL2 and the response to AAC is 371 noted xCDOL2. 373 4 EMV cards for TLS-PSK 375 4.1 Overview 377 The basic idea of this protocol is to used the PAN, i.e. the card 378 number as a static PSK. However the PAN entropy is small, about 36 379 bits, so brute force attacks are possible. In order to avoid these 380 issues, the PAN value is replaced by others parameters stored in the 381 card and providing sufficient entropy, e.g. greater than 80 bits. 383 The psk-identity is a list of information proving that the client 384 holds the card associated with the PAN. This proof is based on an 385 ARQC associated with a 32 bits random number, which is noted r32. 387 4.1.1 EMV-ID 389 The EMV-ID attribute is computed according the following relation: 391 EMV-ID = h(h(SSAD)), where 392 - SSAD is the Signed Static Application Data, 393 - and h is a digest function 395 4.1.2 EMV-CPG 397 The EMV cryptogram (emv-cpg) is the response (yCDOL1) to an ARQC 398 associated with the r32 random number. The ARQC request is followed 399 by an AAC operation that cancels the EMV transaction. 401 Values used for ARQC and AAC (xCDOL1 and xCDOL2) are fix, apart from 402 the unpredictable number set to r32, and their structures are 403 described by the CDOL1 and CDOL2 objects. 405 By convention, the R32 number is a concatenation of multiple r32i 406 values (up to four), and EMV-CPG is the concatenation of associated 407 emv-cpgi, with the index i ranging between 1 and R32-length/4. 409 4.1.3 EMV-PSK 411 The EMV-PSK attribute is computed according to the following 412 relation: 414 EMV-PSK = h(SSAD), where 415 - SSAD is the Signed Static Application Data, 416 - and h is a digest function 418 4.1.4 Authentication scheme selection 420 When the parameter psk-identity-hint is not delivered by the server, 421 a default mode is selected. This default mode works with a static 422 PSK. Otherwise the psk-identity-hint determines a particular profile 423 for xCDOL1 values and PSK calculation. 425 4.2 PSK calculations 427 4.2.1 psk 429 PSK = EMV-PSK. 431 4.2.2 psk-identity 433 RH = h(ClientRandom | ServerRandom), where h is a digest function. 435 R32 is the 32 less significant bits of RH. 437 The psk-identity is the concatenation of the following values: 438 uint16(length) | R32 439 uint16(length) | EMV-ID 440 unit16(length) | PSN 441 uint16(length) | CDOL1 442 uint16(length) | EMV-CPG 444 4.3 DHE-PSK calculations 446 4.3.1 psk 448 PSK = EMV-PSK. 450 4.3.2 psk-identity 451 RH = h(ClientRandom | ServerRandom | ServerPublicKey), where h is a 452 digest function. 454 R32 is the 32 less significant bits of RH. 456 The psk-identity is the concatenation of the following values: 457 uint16(length) | R32 458 uint16(length) | EMV-ID 459 unit16(length) | PSN 460 uint16(length) | CDOL1 461 uint16(length) | EMV-CPG 463 4.4 RSA-PSK calculations 465 4.4.1 psk 467 PSK = EMV-PSK 469 4.4.2 psk-identity 471 RH = h(ClientRandom | ServerRandom | ServerPublicKey), where h is a 472 digest function. 474 R32 is the 32 less significant bits of RH. 476 The psk-identity is the concatenation of the following values: 477 uint16(length) | R32 478 uint16(length) | EMV-ID 479 unit16(length) | PSN 480 uint16(length) | CDOL1 481 uint16(length) | EMV-CPG 483 5 IANA Considerations 485 6 Security Considerations 487 6.1 Replay attack 489 The attacker holds a previous value of the psk-identity, including a 490 datagram and R32 random value. He then starts a TLS-PSK session with 491 the server and generates the ClientRandom value. 493 Because the server produces the ServerRandom value, this attack will 494 success with a probability of 1/2**32, since R32 is deduced from 495 h(ClientRandom | ServerRandom). This probability may be reduced by 496 using multiple EMV cryptograms. 498 However, even with this low probability, the attacker will also need 499 to collect the EMV-PSK value. 501 6.2 Man in Middle attack (MIM) 503 In a MIM scenario, the user opens a session with a fake server that 504 afterwards opens another session with the legitimate server. In that 505 case both sessions works with the same tuple of ClientRandom and 506 ClientServer numbers. 508 As a consequence information transported by psk-identity for PSK and 509 DHE-PSK is valid, i.e. the EMV datagram is generated with the right 510 R32=h(ClientRandom | ServerRandom) parameter. 512 In the case of RSA-PSK the fake server will need to choose a public 513 key (FakeServerPublicKey) so that, 515 R32 = h(FakeClientRandom | ServerRandom | FakeServerPublicKey) 517 So he will have to manage a set of 2**32 public key, and to compute 518 about 2**32 digest values. This complexity may be increased by using 519 multiple EMV cryptograms. 521 This attack works only if the hacker knows the correct EMV-PSK 522 information. 524 6.3 Phishing attack 526 Phishing attack will collect a valid psk-identity, but as 527 demonstrated in section 6.1 reply attacks do not work. 529 7 References 531 7.1 Normative References 533 [TLS 1.0] Dierks, T., C. Allen, "The TLS Protocol Version 1.0", RFC 534 2246, January 1999 536 [TLS 1.1] Dierks, T., Rescorla, E., "The Transport Layer Security 537 (TLS) Protocol Version 1.1", RFC 4346, April 2006 539 [TLS 1.2] Dierks, T., Rescorla, E., "The Transport Layer Security 540 (TLS) Protocol Version 1.1", draft-ietf-tls-rfc4346-bis-10.txt, 541 March 2008 543 [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D, Mikkelsen, J, 544 Wright, T., "Transport Layer Security (TLS) Extensions", RFC 4346, 545 April 2006 547 [TLS-PSK] P. Eronen, H. Tschofenig, "Pre-Shared Key Ciphersuites for 548 Transport Layer Security (TLS"), RFC 4279, December 2005. 550 [EMV] Book 1 - Application Independent ICC to Terminal Interface 551 Requirement and Application Selection, Book 2 - Security and Key 552 Management, Book 3 - Application Specification, Book 4 - Cardholder, 553 Attendant, and Acquirer Interface Require. 555 7.2 Informative References 557 Authors' Addresses 559 Pascal Urien 560 Telecom ParisTech 561 37/39 rue Dareau, 75014 Paris, France 563 Email: Pascal.Urien@enst.fr 565 Copyright Notice 567 Copyright (c) 2010 IETF Trust and the persons identified as the 568 document authors. All rights reserved. 570 This document is subject to BCP 78 and the IETF Trust's Legal 571 Provisions Relating to IETF Documents 572 (http://trustee.ietf.org/license-info) in effect on the date of 573 publication of this document. Please review these documents 574 carefully, as they describe your rights and restrictions with 575 respect to this document.