A white paper of the VSI Alliance
http://vsi.org
Report and Recommendations of
the IP Encryption Workgroup:
1 White Paper, 2 recommendations, 3 Standards
October 2007
VSI Workgroup Contributors:
Jim Robinson and Dave Graubart, Synplicity
Devin Sundaram, Altera
Gary Delp, VSI, LSI
Steven Dovich, Cadence
Subroto Datta, Altera
David Tran, Synopsys
John Shields, Malathi Boypati, and Jaggi Balasubramian, Mentor
Nick Sgoupis, CAST
Jeff Klaben, SF bay Infragard
This version donated to the IEEE, see last page
© VSI Alliance
IP Encryption Workgroup
Report and Recommendation
This version donated to the IEEE, see last page
Page 2 of 23
IP Encryption Workgroup
Report and Recommendation
Contents
Preface......................................................................................................................................................................... 4
Introduction/Problem Statement............................................................................................................................... 4
Purpose of the Open IP Encryption Standard ......................................................................................................... 5
Protection & Rights flow and Principles of Operation ........................................................................................... 5
Use Models – Guidelines for the parties – Devin, Dave, Cast, et. al...................................................................... 7
IP providers ...................................................................................................................................................................... 8
Tool providers .................................................................................................................................................................. 8
Tool and IP users .............................................................................................................................................................. 8
Scope and non-Scope topics .................................................................................................................................... 8
Key management (exchange of keys is the responsibility of the IP Provider) ....................................................... 9
C, C++, SystemC issues ......................................................................................................................................... 9
Binary structured file issues ................................................................................................................................... 9
Parameter use issues/potential exposure ................................................................................................................. 9
Parts of the “Standard” ............................................................................................................................................. 9
Generic Encryption encapsulation standard – Dave ............................................................................................... 9
2. External rights file placement, reference, and security ............................................................................................... 10
Generic file encryption ................................................................................................................................................... 11
1 Overview ..................................................................................................................................................................... 12
2 Definitions ................................................................................................................................................................... 12
3 References ................................................................................................................................................................... 13
Supported algorithms ...................................................................................................................................................... 13
Rights Scope and Lifetime.............................................................................................................................................. 14
Hierarchy issues .............................................................................................................................................................. 14
VHDL (1076) and Verilog (1800) Language specific recommendations – Steve................................................ 14
Recommended profiles (recommended algorithms, rights block references) ................................................................. 15
Rights Scope and Lifetime – see grid next page ............................................................................................................. 15
Recommended extensions/changes................................................................................................................................. 15
Timeline of recommendation .......................................................................................................................................... 15
Rights Block Format (with extension capability) ................................................................................................. 15
Standard “Rights” definitions ............................................................................................................................... 16
References ................................................................................................................................................................ 22
Appendices .....................................................................................................................Error! Bookmark not defined.
This version donated to the IEEE, see last page
Page 3 of 23
IP Encryption Workgroup
Report and Recommendation
Preface
This white paper is prepared by members of the VSI Alliance IP Encryption workgroup as a collection of the
considerations and the current thinking and results. This collection is intended as a handoff of workgroup
thoughts, work product and is the bundle of copyright transfer to the IEEE Study/Work group names P1735.
This is not considered a complete work, but rather an exploration of the field with recommendations. The
handoff from this workgroup is not intended to bind the IEEE workgroup, but rather remove any particular
encumbrances that might have been generated by the work in the VSI Alliance workgroup. The appropriate
cover leters to transfer copyrights, etc are being or have been prepared to affect the transfer. Please refer to
those covering documents for definitive transfer.
There may be some inconsistencies of flow in this document with alternate callouts of recommendation,
standards, and formats. It is assumed that the primary use of this white paper is documentary in the P1735 work
group and timeliness is a primary driver of the release of the white paper as the content may be substantially
modified in the course of IEEE DASC workgroup activities and discussions.
Paragraphs that are included in blue formatting and Arial type face are comments and notes on the topics with
which they are associated. They include topics commended for consideration in future work.
Introduction/Problem Statement
There is an “Industry Need” for addition specification of encryption capabilities for IP, and specifically, there is
a need to have standards for the granting and denial of use rights for particular collections and pieces of IP by
particular tools and particular users.
Because we are operating in a disaggregated ecosystem of IP, where the production flow crosses trust
boundaries, mechanisms for the protection of IP value are needed. When these mechanisms are in place, they
will enable growth of the IP market by allowing control of the uses of transferred IP, where trust can be
provided in specified increments. This will lower one of the barriers for reuse, trust, while increasing the ability
of tools to optimize the inputs they are presented.
A standard for protected and targeted information exchange between providers, tools, and users is needed.
VHDL 1076 and Verilog 1364 (and 1800) already have encryption mechanisms in place, but there are some
limitations that additional work can beneficially extend. When the encrypted data is read into a tool, if the IP
provider can specify to the tool which uses are allowed, and what uses are prohibited, then if the tool is trusted,
the scope of exposure to the user is bounded by those uses.
The concept of rights is referenced in the current standard, but a common format for specification, and a
common set of rights would increase the security and lower the cost of implementation. Specification of use,
display, and output rights would benefit from a standard structure.
The specification of a standard set of use rights would simplify the use; some examples of these standardized
rights include:
 Simulate but not trace
 Simulate but not synthesize
