Of course this is purely hypothetical since -- right now -- none of them do.
But it occurred to me that vendors like Actel could disclose their bitstream format without scaring their customers and admitting that the emperor has no clothes when it comes to bitstream security-as-obscurity.
Getting the bitstream out of a flash/antifuse device that isn't designed to emit it is probably harder than reverse engineering Xilinx/Altera's bitstream formats. And if you already know how to disassemble chips and get a mask image out of them, well, the so-called bitstream "encryption-but-you're-shipping-the-decryption-key to-all-your-customers-in-this-little-black-package" is worthless anyways.
Supposing somebody was able to present one of these vendors with a tangible justification (ie way they would make more money) for publicizing their bitstream format, does anybody think they would publish it?
Thus you have the encrypted bitfile loading on the Virtex lines. Personally, I think the V4 version is easily good enough for protecting a $10,000 secret, and I could probably be OK comfort wise protecting a $100,000 secret.
Hey Nick, 441 Soda Hall just isn't the same without you.... =(
Well, IMHO it doesn't qualify as encryption when the chip itself -- which you're giving to your customers -- contains the decryption key.
$10k (loaded cost) will buy you about half a month of a mediocre hardware engineer's time. I doubt many of Xilinx's customers' designs are that simple. Even
For a non high volume board, would that be enough so the vendor would notice?
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
Physical means. There are quite a few companies in Taiwan that specialize in this. There might also be noninvasive imaging techniques similar to those used for MRI or perhaps even Van Eck phenomena. Dallas Semiconductor is pretty familiar with these attacks since they specialize in designing NVRAM devices that clear themselves in such scenarios.
Actually, I would sincerely hope that the key isn't held in any sort of "memory"; even ROM. If I were designing such a system I would make sure that the "key" was an emergent property of some structure with lower spatial complexity than the key itself (for example, a sequential circuit computing the collatz sequence).
I suppose an even better protection technique would be to base the key on some analog, physical property of the chip itself combined with a per-chip "offset" value. For example, a function of the ratio of oscillation frequencies of two pairs of inverters, plus some offset value "X" which is computed during the testing process and then flashed onto the chip (ie each chip has a different oscillatior value due to process variations as well as a different X -- but they all sum up to the same universal decryption key).
I hadn't thought of this before; this would actually be pretty hard to extract. But at the same time I doubt that Xilinx is hiding any NVRAM in their chips; if their process allowed for that they would probably offer some of it to their customers -- even a few bytes would still be handy.
I suppose that this is my core point: as long as every Xilinx chip of a given type is exactly the same with respect to the part of it that performs decryption, I'm highly suspicious of any design security claims.
And if you're going to go so far as adding nonvolatile storage to a chip, well, you might as well go the Actel route and save your customers the hassle of putting an extra chip on board just to serve up the configuration data. This also means that a breach of one particular device's security doesn't compromise the IP of every single customer at the same time because of a shared secret: Xilinx is putting all of their customers in the same high-profile basket.
And, you are correct, we have no NVRAM in our FPGA devices right now. If we did, we would first use it for more useful things (like serial numbers, lot code, etc).
NVRAM as I described is not secure, so using it for security means the secret you wish to keep is not worth very much. But, hey, there are lots of folks that have inexpensive secrets. I just do not know any that are seriously considering basing their entire product line's secrets on NVRAM solutions.....
And, we have "been there, done that" on having some kind of structure that is inherent in the device, but which provides a unique ID or key. Never succeeded in making any of the methods work. We make just too many chips. And will it change over time? Well, Vts, Idsats, and just about everything else now changes over time (the transistors themselves change as they age in these ultra-deep sub-microm technologies).
Aust> Physical means. There are quite a few companies in Taiwan that
Okay, so, it appears that my argument became invalid about a week ago when the Virtex4 shipped. My apologies for this.
But at the same time, so did the argument "we can't document the bitstream because it will compromise customer design security".... So, what is the current reason for not publishing the bitstream format?
I was probably a bit too specific there; I meant any sort of customer-writable memory that doesn't get cleared when you take away the main power supply to the device. The battery-backed memory for storing a customer-specific decryption key is close enough -- in fact, this is what Dallas Semico uses (rather than flash or some other zero-current storage).
I'm quite happy to see this; unlike previous schemes, this is something I would actually trust. A customer-specific (or design-specific) key is definately the only way to go for any sort of real security.
I admit I'm puzzled. Within a given 'package' form-factor, the Virtex-4 and Virtex2P parts are going to have nearly identical circuitry (since they come off the same lithographic manufacturing process.)
If you developed a field-process to extract the config-bitstream of 1 loaded/configured FPGA, presumably you could do it to any other FPGA based on the same die.
So does it really matter whether the 'secret key' was unique to each customer's bitstream?
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.