[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

  TLS Working Group                                            P. Urien
  Internet Draft                                      Telecom ParisTech
  Intended status: Informational                L.Cogneau and P. Martin
  Expires: September 3, 2010                                     Xiring
                                                          March 3, 2010

                           EMV support for TLS-PSK
                        draft-urien-tls-psk-emv-01.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/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 3, 2010.

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 September 2010              [Page 1]


                            EMV Support for TLS-PSK         March 2010

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)................................. 11
      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 September 2010            [Page 2]


                            EMV Support for TLS-PSK         March 2010

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 September 2010            [Page 3]


                            EMV Support for TLS-PSK         March 2010

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 September 2010            [Page 4]


                            EMV Support for TLS-PSK         March 2010

                 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 September 2010            [Page 5]


                            EMV Support for TLS-PSK         March 2010

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 September 2010            [Page 6]


                            EMV Support for TLS-PSK         March 2010


   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 September 2010            [Page 7]


                            EMV Support for TLS-PSK         March 2010

  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 September 2010            [Page 8]


                            EMV Support for TLS-PSK         March 2010

   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 September 2010            [Page 9]


                            EMV Support for TLS-PSK         March 2010

   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

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.



   Urien & All             Expires September 2010            [Page 10]


                            EMV Support for TLS-PSK         March 2010

6.2 Man in Middle attack (MIM)

   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

   Urien & All             Expires September 2010            [Page 11]


                            EMV Support for TLS-PSK         March 2010

   Management, Book 3 - Application Specification, Book 4 - Cardholder,
   Attendant, and Acquirer Interface Require.


7.2 Informative References


Authors' Addresses

   Pascal Urien
   Telecom ParisTech
   37/39 rue Dareau, 75014 Paris, France

   Email: Pascal.Urien@enst.fr

Copyright Notice

   Copyright (c) 2010 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.


























   Urien & All             Expires September 2010            [Page 12]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/