[Cryptography] Photon beam splitters for "true" random number generation ?

Wed Dec 30 02:56:12 EST 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/29/2015 05:41 PM, Peter Todd wrote:

> Another way this failure can happen is in firmware: flash chip firmware
> notices that some cells aren't able to be reliably rewritten (or soon
> will be) and goes into read-only mode to preserve user data.

We are having two separate conversations here.  We need to distinguish
  a) the limitations of today's firmware, versus
  b) the fundamental limitations of the technology.

Realism is good, but fatalism and defeatism are bad.
 a) As of today, bad things happen in firmware all the time, on
  *every* write to flash, whether there is an error or not.  
 b) Looking into the future, most of the problems are eminently
  fixable.

> to preserve user data.

That highlights one of the fundamental (but fixable) problems.  As
of today, the computer industry considers "reliability" to mean
protecting user data against erasure.  In contrast, the crypto
community thinks "reliability" includes protecting user data 
against eavesdropping.  The two requirements are diametrically
opposite;  one seeks to preserve bits, while the other seeks 
to obliterate bits.

In normal routine operation, SSD firmware could securely obliterate
bits if it wanted to.  The problem is, as of today, it doesn't even
try.  It leaves extraneous copies lying all over the place.

> You have to remember that flash cells usually required a voltage above
> VCC to erase the cells; flash chips have relatively complex and fragile
> charge pumps (usually w/ on-chip capactitors) that generate the
> relatively high voltages required to erase the flash cells. Those charge
> pumps can fail in a multitude of ways, with the result being that one or
> more blocks can be read, but can't be erased. (usually all blocks, as
> there's usually a single charge pump for the entire chip)

That's true, the charge pumps are fragile.  And in all likelihood
the same charge pump is used for programming (writing zeros) and for
erasing (writing ones).  So if the charge pump fails, neither the
erase cycle nor the programming cycle is available for obliterating
sensitive data.  The chip becomes read-only, whether you like it
or not.

On the other hand, there should be no way this can happen without
being noticed.  The user's write() operation should return an error
code.  Let's assume there is private data on the chip at this point.
  -- If in response, the user throws the memory card in the trash,
   and the attackers scoop it up, there is gross data leakage.
  ++ If in response, the user incinerates the chip, or grinds it to 
   dust, there is no data leakage.

To summarize:  There is no point in talking about failure modes in
present-day chips, because the chips are disastrously insecure even
when they are working as designed.  In contrast, in the future we
could write security-conscious firmware.  It would still be easy 
for the attackers to cause gross failures, but it would become
hard to cause subtle failures.  Maybe I'm overlooking something,
but if the user practices decent tradecraft, I don't see the gross
failures as being much of a problem.  I don't mind annihilating a
chip, so long as I don't have to do it very often.

- --------

One super-easy way to annihilate a chip is to throw it into warm 
hydrofluoric acid.  That vigorously removes the insulating layers
(nitride as well as oxide) and shorts out whatever's left.

There was some talk of using a high-temperature torch to reduce
the chip to slag.  That's overkill.  All you need to do is get 
the thing hot enough so that the tunnel oxide becomes reasonably
conducting.  A candle flame is hot enough.  Red hot for 60 seconds
should be plenty.

A microwave oven offers another quick-and-easy option.  This has
the advantage that practically everybody already has a microwave
oven.  Another advantage is that in an emergency, if the storm
troopers are coming up the stairs, you can incinerate a chip
without removing it from its epoxy packaging ... although I
don't recommend breathing the fumes from pyrolized epoxy.