I've been involved with carding for 10+ years and issues with MIFARE Classic cards have been around and known for at least that long. Anyone in the carding industry will (should at the very least) tell you not to use them and move on to DESFire or some other newer safer chips. The introduction even says as much "By 2024, we all know MIFARE Classic is badly broken." If you're still deploying MIFARE Classic cards you reap what you sow.
Yup… the vending machines at my university used to use mifare classic tokens with credit on such tokens… in like 2014 i was a student and ran out of money in the middle of july and barely had the money to buy a train ticket to go home for vacation… but thanks to mommy mifare i managed to survive on sandwiches from said vending machines for like two weeks.
My university had something similar, but with ID numbers correlated to each person in a database that recorded how many credits they had left.
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...
The main point from that is that you should never do a system with stored value on a smart card. The vendors will show you various methods for that, but well it is 2024, just do that online (and the card is just an ID, which optionally can produce ECC signature of some challenge).
No, stored value is a good solution if you want the system to function without online connection. You should still collect all transactions centrally where inconsistencies can be exposed. If that were been implemented GP would have been looking at a fraud charge.
having a pos in places without a reliable internet connection is enough of a reason for stored value cards to be a thing. Some things shouldn't require the mothership to be alive and reachable to work.
You don't need the system to be invulnerable to fraud, you just need to be able to detect it. Offline stored value cards plus separately shipping transactions to a central system with eventual consistency can give you that. The vending machine in question probably isn't invulnerable to physical break in either.
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.
MIFARE Classic are cheap and reliable, only their encryption is broken. One can use them as simple storage and encrypt/authenticate data by different means. Nothing wrong with that. I did that, ECC signatures are small enough to fit in 2K/4K cards.
A signature fits but what good does it do you? The cards can't sign a challenge, and so someone with access to a valid card can just clone it. (or access to a card and reader, in the case encryption is used)
RFIDs are rarely certified as possession factors, you need an EMV card for that. TPM chips may protect readers. Depends on reader/card ratio, if it's feasible.
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.
MIFARE Cards are not RFID cards, and similar systems can absolutely be used as possession factors.
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).
Yes, and more generally I've been baffled by the fact that manufacturers - including ARM-based SoCs with SecureBoot (or similar); you know, those PDF spec docuements that disable copy-paste and a nice "confidential" watermark - put their cyber-security stuff under NDA. As if it security-by-obscurity was still a thing.
Oyster has been using MIFARE DESfire, and stopped using MIFARE Classic, for over a decade now.
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).
could somebody ELI5 the threat vector here? I'm not skeptical, I just don't know what to imagine.
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?
Most RFID card systems in the world uses MIFARE Classic due to its cost and long history.
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).
> 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.
Would you happen to know of a good reference for this? I have a Proxmark and I'd like to learn how the encryption works so I can play around with (and maybe clone) some of my cards.
These systems usually do mutual authentication, and that's as much a side effect of the cryptographic primitives used as it is an intentional feature:
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.
The idea is that by spending a few minutes with your card, someone can now clone it and impersonate you. Yes, they could already steal your card, but you might notice that. But if you leave it on your desk for a few minutes in your wallet, or IT “borrows” it to re-encode it, or any thousand of other ways to get a hold of your RFID card… it can be dumped, cloned, and you can be impersonated.
In the case of this attack, somewhere between 40s and 30min of physical access, depending on how the card was set up. In the case of a hotel, the spicy card to clone would be the cleaning staff's, which conveniently also admits a reasonable explanation for the card going temporarily missing (e.g. abandon it one corridor over, oops must have dropped it while doing the rounds).
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.
> 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.
I know only one access system that is built on Mifare and does not use UID, and that thing uses a file on the card as a bitfield of what doors it can open.
Great question; not to my knowledge. There would be many false positives, especially as people bring in guests. Sometimes guests get a temp badge; at many companies, they get a sticker to put on their shirt and get tapped in by their host, who is responsible for them.
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.
I suppose the expense, and the risk in relying on employees, is gonna be quite relative to the organization and its priorities. I wouldn’t imagine setting up a log monitor with some basic monitoring should be that expensive. As someone above mentioned, it’s kind of odd that these systems are so utterly disconnected to the broader IT protocols in so many places. 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. The most critical point would simply be maintaining healthy access controls and avoiding the potential for new potential vulnerabilities.
> I suppose the expense, and the risk in relying on employees, is gonna be quite relative to the organization and its priorities.
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.
> As someone above mentioned, it’s kind of odd that these systems are so utterly disconnected to the broader IT protocols in so many places.
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)
Yes, locking people into buildings (which is what you are doing if you need a key to get out, whether it's an RFID badge or a skeleton key) has been illegal since the Triangle Shirtwaist Factory Fire
As I mentioned in a sibling comment, you don't lock them in, you just set off major alarms and send an armed response if the door ever opens without badge activation. This presupposes some things about the facility and the facility operator, though.
But places that actually take access control seriously do implement bidirectional badging, and just opening the door to leave without badging out will send a group of people bearing guns in your direction right away.
You'd think that, but, as someone who did a phyiscal pentest on a prison recently, that's 1000% not the case.
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.
Well, the costs for the 'in' and 'out' reader are really not the major issue for most companies, as you could conceivably set a particular perimeter that cordons of 'secure' from 'not secure' and would only have to configure anti-passback for that perimeter. The real trick (and therefore problem) is in making sure that people do not walk through doors together, that is, making sure that only a single person passes the perimeter for a single access request. Single-person passages are way more costly than the readers, and have the additional problem of not allowing all that many people to pass per hour. That means that you may even need multiple for a given people flow. And that's leaving aside the convenience issues.
I used to work on such systems in another life, we could setup antipass back for a gate or area. I believe we could also put a temporal restriction but my memory is a bit fuzzy.
I don't think the contention was that the feature or ability doesn't exist, but rather that companies choose not to do it. When you worked on those systems - did you set up anti-passbacks?
Yes, it was in France and related to security, we had to ensure that the area antipass back was working properly, there were several areas where "random" entry was highly prohibited (let's say live shows).
Recently I worked for a bank where they had different types of entry airlocks, it was a bit a pain, especially the multiperson ones.
That would be a terrible user experience. Most places are not diligent about ensuring each employee separately badges past a barrier. Common to hold the door for Bob while he is juggling a coffee. Boom, missed badge swipe and now things are forever imbalanced.
Notably Apple expects each person to badge in. Google does not, and it is pretty easy to follow a group of people in to a building, but you cannot do that at Apple.
Because nobody has ever jumped over one of those or triggered the motion sensor on the other side of those paddle gates or gone around the side or underneath...
I know many companies I worked for in CA and CO did that at least for their parking garage gates but NOT for their building control readers, even though it was the same badge.
"Should we buy a Chinese knockoff of MIFARE Classic" strikes me as a self-answering question, but I guess that's why I still haven't been promoted to CISO.
The end users of such cards are often not aware of the source, there's usually resellers that supply them who are always trying to save a buck here or there.
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.
Possibly so. It just means that based on the report's findings, even if you'd decided to play it safe and buy exclusively from NXP directly (the creators of this ecosystem and owners of the MIFARE trademark), it looks like you could still end up with backdoored hardware.
Sorry if I was being unclear with my compound snark, but using a MIFARE Classic of any provenance would be a firing offense for the CISO of my daydream company.
Indeed. Alas (or fortunately depending which colour team you work on), fully broken Mifare Classic is still all over the place, and likewise the "hardened" variant broken in this paper :(
MIFARE DESFire is an option. In a genral public reseller, I found 100 DESFire cards sold for 146€ (tax excluded), while 100 of the equivalent versions as MIFARE Classic are sold for 109€ (tax excluded). This is a differnce of 37 cents by card, MIFARE Classic are about 25% less expensive than MIFARE DESFire. I guess the difference increase with the quantity you buy at once.
Maybe for greenfield deployment… but there’s all the existing infrastructure to support.
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.
I still see new apartment buildings with Sentex or Linear call boxes with the factory master passwords. I don't think these guys are crack security experts.
They found the exact same backdoor key present on old NXP and Infineon cards produced as early as 1996. See p.11:
> 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?
I think it's more likely those NXP/Infineon parts are counterfeits. Look at A.12, there are early cards that don't NACK $F000 but claim to be NXP or Infineon, behavior counter to legit parts. It looks like the Chinese copies started to chameleon that behavior later as well.
You might get promoted to CISO if you can come up with a creative way to quantify the risk. Risk management frameworks can communicate how the impact, likelihood, and possible responses would play out in dollar amounts. With a few proposed ideas for how different risk mitigations would affect the resulting residual risk, non-technical people may be able to adopt your vision for securing the enterprise.
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).
That’s not how CISOs get promoted. If a CISO presented it this way, the very obvious next question is “and how much will it cost us to fix” followed by “and how much will insurance cover,” which are both going to blow the reputational damage argument out of the water.
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.
The question is usually a bit more complex, such as "should we rip out thousands of readers and gates in our buildings, or can we maybe get away with switching to hardened cards using the same protocol for a few more years".
Not that I'd recommend it, but in most companies, physical security doesn't have a limitless budget just like everything else.
There absolutely are access control systems out there using PKI. For example, the PIV specification (a la DOD CAC) slot 9e is intended for "card authentication" without a PIN typically being required.
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.
It should not work (yet), at least not the official firmware or the RogueMaster. It requires special auth command(s) instead of the usual. Hopefully soon tho!
Baader Meinhof effect but I spent the last two days trying to clone my uni's Mifare Classic 1K's because they refuse to reactivate my ID because it is faded.
The problem is pretty serious, not an esoteric theoretically exploitable vulnerability, but a gaping hole. From the abstract:
> 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.
This news about RFID vulnerabilities really highlights the importance of rethinking how we secure access to critical systems, especially in industrial environments. At Siemens, we’ve been working on a solution that addresses these exact concerns.
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.
> [...] authenticate to production machines using the biometric sensors on their mobile devices
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.
