How to implement an open IP encryption flow

If each IP vendor used only a single key, then in the event that key is "leaked" or "cracked," all of the IP from that vendor would be compromised. Thus, in order to maximize security, each IP vendor is obliged to associate a unique key with each EDA vendor. Similarly, each EDA vendor needs to associate a unique key with each silicon/FPGA vendor. The end result is a morass of confusion, not the least that it's difficult to ensure that the same version of the IP is being used by all of the applications such as simulation and synthesis.

Furthermore, if the IP vendor decides to change a key and reissue that IP, users will have to wait until the next release of the EDA application (which has the keys from the various IP and silicon/FPGA vendors embedded inside it) is in production.

Every time an IP vendor proposes its own proprietary encryption scheme, it has to persuade the various EDA vendors to use it. Similarly, every time an EDA vendor proposes its own proprietary approach, it has to persuade the IP vendors, other EDA vendors, and the silicon/FPGA vendors to adopt it. The end result is that the industry is riddled with a mix of diverse and incompatible schemes, which drastically impede interoperability between the different applications in the design and implementation flow.

Asymmetric Encryption: In 1976, cryptographer Whitfield Diffie and electrical engineer Martin Hellman created a new form of encryption/decryption known as asymmetric. The "asymmetric" appellation is applied because the key used to decode the data is different to the key used to encode it. Although the DH (Diffie-Hellman) protocol is still used, a more general and more commonly used approach was described by MIT researchers in 1977; this system is known as RSA based on its discoverers' surnames (Rivest, Shamir, and Adleman).

Asymmetric schemes are also commonly known as public key encryption, because they rely on the use of two keys: a public key and a private key. The idea here is that the public key, which is the product of two prime numbers, is made available to everyone (or at least, to everyone who needs to know about it). This public key is used for encryption, but it cannot be used to decrypt the ensuing file; decryption requires access to the private key, which is one of the prime numbers used to create the public key.

For example, an EDA vendor such as Synplicity would create a public key and an associated private key. Synplicity would then make the public key available to all of the IP vendors, who would use it to encrypt their IP blocks. Synplicity would then use its private key (which would be embedded in its applications, and which – for security purposes – would itself be stored in an encrypted form inside these applications) to decrypt the IP from each of the vendors (Fig 3).

3. An asymmetrical encryption algorithm requires the end user
to generate public and private keys, and to provide the
public key to the folks performing the encryption.
(Click this image to view a larger, more detailed version)

In addition to the fact that they are harder to crack than their symmetric cousins, the main advantage of asymmetric schemes is that the key used to decode the file is not being passed around.

One disadvantage of this scheme is the fact that the IP vendor still has to create multiple encrypted copies of the IP block – one for each EDA vendor – which can result in the consistency problems noted earlier (simulating and synthesizing different versions of the IP, for example).

But perhaps the biggest disadvantage associated with asymmetric approaches is that they are extremely compute-intensive; for example, a large IP block can take several hours to encrypt or decrypt. This is a major inconvenience for the IP provider, and it's essentially a show-stopper for the end user. Consider a design containing several blocks of IP – it would be totally unacceptable to end users for each of these blocks to take several hours to decrypt prior to a simulation or synthesis run being able to commence.

The solution: A hybrid encryption flow
The solution to the problem of IP encryption is to employ a hybrid symmetric-asymmetric encryption/decryption flow. This entire solution may be referred to as the cryptosystem. Initially, let's consider the initial encryption performed by the IP vendor (Fig 4).

4. In a hybrid approach, the data is encrypted using a symmetric
algorithm, and then the key to the encrypted data is itself
encrypted using an asymmetrical algorithm.
(Click this image to view a larger, more detailed version)

First, the IP vendor encrypts the IP itself using an internally generated symmetric key [Fig 4(a)]. For the purposes of these discussions, we shall refer to this key as the data key. As was previously discussed, this form of encryption is extremely fast, even on large blocks of IP. The result from this step is known as the data block. It's important to note that the IP vendors are free to select the type of encryption they wish to use: DES, Triple DES, or AES (we shall return to this point a little later).

Next, the IP vendor takes the data key and encrypts it using the RSA algorithm and the EDA vendor's public key [Fig 4(b)]. The result is known as a key block. The IP vendor repeats this process to generate multiple key blocks, one for each EDA vendor, where each of these blocks is encrypted using that EDA vendor's public key. Although this form of encryption is inherently compute-intensive, the data key itself is very small, so the entire process takes only a fraction of a second.

Finally, the IP vendor bundles the data block and all of the key blocks into a single file, and communicates this file to all of the EDA vendors [Fig 4(c)].

Interestingly enough, this hybrid approach is the same technique as that employed by the PGP (Pretty Good Privacy) scheme, which was first published by Phil R. Zimmermann in 1991. However, although PGP is extremely popular, it is not applicable to an electronics design flow because its file format is proprietary and employing this technique would force the use of PGP throughout the flow. Furthermore, PGP is intended only for point-to-point communications and therefore supports only one key block. By comparison, the scheme proposed here supports a multiple-recipient usage model by means of multiple key blocks (note that the recipients are never obliged to share any secrets between each other).