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

Hi Jay,

Just to beat a dead horse.
We are then assuming that the chance encryption produced exactly
--pragma protect end_data_block
is so low we don't worry about it.

Regards,
   John

Jay Lawrence wrote:
> In rereading this I didn't answer the question about length.
>
> All encrypted/encoded blocks are found within begin_*/end_* pairs
> (begin_protected/end_protected, key_block/end_key_block) so a length is
> not necessary. The decoding tool can just keep sixel decoding until it
> finds the matching pragma on a newline by itself.
>
> Jay
>
> ===================================
> Jay Lawrence
> Senior Architect
> Functional Verification
> Cadence Design Systems, Inc.
> (978) 262-6294
> lawrence@cadence.com
> ===================================
>
>
>>-----Original Message-----
>>From: owner-vhdl-200x-ft@eda.org
>>[mailto:owner-vhdl-200x-ft@eda.org] On Behalf Of Ries, John
>>Sent: Wednesday, May 19, 2004 1:43 PM
>>To: vhdl-200x@eda.org; vhdl-200x-ft@eda.org
>>Subject: Re: [vhdl-200x-ft] Re: [vhdl-200x] IP Protection and
>>Encryption Donation
>>
>>
>>I understand. Is the example in the document correct or is
>>it just some
>>"stuff" that looks like the desired output? From my understand
>>of sixel the ascii character should be in the range 0x20 to 0x57.
>>Which is spc ! " # $ % & ' ( ) * + , - . /, 0-9, :, ; < - > ?
>>@ A-Z [ \ ] ^ _. The example has lower case characters in
>>it. Also how
>>encryption block terminated. Is there a length of data encoded or is
>>it the first line that starts with -- pragma protect ...?
>>
>>Regards,
>> John
>>
>>
>>That should produce a
>>
>>Jay Lawrence wrote:
>>
>>>As one of the original authors of this spec inside Cadence
>>
>>I'll comment
>>
>>>here because Ajay is probably offline for the night in India.
>>>
>>>Throughout the document the term "encoded" is used without being
>>>defined. This should be fixed. The encoding assumed is
>>
>>classical "sixel"
>>
>>>encoding (that used by uuencode/uudecode). Using this
>>
>>algorithm each 3
>>
>>>byte (24 bits) is broken into four 6 bit chunks. These bits are then
>>>shifted into the printable ASCII range to guarantee they are ascii.
>>>
>>>The result is easily reversible and only expands the data slightly.
>>>
>>>Earlier versions of the spec also included a "pragma encoding" to
>>>support multiple encoding schemes but sixel is so pervasive that we
>>>decided it just wasn't worth it.
>>>
>>>Jay
>>>
>>>===================================
>>>Jay Lawrence
>>>Senior Architect
>>>Functional Verification
>>>Cadence Design Systems, Inc.
>>>(978) 262-6294
>>>lawrence@cadence.com
>>>===================================
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: owner-vhdl-200x-ft@eda.org
>>>>[mailto:owner-vhdl-200x-ft@eda.org] On Behalf Of Ries, John
>>>>Sent: Wednesday, May 19, 2004 11:15 AM
>>>>To: Ajayharsh Varikat
>>>>Cc: vhdl-200x@eda.org; vhdl-200x-ft@eda.org
>>>>Subject: [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
>>>>--
>>>>
>>>
>>>
>>
>>--
>>-- mailto: johnr@model.com phone: (503)685-0864
>>-- http://www.model.com fax: (503)685-0921
>>--
>>
>
>

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