How is FPGA/MCU configuration/firmware data protected from readout

Question

I came across the question: How to protect FPGA/MCU configuration/firmware data stored in external memory from readout/ripoff.

With MCUs and internal flash you can just lock the e.g. JTAG to prevent readout. I guess you can do the same with FPGAs and internal configuration.

But, if the data is stored in an external flash/eeprom you could just unsolder the IC and wire up a tool to download and replicate it.

So i came up with a few solutions, but they are all not optimal in my opinion.

My ideas:

1. Encrypt the firmware image and write it to the external IC. The MCU/FPGA could have a bit-stream decryptor to not limit/decrease speed. But you could till just copy the memory contents, as long as the key does not change.

2. Encrypt the firmware based on a MCU/FPGA device ID. This would prevent just copying the contents as the crypto key would change. But for field updates, the key needs to be known: So managing images gets tricky/messy quick.

My question:

How to protect MCU/FPGA firmware/configuration stored in external flash/eeprom chips from readout/ripoff?

1. What are the common approaches?
2. What is required? Peripherals, Software, what-not
3. What a common pitfalls in deploying "protected software" in mass?

EDIT 1:

A short summary of the current answers:

1. The simplest Method to protect MCU firmare is to not use an external flash at all. Therefore, it is not possible to clone the external IC - as well as injecting "bad code" is not possible/harder.

2. FPGA indeed use bitstream encryption based on a private (not readable and not the device-ID) key. This key is introduced to the device during factory programming.

3. Modern/bigger MCUs provide peripherals aimed at storing crypto data in certain ways (e.g tamper protected volatile memory, or dedicated register preserved during sleep-modes (for battery backup)).

4. Secure firmware is only required in certain applications. To protect firmware itself is mostly senseless, as "writing new firmware" can be easy compared to developing the actual device. Also, basic IP regulations can be used to protect firmware.

5. When storing crypto keys (e.g. credit-card reader and what not) dedicated hardware is available - and also backed by a "chain-of-trust".

6. Deploying "protected software" is a whole process involving multiple steps and having many loop-holes (e.g. a person in the factory stealing the crypto keys, or tampering with the actual firmware image to inject bad code)

7. When deploying "protected firmware" one must also think about the field-update process - With Updates-Over-The-Air and other transmission protocols, the images can be read-out if not encrypted.

Answer 1

Encrypt the firmware image and write it to the external IC. The MCU/FPGA could have a bit-stream decryptor to not limit/decrease speed.

For an FPGA, that decryptor must be a hard component of the chip: can't have a decryptor in your bitstream if you need it to load your bitstream.

But you could till just copy the memory contents, as long as the key does not change.

Exactly. That's why you need each of your MCU/FPGA to have a unique decryption key, which can only decrypt the firmware meant for it.

But that makes the internal key something that you need to protect from readout.

Encrypt the firmware based on a MCU/FPGA device ID.

No, that would make your device key easily derivable from the device ID for an external party.

You need to put cryptographic secrets in memory that you cannot read externally.

So, let's assume your chip contains memory that's unreadable from software/configurable bitsteam, and a hardware component that can do decryption:

This would prevent just copying the contents as the crypto key would change. But for field updates, the key needs to be known: So managing images gets tricky/messy quick.

Well, there's no free lunch. If you chose to use external memory, and think you have a firmware so valuable that it mustn't run on other devices, that's something that you'll have to deal with.

It's honestly not that bad.

What are the common approaches?

Bitstream encryption is a very common feature in mid/higher end FPGAs. You get a unique key per device. So that's a common approach.

Midrange microcontrollers sometimes also come with built-in security engines, i.e., pieces of software-unreadable memory and hardware decryptors that can use the key in these memory, so you can build the same.

Application processors have TPMs (and similar mechanisms) which allow for trust to be delegated through certificate chains, but are in the end just fancy versions of "read-protected memory + decryptor".

More common is to not use externally readable memory if you have secrets. Just buy a microcontroller with more program memory and set the softfuse (or whatever mechanism there is) to prevent its readout via debugging. No serious microcontroller doesn't offer sufficient internal memory.

Even more common is to not protect your firmware at all. You might be overestimating the value people put in most device firmwares. The hard part is usually producing the device, not recreating the firmware once you know what it does, functionally. Sure, exceptions do exist – like say radio devices with DSPs running proprietary codecs – but you would combine legal IP protection with technical measures on these.

Answer 2

Some, if not all FPGAs support bitstream encryption. The FPGA is programmed with a private, unreadable key that decrypts the bitstream as it is read from the external device.

Example: Xilinx 7 Series

Without the private key, the encrypted bitstream is unusable. This thwarts efforts at ripping off the design.

Using encrypted bitstreams requires establishing a ‘chain of trust’ for manufacturing. That is, there’s an inherent vulnerability when the key gets loaded into the device - it’s visible to the human flashing it into the target.

In my own experience, FPGA bitstream encryption is hardly worth it in the big picture.

It’s better to use robust software authentication and chain-of-trust approaches at the system software level. This requires both hardware in your MCU and an infrastructure to support managing your keying material and software release flow.

Example from ARM: PSA Certified

These not only make duplicating your system more difficult, but they also work to thwart malicious attacks that can compromise your platform.

Answer 3

How to protect MCU/FPGA firmware/configuration stored in external flash/eeprom chips from readout/ripoff?

In addition to readout protection, there are other ways to protect against device copying. If the chip has an internal unique ID, the firmware can be modified to check it and not run on another device. One way is to rewrite the flash automatically on first boot, so that a fresh firmware image can be written on any device but one that has been read out from existing device cannot.

Without readout protection, this becomes a security-by-obscurity battle between obfuscation and reverse-engineering. There are no truly safe ways to hide such copy protections in the firmware or FPGA bitstream, but it is possible to make the reverse-engineering difficult enough that it is not worth the time. Common approaches are ensuring that all debugging interfaces are disabled and hiding the unique ID data using encryption or XOR masking.

Reverse-engineering tools for FPGAs are relatively less common than for microprocessors, so hiding things is easier there. But on the other hand, most FPGAs that have unique ID also support bitstream encryption.