Where do you store/hide your AES keys used for embedded encypt and decrypt?

Question

In a scenario where you have two embedded systems talking to each other, and you want to encrypt/decrypt the data with AES, where/how do you store the AES key in your firmware sources? If I put my aes-128-ecb in my source code of my firmware like this: /* Set up the variables */ 
 uint8_t aesKey[16] = { 
 0x5a, 0x69, 0x67, 0x42, 0x65, 0x65, 0x41, 0x6c, 
 0x6c, 0x69, 0x61, 0x6e, 0x63, 0x65, 0x30, 0x39 
 }; it's out there for everyone that has access to the version control system, and can leak to the outside world. What's your approach?

brianonn · Answer

Definitely don't check any encryption keys into source control. Let's look at the problem: While programming your APIs you see that you needed an AES key for encrypting your shared link. The problem you have is where to get that AES key from and how to securely store it? I have a several thoughts on the matter. If this is a commercial product, and the set of communicating devices is known beforehand and small and limited in the members of the set, then I would come up with a way to allow the end user to enter a shared key into each device at the time of deployment. This would be similar to the way you enter your shared key password into a WiFi router at home. The device is secure and the members of the set that need the key is small and limited in size; If the situation is similar to #1 above, but the device is NOT secured access (i.e. there is public access), or it's impractical due to the number of devices involved, and you want the key pre-set on the device, then you will need to use some secure storage as suggested by many already. The end user can enter the key into secure storage either at the time of deployment or at the time of manufacture if you don't want end-users dealing with keys (of if there is too many to deal with); If you can't or don't want to employ secured storage, then you can also use a random session key for the duration of the connection. Once you get the link up and synchronized, you do a Diffie-Hellman (DH) key exchange with your peer, agree on a shared session key and use that for further communication. You can timeout the shared key if you want, so that a new session key is generated after some time has passed. This limits the usefulness of any session key discovered via cryptanalysis on your link, and your link becomes more secure because of the changing session keys. Doing a DH key exchange can be expensive in memory and time, so it's a tradeoff between how much security you want and how often you are willing to re-generate session key. The amount of security you need for your keys, and the level of risk you're willing to accept depends entirely upon your application. If there's money directly involved, or any other kind of monetary gain to be had, people will be willing to spend time to crack it, and that's when you don't want any keys on insecure storage. If there is a life safety factor, you also don't want anyone to gain access to the keys. Keep in mind that Diffie-Hellman is getting weaker and weaker as computers get more powerful, too. On an embedded system it's tempting to choose DH parameters that are not going to be costly in time, which means a weaker exchange, and one that can likely be cracked on modern PC. It is for this reason that modern DH key-exchanges use an elliptic curve as the field for the generator. Finally, here's a public domain Elliptic Curve Diffie-Hellman (ECDH) library, Curve25519, that is written for x86 architecture but can easily be ported to an embedded processor: https://cr.yp.to/ecdh.html , In fact, this PDF paper https://eprint.iacr.org/2015/343.pdf does just that, describing the author's efforts at porting the ECDH Curve25519 to 8-bit AVR, 16-bit MSP430 and 32-bit ARM Cortex M0. It apparently runs in just 1 second time at 16MHz on an AVR. At that point, both sides of the link have a 128-bit shared key they can use for the session encryption. You can do it twice for a 256-bit AES key, or pass the 128-bit key through a key derivation function to stretch it to 256-bits for AES. Cheers! Brian

Fred27 · Answer

Would a "good enough" solution be to have this in a separate file that's ignored by source control? It would in theory be accessible by anyone who could get hold of the firmware, but that would be hard work and would require someone to have physical access to the devices. Whether this simple solution is good enough depends on what you're protecting and whether it's a commercial product or a home one-off project. Clem's asymmetric key encryption is obviously better but more work.

crjeder · Answer

Please do not use ECB ! Never! Structures which are present in the plain text can be observed in the encrypted data (see Wikipedia ). Use at least CBC with a different (pseudo-) random IV for each new communication. To your question: Depending on your level of "secure enough" I see these two options: 1. Don't include the key in the source code and protect the device from memory readout (like Fred27 suggested) 2. Include (or use micro controller that includes) a safe key storage hardware (Smart Card, TPM, crypto co-processor etc.) Even for asymmetric crypto you need a safe storage because when the attacker gets hold of the secret key (which the device needs) security is compromised. clem57 suggestion unfortunately does not work, because you would need a password to unlock the key ring - you again have the problem where to securely store that secret. For short: every secure solution needs a place to store some kind of secret in a secure manner. The advantage of asymmetric crypto is that you can easily can easily create new (session) keys (e. g. with Diffie-Hellman key exchange) in case of a compromised key.

Workshopshed · Answer

I normally store any keys outside the source control and read them from file on startup. But Fred27 approach is a good one too. If you are designing your own hardware then you can get specialist hardware to do the job see CryptoMemory or https://www.maximintegrated.com/en/products/digital/memory-products/DS28C22.html

crjeder · Answer

For DH you have to solve the Man in the Middle problem: You have to find a way to idetify your device. That again wolud require a safe place to store some kind of secret. Long story short: If an attacker can read the memory (flash or ram) then you can not secure the communication.

BigG · Answer

would something like this provide a workable solution ATECC508A

Jan Cumps · Answer

Thanks! I've been dealing with trusted CA certificates - including chasing the signature of our CFO and submitting the board structure of my company to one of those certification authorities (I work for a rather big multinational and by the time I had all doco submitted we didn't need the certificate anymore).

Jan Cumps · Answer

I just found this service from Maxim: they program the keys in-factory for you: PROGRAMMING SECURE AUTHENTICATORS For end application use these authenticators require programming of keys, data, and device settings. While device evaluation kits provide this capability, Maxim also offers device programming products and services to support high volume needs. Secure Factor Pre-Programming Our factory pre-programming service securely installs your keys and data after which we ship the parts according to your instructions.

Where do you store/hide your AES keys used for embedded encypt and decrypt?

Top Replies