TLS private key storage for embedded systems. Are there any best practices?

Question

I am looking for best practices regarding TLS private key storage for small single chip embedded systems, such as Cortex-M MCUs, with monolithic firmware stored in internal flash. Most recommendations seem to be very PC-centric, and in most cases those PC-centric recommendations don't even care to protect against physical access. I guess many assume the PC is locked away in some server room, but that is an assumption which does not hold true for embedded devices.

Also, user password entry is not an option for embedded systems, as it has to work without user interaction.

I have so far identified two basic approaches:

1. Store private keys in external security chip. This basically protects the private key from plaintext access. But as far as I can tell, it does absolutely nothing to stop an attacker from using the private key by accessing the security chip. Either by some exploit in the MCU firmware, or by physical access to the security chip.

2. Store the keys in internal flash memory of the MCU, and blow fuses to disable the external debug interface. Set up the MPU of the Cortex-M so that only privileged parts of the MCU firmware can access the memory regions where the key is stored. This would seem to provide good protection against physical access, but an exploit in the privileged part of the firmware might result in plaintext access to the key.

It is not obvious to me that either of these two approaches is better than the other. Are there other approaches? Are there any recommended best practices specific for embedded systems like this? Preferably ranking different approaches and their pros and cons.

Answer 1

I was hoping there were best practices available from some reputable source. Lacking that, I am posting this as a suggestion, and welcome any input on it.

Methods for secure key storage in embedded devices depends on the threat scenario.

Threat scenario 1: Both remote and physical attacks.

Threat scenario 2: Only remote attacks.

------------

The best solution in both scenarios

• Single-chip MCU with built-in cryptoprocessor and secure key storage, such as PUF-RAM or tamper-resistant write-only flash accessible only by the dedicated cryptoprocessor.
• Any firmware loaded from off-chip must be signed.
• Ideally no external RAM.
• Use MPU to restrict access to crypto functions to privileged sections of the firmware.
• Blow the JTAG debug fuse if defense against physical attacks is required

The second-best solution, scenario 1 only

• Single-chip MCU, with external security chip.
• All communication with external security chip is encrypted using a device-specific key.
• Any firmware loaded from off-chip must be signed.
• Ideally no external RAM.
• Use MPU to restrict access to crypto functions to privileged sections of the firmware.
• Key for encrypted communication with external security chip is stored in on-chip flash.
• Blow the JTAG debug fuse.

Con: The most complicated to implement, and any bugs in the implementation may compromise security. Performance may suffer because of the additional encryption.

The second-best solution, scenario 2 only

• Single-chip MCU, with external security chip.
• Any firmware loaded remotely must be signed.
• Use MPU to restrict access to crypto functions to privileged sections of the firmware.
• No need to disable JTAG. Greatly simplifies maintenance.

Con: No defense against physical access. The unencrypted interface of the external security chip is wide open to physical attacks

The third-best solution, both scenarios

• Single-chip MCU.
• All firmware loaded from off-chip must be signed.
• Use MPU to restrict access to crypto functions to privileged sections of the firmware.
• Private keys stored in on-chip flash.
• Blow the JTAG debug fuse if defense against physical attacks is required.
• Ideally no external RAM if defense aganst physical attacks is required.

Con: A successful attack yields the plaintext keys, rather than indirect access to keys.

Pro: Ability to add support for new crypto algorithms by firmware update, as security standards evolve.

------------

Explanations

Two lines of defense against remote attacks

The two lines of defense against remote attacks are identical in all four solutions above.

1. Bug-free monolithic main firmware. Remote attacks are only possible if there are bugs in the firmware.
2. Bug-free privileged part of main firmware. Even if the main part of the firmware is compromised due to a bug, the MPU provides a partial second layer of protection for the privileged part of the firmware, and the private keys.

This is where your security focus must be, regardless of hardware solution.

External security chips

Dedicated devices with built-in secure key storage and cryptoprocessor capable of performing all required ECC, RSA and AES functions. Typically connected to your MCU using I2C or SPI

These cannot really be said to add any additional lines of defense against attacks. A better description is to say that they change the outcome of a successful attack. Without a security chip, a successful attack yields the plaintext keys. With a security chip, a successful attack yields indirect access to use the keys. The latter is a marginally less damaging outcome.

But ask the cable-TV industry what they think about this kind of protection. Indirect access to keys is sufficient for widespread cable-TV piracy by having the keys indirectly accessible via internet.

Security chips also come with a significant drawback: They expose an easy to access hardware interface to use the keys, actually making physical attacks very easy. The exception is external security chips with support for encrypted communication with the MCU, and which even over that encrypted interface does not allow reading the private keys. But that creates a new key-storage problem in the MCU.

MCU internal hardware cryptoprocessor and protected key storage

Provides the same advantage as an external security chip, but without the physical attack weakness or performance issues.

Physical attack vectors, and their defenses

Ranked from easiest to hardest attack vector.

1. Serial interface to external security chip.
   • Use MCU-internal cryptoprocessor and key storage instead.
   • Use external security chip with encrypted interface and device-unique encryption key.
   • Use no security chip, and store private keys directly in MCU-internal flash instead.
2. JTAG debug interface.
   • Blow JTAG fuse.
3. External boot flash.
   • Verify signature or hash of loaded firmware.
4. External RAM.
   • Use only internal RAM.
5. Silicon probing.
   • Anti-tampering hardware.
   • PUF-RAM.

Answer 2

I have relevant work experience in that regard.

The main issues

• Keys needing long-term protection must be on a Secure Element and not extractable (TLS/SSH/other ephemeral keys are generally OK in RAM and the performance much better)
• Make sure only the MCU is able to access the Secure Element (a given if integrated, needs peering between SE and MCU at manufacture time otherwise, and then the weak point is the peering mechanism in the MCU)
• Make sure an attacker can never ever have access to the Secure Element through the MCU, which usually means preventing any kind of attacker code execution, which means at the very least: secure boot, secure upgrade, full integrity measurement (no non signed code executed ever, see EVM and IMA if you use Linux) and generally no bugs in the firmware allowing access to your MCU even with all that through a ROP chain, plus disabling or protecting with a strong mechanism additional debug interfaces such as JTAG.

Some people may still be able to extract keys from the Secure Element through various means (glitching, decapping and probing...) but that's on the SE vendor not you.

Obviously, all that is useless if you don't provision your keys securely, this part greatly depends on the specific hardware and manufacturing process. My past experiences were with SCP03 but there are other ways.