This version donated to the IEEE, see last page
Page 4 of 23
IP Encryption Workgroup
Report and Recommendation
 Output in encrypted form
 Output in [specific] obfuscated form
 Output clear text
 etc.
The mechanism for obscuring and protecting the granted rights will benefit from standardization.
Additionally, there are other data formats that do not have any associated encryption standards or rights
semantics. The use of these formats in design flows would benefit from a generic or default IP Encryption
specification that can be used. Two compelling examples of these types of files are constraint input files that
provide constraint specifications for hidden parts of the IP, and EDIF input and output files.
Purpose of the Open IP Encryption Standard
The VSI Open IP Encryption Standard consists of formats and guidelines implementing IP protection in a class
of interoperable tool flows with IP and tools from a wide array of suppliers. This will include algorithm
selection for encryption and encoding. P1735 will specify a generic set of embeddable markup syntax suitable
for IP protection and rights management of arbitrary text files. These files represent potential inputs and
outputs of EDA tools that would otherwise expose IP.
Protection & Rights flow and Principles of Operation
The general flow supported by this standard is shown in the figure below:
Trusted Tool environment
Carry
Forward::
Rights
Tagged Blocks
Data
Rights
Data
Allowed
Operation::
filter
Input Data including:
• Clear text
• Protected Data
• Key Communication
• Rights Descriptions
• Associated Rights File
Request
Response
Output Data including:
• Clear text
• Protected Data
• Key Communication
• Rights Descriptions
• Associated Rights File
Schematic of Protected IP Data Flow
The elements of this flow are:
 The Design Input Data which may be delivered in bundles including:
o Clear text in a variety of files. This IP is not protected, and may be include all of the source,
manifest files, and/or portions of files.
o Protected Data: This is data which is encapsulated, potentially with envelope information. The
envelope information may include tagging information of that the provenance of the IP can be
traced from source, through the tool flow and on to the use of the data. The reader is referred to
both the historic work of the VSI and the ongoing activities in The SPIRIT Consortium. At the
This version donated to the IEEE, see last page
Page 5 of 23
IP Encryption Workgroup
Report and Recommendation

