↑ ↓
 

Podcast for 19 February 2017

Started by MrBogosity, February 19, 2017, 05:59:59 PM

Previous topic - Next topic
Print
Go Down Pages1
User actions
February 19, 2017, 05:59:59 PM
[mp3]http://media.blubrry.com/bogosity/p/podcast.bogosity.tv/mp3s/BogosityPodcast-2017-02-19.mp3[/mp3]


Co-Host: Chris Hangartner

News of the Bogus:
19:12 - Biggest Bogon Emitter: CBS11 (Dallas/Ft. Worth) http://dfw.cbslocal.com/2017/02/03/study-id-fraud-up-since-security-chips-put-into-play/

25:18 - Idiot Extraordinaire: Robert Reich http://www.dailycal.org/2017/02/09/robert-reich-publishes-controversial-theory-regarding-yiannopoulos-demonstration/
This Week's Quote: "Beware of Identity politics. I'll rephrase that: have nothing to do with identity politics." —Christopher Hitchens
February 20, 2017, 02:19:27 PM #1
Unless you're talking about a completely different vulnerability (which is quite likely to exist, given that the spec document for Chip-and-PIN runs to many thousands of pages) the problem is it turns out to be entirely possible to fool a bank into thinking the chip verified the PIN and to fool the chip into thinking it doesn't need to verify the PIN if certain errors are made in the implementation of the Chip-and-PIN system, the errors involving a failure to verify the end-to-end complete encryption path for every communication to ensure that the bank verifies it actually talked  to the chip and the chip verifies it actually talked to the bank, even when they don't have any actual data to exchange.

I've noticed a mistake in the design of the system here in Canada as well.  A good many PIN Pads seem to leak the information that the correct PIN has been entered separately from the entire transaction completing.  This implies that you could use a working PIN pad with a doctored connection that made the pad think it could communicate with the bank (but in reality nothing actually goes to one) to simply brute-force the PIN.  My bank, which is one of the Big Banks here in Canada, only uses 4-number PINs, which are quite feasible to brute-force as long as it doesn't actually send any information to the bank.  The only longer ones I've seen are only 5 digits, which is still not an impossible task to brute-force, and would be trivial if you could find a way to feed the inputs electronically to the pad (which is tricky as the encryption keys, at minimum, will be stored in tamper-resistant memory, blocking any easy opening of the case, but since the keypad itself must be exposed, you could probably go in through the keypad signal traces to do it).
February 20, 2017, 06:30:09 PM #2
If you're talking about the scotch tape one, it's this: https://www.wired.com/2015/10/x-ray-scans-expose-an-ingenious-chip-and-pin-card-hack/

QuoteThe French fraudsters took advantage of a long-known but theoretical vulnerability in chip-and-PIN systems to execute what the researchers describe as a "man-in-the-middle" attack that takes advantage of how cards and card readers communicate. When a buyer inserts his or her card and enters a PIN, the card reader queries the card's chip as to whether the PIN is correct. 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," says ENS researcher Rémi Géraud. "That's the core of the attack."
February 21, 2017, 09:06:31 AM #3
Quote from: MrBogosity on February 20, 2017, 06:30:09 PM
If you're talking about the scotch tape one, it's this: https://www.wired.com/2015/10/x-ray-scans-expose-an-ingenious-chip-and-pin-card-hack/

That's the one I was thinking of, and it was NOT theoretical in 2015, as it was demonstrated to work in 2010, as the article mentions.  So much for the banks supposedly fixing this defect.  All they need to do is do all communications properly encrypted from the bank's server all the way to the chip and back, and you wouldn't be able to just insert a fake chip in the path and trick the system in this way.
February 21, 2017, 01:38:36 PM #4
Quote from: evensgrey on February 21, 2017, 09:06:31 AM
That's the one I was thinking of, and it was NOT theoretical in 2015, as it was demonstrated to work in 2010, as the article mentions.  So much for the banks supposedly fixing this defect.  All they need to do is do all communications properly encrypted from the bank's server all the way to the chip and back, and you wouldn't be able to just insert a fake chip in the path and trick the system in this way.

And like I said, if you baked the PIN into the crypto you wouldn't even have to worry about keeping it secret, since it never actually gets transmitted (nor would it need to be).
February 21, 2017, 04:58:25 PM #5
Well, the PIN isn't transmitted over the network (at least, not in the system as implemented in North America), the PINPad communicates with the chip in the card and the chip validates the PIN.  The problem is that not all banks enforce a direct, cryptographically secured and validated communication between the bank and the chip to verify the PIN confirmation.  Apparently, this is what the standard is supposed to require, but it's a detail that has been demonstrated to have been overlooked in at least some implementations.  The PINs are too short (only 17 bits) to be anything but payload in any sane encryption system.  In fact, they're really to short to make a good payload as well.

This whole thing might not have happened if they didn't decide they wanted the convenience of the card tap payment for smaller purchases.  Without that, there wouldn't be a reason to allow for not verifying the PIN cryptographically from all hard terminals on all transactions.
February 21, 2017, 05:16:54 PM #6 Last Edit: February 21, 2017, 05:19:59 PM by MrBogosity
No, the PIN can be a part of hardened crypto if you do it right.

Just spitballing, but something like this:

Code Select
acct = <account number>
PIN = <PIN>
key = <random 256-bit number local to the card, that never leaves it>

PrivKey = Ed25519(HMAC(key <key>, acct||pin <message>))
PubKey = PrivKey.MakePublicKey()


The bank or payment processor would have the public key, which is all it would need (and it would be regenerated whenever the PIN is changed). So, when the card is used, you use the same technique to make the same PrivKey in the card, and then:

Code Select
Sig = PrivKey.MakeSignature(TransactionID <message>)

The signature would then be sent to the bank, which would verify (or reject) it with the public key.

All keys would have the full 256 bits of entropy thanks to the random number on the card, which is absolutely necessary for the crypto. The PIN isn't stored anywhere; the user types in the correct PIN, which results in the crypto working, or an incorrect PIN, in which case the crypto fails.

You wouldn't even need to encrypt the data (or at least, this part of it) since nothing is transmitted which needs to remain secret, or can be substituted by a MITM in any way that will result in anything except a failed transaction.
User actions
Print
Go Up Pages1