Protecting Your IP Cores - Part 1 Soft IP, Section 1: Encryption of HDL Code

modemdesign

Protecting Your IP Cores - Part 1 Soft IP, Section 1: Encryption of HDL Code [Copy link]

Protecting Your IP Cores - Part 1 Soft IP, Section 1: Encryption of HDL Code

IEEE Std 1735 2014 IEEE Recommended Practice for Encryption and Management of IP HDL Source Code Protection

IEEE Std 1735 2014 IEEE Recommended Practice for Encryption and Management of Intellectual Property (IP) in Electronic Design.

The IEEE 1735 standard defines a convenient way to protect RTL source code.

Primary goal: interoperability across EDA tools

Source code protection has been tested with various EDA tools.

How can I encrypt a Verilog/VHDL file so that it can be simulated or synthesized without revealing the decrypted source file according to the IEEE 1735 standard?

The answer depends on which tools you want to be able to read the encrypted source directly without revealing the original source and which encryption formats they support. Many tool vendors now support the IEEE 1735-2014 encryption recommendation, enabling one vendor to encrypt and another vendor to decrypt the same design. If a vendor does not support the standard, you must contact that vendor to obtain their encryption tools.

Verilog/VHDL encryption is part of the 2005 standard and is now used by many vendors. You will need a tool that encrypts Verilog using this standard, and most of the big simulators do - Modelsim, IUS, and VCS. You can refer to the documentation of the individual tools for more information.

List of some commonly used IEEE 1735-compliant EDA tools:

Rhythm

Incisive, Xcelium, Genus

Intel Altera

quartz

Siemens Mentor Graphics

QuestaSim, model simulation

Xilinx

Vivado

ALDEC encryption tools: protectip / Active-HDL / Riviera-PRO

https://www.aldec.com/en/support/resources/documentation/articles/1650

https://firsteda.com/news/how-to-secure-your-ip-with-encryption/

Aldec supports encryption for both VHDL and Verilog. It was added to the Verilog standard in Verilog-2005 and became part of VHDL in 2008. Both HDL encryption methods are similar in that they use asymmetric encryption, i.e. you need a public key to encrypt and a private key to decrypt. Needless to say, you should not give out your private key.

ALDEC provides an executable file for the encryption tool called protectip, located in the bin folder of the simulator installation. You can run it from the console in Active-HDL or Riviera-PRO. To obtain the Aldec public key, refer to "ALDEC Public Key" in the Riviera-PRO or Active-HDL User Manual. However, if you use the Aldec IP Encryption Tool, you do not need to specify the public key. If the code encrypted by the ALDEC tool will also be used by other tools, the appropriate section containing the other tools' public keys and matching tags should be added to the source before encryption by the ALDEC utility. Since ALDEC is not authorized to distribute public keys belonging to other vendors and tools, IP creators should retrieve them from the current documentation of these tools or contact the tool vendor to obtain them.

Cadence VHDL source code encryption - Incisive, Xcelium, Genus

https://community.cadence.com/cadence_technology_forums/f/functional-verification/13649/vhdl-source-code-encryption

Incisive, Xcelium, and Genus do support the IEEE1753 standard for source code encryption.

What you need is to encrypt the file using ncprotect. The default protection mechanism uses a Cadence proprietary encryption algorithm and does not require a license. Cadence also supports the IEEE encryption mechanism. However, to invoke IEEE encryption, a license is required. To encrypt the file, you need to download and install the Incisive simulator toolset. 1) Download and install the Incisive simulator. 2) Once you have the tools installed, execute ncprotect with your vhdl file and include -autoprotect: ncvhdl myfile.vhd -autoprotect The above will result in full encryption (ports, names, hierarchy, etc...) The resulting file will have the same name as the input file, but with a .vhdp extension.

