FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > Verilog

Verilog comp.lang.verilog newsgroup / usenet

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 03-21-2005, 06:40 PM
Arturi
Guest
 
Posts: n/a
Default Encrypting verilog files

Hello there,
Anybody has an idea how to encrypt verilog files for customer
delivery?
I was considering to use some compiler options to hide the internal
models, and then deliver pre-compiled libraries.
My files are highly configurable, so if I delivered pre-compiled
libraries these would be only a snapshot of a particular configuration
of my design. And the libraries would be simulator dependent as well.
Anybody has a hint on that?
Regards
Reply With Quote
  #2 (permalink)  
Old 03-22-2005, 06:09 AM
dont_reply
Guest
 
Posts: n/a
Default Re: Encrypting verilog files


"Arturi" <[email protected]> wrote in message
news:[email protected] om...
> Anybody has an idea how to encrypt verilog files for customer
> delivery?


Most commercial IP-vendors deliver their IP-models in the form of
a binary (PLI) simulator-library. These are compiled individually
for the different target platforms (SunOS, linux, IBM, HP-UX, etc.)

Additionally, I've seen some IP-models delivered in different
"simulator flavors" (VCS, Modelsim, Nc-Sim/XL, etc.) But the normal
practice is small binary-file set. Configurability is up to the
vendor. Some vendors let you pass configuration-flags to the
IP-model (through the PLI-interface), others require you to
manually manage the configuration by swapping the actual PLI-files.

Both Cadence and Synopsys offer a product that lets users
create self-contained models, for use/import into a remote (customer)
sim-environment. I think Cadence calls it's product "AMP" (Affirma
Model Packager), and it comes with the LDV/IUS product-set.

I don't know Synopsys's offering offhand, but just lookup "SmartModel"
on their www-site.

And obviously, I'm sure the other players (Modelsim) offer a similar
product.


Reply With Quote
  #3 (permalink)  
Old 03-22-2005, 10:24 AM
Jon Beniston
Guest
 
Posts: n/a
Default Re: Encrypting verilog files

[email protected] (Arturi) wrote in message news:<[email protected] com>...
> Hello there,
> Anybody has an idea how to encrypt verilog files for customer
> delivery?
> I was considering to use some compiler options to hide the internal
> models, and then deliver pre-compiled libraries.
> My files are highly configurable, so if I delivered pre-compiled
> libraries these would be only a snapshot of a particular configuration
> of my design. And the libraries would be simulator dependent as well.
> Anybody has a hint on that?
> Regards



You could try a obfuscator. They're pretty easy to write, and you'll
have the benefit that your code will work with any flow.

Cheers,
Jon
Reply With Quote
  #4 (permalink)  
Old 03-22-2005, 06:01 PM
Stephen Williams
Guest
 
Posts: n/a
Default Re: Encrypting verilog files

dont_reply wrote:
> "Arturi" <[email protected]> wrote in message
> news:[email protected] om...
>
>>Anybody has an idea how to encrypt verilog files for customer
>>delivery?

>
>
> Most commercial IP-vendors deliver their IP-models in the form of
> a binary (PLI) simulator-library. These are compiled individually
> for the different target platforms (SunOS, linux, IBM, HP-UX, etc.)


Slightly more complicated then that.


> I don't know Synopsys's offering offhand, but just lookup "SmartModel"
> on their www-site.


.... which has been something of a thorn in my side. I have been
unable to get the SmartModels for the PPC that come with Xilinx
tools working with Icarus Verilog. The whole thing is all so very
closed in spite of the layer that uses PLI (PLI-1 I might add)
to interface with non-Synopsis Verilog compilers that I've been
unable to see making them work with Icarus Verilog.

--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
Reply With Quote
  #5 (permalink)  
Old 03-22-2005, 10:46 PM
Guest
 
Posts: n/a
Default Re: Encrypting verilog files


Arturi wrote:
> Anybody has an idea how to encrypt verilog files for customer
> delivery?
> ...
> And the libraries would be simulator dependent as well.


The existing methods of encrypting verilog source are vendor-specific.
Since the encryption algorithms/keys have to be kept secret to provide
any security, it should be clear why they only work with one vendor.

There are more sophisticated approaches that work by using standard
encryption algorithms. The IP vendor provides the keys to any vendors
they trust, to be put into their tools, or they provide key blocks for
each such vendor in the encrypted code (keys encrypted using public
keys provided by each vendor). This mechanism has been donated to the
IEEE for the next Verilog standard, but I doubt that anyone besides
Cadence supports it yet.

