iClass request

[iceman]

Some ppl has been asking about this and my own curiousity has been there since I implemented a naive dictionary implentation for the proxmark3 client.
There are different attacks already for different parts,  but given a sniffed trace of authentication

A hashcat implementation would be good for the scenario of custom keys.  

What is it?

iClass crypto

- triple des
- three hash diversifications  (hash-0 , hash-1, hash-2) for two modes.  legacy standard / elite (high)
- a twist of the des key aswell.  all parity is in last byte instead of MSB

Possible ideas for Hashcat would be a dictionary or bruteforce mode.

http://www.icedev.se/proxmark3/proxclone...HSKeys.pdf

Documents.
http://www.proxmark.org/files/proxclone.com/

[atom]

Can you be more specific which type of computation is needed?

[thesle3p]

I would really love to see this happen, would make cracking Iclass Elite keys much more viable.

[atom]

I'd be happy to add this to hashcat. Just need the details.

[royce]

https://www.cs.bham.ac.uk/~garciaf/publi...iClass.pdf

[Xadhoom]

I'd be happy to add this to hashcat. Just need the details.

Given the current state and work of the proxmark3 repository, this could be actually reduced to a function to crack 40 bits.

TLDR:
The initial scope described by Iceman was to crack a 64 bit key.
Now, a faster way to do this instead would be to retrieve 24 bits of that key and crack the remaining 40.
This is currently done with a CPU implementation and it takes a significant time to complete.

The details are as follow:

User intake:
- The known 24 key bits, these are distributed as the last 3 bits of each byte in an 8 byte sequence.
- The epurse value (a string of 8 bytes used for macs generation)
- Two nr-macs traces

What the hashcat module should do:

In a bruteforce fashion it should generate the remaining 40 bits of the 64 bits key, leaving the specified 24 bits unchanged.
It should then use the generated 64 bits key to compare it against the epurse+mac1 trace and see if there's a match
If there's a match it should repeat the previous step against epurse+mac2 trace.

If there's a match also with the second generated mac, end the process and return the identified key (40bits bruteforced + 24bits provided), otherwise continue by incrementing the 40 bit value.

It is relatively easy to extract the required c code from the Proxmark3 repository for these calcualtions and I'd be happy to help with this, but I do completely lack the hashcat knowledge to implement this.