FPGARelated.com
Forums

Programming and copyright

Started by Nick January 12, 2005
Symon,
	Crikey!  I hadn't realised it was that commercial yet.
This stuff must be the ultimate nightmare of some groups.  I
guess legislation will catch up soon enough.

Weird seing the computer jagon crud mixed with quantum physics,
much more of this to come...

9 times out of 10 it will probably still be breakable as managers
will go for it without learning the science, and you'll end up with
the same key being reused (QC is only tuely secure if all keys are
varified as unsnooped, are used *once* and only once and are never
stored in anything but very volatile memory :-) and the terminals
at either end running some unpatched OS, being on some unsecured 
network and having a keyboard or video logger installed :-)

I wonder which generation of X & A parts will have QC capable
electro-optics (or just opto-optics) on the die?

Cheers,
	Chris

Symon (symon_brewer@hotmail.com) wrote:
: Christopher,
: There's an article all about Quantum Cryptography in this month's SciAm.
: Google   "Best-Kept Secrets" sciam
: These people can do it over 120km! http://www.magiqtech.com/press/qpn.pdf
: Cheers, Syms.

: "c d saunter" <christopher.saunter@durham.ac.uk> wrote in message
: news:cs75m8$g8$1@heffalump.dur.ac.uk...
: >
: >
: > All change again soon, for short distances at least quantum entanglement
: > based encryption (for key exchanges) is now a fibre based reality... - the
: > USP of this tech. is that by the (current) laws of Physics we *would* know
: > if the data traveling through the fibre is tapped.  So they'll just have
: to
: > tap it somewhere else...
: >
: > ---
: >
: > cds


On Fri, 14 Jan 2005 01:39:07 +0000, c d saunter wrote:

> Symon, > Crikey! I hadn't realised it was that commercial yet. > This stuff must be the ultimate nightmare of some groups. I > guess legislation will catch up soon enough. >
They'll just fall back to the standard BBB methods of intelligence gathering - burglary, bribery and blackmail. Mass-monitoring of communications has such an incredibly low signal-to-noise ratio that any useful information is drowned out by the rest of the world going about their business.
In article <PcvFd.107$9P5.106@newsfe3-gui.ntli.net>,
Kryten <kryten_droid_obfusticator@ntlworld.com> wrote:

>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.
Both Xilinx and Altera have a pretty sophisticated mechanism in their more expensive parts. Basically both have a small encryption engine which can decrypt a bitfile as it is loaded. The key for this encryption is specified by the programming customer and stored either as Flash (Altera) or battery-backed SRAM cells (Xilinx). Both are possibly succeptible to sidechannel or fault injection attacks (I'd bet probably), and the altera parts can always be delidded and probed to get the key (this is harder on the Xilinx because of the need to not disturb SRAM state until you can probe the bits). Both use high quality block cyphers, with the first-gen using 3DES and the current gen using AES. I would comfortably keep a $10k secret in the Xilinx parts, and uncomfortably keep a $100k secret if I could also play with the packaging (eg, route the battery through a series of wire coils throughout the packaging, to add to physical tamper resistance). -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.edu
Nicholas,

The latest V4 has 256 bit AES, as opposed to S2's 128 bit AES.

Both are considered unbreakable by a brute force attack (today).

The BB RAM key storage in V4, V2P, and V2 is a bit tougher to break (pun 
intended) than the e-fuse (which can be viewed optically and read out as 
to their state).

The government routinely uses a spring loaded contact to remove the back 
up battery to 'zeroize' the keys.  This extra level of physical security 
in the packaging of the product makes cracking safe enough for the 
homeland security types.  Of course, before they had BB RAM, they used 
thermite charges to destroy the device if it was tampered with, so 
packaging options were also used effectively to 'zeroize' the whole 
danged thing!  Hard to get UL listing when your product contains an 
explosize incendiary device....

At this time, we have sent our 'logic vault' encryption/decryption eval 
platform to a number of intersted parties, who have promised us to do 
their best to crack them.

The good news is that so far, there is no news.

Since there is no such thing as a secret (obscurity never lasts 
forever), we assume that any method used to crack will become known. 
Once known, we have to be able to find a way to make that attack 
inneffective.  I highly recommend reading up on safe-cracking, as that 
is a field that is quite mature, and has many lessons for what is 
acceptable, or not acceptable security.  For example, a safe's hardness 
is rated in minutes to penetration by a determined and skilled attacker, 
with a bank vault being only perhaps 30 to 40 minutes harder to break 
than a wall safe.

Since there is no 'security in obscurity' we are interested in any real 
attack that might be used, so we can only do better next time.

Austin


Nicholas Weaver wrote:
> In article <PcvFd.107$9P5.106@newsfe3-gui.ntli.net>, > Kryten <kryten_droid_obfusticator@ntlworld.com> wrote: > > >>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. > > > Both Xilinx and Altera have a pretty sophisticated mechanism in their > more expensive parts. > > Basically both have a small encryption engine which can decrypt a > bitfile as it is loaded. The key for this encryption is specified by > the programming customer and stored either as Flash (Altera) or > battery-backed SRAM cells (Xilinx). > > Both are possibly succeptible to sidechannel or fault injection > attacks (I'd bet probably), and the altera parts can always be > delidded and probed to get the key (this is harder on the Xilinx > because of the need to not disturb SRAM state until you can probe the > bits). > > Both use high quality block cyphers, with the first-gen using 3DES and > the current gen using AES. > > I would comfortably keep a $10k secret in the Xilinx parts, and > uncomfortably keep a $100k secret if I could also play with the > packaging (eg, route the battery through a series of wire coils > throughout the packaging, to add to physical tamper resistance).
In article <1vsdu01dfl4or8dqmc6p2p7o5faqikol10@4ax.com>,
Nick  <char-DONTBUGME-les@YY.iiedotcnam.france> wrote:
>On Thu, 13 Jan 2005 09:31:09 GMT, Ben Twijnstra <btwijnstra@gmail.com> >wrote: > >>I suggest you read the following article: >> >>http://www.altera.com/literature/wp/wp_m2dsgn.pdf > >Thank you very much Ben, this white paper is very interesting. It will >provide a fairly good level of reliability for our design. >I shall contact you in a few days. > >Thank you again, you relieve me of a great pressure.
Frankly, don't bother. This app note is CRAP. 100% pure bovine extract. Altera should be ashamed of putting it on their web site. You might as well ask clunkerbell, the magic anti-piracy fairy to protect your design. This style of protection would stop only a very poor amature. The attacker can take the device and the bitfile, and either extract the DES key from the FPGA rather than the MAX2 part (the key is not just in the MAX2 part, but in plaintext in the FPGA), or even more straightforward, trace the connections from the MAX2 part to the FPGA in the FPGA's configuration, trace the enable line in the bitfile, and edit the bitfile to tie this line high. Don't bother wasting the board space or design space on this. If you actually are paranoid enough that the threat of a $1M-100M lawsuit against someone who pirates your design is insufficient security, use a Cyclone II, Virtex II/IIPro, or Virtex 4, with their encrypted bitfile loading options. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.edu
"Austin Lesea" <austin@xilinx.com> wrote in message 
news:cs9f5l$mnq1@cliff.xsj.xilinx.com...

> The latest V4 has 256 bit AES, as opposed to S2's 128 bit AES.
Interesting. Since cryptographic processing is becoming increasingly useful in applications, is the crypto hardware available for use after loading? I suspect it isn't something that the chip makers thought of at the time, but I'd guess it would not be a huge job to multiplex the signals to the rest of the FPGA and say "finished using this for loading, now available to the FPGA application" NCypher in Cambridge UK use FPGA for their web security hardware accelerators, for instance. It might make them more efficient to use the custom-made loading crypto hardware instead of using general-purpose FPGA logic for it.
> The government routinely uses a spring loaded contact to remove the back > up battery to 'zeroize' the keys. This extra level of physical security > in the packaging of the product makes cracking safe enough for the > homeland security types.
If you dissected one unit could you find out the construction and circumvent springs etc on others?
> thermite charges to destroy the device
Maybe they could make some of the silicon microporous instead. :-)
> At this time, we have sent our 'logic vault' encryption/decryption eval > platform to a number of interested parties, who have promised us to do > their best to crack them. > > The good news is that so far, there is no news.
Surprising. I recall specialist labs being able to crack most smartcard keys in about 15 minutes, and they were impressed if they had to take over an hour. Howe expert were the interested parties? I hear it costs several million dollars to get smart card software tested and approved to the top banking security levels (named IPSEC6 or similar, IIRC).
> For example, a safe's hardness is rated in minutes to penetration by a > determined and skilled attacker, with a bank vault being only perhaps 30 > to 40 minutes harder to break than a wall safe.
I guess with FPGA chips, one just needs to protect them for their commercial lives (which may just be a few years these days).
> Since there is no 'security in obscurity' we are interested in any real > attack that might be used, so we can only do better next time.
Indeed, security should lie in the key not the method. Everyone can read how Chubb locks work but this won't tell you the key pattern.
On Fri, 14 Jan 2005 22:38:14 +0000 (UTC),
nweaver@soda.csua.berkeley.edu (Nicholas Weaver) wrote:

>Don't bother wasting the board space or design space on this. If you >actually are paranoid enough that the threat of a $1M-100M lawsuit >against someone who pirates your design is insufficient security, use >a Cyclone II, Virtex II/IIPro, or Virtex 4, with their encrypted >bitfile loading options.
I just need to sell a fair security to my boss. The copyright is the best protection IMHO, but he wants something more. Well, that's something more and it sounds strong enough for me. The cost is minimal compared to switching to a new device. Nick
In article <zt0Gd.556$7C4.122@newsfe2-gui.ntli.net>,
Kryten <kryten_droid_obfusticator@ntlworld.com> wrote:
>Since cryptographic processing is becoming increasingly useful in >applications, is the crypto hardware available for use after loading? I >suspect it isn't something that the chip makers thought of at the time, but >I'd guess it would not be a huge job to multiplex the signals to the rest of >the FPGA and say "finished using this for loading, now available to the FPGA >application"
Except that as hard-cores go, AES doesn't save much. Its only 10 BlockRAMs and ~600 slices for a key agile, >1.5 Gbps AES core. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.edu
In article <jighu0hfup9bj6sp9tbin91d25uecke1lk@4ax.com>,
Nick  <char-DONTBUGME-les@YY.iiedotcnam.france> wrote:
>>Don't bother wasting the board space or design space on this. If you >>actually are paranoid enough that the threat of a $1M-100M lawsuit >>against someone who pirates your design is insufficient security, use >>a Cyclone II, Virtex II/IIPro, or Virtex 4, with their encrypted >>bitfile loading options. > >I just need to sell a fair security to my boss. The copyright is the >best protection IMHO, but he wants something more. Well, that's >something more and it sounds strong enough for me. The cost is minimal >compared to switching to a new device.
Do the math. This will take at least $2-5k of design time (its something else to verify, test, include on the board, etc), and an extra $4/part in production cost. For protection which I could assign an undergraduate class to subvert. And which would be amusing, for sh*ts and giggles, to even write a tool to automatically bypass for Altera's reference code. This simply fails on a cost/benefit basis: I can understand using a chain made of bubblegum wrappers to lock something up. Sometimes bubble-gum chains are appropriate security. I just can't understand PAYING so much for the bubblegum-wrapper chain. And given that it is a bubble-gum wrapper, why not just use an LFSR instead of DES/3DES: its' much smaller and cheaper, and in the end, provides the same level of nearly-nonexistant security. Or just don't bother at all. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.edu
> >Don't bother wasting the board space or design space on this. If you > >actually are paranoid enough that the threat of a $1M-100M lawsuit > >against someone who pirates your design is insufficient security, use > >a Cyclone II, Virtex II/IIPro, or Virtex 4, with their encrypted > >bitfile loading options. > > I just need to sell a fair security to my boss. The copyright is the > best protection IMHO, but he wants something more. Well, that's > something more and it sounds strong enough for me. The cost is minimal > compared to switching to a new device. > > Nick
You can get some decent security by using FPGAs with a built in configruator, like the Secure FPSLIC, but it won't stop the three letter organisations. You have to open the package and probe the die to get to the bit stream. -- Best Regards, Ulf Samuelsson. Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Nordic AB.