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

[Matthias Schniedermeyer <ms@citd.de>]

On 12.12.2013 00:22, Sven Eschenberg wrote:
> Well usually those SSDs don't use any ecryption key, as long as you don't
> use a HDD password (supposedly). Of course they could possible create a
> random key and then write 'zeros' during secure erase, which would
> incidently result in random content.

As the Secure Erase on the SSD i tested only takes seconds, i would 
assume they (optionaly) reset the key and mark all sectors for reuse in 
the wear-leveling-table. And then erase the cells either in the 
background or the next time they are used. IOW the data is not really 
erase immediatly, only inaccessible by normal read commands.

> But judging from experience, it would be quite foolish to assume
> manufactures do anything properly or the way you'd expect it ;-).

Excactly.
There is no real way of verifying what actually happens and if it done 
in a way that really is secure.

The "content"-key can be something like MD5(serial_no + generation_no). 
Which looks random in each iteration, but would be easily cracked by the 
manufacturer.


> Reagards
> 
> -Sven
> 
> On Wed, December 11, 2013 21:55, Matthias Schniedermeyer wrote:
> > 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
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 

Matthias