Additional debug log output while emulating Mifare Classic NFC Cards

[AlexHuebi]

Describe the enhancement you're suggesting.

I am currently in the analysis of an NFC tag and it would help, if the Flipper would report via the debug CLI, when a wrong Key has been used, what the Key was. Like for example if the current emulated file says that for sector 1 the stored key b is '30 FB E6 71 06 9E' and the reader tried to use '6C D0 C0 88 30 D7' The reason is, that the NFC Tag I am analyzing is an Mifare Classic Mini Tag, where (still a guess) the Key B for the sectors 1 to 4 is generated from the 4 Byte UID.

My guess is that the affected file where some changes have to happen is here: /lib/nfc/protocols/mifare_classic.c somewhere at line 891 but for now, I am not familiar enough with the codebase to make that change myself.

Anything else?

No response

[AlexHuebi]

Another thing that just came into my mind: I think it would be cool if there would be an option to ignore wrong keys and allow access to the sectors anyway. But I guess that might have to be a different issue?

[AloneLiberty]

Mifare Classic protocol never expose keys. Both card and reader never transmit keys, they just prove each other that they have same key. After authorization, all data transfer is encrypted with key, so no way to read/write sectors without key.

To get key that reader uses we use cryptographic weakness in Mifare Classic authorization sequence (and in crypto1 algorithm). Detect reader just records those authorization attempts (without emulating card contents). You can read more here. Or about how exactly Mifare Classic works here.

And lastly: during the emulation, time is VERY critical, even 1 line of log can break the emulation.

[AlexHuebi]

I just read through the authentication part of the white paper and I think that I understood that.

To recap: To achieve that what I'd need, the Flipper has to generate the nonce for the Reader. And that wouldn't be possible since the key for that doesn't exist. (or does it? Only the key B is unknown since key A is static when compared with all tags from that group)

But what might work, is the "extract keys from reader" function if I forge a .nfc file with the data in the affected sectors and the key b as unknown. (Although I am not sure here, since the key b will only be used if a write command is executed)

In any case I'll try that.

Thank you for the resources for now.

Also IIRC, if authentication fails, the card doesn't respond. So a single log line should be negligible?

[AloneLiberty]

key b will only be used if a write command is executed

In this case you probably should use nested attack to recover other keys (if your card isn't static encrypted nonce one)

if authentication fails, the card doesn't respond

There is already Wrong AUTH in trace logs

[AlexHuebi]

In this case you probably should use nested attack to recover other keys (if your card isn't static encrypted nonce one)

I've already done that on those, that I've got. But I am trying to create a new one with a different UID and thus different Key Bs.

There is already Wrong AUTH in trace logs

That is correct, but I thought, that if it would've been possible to get the key from the reader, it could've been in the same log output but that has obviously been marked as not possible.

Also, as 'feared' the "extract keys from reader" only got me the key A, which I already knew.

Do you know if something like the Hard Nested attack could also be performed in Reverse?

[AloneLiberty]

Hard nested is card-only attack, not reader. Nested authorization is interesting, in first authorization NT isn't encrypted, but in nested it's encrypted with NEW key. Thus gives us possibility to recover keys via nested attacks, but not messing with reader. You can sniff communication with valid card and reader (not with Flipper Zero, Proxmark3 for example) and recover key.

TLDR: You can't extract keys from reader if it does nested authorization and you don't have real card.

[skotopes]

@gornekich @Astrrra any ideas?

[gornekich]

Thanks @AloneLiberty for the explanations. To calculate "wrong key" we have to accept authentication with "wrong key", which breaks emulation logic.