core of the encapsulation, the data is encrypted using a specific algorithm, seed, and key. The
decoding information is available either implicitly, or is communicated explicitly as part of the
key communication block.
o Key Communication: The key blocks are encrypted blocks, using the public keys of the trusted
tools that contain the keys to be used to decode the protected data that is part of the design input
data.
o Rights Description: This is the element added by the Synplicity and then the VSI work. The
rights description, used in combination with the trusted/qualified tool, ensures that the outputs of
the tool are only those that have been allowed by the IP provider.
o Associated Rights File: This file may contain rights blocks for one to many trusted tools and one
to many source files. The Protected Data and Key Information may refer to external associated
rights file.
The Trusted Tool Environment is the embodiment of qualified set of capabilities that includes ability to
decrypt the protected Data, Key Communication, and rights description and ensure the protection of the
data while processing the data. The capabilities of the trusted tool environment include:
o Read in, process, and tag the sections of input data with
Notes:
1. Privacy of tool-provider-specific rights in the external rights file:
I don't know that we've reached a conclusion on this. I think it is desirable from both a privacy point of view
(supports any confidential arrangements between IP provider and tool provider) and a reliability and liability
point of view (if Synplicity can't decrypt Altera's rights, there is no ability to make mistakes - Synplicity could
only copy the encrypted text). However, this may be something we could live without. This would be worth
finalizing either way as IP provider and Tool provider use models are affected. In particular, if we were to
support this, the external file would need a key block for each supported Tool provider that contained an
encrypted unique session key - one that was not in common with the key from other Tool providers.
2. Licensing as a third rights management method
I think licensing is among the things that can be specified either within Generic Rights or within External Rights,
rather than an independent third method. It might better represent the methods to either spell out all four
combinations, or state that licensing is allowed in both of Generic and External. This affects how and where IP
providers specify and license-enabled rights.
3. External Rights policies and file issues
I don't recall if we had closed on the policies of the External Rights file. I recommend that it be read-only for a
couple reasons. One relates to item #1 that if only the IP provider creates this file, nobody else can mess it up,
and I think it is reasonable to say that only the IP provider should be specifying any rights. Another reason is
file location. For the case that a Tool reads and writes to the same directory, we otherwise need to worry about
overwriting the original file or creating a specification or convention for naming the new External Rights file. (To
be reviewed toward the end of the process: Are there any use cases that tools would add rights detail?
Aggregation steps – e.g., the stronger of)
4. Below is mail I sent a while ago to some of you, a deliberately contrived rights list suitable for discussion. I'm
not strongly advocating that we be able to support 100% of this, but I'm hope it is useful in thinking about what
we do and don't need to do with interaction of Generic and External rights along with the syntax requirements
for each.
This version donated to the IEEE, see last page
Page 6 of 23
IP Encryption Workgroup
Report and Recommendation
Hi all,
Here is my contrived rights example that may be useful in upcoming discussions. It is obviously NOT a
specification and it does sneak in a couple of new variations. Syntax is arbitrary, but hopefully self-explanatory
here. Not everything here may be necessary in an initial version, although I do think we should aim to have a
robust enough framework to handle such things in the future.
Thanks,
Dave
synplicity_synthesis={
allowed_vendors={
default=none
license={
xilinx=synplctyd:ip001x
altera=synplctyd:ip001a
}
}
output_method={
implementation={
xilinx={
default=obfuscated
license={
cleartext=synplctyd:ip001xx
}
}
altera=encrypted
}
verification={
xilinx=external
altera=encrypted
}
}
allowed_view=gate,physical
viewports={
default=aa/bb,cc/dd,xx/yy
license_augment={
synplctyd:ip001xyz:qq/rr/ss,qq/rr/tt
}
}
mentor_simulation={
...
}
Use Models – Guidelines for the parties – Devin, Dave, Cast, et. al.
• Right to Parse/Read the encrypted Data Block is controlled by the Session Key.
• Use and Output Rights are defined using Pragmas and explicit Licensing
This version donated to the IEEE, see last page
Page 7 of 23
IP Encryption Workgroup
Report and Recommendation
•
Every Right that is not explicitly enabled is disabled
– There are no implicit rights (the right to produce an implementation netlist does not imply the
right to produce reports).
– Tools SHALL provide the ability to report enabled rights
• (Must this be enabled as a right?)
Rights are specified for and applied to
– Activities (classes of tools)
– Specific EDA Vendor tools
– Specific Target outputs
Extensibility of Rights for Activities and EDA Vendor Tools is required
License definition to support shared library external licensing scheme (easily spoof able) as well as EDA
tool licensing scheme. (more detail needed)
•
•
•
IP providers




Create IP
Decide what that they want to allow
Decide who they want to trust to ensure this
Obtain the public keys of the tool providers
o The IP vendor has the responsibility to oversee key management and appropriate implementation
of an appropriate trust model. It is out of the scope of this whitepaper recommendation to cover
an appropriate set of trust models. It may be within the scope of the IEEE study group or work
group
Tool providers



Support encryption specification and standard rights definitions
Provide public key to IP vendors
Optionally support extended rights in collaboration with IP vendor(s)
Tool and IP users



Obtain IP from vendor including a license if required
Verify that IP vendor supports the EDA Tools that will be used.
Install license if required
Scope and non-Scope topics
 Parameters and security
o Parameters that are just text expansion provide a Trojan horse
o General issue on encryption. Should be documented as a caveat
o A phrase that MAY be appropriate is:
o A trusted environment MAY publicize an attribute that specifies that this tools does not expand
paramenters in any text sources
 Multiple inputs feeding the output, are there issues?
o Maintain the hierarchical separation of the output files is a default requirement
o Encrypted IP is hard hierarchy
This version donated to the IEEE, see last page
Page 8 of 23
IP Encryption Workgroup
Report and Recommendation



License definition to support shared library external licensing scheme (easily spoof able) as well as EDA
tool licensing scheme. (Potential change to IEEE license semantics)
Which elements require checksums and which require signatures?
Is there a provider identity requirement?
Gary to write something to include the issue of tags to be included in the envelope and clear text that may be in
the envelope, e.g.,
// VSIA_Soft_IP_Tag % Vendor NXP Semiconductors % Product ip_uart % Version 1.3 %
Metric 0 % Process_Step Source % Date_Time 20040101 % _IP_Owner CTO/RTG % _Techno
ANY % _Area 0 % _Celltype IPSoft % _Cell_Id ip_uart_01 % _Signature 0 % _Tag_Spec
1.0
We want to be able to put these tags in the external rights file. If multiple files are sharing the same external
rights file, then the tags may needed labeling for the right file.
In the generic…
‘protect vsi * is reserved for further definition.
The generic form might have included a concatenation of the rights “file” in the encrypted file with a label
begin and end and a defined MD5 algorithm processing. This is problematic due to processing issues of
moving between windows and UNIX™ and the violation of the sanctity of the rights file. Just combining
the files in a zip archive will achieve the same goal of being able to encapsulate a bundle. So there will not
be a concatenation part of the spec.
Key management (exchange of keys is the responsibility of the IP Provider)
Regarding public key management, here are links to two publications from ABA-ISC that are highly relevant:
PKI Assessment Guidelines: http://www.abanet.org/scitech/dch/PKIGuidelines.pdf
Digital Signature Guidelines Tutorial: http://www.abanet.org/scitech/ec/isc/dsg-tutorial.html
C, C++, SystemC issues
Binary structured file issues
Parameter use issues/potential exposure
Parts of the “Standard”
Generic Encryption encapsulation standard – Dave
• Used when there is no alternate spec
• The use model is that it will yield upon reading:
This version donated to the IEEE, see last page
Page 9 of 23
IP Encryption Workgroup
Report and Recommendation
•
•
– IFF reading rights are provided: Clear text version of file annotated with regions and the rights
associated with the regions
– Collection of encrypted rights blocks for writing to output files
– Collection of Open/Clear text rights blocks [with signature]
– Potentially unencrypted by PKE:
• Session key
• Rights Block Data
Based on Use rights, allowed operations may be performed
Based out output rights, allowed outputs may be generated, including encryptions and rights wrappers
clear text, obfuscated text, and text with encrypted blocks.
– The format of binary outputs is TBD
2. External rights file placement, reference, and security
The external rights file contains private rights for individual EDA tools. One EDA tool has no ability to read the
rights for another tool. The actual rights specification is covered elsewhere. This section describes the
encryption envelope applied to the rights specification, file placement, security, and references to the file.
An example file is as follows:
‘protect begin_protected
‘protect key_keyowner=EDA1
‘protect key_keyname=EDA1_2008A
‘protect key_method=rsa
‘protect key_block
<encrypted EDA1-specific session key for rights only>
‘protect author=IP1
‘protect rights_method=aes128-cbc
‘protect rights_block
<encrypted rights for IP1 processed by EDA1 with EDA1-specific key>
<include: sessionkey=<value> that must match session key in corresponding design>
‘protect begin_protected
‘protect key_keyowner=EDA2
‘protect key_keyname=EDA2_1234ABC
‘protect key_method=rsa
‘protect key_block
<encrypted EDA2-specific session key for rights only>
‘protect author=IP1
‘protect rights_method=aes128-cbc
‘protect rights_block
<encrypted rights for IP1 processed by EDA2 read with EDA2-specific key>
<include: same sessionkey=<value> as above>
‘protect end_protected
This version donated to the IEEE, see last page
Page 10 of 23
IP Encryption Workgroup
Report and Recommendation
There will be zero or one encrypted rights files per IP. The file is read-only and may never be modified by an
EDA tool, although an EDA tool is allowed to copy it in its entirety to a new location.
The rights file name is arbitrary but should be verbose to avoid collision with other rights files. Recommended
convention is lower-case: <vendor>_<ipname>_<version>_rights. For example: acme_pcicore64_1248_rights.
The name and location of the file is as specified in the design file and will generally be in the same directory as
the design file for the top-level module. Protection from tampering, abuse, or substitution is achieved by
inclusion of the design session key in the rights file. The EDA tool must verify that these match. (See next
paragraph)
Add a picture to help with the session key correspondence. Discuss the possibility of signature / checksum, and
why this choice is preferable.
Describe IP that encrypts 5 different files that share a single rights file, and what scenario is used for this. Might
an MD5 signature of the clear text version of the rights block, stored in the vendor-encrypted key block work?
Or and MD5 signature of the entire rights file as distributed, a clarification of end file characters is that any
copies are byte for byte copies, so the MD5 sum will not change.
How is a single use a discard flow work?
The encrypted blocks are encoded in base64.
Reference to rights file can be present in Verilog, VHDL, or generic files. The reference will be encrypted in the
data block and take a form similar to that shown below.
‘protect rights_file=<name>,md5=<md5 sum of the full rights file>
The file name should be a relative path from the top-level module design file and use forward slashes to be
platform-independent. The exact placement of this reference will be specified in Verilog, VHDL, or generic file
specifications. See the Cadence contribution from Steve Dovich on a set of proposed amendments to the VHDL
and Verilog standards to provide for referencing an external rights file.
Generic file encryption
File types other than Verilog and VHDL can contain protected IP as described in this section. The protection is
not considered part of the language. The following describes protection of EDIF and similar principles can be
applied to other languages.
Each file will either be plain text or will be fully encrypted, except that an encrypted file may begin with an
encryption envelope and encrypted reference to a rights file. This is done for ease of parsing and to avoid
conflicts with various language requirements such as matching parenthesis in EDIF.
File name recommendation is to add a p for Protected at the end of the unencrypted file extension, .ednp for
Protected EDIF.
This version donated to the IEEE, see last page
Page 11 of 23
IP Encryption Workgroup
Report and Recommendation
Top level EDIF is in plain text. When an IP cell is encountered, no cell content is present in that EDIF. The toplevel file top.edn would contain for example
(library work
(cell IP1
)
A separate file in the same directory named IP1.ednp would contain
‘protect begin_protected
‘protect key_keyowner=EDA1
‘protect key_keyname=EDA1_2008A
‘protect key_method=rsa
‘protect key_block
<encrypted session key>
‘protect key_keyowner=EDA2
‘protect key_keyname=EDA2_ABCD
‘protect key_method=rsa
‘protect key_block
<encrypted session key>
‘protect author=IP1
‘protect rights_method=aes128-cbc
‘protect data_block
<encrypted ‘protect rights_file=<name>>
<encrypted IP1 edif>
‘protect end_protected
–
This text currently taken from the Synplicity donation to VSIA needs expansion and modification…
1 Overview
This document specifies a secured flow for the exchange of IP among EDA tools. The system is open, meaning
that multiple tools can share the same input files and consume each other’s output files while still containing
and protecting the IP. This standard is expected to be used in the case of file formats whose owners have
designated this standard as the format of choice, and may be used in any flow where the IP provider uses this
format and the tool is able to understand and read and protect according to this format.
2 Definitions
IP Vendor
The IP Vendor is the person or company that creates the encrypted file(s) of their IP following this
specification. The IP Vendor MUST have access to the clear text of the IP source. They MUST also have access
to the public-key for each EDA Tool that they wish to support with the recommended public-key method.
EDA Tool
Any software application that needs to read the files of the IP and optionally writes files that contain IP
information. Synplicity’s Synplify Pro is used as an example in this document, reading the original IP,
This version donated to the IEEE, see last page
Page 12 of 23
IP Encryption Workgroup
Report and Recommendation
synthesizing, and writing a gate-level implementation of the IP. EDA tools include front-end tools such as logic
synthesis, analysis tools such as simulation, and implementation tools such as place and route.
Protected File
A file containing encrypted data and optionally encrypted keys for decryption of the data. Such files always
begin with “%%% protected_file 1.0” for easy recognition by file parsers. The file will contain portions in the
original file language and portions with language-independent encrypted IP. Each encrypted IP section starts
with “%%% begin_protected” and ends with “%%% end_protected”.
Data Key
The secret key known used to encrypt the IP using symmetric algorithms such as DES or AES.
Depending on the encryption method used, this key may not need to be known by anyone other than
the IP Vendor
Data Block
The base64-encoded result of encryption of the IP using the desired algorithm and Data Key.
Key Block
The base64-encoded result of encryption of name-value pairs. Required name-value pairs are the Data
Key for data decryption and Output Method that specifies if or how an EDA tools should encrypt its
output files. Other EDA Tool-specific name-value pairs are allowed. An asymmetrical encryption
algorithm such as RSA or Elgamal is used to create a Key Block. Key Blocks are required only for the
recommended public-key method that is described later.
Protected Envelope
A section of a file consisting of
%%% protect begin_protected
plain-text pragmas describing a key block
a key block
plain-text pragmas describing a data block
the data block
%%% protect end_protected
Repeat for each key block
3 References
Mime reference for base-64 encoding
Supported algorithms
It is suggested that the two classes of algorithms that are used, the Session Key and the Public key algorithms
both be limited to a defined list of algorithms, this list to be maintained by the DASC/IP Encryption Working
Group (if approved and within scope) and updated from time to time through the IEEE standards balloting
process.
The initial list has been created:
 to provide compatibility with IEEE 13xx and 1076
 … (Dave will provide text)
This version donated to the IEEE, see last page
Page 13 of 23
IP Encryption Workgroup
Report and Recommendation
1. Encryption algorithms
Symmetric encryption will have a small list of universally supported methods. Since all of the tools reading a
particular input will extract the same session key from their respective key blocks, interoperability can only be
achieved if all tools support the same set of algorithms. The set is chosen to be commonly available in both
open-source and commercial toolkits and to not place an excessive burden on export compliance
des-cbc (add reference text from verilog spec)
3des-cbc
aes-cbc
A specific constant initialization vector will be part of this standard to avoid the need to place information other
than the session key in the encrypted key block. – Comments are invited specifically in this proposed technique.
Asymmetric encryption does not need to have a fixed list of supported algorithms. Any method agreed to by an
IP provider and the EDA tool vendor can be used to encrypt the session key in the vendor key-block as long as
the name of the method is globally unique. The following is only a recommendation
Rsa (add reference to make this specific)

Algorithm name
Key length
Initialization vector CBC – block
standard reference
chaining
Rights Scope and Lifetime
Hierarchy issues
VHDL (1076) and Verilog (1800) Language specific recommendations – Steve
VHDL
Verilog
Conditional
compilation
may have (future) has
Scope of
pragmas
nested by crypt
parsing order
Opportunity to
vary standard
depends on what
is is
cumulative until
reset
Namespace
management
•
•
•
Uses Standard encryption and key management as described in standard
Needs augmentation to:
– Defined protected rights
– Provide transferable encrypted rights blocks
– Makes use of “pointer” to point to this data.
The use model is that it will yield, upon reading:
This version donated to the IEEE, see last page
Page 14 of 23
IP Encryption Workgroup
Report and Recommendation
•
•
– IFF reading rights are provided: Clear text version of file annotated with regions and the rights
associated with the regions
– Collection of encrypted rights blocks for writing to output files
– Collection of Open/Clear text rights blocks [with signature]
– Potentially unencrypted by PKE:
• Session key
• Rights Block Data
Based on Use rights, allowed operations may be performed
Based out output rights, allowed outputs may be generated, including encryptions and rights wrappers
clear text, obfuscated text, and text with encrypted blocks.
– The format of binary outputs is TBD
Recommended profiles (recommended algorithms, rights block references)
Rights Scope and Lifetime – see grid next page
Recommended extensions/changes
Timeline of recommendation
Now
This paper will be / has been published by the VSIA and then once the PAR has been accepted to form the IEEE
workgroup on IP Encryption, the VSI stewardship committee will vote on transferring the copyright to that
working group.
after IEEE language groups respond to recommendation
(what updates will take place)
Rights Block Format (with extension capability)
Cadence has prepared a contribution on the format of the rights block. They will be sharing this directly with
the IEEE workgroup when appropriate; there may be other opinions on the actual format appropriate for
standardized. Those listed in this white paper should be considered to be suggestions, or better yet, as examples
embodying requirements.
Issue: how is the rights block secured to the block of data that it references? Or how is the validation performed
in the other direction?
Is the rights block signed?
Is the signature of the rights block contained inside the encrypted section that points to the external rights
block? Synplicity has some proposals in this area appropriate for contribution to the P1735 work product.
This version donated to the IEEE, see last page
Page 15 of 23
IP Encryption Workgroup
Report and Recommendation
Standard “Rights” definitions
This is an initial enumeration of some of the rights that will be appropriate to express. It is likely that the
standard set will require (and enable) vendor extensions to the rights enumeration. It is also likely that the
recommended practice will benefit from a refactoring exercise to move toward orthogonally in expression of
allowed rights. With these disclaimers out of the way,
Encrypted IP Usage Scenarios
A standard encryption scheme must provide sufficient flexibility to support the different needs of multiple IP
vendors. A description of intended use scenarios follows.
Evaluate the IP – Some IP providers desire the ability to safely distribute their IP to potential customers
for evaluation without entering into a license agreement. In this use model, the consumer has the ability to
evaluate the encrypted IP and obtain information about the IP such as area to implement or estimated
performance, but does not have the ability to produce or obtain information required to implement the IP. In
this case the IP vendor may enable a simulator to display waveforms and enable a synthesis tool to produce
reports, but would not enable the synthesis tool to produce an implementation netlist.
Protect the RTL – Some IP providers desire the ability to encrypt the RTL description of the IP, but do
not require encryption of the EDA Tool output files. For some providers, the post synthesis netlist is
sufficiently obscured to provide the required level of protection of the IP and a clear text output file is
acceptable. Other providers may require additional obfuscation of the output file. A feature of this model is
that it provides some protection of the IP, but does not require that tools that follow in the design flow to be able
to consume an encrypted file.
Protect the IP through synthesis – This flow requires that the IP is always encrypted. The RTL is
encrypted and any tool that processes the IP produces encrypted output files that are then consumed by the next
tool in the design flow.
Synthesis tools transform the design data and may produce output that is of a different format than the
input (example - input Verilog => output EDIF or input VHDL => output Verilog). The synthesis tool produces
output design data that although transformed, is encrypted using the same data key as was used to encrypt the
input design data.
A standard mechanism for transferring Usage Rights from the input design description to the output
design description is required. This will enable the tools that follow in the design flow to process the
transformed design description that is produced by the synthesis tool. The preferred mechanism is one where
the synthesis tool does not read, process, transform or write the Usage Rights for any other tool.
The default output of this flow … Jim to update this.
Protect through physical implementation Protection in FPGA bit stream flow. Devin
In order to use the ip outside of a tool, some tool needs to be provided with some output or integration
right that provides for use outside of the tool.
This version donated to the IEEE, see last page
Page 16 of 23
IP Encryption Workgroup
Report and Recommendation
Output/Usage Rights
In order to support multiple usage scenarios for encrypted IP it is necessary to provide a mechanism for IP
authors to specify how the contents of the encrypted file will be used. This mechanism is referred to as
Usage/Output Rights or simply as Rights. Rights are specified by the IP provider and are read by the EDA tool.
Rights define the actions an EDA tool is allowed to perform on an encrypted file, and the type and format of
outputs the EDA tool is allowed to produce as the result of processing and encrypted file.
Rules





The default condition of all Rights is disabled.
Any Right that is not explicitly enabled is disabled.
There are no implicit Rights.
An EDA tool that processes an encrypted IP, must report which Rights are enabled.
Rights are extensible
Activity
The term ‘Activity’ as used in this document refers to an EDA tool activity such as Simulation, or Logic
Synthesis. Some EDA tools may be capable of performing multiple activities. Such as simulation, static
analysis, synthesis, and layout. In the case of Static analysis, we mean: Analysis of the design to determine
specific characteristics such as static timing, power consumption, or to compare equivalence between two
different representations
Generic and Vendor Specific Rights
The trust relationship between IP providers and EDA Tool Vendors will not be uniform. Due to relationships,
competencies or other factors, some EDA Tools will typically be trusted more than other tools. The Rights
mechanism facilitates a multilevel trust model by providing the ability to specify rights specifically to an
individual EDA Vendor’s Tool(s) that perform a particular activity. Rights may also be specified generically so
that the rights apply to all tools that perform a particular activity.
Generic Rights provides a mechanism to specify uniform rights for all EDA Tool Vendors. This is useful if
Vendor Specific Rights are not required, or to define a standard ‘baseline’ set of rights and then to expand
additional rights for specific EDA Tools.
Combining Rights
Rights are accumulative. If both Generic Rights and Vendor Specific Rights are applied to an encrypted IP, the
Vendor Specific Rights will grant additional rights beyond those specified as Generic Rights. There is no
mechanism for disabling or removing a Right that has been enabled.
Standard Rights Definitions
The following section is documentation of workgroup deliberation based on consideration of a document
prepared by Cadence. The inclusion of this table here provides the ability to VSI release the copyright on
this text to the IEEE, but does not imply the copyright donation of the initial Cadence material.
It is not practical to attempt to define all of the Possible Rights that would apply to every EDA tool or activity.
Instead this document will define a standard set Rights that apply to the following list of activities. As
mentioned above, Vendor Specific Rights are extensible and IP providers and EDA tool vendors may
This version donated to the IEEE, see last page
Page 17 of 23
IP Encryption Workgroup
Report and Recommendation
collaborate to define specific Rights that are not defined in this document. Any tool that encounters a right that
is not understood must consider this an error condition and terminate processing without producing any result
data.
Rights are specified using name value pairs. Each Right requires a Keyword that further specifies the required
behavior.
Rights Identifier
Activities
Description
Report
All
View
All
Output Change Data
Simulate
The Report Right controls the ability to
produce textual reports. The value of the
Report keyword specifies the type of
information that may be reported.
Keywords:
messages
timing
area
all
EDA tools provide a variety of different
ways to view design data to aid design
analysis and debug. The value of the
View keyword specifies the permitted
view modes for the protected IP.
Keywords:
waveform
schematic
placement
Simulation tools produce output
(VCD/print on change) that can be viewed
or processed by other tools. The value of
the Output Change Data keyword
specifies how the data will be represented
upon output from the tool.
Keywords:
cleartext
obfuscate
encrypt
Enable script based
file writing
Static
Analysis
This version donated to the IEEE, see last page
Many static analysis tools provide for a
TCL interpreter to process, for example,
timing scripts.
[Feedback strongly requested]
Default if no right
specified
No reporting for protected
IP
All views of protected IP
are disabled
Output of data for
protected IP is not
permitted
If this write is not granted,
then none of the data that
has been protected may be
used to generate output
files.
Page 18 of 23
IP Encryption Workgroup
Report and Recommendation
Rights Identifier
Activities
Description
Default if no right
specified
Output of data for
protected IP is not
permitted
Output
Synthesis
Implementation Netlist
The implementation netlist is the result of
the design transformation performed by
the Synthesis activity. The value of the
Output Implementation Netlist keyword
specifies how the data will be represented
upon output from the tool.
Keywords:
cleartext
obfuscate
encrypt
Output Physical
Annotation
Synthesis,
Layout
Physical Annotation describes physical
placement information that may be
produced by the layout or synthesis
activity. The value of the Output Physical
Annotation keyword specifies how the
data will be represented upon output from
the tool.
Keywords:
cleartext
obfuscate
encrypt
Output of data for
protected IP is not
permitted
Output Simulation
Netlist
Synthesis
When the implementation netlist is EDIF,
a separate simulation netlist may be
required. The value of the Output
Simulation Netlist keyword specifies how
the data will be represented upon output
from the tool.
Keywords:
cleartext
obfuscate
encrypt
Output of data for
protected IP is not
permitted
Output Programming
Layout
The value of the Output Programming
keyword specifies how the data will be
represented upon output from the tool.
Keywords:
cleartext
obfuscate
encrypt
Output of data for
protected IP is not
permitted
This version donated to the IEEE, see last page
Page 19 of 23
IP Encryption Workgroup
Report and Recommendation
Rights Identifier
Activities
Description
Targets
Layout
The value of the targets keyword specifies
the permitted physical targets for the
layout activity. If a keyword identifier
other than ‘all’ is specified, the identifier
corresponding to the desired physical
target must be present in the list of values
or the EDA Tool shall not perform the
layout activity. The list of supported
targets is implementation specified.
Keywords:
all
License
All
Default if no right
specified
The layout tool shall not
perform the layout
activity.
Keywords defined
– messages– Enables the ability to report general and specific tool messages such as warnings,
errors and tool status while processing the encrypted IP.
– timing – Enables the tool to produce reports containing static timing information for the
encrypted IP
– area – Enables to tool to produce reports containing information about design area of the
encrypted IP
– all – Enables tool to produce all reports when applied to the Report identifier and enables the
tool to target any device when applied to the Target identifier.
– waveform – Enables the ability to display the contents of the encrypted IP in a waveform viewer
– schematic – Enables the ability to display a schematic view of the encrypted IP
– encrypt – The output file is encrypted using the same method and key as was used to encrypt the
encrypted IP input file.
– obfuscate – Obfuscation is defined as providing a structural equivalent of the clear text version
with (at least) all of the name tokens replaced with a coded form of the token. The coding table is
not supplied as part of the output. Encoding (as used in this document) is the process of taking
binary data and converting the representation to a limited set of ASCII characters. No decrypted
image stored on disk. No decrypted image accessible by debugger or memory scanning access
of the running process. (No guarantee is supplied by the standard; qualification of this capability
is the responsibility of the IP provider and the tool supplier.)
– plaintext – The output file is written as unencrypted text (clear text).
Extensibility
Rights and keywords are extensible. EDA vendors may define implementation specific keywords and Rights
identifiers. Use of these extended Rights requires collaboration between the IP provider and the EDA vendor.
This version donated to the IEEE, see last page
Page 20 of 23
IP Encryption Workgroup
Report and Recommendation
Defaults/Missing Rights – The default condition of any right is disabled. Therefore any right that is not
specified (or is missing) indicates a disabled condition. EDA tools must not produce output unless the right to
produce the output is specifically granted. Likewise, EDA tools must not provide any usage or view of the
encrypted IP unless the right has been specifically granted.
Rights that require further investigation – This section is intended to list items that may need to be added to
the Standard Rights Definitions, at a later date after further investigation.
Items include –
 Forward annotation of timing constraints and exceptions
Summary of Rights and Keywords listed by activity
Activity - Simulation
 Report
– Messages
• View
– Waveform
• Output Change Data – I could use input on this one. It seems to me that there should be a Right
pertaining to the ability to produce VCD or other output data files
Activity - Synthesis
 Report
– Messages
– Timing
– Area
– All
• Output Implementation netlist
– Encrypted
– Obfuscated
– Plain Text
• Output Simulation netlist
– Encrypted
– Obfuscated
– Plain Text
• Output Physical Annotation
– Encrypted
– Obfuscated
– Plain Text
• View
– Schematic
Activity – Static Analysis
• Report
This version donated to the IEEE, see last page
Page 21 of 23
IP Encryption Workgroup
Report and Recommendation
•
•
– Messages
– Timing
– All
Simulation netlist
– Encrypted
– Obfuscated
– Plain Text
View
– Schematic
– Waveform
References
1. Hard Intellectual IP (IP) Tagging Standard
2.0 Intellectual
Released: June 2000
Property Protection Revision Released
DWG
November 2006
Available to the Public
Download
2. Soft Intellectual Property (IP) Tagging Standard
1.0 Intellectual
Released August 2004
Property Protection Revision Released
DWG
November 2006
Available to the public
Download
3. The SPIRIT Consortium
This version donated to the IEEE, see last page
Page 22 of 23
IP Encryption Workgroup
Report and Recommendation
This version donated to the IEEE, see last page
Page 23 of 23