Design Rights Management of Intellectual Property (IP) Cores in SoPC designs

Renaud Périllat-Amédée, Jérôme Rampon, Gael Paul, Algodone
Lionel Torres, Université Montpellier 2

Abstract:

This paper presents a Design Rights Management methodology used in a practical EDA tool suite: IP-Idol, developed by the start-up Algodone, based in Montpellier-France. It consists to encrypt and decrypt Hardware Description Language models (following IEEE 1735 and part of IEEE 1800 standards) of some Intellectual Property Cores (IP) in SoPC (System on Programmable Chip) with a strategy model where Algodone plays the role of a trusted third party.

In a context of extending IP-Reuse market in design conception, the main objective of this tool suite is to strengthen the security of Intellectual Property Cores and simplify the interoperability between IP vendors, IP customers and EDA tool vendors. It proposes a better management of Design Rights associated to IP Cores including traceability efforts from the final designs of IP customers back to IP vendors.

This work has been developed conjointly between the company Algodone based in Montpellier, France and the University of Montpellier 2, France.

1. Introduction:

IP vendors face complex challenges as keeping hidden the internal knowhow of their designs to control the source of their revenue. In addition, it is very hard for them to trace their IP HDL models down to the final customer hardware designs. A license per unit scheme remains a dream at the moment. In these conditions, it is not trivial to propose a fine and adequate pricing of their IP cores without any automated control of the final number of design units. It includes lawyer agreements’ costs and a confidence relationship with their customer.

Some standardization efforts have been made in recent years via IEEE 1735 extending cryptography parts of IEEE 1800 (System Verilog) to any type of files. This derives cryptography to propose a solid obfuscation of the original models. It is a real improvement with a range of security strategies pretty large but in practice, these norms have been slowly adopted and packaging IP is still a complex task. At minimum, it consumes too much time. Furthermore, no real automation exists to provide traceability down to final design unit.

2. Background and Motivation:

IEEE 1735 (and partially IEEE 1800-SystemVerilog) proposed various cryptographic features. Additionally, it proposed two main strategies to package IP that are illustrated in Fig 1.

Fig 1 – IP encryption packaging.

First strategy locks the encryption to a specific EDA vendor with the counterpart that the IP model needs multiple encryptions to interact with multiple EDA tools. This multiplication generates various negative points for IP vendors: resources, time, more potential errors, and security weaknesses.

Second one is more open to interoperability by encrypting data once with a symmetric encryption. Then, it multiplies, in different envelopes, an asymmetric encryption of the symmetric key (used for data encryption) with distinct asymmetric public keys (of maximum major EDA vendors if possible). This way, EDA vendor tools can perform decryption with their associate asymmetric private key. The IP model self contains all data for final decryption. Decryption is locally/internally performed by the EDA vendor tools. Flow flexibility is better but packaging still remains today cumbersome and expensive (multiple encryption engines to get access to distinct EDA vendor public keys and low EDA flow changes).

We propose a first simple improvement in that flow described in Fig 2.

Fig 2 – Algodone IP-Idol flow.

Algodone developed an encryption engine and a decryption SDK. The encryption engine minimizes the IP packaging to a single run. A unique asymmetric public key is necessary (IP vendor linked). This way, the IP packaging is immediately simplified (with minimal resource needs). On the other side, the developed SDK has to be interfaced and included in EDA vendor tools. The main idea consists to outsource all encryption/decryption tasks from EDA vendor tools and makes Algodone a trusted third party. It simplifies IP packaging and provides flow flexibility as long as EDA tools include IP-Idol as a “must-have”. Additionally, all the attention Algodone brought on the quality of the encryption/decryption implementation in IP-Idol is a plus. Indeed, the current multiplication of decryption engines offers, today, security weaknesses.

In final, using IP-Idol allows to centralize IP licensing (part of IEEE 1735&1800 but can be delegated to IP-Idol decryption SDK). It can also serve to implement reporting, by collecting back to IP vendors, data on EDA vendor tools traffic, in IP customer sites. In next paragraphs, we detail the benefits of Algodone’s model. Then, we deepen the different security modes proposed by Algodone to insure a more or less strict trusted third party model. Later, we review some optimisations of IP-Idol to justify the quality of the implementation. Finally, we address the licensing and reporting features.

3. Benefits:

The IP interoperability model proposed by Algodone as a trusted third party is a novelty. Three actors are involved: IP vendors, IP customers and EDA vendors. It makes sense for EDA vendor tools to outsource the encryption/decryption as they did for HDL compilers (Verific, …), license checking (FlexLM, …), design viewer (ConceptEng, …). It is a source of cost reduction as this currently requires resources, expertise and maintenance out of their core business. It essentially increases IP vendors satisfaction but indirectly EDA vendors. For IP vendors, the simplification of packaging is the first direct gain. In addition, the security is reinforced with a single provider on this sensitive feature. Finally, global automation of licensing and reporting on EDA tool traffic permit to lower and tune IP cost. For IP customers, it is transparent and the IP cost tuning is an indirect benefit.

4. Trusted third party

