I am working on an embedded device which send/receive data and stored them in ciphertext mode (encrypted mode). Now what's best approach for storing keys (I used ARM CORTEX M series MCU)?

1-Storing keys in the SRAM memory and in each booting sequence, inject keys to the embedded MCU and store them in the SRAM memory. It is best way I think,then when MCU sense penetration (with tamper sensor or ...) it can erased SRAM quickly and reset itself. Disadvantage: if attacker success to pass tampers and access to device, how safe is SRAM memory (against code mining). I can't find any security ability for this memory in MCUs.

2-Generate keys and stored them in the flash memory in programming MCU. MCU flash memory's support CRP (code read protection) which prevent from code mining and with assist of its internal AES engine and RNG (random number generation) engine we can make a random key and encrypt flash memory and stored that random key in the OTP (one time programmable memory -a 128 bit encrypted memory), then in code execution we decode flash memory with RNG key and access to initial key and codes. Disadvantage: Keys stored in a non volatile memory, tampers will be useless and attacker have a lot of time to mine keys.

3-Stored key in the EEPROM memory,combination of 2 above approach, key stored in the non volatile memory but when tampers sense penetration EEPROM is erasable.

I consider LPC18S57FBD208(cortex m3 with 1MB of flash memory, 180MHZ, 136KB SRAM, 16KB EEPROM and a TFT LCD controller which i need to drive a 7" TFT LCD and AES 128 bit crypto engine) for that is there any other better suggestion?


None of those options are particularly better or worse than the others, because they're all very insecure. I'm going with option 4.

  1. SRAM is the most secure place to store keys, but you must never inject them from the outside world. They must ALWAYS be generated within the processor, during boot. Doing anything else instantly invalidates the rest - it's automatically insecure.

  2. Don't store keys in nonvolatile memory, you are correct on this. It doesn't matter if you protect the EEPROM or flash memory from being read. That code read protection fuse is easily reversed. An attacker need only decap (remove or chemically etch away the black epoxy packaging to expose the silicon die inside). At this point, they can cover up the part of the die that is non volatile memory cells (these sections are very regular and while individual memory cells are much to small to be seen, the larger structure can be) and a small piece of something opaque to UV is masked over that section. Then the attacker can just shine a UV light on the chip for 5-10 minutes, and reset all the fuses, including the CRP fuse. The OTP memory can now be read by any standard programmer.

Or, if they're well funded (say, getting those keys are worth more than $1000 to someone), they can just read the memory cells directly with several types of electron microscopes.

To be secure, keys must be erased, not concealed.

  1. No, for the same reasons above.

Now, on to option 4:

  1. Just use encryption. Key distribution is a solved problem. So use that readily available solution. The chip should use its RNG and various other considerations should be made to ensure it has a sufficient supply of entropy available, and the boot loader should boot directly into the program that generates the needed secret key(s), which should be in general purpose registers and moved directly into SRAM, where they will stay until erased.

There is a problem however, which is that nothing except the CPU has any idea what the secret key is. No problem: use public key cryptography. What you DO have stored in the OTP memory is your public key. This key can be read by anyone, you can post it on stack exchange, you can paint it on the side of an oil tanker in 5 foot high letters, it doesn't matter. The wonderful thing about public key cryptography is that it is asymmetric. The key to encrypt something cannot decrypt it, that requires the private key. And conversely, the key to decrypt something encrypted by the public key cannot be used to encrypt something. So, the CPU generates the secret keys, uses your stored public key to ENCRYPT the secret keys, and simply sends it out over USB or RS232 or whatever you want. Reading the secret key requires your private key, which need not be stored, sent, or ever involved at all with the chip. Once you have the secret key decrypted with your private key (elsewhere, outside the chip), you're set. You have a securely transmitted secret key that was GENERATED entirely within the chip, without having to store anything except a public key - which as stated earlier, need not be protected at all from being read.

This process is formally called key negotiation, and every thing uses it. You've used it several times today. There are many resources and libraries available to handle it. Please, do not ever 'inject' keys into anything.

One last thing to mention: All of this is moot because the AES key can be easily recovered using side channel attacks, which sit on the power supply and measure minute changes in current draw and the timing between those changes caused by bits flipping in the CPU as registers. This, combined with knowledge of how AES (or whatever one of the very small set of possible encryption algorithms that could be used) works, makes it relatively easy and inexpensive to recover the key. It won't permit reading the key, but it can narrow down the key space to something ridiculously small, like 255 possible keys. The chip also can't detect it, since it is upstream.

This has defeated AES-256 encrypted boot loaders on 'secure' crypto processors and it's not even that hard. As far as I know, there are no true hardware counter measures to this attack. However, it is the encryption algorithms themselves, and how they require a CPU to flip bits, that is causing this vulnerability. I suspect that side-channel resistant or side-channel proof algorithms will need to be (and hopefully are) being developed.

So as it stands right now, the real answer to how to store a key (or even just use a temporary key) on an embedded device securely is: you can't.

But at least if you generate a new key every time using key negotiation in option 4, then a side channel attack can only compromise the key of an in-use channel, and only if they have a while to monitor the power while it encrypts data. If you frequently negotiate new keys generated internally, this can afford useful amounts of security.

Generate keys, and store them for as short a time as possible.

  • \$\begingroup\$ Really thanks dear Metacollin for clearing me.But my project consist of many readers(contain mcu ) and many target MCUs ,Each reader must able to read any of the targets and any of targets must able to be read by any of the readers.Because of this i think they must agreed with a unique key for transporting data. and based of your answer i think then there are not so much differences between for example LPC18S57 secure cortex m3 and STM32F429 general cortex m4 and even LPC1788 general cortex m3 (cheaper choice),I'm not doing top secret project but i want to do this as secure as i can. \$\endgroup\$ Nov 2 '15 at 17:16
  • 2
    \$\begingroup\$ Your statement that "AES key can be easily recovered" is at least questionable. I understand the principle behind the technique of finding out what happens in the processor, based on its current consumption. However, it assumes that encryption and decryption is the only thing the cpu is working on. However, most of the applications have only 1 cpu which works on a bunch of tasks in the same time. During one block AES encryption tens or hundreds of interrupts can occur which makes it impossible to find out the key, based on current peaks. \$\endgroup\$
    – bakcsa83
    Sep 19 '16 at 20:13
  • 2
    \$\begingroup\$ If the key shouldn't be stored in flash, then the same goes for the code generating the key... just have to translate the op codes to assembler and then you have the key, no matter how intricate the code is. \$\endgroup\$
    – Lundin
    Jan 25 '17 at 12:26
  • \$\begingroup\$ The wonderful thing about private key cryptography is that it is asymmetric. Even though it's clear from your post that you know this, I'll mention it for other readers... s/private/public in the quote above. \$\endgroup\$
    – Radian
    May 5 '17 at 19:45
  • \$\begingroup\$ You may be able to secure a channel between any two devices using method 4, however, without having some form of shared secret, you can't guarantee authenticity of the device with which you are communicating. If your use case requires authentication, you are no better off with a key exchange than you are if you are simply storing a single shared secret in flash. If you need better security, a crypto chip should be used. \$\endgroup\$
    – Greg
    Jun 22 '18 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.