As we have both theoretic and practical cryptographers in our group, Marcin and Phil started by describing the basic technology of a Field-Programmable Gate Array: Unlike ASICs (Application-Specific Integrated Circuit), the function of a FPGA is not determined when it is manufactured. Instead, FPGAs have to be configured; based on their configuration mechanism, they are either
- volatile, i.e. the configuration can be changed, or
- non-volatile where the configuration is "burnt" into the device, e.g. using anti-fuses.
The study group focused on volatile FPGAs, which essentially consist of an array of SRAM lookup tables (LUTs) which map a fixed number of input bits (e.g. 4) to a smaller number of ouput bits (e.g. 1) and configurable interconnect. The LUTs basically emulate the truth tables of the logic gates used in ASICs while the configurable interconnect assures that basically all LUTs can be "wired together" as required. Being SRAM, the LUTs have to be reconfigured at boot time which provides the volatility of the FPGA. A comparison of FPGAs to CPUs and ASICs results (roughly) in the following table:
|low||low||high (tapeout, masks)|
|Cost per unit||medium||high||low|
Of course FPGAs come with a couple of security related issues including such as
- leakage (side channel attacks)
- semi-invasive attacks (fault injection)
- invasive attacks
- trustworthy (remote) configurations (hw trojans, reliability)
- protection of Intellectual Property in configuration bitstreams (IP cores).
The first protocol presented by Marcin and Phil is a simple remote update protocol for which the FPGA needs to have
- a fixed update logic UL besides the configurable logic which can compute a keyed MAC,
- a unique and public fingerprint F,
- a version number V of its current bitstream (to guarantee freshness)
- and of course a key which will be used as input for the keyed MAC.
The second protocol presented by Marcin and Phil addresses the bit stream decryption and IP core protection problem. Basically, if the bitstream is completely owned by the System Designer (SD), the SD could just encrypt it using a symmetric key he has loaded into the FPGA. But IP core vendors want to protect their IP even though it will always be used by SDs as part of a larger system. So a more complex system is needed and Diffie-Hellman style key-exchange can provide it as the presented 4 stage protocol with three parties (FV - FPGA Vendor, CV - Core Vendor, SD) shows. The needed prerequisits of the FPGA are
- a unique key KFPGA,
- unique identifier FID (both stored in non-volatile memory inside the FPGA),
- some hardwired additional registers to store a bit stream encryption key for each CV and
- a hardwired decryption module which has access to all of the above keys.
- Setup: FV generates a secret x and computes a public gx and embeds the secret into the personalisation bitstream PB and encrypts PB using KFPGA and sends [FID, gx, ENCKFPGA(PB)] to SD.
- Licensing: For each CV and each FPGA device, SD sends (FID, gx) to the CV who choses a secret y, computes a public gy and uses a key derivation function KDF (specified by the FV) to compute a key KCV=KDF(y,gx,FID) which he uses to encrypt his IP core and sends [ENCKCV(core), gy] to the SD.
- Personalisation: Having assembled his own bitstream containing all the encrypted cores of the CVs, the SD loads first the encrypted PB onto the FPGA which the FPGA is able to decrypt using KFPGA. The PB contains an implementation of KDF and of the vendor secret x. Furthermore, the SD provides all the gy to the FPGA which in turn uses the KDF to compute all KCV=KDF(x,gy,FID) which it stores in the registers of the decryption logic. (The computation works thanks to Diffie-Hellman.) Now the Personalisation logic (within the configurable part of the FPGA) isn't needed anymore as the (static) decryption logic is fully prepared to decrypt the bitstreams.
- Configuration: The SD sends all encrypted bitstreams to the FPGA which decrypts them using the respective KCV's which were stored during personalisation in the decryption registers.