Volatile FPGA Key Provisioning Using Encrypted Auxiliary Data
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Volatile FPGAs lack the ability to retain a 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 individual secret keys.
Innovation Solution
A method using layers of encryption with independent keys to generate a unique key for each device, where a security block initializes the device by generating a secret key and updating auxiliary data in non-volatile memory, allowing each device to have a unique key without additional components beyond off-the-shelf FPGAs and configuration memory.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Device complexity
If a volatile FPGA is used to reduce device cost and complexity, then the device can operate with off-the-shelf components, but the FPGA loses its state when power is switched off, making it impossible to retain secret unique keys for cryptographic root-of-trust applications
Solution Approach 1:
The system segments the key management functionality into two parts: a volatile FPGA for operational flexibility and a non-volatile memory for key persistence. The secret unique key is generated and stored in the non-volatile memory, while the FPGA uses this key during operation but does not need to retain it in volatile memory, thus resolving the contradiction between volatility and key retention.
Solution Approach 2:
A non-volatile memory component acts as an intermediary between the volatile FPGA and the requirement for persistent key storage. The memory stores the secret unique key and provides it to the FPGA when needed, allowing the FPGA to remain volatile while still supporting cryptographic root-of-trust functionality.
2Object-affected harmful factors
If bit-file encryption with a hardwired decryption key is implemented to prevent reverse-engineering, then security against adversaries is improved, but all devices must have the same hardwired key, preventing individual secret unique keys for each device
Solution Approach 1:
The key system is segmented into two distinct keys with different security requirements: a hardwired decryption key for protecting the bit-file against reverse-engineering, and a separate secret unique key generated and stored in non-volatile memory for individual device identification and cryptographic operations. This segmentation allows both uniformity for manufacturing and uniqueness for individual devices.
Solution Approach 2:
The system uses a template approach where all devices receive the same encrypted bit-file template during manufacturing, but each device generates its own unique secret key in non-volatile memory. This allows mass production with uniform configuration while maintaining individual uniqueness through the generated keys.
3Reliability
If a secret unique key is generated and stored in non-volatile memory for each device, then cryptographic root-of-trust is enabled, but additional components beyond standard FPGAs and configuration memory are required
Solution Approach 1:
The non-volatile configuration memory is made multi-functional by using it both for storing the standard bit-file and for storing the secret unique key. This eliminates the need for separate dedicated key storage hardware, achieving cryptographic root-of-trust capability while avoiding additional components.
Solution Approach 2:
The functionality of key storage is merged with the existing non-volatile configuration memory. The memory structure and access mechanisms are utilized for both bit-file and key storage purposes, combining multiple functions into a single component and avoiding increased device complexity.
Data Source
AI summary
A method for providing a secret unique key for a volatile FPGA 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. The configuration includes a security block with an embedded group key 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.