Re: [dm-crypt] Possibility for safe Luks partition delete functionality

[Robert Nichols <rnicholsNOSPAM@comcast.net>]

On 12/11/2013 02:55 PM, Matthias Schniedermeyer wrote:
> For a non-hybrid HDD a single pass is suppossed to be enough to
> permanently overwrite anything there was before, no recourse whatsoever.
> (Or only the millions of dollar range, a.k.a. "State sponsored enemys")
>
> Non-rotating-platters-of-rust, namely NAND-Flash, are much trickier. If
> you only need to defend against an attacker investing a handfull of
> dollars (a.k.a, let's connect the thing and see what we get with
> standard "get me block X"-commands) a single overwrite/TRIM/Secure Erase
> is enough.
>
> But with just slightly more money (a.k.a., let's desolder the chips and
> see what's the raw contents) it's gets tricky pretty fast. Like you have
> to overwrite the (whole(?!)) contents with random data several times and
> you would still not have a 100% guranteed that the original content is
> really overwritten and not sitting somewhere as "spare" waiting to be
> reused.

The whole point of the anti-forensic splitter in LUKS is to require that
all stripes (4000 by default) of the key material be recovered exactly
in order to get the master key. Even if you can recover 99.9% of that
material, you are no better off than brute-forcing the master key.  For
a non-hybrid HDD, even the most cursory overwrite is going to destroy
_some_ of that key material.

NAND Flash is indeed much trickier. It doesn't (much**) matter what data
you overwrite with since the only thing that actually wipes the old data
is the block erase by the Flash controller. The problem is that even
though the block with the old data has been marked as not in use, there
is no guarantee as to when the controller will get around to doing the
block erase.  (And, TRIM is irrelevant here -- the block was written
to. Ergo, the old one is no longer in use. TRIM is used to inform the
device of blocks that are available even though they have _not_ been
rewritten.)

**The only time that would matter would be if you _knew_ that your write
   was going to be directed to a free block that had previously been used
   for key material.  At a minimum, you would have to write at least
   enough data to fill the (unknown) number of currently unallocated
   blocks to have any assurance of that happening.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.