Encrypting verilog files
Arturi
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_m...@yahoo.com.br> wrote in message
news:1a5dc45a.05032...@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.
sh...@cadence.com
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.
mk
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.
Jon Beniston
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
> "Arturi" <teen_m...@yahoo.com.br> wrote in message
> news:1a5dc45a.05032...@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."
Jason Zheng
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
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
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
> 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
mk
wrote:
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.
spamt...@gmail.com
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
sh...@cadence.com
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.
sh...@cadence.com
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.
pilo...@gmail.com
> 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
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
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
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
(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
Stephen Williams
Indeed, and the `protect/`endprotect support is defined so as to
allow for th decoding to easily work in a preprocessor, which can
then feed decrypted verilog to the main compiler. If I were to
implement `protect/`endprotect in Icarus Verilog, that is how I
would do it. But of course that would offer up a trivial way for
the user to get a decrypted version of the IP. Think DMCA.
The most exasperating application of this is Xilinx uses encryption
to distribute their *simulation* *models*. This pretty much rules
out using open source tools (Icarus Verilog / Verilator / cver) to
simulate those models.
Andy Botterill
>
> The most exasperating application of this is Xilinx uses encryption
> to distribute their *simulation* *models*. This pretty much rules
> out using open source tools (Icarus Verilog / Verilator / cver) to
> simulate those models.
>
XXX_timesim.v with few problems. I had had to make minor changes to the
simprim.v file to cover for some minor differences between what isim
will accept and what cver will accept. I think cver is more strict on
syntax than isim. Maybe when I am closer to finishing my design (I wish)
I will buy modelsim for a sign off simulation. I'm using webpack 10.1.02
under linux. Andy
Stephen Williams
You misunderstood me. Icarus Verilog and cver and others can
simulate all the various unisims and simprims models just fine.
In my day job we do all sorts of FPGA designs and we simulate
before and after P&R using Icarus Verilog.
The problems come with simulating using models for various other
Xilinx supplied IP cores. Those models are encrypted. (They used
to use SWIFT, but Synopsis dropped SWIFT and no one else took it
up.)
Andy Botterill
> Andy Botterill wrote:
>> On 03/17/2010 04:31 PM, Stephen Williams wrote:
>>>
>>> The most exasperating application of this is Xilinx uses encryption
>>> to distribute their *simulation* *models*. This pretty much rules
>>> out using open source tools (Icarus Verilog / Verilator / cver) to
>>> simulate those models.
>>>
>> I use cver and can simulate the p&r gate level netlist e.g.
>> XXX_timesim.v with few problems. I had had to make minor changes to the
>> simprim.v file to cover for some minor differences between what isim
>> will accept and what cver will accept. I think cver is more strict on
>> syntax than isim. Maybe when I am closer to finishing my design (I wish)
>> I will buy modelsim for a sign off simulation. I'm using webpack 10.1.02
>> under linux. Andy
>>
>
> You misunderstood me. Icarus Verilog and cver and others can
> simulate all the various unisims and simprims models just fine.
> In my day job we do all sorts of FPGA designs and we simulate
> before and after P&R using Icarus Verilog.
>
> The problems come with simulating using models for various other
> Xilinx supplied IP cores. Those models are encrypted. (They used
> to use SWIFT, but Synopsis dropped SWIFT and no one else took it
> up.)
I haven't needed to use encrypted models. It's against my concept for my
home project. Sorry for misunderstanding. Andy
>
>
Ira Baxter
"mag" <m...@internet.com> wrote in message
news:2010031622340816807-mag@internetcom...
> On 2005-03-21 22:09:17 -0800, dont_reply said:
>
>> "Arturi" <teen_m...@yahoo.com.br> wrote in message
>> news:1a5dc45a.05032...@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.)
>>
An alternative is IP obfuscation, which doesn't require any decryption
at the recieving end. It doesn't offer perfect protection, but then
nothing does; the argument is does it provide enough for your purposes
and only you can decide that.
See
http://www.semanticdesigns.com/Products/Obfuscators/VerilogObfuscator.html
--
Ira Baxter, CTO
www.semanticdesigns.com
David Rogoff
I've worked with lots of vendor IP that used obfuscation. All signal
and module names are 8 characters long and made up of ones, zeroes,
lower-case "l", uppercase "I", and uppcase "O". So much fun to debug :)
Petter Gustad
> An alternative is IP obfuscation, which doesn't require any decryption
> at the recieving end. It doesn't offer perfect protection, but then
Synthesis and flattening of the netlist to some simple generic library
would also be quite effective if the netnames are assigned in a
similar fashion.
Petter
--
.sig removed by request.
vpo...@gmail.com
https://ipencrypter.com/wp-content/uploads/2016/11/ipe1735v2-1610-1-0-ug01.pdf