Cloning iClass standard security

Heru · 2017-10-25 13:09:33

Hi all ,

I have got my proxmark3 recently and so far having some success with a couple of different type of cards,( personal use and educational purpose only, of course )

Now I stuck with an iClass card not able to clone it ,

The card is very old and I believe its just a standard security card.

So my question is how many security keys do we need in order to read the card?

It looks like there are several encryption keys each has their own unique roles,

HID iClass master auth key ( leaked online?)
AA1 key , AA2 key,

It seems like i would also need PikoPass 2k default key for the blank card which I don't have some yet in my possession,

I do have some r/w HID 2020 blank cards and wonder if I can use this card to write,. ,

Thanks for your hints

carl55 · 2017-10-25 16:34:02

There are three different types of keys that are used in all iClass systems.
1) Authentication Key.
2) Encryption/Decryption Key(s).
3) Diversified Key.

The authentication key is the key that is used (indirectly) to gain read/write access to the internal data blocks stored on the credential. This key is "only" used to calculate a diversified key which is the actual key being used in the authentication sequence. Depending on the context of the discussion, the authentication key is also referred to as the Default key, the HID Master Key, Elite Key, or High Security Custom (Kcus) key. There is one authentication key associated with each application area of the credential however the HID access control application always resides in application area 1 (AA1).

The Encryption/Decryption key(s) are used to encrypt or decrypt the data that is stored in the various data blocks of the credential. The iClass architecture supports three different options including no encryption, DES encryption, and TDES encryption. There are two different encryption keys assigned by HID (K1 and K2). K1 is used for DES encryption and K1/K2/K1 is used for TDES encryption. The specific encryption mode being used is specified in Block 6 of the credential.

The Diversified key is the key that used for all authentication and cryptographic signature operations. This key is what is actually stored on the credential and is different for each credential since it is calculated using the CSN and the main authentication key. When the authentication procedure takes place, both the card and the reader use this key in all of their cryptographic calculations. The reader must calculate this key (based on CSN) before each authentication whereas the card simply retrieves the diversified key from memory (e.g. Block 3 for AA1).

It is also important to understand the concept of key permutation when working with iClass. The HID iClass readers store all of the keys in memory using a permuted format. The Proxmark3 and OmniKey readers store (and use) the non-permuted version of the key. A description of iClass key permutation can be found in the HID iClass Serial Protocol document. However, if you think of a 64-bit key as a group of individual bits arranged in an 8x8 matrix, then the difference between a permuted key and an un-permuted key is basically whether the 8-bit bytes are grouped horizontally or vertically.

One last thing to be aware of regarding iclass ....
There are basically three types of iclass credentials that have been sold by HID:
1) Uninitialized/Unconfigured
2) Initialized/Configured
3) Programmed

The Uninitialized credentials are completely blank. They are programmed with the CSN but all other data blocks are empty. The card uses the PicoPass default authentication key.
These credentials are fully configurable regarding all of the configuration options and fuses. These types of credentials are no longer being sold on the open market.

The initialized/configured credentials are pre-configured (by HID) so the end user no longer has any ability to change any Block1 or Block5 values. The HID access control application is blank. The credential format, facility code, card number, PIN, etc have NOT been programmed. The credentials utilize the HID Master authentication keys.

The programmed cards are fully programmed and externally marked. The have a valid access control payload and can be used right out of the box. These credentials also utilize the HID Master authentication keys.

Last edited by carl55 (2017-10-25 16:38:43)

Heru · 2017-10-26 15:19:52

Hi carl55,

Very insightful and thanks for taking time and writing this post

Onisan · 2017-10-27 08:59:14

@carl55
That is a brilliant post summing up the iClass keys.

Heru · 2017-11-02 13:16:30

So I want to learn and begin from the very basic, For example, how do I read and copy iclass card with no encryption?

Anyone give me a hint or breadcrumb to get a working link for the iclass serial protocol doc? I searched all over the net, It seems HID actively working to get it removed from the google search. Unfortunately, the mentioned pdf is no longer available publicly and does not come up even for advanced google search.

Appreciate your input . thanks all

Last edited by Heru (2017-11-02 13:19:21)

iceman · 2017-11-02 13:20:16

this forum has much what you are looking for. Just start reading.

Heru · 2017-11-02 13:38:37

Dear iceman, thank for your suggestion,

Yes, I read whenever I have time, I guess I read more and more

AmmonRa · 2018-01-06 14:49:18

@carl55 I have a question about the different types of cards.

In terms of reprogram-ability, is there any difference between 2) Initialized/Configured and 3) Programmed? I.e. I can auth to both types of cards, but is there any limitation on writing data to these cards?
I assume I can update AA1 on both cards, but not some other blocks. (I guess blk 3 could be updated, but it would be equivalent of making the Elite, meaning I'd need to use the card appropriate Authentication Key to auth with the card in future.)

also, can the CSN of 1) Uninitialized/Unconfigured be changed?

Last edited by AmmonRa (2018-01-06 14:51:25)

carl55 · 2018-01-06 16:44:52

Those two types of iClass credentials are identical with regards to which data blocks can be written.

The initialized/configured cards are programmed at the HID factory with data in blocks 0-5. The programmed cards are sold with data programmed in blocks 0-9.
Both types of credentials allow the end user to program/modify all data blocks (except 0,1,5) provided you have knowledge of the appropriate authentication key.

According to the various Picopass and HID documentation, the CSN (Block 0) cannot be re-programmed once it has been initially programmed at the factory.
That being said, it is certainly possible that an undocumented "backdoor" feature to do this might have been included in the initial picopass chip design. If so, it would probably require a proprietary method that requires the credential to be uninitialized and still operating in its default "personalization" mode. Unfortunately HID stopped selling the unitialized credentials immediately after the iclass technology was hacked and the iclass SE technology was introduced.

AmmonRa · 2018-01-11 12:18:14

Thanks, I have some unprogrammed cards, is there anything useful that can be done with them?
Here is the info on the card state:

hf search
CSN: XX XX XX XX XX XX XX XX
CC: XX XX ff ff ff ff ff ff
Mode: Personalization [Programmable]
Coding: ISO 14443-2 B/ISO 15693
Crypt: Secured page, keys not locked
RA: Read access not enabled
Mem: 2 KBits/2 App Areas (31 * 8 bytes) [1F]
AA1: blocks 06-FF
AA2: blocks 100-1F
App IA: XX XX ff ff ff ff ff ff

Last edited by AmmonRa (2018-01-11 12:19:32)

carl55 · 2018-01-11 22:30:35

Those appear to be uninitialized cards. They are hard to come across.
Those cards can be used to create configuration cards since they are still in "personalization mode" and the Application Limit field in Block 1 is allocating all blocks to Application Area 1. (reference the Picopass datasheet).

Also, since the Application Issuer Area (Block 5) is unwritten, those cards could potentially be used to generate an iClass SE card assuming someone eventually figures out the SIO payload format.

Just be careful if you try and change the authentication key on that card. If you try and change it while it is in personalization mode then you will need to write a "true" value of the desired key and NOT an XOR image of the old key and the desired key. The XOR rule only applies if the card is operating in application mode.

AmmonRa · 2018-01-13 09:10:47

Cool, I've been doing a little reading about SIO, on the HID page about it says "The collection of this information in an SIO ensures the proper coupling of related data - i.e. guaranteeing that one individual's card is not associated with another individual's fingerprint."

Which makes sense with what you said, i.e. if we hard the new keys and algorithms used, we could generate valid iClass SE cards. However, it begs a question: Why would SIO be needed for this?? It seems to imply the system relies on the integrity of the card data. In my opinion, "once you have physical access to the hardware, it's all over.", why doesn't HID just check all the data matches up on the back-end? The only reason I can find is "Portability", but given what happened iClass Legacy, did HID really do the same thing again? (use a master key). Then again, given how dumb using a master key is in the first place, maybe I shouldn't be surprised at least they used a SAM this time to protect the key... but I have a feeling it will be broken sooner or later.

