Traditionally, a DPA attacker would simply feed an unlimited amount of random data into the decryptor’s ciphertext input port and then collect the side-channel information for analysis. There are two methods by which UltraScale and UltraScale+ FPGAs can detect this random (or invalid) bitstream. To accomplish this, the user selects only one of the following two methods:
- Configuration counting solution
- Configuration counting quickly detects an invalid bitstream in real time
during the decryption process. UltraScale and
UltraScale+
FPGAs add a 32-bit periodic symmetric authentication check every eight
words. Decryption is halted immediately if the periodic authentication fails
and the UltraScale or UltraScale+ FPGA marks it as an
invalid configuration attempt. This method should only be used with
BBRAM-based AES-GCM keys and incurs a tamper penalty if enough invalid
configuration attempts are made (BBRAM key zeroize). The number of allowable
configuration attempts is programmable by the user.Note: The use of obfuscated key storage is not compatible with the configuration counting DPA countermeasure for BBRAM key storage.
- Random data solution
- The encrypted bitstream is authenticated-then-decrypted using asymmetric authentication (RSA) before being fed to the decryptor. Side-channel attacks on the signature verification process are useless because there are no secrets to discover (the public key and public key hash can be known by anyone). This method can be used for eFUSE or BBRAM-based AES-GCM keys and does not incur a tamper penalty. When using this method, symmetric authentication checks are not performed.
For the configuration counting solution, there is an associated down counter located in the BBRAM that tracks configuration attempts (the maximum initial count value is 255 and is set by the user at the same time the key is loaded). The counter can be configured to count either invalid configuration attempts or all configuration attempts (whether valid or invalid). The counter is decremented prior to every configuration attempt. If configured to count only invalid configurations, the counter increments after successful configurations. If configured to count all configurations, the counter remains decremented at the end of every configuration.
The BBRAM key is zeroized (tamper penalty) after the counter reaches its terminal count of zero. A smaller initial count value corresponds to a higher level of protection because it reduces the amount of side-channel data that can be collected. Additionally, security checks are also performed to verify counter operation and BBRAM integrity.
For the configuration counting solution, there is no way to distinguish between an intentionally random (invalid) bitstream and invalid data that is due to signal integrity issues. This eventually causes the BBRAM key to be zeroized if the FPGA is configured enough times. If using this solution, it is critical that the datapath from the memory device to the FPGA’s configuration port be robustly designed to guarantee there are no signal integrity problems.
For the random data solution, the following figure illustrates, at a high-level, how authenticate-before-decrypt prevents the decryption of random data.
The temporary buffer shown in the previous figure is actually the configuration memory normally used to hold the data that defines the user logic. However, in this case it is used to securely hold the encrypted bitstream until after the RSA authentication step is completed. If authentication passes, each frame of encrypted bitstream data is decrypted and then placed back into the same location in configuration memory (this is the read-decrypt-write (RDW) phase). This RDW phase operates at the rate of the specified CCLK frequency used for configuration (either the internally specified CCLK frequency or the CCLK frequency that is derived from the EMCCLK).