[Cryptography] Secure erasure

[John Denker]

On 09/09/2016 12:22 PM, Kent Borg wrote:

> Most of the "secure erase can't work" in this thread seems
> equivalent to "memory can't be trusted". Indeed, there is a lot of
> reason to mistrust hardware. Okay then, do you dare do any
> cryptography at all in your hardware? If so (big if), then how to do
> a secure erase becomes a sensible question.

That argument, oversimplified as it is, cuts both ways.

Back in the Olden Days some operating systems didn't bother to clear
memory before allocating it to a different process,  That wasn't even
particularly unreasonable on a single-owner single-user machine, but
it meant that you could spy on another process just by doing a bunch
of malloc()s.  In contrast, a modern operating system is "supposed"
to be more fastidious than that.

So the oversimplified argument reduces to this: Either you trust the
hardware and the OS to not give away your information, or you don't.
  -- If you don't, then what makes you think it is safe to do any
   crypto at all on this platform?   Your information could be given
   away shortly after it is acquired and before it is erased.
  -- If you do, then what is the added value of your so-called
   secure erase routine?

The way forward is to stop oversimplifying.  Start by asking What's
Your Threat Model.  The real threats come from verrrry far outside
the domain of specification for ordinary computer languages:  cold
boot, attackers with root privilege, NSA "tailoring" (i.e. subversion)
of the firmware in the flash controller, tempest, et cetera.

Let's be clear:  A zeroization routine that might have worked
just fine on an Apple ][e floppy is not good enough for a modern
hard disk, and is guaranteed to do almost nothing on a flash
drive except waste electricity and shorten the useful life of
the drive.

   There are things that could be done, but they involve a lot
   more than writing code with "volatile" keywords.  Support
   is needed at the OS level and the hardware level, down to
   a layer one step above the memory transistors.

This is one of the reasons for the existence of Hardware Security
Modules.  If the bad guys can't get inside, it doesn't matter
whether the software makes frequent calls to the "secure erase"
routine or not.

Here's a low-tech approximation that illustrates the idea:  Put
a single-user machine inside a Faraday cage with locks on the door,
with armed guards.  I'm skipping a lot of details, but the idea
is clear: If the bad guys can't get inside, it doesn't matter
whether the software makes frequent calls to the "secure erase"
routine or not.

On 09/09/2016 09:10 AM, Henry Baker wrote:

> A "linear" object is one which has exactly one reference, and the 
> language and type system conspire to ensure that this constraint is 
> preserved.
> 
> *You* (the programmer) can make a copy of the *contents* of such an 
> object if you wish, but the compiler & run-time system are not 
> allowed to make such a copy

That's an interesting way of formalizing the idea ... but to
implement it would require revolutionary changes, including
the hardware, not just the compiler and the run-time system.
Modern hardware makes copies all over the place without telling
you ... even if it hasn't been "tailored".

> One possible solution: a "one-time pad".  Utilize *two* *independent*
> flash memories, and store a crypto random stream R on one and the
> stream (R xor D) on the other, where D is the stream of *your* data.

Under more than a few threat models, that's a non-solution, because
the same black-bag job that captures (R xor D) can also capture
R.  You'd be better off using ChaCha-style disk encryption, and
then protecting the key.  The key, being smaller than the one-
time pad, is easier to zeroize.  That's still a problem, still
not fully solved, but it's a much smaller problem.

OTOH in some specialized cases splitting the data does help.  For
example, on Tuesday you send a courier across the border.  If he
and his escort arrive safely home and swear that the information
was not compromised, then on Wednesday you send another courier
with the cipher key (or perhaps OTP).  If the bad guys capture the
first courier, you never send the second courier, and the bad guys
learn nothing.  This compares favorably to the insanely laborious
yet ultimately insecure chain of couriers described in
_Cardinal of the Kremlin_.

On 09/08/2016 06:49 PM, Ray Dillinger wrote:

> I have an encrypted swap partition

So do I, if/when swapping is needed.

Most of the time I run with no swap at all.  Usually when I run
out of main memory, it's because some application is grossly
broken, and I'd rather it fail sooner rather than later.