secure a module

R

Rob

Guest
I'm wondering if there is a way to compile/pack (not sure of the term) a
verilog module so that you can share it without giving away the code.

Thanks,
Rob
 
Of coarse there is. Cadence has a tool called NCPROTECT.
You can protect everything in a module or leave the end user a few things to
still see for debug.

"Rob" <buzoff@leavemealone.com> wrote in message
news:GthCj.6106$7d1.596@news01.roc.ny...
I'm wondering if there is a way to compile/pack (not sure of the term) a
verilog module so that you can share it without giving away the code.

Thanks,
Rob
Click to expand...
 
Rob wrote:
I'm wondering if there is a way to compile/pack (not sure of the term) a
verilog module so that you can share it without giving away the code.
Click to expand...
Either lock it up or give it away.
If you want to share text freely,
all you can do is substitute characters or keywords.
Here's a very insecure example:

72 Thu Mar 13> cat count.v

module count (clk, reset, count);
input clk, reset;
output [3:0] count;
reg [3:0] count;
always @ (posedge clk)
if (reset == 1'b1) begin
count <= 0;
end else begin
count <= count + 1'b1;
end
endmodule

73 Thu Mar 13 > alias obfuscate='tr A-Za-z N-ZA-Mn-za-m'

74 Thu Mar 13 > obfuscate < count.v

zbqhyr pbhag (pyx, erfrg, pbhag);
vachg pyx, erfrg;
bhgchg [3:0] pbhag;
ert [3:0] pbhag;
nyjnlf @ (cbfrqtr pyx)
vs (erfrg == 1'o1) ortva
pbhag <= 0;
raq ryfr ortva
pbhag <= pbhag + 1'o1;
raq
raqzbqhyr

This could be improved by restricting characters
to a more confusing set, maybe Oo0i1|!, but this
is a lot of work and it's still quite breakable.

-- Mike Treseler
 
Dwayne Dilbeck wrote:
Of coarse there is. Cadence has a tool called NCPROTECT.
You can protect everything in a module or leave the end user a few things to
still see for debug.
Click to expand...
Yes, however this restricts the audience to
properly licensed and keyed Cadence users.

-- Mike Treseler
 
On 2008-03-13, Mike Treseler <mike_treseler@comcast.net> wrote:
73 Thu Mar 13 > alias obfuscate='tr A-Za-z N-ZA-Mn-za-m'
74 Thu Mar 13 > obfuscate < count.v

zbqhyr pbhag (pyx, erfrg, pbhag);
Click to expand...
^^^^^^ Not many synthesizers are going to like this.. :)

But instead of writing your own obfuscator you can use the
vrename program in the Verilog-PERL package. vrename has an
option to obfuscate the names across an entire design.

(Although as Mike pointed out, the security of this kind of
method is limited, but the compatibility with various tools
is the greatest which probably has to be kept in mind when
deciding what to charge the customer.)


Besides, who knows how good the various netlist encryption
formats really are? They also rely on security through
obscurity after all.

/Andreas
 
On Mar 13, 11:04 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
Dwayne Dilbeck wrote:
Of coarse there is.  Cadence has a tool called NCPROTECT.
You can protect everything in a module or leave the end user a few things to
still see for debug.

Yes, however this restricts the audience to
properly licensed and keyed Cadence users.

        -- Mike Treseler
Click to expand...
ModelSim and Questa users have access to a number of techniques to
protect their code.
Take a look at the 'Protecting Your Source Code' chapter in the User
Manual

Verilog-2005 standardized a public key encryption system that (should)
be supported by all simulators moving forward (Questa & ModelSim
supports it now)

- Nigel
 
Andreas Ehliar wrote:
On 2008-03-13, Mike Treseler <mike_treseler@comcast.net> wrote:
73 Thu Mar 13 > alias obfuscate='tr A-Za-z N-ZA-Mn-za-m'
74 Thu Mar 13 > obfuscate < count.v

zbqhyr pbhag (pyx, erfrg, pbhag);

^^^^^^ Not many synthesizers are going to like this.. :)
Click to expand...
Yes, please add another line of code
to keep the keywords in the clear!


-- Mike Treseler
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ryan wrote:
The big 3 simulators all support tool specific encryption. If you are
using one of those, and the customer you are sending it to is using
the same thing, that's the way to go. Tool specific encryption is by
far the easiest to use.

Otherwise there's the much more difficult, expensive, and cumbersome
solution of creating a SWIFT model. Which as far as I know, requires
you purchase VMC from Synopsys. It will however generate an encrypted
model that will work with any simulator.
Click to expand...
My understanding is that Synopsys is dropping SWIFT.

- --
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."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH2srWrPt1Sc2b3ikRAnu/AJ9fubNq5xCquLdqbU+9DyI0+r2llgCgi0M3
785suC3/rjkxvcMTVgp1E80=
=e+uz
-----END PGP SIGNATURE-----
 
The big 3 simulators all support tool specific encryption. If you are
using one of those, and the customer you are sending it to is using
the same thing, that's the way to go. Tool specific encryption is by
far the easiest to use.

Otherwise there's the much more difficult, expensive, and cumbersome
solution of creating a SWIFT model. Which as far as I know, requires
you purchase VMC from Synopsys. It will however generate an encrypted
model that will work with any simulator.

Ryan
 
On Mar 14, 11:51 am, Ryan <Ryan.Warner...@gmail.com> wrote:
The big 3 simulators all support tool specific encryption. If you are
using one of those, and the customer you are sending it to is using
the same thing, that's the way to go. Tool specific encryption is by
far the easiest to use.

Otherwise there's the much more difficult, expensive, and cumbersome
solution of creating a SWIFT model. Which as far as I know, requires
you purchase VMC from Synopsys. It will however generate an encrypted
model that will work with any simulator.

Ryan
Click to expand...

A poor mans version of a VMC model might be to use Verilator to
generate C code, build a stripped .so and wrap the functionality in a
module that has a pli call to the verilator generated code in the .so.
Now you a somewhat more portable model that would work with any
simulator that supports PLI. This doesn't keep some one from
disassembling the .so and reverse engineering but it provides a degree
of protection through obscurity.
 
On Thu, 13 Mar 2008 22:00:06 GMT, Rob <buzoff@leavemealone.com> wrote:

I'm wondering if there is a way to compile/pack (not sure of the term) a
verilog module so that you can share it without giving away the code.

Thanks,
Rob
Click to expand...
Almost all major verilog simulators support `protect, `endprotect
pragmas which can be encrypted with an option to the simulator to be
used later. At the moment the encryption is completely vendor
specific. Currently there is an effort to standardize (P1735) the IP
encryption process to use public/private keys so that one can generate
encrypted models more easily.

The process is relatively easy. You annotate the sections of your code
which you want protected with `protect, `endprotect (or // protect,
//begin protect, //end protect) and then use a tool (sometimes the
simulator itself) to generate the encrypted netlist which is your
input netlist where the regions you wanted are replaced with their
encrypted versions (verilog +protect ... or ncprotect or vcs +protect
etc.). Then you can distribute the output netlist which can be
understood by the simulator which did the encryption. Some vendors
even support the same encryption in their synthesis tools (I believe
RC supports verilog protect statements.)
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top