Programming and copyright

Hello everybody,

I'm developing a software on a Cyclone FPGA. However now we are think
about the security of the device : i mean, the code is stored on a
flash extern to the Cyclone. What can prevent someone from copying the
data on this flash and clone the product we are doing ?

In Quartus there is a security bit that made me fell confortable,
however it works only with a Max device.

What solution do I have to protect our software ?

Best regards
Nick

In article <sc1bu09h67f7pcn6vcjd8chudvrej6g13v@4ax.com>,
Nick  <char-DONTBUGME-les@YY.iiedotcnam.france> wrote:
>I'm developing a software on a Cyclone FPGA. However now we are think
>about the security of the device : i mean, the code is stored on a
>flash extern to the Cyclone. What can prevent someone from copying the
>data on this flash and clone the product we are doing ?
>
>In Quartus there is a security bit that made me fell confortable,
>however it works only with a Max device.
>
>What solution do I have to protect our software ?

      You sue the bastards who copy it.  Seriously.

      If you want a technical solution, you are going to have to you a
Xilinx Virtex II/IIpro/4 or an Altera Stratix II, which have encrypted
bitfile loaders.

	Digretion: I prefer the approach of the Xilinx parts (volatile
vs nonvolatile key store), but that's just the paranoid in me.  Both
will probably fail against a $100k adversary, both will undoubtedly
fail against a $1M adversary, while the altera one will probably fail
to a $10k adversary while the Xilinx one will probably resist a $10k
adversary until after a $100k adversary shows how to do it.

       But really, the legal approach is probably the least cost,
least hastle, and still reasonably effective way.
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Nick wrote:

> Hello everybody,
> 
> I'm developing a software on a Cyclone FPGA. However now we are think
> about the security of the device : i mean, the code is stored on a
> flash extern to the Cyclone. What can prevent someone from copying the
> data on this flash and clone the product we are doing ?
> 
> In Quartus there is a security bit that made me fell confortable,
> however it works only with a Max device.
> 
> What solution do I have to protect our software ?

Wait for the Cyclone2 with built in Flash, if I'm right.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Rene Tschaggelar wrote:
>
> Wait for the Cyclone2 with built in Flash, if I'm right.
>
> Rene

Hmmm... Does this mean that Spartan parts with embedded Flash are also
around the corner? That would really make by wet dreams complete ;)

--
PabloBleyerKocik /"I believed that people would become programmers
pbleyer        / and not need companies as much. You can see how
@embedded.cl / laughable that was." -- Steve Wozniak

As Nick Weaver explained, you have to assess the budget that your enemy
can expend on his nasty effort. Fuses, antifuses, and EEPROM bits offer
limited protection.  Volatile storage ( with battery back-up) gives
much stronger protection, as everybody "in the know" would agree.
Finally, against the resources of the former KGB or present CIA, or
their counterparts, there may be no complete security. But I hope that
is not your real concern.  ;-)
Peter Alfke

Nick wrote:
> Hello everybody,
> 
> I'm developing a software on a Cyclone FPGA. However now we are think
> about the security of the device : i mean, the code is stored on a
> flash extern to the Cyclone. What can prevent someone from copying the
> data on this flash and clone the product we are doing ?
> 
> In Quartus there is a security bit that made me fell confortable,
> however it works only with a Max device.
> 
> What solution do I have to protect our software ?

Depends on the area of risk, and the product's operation.

  If you are worried about production creep/midnight runs at
an offshore manufacturer, then you need some portion that
you program in house, and supply.

  If you are worried about a 'knock off clone', then you need to
protect up to the cost of them duplicate-engineering, as opposed
to reverse engineering.
  You can include a small uC, or a CPLD, to decrypt the bitstream,
and also provide some co-processing to the FPGA : you then
increase the skill level considerably, way above simple chip-copying.

  You can get FLASH FPGAs from ACTEL, plus there are the MAX II CPLDs
and there are FLASH devices from Lattice, with more imminent, so there
are a number of choices to secure the product, (all of which will
probably need more than one device).

-jg

Peter Alfke wrote:

> As Nick Weaver explained, you have to assess the budget that your enemy
> can expend on his nasty effort. Fuses, antifuses, and EEPROM bits offer
> limited protection.  Volatile storage ( with battery back-up) gives
> much stronger protection, as everybody "in the know" would agree.
> Finally, against the resources of the former KGB or present CIA, or
> their counterparts, there may be no complete security. But I hope that
> is not your real concern.  ;-)

Wasn't there a story about some TLA (three letter agency)
putting taps on fiber optic cables on the bottom of the ocean?
(Without either end noticing.)

How does that compare to reading battery backed FPGA's?

-- glen

On Thu, 13 Jan 2005 15:08:04 +1300, Jim Granville
<no.spam@designtools.co.nz> wrote:

>Depends on the area of risk, and the product's operation.
>
>  If you are worried about production creep/midnight runs at
>an offshore manufacturer, then you need some portion that
>you program in house, and supply.
>
>  If you are worried about a 'knock off clone', then you need to
>protect up to the cost of them duplicate-engineering, as opposed
>to reverse engineering.
>  You can include a small uC, or a CPLD, to decrypt the bitstream,
>and also provide some co-processing to the FPGA : you then
>increase the skill level considerably, way above simple chip-copying.
>
>  You can get FLASH FPGAs from ACTEL, plus there are the MAX II CPLDs
>and there are FLASH devices from Lattice, with more imminent, so there
>are a number of choices to secure the product, (all of which will
>probably need more than one device).


The problem is the cost of developpement is realy high, and the price
we sell our product is high as well. So the engineering cost for the
clone won't be high compared to the selling price.

Having read some documentation about it on the newsgroups, it seems
that nothing can really protect the design, and even the biggest
security can be break. That's bad.

Using a volatile sram + battery to keep the code scares me because i
need to be sure that the product work in more than 10 years. 
I think I'll settle for an external prom chip and a special hanshake.

Thank you for all your answers.

Nick

Hi Nick,

> Hello everybody,
> 
> I'm developing a software on a Cyclone FPGA. However now we are think
> about the security of the device : i mean, the code is stored on a
> flash extern to the Cyclone. What can prevent someone from copying the
> data on this flash and clone the product we are doing ?
> 
> In Quartus there is a security bit that made me fell confortable,
> however it works only with a Max device.
> 
> What solution do I have to protect our software ?
> 
> Best regards
> Nick

I suggest you read the following article:

http://www.altera.com/literature/wp/wp_m2dsgn.pdf

This uses a MAX II as a 'dongle'. The MAX II is - let's say - non-volatile
and generates a continuous stream of bits. The same algorithm runs in the
FPGA, and if there's a mismatch, the FPGA quits working.

I also have an unofficial whitepaper plus reference design that uses a MAX3
device to do something similar, albeit with a less cryptologically sound
algorithm. Contact me on bentw at chello dot nl if you want it. The gmail
address is a spam trap.

Best regards,


Ben

> I'm developing a software on a Cyclone FPGA. However now we are think
> about the security of the device : I mean, the code is stored on a
> flash extern to the Cyclone. What can prevent someone from copying the
> data on this flash and clone the product we are doing ?

Hi Nick.

I don't think there are easy answers here.

If the config code is off-chip, then it can be copied from the flash or 
intercepted at the bitstream pins.

I used to work for a smartcard company and they have the same sort of 
issues:
one has to get a load of blank cards programmed by someone you can't risk 
trusting (e.g. far eastern outfit). How to stop 'extra' cards being made?

The card manufacturer makes them with boot code so they can be programmed by 
the software writers to contain their OS boot code and crypto keys. This can 
be done in bulk, before shipping to banks.

The bank can then 'personalise' cards to individual customers, by talking to 
the OS. The OS handles secure communication, code and data are loaded in 
encrypted form. This includes random elements, so that the encrypted loading 
data is different every time (and thus harder to attack).

The card decrypts the code/data before storage. Smartcards are designed to 
make cracking difficult (though of course it is still possible). Address and 
data lines are in buried layers to make them harder to probe.

FPGAs are not designed with such anti-hacking measures (AFAIK).
By nature, their structure is fairly regular.
There is no dedicated micro to do encrypted loading, and if there were it 
would need a few K of ROM to hold the software. And there would still be a 
decrypted bitstream somewhere that could be probed.

I hear that FPGA makers are trying to add some crypto on some devices, but I 
don't know how effective it will be. Security is not a trivial matter to do 
right.

Essentially, each chip (or batch of chips) has to be different in some way 
(e.g. the loading keys) so that one config pattern cannot config endless 
numbers of pirate products.

One idea (for instance) might be to have the chips have each bit of the 
config shift register XORed with a key bit. You would need to know that 
pattern to XOR the config data. The chip maker would supply the XOR keys, 
and you would create the unique config data for each chip. They can then be 
made up by untrusted party in the far east, who cannot use the data for 
other chips.

Of course the XOR key would be as big as the data so some more practical 
crypto system would be used. But the principle of individualising the chips 
with a key is the same.