cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
philipadavid
Visitor
Visitor
8,449 Views
Registered: ‎08-07-2015

iMPACT & encrypted bitstream configuration

Jump to solution

Hello,

 

I'd like to generate a .xsvf file for programming a Zynq bitstream, but I get an error in iMPACT saying that this is impossible for encrypted bitstreams:

 

ERROR:iMPACT - Encrypted bitstream configuration via JTAG is not supported for Zynq devices.

 

This is quite confusing, since you can program encrypted Zynq bitstreams just fine using Vivado's Hardware Manager over JTAG (with a Platform Cable, for example). Unencrypted bitstreams, on the other hand, work just fine.

 

Is there any way to generate an XSVF or SVF from an encrypted Zynq bitstream?

0 Kudos
1 Solution

Accepted Solutions
philipadavid
Visitor
Visitor
15,638 Views
Registered: ‎08-07-2015

austin,

 

Interesting solution, I didn't realize that was possible. I'd like to clarify a few things though:

 

Does the method of bitstream delivery particularly matter? It sounds like the only options are Ethernet or SD card, maybe QSPI to store it in Flash like you mentioned...

 

Would you program the Zynq to accept an encrypted bitstream the usual way, by setting the BITSTREAM.ENCRYPTION properties through Vivado?

 

Can you expand on the requirements of using TrustZone and why this is necessary? The Zynq TRM keeps referring to WP429 and UG1019, the first of which I understand to be protected by NDA.

 

In the end, doesn't this leave the PS doing all of the heavy lifting for bringing up the PL? Is there specifically a way to securely program the PL via a controller external to the Zynq SoC, such as an external microprocessor, versus piping the bitstream to the PS first and having the PS configure the PL?

 

Thanks!

 

 

View solution in original post

0 Kudos
7 Replies
austin
Scholar
Scholar
8,446 Views
Registered: ‎02-27-2008

p,

 

The security model Xilinx supports is to have the processor system program the FPGA.  As such the encrypted bitstream is in the FSBL, and programming happens securely only throough the PCAP.


No other security model is supported.


Not because it will not work, only because we cannot test everything in every mode (understand and limit all vulnerabilities).  So, only the method just described is fully supported.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
philipadavid
Visitor
Visitor
8,439 Views
Registered: ‎08-07-2015

austin,

 

Thanks for your quick reply. In the case of the Zynq, then how would you recommend securely programming the device from an external microprocessor? The 7-Series Configuration guide mentions that  

 

"...an encrypted bitstream can be delivered through any configuration interface: JTAG, serial, SPI (including x1, x2, and x4 modes), BPI, SelectMAP, and ICAPE2"

 

Though the Zynq Technical Reference Manual makes no indication of support for Slave SPI, SelectMAP, etc. Is there any way to securely program the Zynq through an external controller? What interface could you use, if any, to pipe data from an external controller to the PS to allow secure bring-up of the PL?

 

Thanks!

0 Kudos
austin
Scholar
Scholar
8,407 Views
Registered: ‎02-27-2008

p,

 

Simple.  I would send the encrypted bitstream to the Zynq processor system (store it in DDR memory, or in a flash).


Then it is trivial (at least in linux is running) to cat the file directly to the configuration memory, which is built into the linux as a device.

 

http://www.xilinx.com/support/answers/46913.html

 

As this goes through the PCAP, to ICAP, it will go to the decryptor in the PL.

 

Securely getting the processor to do this then requires the FSBL was encrypted to start with, and the access to command this is secure.  Use of ARM TrustZone (tm) is required.  The layer to prevent just any bistream from being loaded should validate the request, autheticate the request, and then performa has to check the file is not corrupt.


Doing all of this at the c program level, or in the linux shell (for example, only root has this capability) is far easier than designing a lot of logic, and then hoping you have not introduced insecurities.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
philipadavid
Visitor
Visitor
15,639 Views
Registered: ‎08-07-2015

austin,

 

Interesting solution, I didn't realize that was possible. I'd like to clarify a few things though:

 

Does the method of bitstream delivery particularly matter? It sounds like the only options are Ethernet or SD card, maybe QSPI to store it in Flash like you mentioned...

 

Would you program the Zynq to accept an encrypted bitstream the usual way, by setting the BITSTREAM.ENCRYPTION properties through Vivado?

 

Can you expand on the requirements of using TrustZone and why this is necessary? The Zynq TRM keeps referring to WP429 and UG1019, the first of which I understand to be protected by NDA.

 

In the end, doesn't this leave the PS doing all of the heavy lifting for bringing up the PL? Is there specifically a way to securely program the PL via a controller external to the Zynq SoC, such as an external microprocessor, versus piping the bitstream to the PS first and having the PS configure the PL?

 

Thanks!

 

 

View solution in original post

0 Kudos
austin
Scholar
Scholar
8,393 Views
Registered: ‎02-27-2008

p,

 

1.  Yes.  Create an encrypted bitstream in the usual fashion.  I believe the tools allow this (.bin file encrypted with the key you select).  I know that since the format and method is public knowledge, folks who do not trust us write their own software to encrypt the bitstream.  Upon checking, they discover we are not doing anything different.

 

2.  The method for the Zynq PS+PL encrypts the FSBL, thereby creating a secure package for both PS and PL.

 

3.  Trust Zone allows you to set regions and peripjerals that may be read or written only by code that has that same attribute.  This prevents a user application from accessing that hardware.  Convenient to address attack vectors.

TrustZone is a feature of the ARM IP, and Xilinx has done nothing to modify it,  What it is, and how it works, and how to use it is public.

 

4.  Yes, the PS is in control, and it configures the PL, but the decryption of the bitstream is done inside the PL hardware, so the PL bits are never visible.  The PS is in control, but has no access to the PL bitstream in the decrypted form (unless you then do something stupid by having the PS read the bitstream back, and send it out totally bypassing all that wonderful security).

 

5.  And, no, there is no supported way to do otherwise.

Austin Lesea
Principal Engineer
Xilinx San Jose
philipadavid
Visitor
Visitor
8,388 Views
Registered: ‎08-07-2015

Thanks for your help, this has helped clear up quite a bit of my confusion!

0 Kudos
barriet
Xilinx Employee
Xilinx Employee
8,380 Views
Registered: ‎08-13-2007

Here's a few resources with supporting detail on Zynq secure boot:

http://www.xilinx.com/support/documentation/white_papers/wp426-zynq-7000-secure-boot.pdf (Secure Boot in the Zynq-7000 All Programmable SoC)

http://www.xilinx.com/support/documentation/user_guides/ug1025-zynq-secure-boot-gsg.pdf (Zynq-7000 All Programmable SoC Secure Boot Getting Started Guide)
http://www.xilinx.com/support/documentation/application_notes/xapp1175_zynq_secure_boot.pdf (Secure Boot of Zynq-7000 All Programmable SoC)

 

and a few others that are tangentially related:

http://www.xilinx.com/support/documentation/application_notes/xapp1223-crypto-key-change.pdf (Changing the Cryptographic Key in Zynq-7000 AP SoC)
http://www.xilinx.com/support/documentation/application_notes/xapp1224_secure_system_update.pdf (Updating a System Securely in the Zynq-7000 AP SoC)
http://www.xilinx.com/support/documentation/application_notes/xapp1225-rtic.pdf (Run Time Integrity and Authentication Check of Zynq-7000 AP SoC System Memory)
http://www.xilinx.com/support/documentation/application_notes/xapp1226-protecting-info.pdf (Protecting Sensitive Information in Zynq-7000 AP SoC)   

 

Cheers,

bt

0 Kudos