Wednesday, February 13, 2008

Atmel CryptoMemory AT88SC153/1608 :: Security Alert

A "backdoor" has been discovered by Flylogic Engineering in the Atmel AT88SC153 and AT88SC1608 CryptoMemory.

Before we get into this more, we want to let you know immediately that this backdoor only involves the AT88SC153/1608 and no other CryptoMemory devices.

The backdoor involves restoring an EEPROM fuse with Ultra-Violet light (UV).  Once the fuse bit has been returned to a '1', all memory contents is permitted to be read or written in the clear (unencrypted).

Normally in order to do so, you need to either authenticate to the device or use a read-once-given "secure code" as explained in the AT88SC153 datasheet and the AT88SC1608 datasheet.

For those of you who are unfamiliar Atmel's CryptoMemory, they are serial non-volatile memory (EEPROM) that support a clear or secure channel of communications between a host (typically an MCU) and the memory.  What is unique about the CryptoMemory are their capabilities in establishing the secure channel (authenticating to the host, etc). 

Figure 1:  AT88SC153 magnified 200x.


Figure 2:  AT88SC1608 magnified 200x.

These device includes:

  • High-security Memory Including Anti-wiretapping

  • 64-bit Authentication Protocol

  • Secure Checksum

  • Configurable Authentication Attempts Counter

  • Multiple Sets of Passwords

  • Specific Passwords for Read and Write

  • Password Attempts Counters

  • Selectable Access Rights by Zone

Figure 3:  Commented AT88SC153.


Figure 4:  Commented AT88SC1608.

Section 5 of the datasheet labled, "Fuses" clearly states, "Once blown, these EEPROM fuses can not be reset."

This statement is absolutely false.  UV light will erase the fuses back to a '1' state.  Care must be used to not expose the main memory to the UV or else it too will erase itself.

We are not going to explain the details of how to use the UV light to reset the fuse.  We have tried to contact Atmel but have not heard anything back from them.

Reading deeper into the datasheet under Table 5-1, Atmel writes, "When the fuses are all "1"s, read and write are allowed in the entire memory." 

As strange as it reads, they really do mean even if you have setup security rules in the configuration memory, it doesn't matter.  The fuses override everything and all memory areas are readable in the clear without the need for authentication or encrypted channel!  The attacker can even see what the "Secure Code" is (it is not given out in the public documentation, nor with samples).  Atmel was even kind enough to leave test pads everywhere so various levels of attackers can learn (entry to expert).

Our proof of concept was tested on samples we acquired through Atmel's website.  Atmel offers samples to anyone however they do not give out the "Secure code" as mentioned above. 

  • The secure code of the AT88SC153 samples was "$D_ $F_ $7_". 

  • The secure code of the AT88SC1608 was "$7_ $5_ $5_".

We are not going to show you the low nibble of the 3 bytes to make sure we don't give the code out to anyone.  This is enough proof to whoever else knows this code.  That person(s) can clearly see we know their transport code which appears to be common to all samples (e.g. All die on a wafer contain the same secure code until a customer orders parts at which time that customer receives their own secure code.).  A person reading this cannot guess the secure code in because there are 12 bits to exhaustively search out and you only have 8 tries ;).

Of all the other CryptoMemory products, only the AT88SC153/1608 has this backdoor.  We have successfully analyzed the entire CryptoMemory product line and can say that the backdoor doesn't exist in any other CryptoMemory part.  None of the CryptoMemory parts are actually as "secure" as they make it seem.  The words, "Smoke n' Mirrors" comes to mind (It is almost always like that).  In this particular category of CryptoMemory, there are two parts, the AT88SC153 and the larger AT88SC1608.

Thus the questions- 

  • Why has Atmel only backdoored this part (NSA for you conspiracists)?

  • Who was the original intended customer supposed to be?

  • Was the original intention of these devices to be used in a product that used some kind of cryptography?

  • If the above was true, was this device originally intended to be a cryptographic key-vault?

All these questions come to mind because the backdoor makes it so easy to extract the contents of the device they want you to trust.  Some of you may be familiar with the GSM A5/1 algorithm having certain bits of the key set to a fixed value.

Judging by the wording of the documentation, Atmel gives the appearance that CryptoMemory are the perfect choice for holding your most valuable secrets.

Give us your thoughts...


  1. [...] FlyLogic Engineering har precis publicerat att man hittat en bakdörr i ett par av Atmels CryptoMemory-kretsar, mer specifikt AT88SC153 och [...]

  2. Aloha!

    Thanks for a very interesting posting - this does really look very strange.

    If all CryptoMemory devices had this problem, then it could really be simple stupidity, not malice/intent. But since it's only two devices in the family one really starts wondering what caused this.

    Did somebody order this functionality for their devices, or did somebody order Atmel to do this to devices others would buy? Major tinfoil time... ;-)

    Thanks also for posting a heads up on Kryptoblog. I've posted about your discovery (in Swedish - naturally) here:

    Another thing I've yet to post about which you might not (or you have) seen is that there are some new attacks on the KeeLoq. This time it is the implementation. More specifically a side-channel attack on the freq hopping. There is a nice paper about it on IACR:

  3. We have analyzed many of the Keeloq devices too. Their geometry is somewhat ancient (~1.2um or 1200 nanometers for PC guys who love to know the size of their Intel or AMD).

    We will write-up about Keeloq sometime soon. Time is a problem currently.

  4. Another thing I’ve yet to post about which you might not (or you have) seen is that there are some new attacks on the KeeLoq. This time it is the implementation. More specifically a side-channel attack on the freq hopping. There is a nice paper about it on IACR:

  5. It is possible to listen to most of the keeloq parts and capture a few transmissions to then resend to the receiving unit.

    The specification speaks of a window of opportunity for variations of the seed but what happens if the button is continuous pressed on your garage door opener or your car alarm?

    You return to find you can't get in because your seed is out of the window?

    Very small tests appear to show that most of the units from Genie for garage doors do not seem to use this window to make sure this exact scenerio never plays out!

    There is so much to discuss on Keeloq. Perhaps we'll do a more thorough evaluation of it soon and do a write-up.

  6. [...] nos cuentan en Kriptopolis y en el blog de Flylogic Engineering ( Ver la entrada ) el estado de los fusibles que establecen la calve de la encriptación puede ser revertido, o [...]

  7. The specification speaks of a window of opportunity for variations of the seed but what happens if the button is continuous pressed on your garage door opener or your car alarm?

  8. Exactly, in brief tests done in the past, we have found most car and garage door openers do not enforce the window!

  9. Hello
    Very interesting blog :) :)

    question to @Admin :

    I wonder is possibly to glitch some atmel secure chip uses clk if it switch to internall PLL generator ?

    For example when the chip power up and user reset is executed almost secure chip programs switching to internall PLL if we hit uses vcc that function CPU work still in externall and we can glitching uses clk ?

  10. ASIC,

    Anything is possible when there is a motivational factor involved. When you glitch a semiconductor, you are dropping the internal VCC to a level that has increased the internal propagation delay across the gates.

    As VCC drops, the maximum clock frequency of the device commonly drops as well because of the delay growing as explained above. If you increase the clock frequency you can close the gate of a latch before the proper data has been set. You do not always need to touch the clock and even if you are, there is a good chance it was not the reason the glitch was successful. Most glitches are effective at the with-in limits clock frequency of a circuit.

    If you notice, many of the devices out there today have glitch detectors inside however, they take time to process the current VCC level and the glitch will happen much quicker than the detectors can detect. The detectors also need a tolerance before determining a fault is actually happening or the end-user may find themselves seeing abnormal behavior in their software model.

    Many of the detectors also leave the decision up to the software model as well rather than taking action on their own.

    In essence, glitch protection is an on-going battle and as the fabrication process shrinks, the window between a '1' and a '0' is getting smaller. This allows higher frequencies because the switched levels are smaller but also welcomes glitching problems.

    Ironically, people do not seem to glitch with high voltages. Most of the chips today will glitch very easilly with a high-voltage glitch but tend to get hot and possible SCR latchup can happen (auto-destruct if you don't catch the device in SCR latchup!).

    Good luck!

  11. Thanks for good technical answer :)

  12. I work for a company that develops a smartcard o/s, and I've always wondered about exactly how secure the hardware platform really is. I think it would be awesome if you could document a teardown of a proper smartcard chip. It'd be interesting to see all the measures that the manufacturers go to to ensure security. Just an idea ;)

  13. It is a problem. They should try to make it more secure for the users.

  14. Joseph WhiteheadMay 16, 2009 at 4:36 PM

    The most secure methods would not exactly be friendly to mass manufacturing. Until someone comes up with a away to lay specific atoms at the nanometer level one-by-one and then tie security into exact relative positions/angles... hehe good luck with that kind of accuracy and precision.

    Even then, you could just remove atoms one at a time to read out the device's exact layout. There's always going to be a race to make better security and break it.

    One thing that would be interesting is making a chip with decoy logic. Enough of this would at least make it annoying to find the real function. Extra points if the random, almost undetectable variations in devices affect the 'key'. I'm thinking vertical positions and analog logic. Unfortunately, I think it would need to always be at a specific temperature? Would even the age of the device change the key over time? Anyone with experience that can say for sure?

  15. The chip locks up after 8 tries and their are 12 missing bits. So I need 512 chips to break the code and 256 on average.

  16. Cryptomemory not actually encrypted! Hold the press!

    Exactly how many companies have tried to get away with calling access to unencrypted data after whispering a secret to the controller "crypto"?

  17. I will immediately grab your rss as I can not to find your e-mail subscription link or e-newsletter service.
    Do you've any? Kindly allow me know in order that I may subscribe.

  18. What's Taking place i am new to this, I stumbled upon this I've
    found It absolutely useful and it has aided me out loads.
    I hope to give a contribution & aid different users like its helped me.
    Good job.