Fig 2 detailed how Algodone proposes a trusted third party flow. The asymmetric public key is IP vendor related. A first level of security relies on IP vendor confidence in Algodone by using Algodone own keys whose main advantage is to obtain a good security solution through IP self-containment. For some IP vendors and design flow or customer specificity, this may not be a sufficient level of security. Algodone extended the model to a higher level of security described in Fig 3.

Fig 3 - Strict trusted third party IP-Idol mode.

In this model, the asymmetric private key is a new output of the IP packager. As a private key, it is protected and encrypted by some asymmetric Algodone public key. It can only be read by Algodone decryption engine. The IP model does not contain any more full self-contained decryption data but the trusted third party model is stricter. Indeed, anyone who accesses the encrypted IP model (including Algodone) is unable to use it without that separate encrypted key. The encrypted key is generated in IP vendor site. IP vendor has full latitude to distribute it separately to whoever is licensed. It is then included in a configuration file used by Algodone ‘s decryption engine to get access to the final symmetric key with an additional step described in the second part of Fig 3.

For IP vendors concerned by self-containment in IP model or by security to send a key encrypted by Algodone,, a last mode is available. It is described in Fig 4.

In this mode, the IP vendor has the opportunity to over-encrypt the private key (already asymmetrically encrypted by Algodone). It can be through any encryption method. The encrypted result can be set in a configuration file, as normal encrypted private key, for Algodone decryption engine. It can here also be embedded in IP model as a specific Algodone IEEE 1735/1800 Meta-attribute. Then, Algodone decryption engine searches for IP vendor library in its distribution (to be sent by IP vendor to IP customer as a plugin). A decryption routine is called under the implementation/control of IP vendor. This way, only authorized IP customers can access the over-encryption through Algodone decryption mechanism.

Fig 4- Secured trusted third party mode.

5. Optimisations:

Any innovation in term of security model can be cancelled by a low quality of software implementation. It has been a constant concern at Algodone. In particular, the encryption/decryption engines have been optimized in term of performance to minimize runtime and memory consumption. For example, a thread implementation of the encryption/decryption engines optionally takes benefit of multicore processors running IP-Idol. It is based on the use of a pipeline design pattern. Details have been proposed in [3] and some runtime acceleration by 30% has been obtained on average for the different cryptographic algorithms retained by IEEE 1735/1800.

Security against attacks is another major topic. It does not make sense to detail the adopted countermeasures in a public paper but it is of course a permanent quest. The analysis of current IP packagers provided a lot of useful information to strengthen ours.

6. Licensing and reporting:

With Decryption SDK of Algodone, we have the opportunity to analyse the conception traffic using IP models. In addition, IEEE 1735 & 1800 included some licensing features for IP. They are specific license Meta attributes encrypted in the data block. This created a little confusion that encryption manages also licensing but they are two separate tasks. Encryption is mainly a sophisticated obfuscation mechanism. The receiver (IP customer) is not supposed to get access and decrypt directly the IP model. The encryption is used also to hide all the licensing data which is pertinent. In practise, the licensing of IP can also be delegated to Algodone decryption engine and bypass IEEE license Meta-attributes. Different level and refinement of feature names are possible: IP vendor, IP names, IP version …

Concerning reporting, it is a large topic that we just summarize. At the decryption level, in customer site, IP-Idol tool suite collects conception traffic data through EDA vendor tools calls. It does not pretend to analyse any hardware unit data as such information is not available at this level. The reporting combines a master Algodone’s database and synchronization process with a client-server application as described in Fig 5.

Fig 5 – Licensing, Reporting, Monitoring.

Of course, the database is IP customer local if no network connection is available not to lock EDA flows. A synchronization checking is, then, regularly performed to update Algodone ‘s master database in later Algodone’s decryption calls.

References

[1] IEEE_1800_2009 - “IEEE Standard for System Verilog – Unified Hardware Design, Specification, and Verification Language”.

[2] IEEE_1735 - “Recommended Practice for Encryption and Management of Electronic Design Intellectual Property (IP)”.

[3] SAME 2013 - Encryption and decryption of HDL files with a multi-threaded pipeline design-pattern. Renaud Périllat-Amédée, Jérôme Rampon, Algodone. Lionel Torres, University of Montpellier 2, LIRMM & Polytech Montpellier.

About the Authors

Renaud Périllat-Amédée completes his Polytech ERII engineering degree in 2013. He works for 1 year with Algodone (Montpellier-France) to develop compilers, encryption and decryption applications.

Jérôme Rampon is Algodone 's founder . He works in EDA for 20 years with synthesis, formal verification, and HDL compilation background. He worked for Synplicity, Synopsys, CompassDA, XST(Xilinx) and was founder of Veriphia start-up.

Gael Paul has over 16 years of experience in the Electronic Design Automation (EDA) and semiconductor fields. Gael has been involved in several companies including Mentor Graphics, Vector Fabrics, PLDA and Flexras. He was Vice President Software Engineering & Product Development at Achronix, Director of FPGA Synthesis Products at Synplicity and a Senior Design Consultant at Cadence Design Services.

Lionel Torres is Professor at the University of Montpellier 2, he is deputy head of Polytech' Montpellier, and he leads a research group at LIRMM Laboratory (UMR CNRS). He works on reconfigurable computing and system level architecture, with a specific focus in the security and cryptographic applications.