Creating and encrypting netlists

[Altera_Forum]

I am trying to create a design for a customer that is part netlist, that they cannot edit, investigate or reverse engineer and part VHDL. They bought an algorithm that integrates into one of our boards that they wish to modify (it is an open source algorithm) but obviously we do not want them to get hold of our IP that contains memory interfaces, PCI core etc. I am trying to find out if it is possible to provide an encrypted netlist. I have found the steps to make a .qxp file, but dont understand if this is encrypted or not. Is it possible to view or edit a .qxp file?

[Altera_Forum]

A .qxp is not encrypted, but it is a binary format(i.e. it's not clear text for the design). Users can look at the contents in the technology map viewer and chip planner(the RTL viewer will show the same thing as the technology map viewer since the .qxp is post-synthesis, so high-level ideas like muxes will really just be a sea of LUTs and FFs). Bottom line is that it's do-able, but it would be really difficult. 

 In the next release, coming out any day now, I believe there will be (.QXP as source), where you just give them the .qxp and it is read in directly. Right now you need to give them HDL(just a black-box wrapper).

[Altera_Forum]

Thanks for the info. 

 I have a further question about this. Is this file then family specific (eg. stratix 2, cyclone etc) or could it be used over a variety of families?  If it is family specific, could a .qxp generated for a EP2S60 be used in a EP2S130, for example?

[Altera_Forum]

It is family dependent, as the the underlying structure is post-synthesis, and potentially post-fit(depending on what you choose). That's one limitation for providing IP this way, in that it can be parameterized as the user can't resynthesize it. 

 Within a family, it should work fine to re-fit for an EP2S130. (No guarantees when changing families, though it should be for straightforward reasons, i.e. if you go to a smaller part with fewer PLLs and you need more, it wouldn't fit.)

[Altera_Forum]

A further question  

Would any of the namings from source code make their way into the netlist? That could give clues as the the purpose of various areas of logic?

[Altera_Forum]

Node names will be visible in timing analysis, Chip Planner, Technology Map Viewer, etc. Combinatorial node names are really difficult to figure out what they're doing since it's at the LUT level, but register names usually match your source code, so if you're worried about them sniffing stuff inside your logic, this is not a good solution at all. It's more of an impediment to them re-engineering your design. (And at that, it wouldn't pass any true security standards.) The .qxp wasn't really designed as a security feature, it just works nicely that way. I know Altera does have a way of protecting IP, but I'm sure there will be hoops to jump through...

[Altera_Forum]

Is it possible to export a flattened netlist?

[Altera_Forum]

There was a way to export a .vqm, but it's been disabled for newer families(or more specifically, it was never created.) Look under Assignments -> Settings -> Compilation. A .vqm is a Verilog file that is purely structural(i.e. it instantiates LUTs, FFs, etc.) I believe it is "flat" in that there is only one hierarchy, but all the node names imply hierarchy, i.e. you have a flop-flop whose name is top|hierA:instA|hierB:instB|count[2]. SYnplify and Precision are 3rd party synthesis tools that write out netlists too. (Synplify writes out .vqms too, while I think Precision writes out EDIFs. They have the same information, but I've found EDIFs much more difficult to understand) 

 One thing you might want to google is "obfuscation". The idea is a tool that goes through your code and renames everything to nonsensical names, so what was original a state-machine with states idle, push_data, wait, and end_packet, would still be a state-machine but the names would be xhs, fafs, fafdsaf, fadasf, and hsdf. A synthesizer doesn't care about names, so you get the same results, but trying to decipher intent is much more difficult. You could provide obfuscated code(so the user would, in essence, have your source), or a .qxp after obfuscation. Just an idea.

[Altera_Forum]

Unfortunatly most of the source for this design is in BDF and AHDL, and theres alot of it, with quite a few levels of hierarchy. So any flattening and obfuscation would have to be done at the netlist stage.

[Altera_Forum]

How concerned are you that the customer may try to reverse engineer your design? If it's a huge concern(say you have some killer IP that is your bread and butter), it may be worth putting a lot of work into this. If it's a case of "I doubt they'd ever do it, and if they did I'd be upset but progress fine", then maybe the .qxp or something like that is the best flow.

[Altera_Forum]

Hi all 

 I'm reviving this thread since it is still relevant to me.  I've supplied another company a qxp file, but I now I want to add a secret key to it. would it be possible for them to find out the value of this key? of course they can locate the FSM that uses it, but will they be able to locate this constant?  I don't know if this is of any importance but I'm using quartus 8.1  thanks in advance.

[Altera_Forum]

I think so. It wouldn't be too easy, but should be do-able. When providing a .qxp, it's a binary, but after place-and-route the design isn't encrypted or anything. They could look in the Technology Map Viewer to see what logic is in there(it's not intuitive at all, but again, do-able). If you really need something encrypted, try and get in touch with Altera. They and their IP providers do have a way of encrypting IP(often source) so that it is unreadable in all phase of the fit.

[Altera_Forum]

I have been in this very position, and spoken to altera about it. 

 Apparetly the only way to go about encrypting at this level would be to join the Altera IP development program or whatever it is (the thing that provides PCI cores and the like) but then your IP becomes available to the world.  Basically there is no way to actually encrypt the QXP file as is, you'll just have to hope they dont try and reverse engineer it (though, if its a fairly involved design, that would take some serious resource that they could probably have used to develop their own version in the first place!)

[Altera_Forum]

It would be nice if the .qxp's could be encrypted, basically a button that says this can't be looked at in Altera back-end tools. It wouldn't need a license or anything, it would just do some of the stuff that's already done with the licensed IP. The IP could still be compiled by anyone who had the .qxp file, so it doesn't prevent re-use, it just puts up more roadblocks for reverse engineering. I filed something, but please file an SR too. It won't help today, but might be something down the road...

[Altera_Forum]

I think the reason that there is no "user" encryption is because all the IP encryption, is more a security by obscurity than a true secure encryption. 

 If you think about it, there is no way to securely encrypt an IP at this level. Like it or not, Quartus must be able to decrypt the IP to produce the configuration file, which means that the key and decryption routine must be local to the user computer.  All you (and Altera) can do is obfuscation, and keep the encryption/decryption process as private and as undocumented as possible.

[Altera_Forum]

--- Quote Start ---  I think so. It wouldn't be too easy, but should be do-able. When providing a .qxp, it's a binary, but after place-and-route the design isn't encrypted or anything. They could look in the Technology Map Viewer to see what logic is in there(it's not intuitive at all, but again, do-able)  --- Quote End ---    I've browsed the qxp using the technology map viewer but it seems to me that constant values are some how synthesized away, are you it is doable to find them?     --- Quote Start ---  I have been in this very position, and spoken to altera about it.  Apparetly the only way to go about encrypting at this level would be to join the Altera IP development program or whatever it is (the thing that provides PCI cores and the like) but then your IP becomes available to the world.  Basically there is no way to actually encrypt the QXP file as is, you'll just have to hope they dont try and reverse engineer it (though, if its a fairly involved design, that would take some serious resource that they could probably have used to develop their own version in the first place!)  --- Quote End ---    assuming that my bosses would agree to making our design open to world(though it is relevant to very narrow market), would altera charge a fee for joining the program?  my main concern is about duplicating our design to more boards then we know of, not reverse engineering (most of the IP is implemented in SW which they get a binary of)     --- Quote Start ---  It would be nice if the .qxp's could be encrypted, basically a button that says this can't be looked at in Altera back-end tools. It wouldn't need a license or anything, it would just do some of the stuff that's already done with the licensed IP. The IP could still be compiled by anyone who had the .qxp file, so it doesn't prevent re-use, it just puts up more roadblocks for reverse engineering. I filed something, but please file an SR too. It won't help today, but might be something down the road...  --- Quote End ---    I've opened a service request explaining the problem and I'm waiting for a replay.   another thought that came to my head, are there any third part tools that might help me, like precision that creates edf, maybe it is not viewable in the technology map viewer.

[Altera_Forum]

They will synthesize down the downstream logic. So a constant 1 will not show up in the logic, it would just get removed and whatever it drove would have logic reductions based on that. The constant will not be obvious by any means, but it is probably "do-able" if you really know what you're doing and had lots of time.