On 12.12.2013 00:22, Sven Eschenberg wrote: > Well usually those SSDs don't use any ecryption key, as long as you don't > use a HDD password (supposedly). Of course they could possible create a > random key and then write 'zeros' during secure erase, which would > incidently result in random content. As the Secure Erase on the SSD i tested only takes seconds, i would assume they (optionaly) reset the key and mark all sectors for reuse in the wear-leveling-table. And then erase the cells either in the background or the next time they are used. IOW the data is not really erase immediatly, only inaccessible by normal read commands. > But judging from experience, it would be quite foolish to assume > manufactures do anything properly or the way you'd expect it ;-). Excactly. There is no real way of verifying what actually happens and if it done in a way that really is secure. The "content"-key can be something like MD5(serial_no + generation_no). Which looks random in each iteration, but would be easily cracked by the manufacturer. > Reagards > > -Sven > > On Wed, December 11, 2013 21:55, Matthias Schniedermeyer wrote: > > On 11.12.2013 20:16, Heinz Diehl wrote: > >> On 11.12.2013, tada wrote: > >> > >> > I was wondering if it is possible to add something like shred or wipe > >> > functionality for Luks devices, call it luksWipe, to safely delete the > >> > luks header > >> > >> You can do that easily by running dd against the first MB's of the > >> respective partition.. > >> > >> dd if=/dev/zero of=/dev/sdaX > > > > That heavily depends on who is the "bad guy" and what storage technology > > is used. > > > > For a non-hybrid HDD a single pass is suppossed to be enough to > > permanently overwrite anything there was before, no recourse whatsoever. > > (Or only the millions of dollar range, a.k.a. "State sponsored enemys") > > > > Non-rotating-platters-of-rust, namely NAND-Flash, are much trickier. If > > you only need to defend against an attacker investing a handfull of > > dollars (a.k.a, let's connect the thing and see what we get with > > standard "get me block X"-commands) a single overwrite/TRIM/Secure Erase > > is enough. > > > > But with just slightly more money (a.k.a., let's desolder the chips and > > see what's the raw contents) it's gets tricky pretty fast. Like you have > > to overwrite the (whole(?!)) contents with random data several times and > > you would still not have a 100% guranteed that the original content is > > really overwritten and not sitting somewhere as "spare" waiting to be > > reused. > > > > Altough at least some current SSD (don't know which ones) are supposed > > to be secure if you use Secure Erase. Thoses SSDs always encrypt the > > content as a way to guaranteed randomness of the data, which is supposed > > to be better for the flash-cells. So when you need a "scrambler" anyway, > > you just use AES256 and also have something you can advertise, 2 flies 1 > > stone. So when you secure erase such a SSD it (supposedly) discards the > > previous encryption key and generates a new one. If that is implemented > > correctly (which you or i can't really proven one way or the other) it > > would be safe. A single Secure Erase (overwriting not necessary) > > effectivly would make the problem "you need to brute force an AES256 > > key" to even get to the RAW content. > > > > > > > > -- > > > > Matthias > > _______________________________________________ > > dm-crypt mailing list > > dm-crypt@xxxxxxxx > > http://www.saout.de/mailman/listinfo/dm-crypt > > > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Matthias _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