Reply With Quote
  #6 (permalink)  
Old 03-23-2005, 12:33 AM
mk
Guest
 
Posts: n/a
Default Re: Encrypting verilog files

On 22 Mar 2005 14:46:28 -0800, [email protected] wrote:

>
>Arturi wrote:
>> Anybody has an idea how to encrypt verilog files for customer
>> delivery?
>> ...
>> And the libraries would be simulator dependent as well.

>
>The existing methods of encrypting verilog source are vendor-specific.
>Since the encryption algorithms/keys have to be kept secret to provide
>any security, it should be clear why they only work with one vendor.
>
>There are more sophisticated approaches that work by using standard
>encryption algorithms. The IP vendor provides the keys to any vendors
>they trust, to be put into their tools, or they provide key blocks for
>each such vendor in the encrypted code (keys encrypted using public
>keys provided by each vendor). This mechanism has been donated to the
>IEEE for the next Verilog standard, but I doubt that anyone besides
>Cadence supports it yet.


So are the public keys/encrytion algorithms available for IP vendors
to encrypt their IP to be used with Cadence simulators ? I'd love to
be able to write a small utility to do what "verilog +protect foo.v"
does on my files.
Is the donation to the IEEE public information ? Where can I get a
copy of the donation electronically?

Thanks.
Reply With Quote
  #7 (permalink)  
Old 03-23-2005, 06:18 PM
Jason Zheng
Guest
 
Posts: n/a
Default Re: Encrypting verilog files

mk wrote:
> On 22 Mar 2005 14:46:28 -0800, [email protected] wrote:
>
>
>>Arturi wrote:
>>
>>>Anybody has an idea how to encrypt verilog files for customer
>>>delivery?
>>>...
>>>And the libraries would be simulator dependent as well.

>>
>>The existing methods of encrypting verilog source are vendor-specific.
>>Since the encryption algorithms/keys have to be kept secret to provide
>>any security, it should be clear why they only work with one vendor.
>>
>>There are more sophisticated approaches that work by using standard
>>encryption algorithms. The IP vendor provides the keys to any vendors
>>they trust, to be put into their tools, or they provide key blocks for
>>each such vendor in the encrypted code (keys encrypted using public
>>keys provided by each vendor). This mechanism has been donated to the
>>IEEE for the next Verilog standard, but I doubt that anyone besides
>>Cadence supports it yet.

>
>
> So are the public keys/encrytion algorithms available for IP vendors
> to encrypt their IP to be used with Cadence simulators ? I'd love to
> be able to write a small utility to do what "verilog +protect foo.v"
> does on my files.
> Is the donation to the IEEE public information ? Where can I get a
> copy of the donation electronically?
>
> Thanks.

I wonder if it really makes sense to use pulblic key algorithm, where
you tool generates a private/public key pair. The IP vendor uses the
public key to encrypt their IP design, and the private key is used to
decrypt the design at compile time.

However, the key is how to store that private key securely. If the
private key is stored on the IP consumer's workstation, then no one can
prevent that consumer from directly using that key to decrypt the design
without compiling it (I assume that's the main purpose of encrypting
it). If the private key is to be kept by the IP vendor, then we might as
well just not use the public key encryption, because that is equivalent
to using a tranditional cypher key.

The public key algorithm can however be used to digitally sign the
design by a particular vendor, who run the decryption algorithm with the
private key to sign it, and the IP consumer use the public key
encryption to authenticate the signature. The IP vendor can use this
technique to protect the integrity of their design, but not to stop
peeking. In fact, no encryption method can stop peeking, they just make
it difficult to peek. In that respect, distributing in binary formats is
similar to encryption, provided that reverse-engineering is fairly
difficult.
Reply With Quote
  #8 (permalink)  
Old 03-24-2005, 01:46 AM
Ira Baxter
Guest
 
Posts: n/a
Default Re: Encrypting verilog files


"Arturi" <[email protected]> wrote in message
news:[email protected] om...
> Hello there,
> Anybody has an idea how to encrypt verilog files for customer
> delivery?
> I was considering to use some compiler options to hide the internal
> models, and then deliver pre-compiled libraries.
> My files are highly configurable, so if I delivered pre-compiled
> libraries these would be only a snapshot of a particular configuration
> of my design. And the libraries would be simulator dependent as well.
> Anybody has a hint on that?


