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

[Arno Wagner <arno@wagner.name>]

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