The ncprotect tool basically performs text encryption given an encryption algorithm and an encryption key. Since ncprotect uses the standard RSA library, various algorithms such as RSA, RC2, RC4, AES, DSA, etc. can be selected. The ncprotect tool is ported to various 32-bit and 64-bit platforms such as HP, Linux, IBM, Solaris, Windows, etc. Therefore, it becomes very convenient for various IP developers to use it.

Intel Quartus Prime Pro Edition Encrypted Verilog or VHDL Files

The Intel Quartus Prime Pro Edition software supports the IEEE 1735 v1 encryption standard for IP core file decryption. You can encrypt Verilog HDL or VHDL IP files using the encrypt_1735 utility or a third-party encryption tool that supports the IEEE 1735 standard. You can then use the encrypted files in the Intel Quartus Prime Pro Edition software and simulation tools that support the IEEE 1735 encryption standard.

The encryption keys are the same for Verilog HDL and VHDL. You can pass parameters to instantiations of encrypted modules in the same way as non-encrypted modules.

Public encryption keys are required only for file encryption using third-party tools. Public encryption keys are not required for file encryption using the Intel Quartus Prime Pro Edition software.

To encrypt a Verilog HDL or VHDL file using the Intel Quartus Prime Pro Edition software, use the command "encrypt_1735" located in the /quartus/bin folder.

encrypt_1735 <filename>.v --language=verilog --quartus

encrypt_1735 <filename>.vhd --language=vhdl --quartus

Note: The Intel Quartus Prime Standard Edition software does not support IEEE 1735 encryption.

IP Encryption Tools

https://ipencrypter.com/wp-content/uploads/2016/11/ipe1735v2-1610-1-0-ug01.pdf

IP authors can use the IP Encrypter tool to encrypt IP in accordance with the IEEE Std 1735-2014 (IEEE P1735 v2) standard. IP authors can provide protection levels through protection directives in the general and tool blocks. IP authors can select supported tools, each of which requires a public key.

The process of creating an encrypted IP through ipecrypt:

Create IP in plain text

Add protection instructions around the code to encrypt it or specify the instructions in a separate file

Run the ipecrypt application to generate an encrypted IP

Siemens Mentor Graphics QuestaSim, Modelsim

Siemens Mentor Graphics QuestaSim, Modelsim

ModelSim's encryption solution allows IP authors to deliver encrypted IP code to a variety of EDA tools and design flows.

ModelSim supports VHDL, Verilog, and SystemVerilog IP code encryption via protected encryption envelopes. VHDL encryption is defined by IEEE Std 1076-2008 Section 24.1 (titled "Protection Tool Directives") and Annex H, Section H.3 (titled "Digital Envelopes"). Verilog encryption is defined by IEEE Std 1364-2005 Section 28; SystemVerilog encryption is defined by IEEE Std 1800-2012 Section 34 (both sections are titled "Protected Envelopes"). The digital envelope usage model is the VHDL `protect

and Verilog's `pragma protection compiler directive.

ModelSim supports version 1 of the IEEE P1735-2014 working group recommendation for cryptographic interoperability between different encryption and decryption tools. It addresses usage models, algorithm selection, conventions, and minor amendments to HDL standards to achieve useful interoperability.

ModelSim uses two protected forms:

The first form is a text file that contains a transformed version of the input original plain text HDL source file.

The second form is a protected version of the design unit that you compiled.

The ModelSim vencrypt utility for Verilog and SystemVerilog only generates text files. It does not compile anything into libraries, nor does it process macros or handle the usual Verilog switches. In contrast, the Verilog/SystemVerilog compile command vlog +protect generates text files, compiles them into libraries, and processes macros (and all the other usual vlog parameters).

The ModelSim vhencrypt utility for VHDL works the same as the vencrypt utility (although VHDL does not have macros). The VHDL compilation command vcom +protect works the same way When you compile source code, you can use the vcom -nodebug or vlog -nodebug commands to hide the compilation results from the end user.

Synopsys IP Encryption and Deployment Suite VCS (Verilog Compiler and Simulator), VMC (Verilog Model Compiler), and VHMC (VHDL Model Compiler)

