How Do You Protect an FPGA Bitstream With Encryption and Anti-Tamper Features?

Detailed Explanation

An SRAM-based FPGA loses its configuration every time power is removed, covered in the FPGA development flow's bitstream generation and programming section, and reloads it from external SPI flash on every power-up. That reload mechanism is exactly what creates the exposure bitstream encryption addresses: the flash chip holding that configuration is, on an unencrypted design, a complete, directly readable copy of the design's intellectual property, extractable with nothing more than physical access to the board and a flash programmer, no reverse-engineering of the logic itself required.

Bitstream encryption closes this by having the vendor toolchain encrypt the bitstream, commonly with AES-256, before it's written to flash. The FPGA itself stores the matching decryption key internally, in a battery-backed RAM, a one-time-programmable eFuse array, or a dedicated secure element depending on the specific device family, and decrypts the bitstream internally as part of its own power-up configuration sequence. The external flash never holds a usable copy of the design at any point; even a complete, bit-perfect dump of that flash chip is useless without the key that lives only inside the FPGA.

Readback Protection and Authentication

Encryption alone doesn't close every path. Readback protection is a separate, complementary feature that disables the ability to read configuration data back out of a programmed FPGA (typically over JTAG), which matters because encryption protects the bitstream in flash, not necessarily the configuration state already loaded inside a running device. Authentication is a third, distinct concept: verifying that a bitstream hasn't been modified or substituted, using a cryptographic signature, which matters even in cases where confidentiality (encryption) isn't the primary concern, since an attacker who can substitute a modified but valid-looking bitstream can potentially alter device behaviour without ever needing to read the original design's contents. A complete anti-tamper strategy on a device that supports all three typically layers encryption, readback protection, and authentication together, since each defends against a distinct attack path the others don't cover.

Some device families extend this further with dedicated tamper-detection hardware: sensors that monitor for physical intrusion attempts (voltage glitching, temperature extremes outside the specified operating range, or physical probing) and actively erase the internal key store the instant tampering is detected, destroying the ability to decrypt future configuration attempts even if the attacker gains full physical access afterward.

Practical Examples

A defence or industrial product with a contractual anti-tamper requirement is the clearest case for bitstream encryption: the requirement is often explicit in the contract or applicable standard, and the device family selection (see how to choose the right FPGA family) needs to account for encryption and anti-tamper support as a hard requirement from the start of the design, not an afterthought once a family has already been chosen for other reasons.

A commercial product with valuable, hard-to-replicate signal-processing IP in the FPGA fabric, sold into a market with real counterfeiting or IP-theft risk, benefits from bitstream encryption even without a formal contractual requirement, since the alternative (an unencrypted bitstream in flash) gives a competitor with access to a single unit a complete, working copy of the design's IP with no engineering effort required to extract it.

Design Considerations

• Confirm the specific device family's key-storage mechanism and its power-domain requirements before committing to it. A battery-backed key store needs a coin cell or supercap maintained across the product's service life; losing that backup power source can mean losing the key permanently, bricking every unit that depended on it. Understand this failure mode before it becomes a field problem.
• Plan the key-provisioning process for production, not just for prototypes. Programming a unique or shared encryption key into every production unit is a process and security control the manufacturing line needs to support securely; treating key provisioning as a one-off engineering-sample step that doesn't scale to volume production is a common planning gap.
• Enable readback protection alongside encryption where the device supports both, since encryption alone doesn't close the separate JTAG-based configuration-readout attack path covered in the FAQ above.
• Weigh the added complexity against the actual threat model honestly. As covered in the FAQ above, bitstream encryption and key management are a real, ongoing engineering and production cost; commit to them when the IP value or the product's threat model genuinely justifies it, not as a default box to tick on every FPGA design.
• Zeus Design designs FPGA hardware and firmware, including bitstream encryption and anti-tamper implementation for defence, industrial, and IP-sensitive commercial products, as part of embedded firmware development.

Common Mistakes

• Shipping a production design with an unencrypted bitstream in flash when the design's IP genuinely warrants protection, leaving the complete design extractable from any unit an adversary can physically access.
• Treating encryption and readback protection as interchangeable, when, as covered in the FAQ above, they defend against different attack paths and are meant to be used together on devices that support both.
• Losing track of key-provisioning process security in production, treating it as an engineering-sample convenience step rather than a manufacturing-line security control that must scale correctly and securely to full production volume.
• Choosing an FPGA family for other criteria first and discovering afterward that it lacks bitstream encryption or anti-tamper support the application actually needs. Confirm this requirement against the specific device family and tier during initial family selection, not after the design is otherwise locked in.