Our Verilog obfuscator will scramble the source code names pretty
thoroughly,
strip comments, etc. and let you keep the configuration ifdefs.

See http://www.semdesigns.com/Products/O...bfuscator.html


--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com


Reply With Quote
  #9 (permalink)  
Old 03-24-2005, 09:52 AM
Arturi
Guest
 
Posts: n/a
Default Re: Encrypting verilog files

[email protected] (Jon Beniston) wrote in message news:<[email protected] om>...
> [email protected] (Arturi) wrote in message news:<[email protected] com>...
> > Hello there,
> > Anybody has an idea how to encrypt verilog files for customer
> > delivery?
> > I was considering to use some compiler options to hide the internal
> > models, and then deliver pre-compiled libraries.
> > My files are highly configurable, so if I delivered pre-compiled
> > libraries these would be only a snapshot of a particular configuration
> > of my design. And the libraries would be simulator dependent as well.
> > Anybody has a hint on that?
> > Regards

>
>
> You could try a obfuscator. They're pretty easy to write, and you'll
> have the benefit that your code will work with any flow.
>
> Cheers,
> Jon


Hello Jon,
thanks for the hint, I had never heard of an obfuscator before. But if
I understand it right it is nothing but a script which messes up your
code. Still there is a cross reference mapping so that the code can
still be "unobfuscated" (therefore a risk).
Are these scripts able to somehow flatten a design?
I could deliver a flat netlist of my design but then I would loose the
configurability of it.
Anybody out there using an obfuscator?
cheers
Reply With Quote
  #10 (permalink)  
Old 03-24-2005, 05:18 PM
Jon Beniston
Guest
 
Posts: n/a
Default Re: Encrypting verilog files

>
> Hello Jon,
> thanks for the hint, I had never heard of an obfuscator before. But if
> I understand it right it is nothing but a script which messes up your
> code.


Yes.

> Still there is a cross reference mapping so that the code can
> still be "unobfuscated" (therefore a risk).


Some info, such as comments and formatting gets stripped away. There's
no way to recover that. I would say it's easier to write some code
form scratch than generate the reverse mapping by hand. Give it a go!
What does this trivial module do?

module l1OOll1O1O ( lll0O10O1O, llO1O0lO1l, llO00l0O0O, l0lO00l100,
l110Ol0OO0, lO01l1111l ); input lll0O10O1O; input llO1O0lO1l; input
llO00l0O0O; input [3:0] l0lO00l100; input [(16-1):0] l110Ol0OO0;
output [(16-1):0] lO01l1111l; wire [(16-1):0] lO01l1111l; wire
[(16-1):0] llOO0l0l1O; wire [(16-1):0] ll0l1101Ol; wire [(16-1):0]
lO111l0101; wire l0l000ll11; wire [(16-1):0] lOll010l1O; wire [3:0]
ll00OlOl10; wire [3:0] l0llOO10ll; assign lO111l0101 = l110Ol0OO0;
assign l0llOO10ll = l0lO00l100; assign ll00OlOl10 = l0lO00l100; assign
llOO0l0l1O = l110Ol0OO0 << l0llOO10ll; assign l0l000ll11 = lll0O10O1O
? lO111l0101[16-1] : 1'b0; assign lOll010l1O = llO1O0lO1l ? lO111l0101
: {16{l0l000ll11}}; assign ll0l1101Ol = {lOll010l1O, lO111l0101} >>
ll00OlOl10; assign lO01l1111l = llO00l0O0O == 1'b1 ? llOO0l0l1O :
ll0l1101Ol; endmodule

> Are these scripts able to somehow flatten a design?


I haven't seen any that can.

> Anybody out there using an obfuscator?


I do.

Cheers,
Jon
Reply With Quote
  #11 (permalink)  
Old 03-24-2005, 08:50 PM
Alexander Gnusin
Guest
 
Posts: n/a
Default Re: Encrypting verilog files

> Hello Jon,
> thanks for the hint, I had never heard of an obfuscator before. But if
> I understand it right it is nothing but a script which messes up your
> code. Still there is a cross reference mapping so that the code can
> still be "unobfuscated" (therefore a risk).
> Are these scripts able to somehow flatten a design?
> I could deliver a flat netlist of my design but then I would loose the
> configurability of it.
> Anybody out there using an obfuscator?
> cheers


You may try so synthesise your code, mapping the function into generic
library only, then flatten it and replace , with some simple script,
all register names to some meaningless ones.
That's may be the good code obfuscation technique.

