04-03-2014 07:28 AM
We would like to encrypt rtl for customer IP validation. I have a tool that will perform IEEE P1735 encryption and I believe that Vivado could read it given that "The Vivado Design Suite 2013.3 leverages the IEEE P1735 standard...".
In order to properly encrypt for Xilinx/Vivado, however, I need the public key. Is that available?
04-03-2014 12:05 PM
checkout the files in any subdirectory under data\secureip. If you open up any of the encrypted files there, you will find the "key_owner = Xilinx" and key_block entries which is what you need I believe.
04-03-2014 08:57 PM
Please check a related discussion - http://forums.xilinx.com/t5/Design-Entry/How-can-I-encrypt-RTL-source-file/td-p/318337
Xilinx does not offer what you want yet We hope to be able to offer it by Vivado 2014.1 (This is not certain) The IEEE 1735 standard outlining this has not been finalized (Expected to be finalized latter part of 2013) Xilinx does share encryption keys under NDA with other software partners such as Synopsys, Mentor and Aldec, in order to allow for processing encrypted files between vendors Xilinx has an IP partner program that allows IP developers to deliver encrypted RTL. This is also under an NDA and requires a fair amount of qualification and sharing.
04-04-2014 07:21 AM
Okay, thanks for the response. I guess I just have to wait and hope that 2014.1 will offer what I need. I had seen the post you linked and presumed that the keys mentioned were private keys, so that Xilinx and its partners can test their encryption/decryption engines completely.
I'm curious now: Why the secrecy? A public key is intended to be *public*... why make it a trade secret? Aldec has published theirs on the web:
I can find the Synopsys key in their documentation. Xilinx itself has made some key information (but not P1735, it seems) available in the files that muzaffer pointed me at...
Even if Xilinx isn't ready to offer the encryption engine and/or integrate it with the toolset (I understand that the standard isn't ratified yet), I would think that sharing the public key would be a low-risk way of enabling customers and collaborators for the time being.
09-04-2014 02:07 PM
10-01-2014 11:20 AM
I really don't understand this reluctance to release an existing tool. What is needed is the public keys to be made public. If someone wants to write a simulator, I understand the hesitancy to give them the private keys to decrypt but letting people encrypt is such a simple task. Any clue you can give us why such a long delay?
10-07-2014 10:36 AM - edited 10-07-2014 11:55 AM
I should say, 2015.3 is more likely than 2015.1. There is not a firm commitment release that I know of.
I really don't know the details of what it takes to implement the standard.
I do know that it is version2 of the IEEE P1735 encryption standard that is required. For a long time we have been waiting for that version of the standard to be finalized. I also know that this is not the only item on the to-do list for the developers that will be taking care of this so work / schedule prioritization will take some affect. From what I understand, the developers will be building the infrastructure to support this (again I don't know what that entails) over the next several months. Then there will be a lot of testing.
They are not going to let it be released unless they are very confident in the security it will provide to users. I'm starting to sound like a Marketing manager so I'm going to stop there.
01-30-2015 10:28 AM - edited 01-30-2015 10:29 AM
Now that 1735 is standard is out, there is really no excuse for not releasing this tool which we known exists. Xilinx encrypts its own IP with it so they must be "very confident in the security it will provide to users" as the user it themselves.
10-22-2015 01:16 AM
I don't even want to encrypt an "IP CORE" I just want to encrypt a package.
The package contains a Initilisation vector for AES-CBC encryption used on the FPGA.
The package contains a salt value used in key expansion.
Surely there is something i can do to protect these constants.
I know with modelsim I can obsfucate the source code using `protect
Further still I can simulate with this obsfucated file.
Whereas within Vivado this obsfucated file is met with syntax errors & vivado will not synthesise
Can I do something similar? Will vivado be able to synthesis a protected document.
I can see you do something similar for your ip core.
11-03-2018 10:41 AM
The IEEE 1735 encryption flow was released beginning in 2016.3 versions of Vivado. My understanding of the delay between ratification of the Version 2 standard and release had more to do with the support from the 3rd party simulation vendors and the need to fully test all of the Xilinx encrypted IP with those vendor flows to ensure version 2 compliance. That's a lot of work for the hundreds of IPs in the Xilinx catalog.
This is all documented in UG 1118, for the specific version of Vivado with which you wish to encrypt. There are instructions in the UG for how to get access to the public keys for Xilinx, but you must contact the 3rd parties directly to get their public keys - every vendor wish to allow support must be included at the same time during encryption.
There is no separate tool for encryption. This is functionality that is integrated directly in Vivado, and accessed via a Tcl command.
See here if anyone is still interested: