From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vZyJUm_pZMi for ; Thu, 12 Dec 2013 01:30:02 +0100 (CET) Received: from awesome.dsw2k3.info (unknown [IPv6:2a01:198:661:1f::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Thu, 12 Dec 2013 01:30:02 +0100 (CET) Date: Thu, 12 Dec 2013 01:29:54 +0100 From: Matthias Schniedermeyer Message-ID: <20131212002954.GA2263@citd.de> References: <52A8B602.4030303@riseup.net> <20131211191607.GA9082@fancy-poultry.org> <20131211205516.GA21128@citd.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] Possibility for safe Luks partition delete functionality List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sven Eschenberg Cc: dm-crypt@saout.de 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@saout.de > > http://www.saout.de/mailman/listinfo/dm-crypt > > > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt -- Matthias