Hacker News new | past | comments | ask | show | jobs | submit login

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...

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.




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.


  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...

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.


Well, that explains why the implementation seems brain-dead, it's because they wanted offline transactions. I'm not sure why they thought offline transactions would be a good idea given the near impossibility to do it securely (given enough incentive someone will completely reverse-engineer the chip), but the whole situation seems fairly ridiculous.


If you read the linked paper, this vulnerability is not limited to offline transactions.

Edit: clarification, there are sort of three types of transactions--

  offline - vulnerable to this (and a simpler attack)
  online w/ offline pin - vulnerable
  online w/ online pin - not vulnerable


Well, this article only applies to point of sale transactions, so it is either online or offline.

Offline transaction, meaning "authorized within the acquirer domain (at acceptance device, or at the acquirer host)". In other words, the transaction does not hit the issuer's system.

Edit: Even in an online transaction, offline pin is still performed, but the online would fail.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: