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@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
