Hacking iClass Elite with proxmark3

RFID-based physical access control systems (“physical” as in systems for opening doors to grant physical access to a site) are very interesting. Typically, a modern access control system is heavily integrated with IT-systems, susceptible to the same type of vulnerabilities found in any IT system.

LF entry systems

Historically, RFID-based access control systems utilized low-frequency RFID badges. These type of badges operate within 125 KHz or 134 KHz range. They are typically not very sophisticated; upon being powered by a reader, they shout their identifier (UID) continuously. Naturally, a drawback with this system is that they are easily cloneable; anyone who is close enough to both power the tag and read the tags modulations can read the id, thus later simulate the tag or program the identifier into a similar tag.

Low-frequency tags has the advantage that they can operate on a larger distance from a reader. This happens to be an advantage for attackers aswell; as an example, a commercial long-range reader with a read-range of up to 24 inches (~61cm) was modified by Proxclone.com to perform stealth attacks, e.g. by carrying the reader in briefcase close to the victim.

HF systems

The blatant insecurity of LF-based access controls led to the development of more ‘intelligent’ tags; HF-tags. These tags operate on the 13.56 MHz band and are capable of actually communicating (as in, a two-part dialogue, not just shouting an id..) and performing cryptography to protect the communications.

There are a lot of different systems, based on different ISO-standard but also with proprietary protocol extensions. Examples are Mifare Classic (based on iso 14443a) and HID iClass (based on iso 15693).

The most common such system is Mifare Classic. The ‘classic’ comes in several forms, from 1K storage to 4K storage. This system has been cracked since several years (check the whitepapers here for a more thorough reading about that). Without going too much into Mifare classic, these are some of the attacks that can be performed:

• An attacker with access to a card can crack the card (obtain keys) and dump data in less than a minute.
• An attacker with a few seconds access to a reader can obtain the keys (reader-attack) after two unsuccessfull authentication attempts.
• An attacker with ability to snoop communications between card and reader can obtain the keys.

There are now more modern replacements to the Mifare classic, e.g the Mifare Plus and Mifare NG are drop-in replacements where the two primary flaws in the original Classic have been fixed; e.g. an as-yet not cracked PRNG implementation.

HF systems in access control systems

Regarding physical access controls, there are different ways to use HF tags; as with LF systems, both Mifare and iClass has the concept of a unique identifier - UID in the case of Mifare, CSN (Card Serial Number) in the case of iClass. These identifiers can be read by any unauthenticated reader. These values allow a HF-based system to be utilized the same way a LF-system is; the tag is simply a stupid ID-transmitter.

A better approach is to ignore the factory-programmed UID/CSN, and instead use a the storage on the tag itself. This data can, supposedly, only be read/written by authorized readers. In this scenario, the tag is provisioned with a second layer of information, e.g. facility code, employee id and a checksum.

To illustrate how this works, the image below contains the first part of a data-dump from a Mifare Classic. All sectors contain four blocks each. On the first block of the first sector (block 0), the UID is stored, along with manufacturer information. On each fourth block, two keys are stored, which together with the access conditions (in the middle of the block) determine what type of credentials are needed to perform various operations with the data on the sector, e.g. reading and writing.

In the case of Mifare, three blocks of each sector can be used to store data.

iClass Standard

Another system is iClass. IClass are manufactured by HID Global, an Assa Abloy-corporation. The iClass technology also comes in several forms; I’ll just deal with iClass standard and iClass elite.

A few interesting differences between Mifare Classic and iClass are, for one, that it uses a different data layout:

As you can see, there is something called the e-Purse. You may remember that one of the causes that made Mifare Classic so easily hackable, was that it used a PRNG which was not random enough - an attacker with good enough timing could get the exact same nonce each authentication attempt.

iClass has done something a bit different - they don’t use a PRNG at all, but instead the e-Purse. The e-Purse is the equivalent of a nonce (called cc for card challenge in the iClass world), but in order for the security model to hold up, it requires that all legitimate readers update the purse with a new value, so that a potential eavesdropper is unable to do a replay attack.

It has been found that not all readers to this, which makes it possible to do just that. But that’s not what this hack is about.

The iClass technology has been gradually cracked wide open, starting with an attack called “Heart of Darkness” that uncovered the global secret key used to provide security for all iClass standard systems worldwide. Subsequent attacks uncovered the complete internal workings of the cryptographic algorithms, and located several vulnerabilities in the implementations for both standard and elite.

To summarize iClass standard security:

• All iClass standard systems worldwide use the same secret key. An attacker with access to this key can dump and emulate any card. This key has been uncovered by several different individuals, and steps to uncover the key has been posted on the internet in several different places.

iClass Elite

The Elite system is a bit more complicated. It does not use a global key, but instead uses a key which is determined at run-time, and is derived from both a custom key and the specific card with which it communicates:

So, instead of using a globally shared key, as in iClass standard, the actual key that is used is both installation-specific (based on custom key) and card-specific (influenced by CSN). After the diversified key has been calculated, the rest of the communication is identical to iClass Standard.

