[TLS] draft-urien-tls-psk-emv

[Marsh Ray <[e-mail]>]

I saw the emails on the Draft Agenda for IETF-77 came across the
statment about "In 2009, about 1 billion EMV device were issued". I
figured then this proposal could benefit from some review. I haven't
heard whatever discussion occurred at IETF-77.

======== EMV Background

Disclaimer: I didn't know any about EMV beforehand, but I downloaded
some pdfs and stayed up late one night clicking around on the web.

EMV provides a framework for developing protocols for card and user
authentication, and for authorization of specific transactions,
specifically payment systems. The details of the actual protocol
deployed depend on the card issuer, although it seems that there is
large degree of compatibility in practice and the card itself is able to
describe the needs of its issuer. Cards can support multiple "applications".

The EMV architecture has three components (from EMV Book 1):

1. A card with a smart chip and electrical contacts. The standards refer
to this as an ICC.

2. A terminal: "The device used [] at the point of transaction to
perform a financial transaction". This was envisioned to be a device
possessed by a merchant with its own display and keypad. This is
different than a simple card reader which might adapt the
electrical interface to something like USB.

3. A card issuer: This term is not defined, but presumably it's expected
to be a financial institution.

Operations with a card could be done online (where the terminal has an
active connection to the issuer) or offline.

User authentication is usually done with a shared secret between the
user and the card, with a four-digit PIN deemed good enough for legal
purposes.

EMV card systems have been subject to a number of attacks over the
years. Notably:

1. "Yes-card" skimming
>From what I can ascertain on the web, until recently most cards being
issued did not have the horsepower to do RSA. As a result, operations
relied on a Static Data Authentication (SDA) method based solely on a
MAC function involving a shared secret between the card and issuer.
Cards are issued with a Signed Static Application Data (SSAD) block,
which is not considered secret by the card. In online mode,
authentication happens with coordination of the issuer. However, in
offline mode, the terminal cannot strongly authenticate the card, user,
or the transaction. Brief physical access to a card ("skimming") allows
an attacker to produce a clone which doesn't bother to validate the
entered PIN ("yes-card").

All cards are required to support SDA at the protocol level, but I don't
think it's still accepted universally.

Modern cards support RSA and can thus do reasonable authentication
offline. Specs call this "Dynamic Data Authentication (DDA)"

2. Optimized to Fail: Card Readers for Online Banking
Saar Drimer, Steven J. Murdoch, Ross Anderson
http://www.cl.cam.ac.uk/~sjm217/papers/fc09optimised.pdf
Lists several vulnerabilities with the "Chip & PIN" brand of EMV under
the UK Chip Authentication Programme (CAP).

3. Chip and PIN is Broken
Steven J. Murdoch, Saar Drimer, Ross Anderson, Mike Bond
http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf
The authors demonstrate a mitm attack between the card and terminal
which allows bypassing the PIN check even when the terminal is online.

======== Notes on draft-urien-tls-psk-emv

This is the version reviewed here:
http://tools.ietf.org/html/draft-urien-tls-psk-emv-01

The ID proposes an enhancement to TLS allowing the use of EMV's SDA mode
to authenticate TLS connections.

-------- Design scope extension

The vulnerabilities and limitations found in past and current EMV card
deployments suggest that designers of actual systems tend to discount
certain modes of attack. For example, like many "closed" systems, there
is less defenses against malicious terminal hardware. The presence of
32-bit Unpredictable Numbers, four digit PINS, trivial card cloning, and
interface shimming attacks suggests that the system was more designed to
defend against a malicious waitperson than it was expected to be
resilient against dedicated reverse engineering.

It is even less likely that the designers considered the possibility
that their proprietary protocol would be used over the public net.

The differences between an EMV terminal and an ordinary smart card
reader are becoming a bit blurred. EMV terminals were originally
expected to be controlled by merchants, then they took the form of
pocket-calculator style devices. I don't know if any financial
institutions support payment this way, but some popular PC OSes can run
the EMV protocol over basic card readers (which have no dedicated keypad
or display).

For historical comparison, in response to the ease of copying audio CDs,
DVDs were introduced with copy protection which relied on secret
encryption algorithms and keys stored in hardware. This was broken soon
after a software player was made available which could simply be
observed in a debugger.

This is not to say that repurposing a closed industry-specific protocol
could never be made to work, only that it must be done with the greatest
of care. All assumptions (often unstated) made in the independent
security analyses of each protocol must be revisited, as well as the new
considerations (often subtle) raised by the combination of the two
protocols.

It is not specifically stated in this ID whether or not the 'terminal'
role as defined in EVP is intended to be implemented on specialized
hardware, in software on the PC, or even on the web server. This is
essential to define in order to discuss the security of an EVP protocol.

The Introduction (section 1 of the ID) implies that the purpose of this
proposal is user authentication, but there is no mention of where a PIN
would be entered. Because EMV systems typically authenticate the user to
the card using a PIN, it is essential to discuss this process.

Section 1.3 says "The user is equipped with an EMV chip and a smart card
reader." Using a simple card reader may violate common design
assumptions of EMV systems which expect the merchant to ensure physical
security of the terminal.

-------- Non-public data transmitted in the clear

The ID specifies that the psk-identity value be sent in the
ClientKeyExchange (CKE) message. CKE is sent before ChangeCipherSpec
(CCS), and thus in-the-clear for an initial handshake.

Multiple data items are concatenated to form psk-identity, three of
which are read directly from the card.

* Card Risk Management Data Object List 1 (CDOL1)

This is the list of data elements (but not the values themselves) that
the card is programmed to require for initiating a transaction.

There's probably nothing super-secret in this field, but it could also
uniquely identify the issuer. It could represent an information leak
that tells the passive eavesdropper that the user has a particular type
of account at a particular bank and that card is currently inserted into
the reader.
	
* "EMV-CPG" Response to (yCDOL1) Authorization Request Cryptogram (ARQC)

The cryptogram generated by the card in response to a request to begin a
transation. This value actually was intended by EMV to be transmitted
remotely, although the designers may have had something more like a
private phone line in mind rather than the hostile internet.

* PAN Sequence Number (PSN)  (PAN stands for Primary Account Number)

This article http://www.isg.rhul.ac.uk/~kp/EEMV.pdf says "the PAN
sequence number helps to identify a card amongst several cards belonging
to the same customer with the same PAN."

It seems to be up to the issuer to define the exact semantics of this
value. The EMV Books show a method where it is used in the generation of
the "16-byte ICC Master Key MK". It's usually listed alongside the
primary card number, much like the expiration date or the Card Security
Code (CSC).

Like most other values in the EMV specs, it isn't explicitly stated
whether it's considered public or privileged information. Nevertheless,
spec designers probably didn't intend for it to be sent over the public
internet unencrypted.

-------- Public data used for secrets

The ID defines three new cipher suites based on RFC 4279 TLS-PSK.
http://tools.ietf.org/html/rfc4279

All three cipher suites define:
> PSK = EMV-PSK
and
> EMV-PSK = h(SSAD), where - SSAD is the Signed Static Application 
> Data, - and h is a digest function

Based on the docs and the captured data in oakland10chipbroken.pdf, it
sure looks like the card considers SSAD to be public information. In
other words, the card will hand it over to any reader that asks for it.

Generally a pre-shared key is expected to be kept secret, like a password.

This case, however, is somewhat worse than a password. With an actual
password the web server doesn't have to store it in plaintext in order
to validate it. Recommended practice for web sites is to store only a
salted hash of the passwords (I think PCI card tranaction industry
standards require it). In this architecture (Figure 1) every website
which could potentially need to authenticate the user is required to
store the preshared key (not to mention the card account number) in
plaintext.

