Profile

unixronin: Galen the technomage, from Babylon 5: Crusade (Default)
Unixronin

December 2012

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
3031     

Most Popular Tags

Expand Cut Tags

No cut tags

February 11th, 2010

unixronin: Galen the technomage, from Babylon 5: Crusade (Default)
Thursday, February 11th, 2010 10:43 am

Yes, I said "industry".  And this interview from Scam Detectives makes it clear that it is an organized, structured industry in Nigeria.  (By way of Bruce Schneier)

Read directly at Scam detectives here, here, and here (three parts).

A choice excerpt:

Scam-Detective:  John, I think you have been basically honest with me so far.  Please don’t stop that now.  You know as well as I do that not all of your victims were motivated by greed.  I have seen plenty of scam emails that talk about dying widows who want to give their money to charity, or young people who are in refugee camps and need help to get out.  You targetted vulnerable, charitable people as well as greedy businessmen, didn’t you?  You didn’t care whether they could afford it or not, did you?

John: Ok, you are right.  I am not proud of it but I had to feed my family.

Scam-Detective: And fund your BMW, mobile phones and laptops, let’s not forget about that.  When the victim had run out of money and couldn’t send any more, was that the end of it?  Or did you go back later for more?

John: We had something called the recovery approach.  A few months after the original scam, we would approach the victim again, this time pretending to be from the FBI, or the Nigerian Authorities.  The email would tell the victim that we had caught a scammer and had found all of the details of the original scam, and that the money could be recovered.  Of course there would be fees involved as well.  Victims would often pay up again to try and get their money back.

Scam-Detective: So when the victim had had some time to get over the fact that you had wormed your way into their lives, gained their trust and ripped them off, you went back for another bite of the cherry?  The more I speak to you John, the less I like you.

John: I know, I know.  Don’t be angry with me.  I’m not proud of what I have done and I am very sorry for everyone who sent money.  If I could give it back I would.

Scam-Detectives: But only if they sent you $1000 by Wire Transfer first?

unixronin: Lion facepalm (Facepalm)
Thursday, February 11th, 2010 06:00 pm

Researchers at Cambridge University have found a fundamental (and, by the sound of it, elementary) flaw in the chip-and-PIN protocol used to authenticate European bank cards, which allows a chip-and-PIN terminal to be tricked into authenticating a transaction with any chip-and-PIN card, regardless of whether the correct PIN is entered.  The required device is simple to construct and use.  Details of the attack here.

The crucial detail here is this one:

The majority of transactions require PIN verification.  The customer enters their number on a PIN entry device.  The PIN is then sent to the card, which compares it to a PIN that it stores on its chip.  If the PIN is correct, the card sends a verification code — 0x9000 — back to the terminal, which completes the transaction.

The problem here — and this really is a complete beginner's design error — is that the verification code sent back by the card is both fixed and sent in clear, and contains no mechanism whatsoever either to protect the conversation or to encode the data that it is verifying (or rejecting) in the reply.  So all an attacker need do is intercept the card's "reply" and replace it with the constant 0x9000 "Verified" response.

This has been a solved problem for over thirty years.  To be failing at it in a supposedly-secure financial transaction protocol introduced only four years ago lies somewhere between appalling and inexcusable.


Afterthought over supper:  The last paragraph above is probably over-simplified.  I should clarify that the problem of non-spoofable authentication remains to be fully solved.  However, techniques for exchanging data securely over an insecure channel have been known for more than thirty years.  Just as a first cut, a much better way of handling the PIN and verification exchange might be as follows: The terminal and the card use Diffie-Hellman key exchange or some other mechanism to establish a one-time shared secret.  The terminal encrypts the PIN with the shared secret, saves that value temporarily, then sends the PIN in clear¹ to the card.  The card then validates that PIN in a secure manner; if it matches, it too encrypts the PIN with the shared secret, and sends the ciphertext back.  If it does NOT match, the card encrypts a random false PIN and sends that instead.  The terminal compares that ciphertext to the one it generated; if they match, the transaction is authenticated.  Without knowing the shared secret, a man-in-the-middle attacker cannot spoof the correct response, because the attacker cannot know in advance what it will be.

This is of course an oversimplification, for two reasons:

  • It handwaves the problem of securely authenticating the PIN;
  • If a MITM attack is a possibility, then the terminal needs to be able to confirm that it is in fact talking to the card and not to the MITM, or the MITM could hypothetically simply spoof the entire handshake.

[1]  "In clear?  Isn't that insecure?"  Well, yes, in principle, but for the purposes of defeating this attack it wouldn't matter; not only does the attacker already know what PIN he just entered, but in this attack it's a false PIN anyway, so no actual sensitive information is exposed.  However, if the terminal sends the ciphertext of the PIN to the card, then the hypothetical possibility of a known-plaintext attack exists.  So in this — admittedly hypothetical and incomplete — example case, it is actually more secure to send the PIN candidate to the card in clear.


Afterthought two:  W00t!  I beat Bruce Schneier to this one!