Nice. I agree with most of what you say. Some remarks. For magnetic media, reallocating so many sectors are to contain a full keyslot is rather unlikely, should show up in the SMART log and should only happen if the sectors are actually defect in some way. That would protect the old data in there due to the anti-forensic stripings all-or-nothing mechanism. Still, a malicious disk can keep you headers, no doubt. It may even be able to attack your OS and send all your data out over the internet. Malicious NIC firmware seems to be already able to do that so why not disk firmware. (Side note: Targetted attacks that can compromise hardware before it is installed can basically not be fought at this time. You have to trust the hardware. But other types of targetted attacks are still often pathetically easy, so hardware-based attacks may be mostly in the future.) SSD and USB flash are fundamentally different here as no need to keep geometry for performance and very serious need for wear-leveling. That is not to say LUKS key-slot changes are always insecure on SSD/Flash, just that the design of the LUKS header makes certain assumptions and they are good ones on HDD and not so good ones on SSD/Flash. Using "secure discard" for non-rotational is certainly a good idea. If possible, add a way to test for the presence of secure discard via cryptsetup. I also hope somebody finds the time to de-solder some Flash chips from SSDs in the future and check whether secure discard actually works. For the moment this seems to be the best reference available: http://cseweb.ucsd.edu/users/swanson/papers/Fast2011SecErase.pdf Does only talk about secure erase (not discard) and conventional overwriting though. Key quote: "none of the existing hard drive-oriented techniques for individual file sanitization are effective on SSDs". But still, while it is not optimal, we need to warn users that at this time LUKS may be less secure on SSD/Flash than on magnetic disk, but clearly specify how and what attacks may become possible and which security properties are unaffected. For most users LUKS on SSD/Flash should still be fine. I think this will need some time to get right, i.e. discussion is good! ;-) Arno On Fri, Aug 24, 2012 at 05:06:48PM +0200, Milan Broz wrote: > > 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 > -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
