"[1052] Defeating a RFID System With The ESPKey" => https://youtu.be/0SEHUqkbIjU
"[1056] This Black Box Reads RFID Cards in Your Pocket" => https://youtu.be/dTObKtHzroM
"[1052] Defeating a RFID System With The ESPKey" => https://youtu.be/0SEHUqkbIjU
"[1056] This Black Box Reads RFID Cards in Your Pocket" => https://youtu.be/dTObKtHzroM
The lesson in 1052 sort of misses the point. LPL (his videos are a lot of fun by the way and I recommend them to anyone who is curious about lock picking) says:
> So, if you are installing an access control system like this it is really important to use one that only transmits encrypted data
This would defeat the ESPKey demonstrated, but of course that product exists precisely because it's all you need for common systems today. If "encrypted data" was common the ESPKey's successor would probably be a product that sits next to the reader and gets its own copy of the raw RFID signal. Not as convenient, and less fun for doing cool demos, but still plenty effective enough for crooks.
What you actually need to do to defeat this is a bit more expensive. You need the token (keyfob, card, etcetera) to be smart enough to use the tiny surge of power to do local computation, and then produce one-time-only access codes. That would actually fix the problem, because to get the current code a bad guy needs to steal the token and that's an ordinary physical security consideration that humans are used to dealing with. This way an ESPKey gets the one-time code you just used, but neither replaying it nor copying it to a card to try later will do anything useful.
Unfortunately this smarter token would be significantly more expensive. We saw with EMV cards (payment cards) that the smart and secure option (DDA with changing cryptograms) is expensive enough that providers would often rather take a risk and give you an insecure cheaper alternative which looks identical, especially if they believe regulators, courts etc. won't realise they took the cheap option and so the risk actually lands on their customers not on them.
There have been vulnerabilities found in older versions, but as far as I know, later versions are still considered secure.
MIFARE is not a card type, it's more a family of cards in the 13.56MHz space, produced by NXP.
There are multiple cards under the banner of Mifare, including:
- Mifare Classic 1/4k - UID + Storage space, with individual keys and crypto. Suffers/ed from multiple vulnerabilities. Used mainly in cheaper hotel access systems, gym cards, etc etc. Can be secure, if your security layer relies on strong crypto on card contents, as opposed to the crypto of the card itself. There are no counters in Mifare Classic.
- Ultralight / Ultralight-C / Ultralight EV1 These cards are low cost, reduced storage space, and are / were conceived specifically for the transport industry. They have 'one way' counters that can be used to deduct 'credits' - but these can't be re-written - so they fulfill the task of discardable tickets.
- Mifare DESFire 3DES / EV1 / EV2 The EV2 is the latest generation - ID + Storage + "Applications", with AES encryption. The 3DES was cracked with side-channel power analysis (like the items in this article) - but the EV2 has no practical attacks to this day.
Information aside, most transport systems do not store value on the cards, but allow for offline use by forcing sync the next time the card passes by an online system - IE, limited trust.
When you topped up online (I haven't lived in London for a few years, so don't know if it still works like that) you had to select which station your top up would be applied to, then overnight that station would download a list of topups, and apply it to your card when you touched in or out next. So at the time there was no real time connection to a centralised database.
The best solution is to assume that a card's encryption is or will be broken, and build a system around it.
That is to say, store encrypted or signed data on the MIFARE card.
VIGIK is a French system that uses RSA signed data in MIFARE cards which has not been cracked to date.
There are literally hundreds of other protocols and systems that are much better: the DesFire EV2, etc [2] for similar costs (ie 80c vs 70c) [3][4]
Just wanted to point out that the systems that you hypothesize exist already, and are not orders "Significantly" more expensive.
[1] https://en.m.wikipedia.org/wiki/Wiegand_interface
[2] https://en.m.wikipedia.org/wiki/MIFARE#MIFARE_DESFire_EV2
[3] https://www.idcardsdirect.co.uk/nxp-mifare-desfire-ev2-4k-bl...
[4] https://www.amazon.com/100pcs-Proximity-ISOProx-26-Bit-H1030...
Why do you need the keyfob to rely on a "surge of power"? Can't you put a battery in it and charge that battery when driving? If the battery runs down, you needed a backup anyway (physical key or phone app) in every implementation I've seen.
Most popular card/fobs (95%+ of all I've seen) don't use challenge-response, but always transmit the same 26 bytes. I don't have to explain how "secure" is that.