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

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

[tada]

Hi everyone!

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 in case of emergency by overwriting it several times with
random data as shred is doing to files for example.

Cheers!
Tada

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

[Heinz Diehl]

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

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

[Heinz Diehl]

On 11.12.2013, Heinz Diehl wrote: 

> You can do that easily by running dd against the first MB's of the
> respective partition..

I forgot: you can just switch off the power, which will surely be
much faster than wiping the LUKS header.

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

[Arno Wagner]

On Wed, Dec 11, 2013 at 20:18:16 CET, Heinz Diehl wrote:
> On 11.12.2013, Heinz Diehl wrote: 
> 
> > You can do that easily by running dd against the first MB's of the
> > respective partition..
> 
> I forgot: you can just switch off the power, which will surely be
> much faster than wiping the LUKS header.

Ah, no? Unless you have it in a RAM-disk? If you power off,
the device is not mapped anymore, but the header is there.
Wit things like rubber-hise cryptoanalysis, you can still get
at it. If the header is wiped, that becomes impossible.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

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

[Matthias Schniedermeyer]

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

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

[Heinz Diehl]

On 11.12.2013, Arno Wagner wrote: 

> Wit things like rubber-hise cryptoanalysis, you can still get
> at it. If the header is wiped, that becomes impossible.

Of course. You will then have the possibility to maybe safe your life
by giving the passphrase to the adversary, which would be impossible
if the header has been wiped.

In all other situations, simply cutting the power will be the fastest
way to secure your data in case of an "emergency".

It all boils down to the fact that WDE is very suitable to protect
your data in case a laptop gets stolen or a harddisk dies, but not
against criminal minds putting a threat on your life.

Furthermore, with solid state drives taking over the market, WDE
renders all of their advantages (high speed and low access time) to
zero.

Just my 5ø.

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

[Arno Wagner]

On Wed, Dec 11, 2013 at 22:48:16 CET, Heinz Diehl wrote:
> On 11.12.2013, Arno Wagner wrote: 
> 
> > Wit things like rubber-hise cryptoanalysis, you can still get
> > at it. If the header is wiped, that becomes impossible.
> 
> Of course. You will then have the possibility to maybe safe your life
> by giving the passphrase to the adversary, which would be impossible
> if the header has been wiped.

That depends on your priorities. Advising things as "wiping"
that do not wipe is not a good idea...
 
> In all other situations, simply cutting the power will be the fastest
> way to secure your data in case of an "emergency".

For varable values of "secure"...
 
> It all boils down to the fact that WDE is very suitable to protect
> your data in case a laptop gets stolen or a harddisk dies, but not
> against criminal minds putting a threat on your life.

It depends. The point is that it it not your decision what somebody
else needs. Hence it is really a bad idea for you to make assumptions
about the protection needs of others....

Arno
 
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

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

[Sven Eschenberg]

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.

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

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
>

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

[Matthias Schniedermeyer]

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

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

[Arno Wagner]

On Thu, Dec 12, 2013 at 01:29:54 CET, Matthias Schniedermeyer wrote:
> 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.

Indeed. Or the manufacturer has some kind of backdoor. That is why
I recommend several overwrites with zeros, followed by physical 
destruction for SSDs. Same, BTW, for "hybrid" drives.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

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

[Heinz Diehl]

On 12.12.2013, Arno Wagner wrote: 

> Hence it is really a bad idea for you to make assumptions
> about the protection needs of others....

Everyone decides for themselves. EOT for me.

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

[Robert Nichols]

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.

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

[Arno Wagner]

On Sun, Dec 15, 2013 at 03:55:22 CET, Robert Nichols wrote:
[...]
> 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.

Indeed. And as soon as an attacker only knows some bits have been 
changed, they have to run though the complete attack effort.

> 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.)

Add to that that SSD internal blocks can be much larger than LUKS
key-stripes, and you are screwed. In fact, the only secure 
thing I see is increasing key-stripe size to more than what the 
SSD has in reserve space and then overwriting everything with
randomness (to prevent compression from working). After that, the
disk is not able to retain the whole key-stripe somehwere.

It might be a good idea to allow key-stripe size to be a parameter
in the future and to be prepared for some users to put sizes in the
multi-GB range in there. On the other hand, this is a brute-force
solution, and the overwrite of the whole disk with random data is 
still needed. So maybe it is better to just warn users away from 
SSDs for this purpose.
 
> **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.

Unfortunately, that does not work. All your writes could go into 
freshly recucled cells and the key-stripe would just remain in there.
All it takes for that is a temporary stack-likle behaviour for
the free-block queue.

Bottom line is that for SSDs and other flash-storage, secure erase of 
a LUKS password or container requires additional physical destruction.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare