
X-Ray Scans Expose Chip-And-Pin Card Hack - miralabs
http://www.wired.com/2015/10/x-ray-scans-expose-an-ingenious-chip-and-pin-card-hack/
======
ajross
FTA: _A fraudulent chip can listen for that query and pre-empt the real chip
with its own answer: a “yes” signal regardless of whatever random PIN the
fraudster has entered. “The attacker intercepts the PIN query and replies that
it’s correct, whatever the code is,”_

Wait, what? How is that the protocol? There's no two way validation at all?
The chip just says "yes"?!

Can anyone with knowledge of details confirm? This seems isomorphic to my ears
with "the PIN is just security theater".

~~~
bravo22
In this case the fault lies with the bank. The chip can authenticate the
transaction and also optionally cryptographically sign it as verified. The
bank should check the last step but most/some don't because a lot of the first
wave of terminals that went out didn't have full/proper implementation,
therefore they only relied on the chip saying "yeah it looks good", instead of
"yeah it looks good, btw here is my signature on this transaction which you
can pass to the bank to verify that it really is kosher".

So it is more an issue of the bank accepting partially verified transactions
on large dollar amounts.

~~~
ChuckMcM
Really? Its like the banks saying "really all this fraud stuff isn't really
our problem."

~~~
rdtsc
In a way it is isn't though ;-) They are insured against it, they will refund
the money back and their risk analysis probably indicates that loosing all
that money to fraud is cheaper than waiting and properly deploying and testing
the solution.

I imagine just like in the government security world, a lot of bank security
is "paper" security (the way I call it). It is a set of formalities,
certifications, rubber stamps, audits, other other red tape that in the end
all check off and yet the system is still not secure.

~~~
leejo
> They are insured against it, they will refund the money back and their risk
> analysis probably indicates that loosing all that money to fraud is cheaper
> than waiting and properly deploying and testing the solution.

This. Some behaviour i encountered by acquiring banks when working on backend
software for interfacing with them:

\- Authorising a transaction when they failed to contact the issuing bank,
because the value of the transaction is lower than a certain threshold.

\- Overloading fields in the APACS spec to get around 3D Secure / Verified By
Visa, i.e. passing the cardholder straight through the process and then
marking it as bypassed (a poorly implemented one factor auth becomes a "eh,
this looks ok to me" zero factor auth by the issuing bank).

\- Being sat in meetings where the max value of contactless transactions was
explicitly stated as being that of a level that any contactless chargebacks
were not defended because they're so low.

\- Asking me to send PANs in clear text, split over two e-mails (no, i
didn't).

Backend backing systems are horrible. Nobody really wants to work on them and
they have so much legacy cruft that they're like concrete, so any change takes
forever and carries massive amounts of dev/test/risk.

Even the seemingly sensible ones have major WTF's - One of the integrations i
did at my previous job was interfacing to Amex's endpoint for online
authorisations. HTTPS posts over the web, seems sensible enough right compared
to APACS-70 over X.25? No, the ISO-8859-1 POST parameter _values_ needed to be
encoded as EBCDIC and then converted to hex (IIRC) before being sent.

Banks playing the chargeback cost balancing game is all well and good for
_them_ , but if you're living on the edge and experience fraud then this can
lead to all sorts of financial problems.

~~~
kbenson
>
> [http://www.npr.org/sections/money/2014/09/08/345820789/why-d...](http://www.npr.org/sections/money/2014/09/08/345820789/why-
> do-we-sign-for-things-a-rabbi-a-lawyer-and-a-mastercard-exec-explain)

Having had to re-implement a few legacy systems in newer code for nothing
nearly as complex or with as much risk as what you're referring to, I can't
imagine any dev not screaming and running for the hills if asked to do this.
The chance it will work correctly without bugs early on is close to nil, and
the downside for bugs when dealing with financial systems makes the risk
analysis being as large as it is, it's pretty clear cut.

I keep telling myself one of these days I'll get to reimplement some system
that has good test cases, but I know that will never happen. Any system that
is designed well enough to have good tests doesn't really require rewrites in
the vast majority of cases.

------
JimmaDaRustla
This is technically old news - as the article states, it has since been
resolved. Edit: I guess they're shedding new light on how they performed the
hack.

Another thing, in context of USA, is that the authentication being done isn't
much of a vulnerability as this only applies to offline chip transactions. In
the USA (I believe) and here in Canada, all transactions are online, which
means the pin will be rejected by your financial institute's back end systems
in these scenarios.

These types of hacks have since been corrected using what is called CDA
(Combined Data Authentication). Blurb on SDA/DDA/CDA here:
[http://www.cryptomathic.com/hubfs/docs/cryptomathic_white_pa...](http://www.cryptomathic.com/hubfs/docs/cryptomathic_white_paper-
emv_key_management.pdf)

Edit: Many Canadian financial institutes still use the weakest data
authentication (SDA) because all transactions go online - spoofing a card PIN
verification response doesn't fool the back-end system. Visa and Mastercard
both have mandates to have newly issued cards be provisioned on chips with CDA
(I believe, could be DDA which would still be susceptible to this attack).

Edit 2: When I say "offline", I mean at a point of sale machine - the POS does
not reach out to the payment network to perform an "online" transaction where
the PIN and card are validated by the back-end systems.

Edit 3: The article doesn't give EMVCo any credit for actually solving the
issue before any real world hack was known to exist.

~~~
makomk
I'm not sure I'd describe it as "resolved". They've deployed a couple of
countermeasures that take advantage of bugs in this particular implementation
of the exploit (it doesn't detect parity errors in the card-to-reader
transmissions and replies yes to the PIN authentication command even if it's
sent at the wrong time). Those bugs can easily be fixed, and the first trick
is probably very familiar to most folks acquainted with Funcards.

~~~
JimmaDaRustla

      couple of countermeasures
    

In CDA, the responses are encrypted by the card, which means a they can no
longer be spoofed.

The only lingering possibility of this type of attack occurring is in regions
where offline transactions are still permitted, and if you can find a terminal
which still does not have CDA capabilities or if you have a card which doesn't
have CDA. Totally possible, but the opportunities are diminishing rapidly as
the issued has been RESOLVED.

Edit: Found a decent write up on the CDA differences over DDA:
[http://www.infonomics-
society.org/IJICR/Fraud%20Reduction%20...](http://www.infonomics-
society.org/IJICR/Fraud%20Reduction%20on%20EMV%20Payment%20Cards%20by%20the%20Implementation%20of%20Stringent%20Security%20Features.pdf)

The CDA cards have this advantage over the DDA cards, in that _the message
signed by the ICC which includes an additional Application Cryptogram (AC),
which is used to protect and validate the specific transaction messages
(amount, time, etc) generated during the transaction_. The ICC uses the AC
Session Keys (derived from the ICC AC Master Key, shared only between the ICC
and the card issuer) to place this MAC on the transaction details.

------
kbenson
That's amazing. They were able to MITM the chip-and-pin chip by taking it out
and attaching it to another hobbyist chip that's capable of spoofing the
response, and the whole thing when put back in the card was only a slight
bulge bigger than the original.

They say nearly 600k Euros were charged, but given the sophistication of the
attack, I wouldn't be surprised if we hear later that it was in use at
different locations as well, and we just aren't hearing about it because they
haven't caught those people yet. They only caught these ones because they kept
going back to the same locations.

~~~
jessaustin
Don't keep purchasing at the same merchants; that's like Carder 101!

Regardless, this whole "ask the card if the PIN was right" protocol is just
dumb. Surely they could have e.g. had the card sign a challenge in a way it
could only do if given the right PIN? That gets slightly more complicated when
revoking old PINs or issuing new ones, but it would still be _possible_. For
all we heard about the wonders of C'n'P, this seems to fall short. If you're
going to the expense of chipping all those cards and replacing all those
terminals, at least get the software right.

~~~
joosters
But the chip is the only part of the communication that knows the PIN. (the
protocol does not need a network connection to the bank).

The chips could be made to sign their response with a bank's private key and
the terminal checks this against a known list of banks. But that would be
cumbersome (lots of banks, lots of keys), the terminals would need to be
constantly updated to keep the key list up to date, and it all falls apart
when a key is extracted out of the chip.

Now if the protocol required a network connection to the bank, you could speak
to the bank to validate a PIN instead of talking to the chip at all.

~~~
bravo22
They signed transaction would indeed fix this issue but it was ignored by the
bank (to their detriment) for other reasons. The implementation is actually
pretty decent.

It doesn't require key management the way you describe it.

Banks use a derived key schemes for EMV transactions. In a way you can think
of it as PKI. In any event, the actual verification doesn't happen on the
terminal. The terminal is supposed to take the signed transaction and pass it
up through the network where it will end up with the originating bank who will
say "Yes, we accept it", or "No, we don't accept this charge". This is
something that happens today but it is the CC# and the CVV that get passed. If
they are revealed/stolen you're screwed.

~~~
dfox
While EMV is quite reasonable protocol, it is needlessly complex. And this
complexity is at the root of what this attack exploits.

------
Sleaker
I'm dealing with development on some of this right now for US based POS
customers and so far everything I've been told is that the US isn't even going
to attempt to utilize the PIN entry capabilities, so we're still using
signature validation in case of fraud. I'm not sure how this is any better
than MSRs. The whole spoofing PIN validation thing doesn't even come into play
because it's not even going to be checked.

~~~
ghshephard
"signature validation "

I've left the back of my credit-card unsigned for 2+ years, and in that entire
time, and north of 500+ transactions with a signature, I've been asked for
identification less than 10 times.

I wonder if there has been a single person challenged on a signature in the
last 5+ years with a credit card if they even made the _slightest_ attempt to
sign in a fashion similar to what's on the back of the card?

~~~
hga
Tip from my father, who switched from cash to almost all credit cards at POS:
write "Photo ID Req." in permanent marker in the signature area. And, hey, one
time when he sent me in to BBQ joint for some takeout with his card the
cashier _did_ look, but I was able to show my ID and make a plausible case for
being his eldest son ^_^.

~~~
MichaelGG
Problem is the card is not valid unless signed. An attentive merchant will
insist on the card being signed. This has only happened to me a couple of
times but still.

~~~
heywire
One of my American Express cards doesn't even have a place to sign anymore
(Amex Blue Cash Everyday)

------
893helios
What's this (Chip and Pin) being crap already disclosed here?
[https://media.blackhat.com/bh-
us-11/Laurie/BH_US_11_Laurie_C...](https://media.blackhat.com/bh-
us-11/Laurie/BH_US_11_Laurie_Chip_Pin-Slides.pdf)

------
klagermkii
Watched this a couple of days ago and found it quite interesting talking about
C&P flaws
[https://www.youtube.com/watch?v=Ks0SOn8hjG8](https://www.youtube.com/watch?v=Ks0SOn8hjG8)

~~~
bardworx
Great video. I just posted it in a reply to another comment.

My biggest takeaway is that all systems are safe until the bad guys really try
to break them.

------
akavel
Noteworthy: _For the Cambridge researchers, the French attack is an “I-told-
you-so” moment. Five years ago, EMVCo and the UK Cards Association both
dismissed their attack as improbable or impossible._

------
bmsleight_
Found some details of the cards

[http://www.infinityusb.com/default.asp?show=store&ProductGrp...](http://www.infinityusb.com/default.asp?show=store&ProductGrp=8)

~~~
rasz_pl
no, afaik this article talks about super thin shim glued on top of real chip
on real card

but I guess you could use cards you linked IF you drill them, cut real chip
from real card, place it in drilled hole, cover hole so its not visible, print
card over with authentic looking color scheme/logo, stamp number, sounds like
a lot of work

------
nathanb
Let's not lose sight of one thing -- this doesn't make chip-and-pin _less_
secure than swipe-and-sign, it just makes it _no more_ secure, in the worst
case.

~~~
kbenson
It's not just about security though, it's also about liability. Chip-and-pin
may have different liability rules than have been established for signatures.
If so, then a hacked chip-and-pin system may be no less secure for the
consumer, but it may be much more costly.

------
derekp7
I was under the impression that the card created a cryptographic signature on
the transaction, and the card had to receive the correct pin before it would
sign it. Which is why you have to leave the card in the reader until the total
is completed. Is this really not the case? Or does the card still
cryptographically sign the transaction, but doesn't process the PIN first
(other than answering valid/invalid)?

------
coleca
> "They also note that other protections have been added to the system at the
> network level, which they decline to detail for fear of tipping off
> criminals."

Security by obscurity. That's always a good plan. I'm sure that folks who went
through all this trouble to design this hack wouldn't ever be able to find
that information. </sarcasm>

------
jgalt212
pretty lame if the card can just say "yes" no matter what PIN is entered.

Away from being a proprietary tech, I'm not sure why fingerprinting the
magnetic stripe never took off. It seems so much simpler, and if you cannot
rearrange iron at the molecular level impossible to replicate.

[http://www.magtek.com/V2/media/whitePapers/2012/MagTek-WP-
An...](http://www.magtek.com/V2/media/whitePapers/2012/MagTek-WP-An-
Introduction-to-Dynamic-Authentication-To-Launch.pdf)

~~~
rsfern
Probably it's lack of infrastructure buy-in. And personally, I find the misuse
of the word biometric in the white paper off-putting, along with the lack of
detail on the basis for the technique. The fingerprint is somehow related to
the magnetic particle distribution--how stable is it against weak magnetic
fields, or against heat?

If you really can reliably get magnetic signatures, it would be really hard to
clone cards.

Edit: the particles won't really change, but their magnetic states feasibly
could

------
ck2
So those millions spent replacing everyone's card and all the vendors merchant
machines was a waste.

Besides you can just use the chipped card online without the chip or pin?

------
ljk
So is the safest way just to use cash?

