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

[Matthias Schniedermeyer <ms@citd.de>]

On 11.12.2013 20:16, Heinz Diehl wrote:
> On 11.12.2013, tada wrote: 
> 
> > I was wondering if it is possible to add something like shred or wipe
> > functionality for Luks devices, call it luksWipe, to safely delete the
> > luks header
> 
> You can do that easily by running dd against the first MB's of the
> respective partition..
> 
> dd if=/dev/zero of=/dev/sdaX

That heavily depends on who is the "bad guy" and what storage technology 
is used.

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.

Altough at least some current SSD (don't know which ones) are supposed 
to be secure if you use Secure Erase. Thoses SSDs always encrypt the 
content as a way to guaranteed randomness of the data, which is supposed 
to be better for the flash-cells. So when you need a "scrambler" anyway, 
you just use AES256 and also have something you can advertise, 2 flies 1 
stone. So when you secure erase such a SSD it (supposedly) discards the 
previous encryption key and generates a new one. If that is implemented 
correctly (which you or i can't really proven one way or the other) it 
would be safe. A single Secure Erase (overwriting not necessary) 
effectivly would make the problem "you need to brute force an AES256 
key" to even get to the RAW content.



-- 

Matthias