Encrypting verilog files

[Arturi]

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

 

[dont_reply]

"Arturi" <teen_machines@yahoo.com.br> wrote in message
news:1a5dc45a.0503211040.5e6dd6a1@posting.google.com...

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.

 

[Jon Beniston]

teen_machines@yahoo.com.br (Arturi) wrote in message news:<1a5dc45a.0503211040.5e6dd6a1@posting.google.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

 

[Stephen Williams]

dont_reply wrote:

"Arturi" <teen_machines@yahoo.com.br> wrote in message
news:1a5dc45a.0503211040.5e6dd6a1@posting.google.com...

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

 

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.

 

[m]

On 22 Mar 2005 14:46:28 -0800, sharp@cadence.com 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.

 

[Jason Zheng]

mk wrote:

On 22 Mar 2005 14:46:28 -0800, sharp@cadence.com 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.

 

[Ira Baxter]

"Arturi" <teen_machines@yahoo.com.br> wrote in message
news:1a5dc45a.0503211040.5e6dd6a1@posting.google.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?

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/Obfuscators/VerilogObfuscator.html


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

 

[Arturi]

jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0503220224.e5045d4@posting.google.com>...

teen_machines@yahoo.com.br (Arturi) wrote in message news:<1a5dc45a.0503211040.5e6dd6a1@posting.google.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

 

[Jon Beniston]

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

 

[Alexander Gnusin]

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

 

[m]

On 24 Mar 2005 12:50:00 -0800, agnusin@gmail.com (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.

 

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

 

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.

 

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.

 

[pilokino@gmail.com]

spamtokeith@gmail.com 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.

 

[Jon Beniston]

"pilokino@gmail.com" <pilokino@gmail.com> wrote in message news:<1112367835.017855.274350@f14g2000cwb.googlegroups.com>...

spamtokeith@gmail.com 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

 

[Keith]

Jon Beniston wrote:

"pilokino@gmail.com" <pilokino@gmail.com> wrote in message
news:<1112367835.017855.274350@f14g2000cwb.googlegroups.com>...
spamtokeith@gmail.com 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

 

[mag]

On 2005-03-21 22:09:17 -0800, dont_reply said:

"Arturi" <teen_machines@yahoo.com.br> wrote in message
news:1a5dc45a.0503211040.5e6dd6a1@posting.google.com...
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.

So how popular is encryption of IP, especially encryption of IP that is
intended to be synthesized? How open are customers to using protected
IP? What are the pros/cons of an always-encrypted silicon IP business
model?

 

[glen herrmannsfeldt]

mag <mag@internet.com> wrote:
(snip)

So how popular is encryption of IP, especially encryption of IP that is
intended to be synthesized? How open are customers to using protected
IP? What are the pros/cons of an always-encrypted silicon IP business
model?

I do wonder how much it will slow down anyone.

Note that for it to be useful, the tools need to be able to
decrypt it, which means that they need the key. It can't be
that hard for someone to extract the key.

-- glen