[Adam Laurie] spent time tearing into the security of the SAM7XC chip produced by Atmel. Even if he hadn’t found some glaring security holes just reading about his methodology is worth it.
The chip is used in a secure RFID system. The chip is added to the mix to do the heavy lifting required when using encryption. [Adam] grabbed a couple of open source libraries to put it to the test. The firmware is locked down pretty tight, but his explorations into the content of the RAM yield a treasure trove of bits. After investigating the sample code for the chip he’s shocked to learn that it uses RAM to store the keys at one point. The rest of his journey has him dumping the data and sifting through it until he gets to the “Master Diversification Key”. That’s the big daddy which will let him decrypt any of the tags used.
He reported his findings to Atmel in September of 2011. Their response is that they have no way of protecting RAM from exploit. [Adam] asserts that the problem is that the sample software wasn’t designed with the vulnerability of RAM in mind. The keys should never be stored there specifically because it is vulnerable to being dumped from a running system.
Keep it stored in the program memory itself?
Does progmem stored data get shifted into sram when it is being used?
Very nice article – but left an important question unanswered.
What WAS the code doing there after flash erase – was it copied from flash by the hardware OR by the software ? Was it complete or just partial ? Is this a hardware or software flaw ? I.e. could this affect ANY software within these chips – even if you carefully clear your keys from sram ? There are just too many unanswered questions …. Hmm time to find me one of these micros.
It seems to me it’s a coming together of circumstances. I don’t know the exact specifics of this crypto engine, but there are a few assumptions for this to work. The program must copy the data to RAM for whatever reason, and leave it there. Moreover, the erase funtionallity of this ATMEL chip is probably broken, or assumed that after an ERASE you give the chip a RESET command as well, which will clear the SRAM (probably). Otherwise, a good memory initilisation routine from the compiler should clear memory (for e.g. copy data and fill with 0’s).
For me it seems rather strange that they need to put these keys into SRAM, because you would say on an ARM based system (where flash and program memory share the same bus, so only an address seperates the two) can easily read data from FLASH, put 1 byte on the stack, write it into the crypto, and go to the next byte.
Rather strange. Ah well, I guess the software on this controller was secure if they assumed one can’t access the FLASH or RAM at all without an erase.
How do I select the aids free version of every card in my life?
$ desfiretool.py select 000000 aids version free
Hahahahaah
I guess you could just pass them in the registers, ARM have tons of them. How hard would that be to read ? But yeah, crypto keys ever hitting RAM is absolutely stupid.
nevermind, actually you can ‘just’ read the registers by jtag too, that was a moment of weakness. Oh well….
on second thought.. why would you even keep the key in flash? Isn’t it supposed to stay in the crypto coprocessor in permanent storage forever without any ability to read it back?
turns out the correct procedure is flash -> cpu register -> write-only coprocessor register (mmio), never hitting RAM and clearing the cpu register immediately afterwards. So it all depends on how secure the flash security is.
and furthermore, since you can’t disable JTAG on this chip via a fuse, you’ll be able to read the key in 100% cases if you gain JTAG access.
I take that back.. there is a security fuse that disables jtag. But if you assert ERASE at just the right time, you’ll be able to get the key from a register via jtag afterwards. Sure, almost no chance but it is a way.
sooo … anyone tried master on a different one? is the master global?
What about a hardware defense? After programming, give the jtag pins a HV jolt to fry the jtag io pins. Just short vcc and gnd to prevent a rise in supply while zapping.