3
$\begingroup$

I am working on some security features that should be executed by the firmware of a consumer device whose communication to a server must be secure.

Any exchange of data is based on symmetric cryptography, with keys created by "Elliptic Curve Diffie Hellman Key Agreement".

For reasons of cost, a dedicated hardware security module (HSM) was omitted. Instead, all cryptographic algorithms are executed within the board firmware, additionally supported by powerful hardware accelerators directly on the MCU to handle AES and ECC.

  • All RAM and used flash memory is internal to the MCU.
  • JTAG interface is disabled.
  • No external memory is used.
  • Beside of executing directly within the firmware, all cryptographic algorithms are state of the art.

The open question is, where to store sensitive keys:

Is it acceptable from a security point of view, to keep private and symmetric keys in the MCU's flash memory, since there is no way to penetrate from outside, except perhaps the monitoring of power consumption as a side channel attack? To be more secure, all these keys are additionally encrypted by a unique device key, to be created upon factory startup. However, I feel, because this device key is also kept solely within internal flash that this gives only very little additional security.

What considerations should be considered to verify whether such an approach will fulfill standard security requirements or not? What would be the right way without using a dedicated HSM?

$\endgroup$
  • 1
    $\begingroup$ This question is similar to several questions asked here before, so I will throw in my two-cents worth and state again that the only safe way to store keys is on one's own person via a memory stick or some little device that you always keep with you and are diligent enough to never lose or misplace. Of course someone could rob you of your keys but then in that case you really wouldn't need cryptography for security, you would need a gun ! ;-) $\endgroup$ – William Hird Jun 6 '17 at 23:08
3
$\begingroup$

With your constraints, there is no way to safely store keys, and this is from a hardware perspective. If they exist in memory, there is pretty much a way to get them out. If you have a way to update the firmware, I can get something in there to get the keys out. It would have cost less than a penny to add a hardware core if you had a custom IC. (I go over this with the B-school boys all of the time as a breach costs more than throwing hardware in the IC and it's always a software issue that causes trust issues)

When I make a hardware core, the key region is write only (e-fuses), so once they are written, there's no way to get the keys out because hardware does not physically exist.

Assuming that you are completely in the FLASH, the way to get your keys is however you chose to update the firmware (unless you don't verify it). I've also never seen a JTAG interface that couldn't be re-enabled because we that to program the ICs on the wafers before dicing.

Also, I can decap your IC and FIB on a connection to read out the FLASH anyway. (takes about 4 hours in the university lab)

I just cannot think of a way with your constraints to hide your keys in a way that I couldn't get them out.

$\endgroup$
  • $\begingroup$ With decapping does it make it harder if the memory is volatile? Can you decap an IC while it is powered? This would add complications to the supply chain (keep memory IC powered constantly after the key is read) and may not add any extra hurdles. $\endgroup$ – daniel Jun 7 '17 at 21:23
  • $\begingroup$ @daniel of course, but it just changes how you do things because the information is there in the flash, in this case. You could decrease the diffusion current of a device by supercooling it, so even if you have a DRAM cell via trench in the silicon, you could run it, kill the power and read out the data. You can actually do this just with a camera because transistors make a little "flash" when they switch, so you just need the correct type of camera and you can see the electricity move through the IC. $\endgroup$ – b degnan Jun 7 '17 at 23:20
4
$\begingroup$

If it can be stored, it can be recovered.

Consider the unsettling fact that even if you were able to select a hard-to-discover location, since you are using a consumer device, at any point in the supply chain (HDL design, whoever makes your microcontrollers, etc) someone could have compromised the device long before you get to designing the firmware. You are wise to observe the likely-negligible extra security obtained.

As others have mentioned, reactivating JTAG or UART ports is not that big of a deal, and I can just crack open your device and dump out the flash memory anyway. Understanding firmware is easier than ever. You should assume your adversary has access to IDA Pro, understands firmware emulation, and is willing to drop some cash on an EEPROM or flash reader. (This is what I do, anyway.) Being clever may slow an adversary down but it can provide no guarantees.

Even HSMs are not necessarily secure. It's turtles all the way down.

$\endgroup$
2
$\begingroup$

I believe your problem is more related to electrical engineering since you need a way to physically store sensitive data. Cryptography alone cannot protect against physical attacks that aim to recover information that is stored in plain. It does however ensure that encrypted communications cannot be fiddled with (MITM, replay, etc.) and that (properly) encrypted data is safe at rest.

Anyway, going back to your request, provided the customer may open up the device to have physical access to the PCB, it is possible that some chips (eg. memory) may be "monitored". For instance, by looking for data transactions from/to the chip by using an oscilloscope or other means, it may be possible for the customer to retrieve some information (assuming chip-to-chip communications are in plain).

You should never assume that the hardware is safe. Always consider the possible outcome in which the user may gain access to it and have full control over its components.

One thing you should always keep in mind is that security through obscurity is bad (if you intended to use it). In short, you should never rely on secrecy of design as a security measure. It may however be used in addition to another (proper) guarantee, such as encryption. Note that it does not mean that you have to publish all design details; instead, even if they are "leaked", your system should still be safe.

$\endgroup$
  • $\begingroup$ I'm completely aware of that issues. But what is the recommended way to store keys? Somewhere the material must be stored...In my case the CPU and the memory are within one chip, so there is no data/address bus to listen on. $\endgroup$ – michael Jun 6 '17 at 11:36
  • $\begingroup$ @michael depending on the CPU you use, you may be able to ask the manufacturer to embed some data within a "protected memory" that lies inside the CPU die. Such a memory may be hard to access from the outside. ymmv $\endgroup$ – Dreadlockyx Jun 6 '17 at 16:19

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.