So many ridiculous hacks upon hacks going on here. There is only ONE WAY to implement these payment systems and it was known to the designers of the smart card and related public-key crypto designers 40 years ago: the merchant must sign the transaction with their key, the user must inspect the signed transaction on their own trusted device and enter PIN to sign with their private key, and the whole thing is verified and cleared by the network operators.
The pile of hacks we have today is just a result of the fact that the networks don't want to operate the PKI.
Or more likely because customers don't want to inspect a transaction on their own device at the supermarket checkout or even worse a transport fare gate. A "solution" which takes minutes to perform is not a solution to the real-world problem.
It's a tradeoff between speed and security. Anyway there's certainly no reason why minutes need be the case. A contactless smartcard with an integrated e-ink display and PIN pad would not take anywhere near the amount of time we currently suffer in the US implementation of chip and PIN.
Edit: fare gate is a special class of problem. I don't expect TfL to be screwing with me, whereas I may be highly suspicious of the point-of-sale system down at the corner bodega.
Totally unreasonable to implement. How are these cards supposed to run? They don't have batteries. Even if this was realistic to deploy it would be prohibitively expensive, far exceeding what it's costing banks to eat the fraud.
Why? Forget the e-ink for a moment and just use lcd instead. I once had an lcd calculator (no backlight, of course) that ran for a decade on a lithium battery. smart cards barely use any energy at all.
Things a NFC card implementing the system you describe:
- Radio
- Public key crypto
- ASN.1 DER X.509 parsing to validate the signed transaction from the terminal. The terminal would need to send a cert chain to the card and the card follow the chain to the network root to correctly verify the terminal signature.
- Parsing OCSP responses, which the terminal would have to staple to its cert because the card has no other way of knowing the revocation status of the terminal cert.
- Conform to ISO 7816 for interoperability with legacy equipment.
This is a standard for smartcards. They often include certificate-based authentication. You don't power the radio - the radio powers you, so that's not a big issue. OCSP seems irrelevant - it's pass-by-default, so if you're a bad guy you just pretend you can't reach the OCSP servers.
You can do that for under 20 cents in bulk with a power budget of around 0.01 watts. Modern CPU are kind of mind bending awesome, but you can also get useful processing at the 35µA level.
I bet it's not interactive. Interactivity powered by near field RF is impractical because power is lost when the card is out of range. This would result in some very awkward UX as users have to hold their card close enough to the reader for power while they verify the transaction metadata and enter their PIN.
> the user must inspect the signed transaction on their own trusted device
I don't believe this has been ever implemented, or anyone knows how to do this really. How do you imagine it would work? Every card preloaded with every bank's CA? Cards connecting back to the issuer for updates? Something else?
Basically a) signed with what, and b) what does "inspect" mean?
> The networks would delegate a cert to the merchant which the card can verify because it's loaded with the root/intermediate chain needed to do so.
Revokation of CAs or intermediates would mean that many cards suddenly stop working before the expiry date. Can you imagine the PR fallout if that happens?
> "Inspect" means you get to see the amount you're going to be charged.
You still don't know who you're charged by. It could be another transaction relayed to you. It makes it less practical (synchronised payment / compromised terminal), but not impossible considering how many hoops we have to jump through for this class of attack in general.
> Revokation of CAs or intermediates would mean that many cards suddenly stop working before the expiry date. Can you imagine the PR fallout if that happens?
Revocation shouldn't make cards stop working, as long as certs are still signed with some valid chain. And new CAs can be cross-signed. The only thing that has to get updated is the merchant terminal config.
Stopping things from working is the whole point of revokation. Parallel, offline, "emergency" CAs would work, that's true. But it would still take some time to move everyone over to a new configuration.
To make a card break, you have to revoke the card or revoke [nearly] every CA that card trusts. If you're revoking a card, you did that on purpose; that's not a flaw. And it's exceedingly unlikely that every CA would be revoked. I don't understand the scenario where revocations break the system. We've never had to revoke the majority of web certificates in a single five year period.
That is a bit silly, especially considering its bank money, not bitcoins
Just have an app that allows the user to review transactions after they have happened. If there is a double charge, dispute and win easily, if charged too much, dispute and win easily, etc etc
The fraud resolution on my Visa card[1] required me to:
1. call the merchant that charged the fraudulent charge, and attempt to get them to void it. This was literally as pointless as it sounds.
2. Receive a specific form that could only be sent by snail mail or fax. The sending end absolutely refused to send it over email. Thankfully my building has a fax machine, and my building manager has common sense, and allowed me to borrow it. The fax service we use (because who uses fax?) turns faxes into — you guessed it — emails. Of course, at the bottom of the received fax is "H:\SharedDocs\Stuff\More Stuff\TheForm.pdf".
3. Fill it out, scan it back into a computer, fax the PDF back. (I could have also snail mailed it back.)
4. Receive a confirmation over snail mail, noting that it will be resolved sometime in the next 6 months.
I never lost possession of my card, and the merchant who charged the card was able to confirm that the "card" was presented at the time of purchase (it was made physically, in a store) — while the real card rested in my wallet, thousands of miles away.
I was issued a new card, of course, and the old one voided. The new card is still not chip and pin, despite me explicitly asking for it.
I'd love to take on the "hassle" of public-key crypto.
[1] This was a debit card that works as either a credit card or a debit card (though the latter mode requires a pin, but the former mode requires nothing … because … waves hand); I am told credit cards are supposedly less of a pain.
I've had to deal with a Mastercard fraud department a few times. My card has long been chip and pin, but it still has a magstripe, which gets a skimmed every few years.
The usual way it works is this:
- I discover something is wrong when my card is declined. I pay with my other credit card instead.
- I call the card issuer that evening. Within 5 minutes I'm talking to their fraud department.
- They inform me of suspicious transactions (often preemptively declined) and I confirm I did not authorise them. I'm done within 15 minutes.
- I use my secondary credit card for a week while they mail me a new one.
This is why nobody should use a debit card. With a credit card, I call my issuer, tell them that I don't owe the charge, and after that it's the merchant's problem.
While I agree that this seems to be the optimal strategy with which to play this part of life's game, if you step back a bit, the whole thing is bullshit.
A credit card is effectively the exact same as a debit card (for what uses I would be using it for), it's just more hassle (again) on my part to get it to be backed by cold hard cash, and requires me to agree to an agreement that, should I ever slip up, has some exceedingly nasty clauses.
> 1. call the merchant that charged the fraudulent charge, and attempt to get them to void it. This was literally as pointless as it sounds.
For any merchant who knows what they're doing, this is FAR from pointless. It's much cheaper for them to just go ahead and refund you than to get a chargeback. They should only refuse to refund you if they believe that the charge is legitimate and that they can successfully represent the chargeback.
Interesting. H&M was the merchant here; the representative talking to me sounded as if he'd never heard of anyone ever calling in for fraud resolution, and wondered why I wasn't talking with the card company (because they sent me to you).
I recently had a credit card used on the wrong continent. I called up the card issuer (capital one), said "hey I don't recognize this charge". They issued me a new card (via next day air) and refunded the transaction.
I dunno if it's an issuer thing or a credit card thing.
I do not think the title corresponds particularly well to the article, as it focuses on at least something being done: The article details how the new MasterCard specification for contactless payments requires that payment terminals time the response of contactless cards to 2ms or less. This would as I understand it almost eliminate real-world relay attacks: it would exclude using the Internet to relay data and thus require building sophisticated radio equipment, all for relatively little gain as contactless payments without PIN are usually capped to low sums.
The article does point out, though, that this might well be "too little too late" as the MasterCard specification is only one of many and it will take years For new cards to actually end up in the hands of consumers. I guess this is what the title refers too, but I have to admit that at least I was surprised to learn that something is being done at all about this...
Just add an e-ink display (like this: https://plastc.com/) that shows the transaction value and a button to approve on card. Only then the card would sign the transaction. Seems simple.
It doesn't even have to be a card-shaped anymore, since it's NFC. There are other form factors that handled real-word payments, like bracelets, watches and phones. All of those can be easily equipped with a display (enough to show a transaction amount) and some sort of sensor (keypad, touchscreen, single "approve" button, fingerprint scanner) to handle user authorization.
This will probably break the "fix" though, as the "card" may take up to tens of seconds to "respond", awaiting for owner granting permission. And won't work for stores that can't handle NFC.
It could be configured to automatically allow X transactions below $Y every Z seconds. So you could tag into the subway once every five minutes without any user input, but larger or more frequent transactions would require confirmation.
Contactless cards are vulnerable to some kinds of fraud, fraud in such low amounts that it's not been worth the effort to actually commit on any great scale.
Non-chip cards are by far the bigger liability. The levels of fraud on contactless cards have been so low that the banks put the limit up from £10 to £30 recently here, and take full liability themselves.
I've actually used the "attack" in the article to design a P2P Bitcoin exchange based on the idea of using someone else's contactless card (with permission) in exchange for Bitcoin. This would solve one of the big issues in exchanges today - that is the fiat escrow handling.
There's a demo for a quick PoC here https://www.youtube.com/watch?v=ZsOzeELdjxM . It makes me sad that they're closing this, the fraud potential was really small (as the article implies).
I'm curious about the example used. They show a fraudulent purchase of $2000. I know my MC caps the size of the purchase that can use tap for auth (somewhere under $100). Is the same challenge/response used for both tap and chip? Otherwise, wouldn't the bank catch that it got a tap response for a purchase that should've used chip and pin?
Or is this assuming the bank allows a $2000 purchase using only tap?
The article is a bit confusing (perhaps deliberately to scare the reader).
The attack is possible on all current electronic chip payment forms (contacted/contactless, with & without PIN).
For contactless without PIN, transactions are limited (in my country to €25 per transaction and €50 total before a PIN is required). Contactless without PIN is much easier to attack (for obvious reasons), but cannot break this limit. Contacted with PIN is fully vulnerable, but also a lot harder to pull off.
The 600km limit is also highly deceptive, as it doesn't take into account latency introduced by electronics. E.g. a typical good wifi connection has a much higher ping than 2ms.
would it be too hard to do: send request to bank, bank checks, says it's ok and returns the amount to withdraw, the card reader already says "is amount $20.00 ok", just replace that with what the bank said it was authorizing, user wouldn't have to do anything else, but the real amount would be shown at the time of transaction not what the card reader was told
EM shielded financial pockets are going to become a deal breaker. While there are a few wallets and purses today which offer this (harder on a purse since it makes your phone unusable if stored in it) at some point if your card holder doesn't shield it will be considered impractical.
Alternatively, simply the popularity of the NFC cards will sort it out. I've got 2 NFC credit cards and 2 NFC public transport cards. They're not compatible with the time-delay enumeration, so you can't scan them separately while they're in the wallet.
The pile of hacks we have today is just a result of the fact that the networks don't want to operate the PKI.