[Cryptography] Secure erasure

[Ray Dillinger]

On 09/08/2016 05:19 PM, Arnold Reinhold wrote:
> On Wed, 7 Sep 2016 17:24 John Denker wrote:
> 
>> The language is guaranteed to produce "the" right answer and leave
>> it in "the" appropriate place.  It offers no guarantees as to how
>> many extraneous copies are left lying around.
> …

Indeed.  That is in fact the main problem.  All these systems
are defined in terms of what they make visible or available,
and security is defined in terms of what is destroyed or kept
unavailable.  The result is that a lot of things are made
available by copying or caching or whatever, when we wanted
to assure that no copies are ever made.  But we don't have
the ability to express that, because NOT making copies isn't
defined in terms of making something visible or available.

Similarly, in the case of memset(), the intent of the code was
to make the data in that buffer UNAVAILABLE - ie, to destroy it
so an asshat trying to scrape it out of the system with a memory
snapshot or a force it to get dumped to disk cache would have a
harder time doing it.  But the compiler looked and said, hey,
this new data being written doesn't have to be available later,
so we can skip the write entirely.  It was designed, from the
ground up, to ignore any instructions except as they relate to
making things visible or available.  And if that visibility or
availability isn't needed, it wants to skip the work of
destroying the stuff it was our intent to destroy.  It's like
we trusted somebody to shred the stuff in the confidential
files in our office, and they didn't bother because they
didn't need the space for new files yet.

There's a fine line between working smarter not harder, and
being too damn lazy and stupid to be allowed to live.  If
an attorney, or a paralegal, or even a secretary, failed in
such a way they'd be fired immediately.  But we're not even
entitled to legitimately complain about the non-performance,
because we weren't even able to explicitly command them to
shred the damn files.  Shredding the files, you see, isn't
making something available or visible.

We have no way to even begin to EXPRESS a positive requirement
for making things invisible, destroyed, or unavailable.

> 
> Imagine for a moment what might be possible if the toolmakers were actually trying to help ....

Oh hell yes.  It would be really REALLY nice if I could declare
something with a keyword like 'secure' instead of 'static volatile',
meaning DON'T make caches of this, DON'T copy its value to anywhere
else as part of an optimization, DON'T allow the OS to swap it
out to disk, DON'T allow the program to exit without explicitly
destroying it, DON'T allow more than my one designated single
security-handling thread to read it, DON'T put it into L2 or L1
on-chip cache, DON'T elide writes to it ever, DON'T ever leave
part of its contents in registers where they might get spilled
into the stack on a call, DON'T allow the power manager to dump
the memory image of it to disk when the machine is going to
sleep (instead just plain EXIT when the machine is going to
sleep), DON'T allow the program to run in any kind of VM, etc
etc etc....

Every last one of these new pieces of functionality intended to
make things visible or available is another DON'T that I have to
add to the list because of that asshat who can set the exec bit
on his malware using the rowhammer bug, or the botmaster who
successfully phished Homer Husband or Harriet Housewife, or the
user whose root password is the same as the password they used
on the account in the un-hashed database that got stolen yesterday,
or whatever else is fresh and bloody this week.  I mean, there's
always going to be bugs because both coders and users are human.
I get that.  But the bugs could be a HELL of a lot harder to
leverage and exploit given tool support.

			Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160909/737c4be4/attachment.sig>