NV on-chip memory?

Guy wrote:

> As far as security for Key storageI did say there weren't alternatives that
> already exist, I was exploring the benefits of this new alternative.  Then
> the conversation moved to other secure data storage.  AES is current, before
> it were many other encryption standards, as time marches on, Secure becomes
> a non-absolute changing value.  I am posing an alternative that might
> provide an equal or greater cost function of obtaining a stored Key than
> volatile/battery SRAM etc.

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

In article <7dL6d.4447$nj.3468@newssvr13.news.prodigy.com>,
Guy <guys@altera.com> wrote:
>Nicholas -

>First, I have made my disclosure which unfortunately was taking 3-9
>hours to post by Google which exacerbated this whole thread - sorry.
>I will continue under this Moniker until the end of this thread at
>which point I will move on to a new user name.  I attempt to remain
>anonymous for now as have many individuals on news groups do for
>various reasons.

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.


> Anyways, I did not understand your point about the cost of a
> standard solution for AES solution.  That was my whole point that
> potentially using a huge cost of detection NV technology would save
> costs in different ways: on chip NV configuration storage reducing
> system costs (battery, cpld, external config data).

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.

I'll be back in the morning.


what do you think?
"Nicholas Weaver" <nweaver@soda.csua.berkeley.edu> wrote in message
news:cjg594$28r1$1@agate.berkeley.edu...
> In article <7dL6d.4447$nj.3468@newssvr13.news.prodigy.com>,
> Guy <guys@altera.com> wrote:
> >Nicholas -
>
> >First, I have made my disclosure which unfortunately was taking 3-9
> >hours to post by Google which exacerbated this whole thread - sorry.
> >I will continue under this Moniker until the end of this thread at
> >which point I will move on to a new user name.  I attempt to remain
> >anonymous for now as have many individuals on news groups do for
> >various reasons.
>
> 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.
>
>
> > Anyways, I did not understand your point about the cost of a
> > standard solution for AES solution.  That was my whole point that
> > potentially using a huge cost of detection NV technology would save
> > costs in different ways: on chip NV configuration storage reducing
> > system costs (battery, cpld, external config data).
>
> 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

> I have even been told that reading out the state of our battery backed 
> key memory can be done today.

> The reason why I do not believe the latter, is that they have to do it, 
> while keeping the battery backed memory power ON.

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?


> Don't bother to argue with me.  It is the NSA, CIA, etc. you would have 
> to convince.

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.

In article <BGN6d.4506$nj.4491@newssvr13.news.prodigy.com>,
Guy <guys@altera.com> wrote:
>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?

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.

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

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

Hal,

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

Austin


Hal Murray wrote:

>>I have even been told that reading out the state of our battery backed 
>>key memory can be done today.
> 
> 
>>The reason why I do not believe the latter, is that they have to do it, 
>>while keeping the battery backed memory power ON.
> 
> 
> 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?
> 
> 
> 
>>Don't bother to argue with me.  It is the NSA, CIA, etc. you would have 
>>to convince.
> 
> 
> Only if that's his market.  Maybe what he is thinking about is good
> enough for some high volume commercial applications.
> 

Guy,

<ignore>

Austin

Guy wrote:

