Proxmark3 community

Whacko

Contributor

Registered: 2014-06-11

Posts: 7

MiFare Known Plaintext attack Card Side

Hi,

I've been playing with MiFare cards for a few years now but recently I started reading more into the various papers on the weaknesses etc.
I came across this paper: http://gerhard.dekoninggans.nl/documents/publications/dekoninggans.phd.thesis.pdf
I think it's an earlier version of "Dismantling Mifare classic". But it has some more examples of the communication with MiFare cards.

One thing that spiked my interest was the section about "Known Plaintext". Some readers send an encrypted HALT or READ that is encrypted using ks3.

Now let's say I can control the entire card side of the authentication: fixed Tag nonce, UID. And assuming the reader sends this HALT or READ. How easy would it be to recover the key?

Do I still need to setup the LFSR for rollback etc? would this still require a lot of power or could it be done on a picc ?

holiman

Contributor

Registered: 2013-05-03

Posts: 566

Re: MiFare Known Plaintext attack Card Side

You want to do a reader-attack with a picc, as I understand it. Since you control the tag, you can easily obtain get two AR/NR pairs.  You can check out /tooks/mfkey/mfkey32.c which implements can be used for that attack, it bruteforces the secrets based on that input. It uses lfsr rollback and crapto library. I don't know about any attack such as the one you're describing which does not require crypto state rollback and a pretty intense cpu-usage.

Whacko

Contributor

Registered: 2014-06-11

Posts: 7

Re: MiFare Known Plaintext attack Card Side

Thanks for your reply holiman.
Indeed I know of the mfkey32 code. It works as described indeed.

The situation described in the paper is as follows:
if you spoof a tag without knowing the key to the requested sector, you cannot send a response back to the reader encrypted with ks3. If your tag simply doesn't respond, some readers might timeout, and send a HALT command encrypted with ks3. since the bytecommand for the halt is known, you can xor the halt command from the reader with this code and get ks3. in some cases it might try the same, but try a new READ command encrypted with ks3.

That's why I thought this might be less cpu-intensive. (at least to get ks3) and maybe ks2 was easier to get aswell.