"secure" file flag?

[StefanEßer]

On 2003-11-23 10:11 -0800, Wes Peters <wes at softweyr.com> wrote:
> > Encrypting data and secure removal of data are orthogonal and in case
> > you need one, the other propbably won't be a good choice.
> 
> Both are completely adequate to protect the data on the disk from 
> disclosure.

Yes, if effective. Encryption protects as long as the keys are 
unknown to the attacker, secure removal protects as long as the
data is overwritten before the attacker tries to get access.

I'm sure you know that ...

> > fsck could identify incompletely erased (in the sense of multipass
> > overwrite with specific patterns) blocks, if that state was marked in
> > the inode.
> 
> But if someone is attempting to recover your deleted data, they're not 
> going to run tools that would potentially eliminate that data from the 
> disk.  I'm designing to the idea of a disk that has been physically taken 
> to a data recovery lab, because the intermediate steps don't interest me.  
> But you see that:

Thanks! I'm getting more convinced that there might a chance to
communicate, now ;-)

> > This is not meant as protection in case power is removed and the disk
> > is analyzed off-line since most probably no fsck will ever be run over
> > the filesystem again.
> 
> The data needs to be overwritten in a timely manner as well.  Leaving the 
> disk in a partly erased state is the same as leaving it unerased.  If you 
> don't want the processing delay needed to do the full erasure you 
> obviously don't really need full erasure.

Yes. That's why encryption can be required. It protects data from
the instant the clear-text has vanished (from RAM or some media).
Secure deletion can't provide that!

But there may still be situations, where you want to securely erase
data from a medium. Either because that medium contained sensitive 
plain text or because it contained key data, for example (which is
just another kind of sensitive plain text, in a way ;-)

In that case, a small window of wulnerability may be tolerable (at
least in a commercial environment).

Encryption promises to keep existing data secret, and that promise
may be broken. But in case you still need that data, you don't have 
much choice. Deleting it will not be an option.

Secure erase gets rid of that data, and you don't have to worry that
anybody may get hold of some kind of access key, once it's gone (which
may take some time and effort to achieve, and that's what started this
thread).

Again: Nothing new to you ...

> > It is meant to protect against a power failure (or reboot) with data
> > not being erased according to the specification, which might survive
> > for a long time after next start (not by an attacker but in normal
> > service). This is extra paranoia (compare to a crash while "obliterate"
> > is overwriting blocks, which will not be restarted after a crash ...)
> >
> > It seems that you are opposed to having "secure erase" support in the
> > kernel, and in fact, I'm not sure it is that useful, myself.
> 
> No, at one time I had it on my todo list, but came to a more full 
> understanding of the expense and abadoned it for that reason.  I may 
> someday do it in the simplest form just to prove it workable to myself, 
> but I doubt that is a solution of general interest to FreeBSD.

Ok. I've also thought some about this, and I think that different media
might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs. 
Flash media). High density disks (ATA more than SCSI, actually) seem 
to make it much harder to recover remains of overwritten data, and it
may in fact be acceptable to perform just a few passes with random 
data (as suggested by Peter Gutmann, 7 years ago, when areal densities 
were one to two orders of magnitude lower than today ...)

> > But in case it is considered useful and implemented (I'd try it myself,
> > if I was interested in using this feature), then we should discuss the
> > techical (and security) aspects of several designs and that's what I'm
> > trying to do.
> 
> There is some merit in providing a mechanism that is 90% as secure at 10% 
> the computational cost.  I basic infrastructure that provides a "secure 
> removal" flag at the file and/or filesystem layer and a choice of 
> patterns would be a nice solution.  Those who just want to make sure the 
> contents of an email aren't inadvertantly disclosed to another user could 
> specify a simple pattern like overwrite with zeros once, those who want 
> to keep the FBI at bay could use the whole 37 passes and spend days 
> deleting files.  Maybe I'll look into this again after all.  The former 
> variant seems like it might even be useful for a mail server or similar 
> application.

The ability to specify different patterns seems useful. I'd consider a
window of vulnerability of 10 seconds to one minute acceptable, and I
guess this should be possible to acchive, even for nontrivial amounts
of data that are to be deleted (40 passes at 1MB/s effective (including
seeks) would impose a limit of 25KB/s per disk, while 8 passes at 4MB/s
effective would result in 0.5MB/s, both cases assuming that small files 
taht are spread over a file system are to be erased, maximum rate could
obviously be higher than 5MB/s for modern disks if 8 passes are considered
sufficient). I have not seen any estimate of the number of passes required
for current time PRML disks in the 40GB per surface class ...

> Have you seen any literature on secure overwrite patterns for flash?  That 
> would be an interesting option to provide.  If nothing else, I'd like to 
> hack something like that into obliterate.

No, not really. I think the points made by Gutmann relating to RAM are
valid for Flash, too. Flash devices are capable of remapping bad blocks
in hardware, AFAIK, and ISTR that this feature can be used to evenly 
spread writes over all cells. This might lead to some other region of 
memory being overwritten than the one which is holding the data to be 
obliterated.

I'd guess that the effects that made data recovery from RAM possible
are as valid for Flash. And since you can't follow the advice given
for RAM (toggle bits every few seconds), I don't know what you might
do to prevent this.

Increased areal density does not help as much as it does in the case
of magnetic media, I guess, since bits are stored in distinct cells 
(and not on tracks on a surface as in case of magnetic media, where
head postioning accuracy and other mechanical effects play a role).

Regards, STefan