Re: Possibility for safe Luks partition delete functionality

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

But judging from experience, it would be quite foolish to assume
manufactures do anything properly or the way you'd expect it ;-).

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




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux