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

From: Jay Lawrence <lawrence@cadence.com>
Date: Wed May 19 2004 - 15:03:47 PDT

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
> --
>
>
Received on Wed May 19 15:03:53 2004

This archive was generated by hypermail 2.1.8 : Wed May 19 2004 - 15:04:00 PDT