Re: [vhdl-200x] IP Protection and Encryption Donation

John,

Please see my comments below.

-ajay

>>
>> It seems to me the basic requirements for IP encryption are:
>>
>> A) Provide a secure method of providing IP to VHDL tools so that
>> they can do there work, i.e. simulation and synthesize, without
>> providing to the customer how the IP works.
>>
>> B) Allow for the same IP to work in tools from different vendors
>> without having to provide multiple copies of the IP. The current verilog
>> `protected is different for each vendor.
>>
>> C) Allow the IP provider to control who has access, not just everyone
>> that owns the specific tool.
>>
>> The Cadence document seams to address C well. I don't think it addresses
>> A and B very well.
>>
>> I don't believe there is sufficient depth in how data is represent in the
>> data_block, key_block, and digest_block, to allow one vendor tool's
>> to read blocks generated by another vendor's tool. Specifically there is
>> no text describing how result of the encryption is converted into the text stream
>> within the data, key, and digest blocks. Maybe this is part of the encryption
>> algorithms themselves. If it is then this comment is moot.

It is possible to encrypt and consume IP in a tool-vendor independent
way using the mechanism described in the proposal.

Let me give an example of a simple encryption-decryption flow that works
across tools from multiple vendors. An IP vendor, say V1, generates a
public/private key pair that he names V1_key1, and uses the public key
with the DES algorithm for encrypting his IP. In the encryption envelope,
he specifies the following:

     data_keyowner = V1
     data_key = V1_key1
     data_method = DES

To the encrypting tool, he has to specify that the key name V1_key1
is associated with the public key he has generated. This association is
tool vendor dependent, and will presumably be stored in the tool's
secure key database. The IP vendor also has to provide the key owner,
key name and private key to every tool that consumes the IP, which again
would be stored in a secure database. The consuming tool then picks up
the appropriate key using the key name from the encrypted envelope, and
uses the associated algorithm to decrypt the data portion.

The algorithms supported in the proposal are all standard ones and
work straight on the encrypted data to give the decrypted stream.

There are other more secure ways in which IP can be encrypted and
consumed using the proposed mechanisms. I shall send a separate write-up
about the different IP distribution models that could be supported.

There is a set of fairly standard algorithms supported in this proposal.
Tool vendors may choose to support other algorithms also, but those may
work only with the specific vendor's tools.

>>
>> As for providing hiding of IP from the user, the document does say anything
>> about a number of items.
>>
>> 1) Does the VHPI have access to encrypted models.
>> 2) If error/assertions occur within the encrypted model can
>> the tool report a pathname to an object in the model?
>> 3) If part of the hierarchy is encrypted, what does the `path_name
>> attribute return. Can on use the `path_name attribute in
>> an encrypted portion? What does it return?
>> 4) Can SDF be applied to an encrypted model.
>> 5) Is direct visibility effected by an encrypted model?
>> 6) Can configurations be applied to an encrypted model?
>> 7) This is an implementation question, but most vendors have
>> tools that allow for inspection of libraries, do they show encrypted
>> design unit names decrypted?
>> 8) Is single stepping allowed within an encrypted model?

In general, a tool that consumes encrypted IP must not reveal any
details through any of it's interfaces or in any other output it generates.
Similarly, a synthesis tool should not generate a non-encrypted
netlist for encrypted portions of input. SDF and configurations
should be allowed.

However, is it appropriate to specify such expectations in a
language standard? Can we maybe list this as an appendix? What do
others on the reflector think about this?

There is another issue we have in specifying exactly what may be
revealed and what must not. There is no way of restricting where
begin and end pragmas can be placed in the code, and this could
lead to some confusion about what exactly gets protected. One way
out is to change the pragmas to language keywords and specify exactly
where they can occur. The down side is that encrypting tools will have
to be able to parse the language correctly.
Received on Wed May 19 06:25:39 2004