That said, I saw your post about decoding the communication between the SAM and the MCU, you had a program for parsing out interesting data, is that program available? your site seems down... I plan to start looking at the SAM too, unless you already figured it out.

Also, I have another question. I have uninitialized cards from two sources, the one I posted above I can auth with using one of the keys for uninitialized cards, however I am unable to auth with the other card type, using either the key for uninitialized cards key from the reader eeprom or the uninitialized cards key from the OmniKey. Any idea what key it could be using? See the card info below, the only difference from the card in my last post is the addition of the " Crypt: Non secured page" line.

CSN: XX XX XX XX XX XX XX XX
CC: fe ff ff ff ff ff ff ff
Mode: Personalization [Programmable]
Coding: ISO 14443-2 B/ISO 15693
Crypt: Secured page, keys not locked
Crypt: Non secured page
RA: Read access not enabled
Mem: 2 KBits/2 App Areas (31 * 8 bytes) [1F]
AA1: blocks 06-FF
AA2: blocks 100-1F
AppIA: ff ff ff ff ff ff ff ff

edit: it may well be this second card is in fact just a uninitialized picopass card, not iClass at all, where can I find the HID iClass CSN range?

Last edited by AmmonRa (2018-01-13 12:48:23)

carl55 · 2018-01-13 17:01:11

The concept of an SIO was introduced by HID in an attempt to prevent the cards access control data from ever being copied over to a different card.
The SIO is basically a sequence of commands and a long string of encrypted data that has been encapsulated into a standalone data packet that also includes the credentials unique CSN. If that encapsulated data packet was ever copied over to another card, the reader would reject it once it decoded the packet and determined that the encapsulated CSN did not match the CSN of the credential where the SIO now resides.

Regarding your first question - "why doesn't HID just check all the data matches up on the back-end? "
The answer is simple. Backwards compatability. All of the new designs still have to be able to function withing the existing infrastructures. The existing wiegand specification and back end controller designs would not be able to support that type of concept.

Regarding your second question - "you had a program for parsing out interesting data, is that program available?"
That particular software runs on a custom piece of hardware that I built. It does not run on the PM3. It sits on the readers CPU-to-SAM interface and captures the high speed serial ASN1 communication between the two components. Your best (and easiest) approach would be to replicate this setup using a logic analyzer and some custom post-processing software.

Regarding your last question about your uninitialized card key ...
I agree with your suspicion that your card is simply an uninitialized picopass card. However, since you edited out the CSN value I have no way to know for sure. As far as we know, all legitimate iclass cards have a CSN value as follows: XX XX XX XX XX FF 12 E0.
The picopass default keys are shown in Appendix B of the iClass Serial protocol document.

AmmonRa · 2018-01-14 17:47:04

I see, thanks. Backwards compatibility makes sense.

There is only one thing which now confuses me. The CSN of cards from both sources end in "00 12 E0", meaning they are not actually iClass at all, I just assumed the first one was because I am able to auth with it using an iClass key...

Proxmark3 community

Announcement

#1 2017-10-25 13:09:33

Cloning iClass standard security

#2 2017-10-25 16:34:02

Re: Cloning iClass standard security

#3 2017-10-26 15:19:52

Re: Cloning iClass standard security

#4 2017-10-27 08:59:14

Re: Cloning iClass standard security

#5 2017-11-02 13:16:30

Re: Cloning iClass standard security

#6 2017-11-02 13:20:16

Re: Cloning iClass standard security

#7 2017-11-02 13:38:37

Re: Cloning iClass standard security

#8 2018-01-06 14:49:18

Re: Cloning iClass standard security

#9 2018-01-06 16:44:52

Re: Cloning iClass standard security

#10 2018-01-11 12:18:14

Re: Cloning iClass standard security

#11 2018-01-11 22:30:35

Re: Cloning iClass standard security

#12 2018-01-13 09:10:47

Re: Cloning iClass standard security

#13 2018-01-13 17:01:11

Re: Cloning iClass standard security

#14 2018-01-14 17:47:04

Re: Cloning iClass standard security

Board footer