I'm working for a company that sell FPGA IP in netlist form. I'd like to protect theses IP as much as I can, to try to make it as hard as possible to RE them. I know I can't possibly fully protect them, but that doesn't mean it doesn't worth trying.
I've already used the "secure netlist" option of the Xilinx tools, but it's not that secure. Also, the net names stays the same. So I'm looking at an obfuscating tool that would rename all net/instances for me. And also other methods you might know ?
Protecting IP is one issue. Providing a means for IP developers to be paid for the use of their IP is another problem (and different). Using multiple IP from multiple vendors, and all getting paid is yet a third problem.
As you point out, today there are few good ways (really none) to do any of the above.
There is AES256 encryption and decryption in V4 and V5 which provides a FIPS-140 compliant solution for the protection of the IP.
But the encrypt/decrypt is not authentication, so it does not help you get paid for your work, it just keeps it a secret.
In Virtex 5, we have provided for decrypting AND reconfiguration, so that you may load multiple encrypted bitstreams (all using the same key), but again, this does not provide a model for IP 'per use' payments. It does allow for secure crypto solutions for applications like SDR.
It is a tough problem, and one we would like to solve (obviously).
The use of physically unique coding function (known as PUF codes) would allow each device to uniquely be matched to a bitstream (only that bitstream can work with that device), but this requires each bitstream to be unique for that part. That doesn't help you, unless the customer emailed you their PUFs and AES256 key and you emailed back the matching (partical) bitstreams.
Challenge response systems (like RSA) are very complex, and would use a lot of silicon. We would also need a battery backed local session key store of about 4 Kb.
This is a topic where there is a lot of opportunity for innovations.
Obfuscation (keeping a secret by keeping secrets) should never be considered secure, as paying someone in the parking lot is all it takes to crack it. Keeping your algorithm a secret is equally dumb, as most "clever" and "secret" functions are easily cracked (since they have had no serious peer cypto review).
Anyone who claims security by obscurity is just ignorant (and dangerous)!
Brands X and A do this for the cores that they resell, so it can be done, but it might also cut your profit margin to zero. Consider distributing your stuff via a vendor IP program.
The only one I know of is dealing with people you trust and signing legally binding contracts. At the high end, customers are willing to pay for source code and support.
When it comes to these things, it ultimately comes down to trusting customers and partners (backed up by a suitable contract, of course).
If someone is determined to crack the IP, they will very probably do so. We both pay per unit for some things and get paid per unit for others. We don't do business any more with certain companies, shown in one particular case where they claimed they only sold 'x' units, but we found out (by coincidentally talking to their biggest customer) that they had sold many hundreds 'x'.
Some might say the pricing was too high, but in that case they were free to ask for renegotiation of the contract or simply stop using the provided functionality - if they stopped, we got nothing (we were paid based on sold units), so we had plenty of motivation to look at it should that happen.
No - Mike is right - do business with those you can trust. I know that's not necessarily easy for some companies and it can be quite a conundrum.
Yes, preventing someone to loading the .bit else where is not really easy ;)
Yes, but that's from the guy who provide the .bit perspective. To protect from a user of the final product.
Here I'm more talking about the guys who receive the .ngc, prevent them to look inside it too easily. (I know a motivated attacker will succeed at looking inside but if it could take him more than 15 min that would be nice ...)
Obfuscating the net name would be a good start, since without names and hierarchy, figuring out how a 10k slices IP work should take him a while.
The point here is not a crypto algorithm at all. Every body knows how to do it (video compression standard). But everybody doesn't know how to do it very quickly and efficiently in a FPGA ...
Yes, a complex design is not well protected when it is in a machine readable format (such as something that is parsed by FPGA Editor).
These techniques will not prevent their IP from being reverse engineered, it just makes it so it would take more time to do so.
One can also prevent the tools from simulating the IP, which may also aid in preventing its miss-use. I do not know how the simulation is prevented, but I can ask if you wish.
If you can get the bits into the fpga securely, and the fpga has network access, then you can easily do per use.
This is where failing to think in terms of systems level solutions generally gets the hardware only guys only part way to a viable solution. At a systems level, simply providing access to a license server can easily lock valuable IP on a per use basis. Again, it's possible to defeat a license server, but it does raise the bar considerably, especially if the license server is not hosted at the customers site.
You should make up your mind about what the threats are. This is called a "threat model".
Write down a list of who might want to violate your licensing terms and what his incentive is (eg quantity of money gained or not spent).
Now figure out how each of the threats can complete, and how you can protect against that. A protection is usually good enough, if it raises the bar higher than the incentive of the attacker (eg more expensive to copy than to buy).
Writing netlist obfuscation tools costs time, and with "found somewhere on the net" grade tools you risk delivered product quality.
It may well be that you are wasting resources on this one, while your threat actually is completely different. Just image a customer who pays
10 units but produces 10000. No obfuscation tool will keep him from doing that. It won't even raise his cost (=lower his incentives to do it).
A proper threat model helps you to identify where your threats are and which ones are effective to counter. Don't spend your resources on measures that counter nothing.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.