SSDs & flash... and "secure" keyslot wiping The storage devices are usually constructed with reliability vs cost in mind. In LUKS we have problem of safe deletion of old key material (keyslot). In short, on keyslot change we need delete old key material or at least make them unusable. How this can be achieved depends on storage used... 1) Rotational devices, aka classical disks Rotational drive today has processor which boots firmware which is "smart" in sector/track management functions. It surely reallocates sectors. The disk lies where it really stores data, in fact even with rotational disk you have no idea what exactly happens. If data is written to media, disk re-reads them and if any problem appears, the area is marked bad and sector is written to some other area (disk still have correct data in memory). So even initial LUKS format can create some data copies. Wiping data area several times is perhaps just snake oil medicine but should not hurt here. We can just hope that reallocated area is not the whole keyslot and LUKS AF helps. Can we trust that this happens on all drives? I guess no. We can use some "secure erase" functions... which can brick the whole drive. And analyzing directly magnetic media (hidden tracks etc) is not easy, but possible. Also there are often also management interfaces which allows access some internal drive parameters without really opening the drive... (Nice talk here https://events.ccc.de/congress/2010/Fahrplan/events/4231.en.html ) 2) Cheap USB flash disk Flash disk uses just different (slower) chips than SSDs but in principle it has the same problems. But USB disks are cheap, thus no powerful processors which run garbage collector in the background (it cannot run some long-time processes - it is hotplug device). Often you can open the device and see some standard controller chip there, there are tools to reprogram parameters of these controllers. (Anyone bought 32GB pendrive on eBay which had only 2GB chip and just faked device size?) Also TRIM/discard and secure discard is usually not supported here. Rewriting LUKS keyslot many times definitely makes no sense here. So for non-rotational device it will just try to wipe it once with random data. (Non rotational device attribute is set by kernel driver per device.) 3) SSDs Almost all SSDs contain powerful processor which run quite complex sw and manages the whole disk, including many features (internal encryption etc). You can hardly say what happens after IO is submitted. It can return that discards is done but in reality it is just queued and will be run later. It can run garbage-collection process and re-arrange internal data layout through idle time. The SSDs firmware are buggy, a lot of drives have still stability problems and performance problems after longer period of use. It is new technology though and it is getting better. For now LUKS keyslot deletion is the same as 2) but there is "secure discard" in Linux supported already which should guarantee that data (and all its copies inside the drive) is wiped (zeroed). Next release of cryptsetup will try to run this erase on non-rotatinal disks for keyslots. (But most of drives do not support it yet anyway.) But even (non secure) discard of keyslot area (after data rewrite try) can have some value - at least it increases chance drive will really wipe it because it now knows the area is not used anymore. (Discard is write operation which instead of writing data says "this area is unused now".) Also the situation is complicated if image is not disk, but file in filesystem or there are more device layers (sw RAID, thin provisioning). For disk image, we can try to use "punch hole" mechanism. But there is no perfect solution. m. It is trivial to detect e.g. LUKS keyslot update according to data access pattern ("copy last write IO if following write is 4k write and data starts with LUKS in ascii") And hacking hw firmware is not so sci-fi as it appears to be sometimes... So to add more paranoia, targeted attack can be really fun here :) _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
