The crown jewel of the FPGA is the AES-GCM key used to decrypt the bitstream. After an attacker has access to the key, the contents of the original bitstream can be easily determined. By connecting your design to the KEYCLEARB1 input (located on the STARTUP block primitive in the External PROGRAM_B Intercept (Prevention and Detection) section, you can choose to assert this signal as a penalty in response to internal (or external) tamper events. By zeroizing the 256-bit key in BBRAM, the registered content of the eFUSE key, and the 1920-bit expanded key in the decryption block, the encrypted bitstream stored in off-chip non-volatile memory becomes useless to the attacker. For UltraScale and UltraScale+ FPGAs, a configuration status bit(2) is also available that indicates whether the key data erasure has been verified (proves zeroization).
The decision for the KEYCLEARB assertion (as well as all other tamper responses) does not necessarily need to originate from within the FPGA itself. It could be due to a tamper event somewhere else in the system (for example, a breach of a system-level or module-level tamper boundary).
After the key is zeroized, the FPGA is useless until reprogrammed with the same key or reconfigured using IPROG to an unencrypted bitstream (perhaps with reduced functionality) Refer to UltraScale Architecture Configuration User Guide (UG570) for more information. Ensure that the KEYCLEARB input is only asserted under the proper conditions. In many cases, equipment must be taken out of the field and sent back to a central depot or manufacturing facility to be re-enabled with a key load operation.
KEYCLEARB can also be combined with the IPROG command in response to tampering to also erase the configuration memory. The KEYCLEARB assertion must occur before an IPROG command is sent (that is, the IPROG command can be sent to the ICAPE3 immediately following the assertion of KEYCLEARB).