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.
Subscribe for weekly videos
Nice to see someone else showing that another so-called “high-security” product isn’t as high-security as the manufacturer claims.
the solution is simple: don’t put the security in the reader, and use really secure cards, chips and protocols.
proprietary and obfuscated security has always been sh*t.
What makes you believe the card is harder to hack?
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.
well, we’re the same, really
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.
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.
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..
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.
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!
That was Milosch code. This one doesnt write any code into the device, only manipulates FSR register.
Yep, you are right. I was admiring the “boot block attack” when I was writing the reply :-)
which is also briliant, BTW :)
this is probably one reason for the AVR to reset all ram to 0 upon start-up
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.