HMAC Authentication - how to secure private keys in flash?

[mikerj]

Is there a method of securing private keys (or any secure data come to that) that need to be stored within, say, flash memory that could be accessible via e.g. debug port or bootloader?

There is a mechanism for protecting the memory against reads through the debug port, but I don't know how secure/reliable this is.  The device has a bootloader built in, and the application has a bootloader, either of which could be vulnerable to exploits, so storing the keys as plain text is a bad idea.  I'm assuming some kind of encryption would be needed, but that leads to the problem of storing the encryption key itself.  The application must be able to gain access to these keys at any time without requiring any kind of external password to be sent.

I've spent quite a long time googling this, but I'm not really getting anywhere.  As always, I might just need to know a phrase to search for and the answer will be obvious.

[Kjelt]

If the internal flash memory can be read out or allow 3rd party to debug than there is no way of making the described situation secure unless you use a dedicated secure microcontroller with its own keylocker.
 
So step 1 will be to make sure there is no way an attacker can read out (part of) your flash memory (unless through great expense like opening the chip).
Step 2 is that an attacker is not allowed to run his own code or debug your code (simply set a breakpoint after the decryption and read the key from RAM).

Without those steps you can stop, its no use.
If you have these steps than there are some methods of obfuscating the keys. Plainly encrypting them is ok but relative easy to hack because as you said there has to be some key somewhere. You can use (part of) the unique ID of the device to make the key only usefull on that device.
You can also use a simple form of whiteboxing (hide the key in a big block of random noise, extractable through a secret algorithm) but to make it very effective it needs large amounts of storage, too large for an embedded device but it is better than nothing I guess.

I guess you have to start thinking about security from the getgo to make it effective. Making an implementation secure afterwards is sometimes impossible or very hard.

[mikerj]

I guess you have to start thinking about security from the getgo to make it effective. Making an implementation secure afterwards is sometimes impossible or very hard.

Thanks for the reply.  This reinforces my suspicions that this is pretty much a non-starter.  The hardware is already defined and implemented as is the application upgrade protocol which includes a basic level of security, but was primarily designed to ensure the firmware image is not corrupted rather than for authenticity.

This is a last second feature request from a customer.  I've never had similar requests for any other customer, and parts of the hardware would be extraordinarily difficult and very expensive to clone (it uses in-house designed and manufactured semiconductor and optical devices) so the risk of this happening is negligible IMO.  If a company could clone these parts, then they would have little problem working their way around any half-assed security that could be added at this stage.

[jeremy]

I am by no means an expert, but all effective key storage I have ever seen relied on PUC (physically unclonable circuits) or write only memory (to the host, it was on-die RAM for the tiny shielded crypto coprocessor). I'm pretty sure this "write only memory" approach is the way Apple does it in their iOS devices.

[Jeroen3]

Assuming you're using regular arm chips running from flash you could do the following:

OTP out the JTAG interface, goodluck working around that.
MPU the entire RAM to no-execute, don't include a bootloader or MPU to no-execute the bootloader in the startup file conditions are not met.
Don't use a "pull pin low to enter bootloader" method, have software jump to a special routine (after receiving a hash from your unique key for example), to reset the chip and set conditions in the backup registers for the bootloader. Make sure the binary you provide is encrypted, scrambled and/or signed.

Or get a chip with a write-only AES key OTP area in the crypto peripheral. These chips are usually capable of running from an encrypted binary.
You might experience customs with these chips.

[Kjelt]

You might think about writing a firmware update bootloader that itself can not be updated (so should be tested thoroughly or you have a brick device in the future), protecting that flash page (where the bootloader resides) and only allowing updates to be stored first in external flash and let the bootloader verify the cryptographic secure authenticity of that firmware (so it is cryptographically authenticated and preferred encrypted so it is tough to see what a valid firmware looks like) before doing the update. The attacker should hack the bootloader to be able to retrieve the key and create its own firmware update. But as said there are always ways around that.

[madires]

Another idea is to obfuscate or encrypt the private key. With encryption the user might have to enter a password/secret to enable the key.

[amyk]

How secure do you want it to be? There's always a way to crack it.
https://www.eevblog.com/forum/chat/hacking-ic's-and-pcb's-for-crooks/