However, some vulnerabilites have been uncovered regarding how the diversified key is calculated, making it possible to obtain the custom key by simulating ‘malicious’ CSN values. An attacker who is able to spoof these well-chosen CSNs against a reader, will be able to

• Calculate hash1(CSN) - since the CSN is known and the hash1 algorithm has been reverse engineered.
• Bruteforce the hash2 key table. This is only possible if the indices ( hash1(CSN) ) has low enthropy.
• From the hash2 key table, calculate the kCus, since there is a reversability in hash2. In fact, only the first 16 bytes of the hash2 key table are required to recover the Kcus (and, thus, the rest of the hash2 key table.)

Once the Custom Master Key (KCus) is known by the attacker, the game is over.

Thus, from a number of authentication attempts with carefully chosen ‘malicious’ CSN-values, where the reader tests if the card is “one of ours” (it’s not), the attacker is able to obtain kCus - corresponding to the master key for iClass standard:

• Ability to read and write any card
• Ability to emulate/spoof any card

In a word, iClass standard and Elite are on par with Mifare Classic on crack-status. It is interesting to note that any iClass elite system is crackable by only a few seconds of proximity to a legitimate reader, while iClass standard is more difficult to crack (the global master key has not been publically leaked onto the internet, afaik).

For a more thorough description of iclass weaknesses, I recommend the paper Dismantling iClass by Flavio D. Garcia, Gerhard de Koning Gans, Roel Verdult and Milosch Meriac.

Practice

That’s the theory, at least. I was testing such a system, and noticed that these attacks, while detailed thoroughly in research papers, were not implemented in Proxmark. One attempt here had been made, but failed since the pm3 failed in communicating with modern readers. Proxclone (carl55 in pm3 forum) even took some oscilloscope traces in order to try and find the reason for the failure, but other than some timing differences between the end of reader tranmission and start of tag-transmission, found nothing missing.

So, I decided to go even more in-depth, using my new Rigol DS1074Z oscilloscope and a Omnikey 5321 V2 reader, I tooks some measures of the valid reader<->tag communications, comparing them with the Iso15693 specifications.

In order to capture the RFID communications with a common oscilloscope, I used the following setup.

1. On the bottom, a legit reader.
2. Next, a pm3 HF-antenna, with the oscilloscope probe connected to one of the HF-connectors.
3. On top of that, the tag. I replace this with another pm3 HF-antenna when I want to capture the pm3 simulation.

In these measurements, the reader was doing the reading every second or so, which meant I could just hit the scope stop button a few times, and sooner or later catch the start of communication. In other scenarios, you may not be so lucky, and may instead need an external trigger signal. I found that the pm3 has seven testpoints, and there are also a couple of LED’s that can be used for that purpose.

For example, if you want to perform the capture on something that happens very infrequently, you could just light up a pm3 LED at the appropriate time, connect a scope probe to that LED, and use that as external trigger to the scope. For reference, here are the testpoints:

Four of them are directly connected to the antenna(s) so you can do measurements there instead of connecting to the antenna like I did.

• TP3 and TP4 are connected to the HF antenna
• TP2 and TP5 are connected to the LF antenna
• TP1 is connected to the output of the MUX and shows the ADC input.
• TP7 is connected to an output of the FPGA and can be used by the FPGA code to output a debug signal (that’s output dbg in fpga/fpga.v).
• TP6 is simply connected to GND to give an easily accessible reference ground

Legit reader and tag

Here we see the legit reader and legit tag. Unfortunately, I made a bad screenshot which does not properly show the measures. But each grid is 100us, so it’s around 340us between end of reader transmission and tag SOF.

On the image below, I’ve zoomed in on the tag SOF. It clearly shows the 24 peaks. Each grid is 10us.

Here you can see what the ISO-15693 specification SOF looks like. 24 pulses followed by a zero-period, then 8 more pulses.

Here is a snapshot of a 8 modulations. Shows a modulated “0”. 8 pulses within 18.88 us, total length 37.76 us. Measured length: 38us - which is within the margin of error.

And this is the spec - it looks very much like the capture, not surprisingly:

Legit reader pm3 simulated tag

So, that’s the background. Let’s look at how the pm3 behaves in tag mode. (The blue is the signal, and the yellow my oscilloscope trigger attempt) Simulated tag, legit reader. The time before SOF is 280 us. This is a bit faster than the legit tag (which was ~340), but should be easy to fix:

Here we see the timing of the latter part of the SOF. The time should be 56.64 us (see spec above). Measured: 57 us. Within margin of error.

This picture hows the SOF ones in more details: measured time 56.40 us. But… There should be 24 peaks, the trace shows 48 peaks. The timing seems correct, but the frequency of the modulated signal appears doubled. Compare with the legit SOF above with its 24 peaks.

Here we look at the end part of the tag SOF. Shows the end of SOF. Time should be 37.76us, measured 37.40 us. 16 peaks, should be 8. Frequency is doubled.

So, to conclude: The carrier modulation frequency was doubled. This seemed to be an easy bug to fix!

Fixing the carrier

