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

Hi Ajay,

Thanks for the clarification on data_keyowner, data_key, and data_method.
I agree that the encryption is tool-vendor independent. One issue I was
trying to raise is that the docuement doesn't specify how the output
of the encyrption algorithm is converted to printable ascii.

I'm assuming that the source withing the protect begin/end paragmas
is run through the encryption algorithm and results in some sort
of binary data stream. This data stream then needs to be convert to
printable characters of some sort. This conversion also needs to allow
for the tool to detect the protect end_data_block pragma.
For example if the plain text is

SIGNAL hidden_sig: std_logic_vector;

The encryption procduces some binary stream say

0x01 0x37 0x28 0x32 0x47 0x58 0xAC 0x29 0x67 0x42
0x12 0x34 0x35 0x59 0xB3 0x4C 0x9E 0xF0 0x61 0x8A
0x98 0x44 0x7D 0x2A 0x93 0x08 0x38 0x86 0xA3 0xB4
0x32 0x58 0x69 0x48 0x8A 0x3F

This then needs to be convert to printable character.
Is there already a standard for how this is done?
Do encryption algorithm produce ASCII out always?
If both these questions are no the we need to specify this
transformation as part of the standard.

Regards,
   John

Ajayharsh Varikat wrote:
> 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.
>

-- 
-- mailto: johnr@model.com     phone: (503)685-0864
--   http://www.model.com        fax: (503)685-0921
--