I think it comes down to unreliable communications... In the case that your POS terminal isn't able to connect upstream, do you completely decline the transaction? Businesses used to accept checks from most people without issue.. these transactions took several days.. yes there was some fraud, but it was minimal.
In this case it may be part of the protocol to not confirm if there is a communication problem, and that risk may be acceptable. It seems to me a test of is "0000" valid and is "9999" valid and at least one of the two rejected before the user is allowed to enter their pin would be reasonable here.
There's a lot to be said for user in/convenience in decision making.
Well... in principle the device is supposed to be able to provide an authenticated public key that gets signed by some upstream bank/authority, right? It's the same principle as TLS -- you can trust the site because they have a signed cert.
And this part apparently was unbroken, because the attackers left the initial chip in place and just proxied the PIN response.
So... if you have that, why on earth didn't the protocol specify a two-way kind of thing that allows the already-authenticated card device to sign and return a "I validated that PIN" message, which wouldn't be MitMable?
I'm just stunned that somehow they went through the trouble of putting a !@#!?! computer into every credit card capable of elaborate crypto and then blew this really obvious hole in the middle of it...
Offline authentication was included for reasons you state but banks and terminals are supposed to limit it to small transactions, i.e buying a cup of coffee. For larger ones you wait and retry for online transaction before you let the customer walk out with that shiny new 2K MBP.
Comments
I think it comes down to unreliable communications... In the case that your POS terminal isn't able to connect upstream, do you completely decline the transaction? Businesses used to accept checks from most people without issue.. these transactions took several days.. yes there was some fraud, but it was minimal.
In this case it may be part of the protocol to not confirm if there is a communication problem, and that risk may be acceptable. It seems to me a test of is "0000" valid and is "9999" valid and at least one of the two rejected before the user is allowed to enter their pin would be reasonable here.
There's a lot to be said for user in/convenience in decision making.
Well... in principle the device is supposed to be able to provide an authenticated public key that gets signed by some upstream bank/authority, right? It's the same principle as TLS -- you can trust the site because they have a signed cert.
And this part apparently was unbroken, because the attackers left the initial chip in place and just proxied the PIN response.
So... if you have that, why on earth didn't the protocol specify a two-way kind of thing that allows the already-authenticated card device to sign and return a "I validated that PIN" message, which wouldn't be MitMable?
I'm just stunned that somehow they went through the trouble of putting a !@#!?! computer into every credit card capable of elaborate crypto and then blew this really obvious hole in the middle of it...
Offline authentication was included for reasons you state but banks and terminals are supposed to limit it to small transactions, i.e buying a cup of coffee. For larger ones you wait and retry for online transaction before you let the customer walk out with that shiny new 2K MBP.
I'm not disagreeing.. was only stating a reason why they might bypass the check.