Building an iClass Cloner


May 21, 2014

By Jay Davis, @jaymaster2000

We have been investigating RFID access control security and the models typically implemented by businesses in Australia. The iClass line of devices developed by HID are an interesting subject as they are commonly used throughout Australia (and globally) and have been proven to have security flaws. We conducted some research to see if we could create a covert cloning device for use in our engagements. Read on for more details of our successes!

The physical access control sector has not moved as rapidly as it could have despite the array of good security frameworks and cheap electronics that exist today. As previously mentioned, popular systems for managing physical access are the Prox and iClass products from HID. It has been known for some time that Prox employs no security model and is very easy to compromise with off the shelf hardware. In an attempt to fix these issues, HID released the iClass range of devices, which employ “enhanced security through encryption and mutual authentication”. This particular functionality has already been broken through implementation of a common authentication key for standard security and the ability to dump the high security key table from readers with the built in programming port.

iclass_3_smallThe programming port is highlighted above in red.

Knowing that the new security model for the iClass devices has flaws, we wanted to investigate the feasibility of creating a covert tool that would allow us to clone iClass credentials. Our brief in these efforts was “could anyone with some spare time on their hands time put together a covert device with a few dollars and have free rein of a victim’s workplace or home?”.

We acquired an iClass RW300 (pictured above) and associated protocol documentation. While the bulky nature of the device wasn’t ideal for the type of covert device we had in mind, we decided to first work on a proof of concept (PoC). After reading the documentation and interacting with the device we managed to create a functional PoC that could read standard security credentials, this was a good start and meant that we could proceed with further design of the device and underlying code.

From here we came up with the following specifications for our covert device:

  • Clone iClass standard security credentials
  • Clone iClass high security credentials
  • Dump iClass high security keytable from reader using the programming port
  • Clone Prox credentials
  • Be usable in public without suspicion

As we already had access to a proxmark3, it seemed plausible that we could create something to clone iClass Standard Security and Prox in the one package, with a view to move onto high security and key dumping for iClass in the future. From here we created a block diagram:

block_diagram_2After considering the hardware we would need to enclose our device we settled on something quite common here in Australia…

boxThis seemed like a valid option for the following reasons:

  • It would have space to house components and power system
  • If it can hold a bottle of wine it will be sturdy enough for our requirements without adding too much weight
  • It is not something that anybody would be suspicious of

As noted in the block diagram, in order to interact with the device and maintain it’s disguise we decided that interaction though SSH over WIFI would be an acceptable solution. This allows an attacker to surreptitiously monitor and control the device.

After acquiring the required hardware, we mounted the devices on to an internal chassis.

internalsFrom here we worked towards completing a basic version of the code. At the time of writing, we are able to:

  • Read iClass standard security credentials
  • Read iClass high security credentials providing you have the keytable loaded into the reader
  • Read Prox credentials
  • Write all logged Prox and iClass credentials

phone_screens

We’re currently working on dumping the high security keytable from the programming port of a reader and implement this functionality into our device.

On top of the device specific security issues outlined above, access control devices are too often implemented in conjunction with a model that doesn’t account for hostile attackers able to bypass perimeter controls.

The conclusion drawn is that physical access control needs to improve both from technology and implementation standpoints. Entities need to make sure that proper implementation of physical access is addressed as well as mitigating factors for assets if access is bypassed, layered security if you will.

Until some of these issues are resolved, be suspicious of people wandering around your local CBD with a wine box under their arm and a phone in their hand…

The PoC code can be found here

 

Leave a Reply

Your email address will not be published. Required fields are marked *