MIFARE Classic: exposing the static encrypted nonce variant [pdf]
eprint.iacr.org
eprint.iacr.org
They're stopping it for completely unrelated reasons (primarily convenience – people don't like having to buy and top up a card – and not having to maintain a vending machine and top-up infrastructure).
Oh, to be young again.
It's reminiscent of the old NASA saying: "faster, better, cheaper: pick any two".
Nice idea in theory, except that now you have a system that immediately and catastrophically breaks if there is ever a backend outage (due to, say, a cyberattack or incompetent software trying to prevent one) or your reader loses network connectivity.
> you should never do a system with stored value on a smart card
...if you can afford to ignore the disadvantages of not doing it. Quite often, you think you can, until you can't.
Tapping the vending machine with your card sends the ID in plaintext over the wire to the upstream server, which responds in plaintext for the machine to either accept or reject the transaction.
Tomfoolery may or may not have been performed by a bunch of bored, hungry college students at 1AM one night...
Clones/double use/double spend must be caught on reader/server anyway. One can pass a card to another person, and you do not want two people to enter building with the same card.
I implemented double spend protection by introducing a simple operation counter. If the sequence of operation IDs is not continuous, card is blocked. Clones were added to block list within minutes. It was good enough for the use case. Again, MiFARE is very cheap, so tradeoffs are expected.
There are also many other authentication-capable cards other than EMV (which is optimized for payments, not really general-purpose authentication) such as various building access cards, national ID cards, ICAO biometric passports etc.
> I implemented double spend protection by introducing a simple operation counter. If the sequence of operation IDs is not continuous, card is blocked. Clones were added to block list within minutes. It was good enough for the use case.
Using that scheme, you could just as well use regular old barcodes, no? Makes for much cheaper readers and even wider compatibility.
> Again, MiFARE is very cheap, so tradeoffs are expected.
There are equally-cheap but secure options that actually prevent cloning or even implement the "electronic purse" use case in a fully offline way.
Usually, MIFARE Classic is only used because there's a huge installed base of readers and/or cards (and/or attached backend software).
backdoor implies somebody can "get in" to my rfid, but rfid's spend most of their time "off the grid". So when my rfid powers up, does the "host" who powered it up also need to be insecure or on an insecure/compromised net?
then... what capabilities would suddenly become possible; unlocking the door is already unlocked, my credit card is already all ready to spend...
or does it simply allow people passing me on the sidewalk to make a copy of my card?
That’s the threat vector.
E.g. if "John" badges in... and then 10 minutes later "John" badges in again...
Will most systems complain?
As the saying goes, the wall is only as good as how frequently the guards patrol it.
Rather than building a SOC to look at logs and flag unbalanced entries or similar (which would be very expensive), companies tend to rely on their employees’ vigilance.
Of course. If you work in a SCIF, you're going to have a very different set of rules and experiences than if you work at LiftMaster, if you know what I mean.
> I use a few different RMM solutions that could almost certainly handle the log collection, analysis, and real-time monitoring with alerts and I don’t think it’d take much time/effort to set up.
Right! But someone's gotta watch it. All day, and all the time. If it's sending alerts, who is it sending them to? The same security guard can't be responsible for both watching security monitors and watching or responding to access log issues.
The expense is in the people and maintenance, not in the initial buildout, as is true for many large enterprise initiatives.
My greatest realpolitik lesson at uni was being assigned parking in an "odd" building's gated parking lot. It was close to my dorm, but required carrying your permit to them, so they could enter you into their system for access.
Cue realization they weren't connected to the main university parking registry.
Cue my not buying a parking pass (a substantial cost, as this was an urban campus) for the next few semesters... as my prior auth continued to work on the gate.
And why would parking police think to check for unregistered parkers in a gated lot?
(As far as I can remember, I still had access ~2 years after graduation, then they finally cleaned up their DB)
AKA they ignore the problem but check it off on the security audit.
You can set up your access controllers for anti-passback, but, most folks don't, because companies don't want to pay the costs associated for an 'in' reader and and 'out' reader and implement that level of security.
Yes, some places do. But those places are rare.
Recently I worked for a bank where they had different types of entry airlocks, it was a bit a pain, especially the multiperson ones.
Depending on the specifics of a deployment, I'm guessing you could also use the card secrets to mint new cards that authenticate correctly to facility readers, but contain different information? But I don't know nearly enough about how these cards get used to know how much flexibility you get there.
A lot of systems still just use the UID.
Physical security/door access control is still completely disconnected from IT security, despite these systems relying on software for the last 20 years. As such, there is generally no knowledge in the buyers of such systems as to the risks and how to test for any vulnerabilities.
I bet systems which rely on the UID only (something even the card manufacturer specifically warns against in their datasheet) are still being sold, and lots are definitely still out there. This is trivial to clone and requires only a single read of the card, no cracking needed because the UID isn’t designed to be private to begin with.
MIFARE (not just the Classic family) have a UID (32 bits) and x blocks of encrypted data (12 for Classic). Each block is protected by a A key and a B key.
The earliest card system only uses UID for authentication ie. if the card says the right UID the card passes authentication.
Obviously, anyone can forge a card with said UID, so the latter system start to use the 12 encrypted fields for authentication. The card reader would challenge the card to encrypt the nonce plus stored identification. Only cards with the correct key can respond with the correct encrypted data + nonce.
The authentication uses symmetric encryption. Depending on how the system is setup, A key is used for Read only, Read Write, or A is used for read and B is used for write, or both A/B is need for read write.
The original Mifare Classic uses a proprietary crypto crypto-1. Due to various reasons (eg. weak PRNG, collisions, etc.) , it can be trivial to crack a traditional Mifare Classic key. However there are harden keys that still could not be cracked due to various countermeasures.
The paper seems to found a hardcoded A/B key A396EFA4E24F for a particular brand of RFID cards (I just skimped the paper and its been years since I worked on RFID. I might be wrong on the detail).
Actually, if I understood the paper well, the same key worked also on older, non-Chinese cards like those produced by NXP. Why, that's a big question.
Sadly, neither my gym or work access card were cloneable even though they are MIFARE Classic. So I did not end up getting an implant.
They're often using symmetric cryptography (even ECC is orders of magnitude more complex than a simple block cipher), and you get mutual authentication "for free" that way, in exchange for having to guard the keys on both the card and the reader to prevent a total compromise.
I still see classic being installed for door/gate systems in American apartments that are under active construction in 2024. Presumably that’s because resellers either don’t know better or they just have a massive inventory.
> But, quite surprisingly, some other cards, aside from the Fudan ones, accept the same backdoor authentication commands using the same key as for the FM11RF08!
> ...
> - Infineon SLE66R35 possibly produced at least during a period 1996-20136 ;
> - NXP MF1ICS5003 produced at least between 1998 and 2000 ;
> - NXP MF1ICS5004 produced at least in 2001.
> ...
> Additionally, what are we to make of the fact that old NXP and Infineon cards share the very same backdoor key?
We have customers who use smartcards and we often need to read or write to them, during on-boarding they often have no clue what version or spec they are using and it often results in trial-and-error after they send us a few cards with little-to-no markings on them.
Yes, it also means doing basic things like saying "security is important", "vulnerabilities are bad", and "supply chain risk should be addressed", etc. The more informed you are, the more of a pain this is, at least in my experience (disclaimer: I'm not a CISO).
2) Present a huge dollar number to make it sound important;
3) Get promoted as everyone high-up implicitly understands that reputational damage is a fiction that never materializes in practice.
CISOs get promoted by being willing to focus on compliance over security, so that they can cover the company if and when it inevitably gets breached by saying they “followed best practices” (if that’s true).
All of this is because resolving a breach and giving everyone a year of identity theft protection is a lot less expensive, short-term, than actually investing in a real security practice, and companies in the US think in quarters, not years.
Europe is better about this because they tend to think many years ahead rather than focusing on short-term results.
Not that I'd recommend it, but in most companies, physical security doesn't have a limitless budget just like everything else.
MIFARE Classic: exposing the static encrypted nonce variant
Cryptology ePrint Archive, Paper 2024/1275
author: Philippe Teuwen
Or maybe there’s door access control systems out there that use FIDO2 :D
PKCS based cards get all the benefits of smart cards (hard in theory to extract keys, side channel resistance, etc), with the usual risks (trust in vendors and issuers to not add backdoor APDUs to applets etc.)
Doubt anyone would want to use FIDO2 for a door access control system, but in theory there's nothing really to stop you, if you come up with a clever URI schema for your doors and know what public key to expect for each identity on each URI. That's where FIDO2 wouldn't be ideal, as you'd get a different identity on each URI, so it would only really work with a single URI (zone?) for the whole site, and implementing zone access checks at each individual verifier.
Realistically, doing a PIV style PKI verification would give you all the benefits of FIDO2, but also with the ability to handle card revocation etc via a CRL that's distributed through the system.
I was expecting to have to write some code for it!
I do have a flipper and a classic key, will test it out soon!
> Through empirical research, we discovered a hardware backdoor and successfully cracked its key. This backdoor enables any entity with knowledge of it to compromise all user-defined keys on these cards without prior knowledge, simply by accessing the card for a few minutes. Additionally, our investigation into older cards uncovered another hardware backdoor key that was common to several manufacturers.
I’ve developed Unified Air, a new technology that allows factory workers to authenticate to production machines using the biometric sensors on their mobile devices—eliminating the need for insecure RFID cards altogether. Not only does this method enhance security by leveraging unique biometric data, but it also streamlines the authentication process, making it both faster and more reliable for operators.
If you’re interested in a more secure and user-friendly alternative to RFID, you can check out more details about Unified Air here: https://support.industry.siemens.com/cs/document/109827772/d...
How does adding a mobile phone with a significantly larger code and hardware base improve security?
> eliminating the need for insecure RFID cards altogether.
Why not use a secure card system instead?
I can see the convenience factor, and that might well make for a more effective system all in all, but in terms of security, I don't see this as a step forward.