cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
8,628 Views
Registered: ‎03-21-2014

Fallback and Encryption in Kintex7

Hopefully someone can offer some guidance ...

 

I'm trying to implement a Fallback reconfiguration strategy with an encrypted bitstream in a Kintex7.

 

I've successfully done it without encryption by setting the "-g configFallback" and related switches in Bitgen for the Golden design and locating the Update design in the upper regions of the SPI Flash (N25Q256).  However, if I use an encrypted Update design, configuration always falls back to the Gold design with a Watchdog Time Out Error indicated in BOOTSTS(1).

 

In UG470 (7 Series FPGAsConfigurationUser Guide) on page 83 it states "Fallback reconfiguration and IPROG reconfiguration are enabled in 7 series FPGAs after encryption is turned on."   However, it doesn't appear possible to encrypt the Golden design since Bitgen dosn't allow both encryption and fallback to be simultaneously selected.  What is the procedure to make this work?

 

I can live with a non-encrypted Golden file, but the Update image must be encrypted.

 

Thanks in advance for any assistance.

 

0 Kudos
3 Replies
Highlighted
Scholar
Scholar
8,622 Views
Registered: ‎02-27-2008

s,

 

Simply stated, doing what you wish represents a potential security vulnerability (vector for attack) that we do not wish to even consider, so it is not possible.

 

However, once a design has been successfully decrypted, if that design wants to make use of the ICAP feature to reconfigure the part, then that is perfectly acceptable.  It that case, you fully understand that you have now opened the door to an attack, and it is up to you to design your system to be secure.

 

Best security practices require the simplest possible scenarios, with as few options as possible.  We chose to implement the decryption in a way that exposes the least to attack.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
Highlighted
Visitor
Visitor
8,617 Views
Registered: ‎03-21-2014

Hi Austin,

 

Thanks for the quick response, but can you please elaborate on the what you've called a vulnerability as I'm not clear on how that is the case.

 

I'm trying to create a "safe" field upgrade option using fallback configuration. That way if there is a power interruption or other failure during the upgrade, the Gold design will still allow the FPGA to configure, communicate, and begin another update cycle.  I can create a Gold design that doesn't include any proprietary IP, just enough logic to perform the udate if it's not possible to encrypt the gold design.

 

Under normal conditions, the fallback header would do an IPROG jump to the encrypted Update design.  Wouldn't I then have all the benefits of an encrypted bitstream?

 

Thanks,

Steve C

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,600 Views
Registered: ‎07-31-2012

Hi,

 

Under normal conditions, the fallback header would do an IPROG jump to the encrypted Update design.  Wouldn't I then have all the benefits of an encrypted bitstream?

A: Yes, but fallback from bitstream with encryption is not allowed. The tool also does not allow it.

 

Because the encryption and decrytion happen with a single bitfile and a single encryption key. 

 

However if you are looking for fallback using ICAP logic, then it should be possible, however it would pose security risks. Read through the topic in the user guide to understand better "Bitstream Encryption and Internal Configuration Access Port (ICAPE2)" 

 

The Internal Configuration Access Port (ICAPE2) primitive provides the user logic with
access to the 7 series FPGA configuration interface. The ICAPE2 interface is similar to the
SelectMAP interface, although the restrictions on readback for the SelectMAP interface do
not apply to the ICAPE2 interface after configuration. Users can send an unencrypted
partial bitstream or can perform readback through the ICAPE2 interface even if bitstream
encryption is used. Unless the designer wires the ICAPE2 interface to user I/O, this
interface does not offer attackers a method for defeating the 7 series FPGA AES encryption
scheme.

Thanks,
Anirudh

PS: Please MARK this as an answer in case it helped resolve your query.Give kudos in case the post guided you to a solution.