Electronics > FPGA

FPGA Design Security, Without Limiting Modification

(1/5) > >>

gnuarm:
I have a board I designed and sell to a major networking company.  We recently had some manufacturing issues because of component availability (not the semiconductor shortage, but a factory fire).  They are still happy to work with me, and are asking for a redesign of the board to remove the parts we can't buy any longer.

As part of this, they want the right to manufacture the board, if my company is "unable to build or deliver forecasted quantities due to unforeseen supply chain circumstances, IP and manufacturing rights would be relinquished over to" XYZ company. 

The IP rights would absolutely not be transferred, in the sense of them owning the design.  But I'm ok with them making the boards, as long as they pay royalties. 

The question here is, how can I provide them with the design for manufacturing without also giving away the keys?

First pass thought, use an SRAM FPGA with a separate Flash chip.  Flash chip is copyrighted.  Let the law protect me.  lol  I expect a major US company would not violate this protection.  However...

It seems clear to me, their intent is to have the IP for making the board, but also for maintenance.  We made some minor mods to rev 1 and rev 2 of the board after in production (this will be rev 3, of course).  Or maybe not.  Maybe the IP rights are requested just to avoid any claims of copyright violation???  As long as they pay me, I'm fine.

Still, if I want to give them sources to the FPGA code, is there a way to protect the IP rights from being copied without compensation?  I found this page at Intel. 

https://www.intel.com/content/www/us/en/support/programmable/support-resources/design-examples/vertical/ref-des-secur-mem.html

Seems to be about a chip that could be sold (I assume programmed) so the design can't run without it.  They don't actually give much details, so I'm not clear.  However, it looks like it only protects the bitstream and could easily be worked around if you recompile the sources. 

I know there are a few one time programmable FPGAs, but I'm not very familiar with them.  The Lattice iCE40 parts have nonvolatile, one time programmable memory.  I could specify the part number of a programmed chip, but they still would be able to work around this if they had a source code.

I think the secure Xilinx chips had to have the key programmed after assembly with the key backed up by a cap or something. 

By selling them a physical entity, it allows me to know how many they are building.  That's a good feature.  I might even be able to have a distributor handle all the order taking and give me my cut! 

I'm starting to think this is not going to be so easy to figure out.  I'm sure I'm not the only one to want something like this.

Just to be clear, I'm not expecting this to foil major attempts to break security.  It's not state secrets. 

abyrvalg:
A pretty old FPGA protection idea not requiring any special FPGAs: a small, but essential part of design is moved into a separate small CPLD connected to a bigger FPGA doing the major work. You keep the CPLD content in secret, program them, ship to the manufacturer and thus control the production quantity.
Seen that implemented in some instruments - a big Spartan plus a small CoolRunner. One of them (a Swiss-made USB analyzer) even had the CPLD programmed by some 3rd party mass programming company (or Xilinx themselves?) with a custom name lasered below the CPLD name, so the designer company even didn’t need to run their own mass programming, passing that to a reputable 3rd party.

langwadt:
if you give them the source I don't see how you can stop them building their own

the xilinx fpgas have one time programmable efuses, so you can give them an encrypted bitfile and it'll only work on fpgas that have the right key in efuses, but it requires you program the key in every fpga

gnuarm:

--- Quote from: langwadt on September 24, 2022, 11:20:36 am ---if you give them the source I don't see how you can stop them building their own

the xilinx fpgas have one time programmable efuses, so you can give them an encrypted bitfile and it'll only work on fpgas that have the right key in efuses, but it requires you program the key in every fpga

--- End quote ---

If I give them the source, encrypting the bit file won't accomplish anything. 

I'm thinking more in terms of what abyrvalg wrote, but even then, if they want the source to the FPGA, they will want the source to the CPLD. 

A dedicated chip that would make the design not work without it would work.  That's what they were essentially talking about in the paper, but even that requires a part of the design to disable the FPGA without the "key" chip.  Putting any functional part of the design into a separate CPLD or other programmable device would allow them to design around that.

I was thinking of something like a Maxim chip that has a unique serial number in each one.  I could reserve a bank of 20,000+ serial numbers in my company name.  They can not be sold to anyone but me.  But how to make the FPGA not work without the chip?  If the method described in the paper were part of the FPGA, rather than software, maybe that would work.  Or, a method where the FPGA itself has some aspect that they must buy them through me.  Even this has the issue of the customer simply buying the non-keyed FPGAs and compiling the software to run on those! 

rstofer:
If your customer is willing to buy a license for the code and you're willing to sell it for a bunch of money, sell it on a non-exclusive basis.  You retain the right to sell the same code elsewhere for different or even identical applications.  If they want an exclusive license, the price goes way up.

Engineering is fun, production is boring.  Sell the code for as much as you can get and walk away.  Or, take an equity position in your customer's company.  Profit is fun too!  A license fee based on sales is a pretty good idea.  They don't pay if the product doesn't sell and you're motivated to do upgrades for increased earnings.

You can try to work with hardware security but, in the end, it doesn't work under all conditions.  Sometimes the application is so obvious that the code simply flows from your fingers.  Once it is known that a problem can be solved, alternative solutions abound.

Navigation

[0] Message Index

[#] Next page