Using Encryption to Secure a 7 Series FPGA Bitstream

Application Note: 7 Series FPGAs
Using Encryption to Secure a 7 Series FPGA
Bitstream
XAPP1239 (v1.0) April 15, 2015
Author: Kyle Wilkinson
Summary
This application note describes a simple step-by-step process to generate an encrypted
bitstream and encryption key using the Xilinx® Vivado® Design Suite. Steps to program that
encryption key and encrypted bitstream into a Xilinx 7 series FPGA using the Vivado Design
Suite are included.
Introduction
Xilinx 7 series devices have on-chip Advanced Encryption Standard (AES) decryption logic to
provide a high degree of design security. Encrypted 7 series FPGA designs cannot be copied or
reverse engineered for use on unintended FPGAs. The 7 series FPGA AES system consists of
software-based bitstream encryption and on-chip bitstream decryption with dedicated memory
for storing the encryption key. Xilinx Vivado tools are optionally used to generate the
encryption key and the encrypted bitstream. A user-generated key from a truly random source
is recommended. The 7 series devices store the encryption key internally in either dedicated
RAM, backed up by a small externally connected battery (BBRAM), or in the eFUSE. The
encryption key can only be programmed onto the device through the JTAG port. The 7 series
device performs the reverse operation, decrypting the incoming bitstream during
configuration. The 7 series FPGA AES encryption logic uses a 256-bit encryption key. The
on-chip AES decryption logic cannot be used for any purpose other than bitstream decryption.
AES decryption logic is not available to the user design and cannot be used to decrypt data
other than the configuration bitstream.
Advanced Encryption Standard (AES) and Authentication
The 7 series FPGA encryption system uses the Advanced Encryption Standard (AES) encryption
algorithm. AES is an official standard supported by the National Institute of Standards and
Technology (NIST) and the U.S. Department of Commerce
(http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf). The 7 series FPGA AES encryption
system uses a 256-bit encryption key (the alternate key lengths of 128 and 192 bits described
by NIST are not implemented) to encrypt or decrypt blocks of 128 bits of data at a time.
According to the NIST, there are 1.1 x 1077 possible key combinations for a 256-bit key.
Symmetric encryption algorithms such as AES use the same key for encryption and decryption.
The security of the data is therefore dependent on the secrecy of the key.
XAPP1239 (v1.0) April 15, 2015
www.xilinx.com
1
Encrypted Bitstream Implementation Overview
The AES supported in 7 series FPGAs is identical to that supported in Xilinx Virtex®-6 devices.
(The AES support has been validated, see the Advanced Encryption Standard Algorithm
Validation List at http://csrc.nist.gov/groups/STM/cavp/documents/aes/aesval.html#2363.) A
256-bit encryption key is loaded into the eFUSE bits or battery-backed RAM by the user. The
Xilinx bitstream writer, using AES, encrypts the bitstream. This feature allows you to encrypt
your bitstream using 256-bit AES encryption in cipher block chaining (CBC) mode. You can
supply a 128-bit Initial Vector and 256-bit key, or let the software choose a random key.
Allowing the Vivado Design Suite to generate the key is not as secure as generating your own
key by means of a a truly random process (see XAPP1084 [Ref 1]). Some security features such
as the ability for the FPGA logic to clear the AES key from battery-backed RAM require that the
part is configured with an encrypted bitstream in order to function.
7 series devices also have an on-chip bitstream keyed-Hash Message Authentication Code
(HMAC) algorithm implemented in hardware to provide additional security beyond that
provided by the AES decryption alone. (See FIPS PUB 198-1, HMAC Federal Information
Processing Standards at http://www.nist.gov/itl/upload/FIPS-198-1_final.pdf.) The additional
security provides cryptographically strong authentication of the decrypted bitstream to prove
that not even a single bit was modified. Without knowledge of the AES and HMAC keys, the
bitstream cannot be loaded, modified, intercepted, or cloned. AES provides the basic design
security to protect the design from copying or reverse engineering, while HMAC provides
assurance that the bitstream provided for the configuration of the FPGA was the unmodified
bitstream allowed to load. Any bitstream tampering, including single bit flips, are detected.
The HMAC algorithm uses a key that is provided to the Xilinx software. Alternately, the software
can automatically generate a random key. The HMAC key is separate and different from the AES
key. The Xilinx software then utilizes the key and the Secure Hash Algorithm (SHA) to generate
a 256-bit result called the Message Authentication Code (MAC). The MAC and HMAC key are
transmitted as part of the AES encrypted bitstream, verifying both data integrity and
authenticity of the bitstream. Authentication covers the entire bitstream for all types of control
and data. When used, the 7 series FPGA security solution always consists of both HMAC and
AES.
Encrypted Bitstream Implementation Overview
The following is a list of six fundamental steps needed to implement an encrypted design in a
Xilinx 7 series FPGA:
1. Choose an AES key storage location: BBRAM or eFUSE; and corresponding security options
(see XAPP1084 [Ref 1] for trade-off between BBRAM and eFUSE).
2. Implement the hardware requirements in your board design, based on your AES key storage
selection.
3. Using Vivado Design Suite software, generate an AES key or provide your own custom AES
and HMAC keys to the software (which is always the most secure approach) and encrypted
bitstream.
4. Program the AES key into the FPGA using JTAG interface.
XAPP1239 (v1.0) April 15, 2015
www.xilinx.com
2
Hardware Board Requirements
5. Program the encrypted bit file into the FPGA via JTAG or other configuration mode such as
SPI or BPI, and ensure that the DONE pin asserts.
6. Perform hardware validation to ensure proper operation.
Hardware Board Requirements
There are a few basic hardware requirements needed to implement an encrypted design flow:
•
For programming ability and debugging capability: JTAG connector to FPGA.
•
For BBRAM key storage: Battery to VCCBATT (see data sheet for battery voltage
requirements)
•
For eFUSE key storage: Recommend VCCBATT to VCCAUX to enable the ability to test with
BBRAM flow prior to burning the eFUSEs.
Software Requirements
Vivado Design Suite 2014.3.1 or newer is required.
AES Key Storage
There are two options for AES key storage; Battery backed RAM (BBRAM) or eFUSE. When
selecting the BBRAM or eFUSE storage options it is highly recommended that you consider the
advantages and disadvantages of each option and which option fits your design requirements
best. Refer to the following sections for details on each of their respective advantages and
disadvantages. Additional information on each of these storage options can be found in the
7 Series FPGAs Configuration User Guide (UG470) [Ref 2].
BBRAM
When an encryption key is stored in the FPGA's battery-backed RAM, the encryption key
memory cells are volatile and must receive continuous power to retain their contents. During
normal operation, these memory cells are powered by the auxiliary voltage input (VCCAUX). A
separate VCCBATT power input is recommended for retaining the key when VCCAUX is removed.
Therefore it is recommended that the AES key be programmed in-system on a board that has
the battery back-up. Otherwise, the key is lost when power/battery is removed. BBRAM storage
location advantages and disadvantages are identified in Table 1.
XAPP1239 (v1.0) April 15, 2015
www.xilinx.com
3
AES Key Storage
Table 1:
BBRAM Storage Location Advantages and Disadvantages
Advantages
Disadvantages
• Volatile and reprogrammable
• Requires an external battery
• Passive and active key clearing (i.e., the evidence can
be removed)
• Many battery vendors do not specify operation
at high temperatures and/or long lifetimes
• Tamper resistant
eFUSE
eFUSE is a nonvolatile one-time-programmable technology used for selected configuration
settings. The fuse link is programmed (or burned or blown) by flowing a large current for a
specific amount of time. User-programmable eFUSEs can be programmed with the Xilinx
configuration tools. Again it is important to mention that eFUSE bits are one-time
programmable (OTP). After they are programmed, they cannot be unprogrammed. For example,
if access to a register is disabled, it cannot be re-enabled. The FPGA logic can access only the
FUSE_USER register value. All other eFUSE bits are not accessible from the FPGA logic. eFUSE
storage location advantages and disadvantages are identified in Table 2.
Table 2:
eFUSE Storage Location Advantages and Disadvantages
Advantages
Disadvantages
• No external battery required
• Permanent: Key can NOT be cleared
• If the CFG_AES_Only security eFUSE bit is set, only a
bitstream encrypted with the eFUSE key can be
loaded into the FPGA
• Less secure than BBRAM solution
eFUSE Registers
A 7 series FPGA has a total of four eFUSE registers: FUSE_KEY, FUSE_CNTL, FUSE_USER, and
FUSE_DNA. For the purpose of this application note we will only focus on the FUSE_KEY,
FUSE_CNTL, and FUSE_USER registers. eFUSE registers are described in Table 3.
Table 3:
eFUSE Register Description
Register Name
Size (Bits)
Contents
Description
256
Bitstream encryption key
[0:255]
(bit 255 shifted first)
Stores a key for use by AES bitstream decryptor.
The eFUSE key can be used instead of the key
stored in battery-backed SRAM.
FUSE_KEY
The AES key is used by the 7 series FPGA
decryption engine to load encrypted bitstreams.
Depending on the read/write access bits in the
CNTL register, the AES key can be programmed
and read through the JTAG port.
XAPP1239 (v1.0) April 15, 2015
www.xilinx.com
4
AES Key Storage
Table 3:
eFUSE Register Description (Cont’d)
Register Name
Size (Bits)
Contents
Description
FUSE_CNTL
14
Control Bits
CNTL [13:0]
(bit 0 shifted first)
Controls key use and read/write access to eFUSE
registers. This register can be programmed and
read through the JTAG port.
FUSE_USER
32
User Defined [31:0]
(bit 0 shifted first)
Stores a 32-bit user-defined code. This register is
readable from the FPGA logic using the
EFUSE_USR primitive. See the 7 Series Libraries
Guide for a description of the EFUSE_USR
primitive.
Depending on the read/write access bits in the
CNTL register, the code can be programmed and
read through the JTAG port.
eFUSE Control Register (FUSE_CNTL) Description
This register contains user programmable bits. These bits, described in Table 4, are used to
select AES key usage and set the read/write protection for other eFUSE registers.
Table 4:
Bit Index
No.
0
eFUSE Control Register Bit Description
FUSE_CNTL Bit
Name
CFG_AES_Only
Description of eFUSE Control Bit
• Configure using AES decryptor only.
• When programmed to 1, this bit forces use of AES
key stored in eFUSE.
• When not programmed (0), use of the AES
decryptor, or not, is selected by the bitstream's
security options.
Recommended
Setting
No
(recommended to
keep as 0 pending
customer security
requirements)
CAUTION! If this bit is programmed to 1, the device
cannot be used unless the AES key is known. Return
material authorization (RMA) returns cannot be
accepted and the Vivado Indirect SPI/BPI flash
programming flow cannot be used if this bit is
programmed.
1
AES_Exclusive
• When programmed to 1, this bit disables partial
reconfiguration from external configuration
interfaces.
No
(keep as 0)
• When not programmed (0), partial configuration is
allowed from external interfaces but the partial
bitstream must be encrypted with a matching key.
CAUTION! If this bit is programmed to 1, return
material authorization (RMA) returns are limited in
device analysis and debug. Instead, set the
bitstream Security to Level2 which also disables
partial configuration from external interfaces.
XAPP1239 (v1.0) April 15, 2015
www.xilinx.com
5
AES Key Storage
Table 4:
eFUSE Control Register Bit Description (Cont’d)
Bit Index
No.
FUSE_CNTL Bit
Name
2
W_EN_B_Key_User
Description of eFUSE Control Bit
Recommended
Setting
• Write enable (active-Low) the key and user-defined
eFUSE value.
Yes
(program to 1)
• When programmed to 1, this bit disables
programming of the AES key and user-defined
value bits.
RECOMMENDED: Program this bit after
programming the key to prevent unintended
changes/corruption to the eFUSE AES key value.
3
R_EN_B_Key
• Read enable (active-Low) the key.
• When programmed to 1, this bit disables reading of
the AES Key and programming of the AES Key and
user-defined value bits.
Yes
(program to 1)
CAUTION! This bit must not be left unprogrammed
(0) after key programming because the eFUSE AES
key would be readable via the JTAG interface.
4
R_EN_B_User
• Read enable (active-low) the user-defined eFUSE
value.
No
(keep as 0)
• When programmed to 1, this bit disables reading of
the user-defined value via the JTAG and also has the
side-effect of disabling programming of the AES
Key and user-defined value bits.
Note: The user-defined value can always be accessed by
the FPGA design via the EFUSE_USR primitive.
5
W_EN_B_Cntl
• Write enable (active-Low) the FUSE_CNTL eFUSE
bits.
Yes
(program to 1)
• When programmed to 1, this bit disables
programming of the FUSE_CNTL bits.
RECOMMENDED: Program this bit to 1 after
programming the FUSE_CNTL register bits to
prevent unintended changes to the FUSE_CNTL
eFUSE bits.
When FUSE_CNTL[0] is NOT programmed:
•
Encryption can be enabled or disabled via the bitstream options.
•
The AES key stored in eFUSE or battery-backed RAM can be selected via the bitstream
options.
CAUTION! When FUSE_CNTL[0] is programmed, only bitstreams encrypted with the eFUSE key can be used
to configure the FPGA through external configuration ports. This precludes device configuration from Xilinx
test bitstreams and Xilinx pre-built bitstreams. Thus, Xilinx does not support RMA requests nor Vivado
indirect SPI/BPI flash programming for devices that have the FUSE_CNTL[0] bit programmed.
XAPP1239 (v1.0) April 15, 2015
www.xilinx.com
6
Creating an Encryption Key and Encrypted Bitstream
External configuration ports are blocked from accessing the configuration memory after initial
configuration if FUSE_CNTL[1] is programmed. The only way to reconfigure the device is to
power cycle, issue a JPROGRAM or IPROG command, or pulse the PROGRAM_B pin.
Creating an Encryption Key and Encrypted Bitstream
The bitstream generator (write_bitstream), provided with the Vivado tools, can generate
encrypted as well as non-encrypted bitstreams. For AES bitstream encryption, set the
write_bitstream property to enable bitstream encryption. You can either specify a 256-bit key as
an input to the bitstream generator or you can have the Vivado tool generate a pseudo-random
key for you. The bitstream generator in turn generates an encrypted bitstream file (.BIT) and
an encryption key file (.NKY). Table 5 shows the write_bitstream properties available to be
defined in the XDC file and their corresponding descriptions.
Table 5:
Write_bitstream Encryption Properties
Write_bitstream Property
BITSTREAM.ENCRYPTION.ENCRYPT
BITSTREAM.ENCRYPTION.
ENCRYPTKEYSELECT
Default
Values
Possible Values
No
No–Yes
bbram
BBRAM, eFUSE
Description
Encrypts the bitstream.
Determines the location of the AES encryption key
to be used, either from the battery-backed RAM
(BBRAM) or the eFUSE register.
Note: This property is only available when the Encrypt
option is set to Yes.
BITSTREAM.ENCRYPTION.HKEY
Pick
Pick, <hexstring>
HKEY sets the HMAC authentication key for
bitstream encryption. 7 series devices have an
on-chip bitstream-keyed Hash Message
Authentication Code (HMAC) algorithm
implemented in hardware to provide additional
security beyond AES decryption alone. These
devices require both AES and HMAC keys to load,
modify, intercept, or clone the bitstream. The pick
setting tells the bitstream generator to select a
pseudo-random number for the value. To use this
option, you must first set Encrypt to Yes.
BITSTREAM.ENCRYPTION.KEY0
Pick
Pick, <hexstring>
Key0 sets the AES encryption key for bitstream
encryption. The pick setting tells the bitstream
generator to select a pseudo-random number for
the value. To use this option, you must first set
Encrypt to Yes.
None
<string>
Specifies the name of the input encryption file
(with a .nky file extension). To use this option, you
must first set Encrypt to Yes.
Pick
Pick,<32-bit
hexstring>
Sets the starting cipher block chaining (CBC) value.
The pick setting enables selection of a
pseudo-random number for the value.
BITSTREAM.ENCRYPTION.KEYFILE
BITSTREAM.ENCRYPTION.STARTCBC
XAPP1239 (v1.0) April 15, 2015
www.xilinx.com
7
Loading an Encryption Key and Encrypted Bitstream
The following is an example XDC file showing BBRAM Key storage and a custom user-defined
AES key. These encryption properties are also available in the Edit Device Properties GUI.
24
25
26
27
28
29
#Encryption Settings
set_property BITSTREAM.ENCRYPTION.ENCRYPT YES [current_design]
set_property BITSTREAM.ENCRYPTION.ENCRYPTKEYSELECT BBRAM [current_design]
#set_property BITSTREAM.ENCRYPTION.ENCRYPTKEYSELECT eFUSE [current_design]
set_property BITSTREAM.ENCRYPTION.KEY0 256’h12345678ABCDDCBA1234578ABCDDCBA1234578
ABCDDCBA1234578ABCDDCBA [current_design]
30
The NKY file generation occurs at the same time as bitstream generation. The NKY file takes the
same top_level name as the bit file and is placed in the same implementation directory.
The NKY file format is:
KEY 0 <hex string> (256 bit AES key)
For example: (top.nky)
Device xc7k325t;
Key 0 12345678ABCDDCBA12345678ABCDDCBA12345678ABCDDCBA12345678ABCDDCBA;
Key StartCBC 7115e9aa80085ea3ed65d26d3a8ab608;
Key HMAC d293d51c6058430262b05521f8f67279c9abce27d5fcafcf839bbe1af46713cc;
Loading an Encryption Key and Encrypted Bitstream
The encryption key can only be loaded onto a device through the JTAG interface. The Vivado
Device Programmer tool can accept the NKY file as an input and program the device with the
key through JTAG, using a supported Xilinx programming cable. To program the key, the device
enters a special key-access mode. In this mode, all FPGA memory, including the encryption key
and configuration memory, is cleared. After the key is programmed and the key-access mode is
exited, the key cannot be read out of the device by any means, and it cannot be reprogrammed
without clearing the entire device. The key access mode is transparent to most users. The key
can be programmed into the battery-backed RAM (BBRAM), which is powered by VCCAUX or
VCCBATT, or into the eFUSE bits.
BBRAM key programming solutions include a Vivado Design Suite and JTAG cable.
Note: Any attempted read or write access to the BBRAM via JTAG causes the BBRAM contents to be
cleared and the entire configuration of the FPGA to be erased prior to access being enabled (being
able to enter key access mode).
eFUSE key programming solutions include a Vivado Design Suite and JTAG cable. Contact an
authorized Xilinx distributor for availability of device programming services.
Note: For the eFUSE solution, it is also recommended to take the following precautions for in-system
programming of the AES key:
°
Prevent or clear the FPGA of a configured design to minimize power supply noise within
the FPGA.
°
If possible, stop board-level system clocks to also minimize system power supply noise.
XAPP1239 (v1.0) April 15, 2015
www.xilinx.com
8
Loading an Encryption Key and Encrypted Bitstream
After connection to a valid hardware target using the Vivado HW_Manager, right-click on the
7 series FPGA and select either Program BBR Key...(to use BBRAM storage) or Program eFUSE
Registers...(to use eFUSE storage), depending on which storage option you have previously
chosen (see Figure 1).
X-Ref Target - Figure 1
Figure 1:
Vivado HW Manager Key Programming Selection
BBRAM Key
When the Program BBR Key is selected you have the ability to browse to the recently generated
NKY file in the project directory. After you add the .NKY file, the key value appears in the AES
key field as shown in Figure 2. This allows you to check the key value and verify that this is the
correct key you intend to program into the device.
X-Ref Target - Figure 2
Figure 2:
BBRAM Programming GUI
After successfully programming the NKY file into the FPGA via JTAG, the TCL console reports the
following:
set_property ENCRYPTION.FILE
{C:/config/series-7/Encryption/ecryption_test_325T.runs/impl_1/top.nky} [get_property
PROGRAM.HW_BITSTREAM [lindex [get_hw_devices] 0]]
program_hw_devices -key {bbr} [lindex [get_hw_devices] 0]
INFO: [Labtools 27-3088] BBR Key programmed:
12345678ABCDDCBA12345678ABCDDCBA12345678ABCDDCBA12345678ABCDDCBA
INFO: [Labtools 27-3087] Key programming succeeded
INFO: [Labtools 27-3087] Key programming succeeded
XAPP1239 (v1.0) April 15, 2015
www.xilinx.com
9
Loading an Encryption Key and Encrypted Bitstream
Program eFUSE Registers
When Program eFUSE Registers is selected, a Wizard appears and guides you through the
process of selecting the NKY file and the eFUSE registers you want to program. The eFUSE
Programming GUI/AES Key Setup is shown in Figure 3.
X-Ref Target - Figure 3
Figure 3:
eFUSE Programming GUI (AES Key Setup)
IMPORTANT: For 7 series FPGAs, programming the AES key and the lower 8 bits [7:0] of the FUSE_USER
register occurs at the same time. Therefore if you program the AES key and do not specify a pattern for the
FUSE_USER [7:0] bits, they cannot be programmed at a later time. Similarly, if you program the lower
FUSE_USER bits and not the AES key then you cannot program the key at a later time.
RECOMMENDED: Program all 32 bits of the FUSE_USER register when you program the AES key. Refer to
Table 4, page 5 for a description of the FUSE_CNTL register bits. The eFUSE Programming GUI/Control
Register Setup is shown in Figure 4).
X-Ref Target - Figure 4
Figure 4:
eFUSE Programming GUI (Control Register Setup)
The Tcl commands for programming the eFUSE registers are as follows:
•
AES Key and entire 32 bits of FUSE_USER:
program_hw_devices -key {efuse} -user_efuse {xxxxxxxx} [lindex [get_hw_devices] 0]
•
FUSE_CNTL bits:
program_hw_devices -control_efuse {xxxxxx} [lindex [get_hw_devices] 0]
XAPP1239 (v1.0) April 15, 2015
www.xilinx.com
10
Loading the Encrypted Bitstream
After the eFUSE registers have been successfully programmed you can see the values of the
FUSE_CNTL and FUSE_USER registers in the Hardware Device Properties/EFUSE register
dropdown menu (see Figure 5), or by typing the following Tcl commands into the Tcl console:
•
For the FUSE_CNTL register:
report_property [lindex [get_hw_device] 0] REGISTER.EFUSE.FUSE_CNTL
•
For the FUSE_USER register:
report_property [lindex [get_hw_device] 0] REGISTER.EFUSE.FUSE_USER
X-Ref Target - Figure 5
Figure 5:
Hardware Device Properties/EFUSE Register Dropdown Menu
Loading the Encrypted Bitstream
After the device has been programmed with the correct encryption key, the device can be
configured with an encrypted bitstream. After the configuration, it is not possible to read the
configuration memory through JTAG or SelectMAP readback, regardless of the bitstream
security setting. While the device holds an encryption key, a non-encrypted bitstream can be
used to configure the device (only if the CFG_AES_ONLY bit is not programmed) and only after
POR or PROGRAM_B is asserted, thus clearing out the configuration memory. In this case the
key is ignored. After configuring with a non-encrypted bitstream, readback is possible (if
allowed by the bitstream security setting). The encryption key still cannot be read out of the
device, preventing the use of Trojan Horse bitstreams to defeat the 7 series FPGA encryption
scheme.
Most methods of configuration are not affected by encryption. The 7 series FPGAs allow for
bitstreams to be created with both compression and encryption. An encrypted bitstream can be
delivered through any configuration interface: JTAG, serial, SPI, BPI, SelectMAP, and ICAPE2.
However, an encrypted bitstream has a few limitations or timing differences for some of the
configuration methods. The Slave SelectMAP and ICAPE2 interfaces accept encrypted
bitstreams only through the x8 bus (x16 and x32 Slave SelectMAP are not allowed). The Master
SelectMAP and Master BPI interfaces accept encrypted bitstreams through either the x8 or x16
data bus, but for the x16 bus width, the master CCLK frequency is slowed to half of the
ConfigRate, or half of the EMCCLK rate when ExtMasterCCLK_en is used. The slower CCLK
begins early in the bitstream when the DEC (AES encryptor enable) bit is read, before the CCLK
is updated based on the ConfigRate frequency or the external EMCCLK frequency.
XAPP1239 (v1.0) April 15, 2015
www.xilinx.com
11
Loading the Encrypted Bitstream
The encrypted bitstream must configure the entire device because partial reconfiguration
through the external configuration interfaces is not permitted for encrypted bitstreams. After
configuration, the device cannot be reconfigured without toggling the PROGRAM_B pin,
cycling power, or issuing the JPROGRAM or IPROG instructions. Fallback reconfiguration and
IPROG reconfiguration are enabled in 7 series FPGAs after encryption is turned on. Readback is
available through the ICAPE2 primitive. None of these events reset the key if VCCBATT or VCCAUX
is maintained. A mismatch between the key in the encrypted bitstream and the key stored in the
device causes configuration to fail with the INIT_B pin pulsing Low and then back High if
fallback is enabled, and the DONE pin remaining Low. The HMAC_ERROR bit in the
Config_Status register also flags if an error occurs.
To confirm in hardware that the encrypted design loaded successfully, check that the DONE pin
is High or verify using other visual indicators that your design is functioning (LEDs, UARTs, etc.).
To confirm in software that the encrypted design loaded successfully you can refer to the
Config_Status register included in the Hardware Device Properties list. Bits 1
(DECRYPTOR_ENABLE), 4 (EOS), and 14 (DONE_PIN) are the main indicators for confirmation
(see Figure 6).
X-Ref Target - Figure 6
Figure 6:
XAPP1239 (v1.0) April 15, 2015
Device Status Register
www.xilinx.com
12
Hardware Verification
Hardware Verification
You will most likely want to verify that the AES key was properly programmed into either the
BBRAM or eFUSE bits properly. The following is a check list of verification steps:
1. Generate bitstreams using Vivado Design Suite 2014.3.1 or later: Unencrypted bitstream,
encrypted bitstream with your personalized key, encrypted bitstream with an all-ones key,
finally an encrypted bitstream with an all-zeros key
2. Review the generated bitstreams to validate encryption took place. (See Figure 7, page 14
for an example of encrypted and unencrypted bit files.)
3. On an FPGA that has not yet had its eFUSE programmed:
a. Check hardware: Use Vivado Device Programmer to connect to the FPGA, download the
unencrypted BIT file via JTAG. Does the design function as expected?
b. Test FPGA decryptor: Download the encrypted BIT file with the all-zeros key (for eFUSE).
c. Test encrypted bitstream security: Download the encrypted BIT file with your
personalized key. A configuration failure is expected.
4. Program the eFUSE key and options:
a. Power-cycle the board to assure any errors from the above tests have been cleared from
the FPGA and that the FPGA is not configured.
b. Program the AES key via JTAG. (If using eFUSE, first do steps 3b and 3c with the BBRAM
key as a validation check. Then program the eFUSE for a final test.)
c. Check key cannot be read: Use the Vivado tool to check the Hardware
Device>Property>Registers>eFUSE>FUSE_CNTL and that bit 3 is programmed to 1.
Also, check that the other FUSE_CNTL bits are programmed as selected during the
programming operation.
5. On the FPGA with the programmed eFUSE key and options:
a. Test key: Download the encrypted BIT file with your personalized key.
b. Test key: Download encrypted BIT file associated with the all-zeros key. A configuration
failure is expected.
c. Test key settings: Download the unencrypted BIT file. Results vary depending on
security settings.
Conclusion
This application note describes AES encryption and authentication standards and identifies the
advantages and disadvantages of the different key storage options available. Most importantly,
it functions as an easy how to guide to create an AES encryption key and an encrypted bit file
and to program these files into a 7 series FPGA using Vivado Design Suite software.
XAPP1239 (v1.0) April 15, 2015
www.xilinx.com
13
Appendix A: Encrypted and Unencrypted Bitstreams
Appendix A: Encrypted and Unencrypted Bitstreams
The difference between an encrypted bit file and unencrypted bit file is shown in Figure 7.
X-Ref Target - Figure 7
Unencrypted bit file
Encrypted bit file
Figure 7:
XAPP1239 (v1.0) April 15, 2015
Encrypted and Unencrypted Bit Files
www.xilinx.com
14
References
References
1. Developing Tamper Resistant Designs with Xilinx Virtex-6 and 7 Series FPGAs (XAPP1084)
2. 7 Series FPGAs Configuration User Guide (UG470)
3. Using Advanced Encryption Standard Keys with the Battery-Backed (BBRAM Tutorial
http://www.xilinx.com/training/vivado/using-encryption-keys-with-bbram.htm
Revision History
The following table shows the revision history for this document.
Date
Version
04/15/2015
1.0
Revision
Xilinx initial release.
Please Read: Important Legal Notices
The information disclosed to you hereunder (the "Materials") is provided solely for the selection and use of Xilinx products. To the
maximum extent permitted by applicable law: (1) Materials are made available "AS IS" and with all faults, Xilinx hereby DISCLAIMS ALL
WARRANTIES AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether in
contract or tort, including negligence, or under any other theory of liability) for any loss or damage of any kind or nature related to,
arising under, or in connection with, the Materials (including your use of the Materials), including for any direct, indirect, special,
incidental, or consequential loss or damage (including loss of data, profits, goodwill, or any type of loss or damage suffered as a result
of any action brought by a third party) even if such damage or loss was reasonably foreseeable or Xilinx had been advised of the
possibility of the same. Xilinx assumes no obligation to correct any errors contained in the Materials or to notify you of updates to the
Materials or to product specifications. You may not reproduce, modify, distribute, or publicly display the Materials without prior written
consent. Certain products are subject to the terms and conditions of Xilinx's limited warranty, please refer to Xilinx's Terms of Sale which
can be viewed at http://www.xilinx.com/legal.htm#tos; IP cores may be subject to warranty and support terms contained in a license
issued to you by Xilinx. Xilinx products are not designed or intended to be fail-safe or for use in any application requiring fail-safe
performance; you assume sole risk and liability for use of Xilinx products in such critical applications, please refer to Xilinx's Terms of
Sale which can be viewed at http://www.xilinx.com/legal.htm#tos.
Automotive Applications Disclaimer
XILINX PRODUCTS ARE NOT DESIGNED OR INTENDED TO BE FAIL-SAFE, OR FOR USE IN ANY APPLICATION REQUIRING FAIL-SAFE
PERFORMANCE, SUCH AS APPLICATIONS RELATED TO: (I) THE DEPLOYMENT OF AIRBAGS, (II) CONTROL OF A VEHICLE, UNLESS THERE
IS A FAIL-SAFE OR REDUNDANCY FEATURE (WHICH DOES NOT INCLUDE USE OF SOFTWARE IN THE XILINX DEVICE TO IMPLEMENT THE
REDUNDANCY) AND A WARNING SIGNAL UPON FAILURE TO THE OPERATOR, OR (III) USES THAT COULD LEAD TO DEATH OR
PERSONAL INJURY. CUSTOMER ASSUMES THE SOLE RISK AND LIABILITY OF ANY USE OF XILINX PRODUCTS IN SUCH APPLICATIONS.
© Copyright 2015 Xilinx, Inc. Xilinx, the Xilinx logo, Artix, ISE, Kintex, Spartan, Virtex, Vivado, Zynq, and other designated brands
included herein are trademarks of Xilinx in the United States and other countries. All other trademarks are the property of their
respective owners.
XAPP1239 (v1.0) April 15, 2015
www.xilinx.com
15