Cracking A SAM7XC Cryptographic Coprocessor


[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.

13 thoughts on “Cracking A SAM7XC Cryptographic Coprocessor

  1. 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.

  2. 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.

      1. 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.

          1. 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.

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.