TLS Working Group P. Urien Internet Draft Telecom ParisTech Intended status: Informational L.Cogneau and P. Martin Expires: April 15, 2010 Xiring October 15, 2009 EMV support for TLS-PSK draft-urien-tls-psk-emv-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This draft describes an authentication protocol based on TLS pre shared key (TLS-PSK), RFC 4279. Identity and psk attributes, defined in TLS-PSK are extracted from EMV chips, which are widely deployed for payments transactions. The goal of this protocol is to provide a strong mutual authentication transparent for the end users and guarantying the confidentiality and the integrity of exchanged data over Internet network. This is a new step avoiding the use of static passwords for on-line services, such as electronic banking or electronic payment. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Urien & All Expires April 2010 [Page 1] EMV Support for TLS-PSK October 2009 Table of Contents Abstract........................................................... 1 Conventions used in this document.................................. 1 1 Introduction..................................................... 3 1.1 The issuer.................................................. 3 1.2 The WEB site................................................ 4 1.3 The user.................................................... 4 2 About TLS-PSK.................................................... 4 2.1 The PSK mode................................................ 5 2.2 The DHE-PSK mode............................................ 5 2.3 The RSA-PSK mode............................................ 6 3 Overview of an EMV smart card.................................... 6 3.1 Definition of some EMV object............................... 6 3.1.1 PAN .................................................. 6 3.1.2 PSN .................................................. 6 3.1.3 Signed Static Application Data (SSAD) ................ 7 3.1.4 ICC Public Key Certificate (IPKC) .................... 7 3.1.5 CDOL1 ................................................ 7 3.1.6 CDOL2 ................................................ 7 3.2 Cryptogram generation....................................... 7 3.2.1 ARQC ................................................. 8 3.2.2 AAC .................................................. 8 4 EMV cards for TLS-PSK............................................ 8 4.1 Overview.................................................... 8 4.1.1 EMV-ID ............................................... 8 4.1.2 EMV-CPG .............................................. 8 4.1.3 EMV-PSK .............................................. 9 4.1.4 Authentication scheme selection ...................... 9 4.2 PSK calculations............................................ 9 4.2.1 psk .................................................. 9 4.2.2 psk-identity ......................................... 9 4.3 DHE-PSK calculations........................................ 9 4.3.1 psk .................................................. 9 4.3.2 psk-identity ......................................... 9 4.4 RSA-PSK calculations....................................... 10 4.4.1 psk ................................................. 10 4.4.2 psk-identity ........................................ 10 5 IANA Considerations............................................. 10 6 Security Considerations......................................... 10 6.1 Replay attack.............................................. 10 6.2 Man in Middle attack (MIM)................................. 10 6.3 Phishing attack............................................ 11 7 References...................................................... 11 7.1 Normative References....................................... 11 7.2 Informative References..................................... 12 Authors' Addresses................................................ 12 Full Copyright Statement.......................................... 12 Urien & All Expires April 2010 [Page 2] EMV Support for TLS-PSK October 2009 1 Introduction Millions of EMV cards, equipped with microprocessor chips (compliant with ISO 7816-1/4 standard), are already deployed by banks and used every day for payment transactions. These devices are equipped with tamper resistant micro-controller and therefore have computing resources. Each card is identified by a number (the PAN or Primary Account Number) and stores a symmetric cryptographic key required for cryptograms generation. The card contains at least one certificate (RSA based) and its content is signed by its management entity, usually refereed as the ISSUER. Optionally EMV cards hold RSA private keys, used for authentication purposes according to a mechanism called DDA (Dynamic Data authentication) The goal of this protocol is to provide a strong and mutual authentication method using EMV chip capabilities, and typically used for on-line banking services. In order to avoid password techniques which are vulnerable to social engineering based attacks like Phishing or Man In The Middle, we suggest deploying TLS-PSK [TLS-PSK] facilities; the needed parameters i.e. psk-identity and psk, are stored and computed by standard EMV chips. In addition, this authentication method does not require any decision-making from an unaware end user. The operational architecture deals with three entities, the issuer, a registered WEB site, and the user. +-----------+ TLS-PSK +-------------+ +----------+ | |<------->| | (PAN,EMV-CTG) | ISSUER | | USER | EMV-ID | WEB | ------------> | AUTH. | | | EMV-CTG | SITE | OK | SERVER | | | EMV-PSK | | <----------- | | +----+------+ +------+------+ +-----+----+ ! ! ! +---v--+ ! DATABASE +--+--+ | EMV | +--------+-----+-------+ | HSM | |DEVICE| | EMV-ID | PAN | Other | +-----+ +------+ +--------+-----+-------+ Figure 1. Operational Architecture 1.1 The issuer. The issuer authentication server checks cryptograms (EMV-CTG) produced by EMV chip. These operations need the public information of the EMV chip as PAN value and are usually performed thanks to a security module controlled by he issuer. It could be, for example, HSM (Hardware Secure Module) facilities controlled by the bank issuer. Urien & All Expires April 2010 [Page 3] EMV Support for TLS-PSK October 2009 1.2 The WEB site. The WEB site is able to indirectly authenticate EMV cryptograms, via issuer services. It forwards (PAN, EMV-CTG) tuples, which are checked by the issuer authentication center This entity manages database that stores all useful public data available in this customer EMV card. We note EMV-ID a fix identifier used as an index (primary key) for this database. EMV-ID is a digest of a set of public information embedded in the EMV device; in order to avoid brute force attack its entropy should be greater than 80 bits. The psk-identity attribute includes EMV-ID, a cryptogram (EMV-CTG), and additional values useful for its verification. The psk attribute is deduced from the EMV device (EMV-PSK). 1.3 The user The user is equipped with an EMV chip and a smart card reader. He opens TLS-PSK sessions from its browser. 2 About TLS-PSK The [TLS-PSK] describes a pre-shared key mechanism dedicated to the TLS protocol. Two additional parameters are defined - The PSK or pre-shared key. - The PSK identity (psk-identity), an identifier associated to the PSK value The Client starts a TLS-PSK dialog by requesting specific CipherSuites in its Hello message. Three set of Cipher-Suites are supported - The first set (PSK) uses only symmetric key operations for authentication. - The second set (DHE-PSK) uses a Diffie-Hellman exchange authenticated with a pre-shared key, - The third set (RSA-PSK) combines public key authentication of the server with pre-shared key authentication of the client. The Server chooses a CipherSuite and MAY select a particular psk- identity scheme by inserting the parameter psk-identity-hint in its ServerKeyExchange message struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ Urien & All Expires April 2010 [Page 4] EMV Support for TLS-PSK October 2009 case psk: /* NEW */ case diffie_hellman_psk: case rsa-psk: opaque psk-identity-hint<0..2^16-1>; }; } ServerKeyExchange; 2.1 The PSK mode The client packs in the ClientKeyExchange its PSK identity (psk- identity) struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case psk: /* NEW */ opaque psk-identity<0..2^16-1>; } exchange_keys; } ClientKeyExchange; If the PSK is N octets, the premaster secret is formed by the concatenation of - A uint16 reflecting the N value, - N zero octets, - A uint16 reflecting the N value, - The PSK value. 2.2 The DHE-PSK mode The client packs in the ClientKeyExchange its PSK identity (psk- identity) struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case Diffie-hellman-psk: /* NEW */ opaque psk-identity<0..2^16-1>; ClientDiffieHellmanPublic public; } exchange_keys; } ClientKeyExchange; If the PSK is N octets, the premaster secret is formed by the concatenation of: - A uint16 reflecting the Diffie Hellman value, - The Diffie Hellman computed value (g**ab), - A uint16 reflecting PSK length, - The PSK value. Urien & All Expires April 2010 [Page 5] EMV Support for TLS-PSK October 2009 2.3 The RSA-PSK mode The client packs in the ClientKeyExchange its PSK identity (psk- identity) struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case rsa_psk: /* NEW */ opaque psk-identity<0..2^16-1>; EncryptedPreMasterSecret; } exchange_keys; } ClientKeyExchange "The EncryptedPreMasterSecret field sent from the client to the server contains a 2-byte version number and a 46-byte random value, encrypted using the server's RSA public key". If the PSK is N octets, the actual premaster secret is formed by the concatenation of: - A uint16 reflecting the length of the RSA premaster secret (48 bytes). - The RSA premaster secret, 2-byte version number and a 46-byte random value. - A uint16 reflecting PSK length, - The PSK value. 3 Overview of an EMV smart card An EMV smart card contains one or several EMV applications. An EMV application manages a set of information that can be freely read. These data are encoding according to the ASN.1 syntax. An EMV application produces cryptograms that authenticate payment transactions. 3.1 Definition of some EMV object 3.1.1 PAN The Primary Account Number (PAN) is typically an 8 bytes value, which represents the card number, coded according to a BCD format (i.e. 16= 2x8 decimal digits). The TAG associated to this object is 0x5A. 3.1.2 PSN The PAN Sequence Number (PSN) represents an additional identifier for the card; its typical value is 0x00. Urien & All Expires April 2010 [Page 6] EMV Support for TLS-PSK October 2009 The TAG associated to this object is 0x5F34. 3.1.3 Signed Static Application Data (SSAD) This attribute is a signature for a set of information stored in the card. The TAG associated to this object is 0x93. 3.1.4 ICC Public Key Certificate (IPKC) This optional attribute, is the certificate of the card public key (if any). Generally the remainder of the public key is stored in an additional object, the ICC Public Key Remainder (IPKR) The TAG associated to the object ICC Public Key Certificate is 0x9F46. The TAG associated to the object ICC Public Key Remainder is 0x9F46 3.1.5 CDOL1 The Card Risk Management Data 1 (CDOL1), is according to the EMV terminology a Data Object List (DOL), i.e. a list of tuples TAG value (one or two bytes) and object length (one byte) CDOL1 is the list of objects required for the generation of a transaction cryptogram. The TAG associated to this attribute is 0x8C 3.1.6 CDOL2 The Card Risk Management Data 2 (CDOL2), is according to the EMV terminology a Data Object List (DOL), i.e. a list of tuples TAG value (one or two bytes) and the object length (one byte) CDOL2 is the list of objects required for the completion of a transaction. It is the concatenation of the Authorization Response Code (TAG 8A, length 02) and the CDOL1 value. The TAG associated to this attribute is 0x8D 3.2 Cryptogram generation Cryptogram generation is handled by the GENERATE AC command, associated with ARQC (Authorization Request Cryptogram) or AAC (Application Authentication Cryptogram) parameters. Urien & All Expires April 2010 [Page 7] EMV Support for TLS-PSK October 2009 3.2.1 ARQC The Authorization Request Cryptogram (ARQC) starts an EMV transaction. A set of values, whose elements are listed by the CDOL1 object, and without TAG or length information, are pushed towards the card. The content of CDOL1 is noted xCDOL1 and the response to ARQC is noted yCDOL1. xCDOL1 comprises an Unpredictable Number (TAG 9F37, length 04), i.e. a random value of 32 bits. The response yCDOL1, includes an 8 bytes cryptogram and additional information. 3.2.2 AAC The Application Authentication Cryptogram ends an EMV transaction. A set of values, whose elements are listed by the CDOL2 object, and without TAG or length information, are pushed towards the card. The content of CDOL2 is noted xCDOL2 and the response to AAC is noted xCDOL2. 4 EMV cards for TLS-PSK 4.1 Overview The basic idea of this protocol is to used the PAN, i.e. the card number as a static PSK. However the PAN entropy is small, about 36 bits, so brute force attacks are possible. In order to avoid these issues, the PAN value is replaced by others parameters stored in the card and providing sufficient entropy, e.g. greater than 80 bits. The psk-identity is a list of information proving that the client holds the card associated with the PAN. This proof is based on an ARQC associated with a 32 bits random number, which is noted r32. 4.1.1 EMV-ID The EMV-ID attribute is computed according the following relation: EMV-ID = h(h(SSAD)), where - SSAD is the Signed Static Application Data, - and h is a digest function 4.1.2 EMV-CPG The EMV cryptogram (emv-cpg) is the response (yCDOL1) to an ARQC associated with the r32 random number. The ARQC request is followed by an AAC operation that cancels the EMV transaction. Urien & All Expires April 2010 [Page 8] EMV Support for TLS-PSK October 2009 Values used for ARQC and AAC (xCDOL1 and xCDOL2) are fix, apart from the unpredictable number set to r32, and their structures are described by the CDOL1 and CDOL2 objects. By convention, the R32 number is a concatenation of multiple r32i values (up to four), and EMV-CPG is the concatenation of associated emv-cpgi, with the index i ranging between 1 and R32-length/4. 4.1.3 EMV-PSK The EMV-PSK attribute is computed according to the following relation: EMV-PSK = h(SSAD), where - SSAD is the Signed Static Application Data, - and h is a digest function 4.1.4 Authentication scheme selection When the parameter psk-identity-hint is not delivered by the server, a default mode is selected. This default mode works with a static PSK. Otherwise the psk-identity-hint determines a particular profile for xCDOL1 values and PSK calculation. 4.2 PSK calculations 4.2.1 psk PSK = EMV-PSK. 4.2.2 psk-identity RH = h(ClientRandom | ServerRandom), where h is a digest function. R32 is the 32 less significant bits of RH. The psk-identity is the concatenation of the following values: uint16(length) | R32 uint16(length) | EMV-ID unit16(length) | PSN uint16(length) | CDOL1 uint16(length) | EMV-CPG 4.3 DHE-PSK calculations 4.3.1 psk PSK = EMV-PSK. 4.3.2 psk-identity Urien & All Expires April 2010 [Page 9] EMV Support for TLS-PSK October 2009 RH = h(ClientRandom | ServerRandom), where h is a digest function. R32 is the 32 less significant bits of RH. The psk-identity is the concatenation of the following values: uint16(length) | R32 uint16(length) | EMV-ID unit16(length) | PSN uint16(length) | CDOL1 uint16(length) | EMV-CPG 4.4 RSA-PSK calculations 4.4.1 psk PSK = EMV-PSK 4.4.2 psk-identity RH = h(ClientRandom | ServerRandom | ServerPublicKey), where h is a digest function. R32 is the 32 less significant bits of RH. The psk-identity is the concatenation of the following values: uint16(length) | R32 uint16(length) | EMV-ID unit16(length) | PSN uint16(length) | CDOL1 uint16(length) | EMV-CPG 5 IANA Considerations 6 Security Considerations 6.1 Replay attack The attacker holds a previous value of the psk-identity, including a datagram and R32 random value. He then starts a TLS-PSK session with the server and generates the ClientRandom value. Because the server produces the ServerRandom value, this attack will success with a probability of 1/2**32, since R32 is deduced from h(ClientRandom | ServerRandom). This probability may be reduced by using multiple EMV cryptograms. However, even with this low probability, the attacker will also need to collect the EMV-PSK value. 6.2 Man in Middle attack (MIM) Urien & All Expires April 2010 [Page 10] EMV Support for TLS-PSK October 2009 In a MIM scenario, the user opens a session with a fake server that afterwards opens another session with the legitimate server. In that case both sessions works with the same tuple of ClientRandom and ClientServer numbers. As a consequence information transported by psk-identity for PSK and DHE-PSK is valid, i.e. the EMV datagram is generated with the right R32=h(ClientRandom | ServerRandom) parameter. In the case of RSA-PSK the fake server will need to choose a public key (FakeServerPublicKey) so that, R32 = h(FakeClientRandom | ServerRandom | FakeServerPublicKey) So he will have to manage a set of 2**32 public key, and to compute about 2**32 digest values. This complexity may be increased by using multiple EMV cryptograms. This attack works only if the hacker knows the correct EMV-PSK information. 6.3 Phishing attack Phishing attack will collect a valid psk-identity, but as demonstrated in section 6.1 reply attacks do not work. 7 References 7.1 Normative References [TLS 1.0] Dierks, T., C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999 [TLS 1.1] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006 [TLS 1.2] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.1", draft-ietf-tls-rfc4346-bis-10.txt, March 2008 [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D, Mikkelsen, J, Wright, T., "Transport Layer Security (TLS) Extensions", RFC 4346, April 2006 [TLS-PSK] P. Eronen, H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS"), RFC 4279, December 2005. [EMV] Book 1 - Application Independent ICC to Terminal Interface Requirement and Application Selection, Book 2 - Security and Key Management, Book 3 - Application Specification, Book 4 - Cardholder, Attendant, and Acquirer Interface Require. Urien & All Expires April 2010 [Page 11] EMV Support for TLS-PSK October 2009 7.2 Informative References Authors' Addresses Pascal Urien Telecom ParisTech 37/39 rue Dareau, 75014 Paris, France Email: Pascal.Urien@enst.fr Full Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires April 2010 Urien & All Expires April 2010 [Page 12]