A Better Way To Hack IClass RFID Readers

iClass is an RFID standard that is aimed at better security through encryption and authentication. While it is more secure than some other RFID implementations, it is still possible to hack the system. But initial iClass exploits were quite invasive. [Brad Antoniewicz] published a post which talks about early attacks on the system, and then demonstrates a better way to exploit iClass readers.

We remember seeing the talk on iClass from 27C3 about a year and a half ago. While the technique was interesting, it was incredibly invasive. An attacker needed multiple iClass readers at his disposal as the method involved overwriting part of the firmware in order to get a partial dump, then patching those image pieces back together. [Brad] makes the point that this is fine with an off-the-shelf system, but high-security installations will be using custom images. This means you would need to get multiple readers off the wall of the building you’re trying to sneak into.

But his method is different. He managed to get a dump of the EEPROM from a reader using an FTDI cable and external power source. If you wan to see how he’s circumventing the PIC read protection you’ll have to dig into the source code linked in his article.

18 thoughts on “A Better Way To Hack IClass RFID Readers

      1. Nothing.

        I was thinking of the access controller. If the reader is “transparent” (only routing APDUs, which means a normal ISO card is used, not some proprietary technology using a malformed protocol) then the secure node can be transferred in a secure room.

  1. The bigger issue that I see here is not trusting other peoples security. The reader is perfectly secure under the assumption that the read protect functionality of the PIC18F is secure, but he managed to find a flaw that allows him to bypass that almost trivially, which I believe is a first for the PIC18F series. The only other version I know of is the work done by bunny who decapped the chip and used UV to reset the bits ( http://hackaday.com/2011/06/27/bunnies-archives-unlocking-protected-microcontrollers/ ). There are other implementations that so far have been proven to be reliable (ex, debit card terminals), although there is something to be said that putting anything with secrets mounted on the outside of your building is just asking for trouble.

    1. He only reads the volatile RAM of the PIC: when a card is read the keys get loaded from the EEPROM into RAM for verification, and are not wiped afterwards. I don’t think he can read the program this way.

    2. It gets more site-traffic and job offers if you say you broke an algo or protocol though. You switch up keys and proper OCD and it’s ‘secure’ again..

      You haven’t earned your stripes in RFID RE till legal teams and engineers from companies like Phillips, Megamos, and Hitachi call your home or office telling you what’s going to happen if you publish your papers. This is why when you google for RFID research on the more complex challenge-response systems all you’ll find is some articles on a college being shut-up years back after reversing the GM system..

      1. So freaking true, Why no one holds these companies accountable like any other company claiming to be a security company is beyond me. The technology is certainly pervasive enough, more companies have it then anti-virus and they would die overnight if they exhibited remotely similar behavior. Dumbfounded.

    3. I looked at the code and as crazy as it sounds it looks like PIC is EXECUTING instructions if you push them on the bus pins in programming mode :o Register indirect addressing mode to be exact. He resets File Select Register, then increments it and reads data pins.
      This is an extension to Milosch Meriac attack. His attack wrote to memory, this one writes to FSR register and results in this register exposing addressed data on the data bus ???

      Someone who knows PIC should look at it, I probably got it wrong.

      1. If I got it right, it works something like this: This PIC has a Boot Block – a 512 bytes of program space reserved usually for boot loaders. Now, since unlocking security fuse bits in the firmware (for retrieving locked firmware) is not possible without re-programming the device, what he did is wrote a small firmware that he programmed just into that boot block. That small firmware is in appendix B (if I remember correctly) in Milosch Meriac’s attack PDF document. So, now when he resets the PIC that little firmware he wrote reads contents of Flash memory (firmware) and dumps it onto the UART port.
        The PIC reads itself and dumps it into the UART… brilliant!

  2. FYI – HID has recently redesigned their iClass readers and they now uses a newer microcontroller that is not vulnerable to this type of attack. Anyone trying to exploit this vulnerability will need to use the older Revision A iclass reader.

  3. First things first: iClass is NOT a standard. It is a proprietary technology on a commonly used frequency for RFID. Nothing standard about it from any definition. Hence which is why there was no peer testing and was blown to bits when tested for common security concepts that are generally accepted:

    Second: You cannot put all of the security completely in the card. Anything in the card’s chip that is used for authentication needs to be validated by something outside of it. In high frequency cards, this happens in two places a) a master key in the read and b) a card number previously bound to a card/person that is typically in a controller. Readers are generally passive in this respect with exception to “a”. This is a major design-level flaw of physical access control systems – storing mater keys in hardware that is generally not designed to strong principles as you might an HSM. This is changing, slowly, starting with the US federal gov PIV program leveraging PKI and calling an OCSP, though very challenging and expensive at the moment.

    Third: Comment that HID has redesigned iClass readers to use a new microcontroller and is not susceptible to this attack. Only some versions are redesigned, some of the same continue to be sold for compatibility reasons. Customers will need to actively transition to these new readers for the benefit, many cannot – yet. Also, there has been no peer testing to validate that this attack, or another, is not possible. One of the challenges with this vendors approach – security through obscurity.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.