[HN Gopher] MIFARE Classic: exposing the static encrypted nonce ...
___________________________________________________________________
MIFARE Classic: exposing the static encrypted nonce variant [pdf]
Author : dave_universetf
Score : 194 points
Date : 2024-08-16 18:53 UTC (4 hours ago)
(HTM) web link (eprint.iacr.org)
(TXT) w3m dump (eprint.iacr.org)
| jeffbee wrote:
| "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.
| dave_universetf wrote:
| The paper reports that the same backdoor seems to be present in
| some NXP and Infineon SKUs as well, including some manufactured
| in Europe.
| janice1999 wrote:
| They could have licensed the IP from the same company.
| dave_universetf wrote:
| 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.
| jeffbee wrote:
| 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.
| nine_k wrote:
| What's a good alternative? How more expensive is it?
| Aiolo wrote:
| MIFARE DESFire is an option. In a genral public reseller,
| I found 100 DESFire cards sold for 146EUR (tax excluded),
| while 100 of the equivalent versions as MIFARE Classic
| are sold for 109EUR (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.
| dave_universetf wrote:
| 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 :(
| RockRobotRock wrote:
| NXP would probably want to steer you away from mifare
| classic in the first place, wouldn't they?
| mzs wrote:
| 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.
| Haemm0r wrote:
| ... or used the IP without licensing.
| aragonite wrote:
| 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?
| turtle_heck wrote:
| 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.
| evanjrowley wrote:
| 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).
| TeMPOraL wrote:
| 1) Frame as much of the risk in terms of reputation damage;
|
| 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.
| borski wrote:
| 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.
| closeparen wrote:
| Does a CISO even make this decision? Probably like a contractor
| hired by the building manager of an anonymous commercial real
| estate holding company.
| nine_k wrote:
| 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._
| fsckboy wrote:
| 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?
| borski wrote:
| 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.
|
| That's the threat vector.
| ethbr1 wrote:
| Super curious to know how many common access control
| solutions flag unbalanced entries/exits.
|
| E.g. if "John" badges in... and then 10 minutes later "John"
| badges in again...
|
| Will most systems complain?
| 0cf8612b2e1e wrote:
| 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.
| closeparen wrote:
| If you care about this at all you'd use a turnstile.
| borski wrote:
| 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...
| borski wrote:
| 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.
| nativeit wrote:
| 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.
| borski wrote:
| > 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.
| emag wrote:
| From experience, more places than you'd expect only have
| you badging in one direction and not both.
| padthai wrote:
| Probably fire safety laws
| dingnuts wrote:
| 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
| floren wrote:
| 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.
| floren wrote:
| 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.
| imroot wrote:
| 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.
| borski wrote:
| And also pay for the people to enforce it.
|
| Yes, some places do. But those places are rare.
| Foobar8568 wrote:
| 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.
| borski wrote:
| 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?
| dave_universetf wrote:
| 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.
| Nextgrid wrote:
| > 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.
| guardiangod wrote:
| 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).
| ale42 wrote:
| > 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.
| gillesjacobs wrote:
| This is also why chip implants from eg Dangerous Things with
| MIFARE were desirable: you could clone old MIFARE chips this
| way using some tools.
|
| 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.
| altairprime wrote:
| Backdoor root access to instantaneously clone any affected RFID
| card with one of the chipsets listed on the second to last
| page.
| noddingham wrote:
| 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.
| jtriangle wrote:
| "carding" is also colloquially used to refer to people involved
| in credit card fraud online. Just FYI in case you get weird
| looks when you say that.
| pajeets wrote:
| also attracts 3 letters when they see "carding" on clearnet
| corn13read2 wrote:
| 3 letters and clearnet in conjunction I'm sure won't garner
| attention
| astrobe_ wrote:
| 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.
| minkles wrote:
| Yeah TFL killed them off starting 2010 in London due to this.
| I'm surprised this is even a thing now.
| znpy wrote:
| 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.
|
| Oh, to be young again.
| madjam002 wrote:
| How does this relate to PKCS or cards using PKI? Are there access
| control systems out there that use this and is it more secure?
|
| Or maybe there's door access control systems out there that use
| FIDO2 :D
| g_p wrote:
| 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.
| arjvik wrote:
| Can I use a flipper zero to perform these attacks?
| hoherd wrote:
| My guess is NFC -> Extra Actions -> MIFARE Classic Keys -> Add,
| but I don't have any Classic keys to test on right now.
| arjvik wrote:
| Oh, the existing MIFARE app already supports this new attack?
| That's awesome!
|
| 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!
| bobnarizes wrote:
| 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.
|
| 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...
| Thoreandan wrote:
| Non-PDF link w/ abstract: https://eprint.iacr.org/2024/1275
|
| MIFARE Classic: exposing the static encrypted nonce variant
|
| Cryptology ePrint Archive, Paper 2024/1275
|
| author: Philippe Teuwen
___________________________________________________________________
(page generated 2024-08-16 23:00 UTC)