12-29-2015 11:09 AM
12-30-2015 12:17 PM
12-29-2015 02:09 PM
12-29-2015 04:29 PM
Thank you for your response. I agree that public/private key pair would be the secure solution for a remote upgrade.
However, I could not find any document where it is specificly mentioned if any of the Xilinx FPGAs use public/private key based encryption. From my understanding Xilinx FPGAs use symmetric key based encryption where both the key and the bitstream is sent to the device at the same time. Correct me if I am wrong.
If you have any of such reference/documents, kindly let me know.
12-29-2015 08:20 PM
12-30-2015 09:58 AM
Hi Muzaffer, as you mentioned "The keys are for all practical purposes permanently programmed to the FPGA and should not change at customers' premises at all."
I was wondering about a situation, where an FPGA is remotely operating in a system (like a car).
And suppose, the vendors decides to upgrade the system and designes a new IP and generates a new bitstream.
Now, to program the appropriate key for the new bitstream, the vendors would not get the system(like the car) near them.
Rather, they would have to send the new key and the bitstream wirelessly to the intended FPGA.
From your knowledge, do you think the Key is fixed for all the future upgrades? If yes, could you kindly add some reference?
Thank you for your time!
12-30-2015 10:48 AM
The decryption is covered in the configuration users guide,
One may provide for supporting a public/private key protocol using an additional layer of software and logic, but that also creates a back-door for an attacker, so you must be careful, and test the solution to be sure it is not a vulnerability. Even in an encrypted design, one may use the internal configuration access port (ICAP) to load a new (partial) bitstream. Obviously, one cannot load the entire bitstream, as the ICAP itself would get over-written, causing the update to stop.
Zynq devices with their ARM cores allow the programmable logic to be completely re-written, and the ARM cores may be used to support just what you describe. The feature is a vector for attack, so previous warnings still apply.
12-30-2015 12:17 PM
12-30-2015 01:36 PM
In case of a software or logic implemented public-private key protocol, exactly what kind of vulnerability do you think might exsist? (like side channel attack on the decryptor block, or brute force, etc.)
12-31-2015 12:17 PM - edited 12-31-2015 12:18 PM
A nation-state attack is not the same as a casual hacker attack. What threats are you looking at?
If the attacker knows you send updates, then they will try to intercept them, and reverse engineer the protocol. If you use an open source public/private key protocol, there is nothing to learn, so they will address physical weakness such as a side-channel attack, or a man in the middle attack. If you have used a well tested and trusted protocol, then it will be quite tough to crack it. If the have physical access, they will likely be able to observe the encrypted data which is of no help. You will need to disable JTAG (in Zynq the ARM has 100% control of JTAG, so if you do not allow access to the programmable logic, they are unable to read it back out unecrypted.
Contact your Xilinx FAE for assistance with the details. As our devices are present in many crypto systems today, we have a track record of use there. If you Google single-chip crypto you will see we were the first to be accepted and used.