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.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
