How to implement an open IP encryption flow

Not surprisingly, due to the fact that each IP block represents a considerable amount of time and investment, the IP vendors wish to guard their secrets. The way this is achieved is to encrypt the source, which means encoding it so as to make it unintelligible to unauthorized parties.

The problem is that, at the time of this writing, there is no standard for encryption and decryption in electronic design flows that facilitates industry-wide interoperability. As a result, different IP vendors and EDA vendors have employed a variety of proprietary schemes. In turn, this has resulted in a huge support burden on the various organizations, it is confusing to the end user, and it can result in a lack of consistency (simulating one version of the IP block and synthesizing a different version, for example).

In order to address this issue, the scientists and engineers at Synplicity have invented (and implemented) an open IP encryption environment that will facilitate the use of protected IP throughout the design flow: from IP vendor to EDA vendor to silicon vendor.

This paper first discusses where the various encryption and decryption steps occur in the design flow. Next, it introduces the conventional encryption techniques – specifically symmetric and asymmetric encryption algorithms – and explains the problems associated with these approaches in the context of an electronic design flow. Finally, a hybrid symmetric-asymmetric open solution is described that leverages existing technology, that fully addresses the needs of modern electronic design environments, and that would be easy to adopt by IP, EDA, and silicon vendors.

Encryption and decryption steps in the design flow
Before we introduce the various encryption/decryption options in detail, it's important to understand where these activities occur in the design flow. As an example, let's consider the encryption and decryption activities with regard to the synthesis component of an FPGA flow as illustrated in Fig 1.

1. Encryption and decryption activities with respect to
the synthesis portion of an FPGA design flow.
(Click this image to view a larger, more detailed version)

The IP block, whose function is typically captured as a Register Transfer Level (RTL) representation, is originally encrypted by the third-party IP vendor [Fig 1(a)]. This encrypted block is subsequently passed to the to the customer's design team. The design team will typically combine this block with other IP blocks and with its own custom-generated RTL to create a representation of the entire design. The team will then use synthesis tools from an EDA vendor to translate this design into a gate-level netlist [Fig 1(b)]; later, they will use the place-and-route tools provided by the FPGA vendor to generate the configuration bit-stream that will ultimately be used to configure (program) the FPGA [Fig 1(c)].

Once again, Fig 1 focuses on the synthesis-related activities in the flow. As will be discussed later in this paper, it may be required for the encrypted IP block to be used by multiple EDA tools – such as synthesis and simulation – which are often supplied by different vendors.

In the case of synthesis, our example block – along with other IP blocks – is first decrypted and then synthesized along with any unprotected portions of the design. In many cases, the ensuing netlist – or at least the portions of the netlist representing the protected IP functions – will be re-encrypted before being fed forward to the FPGA vendor's tools (we will discuss this point in more detail later). It is important to note that all decryption, data manipulation, and encryption activities take place inside the synthesis application itself; the unencrypted IP is never accessible by the user, the encrypted files are decrypted in memory only (no disk storage), and the decryption is performed on small blocks so as to thwart hacking via memory dump techniques.

Following synthesis, the encrypted netlist is passed to the FPGA vendor's tools. Once again, any protected portions of the netlist are first decrypted before being processed by the place-and-route engines. The final step in Fig 1 shows the encryption of the bitstream generated by the silicon vendor's place-and-route application. In this case, the place-and-route tool may encrypt either the entire bitstream or only those portions of the bitstream representing the protected IP. This step falls under the responsibility of the FPGA vendor's tools, it is a function of the underlying FPGA architecture, and it is not further considered in this paper.

An ASIC design flow is very similar to the FPGA flow illustrated in Fig 1. The ASIC flow will, however, include many verification steps that are not present in the FPGA flow; each of these steps will require the use of an EDA tool, and each of these tools may come from a different EDA vendor. Furthermore, in the case of an ASIC flow, the output from the place-and-route engines will be the GDSII files that are used to create the photo masks, which are in turn used to fabricate the device. These files are typically not encrypted at the present time; having said this, the methodology proposed in this paper could easily be applied to this content.

The problems with current encryption methodologies
There are two major classes of encryption/decryption algorithms, which may be classed as symmetric and asymmetric. As will be discussed, each of these techniques has associated advantages and disadvantages.

Symmetric encryption: In order to encrypt a source file, the encryption algorithm uses a special number known as the key. The value of this key modifies the detailed operation of the algorithm; that is, the way the contents of the original file will be "scrambled up." This means that if the same file is encrypted using two different keys, the results will be totally dissimilar. Algorithms and keys are created in such a way as to make "cracking the code" by unauthorized parties as difficult as possible. The point is that, in order to open the encrypted file and access its data, the end user also requires access to an appropriate key.

Historically, encryptions algorithms have primarily been of a type known as symmetric. This means that the same key is used to encrypt and decrypt the file (Fig 2). The advantage of this technique is speed due to its relatively low computational requirements. Using a modern computer, encrypting even a large file using a symmetric algorithm takes only seconds, and the time taken to decrypt the file when it is accessed by an application such as synthesis is unperceivable to the user.

2. A symmetrical encryption algorithm requires the originator
to communicate the key to the end user.
(Click this image to view a larger, more detailed version)

Examples of this type of algorithm are the Data Encryption Standard (DES), whose specification was first published in 1977, Triple DES [also known as TDES or TDEA (Triple Data Encryption Algorithm), which involves using DES three times], and the more sophisticated Advanced Encryption Standard (AES), which was adopted in 2001.