These things do not have to be mutually exclusive : you could deploy obscurity AND Volatile Keys AND NV cyphers AND UniqueID Seeds, all together in the maximal designs. Each one hikes the time/cost to crack the system. In most commercial systems, you only need to hike it above the cost of development (or possibly above litigation risk-cost, as you may be doing some of this to make it impossible to verify patent infringement ;) In government/banking etc, the data payloads give different cost thresholds.
Actually, most on this newsgroup are DELIBERATELY non-anonymous. If you want to verify me, or Peter Aflke, or Ray Andraka, or just about everybody else on this newsgroup post under their own names because it tells alot, and can be used as a pointer to their copus of work.
EG, Ray Andraka is a top flight FPGA engineer, able to get things to fit that others would give up on.
While I'm a slighly loony ivory tower academic, who's better at coming up with ways to destroy systems.
Just accept that Nonvolatile cells are vastly easier to probe, because to probe a volatile cell, you have to remove the chip, and probe the signals under several layers, without disturbing the power supply. It IS doable, mind you, but its a lot more work.
Thus the plaintext key which holds the rest of the system together (eg, the bitfile encryption key) is best stored in volatile cells, and are specified as such in many places.
The AES point is that you have an AES key embedded in the bitfile, that is used to on the fly encrypt/decrypt a large external store. Thus to crack the store, you need to get either the encrypted AES key by either doing an analysis on the soft-core encrypter OR on the hard-core bitfile loader to get the bitfile's key which is protecting the AES key.
Thus the keystone of unencrypted data is the volatile SRAM of the bitfile encryptor, which should be harder to extract than data stored in nonvolatile cells.
Also, since you are posting anonymously (falsly), remember that neither Xilinx nor Altera will willingly slow down the circuits, and adding fab steps would be a big No-Go unless the payoff is really, REALLY big.
As I've said, one can use the existing bitfile encryption, a battery, an external flash, and about ~1000 slices of glue to create a large nonvolatile protected store, which will be more secure than efectively any solution which just uses nonvolatile storage.
--
Nicholas C. Weaver. to reply email to "nweaver" at the domain
icsi.berkeley.edu
Nicholas- Thanks for the response. Unfortunately because of my current employeement, I can not post as myself like I have done in the past. I recognize that value and promise in due time, I will do it again. (After this thread I will change to a different anonymous moniker).
You raise good points, but it appears that you are making assumptions about NV memory detection when you mention probing - doesn't that assume that there is actually a charge (a la flash) stored? What if there was some other storage mechanism, almost like an un readable ROM bit?
Would you agree that if the difficulty/cost of extracting a KEY from this NV memory exceed that of the battery/SRAM storage, then it could very well be considered a superior mechanism? This is what I would like to explore.
Also, don't forget the fact that one would not even need to store a key for the configuration data since it would be stored on chip in this NV memory.
Just because we don't know how to do it yet doesn't mean that somebody else doesn't know how to do it. Or that it can't be solved with enough money.
On the other hand, if it's cheaper to use social engineering or a rubber hose, then it's good enough.
How long do your bits last if I just disconnect the battery? (leakage vs capacitance) What if the chip is cold?
Only if that's his market. Maybe what he is thinking about is good enough for some high volume commercial applications.
--
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.
No, I am just assuming that because there is something static there, it is easier to probe because you don't need to worry about fubaring the power supply and a bunch of other things in the process.
I don't care if its antifuse, FLASH, or MysticPixieGates: the NV ram must have a property where you can repeatedly attempt to distinguish a cell's contents by measuring its behavior without worrying about disturbing the power supply while getting to that point where you can probe the bit.
I SEROUSLY doubt the cost of extracting a key from any NV storage you could imagine would be easier than extracting it from sram cells, see above and lots of exercises by attackers on the subject.
--
Nicholas C. Weaver. to reply email to "nweaver" at the domain
icsi.berkeley.edu
The colder is gets, the less charge leaks off, and the more likely the bits are retained.
A count to ten at room temp seems to be effective (without power), so I imagine it might stick around for hours at -40C, and perhaps days at 77K (liquid nitrogen).
Still, working on it under liquid nitrogen is probably going to be a bit tough.
And stripping off those metal layers to get to it, that is another problem while keeping power on it.
Basically, all we have to do is offer a secure enough solution that the attacker moves on to a less secure objective (like the box with the poly fuses which the IEEE published photomicrograph and techniques for to see which ones are programmed or not).
That makes it much *less* useful. When a CPU is put into an FPGA, it is a real encumbrance to use external memory and the internal FPGA memory is often not large enough for program storage. Having a hunk of NV
*rewritable* (such as flash) memory would be very useful for this sort of app. When are SW programs *ever* mature??? My network router already has a code update waiting to go into the Flash.
One poster indicated that 128 bits for a unique serial number would be useful. We have used Dallas one-wire parts for that sort of thing. So that could put a $1 price on providing a bit of NV memory, but the Dallas parts also have a bit of EEPROM memory, so again the reprogrammable feature is important.
Another feature that we look for often is a way to provide a software configurable board jumper. This jumper needs to be reprogammable, control a signal on the board, and be asserted from power up. Currently we use a Flash PLD for this.
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
But why is NV more interesting than general purpose SRAM?
Are you looking for something big enough so that the normal config loading mechanism can't handle the extra load? (Say
10 times the config size.)
My straw man to compare with would be lots more RAM on the FPGA, using current technology. (My guess is the market isn't there or somebody would have done it by now.)
--
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.
Features like theses are why we include 8 Kb of user useable, in-system reprogrammable Flash in Max II. If you can give people a cheap CPLD, and absorb an adjacent ~$1 part too, that's worth a lot to users.
But what about FPGAs?
On the high end of things, absorbing a $1 part in a $100 FPGA is less interesting, especially if the extra masks and processing needed to make the NV memory increases the cost of the FPGA. This only becomes potentially interesting if footprint is the issue, but serial EEPROMs are pretty tiny.
At what point does it become worth absorbing the $1 part into the FPGA? For small low-cost parts (Cyclone, for example, as Guy used in his original post), this could be equivalent to a ~20% savings. But if you incorporate NV in the low-end of the family, you probably do so across the entire family since you want to use the same process, unless it is simple to nuke the extra masks and get back to a process with the exact same costs (production and characterization) of a vanlilla CMOS.
And there is the issue of what size process technology you can use, and how much overhead there is to incorporating NV. For example, if you want Flash the smallest available process is maybe 0.13u (from what I've seen in the press), so you take a big cost hit compared to using 90 nm. Also, you need sense amps etc. as well as the bits, so once you through in a small bit of memory, you might as well throw in a little more...
And you have ask -- what are you gaining by incorporating an NV RAM? Is it a cost reduction? Why would an FPGA and discrete NV RAM be more expensive than an FPGA including NV RAM? Combining two dice into one larger die can increase cost due to higher chance of defect. Is it for lower footprint? Certainly there could be niches that would like the footprint reduction of combining two functions into one, but is it large enough to support the development and is it worth taxing all the other users who don't care about footprint?
Incorporating extra functionality in an FPGA is usually done because it provides some additional advantage beyond absorbing external components. Let's look for a second at incorporating volatile RAM. Altera clearly thinks it is worth including medium-sized SRAM blocks (hence the 512 Kb rams in Stratix and Stratix II). Designs often require one or two large RAMs (off-chip) for long-term data storage, and a few medium RAMs for buffering data (packet headers, line buffers in video apps), and many small RAMs for a slew of applications including buffering. While discrete SRAMs are cheap, you need to consume a lot of I/Os to talk to them, which burns power and means you need to route a lot of traces. So bringing most RAM functions on-chip can pay-off for the small and medium RAMs. More importantly, by using multiple on-chip SRAMs you can achieve higher bandwidth and/or lower latency than off-chip RAMs, so there can be a system performance advantage as well.
Yet Xilinx does not include SRAMs larger than 18 Kb in their parts. If the market is divided on incorporating medium SRAMs, my guess is it's a long way from thinking big NV rams are needed.
Paul- you make some good points in your discussions especially about the $1 extra cost compared to a $100 FPGA as well as highlighting the significance of saving that same $1 if it was in a Cyclone low cost device.
However, how would you change your mind if some of the newer developing NV memory technologies were similar in size to flash cell/dram cell (
a) I doubt it would come without a process penalty in the .13 or 90nm node (or the equivelent at a given point in time). If it could, that might be another story.
b) If it could, it would need to be many times rewriteable to be acceptable to the FPGA companies. One of the real advantages of the FPGAs over other technologies (antifuse, etc) is the unlimited rewrite capability. THus a write once or limited write memory would be far less useful.
c) My point is that the security aspect of embedded NVram is significantly less when compared to using the existing SRAM-based bitfile encryption to protect a large external nonvolatile store. So I'm a naysayer on NVram.
--
Nicholas C. Weaver. to reply email to "nweaver" at the domain
icsi.berkeley.edu
Regarding point d - I agree depending on your cost threshold for security and purpose. S/W code flexibility? Cost of Battery+NV chip = 20% premium on $10 12K Lcell low cost device? I think decision will vary situation by situation.
For points a and b - regarding rewriteable flexibility - despite the value - I have been told by many FPGA Vendor employees that something like 50% of FPGA users do not provide means for in-field configuration data upgrades. For these customers I thought that on-chip OTP NV data would provide extra storage utility since they do not have the external NV chip. Thoughts?
Well, if we knew a way to replace the configuration storage latches with NV cells of the same size, reliability, unlimited re-writability, and fast speed (?), without a negative impact on the processing complexity or yield, you bet we would do it, whether it's needed for security or not... But... Peter Alfke
RAM would be ok, but I am assuming that NV is cheaper than RAM. But there are multiple ways that adding NV memory affects chip costs and area is just one.
BTW, that brings up the issue of RAM cell size. I recall that Mosys has a 1T sram cell using a single transistor and a capacitor. This sounds like a DRAM to me. Anyone know how this works? To the best of my knowledge it does not require any refreshing or is that somehow done invisibly? They don't call this peusdo-SRAM and I believe they have some patents on it.
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
That is what he is describing. I don't know if he knows something we don't, but certainly it is conceivable that a new NV type could be process compatible with CMOS.
I don't know how many times you would feel the need to write your NV ram. But various formats of separate chips only provide anywhere from
1000 to 100,000 guaranteed. I expect there are tons of apps for even
1000 time rewritable NV ram.
But for the low end cost market, there is no built in encryption hardware. That is only on the expensive chips like Virtex-II and 4. Spartans don't have it and I believe we are talking about the low cost chips. If you are using the $100 FPGA, I don't think an external $1 NV memory will be a problem. With the low cost chips, the on board NV ram is likely more secure than than an encrypted external NV store since the encryption mechanism is not protected in any way.
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
I would like to add my 'wish-list' for an FPGA: As I'm working with processors in FPGA I always need external SRAM: costing money, PCB space, routing troubles, more pins... I would like to see more SRAM on-chip. I don't need it as super-fast dual-ported block RAMs. I would be happy with a single port 10-20ns access RAM, but larger. Let's say 128KBbytes (not bit) to 1MB in EP1C3-EP1C12 devices. When the system memory is integrated I will vote for smaller packages: tqfp100 or even tqfp44. The idea is the same as for microcontrollers in very small packages. And an open documentation (not only as feature in NIOS) how to write to the serial config Flash from within the FPGA.
my 2c Martin
---------------------------------------------- JOP - a Java Processor core for FPGAs:
Martin- It makes sense that integrating ram replacing external memory would reduce pin count etc, the confusing part of your message is realted to this thread being NV memory oriented. Do you want your 128KB on chip memory truly for ram or for code storage? Does that relate to the NV aspect of the discussion for those low density devices you mention?
Do you know this *specifically* about the Mosys design? Exactly how do they work the refresh into the ram without disturbing the timing? These are not asynch parts, but synch parts running at up to 200 MHz IIRC.
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
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.