One document matched: draft-urien-tls-psk-emv-02.txt
Differences from draft-urien-tls-psk-emv-01.txt
TLS Working Group P. Urien
Internet Draft Telecom ParisTech
Intended status: Informational L.Cogneau and P. Martin
Expires: February 1, 2011 Xiring
September 1, 2010
EMV support for TLS-PSK
draft-urien-tls-psk-emv-02.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 March 1st, 2011.
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 February 2011 [Page 1]
EMV Support for TLS-PSK September 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
8. Annexe......................................................... 12
8.1 Example of EMV dialog...................................... 12
Authors' Addresses................................................ 13
Copyright Notice.................................................. 13
Urien & All Expires February 2011 [Page 2]
EMV Support for TLS-PSK September 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 the issuer. It could be, for example,
HSM (Hardware Secure Module) facilities controlled by the bank
issuer.
Urien & All Expires February 2011 [Page 3]
EMV Support for TLS-PSK September 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 February 2011 [Page 4]
EMV Support for TLS-PSK September 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 February 2011 [Page 5]
EMV Support for TLS-PSK September 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 February 2011 [Page 6]
EMV Support for TLS-PSK September 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 February 2011 [Page 7]
EMV Support for TLS-PSK September 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 yCDOL2.
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 February 2011 [Page 8]
EMV Support for TLS-PSK September 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 February 2011 [Page 9]
EMV Support for TLS-PSK September 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 February 2011 [Page 10]
EMV Support for TLS-PSK September 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.2", RFC 5246, August 2008
[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 February 2011 [Page 11]
EMV Support for TLS-PSK September 2010
7.2 Informative References
8. Annexe
8.1 Example of EMV dialog
Selection of the EMV VISA application
Tx: 00A40400 07 A0000000031010
Rx: 6133
Tx: 00C00000 33
Rx: 6F 31 84 07 A0 00 00 00 03 10 10 A5 26 50 04 56
49 53 41 87 01 02 9F 11 01 01 9F 12 04 56 49 53
41 5F 2D 02 66 72 BF 0C 0A DF 60 02 0B 19 9F 4D
02 0B 19 90 00
Starting an EMV session: the getProcessingOptions command
Tx: 80A80000 02 8300
Rx: 61 14
Tx: 00C00000 14
Rx: 80 12 7C 00 08 01 01 00 10 01 02 01 18 01 05 01
20 01 02 02 90 00
Checking the PIN code (1234)
Tx: 00200080 08 24 1234 FFFFFFFFFF
Rx: 90 00
Generation of an ARQC: ARQC(r32)
Tx: 80AE8000 1D
===================xCDOL1=========================
00 00 00 00 00 00, the transaction amount
00 00 00 00 00 00, the cash back
00 00, the national code of the payment terminal
80 00 00 00 00, the terminal verification result
00 00, the transaction currency code
01 01 01, the transaction date
00, the type of transaction
12 34 56 78, a four bytes random value: r32
==================================================
Rx: 6120
Tx: 00C00000 20
======================yCDOL1=======================
Rx: 77 1E 9F 27 01 80 9F 36 02 00 18 9F 26 08 80 29
D3 A0 BB 2A 5E 60 9F 10 07 06 7B 0A 03 A4 A0 00
===================================================
Urien & All Expires February 2011 [Page 12]
EMV Support for TLS-PSK September 2010
90 00
Generation of an AAC
Tx: 80AE0000 1F
=======================xCDOL2======================
5A 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80 00 00 00 00 00 00 01 01 01 00 12 34 56 78
===================================================
Rx: 6120
Tx: 00C00000 20
=======================yCDOL2======================
Rx: 77 1E 9F 27 01 00 9F 36 02 00 18 9F 26 08 05 84
16 5C F0 17 A6 66 9F 10 07 06 7B 0A 03 25 A0 00
===================================================
90 00
Authors' Addresses
Pascal Urien
Telecom ParisTech
37/39 rue Dareau, 75014 Paris, France
Email: Pascal.Urien@telecom-paristech.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 February 2011 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 01:31:47 |