The pm3 is divided into several parts.

• The client. This is the PC software, which talks to the device over USB. Implemented in Ansi C, but also has Lua bindings (courtesy of myself).
• The ARM. This is the onboard microcontroller, where most device-side logic is implemented in Ansi C.
• The FPGA. This is the first receiver of input (after AD) and last stop of output (before antenna) regarding low-level signals. This part is responsible for low-level modulation and demodulation; removing/adding carrier frequeny. The FPGA has a 13.56 MHz clock which can keep it in perfect sync with HF tags. Written in Verilog.

So, after taking a dive into Verilog, I was able to fix the carrier frequency problem.

The next step in order to perform an attack would be to emulate a set of CSNS. In the “Dismantling iClass”-paper, they use an approach which uses 15 authentication attempts. I decided to optimize that a bit - an optimal approach would have the following characteristics:

• The first CSN should consist of three individual indices, preferrably all lower than 16.
• Each subsequent CSN should produce hash2 values introducing two new indices, both lower than 16.

If such CSNs can be found, a mere 8 authentication attempts would reveal the first 16 bytes of the key table, which is all that is required to calculate the custom key (KCus).

I wrote a simple python implementation of Hash2, which was allowed to run for about a day. The script found these CSN-values:

|Recovered bytes |Required bytes |        CSN              |     HASH2(CSN)          |
|----------------+---------------+-------------------------+-------------------------|
|0,1,69          |               | 00 0B 0F FF F7 FF 12 E0 | 01 01 00 00 45 01 45 45 |
|2,12            |0,1,45         | 00 13 94 7e 76 ff 12 e0 | 02 0c 01 00 45 01 45 45 |
|7,11            |0,1,45         | 2a 99 ac 79 ec ff 12 e0 | 07 45 0b 00 45 01 45 45 |
|3,15            |0,1,45         | 17 12 01 fd f7 ff 12 e0 | 03 0f 00 00 45 01 45 45 |
|4,8             |0,1,45         | cd 56 01 7c 6f ff 12 e0 | 04 00 08 00 45 01 45 45 |
|6,14            |0,1,45,8       | 4b 5e 0b 72 ef ff 12 e0 | 0e 06 08 00 45 01 45 45 |
|9,5             |0,1,45,11,15   | 00 73 d8 75 58 ff 12 e0 | 0b 09 0f 00 45 01 05 45 |
|10,13           |0,1,45, 15, 5  | 0c 90 32 f3 5d ff 12 e0 | 0d 0f 0a 00 45 01 05 45 |

I implemented the cryptography related to iclass in loclass, written in ANSI-C in order to be simple to insert into the proxmark3 codebase. A lot of credit goes to pm3-forum users midnitesnake, pentura_prox, proxclone and proxmarkzzz.

Tying it all together

As of right now, everything is still not tied together. The pm3 can be used to perform the ‘malicious CSN’-attack.

hf iclass sim 2

This will save the dump as a binary file iclass_mac_attack.bin (and then iclass_mac_attack-1.bin etc), which can then be run through the loclass framework:

#./loclass 
IClass Cipher version 1.2, Copyright (C) 2014 Martin Holst Swende

Comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to use, abuse and repackage, please keep the credits

Usage: iclazz [options]
Options:
-t                 Perform self-test
-h                 Show this help
-f <filename>      Bruteforce iclass dumpfile
                   An iclass dumpfile is assumed to consist of an arbitrary number of malicious CSNs, and their protocol responses
                   The the binary format of the file is expected to be as follows: 
                   <8 byte CSN><8 byte CC><4 byte NR><4 byte MAC>
                   <8 byte CSN><8 byte CC><4 byte NR><4 byte MAC>
                   <8 byte CSN><8 byte CC><4 byte NR><4 byte MAC>
                  ... totalling N*24 bytes
                  Check iclass_dump.bin for an example

And testing with the example dumpfile:

#./loclass -f iclass_dump.bin 
IClass Cipher version 1.2, Copyright (C) 2014 Martin Holst Swende

Comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to use, abuse and repackage, please keep the credits

Bruteforcing byte 1
Bruteforcing byte 0
Bruteforcing byte 69
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123=> 1: 0x35
=> 0: 0xf1
=> 69: 0x7b
=> 2: 0x59
[... removed for brevity... ]
=> 5: 0x5a
=> 125: 0x70
=> 21: 0x85

Performed full crack in 107.098549 seconds

High security custom key (Kcus):
Std format    = 8fa250c3cb61f41c
Iclass format = 5b7c62c491c11b39
Key verified ok!

The example file above uses the CSN-values from proxclone’s covert attack, which uses 126 authentication attempts. Loclass is agnostic regarding what CSNs have been used during the authentication attempts.

There is more work to be done, in order to dump an elite card using proxmark. Forum users midnitesnake and pentura_prox wrote functionality to dump standard iclass tags, but I’ve not succeeded in dumping elite cards as of yet - unfortunately I don’t have access to an elite card right now, but I hope to be able to finish that part later.

2014-08-10

tweets

favorites