Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MIFARE Classic: exposing the static encrypted nonce variant [pdf]

eprint.iacr.org

Post reply on HN
Print view View original

91–100 of 103 posts

Re: MIFARE Classic: exposing the static encrypted nonce variant [pdf]

#91

Post by ethbr1 »

nativeit wrote: post #46
borski wrote: post #20

Earlier quoted context omitted.

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 empl…

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 ce…

> 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)

Re: MIFARE Classic: exposing the static encrypted nonce variant [pdf]

#92

Post by nullc »

adontz wrote: post #89
noddingham wrote: post #35

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 r…

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)

Re: MIFARE Classic: exposing the static encrypted nonce variant [pdf]

#93

Post by adontz »

nullc wrote: post #92
adontz wrote: post #89

Earlier quoted context omitted.

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.

Re: MIFARE Classic: exposing the static encrypted nonce variant [pdf]

#94

Post by account42 »

dfox wrote: post #69
znpy wrote: post #62

Earlier quoted context omitted.

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.

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.

Re: MIFARE Classic: exposing the static encrypted nonce variant [pdf]

#95

Post by account42 »

ThePowerOfFuet wrote: post #78
yuliyp wrote: post #76

Earlier quoted context omitted.

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're not wrong, but that is precisely the tradeoff: stored-value is more reliable but also more vulnerable. It's reminiscent of the old NASA saying: "faster, better, cheaper: pick any two".

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.

Re: MIFARE Classic: exposing the static encrypted nonce variant [pdf]

#96

Post by account42 »

borski wrote: post #20
ethbr1 wrote: post #16

Earlier quoted context omitted.

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?

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 empl…

> companies tend to rely on their employees’ vigilance

AKA they ignore the problem but check it off on the security audit.

Re: MIFARE Classic: exposing the static encrypted nonce variant [pdf]

#97

Post by lxgr »

adontz wrote: post #93
nullc wrote: post #92

Earlier quoted context omitted.

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.…

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).

Re: MIFARE Classic: exposing the static encrypted nonce variant [pdf]

#98

Post by lxgr »

dfox wrote: post #69
znpy wrote: post #62

Earlier quoted context omitted.

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.

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).

> it is 2024, just do that online

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.

Re: MIFARE Classic: exposing the static encrypted nonce variant [pdf]

#99

Post by lxgr »

minkles wrote: post #48
noddingham wrote: post #35

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 r…

Yeah TFL killed them off starting 2010 in London due to this. I'm surprised this is even a thing now.

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).

Re: MIFARE Classic: exposing the static encrypted nonce variant [pdf]

#100

Post by lxgr »

bobnarizes wrote: post #42

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—eliminati…

> [...] 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.

Post reply on HN