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
--