Volatile FPGA Root-of-Trust Keying via Encrypted Configuration Memory
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Volatile FPGAs lack the ability to retain a secret unique cryptographic key, which is essential for secure operations, as they lose their state when power is switched off, making them unsuitable for cryptographic root-of-trust applications, and manufacturing processes require uniform bit-files across devices, conflicting with the need for unique keys.
Innovation Solution
A method using layers of encryption with independent keys to store auxiliary data in the configuration memory, where a security block generates a unique key during initialization and communicates it to an external validation system, allowing each device to have a secret unique key without additional components beyond off-the-shelf FPGAs and non-volatile memory.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a secret unique cryptographic key is embedded in a volatile FPGA, then cryptographic root-of-trust functionality is enabled, but the key is lost when power is switched off
Solution Approach 1:
The system segments the key management functionality into two parts: a volatile FPGA that performs cryptographic operations and a non-volatile configuration memory that stores the secret unique key. The FPGA is configured with a security block that has access to the key stored in the configuration memory, allowing the key to persist across power cycles while the FPGA maintains operational flexibility.
Solution Approach 2:
The configuration memory acts as an intermediary between the need for a persistent secret key and the volatile nature of the FPGA. The key is stored in the configuration memory and made available to the FPGA through the configuration process, allowing the FPGA to use the key without permanently storing it internally.
2Ease of manufacture
If all devices are manufactured with the same bit-file, then manufacturing uniformity is achieved, but each device cannot have a unique secret key
Solution Approach 1:
The system performs preliminary configuration by storing a template bit-file in the configuration memory during manufacturing. This bit-file contains a security block with a placeholder or encrypted form of the unique key. During device initialization, the actual unique key is generated or retrieved and used to decrypt or activate the security block, allowing all devices to start with the same manufacturing process while achieving individual uniqueness.
Solution Approach 2:
The system changes the state of the key from an encrypted or placeholder form in the manufactured bit-file to an active decrypted form during initialization. The configuration memory stores the key in a protected state that can be transformed into an operational state through cryptographic operations performed by the security block in the FPGA.
Data Source
Figure 1~3
Figure 4
Figure 5
AI summary
The present disclosure describes a method for providing a secret unique key for a volatile FPGA. The method uses layers of encryption with different and independent keys and the possibility to store auxiliary data in the configuration memory. The configuration may be stored in a bit-file protected using hardwired bit-file encryption offered by modern off-the-shelf FPGAs. The configuration includes a security block which has an embedded group key that is, in turn, used for protecting the auxiliary data. In the beginning, the auxiliary data may include a specific field with null identifier, which indicates that the device has not been initialized. During the initialization, the device generates a unique key and sets the field to specific identifier, which indicates that the device has been initialized, and replaces the original auxiliary data in the non-volatile configuration memory with a new auxiliary data constructed from these values. During normal operation this key is fetched from the auxiliary data and used to build a root-of-trust.