[dm-crypt] SSD disks and cryptsetup-reencrypt

[dm-crypt] SSD disks and cryptsetup-reencrypt

[octane indice]

Hello

I read the FAQ, the point 5.19, especially:
(...)
However, for LUKS, the worst case is that key-slots and LUKS header may end up in these 
internal pools. This means that password management functionality is compromised (the old 
passwords may still be around, potentially for a very long time) and that fast erase by 
overwriting the header and key-slot area is insecure. 
(...)

Now, we have a cryptsetup-reencrypt tool that could change the master-key.
So, we could use it after changing a password for a slot.

But, dm-crypt use 512bytes for block operations, so the problem remains the same?
An attacker with the knowledge of the master-key could read old sectors un-erased and 
decipher data?

Thanks 

Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com

Re: [dm-crypt] SSD disks and cryptsetup-reencrypt

[Arno Wagner]

On Wed, Jun 12, 2013 at 04:44:16PM +0200, octane indice wrote:
> 
> Hello
> 
> I read the FAQ, the point 5.19, especially:
> (...)
> However, for LUKS, the worst case is that key-slots and LUKS header may
> end up in these internal pools.  This means that password management
> functionality is compromised (the old passwords may still be around,
> potentially for a very long time) and that fast erase by overwriting the
> header and key-slot area is insecure.
> (...)
> 
> Now, we have a cryptsetup-reencrypt tool that could change the master-key. 
> So, we could use it after changing a password for a slot.
> 
> But, dm-crypt use 512bytes for block operations, so the problem remains
> the same?  An attacker with the knowledge of the master-key could read old
> sectors un-erased and decipher data?

This is a different problem. An attacker that can recover an old 
key-slot gets the master-key and hence all _current_ encrypted data.
If you re-rencrypt, the master key is changed and only old sectors 
in the "erased" pool could be decrypted with the old master key.
But the attacker would still need to get the old master key somehow
(possibly from the same erased sector pool) and could only decrypt
sectors in this pool. This is far less data the attacker can read.
For example, my Samsung 244GB SSD has something like less than 
12GB erased pool area. (To be really, really sure, this disk would 
require key-slot sizes > 12GB, wasting > 96GB of the space.)

So the mechanism of the problem remains the same, but the "size"
is far less. 

I would reccomend not using re-encryption on an SSD, instead
backup all data, use that ATA secure erase command, and create
a new LUKS container on it. If you do not trust the secure
erase command, use it anyways and physically destroy the SSD
afterwards and restire the backup to a new one.

There is something else you can to that just might solve
these problems (or not): So re-encryption several times.
With a bit of luck, the "erased sector pool" will get completely
re-used in one of the re-encryptions, which would make the
attack infeasible, as the original, old master-key is then
worthless. While it is plausible that this would work (the
SSD should use all erased sectors ith has in store when it
gets overwritten repeatedly), it is by no means assured.
There may be conditions where it legitmately does not do
so and there may be formware bugs that lead to it retaining
old key-slots and sectors regardless. The only way to be
sure would be to de-solder the FLASH chips and check their 
contents. And that would only yield result for that one SSD,
not even for its model or series.

That said, unless you have high-resource attackers to defend
against, with something like, say, 8 complete-disk re-encryptions
you should be relatively secure. But don't blame me if it turns
out you are not.

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] SSD disks and cryptsetup-reencrypt

[Matthias Schniedermeyer]

On 13.06.2013 00:30, Arno Wagner wrote:
> 
> That said, unless you have high-resource attackers to defend
> against, with something like, say, 8 complete-disk re-encryptions
> you should be relatively secure. But don't blame me if it turns
> out you are not.

Or use one of the newer SSDs that take "the easy way" for secure 
erasing.

At last one or more of the current generation controller chips encrypt 
the contents by default (even without enabling FDE), as the controller 
has to do some form of scrambling anyway as high-entrophy is better for 
the flash cells(*). So at least one does AES256 encryption always. When 
you secure erase such a SSD they typically just generate a new key and 
not actually erase the flash-cells. The unknown is if they "drop" the 
old key in a secure way, but if they do there is no way to decrypt older 
content even if you desolder the flash-chips.

Also you have to have to hope that key generation is really random. That 
is something that can't really be proven (only disproven), so personally 
that is not something i could rely on. So i classify it as a "nice to 
have", if it works it is a line of defense otherwise it is "nothing".

Problem is i can't remember which one(s) do(es) that, and it's bed time.
:-)


*:
Something about preventing long streams of zeros, ones or both.


-- 

Matthias

Re: [dm-crypt] SSD disks and cryptsetup-reencrypt

[Yves-Alexis Perez]

[-- Attachment #1: Type: text/plain, Size: 2105 bytes --]

On jeu., 2013-06-13 at 01:43 +0200, Matthias Schniedermeyer wrote:
> On 13.06.2013 00:30, Arno Wagner wrote:
> > 
> > That said, unless you have high-resource attackers to defend
> > against, with something like, say, 8 complete-disk re-encryptions
> > you should be relatively secure. But don't blame me if it turns
> > out you are not.
> 
> Or use one of the newer SSDs that take "the easy way" for secure 
> erasing.
> 
> At last one or more of the current generation controller chips encrypt 
> the contents by default (even without enabling FDE), as the controller 
> has to do some form of scrambling anyway as high-entrophy is better for 
> the flash cells(*). So at least one does AES256 encryption always. When 
> you secure erase such a SSD they typically just generate a new key and 
> not actually erase the flash-cells.

Actually they still need to erase the cells, at least as part of the
garbage collection, since at one point they will be reused. And when you
do a secure erase, the few seconds needed to erase all the cells doesn't
really matter, I guess.

That said, nobody knows exactly what the firmware do.

>  The unknown is if they "drop" the 
> old key in a secure way, but if they do there is no way to decrypt older 
> content even if you desolder the flash-chips.
> 
> Also you have to have to hope that key generation is really random. That 
> is something that can't really be proven (only disproven), so personally 
> that is not something i could rely on.

And one needs to know how it is linked to the ATA password, too.

>  So i classify it as a "nice to 
> have", if it works it is a line of defense otherwise it is "nothing".

Yeah, right now I don't think I'd trust a self-encrypting SSD and would
put luks on top of it anyway. Note that you lose some performances here
since those SEDs work way better on compressible data.
> 
> Problem is i can't remember which one(s) do(es) that, and it's bed time.
> :-)

SandForce (now LSI) controllers. Which can be found in OCZ and some
Intel drives.

Regards,
-- 
Yves-Alexis

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]