Programming and copyright

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.

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,

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:

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.

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.

If you dissected one unit could you find out the construction and circumvent springs etc on others?

Maybe they could make some of the silicon microporous instead. :-)

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).

I guess with FPGA chips, one just needs to protect them for their commercial lives (which may just be a few years these days).

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.

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

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.

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.

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.