[idea] hf iclass ident

iceman · 2017-12-23 12:09:30

Been thinking on iclass authentication during my implementation of the new check keys command against a iClass tag.

Once you have, say the legacy AA1/ Kd key, it quite easy to detect which mode the reader is configure.
Well, obviously, since you have the key and make a valid authentication...

However, for SNIFF / SIMULATION, you don't have that info currently,

Like in the sample below, ignore that I used the legacy key, and look at the trace.

pm3 --> hf icl readblk b 06 k -------------
Block 06: 03 03 03 03 00 03 xx xx

pm3 --> hf ic lis
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
iClass    - Timings are not as accurate

      Start |        End | Src | Data (! denotes parity error)                                   | CRC | Annotation

------------|------------|-----|-----------------------------------------------------------------|-----|--------------------

          0 |          0 | Rdr |0a                                                               |     | ACTALL
        576 |        576 | Tag |0f!                                                              |     |
       3408 |       3408 | Rdr |0c                                                               |     | IDENTIFY
       6192 |       6192 | Tag |b2! 8a  YY! 00! ff! 5f! 02  dc  7b! 41!                          |  ok |
      10048 |      10048 | Rdr |81  b2  8a  YY  00  ff  5f  02  dc                               |     | SELECT
      12832 |      12832 | Tag |96! 55! a4  00! f8  ff! 12! e0  89  f8                           |  ok |
      15792 |      15792 | Rdr |88  02                                                           |     | READCHECK[Kd](2)

      18064 |      18064 | Tag |f0! ff! ff! ff! ff! ff! ff! ff!                                  |  ok |
      21920 |      21920 | Rdr |05  00  00  00  00  89  cb  98  4b                               |     | CHECK
      23168 |      23168 | Tag |dc  68  d7! 57                                                   |  ok |
      26384 |      26384 | Rdr |0c  06  45  56                                                   |  ok | READ(6)
      29184 |      29184 | Tag |03! 03! 03! 03! 00! 03! xx  xx! 43  23                           |  ok |

For you who don't know what to look for, let me point it out.
the key here is the MAC that the reader sends.

      21920 |      21920 | Rdr |05  00  00  00  00  89  cb  98  4b                               |     | CHECK

the 0x00000000 is our "really" random nonce pm3 generates.
The 0x89cb984b in the end is the MAC that the reader calculates over the CSN and key

If we have the CSN, (uid), since we are sniffing, yes.
If we have the CCNR (card nonce block2)
If we have the legacy key, also,
than we can see which security mode the reader was when this sniff was done.
if it fits the legacy key mac calc, its in legacy,
if not, the reader must be in elite /high security mode.

Here is the kicker,
mix this together with having a default key list, we can also make a reader based attack when simulating, (we control CSN,CCNR)
since we can pre-calculate all mac in elite mode, for each of our defaultkeys in list, it comes down to collecting this MAC in order to look up in a table.

This would enable
- very fast check keys algo against reader (not only card)
- very fast identification which mode reader is in. (when sim)
- decoding a trace, from sniff, sim

Merry x-mas!

(yes, the trace has been anonymized abit with XX, YY values, since the block6 wasn't encrypted)

carl55 · 2017-12-24 02:13:20

iceman wrote:

Here is the kicker,
mix this together with having a default key list, we can also make a reader based attack when simulating, (we control CSN,CCNR)
since we can pre-calculate all mac in elite mode, for each of our defaultkeys in list, it comes down to collecting this MAC in order to look up in a table.
This would enable
- very fast check keys algo against reader (not only card)

Unless I am missing something, I tend to disagree with the above statement.
In my opinion it would be very difficult to create a table to do what you are proposing.
Since the reader always generates a 32-bit "random" nonce (challenge) that is used in calculating the authentication MAC, there would be a total of 2^32 MACs that would have to be calculated for each "known" elite key that was in your list. It would be nice if the reader always used a nonce value of 0x0000000000000000 as shown in your sample communication sequence above but that is just not the case.

iceman · 2017-12-25 14:50:26

Well, don't we get the reader nonce when sniffing or looking at a trace? Or when we simulating? Or did I miss something?

carl55 · 2017-12-25 16:59:02

It appears that I misunderstood what you are trying to accomplish.
There are three ways you could try and obtain the key (see below). I assumed that you were attempting to base your attack on approach two. An attack using approach one and three should work.

1. Emulate a reader interracting with a legitimate high security/Elite credential.
2. Emulate a HS/Elite credential interracting with a legitimate HS reader.
3. Sniff a communication sequence between a legitimate HS reader and a legitimate HS credential.

In approach one, you would need to have knowledge of the reader nonce, the card challenge(e-purse), and the credential UID in order to generate the diversified key and subsequent MAC. If you have a n-length list of possible keys then you should be able to try "n" authentication attempts until one works, provided you do not update the credentials e-purse like a legitimate reader would.

In approach two, you would need the same information. However, since the reader is now issuing a new 32-bit random nonce for each authentication attempt you would not be able to use a table of pre-calculated MACs.

In approach three, you would be able to capture the UID, e-purse, nonce and reader MAC. This would allow you to then calculate your own MAC for each Elite key in your list until you found one that matched.
Attack #3 however is probably the most difficult since it requires that your PM3 has access to a legitimate HS/Elite reader AND a legitimate credential that utilizes the same Elite key.

iceman · 2017-12-25 17:52:05

(1) that would be the idea of the CHK (check keys) implementation. a card-attack.
(2) a reader-attack, using a new SIM command, would give the same info as used for (3), Attack contains two parts. Online against reader, offline calculate like (3).
(3) that would be the idea of default keys list and using only trace information CSN, CCNR, to find calc_macs=MAC. if found, this would indicate what password the reader tried to authenticate with.

All above has a strong limit:
These attacks would only be as good as your collected default_iclass_keys.dic file.

iceman · 2017-12-26 13:43:50

Well, implemented the (3) item, works as expected. Will try a new sim mode.

Proxmark3 community

Announcement

#1 2017-12-23 12:09:30

[idea] hf iclass ident

#2 2017-12-24 02:13:20

Re: [idea] hf iclass ident

#3 2017-12-25 14:50:26

Re: [idea] hf iclass ident

#4 2017-12-25 16:59:02

Re: [idea] hf iclass ident

#5 2017-12-25 17:52:05

Re: [idea] hf iclass ident

#6 2017-12-26 13:43:50

Re: [idea] hf iclass ident

Board footer