> I thought I was being clear when I said not to assume I was affiliated with
> Altera.  So to be clear about it, I am not employed by Altera nor do I have
> the ability to know whether they are considering or Analyzing NV memory for
> use in their FPGAs.  Unfortunately, when creating my original post, I did
> not realize nor intend for the Altera email address to have been posted I
> simply thought it was a log-in procedure, a GOOGLE NEWS GROUP limitation I
> did not remember since it has been a long time since using Google to post
> (rather than other more anonymous methods).  This lead to my reason for
> disclosure.
> 
> 
> 
> As an FPGA industry veteran,  I am however very interested in continued
> market research and discussions, which I hope you will agree, can be
> beneficial to all FPGA users to create and provide vendors feedback.
> 
> 
> 
> AUSTIN-
> 
> You have made assumptions in your postings/responses with respect to
> security.  I never mentioned the word government or any of their standards.
> You have assumed once again.  Shame on you again? - Just kidding.  Anyway,
> the link you provided to the xilinx website was informative
> (http://tinyurl.com/496n2).
> 
> 
> 
> A couple of comments:
> 
> In one of my earlier posts, I did not include other options when mentioning
> NV memories in SRAM fpgas, I should have included battery backed SRAM, Fuse
> based methods for Key storage, distributed polygon approaches and likely
> others.
> 
> 
> 
> One of the most important points the Xilinx link makes which Austin
> neglected in his assumption that Security is no less than 100%, is the
> tradeoff of security with cost.  While I did say that it was undetectable, I
> did not say it was suitable for government applications (another
> assumption).   So, the implication in the original posting is that there
> would be a very low cost NV solution that would be super costly to reverse
> engineer (order(s) of magnitude more difficult that Flash or even Antifuse)
> providing a significantly lower cost solution for those non-government
> applications needing high security than the solutions that Altera or Xilinx
> currently offer.
> 
> 
> 
> A decent article talking about security from a practical perspective:
> http://www.algotronix.com/content/security%20FPL%202001.pdf
> 
> 
> 
> Also, now coming back to government, although I am not familiar with the
> specific published requirements (I add that due diligence to my to-do list),
> I do believe security has been moving target with rising requirements even
> for government./?   So, just as Austin says that there might be ways to
> detect and capture the Volatile SRAM stored KEY thus enabling the cracking
> of governement data stream there is a level of probability and cost function
> involved that is the current governement requirement.  I'll bet that this
> requirement and cost function will continue rise in time.
> 
> 
> 
> Austin - Why is it impossible to believe that a new NV memory technology can
> actually exceed this probability / cost function of detecting the stored
> volatile key?
> 
> 
> 
> 
> 
> As for Paul's comparison to Max II - I really do not see very many parallels
> to the bulk of the discusson in this thread regarding applications for the
> NV on chip memory.  Max II does have NV memory and can potentially integrate
> an external solution.  I am trying to emphasize that much of this thread is
> beyond that - especially with respect to larger data storage and other NV
> needs (like that of  secure processor code).
> 
> 
> 
> 
> 
> More discussion?
> 
> Thanks.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message
> news:0LqdnVRXQ4PYyMbcRVn-vA@rogers.com...
> 
>>>That's a disclosure ?
>>>Q: Do you work for Altera, or are affiliated with Altera ?
>>
>>My guess is no, this Guy guy does not work for Altera.  If he does, it's
> 
> the
> 
>>first I've heard of him and he is violating Altera posting protocol by not
>>clearly stating his affiliation in each posting.  His email address is
> 
> also
> 
>>not in the format of an altera address for someone with the name Guy, and
>>besides it bounces.
>>
>>
>>>Q: Are Altera considering/analysing NV memory in FPGA ?
>>
>>We have Non-Volitile memory in our MAX II CPLD family.  A Flash block is
>>used to store the device configuration program.  We also expose 8 Kb of
>>Flash memory for use by the user -- for example, to absorb functions
>>normally stored in off-chip serial eproms, such as a device serial number.
>>
>>I cannot comment on whether or not we are considering it for future FPGA
>>families, except to say I doubt we would conduct market research in a
> 
> public
> 
>>forum such as this.  We typically talk to all of our big customers to get
>>feedback on family plans, and this is done under NDA.
>>
>>Regards,
>>
>>Paul Leventis
>>Altera Corp.
>>
>>
> 
> 
> 
> 

Guy wrote:
> 
> Let me first say thank you for your responses.
> To address some of the questions / comments:
> I realize that not everyone will extract the same application or value
> from the on-chip NV memory, however, since it has the potential to
> provide or support different applications, general enough value may be
> justified for inclusion.
> Answers / Comments for Jim and Hal:
> a.  bad bits:  built in ECC would make bad bit transparant to the user
> 
> b.  speed = assume approximately 25ns access time
> 
> c.  width = flexible, 16/32/64 bit
> 
> d.  secure code storage would come by two assumptions:  i) on-chip
> processor preventing external need to access the memory. ii) readback
> via JTAG etc of Memory would be programmed as disabled by the user
> 
> e.  on-chip charge pumps require no special external voltage supply
> 
> f.  user application would be able to log/write data to NV memory for
> storage
> 
> g.  external applications could read NV data too, but you obviously
> loose security
> 
> h.  OTP = nonerasable

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.  


> i.  no tradeoff with NV and Ram like functionality - it would be a
> standard feature, not swappable block within the silicon family
> 
> j.  yes for non secure, it would enable integration into the FPGA of
> on-board NV data for some applications (mature s/w code for example).
> Realize that also for some applications, you can create a sense of
> "virtual" unlimited multiwrite capability.  To demonstrate what I mean
> by Virtual multi-write, I'll use the following example.  Let's say
> that you know you may need to write 10,000 maximum lifetime events at
> 100 bits data each but do not need to keep history for more than 16
> events.  As a designer, you could buy a tiny block of flash or EEPROM
> of 1.6kbits and keep writing over the older events.  Or, with OTP, you
> could simply purchase enough OTP memory to store the entire lifetime
> worth of events.  Many applications that store NV data can quantify
> the lifetime of storage from a practical specification.  One example,
> Televisions need to store user configuration (like:  color, tint,
> favorite channels etc), and need to provide the user with unlimited
> adjustments of this data.  However if you make some assumption, the
> design can calculate an upper limit of needed storage.  For example,
> lets say 512bits stored, TV life is 20 years.  I would venture to
> guess that if you assumed that data storage would occur Max once a day
> for each of 20 years, you would be happy to remove the $1 EEPROM from
> the board as long as the on-chip cost of the NV block was less.
> 20yr*512b*365days = 7Mbit total
> 
> Any other creative thoughts on how this could be used would be
> appreciated.

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

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

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.

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

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 Leventis
Altera Corp.