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@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
