linux-kernel - Re: [PATCH] Support for secure erase functionality

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 14 Sep 2017 14:51:52 +0200
From:   Philipp <philipp.guendisch@....de>
To:     Damien Le Moal <damien.lemoal@....com>
Cc:     linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-block@...r.kernel.org, axboe@...nel.dk,
        viro@...iv.linux.org.uk, bart.vanassche@...disk.com,
        martin.petersen@...cle.com, hare@...e.de, osandov@...com,
        dan.j.williams@...el.com, ming.lei@...hat.com,
        linux-kernel@...cs.fau.de, Mate Horvath <horvatmate@...il.com>
Subject: Re: [PATCH] Support for secure erase functionality

Dear Damien,

Thank you for your feedback. 

> On 14. Sep 2017, at 10:46, Damien Le Moal <damien.lemoal@....com> wrote:

[…]

> Writing once to a sector stored on spinning rust will *not* fully erase
> the previous data. Part of the signal used for storing that data will
> remain on the track (because the disk head is never perfectly aligned on
> the track). With some signal processing work, the old data can be retrieved.
> 
> You will need a *lot* of normal writes to make sure nothing remains of
> the old data signal. Granted, even a single write will make it hard to
> get to the old data, but it is possible nevertheless. Hence the standard
> defined SANITIZE with cryptographic erase option to ensure that the old
> data is really dead.

We constructed our patch based on a paper called 
“Overwriting Hard Drive Data: The Great Wiping Controversy” which stated that a single overwrite
of the data is sufficient.
Nevertheless this should not be a solution to replace encryption but to improve data security when
better techniques are not viable (e.g. travelling between countries while importing or exporting
encrypted data may be prohibited without a license).

> I think that a similar problem also exist for SSDs, and it is even worse
> there since writing twice to the same logical sector does not even go to
> the same physical sector. The old data is not even overwritten.

We know about the problems regarding the data placement on SSDs, but there is very little we can
do with code against the hardware controller of specific devices.
On SSDs, you would probably want to use full disk encryption, because it should be no problem,
when encrypted blocks are left on the drive.

However in cases where encryption is too slow or not possible, this could improve data confidentiality.

Best regards,
Philipp