[LINK] RFC: How do Contact-Chips make Credit-Cards more secure?
Roger Clarke
Roger.Clarke at xamax.com.au
Mon Feb 7 15:33:38 AEDT 2011
I'm presenting a seminar on 'mobile payments security' at Bond Uni
this Friday 11 Feb at 15:00. It's an updated version of this paper:
http://www.rogerclarke.com/EC/MP-RAF-1102.html
Part of the seminar is a review of the security of several pre-mobile
payment mechanisms.
I'm trying to summarise why credit-card transactions using
contact-chips (EMV) are capable of being more secure than
transactions using the embossing (i.e. flick-flack) or the mag-stripe.
(Contactless chips, as in Visa Paywave and MCard Passport, are a
separate analysis - and, as discussed a while back, a much, much
scarier one).
I'm focussing on card plus PIN, rather than card plus signature
(because my real target is mobile payments, and PIN is the direction
we're all going).
If anyone can spot any material flaws in what follows, I'd greatly
appreciate a quick heads-up.
Thanks! ... Roger
________________________________________________________________________
As I understand it, the reasons why Chip-Card (EMV) credit-cards are
more secure than their predecessors are as follows:
(1) Chip-Cards can't be cloned
The data in the chip can't be accessed (whereas printing, embossing
and mag-stripe data can); and hence a fraudster can't produce a
functionally equivalent clone of tbe card
(2) A Chip-Card can help prevent successful replay attacks
The chip can provide a different transaction-stamp to each
transaction, and thereby enable financial institutions to detect when
a valid transaction is submitted to it a second time. (Without such
a stamp, a genuine identical transaction is difficult to distinguish
from a fraudulent one).
(3) A Chip-Card can authenticate the terminal
A Chip-Card can engage in a challenge-response conversation with the
ATM or EFTPOS terminal, and hence check whether the device is
trustworthy.
It can be argued that a further security feature is:
(4) The Chip-Card enables the PIN to be authenticated offline
For example, this can be done by storing a hash of the PIN. But this
is essentially a service improvements, not a security improvement.
That's because a terminal that is designed to be online but is
currently offline should simply not process any transactions (because
it can't authenticate the PIN), whereas an offline terminal *can*
process a transaction if a trustworthy Chip-Card says the PIN is
correct.
Each of these security features may or may not be real, depending on
the circumstances (such as the programming of the terminal, the
country that the device is in, and the country in which the card was
issued). In Australia:
- there may still be some ATMs that can't handle the chip, and work
only off the mag-stripe, and hence are open to cloning fraud
- there may still be unattended EFTPOS terminals with the same problem
There are multiple other risks that the chip and EMV design do not address
(e.g. PIN observation, combined with theft or borrowing of the card).
There is little or no impact on card not present contexts (Mail,
Telephone, Internet). (The card may or may not be in the hand of the
person instigating the remote transaction, but very few of such
people have a contact-card reader available and hence the chip can't
be used).
There can be operational deficiencies (e.g. fallback arrangements),
and some design flaws have been demonstrated (e.g. by Cambridge Uni
Computer Lab staff).
Hence:
- implementation of Chip-Cards and EMV is a good thing, but ...
- it only addresses some risks
- it does not address even those risks entirely reliably
- to date, it does very little for cross-border fraud, because
national implementations of international standards reflect
local factors and hence are highly varied (or just haphazard)
--
Roger Clarke http://www.rogerclarke.com/
Xamax Consultancy Pty Ltd 78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 1472, and 6288 6916
mailto:Roger.Clarke at xamax.com.au http://www.xamax.com.au/
Visiting Professor in the Cyberspace Law & Policy Centre Uni of NSW
Visiting Professor in Computer Science Australian National University
More information about the Link
mailing list