[Jeroen3]

As the rule of thumb for most computer systems dictates: physical access is full access.

Another approach: put the key in the memory protected by the TAMPER pins and memory battery.
If housing is opened or memory battery/capacitor is drained, the key is erased.

[mikerj]

No memory backup battery or external storage is present.  There are no special security features within the (ARM Cortex) micro other than the usual read/write memory protection and the ability to disable reads via the debug port.  I can't rely on an external password to decrypt anything stored within the micro since this isn't part of the authentication protocol which has been defined.  I may be able to enhance security of the application bootloader, but the bootloader in the micro's ROM obviously can't be modified.

Obfuscation (e.g. spread the keys throughout the memory rather than all in one place) and/or a basic level of encryption e.g. using the serial number of the device as a key is doable, but provides only a small level of protection.

From what I can see the customer has two options;  I can either implement the HMAC, but it won't be very secure, or they can drop the requirement.

I'm kind of pleased there wasn't some blatantly obvious solution that I'd overlooked though. 

[nctnico]

Is there a method of securing private keys (or any secure data come to that) that need to be stored within, say, flash memory that could be accessible via e.g. debug port or bootloader?

There is a mechanism for protecting the memory against reads through the debug port, but I don't know how secure/reliable this is.

Usually that is reliable enough to need fancy $$$ equipment like on-die probing to circumvent the security measures (on modern chips that is).

[Jeroen3]

but the bootloader in the micro's ROM obviously can't be modified.

You can run your own bootloader, it's just regular code without special magic, no need to use the rom version.

[mikerj]

but the bootloader in the micro's ROM obviously can't be modified.

You can run your own bootloader, it's just regular code without special magic, no need to use the rom version.

We do use our own bootloader, but that doesn't stop the one in ROM being invoked if one of the micro pins is held at the correct level during reset.

[nctnico]

If the ROM bootloader offers security against reading then you should be OK. I don't see the problem here.

[Jeroen3]

Depending on the brand, there is either a OTP bit disabling any boot-time (of full) access to the bootloader.
Or there is a magic pattern that needs to be put at an arbitrary location in flash.

If both are unavailable, you should seriously reconsider the choice of chip. These are basic protection mechanisms.

[Skashkash]

If the hardware design is completely done, then your options are limited.
If you make a small change, you could add an external authenticator chip.
   They are small (sot-23) , and cheap. I2C or a single wire interface. Does HMAC and SHA256.

   http://www.atmel.com/Images/Atmel-8885-CryptoAuth-ATSHA204A-Datasheet.pdf
 

   

[Kjelt]

If the hardware design is completely done, then your options are limited.
If you make a small change, you could add an external authenticator chip.
   They are small (sot-23) , and cheap. I2C or a single wire interface. Does HMAC and SHA256.
   http://www.atmel.com/Images/Atmel-8885-CryptoAuth-ATSHA204A-Datasheet.pdf

AFAIK this is useless if the internal firmware of the microcontroller is not secure. If this chip would be integrated IN the microcontroller itself it would be an excellent security measure but now the secret keys are in the open in the internal firmware, so what is the point of storing another key or data on an external protected device?

[Skashkash]

The internal keys of the atsha204 are never exposed once the chip is locked.
 You just use it to confirm the MAC to be sure the 32byte master key is the same.

  You can do other operations too, like diversify the keys or secure the boot process.
 http://www.atmel.com/Images/doc8753.pdf

[Kjelt]

Again if a hacker has access to the internal firmware of the microcontroller he can simply modify anything he wants. Such as in the "secured" boot process:

The device combines the digest with the secret to create its own signature, and compares it with the signature passed to it by the boot program. The security device passes a “yes” (comparison succeeded) or “no” (signatures do not match) back to the processor.

And the processor just accepts any answer from the device and continues.

The whole point of a secure boot process is a chain of trust that starts with an uncompromised starting point, in a PC this is the BIOS, in an embedded device it is the bootstrap then the bootloader. In this particular case the TS can not guarantee the validity of the bootloader, a hacker has acces to debug it, to change it so it can be any program.
It is already hopeless from that point onwards.

[Skashkash]

 Just linked the secure boot pdf to show that the chip could be used for other purposes.

 I  thought the OP just wanted to secure the keys used for the MAC/HMAC. As in prevent them from being copied.  The atsha204 would do that, at the expense of some additional hardware and bandwidth (it's slow).

   I agree, if somebody has physical access to an unsecured micro, then they can pretty much bypass anything.
   
  So, if the OP can't make any hardware changes, I don't think they can really secure the keys or the system. 
   
       

 

 

[mikerj]

Just linked the secure boot pdf to show that the chip could be used for other purposes.

I  thought the OP just wanted to secure the keys used for the MAC/HMAC. As in prevent them from being copied.  The atsha204 would do that, at the expense of some additional hardware and bandwidth (it's slow).

   I agree, if somebody has physical access to an unsecured micro, then they can pretty much bypass anything.
   
  So, if the OP can't make any hardware changes, I don't think they can really secure the keys or the system. 

The Atmel device looks to be almost perfect.  Speed is not important within reason, there is handshaking between our device and the host system so it waits until the HMAC operation has completed, and it's only done once after power on/reset.  Even if it took a several seconds it would be fine.

I state almost since the secure hash I require is SHA1 (not very secure any more apparently) which isn't supported by the Atmel devices.  That is a shame because it otherwise seems to be a good fit, and is small enough that a future respin could be considered (space on the PCB is tight, we are using 0201 passives and UCSP packages extensively).

[Kjelt]

Then please enlighten me what is your future security scenario with this device because you said that you could not protect the internal firmware?
SHA-1 has been broken for over  9,5 years. I am not sure what you think you are doing but apparently you are not up to date with current security requirements, and let me assure you that security is one thing you have to do as good as you can get it, or you can just as easily not do it at all.
https://www.schneier.com/blog/archives/2005/02/sha1_broken.html

[gmb42]

SHA-1 has been broken for over  9,5 years. I am not sure what you think you are doing but apparently you are not up to date with current security requirements, and let me assure you that security is one thing you have to do as good as you can get it, or you can just as easily not do it at all.
https://www.schneier.com/blog/archives/2005/02/sha1_broken.html

Not to invalidate your general point, but as noted in the blog entry you referred to,

(although it doesn't affect applications such as HMAC where collisions aren't important)

which I believe is the OP's intended use.

[ovnr]

Then please enlighten me what is your future security scenario with this device because you said that you could not protect the internal firmware?
SHA-1 has been broken for over  9,5 years. I am not sure what you think you are doing but apparently you are not up to date with current security requirements, and let me assure you that security is one thing you have to do as good as you can get it, or you can just as easily not do it at all.
https://www.schneier.com/blog/archives/2005/02/sha1_broken.html

"Broken" in this instance doesn't imply "trivially broken", just "not as secure as it could be".

Let me quote Wikipedia:

As of 2012, the most efficient attack against SHA-1 is considered to be the one by Marc Stevens[34] with an estimated cost of $2.77M to break a single hash value by renting CPU power from cloud servers. Stevens developed this attack in a project called HashClash, implementing a differential path attack. On 8 November 2010, he claimed he had a fully working near-collision attack against full SHA-1 working with an estimated complexity equivalent to 2^57.5 SHA-1 compressions. He estimates this attack can be extended to a full collision with a complexity around 2^61.

So, you know, unless someone's willing to spend a million bucks or so on the problem, it's not a big deal.


Back to the original topic: How secure does this need to be against intrusions? I'd consider finding a good potting compound. It won't stop a determined attacker - nothing will - but it is better than nothing.

[Kjelt]

Not to invalidate your general point  .......... doesn't affect applications such as HMAC which I believe is the OP's intended use.

Yes you are absolutely right. As HMAC it is still NIST recommended till 2030 (or unless some other attack will take place) see link below.

"Broken" in this instance doesn't imply "trivially broken", just "not as secure as it could be".

Yes in that point you are also right. I am only allowed to use the cryptographic functions that will be NIST recommended secure till 2030+ for new products. That is why I reacted so strongly I often see people use old obsolete ciphers because they had some open source software and keep on using it.
But for this particular use as HMAC it is still recommended.

http://www.keylength.com/en/4/