Regards,
Alexander Gnusin
Reply With Quote
  #12 (permalink)  
Old 03-24-2005, 09:20 PM
mk
Guest
 
Posts: n/a
Default Re: Encrypting verilog files

On 24 Mar 2005 12:50:00 -0800, [email protected] (Alexander Gnusin)
wrote:

>> Hello Jon,
>> thanks for the hint, I had never heard of an obfuscator before. But if
>> I understand it right it is nothing but a script which messes up your
>> code. Still there is a cross reference mapping so that the code can
>> still be "unobfuscated" (therefore a risk).
>> Are these scripts able to somehow flatten a design?
>> I could deliver a flat netlist of my design but then I would loose the
>> configurability of it.
>> Anybody out there using an obfuscator?
>> cheers

>
>You may try so synthesise your code, mapping the function into generic
>library only, then flatten it and replace , with some simple script,
>all register names to some meaningless ones.
>That's may be the good code obfuscation technique.
>
>Regards,
>Alexander Gnusin


But that removes the configurability option. You have to do for each
customer and for each configuration they may want. And it doesn't
prevent them from actually putting the design on a chip even if their
only way of checking timing is simulation.

Reply With Quote
  #13 (permalink)  
Old 03-25-2005, 01:24 AM
Guest
 
Posts: n/a
Default Re: Encrypting verilog files

Better to ask what the module does in this form, since it's trivial to
convert the ugly names. There are perl scripts available on the net to
do this:

module top ( a, b, c, d, e, result );

input a;
input b;
input c;
input [3:0] d;
input [(16-1):0] e;
output [(16-1):0] result;

wire [(16-1):0] result;
wire [(16-1):0] k;

wire j;