Synopsys offers a full suite of tools to handle IP encryption and deployment. Specifically for encryption, I recommend looking at the VCS (Verilog Compiler and Simulator), VMC (Verilog Model Compiler), and VHMC (VHDL Model Compiler) products. These convert the source RTL into a very secure encrypted package that can then be safely delivered to customers. The encrypted model can be plugged into most commercial simulators.

There is no trace of the original source in the deliverable model, so it cannot be "hacked".

Xilinx Vivado Design Suite IP Encryption

https://support.xilinx.com/s/question/0D52E00006hpVtJSAU/how-can-i-encrypt-rtl-source-file?language=en_US

https://support.xilinx.com/s/question/0D52E00006zybDsSAI/how-to-encrypt-my-ip-into-secureip-like-logicore-ip-in-xps?language=en_US

http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_4/sim.pdf

http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_2/irn.pdf

In Vivado 2016.3 and later, Xilinx has added the ability to encrypt HDL source files using IEEE 1735 v2 encryption. The Xilinx Vivado Design Suite supports encryption compliant with IEEE-1735-2014 version 2. IP encryption covers HDL (SystemVerilog, Verilog, VHDL) design entry through bitstream generation. IP authors can manage access to their IP by expressing how tools should interact with the IP. Protecting the bitstream itself requires encrypting the bitstream on a programmed Xilinx device, a step typically done by the IP user rather than the IP creator.

Although there are many formats for design source files, IEEE-1735-2014 applies only to Verilog, SystemVerilog, and VHDL formats. These RTL standards are also managed by the IEEE, and through mutual agreement, these standards will allow IEEE-1735 to define behavior in IP Security until the recommendations in IEEE 1735 can be modified to be included in the language.

Reference Manual (LRM). IEEE 1735 does not cover popular netlist formats such as EDIF.

IEEE-1735 v2 cryptographic functionality requires a license, which can be obtained by sending an email to xilinx_security_app@xilinx.com.

NOTE: The encryption license feature is tied to a specific Vivado version. When requesting a license, please provide the exact version of Vivado for which you need a license (e.g., 2016.3, 2016.4). Please make sure to use your company/corporate email address when requesting a license.

Protecting IP Cores with EDA and FPGAs – A Recommendation

This is a suggestion for protecting IP using EDA and FPGA design.

First, let's assume that the EDA software is trustworthy. The IP core designed by a third party must first be purchased from the EDA software developer at the RTL level. The third party encrypts the IP core with the public key of the EDA developer, and then uses the public key provided by the designer. In this way, although the designer obtains the third-party IP core, he does not know the private key of the EDA software developer, so the designer cannot know the RTL level description of the IP core.

Designers can treat purchased IP cores as black boxes with known functions. After completing the circuit description using the black box and other circuit modules, the designer imports the design into the EDA tool. The EDA tool decrypts the encrypted IP core twice using the key entered by the designer and the key of the EDA developer to obtain a complete RTL representation of the entire design. The EDA tool can then perform behavioral synthesis, logic synthesis, technology mapping on the design, and finally generate a netlist after technology mapping. Assume that the tools for synthesis and technology mapping are provided by the EDA developer, and the FPGA placement and routing tools are provided by another EDA developer, such as an FPGA manufacturer.

Before writing the optimized gate-level netlist to the file, the EDA tool first encrypts the netlist with its own private key, and then encrypts the netlist with the public key of the placement and routing tool provider. In this way, designers still cannot view the netlist after synthesis and technology mapping, thus preventing designers from stealing IP cores using reverse engineering.

The layout tool first decrypts the encrypted netlist with its own private key, and then uses the public key of the front-end EDA tool developer to perform a second decryption to obtain the decrypted netlist. Using this netlist, the layout tool can complete the layout of the design on the chip and finally generate a bit-stream file for FPGA configuration.

notes:

This article is part of the chapter “Part 17 IP Core Protection” in the book “Silicon IP – Not Just Design” by Mark Chen. You can also find more information at the following website.