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

The encrypted text produced by encryption when translated to sixal is
usually included text as a set of precisely 60 character "words" each
on their own line, with no internal spaces, or the use of the
character "_"; so you are quite safe.

For example, the granddaddy of binary encapsulation is uuencode, which
turns your email message into:

begin 664 Johns_message
M+2T@3VX@36%Y(#$Y(#(P,#0@870@,34Z,C$L(%)I97,L($IO:&X@<V5N="!A
M(&UE<W-A9V4Z"B`^(%1O.B!L87=R96YC94!C861E;F-E+F-O;2P@=FAD;"TR
M,#!X0&5D82YO<F<L('9H9&PM,C`P>"UF=$!E9&$N;W)G"B`^(%-U8FIE8W0Z
M(")293H@6W9H9&PM,C`P>"UF=%T@4F4Z(%MV:&1L+3(P,'A=($E0(%!R;W1E
M8W1I;VX@86YD($5N8W)Y<'1I;VX@1&]N871I;VXB"B`^($AI($IA>2P*(#X@
M"B`^($IU<W0@=&\@8F5A="!A(&1E860@:&]R<V4N"B`^(%=E(&%R92!T:&5N
M(&%S<W5M:6YG('1H870@=&AE(&-H86YC92!E;F-R>7!T:6]N('!R;V1U8V5D
M(&5X86-T;'D*(#X@+2UP<F%G;6$@<')O=&5C="!E;F1?9&%T85]B;&]C:PH@
M/B!I<R!S;R!L;W<@=V4@9&]N)W0@=V]R<GD@86)O=70@:70N"B`^(`H@/B!2
796=A<F1S+`H@/B`@("!*;VAN"B`^(`H`
`
end

In our case we would see:

architecture of rtl_code of decss is
  begin_protected
M+2T@3VX@36%Y(#$Y(#(P,#0@870@,34Z,C$L(%)I97,L($IO:&X@<V5N="!A
M(&UE<W-A9V4Z"B`^(%1O.B!L87=R96YC94!C861E;F-E+F-O;2P@=FAD;"TR
M,#!X0&5D82YO<F<L('9H9&PM,C`P>"UF=$!E9&$N;W)G"B`^(%-U8FIE8W0Z
M(")293H@6W9H9&PM,C`P>"UF=%T@4F4Z(%MV:&1L+3(P,'A=($E0(%!R;W1E
M8W1I;VX@86YD($5N8W)Y<'1I;VX@1&]N871I;VXB"B`^($AI($IA>2P*(#X@
M"B`^($IU<W0@=&\@8F5A="!A(&1E860@:&]R<V4N"B`^(%=E(&%R92!T:&5N
M(&%S<W5M:6YG('1H870@=&AE(&-H86YC92!E;F-R>7!T:6]N('!R;V1U8V5D
M(&5X86-T;'D*(#X@+2UP<F%G;6$@<')O=&5C="!E;F1?9&%T85]B;&]C:PH@
M/B!I<R!S;R!L;W<@=V4@9&]N)W0@=V]R<GD@86)O=70@:70N"B`^(`H@/B!2
796=A<F1S+`H@/B`@("!*;VAN"B`^(`H`
  end_protected

end rtl_code;

-- On May 19 2004 at 15:21, Ries, John sent a message:
> To: lawrence@cadence.com, vhdl-200x@eda.org, vhdl-200x-ft@eda.org
> Subject: "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
> --
Received on Wed May 19 15:43:31 2004