assign j = a ? e[16-1] : 1'b0;
assign k = b ? e : {16{j}};
assign result = (c == 1'b1) ? (e << d) : ({k, e} >> d);

endmodule

I think that the method used is really dependent on what's being
delivered. Is it synthesizable RTL code, or a behavioral simulation
model? What are you worried about them doing with the code? And think
about how you're going to work with customers when they have problems.

-Keith

Reply With Quote
  #14 (permalink)  
Old 03-28-2005, 11:17 PM
Guest
 
Posts: n/a
Default Re: Encrypting verilog files

There is a utility called ncprotect provided with NC-Verilog, which
will encrypt the IP. The available encryption algorithms are standard
ones, so you could theoretically write your own utility to do the
encryption. However, I think some of them require a license from the
owners of the algorithms if you wanted to use them.

I don't know what the legal status of the donation is. Since the 1364
standard is starting the balloting process, access to the draft
standard has become more restricted. I also don't know how much was
changed between the Cadence implementation and the final version being
standardized. If you have access to the Cadence documentation, you
should be able to get some information.

Note that this is not the same encryption that you get with Verilog-XL
+protect. That is a proprietary algorithm whose security depends on
the algorithm not being publicly known. It is not a public-key system,
so there would be no way to tell you how to encrypt source without also
revealing how to decrypt it. The new system avoids that problem by
having you select the key, which you can either register with the tool
vendors (if they support you doing that), or encrypt in one or more key
blocks for one or more tool vendors, using public keys provided by each
vendor.

Reply With Quote
  #15 (permalink)  
Old 03-28-2005, 11:36 PM
Guest
 
Posts: n/a
Default Re: Encrypting verilog files

There is limited advantage in using a public key algorithm to encrypt
the source code. The best that could be done that way is that each
tool vendor could publish their public key and embed their private key
in their tools. Then anyone could encrypt for any of those vendors,
but would need to provide multiple versions encrypted with the keys of
each vendor. This can be improved by having the IP vendor encrypt the
source with a normal encryption algorithm and their own key, and use
the public key algorithm just to provide their own key to the different
tools. This way you don't need multiple copies of the source code
encrypted with different algorithms, just multiple copies of the IP
vendor key encrypted with different algorithms. That is a lot smaller.

And you are right, the best that can be done is to make it harder to
peek. Ultimately, the IP has to be decrypted on the IP consumer's
workstation for the tool to compile it, so reverse-engineering the tool
is the easiest way to attack it. All that tool vendors can do is try
to make that reverse-engineering harder.

Reply With Quote
  #16 (permalink)  
Old 04-01-2005, 03:03 PM
Guest
 
Posts: n/a
Default Re: Encrypting verilog files

[email protected] wrote:
> Better to ask what the module does in this form, since it's trivial

to
> convert the ugly names. There are perl scripts available on the net

to
> do this:
>
> module top ( a, b, c, d, e, result );
>
> input a;
> input b;
> input c;
> input [3:0] d;
> input [(16-1):0] e;
> output [(16-1):0] result;
>
> wire [(16-1):0] result;
> wire [(16-1):0] k;
>
> wire j;
>
> assign j = a ? e[16-1] : 1'b0;
> assign k = b ? e : {16{j}};
> assign result = (c == 1'b1) ? (e << d) : ({k, e} >> d);
>
> endmodule



I would be interested in such a Perl script. Any pointers appreciated.

cheers,

P.

Reply With Quote
  #17 (permalink)  
Old 04-04-2005, 11:41 AM
Jon Beniston
Guest
 
Posts: n/a
Default Re: Encrypting verilog files

"[email protected]" <[email protected]> wrote in message news:<[email protected] roups.com>...
> [email protected] wrote:
> > Better to ask what the module does in this form, since it's trivial

> to
> > convert the ugly names. There are perl scripts available on the net

> to
> > do this:
> >
> > module top ( a, b, c, d, e, result );
> >
> > input a;
> > input b;
> > input c;
> > input [3:0] d;
> > input [(16-1):0] e;
> > output [(16-1):0] result;
> >
> > wire [(16-1):0] result;
> > wire [(16-1):0] k;
> >
> > wire j;
> >
> > assign j = a ? e[16-1] : 1'b0;
> > assign k = b ? e : {16{j}};
> > assign result = (c == 1'b1) ? (e << d) : ({k, e} >> d);
> >
> > endmodule

>
>
> I would be interested in such a Perl script. Any pointers appreciated.


An obfuscator will do the job for you! You just have to change it so
that instead of outputing obfuscated names, it outputs a, b, c etc.

Although the above is more readable, for any complicated block of
code, unless you have the original net names, it's still going to be a
hell of a struggle to understand it IMHO.

Be careful though, your IP license probably forbids you from doing
this.

Cheers,
Jon
Reply With Quote
  #18 (permalink)  
Old 04-04-2005, 05:31 PM
Keith
Guest
 
Posts: n/a
Default Re: Encrypting verilog files

Jon Beniston wrote:
> "[email protected]" <[email protected]> wrote in message

news:<[email protected] roups.com>...
> > [email protected] wrote:
> > > Better to ask what the module does in this form, since it's

trivial
> > to
> > > convert the ugly names. There are perl scripts available on the

net
> > to
> > > do this:
> > >
> > > module top ( a, b, c, d, e, result );
> > >
> > > input a;
> > > input b;
> > > input c;
> > > input [3:0] d;
> > > input [(16-1):0] e;
> > > output [(16-1):0] result;
> > >
> > > wire [(16-1):0] result;
> > > wire [(16-1):0] k;
> > >
> > > wire j;
> > >
> > > assign j = a ? e[16-1] : 1'b0;
> > > assign k = b ? e : {16{j}};
> > > assign result = (c == 1'b1) ? (e << d) : ({k, e} >> d);
> > >
> > > endmodule

> >
> >
> > I would be interested in such a Perl script. Any pointers

appreciated.
>
> An obfuscator will do the job for you! You just have to change it so
> that instead of outputing obfuscated names, it outputs a, b, c etc.
>
> Although the above is more readable, for any complicated block of
> code, unless you have the original net names, it's still going to be

a
> hell of a struggle to understand it IMHO.
>
> Be careful though, your IP license probably forbids you from doing
> this.
>
> Cheers,
> Jon


That's a twisted idea - I like it ;-) You could also try vrename. It's
been a long time since I used it, but I think that it could do the job.

I think that anyone relying on obfuscation should at least give this a
shot, and make sure that they feel comfortable with the results.

Regards,
Keith

Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Portability of files written with %z Jonathan Bromley Verilog 6 02-07-2005 06:52 PM
spectre model files for use in verilog ams Vineet Verilog 0 02-27-2004 04:36 PM
How to include paths to Header Files in NC-Sim/NC-Verilog Rajat Mitra Verilog 1 02-09-2004 11:52 AM
Encrypting SDF files for modelsim Paul Richardson Verilog 1 01-12-2004 07:13 PM
Verilog Header files Paulo Dutra Verilog 1 10-29-2003 08:19 PM


All times are GMT +1. The time now is 04:19 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved