[dm-crypt] Possibility for safe Luks partition delete functionality
arno at wagner.name
Sun Dec 15 13:47:38 CET 2013
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
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 Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at 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
More information about the dm-crypt