As this information is public, static, and bound to a specific hardware
item it is quite difficult to change.

When an attacker has this info (again, any reader or website that ever
handled this card) the PSK and DHE-PSK modes are vunerable to
impersonation of either the client or server end. The RSA-PSK
mode would allow impersonation of the client to the server or the server
to the client after the initial handshake completed. Additionally, the
PSK mode would allow decryption of data captured previously.

Of course, much of this caused by the limitations of PSK in general,
which comes from the decision to build on top of cards with
insufficient CPU for RSA.

-------- Replay attack

The EMV protocol allows for a 32-bit Unpredictable Number (R32) to be
included in the transaction in order to resist replay. R32 is generated
solely from the ClientRandom, and ServerRandom values passed in the
hello messages in-the-clear (RSA-PSK also includes ServerPublicKey).

Something with a known attack that succeeds after just 2^32 tries on
average is probably a little weak for a new design, especially one
specifically intended for financial data over the public network.

This might be a reasonable rate in a system where all failed
transactions are transmitted to at a central location where they are
correlated for fraud. However, in this case the attacker need only
elicit a single Server Hello packet for each attempt and may be content
with access to any one of many distributed servers.

Furthermore, the attacker can greatly increase his chances if he has
multiple previous auths to potentially replay. It is not out of the
question that he could observe 100 handshakes during a normal web
session, particularly if he can interfere with successful TLS session
resumption. With a pool of 100 handshakes to work with, the attacker
could expect to succeed after sending only about 43,000,000 packets.

It's not clear what time limit would be imposed on the attacker's
attempts. An attack could conceivably be diluted over sufficient time so
as to not cause a noticeable increase in load to a busy site.

-------- Server impersonation and credential forwarding

The PSK and DHE-PSK modes provide no server authentication. Hopefully
they would not be accepted by legitimate clients and servers in
practice. However, note the even the RSA_PSK ciphersuites do not allow
the client to effectively verify the server's certificate until the very
last message of the handshake (when he receives the Finished message
from the server).

In all three modes, an attacker impersonating the server side for the
first part of the handshake can also control R32. He could test on his
own hardware 2^32 variations on ServerRandom before choosing the one he
wishes to include in the Server Hello.

This suggests that a user connecting to a website could have his
authentication forwarded to authenticate the attacker's own connection
to the legitimate server. Perhaps the authentication
could even be forwarded off the network entirely to a shim device
inserted in an actual terminal.

The ID states that
> complexity may be increased by using multiple EMV cryptograms.
but there is no provision for actually doing this in the protocol. It is
not clear how well this would work in practice, e.g., would the user be
required to enter a PIN multiple times?

-------- IPR Disclosure

The author lists several patents on his web site including:

US Patent 6751671 Method of communication between a user station and
a network, in particular such as internet, and implementing architecture

Which says:
> However, according to another feature of this invention, the smart
> card can authorize direct links between the terminal and, in
> particular, the navigator, for Internet-type transmissions and the
> network, for example, for data that requires security processing
> (graphic or image data of "WEB" pages etc.).

I'm no expert on these matters, but it seem that it might be appropriate
to include an IPR Disclosure with this submission.

======== Conclusion

It looks like this proposal has some limitations:

The proposal relies on EMV's SDA authentication method which has
well-documented susceptibilities to counterfitting.

The proposal is subject to various attacks with a complexity of 2^32.

The proposal seems to allow any card reader that has ever interacted
with the card, as well as any website that could potentially need to
authenticate the user in the future, to intercept data and/or
impersonate one or both sides of the connection. Potentially this
impersonation could be redirected off the net to impersonate a card in a
physical terminal.

Since the website is required to know the credit card details and PSK in
advance, it would probably only be useful for the issuer's own site.

For these reasons I don't think this proposal has much utility as an
internet standard protocol feature.

- Marsh