Using Encryption to Protect the Xilinx 7-Series Bitstream
When it became necessary to protect the device from unwanted use, it turned out that there was little information on this topic. In the end, the process of clicking on the many links that the search engine gave out led to XAPP1239, UG470 And XAPP1084. Before reading this article, it is better to familiarize yourself with them, so it will be clearer what is being discussed. Below will be a step-by-step description of the processes of creating an encrypted bitstream and configuring the FPGA on the ARTY A7 debug board and XC7K325T KINTEX-7 on a custom board for programming this encrypted bitstream.
Disclaimer
Here will be described specific experience of the last couple of days and some experiments with debug boards. This is not the experience and experiments of a professional FPGA developer. Maybe this will be read by specialists who are well versed in this topic and will give constructive criticism.
Introduction
First, let's experiment with the ARTY A7 and use its BBRAM. Even though it doesn't have a battery, it's good enough to get your hand in. The process will be described below (with some screenshots and comments) eFUSE programming and flash programming with encrypted bitstream.
The work will be carried out in Vivado 2021. Several old designs were used for testing using MicroBlaze, which is programmed in Vitis 2021. But Vitis will only require the generated .elf, which may be difficult to attach if you are used to working with tcl in terms of connecting .bit and .elf using the updatemem utility. But first things first.
Generating encrypted bitstream
To do this, you need to open the synthesized design (Open Synthesized Design)
Hidden text
In the Tools -> Edit Device Properties menu, go to the Encryption tab. On the Encryption tab, in the Enable Bitstream Encryption field, specify “YES” (there are only two options), and in the Select location of encryption key field you need to select where the keys will be stored (which are generated by Vivado itself or independently). At this stage, the storage location specified as training is BBRAM, but this memory is volatile! It is necessary to use a special battery for this approach!
The author's boards do not have a battery. Experiments with BBRAM were conducted solely for training. Next, a working version with storing keys in eFUSE will be considered.
Hidden text
Key Settings
The Encryption tab contains the following fields:
These fields can be left blank and Vivado will generate the keys itself, or you can fill in HMAC, key 0 and CBC (The author has not experimented with input file encryption). And then the encryption will be more reliable. As written in XAPP1239, you need to decide who you are protecting yourself from? From a white hat hacker or from an enemy government agency?
Author's note
This has nothing to do with encryption, but it will affect the bitstream loading speed from the flash when powering up. In the Edit Device Properties menu there is a Configuration tab, and on it the Configuration Rate (MHz) field. It is better to change the standard value to a value that your flash supports, for example, to 33 MHz. And in the configuration Modes enable Master SPI x4.The author did not do this right away and instead of the 7-second download that was already familiar to him at that time, the encrypted bitstream began to download in 30. This is no good!
After all these settings you need to save Constraints (and if you don't do this, Vivado itself will offer to do it) and generate a new bitstream (Generate Bitstream). With these settings it will already be encrypted. Now, if you go to the .xdc file (so-called constraints) new lines will appear there set_property BITSTREAM.ENCRYPTION.ENCRYPT YES [current_design]. And if you specified the keys yourself, and did not trust Vivado with this, more lines with these keys will appear.
Hidden text
Author's note
If you work with MicroBlaze, you may encounter some peculiarities. It all depends on how you combine .bit and .elf files. When the author began experimenting with Vivado and Vitis, he used the excellent article from the resource fpga-systems.ru. It's so good that there are people who describe seemingly simple things. But they are simple when you do them for the hundredth time, and when you need to generate a binary file to load an FPGA from flash and have never done it before, it does not seem simple. On fpga-systems.ru two methods of connecting .bit and .elf are described and the author liked the method with the updatemem utility more, but here's the problem – it doesn't work with encrypted bitstream. If you google it, you can find this one comment from an AMD specialist. Then you need to contact the second method .bit and .elf connections via graphical interface.Some screenshots for Vivado 2021 will not hurt:
In Design Sources, right-click on .bd and click Associate ELF Files;
In the dialog box that opens, specify the path to your .elf;
Hidden text
Now the necessary .elf has appeared in the project hierarchy and it won’t be possible to flaunt tcl scripts.
Hidden text
Programming the debug board
If you open Hardware Manager and try to program the FPGA with encrypted bitstream without preparing the FPGA for this, the process will end with an error.
Therefore, in the Hardware Manager, right-click on the FPGA and go to Program BBR Key
If the encrypted bitstream is successfully generated, the .nky file was created and in the dialog box that opens, you need to specify the path to it in the AES key file (.nky) field. This file is usually located in the impl_1 directory. When loading this file, AES Key 0 will be displayed, it must be compared with what you specified when setting up the bitstream generation. In the case of experiments with BBRAM and an unconnected battery, nothing terrible will happen, but when using eFUSE there will be no way back, you should learn to treat the keys very carefully! When everything is correct, you need to click “Ok”. In this case, information about the successful programming of the keys will be displayed in the Tcl Console.
Hidden text
Now you can load the encrypted bitstream onto the configured FPGA and work as usual.
Interim results of the first experiment
It turned out to be not so difficult to encrypt the bitstream and program the FPGA with it. Now if you save the binary to the boot flash (from which the firmware is loaded when power is applied), it can still be read using Readback Configuration Memory Device in Hardware Manager.
It will not be possible to program another exactly similar Arty A7 debug board with this binary. Unless, of course, you first prepare the FPGA to work with the encrypted bitstream using special encryption keys. But while these keys are unknown to anyone except you, it will be quite problematic to use this encrypted binary file.
In order to use BBRAM to store keys, you need to take care of the circuitry of your product in advance, so in practice you can use eFUSE to store keys.
eFUSE for storing encryption keys
For training, BBRAM without a battery is good because any changes will be restored after a power reset. When working with eFUSE, you need to be careful, because this memory is burned only once. All the advantages and disadvantages, as well as the criteria for choosing where to best store the keys for your project are exhaustively well described in XAPP1239.
Bitstream for eFUSE
Bitstream generation is configured in exactly the same way as for BBRAM, only for storing keys you need to specify “EFUSE” in the Select location of encryption key field
Save. Now in .xdc set_property BITSTREAM.ENCRYPTION.ENCRYPTKEYSELECT EFUSE. And generate bitstream (Generate Bitstream). Again, it will not be possible to program this FPGA without preparation.
Program eFUSE Registers
As before, in the Hardware Manager, right-click on the FPGA, but now you need to select Program eFUSE Registers.
In the opened wizard, you need to activate the Enable AES key programming checkbox and specify the path to the .nky file, which is usually in the impl_1 directory. Check the key again to make sure it matches what you specified when setting up the bitstream generation, the eFUSE memory is burned once! If desired, you can program user bits (arrows 2, 3 and 4). You can put the software version number or the circuit version, or the date there (as an author), or nothing at all.
The next page sets the FUSE_CNTL bits. You need to set these bits depending on who you decide to protect yourself from.
Note from the author
The author decided not to defend himself from imaginary enemies for now and left the Enable control register programming checkbox inactive. Or not…
Hidden text
On the next wizard page you can specify the name of the auxiliary file and the location where it will be exported.
On the next page the wizard will display information about the encryption key (check it again just in case), information that will be programmed into USER registers (there is just some useful information or default zeros) and the path to the exported settings file.
With your permission, there will be no screenshot here, so as not to compromise the author's encryption key, but besides the Finish button, there is also the one you need to click.
Vivado will then warn you that eFUSE cannot be reprogrammed.
We were careful and confident in everything, so we will press Ok and receive messages in the console about the successful burning of eFUSE. Now we can safely generate a file for the bootable flash, program the bootable flash with it and be sure that the device cannot be cloned simply anymore.
Note from the author
To generate a file for a bootable flash, the author uses the Vivado GUI.
Select format (always bin);
specify for which flash;
location and name for the output file;
Interface (must match what is specified in Configuration Modes);
Activate the checkbox;
Specify the path to the required bitstream;
Generate file.
Hidden text
Loading into flash occurs in standard mode.
Results
After several experiments, it was possible to generate an encrypted bitstream and program the FPGA with it even after a power reset.
Note from the author
The author had four identical custom boards with Kintex-7 on board. Having programmed one of the boards in this way (keys in eFUSE) and having read the data from the boot flash using Readback Configuration Memory Device, the author was unable to program other FPGAs with an encrypted file without programming encryption keys in the FPGA.
How do you protect your firmware?
P.S.
In 2020 in the magazine HACKER came out article about a vulnerability in Xilinx FPGA chips. I didn't pay much attention to it then, but now I've read original articleand I had a lot of questions. Maybe you heard about this or are a specialist in this field, then please write how realistic it is to hack the protection described above?
Thank you.
S.N.
