headers
David Kreil | 4 Sep 2004 00:43
Picon
Picon
Favicon

Re: gbde blackening feature - how can on disk keys be "destroyed" thoroughly?


Hi,

>From what I can see so far, they are simply overwritten with zeros - is that 
right? If so, the blackening feature would be much weakend, as once can read 
up to 20 layers of data even under random data (and more under zeros). I would 
be most grateful for comments, or suggestions of where/how one could extend 
the code to do a secure wip of the key areas. Also, I know practically nothing 
of how I could to best get FreeBSD to physically write to disk 
(configurability of hardware cache etc permitting).

With best regards,

David.

> 
> Hello,
> 
> I was wondering whether someone knowledgable about gbde internals could tell 
> me how the keys are being destroyed on request under the "blackening feature". 
> Ideally, I'd like them to be overwritten with random data at least 20 times 
> independently, but I suspect it may well be done in a different way. I'd be 
> grateful for learning how the blackening works (and why!).
> 
> With many thanks for your help in advance,
> 
> David Kreil.
> 

------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 15 comments |
headers
David Kreil | 4 Sep 2004 01:18
Picon
Picon
Favicon

Re: gbde blackening feature - how can on disk keys be "destroyed" thoroughly?


Dear Vijay,

> I guess I took this off the list. It's OT, in my oppinion.

Oh. Anywhere more appropriate to send it to that you could suggest at all? Now 
also trying freebsd-geom - would that have been the better place to send this 
to to start with?

> I don't know much of anything about data recovery. But, if you can recover  
> data under 20 layers of random writes or 20 iterations of 0s, then how  
> *can* you wipe a hard drive? Short, preferably, of setting fire to it :D

Sigh, tricky, yes. Apparently wiping with >20 repeats of random noise does the 
trick (say from /dev/random or arc4random generated). The difficulty with 
modern file systems / operating systems / disk drives is actually getting the 
patterns written to the magnetic media.

I'm writing to the list because both assessing whether there really is a risk 
and how to fix it requires quite a bot of knowledge that I lack, like knowing 
where to look in the gbde code (maybe I misunderstood?), or writing code that 
is disk driver/hardware caching aware and can hence force a flush.

I'd be most grateful for any help or suggestions.

With best regards,

David.

> >
(Continue reading)

Permalink | Reply | 8 comments |
headers
Len Zettel | 4 Sep 2004 01:41
Picon
Favicon

Re: gbde blackening feature - how can on disk keys be "destroyed" thoroughly?

On Friday 03 September 2004 07:18 pm, David Kreil wrote:
> Dear Vijay,
>
> > I guess I took this off the list. It's OT, in my oppinion.
>
> Oh. Anywhere more appropriate to send it to that you could suggest at all?
> Now also trying freebsd-geom - would that have been the better place to
> send this to to start with?
>
> > I don't know much of anything about data recovery. But, if you can
> > recover data under 20 layers of random writes or 20 iterations of 0s,
> > then how *can* you wipe a hard drive? Short, preferably, of setting fire
> > to it :D
>
While i am not an expert in this area, I can not help but wonder---
Who are you worried about recovering the data, under what
circumstances?  My best guess is that recovering anything from
even _one_ data over-write is going to require that the recoverer have
physical posession of the drive and very sophisticated equipment
indeed.  That means they have to be some branch of a govermnment.
If you are going to attract attention of that caliber there are likely a lot
of other easier means of finding out what you are up to.  Otherwise, a
good hot fire ought to be pretty final even for the CIA.
   -LenZ-
> Sigh, tricky, yes. Apparently wiping with >20 repeats of random noise does
> the trick (say from /dev/random or arc4random generated). The difficulty
> with modern file systems / operating systems / disk drives is actually
> getting the patterns written to the magnetic media.
>
> I'm writing to the list because both assessing whether there really is a
(Continue reading)

Permalink | Reply | 4 comments |
headers
Vijay Kaul | 4 Sep 2004 01:55
Picon
Favicon

Re: gbde blackening feature - how can on disk keys be "destroyed" thoroughly?

On Fri, 03 Sep 2004 19:41:18 -0400, Len Zettel <zettel <at> acm.org> wrote:

<snip>

> While i am not an expert in this area, I can not help but wonder---
> Who are you worried about recovering the data, under what
> circumstances?  My best guess is that recovering anything from
> even _one_ data over-write is going to require that the recoverer have
> physical posession of the drive and very sophisticated equipment
> indeed.  That means they have to be some branch of a govermnment.
> If you are going to attract attention of that caliber there are likely a  
> lot
> of other easier means of finding out what you are up to.  Otherwise, a
> good hot fire ought to be pretty final even for the CIA.
>    -LenZ-

I used to work in a lab and a co-worker had be a submarier for the US. He  
said that one of their projects was to figure out how to best destroy CDs  
for the government. Supposedly the CDs were recoverable even after  
cross-shredding. They either decided that melting them over a "heatsink"  
(coffee mug) in a microwave (also makes a nice ash tray) or going at them  
with an acetaline torch was the final solution.
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
David Kreil | 4 Sep 2004 02:36
Picon
Picon
Favicon

Re: gbde blackening feature - how can on-disk keys be "destroyed" thoroughly?


Dear LenZ,

> Who are you worried about recovering the data, under what circumstances?

The value of the blackening feature should be that you can give away the drive 
and your password, say, under pressure by the [court|mafia|whoever], without 
compromising any confidential information on the drive.

> My best guess is that recovering anything from
> even _one_ data over-write is going to require that the recoverer have
> physical posession of the drive and very sophisticated equipment
> indeed.  That means they have to be some branch of a govermnment.

Hmm, I much doubt that. True, you need a clean room and a magnetic force 
microscope. Even standard data recovery firms like www.dataclinic.co.uk, 
however, can recover data under up to 8 overwrites. (NB: No affiliation or 
recommendation there.)

Government agencies can go deeper (20x or possibly more but it gets 
increasingly more difficult).

> If you are going to attract attention of that caliber there are likely a lot
> of other easier means of finding out what you are up to.

Sure, like pointing an antenna at my computer while its running ;-)

I guess my main point is: If there is a blackening feature which is designed 
to give users peace of mind about disclosing their password under pressure, 
and it is known that data can be recovered underneath simple overwrites for a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Poul-Henning Kamp | 4 Sep 2004 10:03
Picon
Favicon

Re: gbde blackening feature - how can on disk keys be "destroyed" thoroughly?

In message <200409032243.i83MhuA02066 <at> puffin.ebi.ac.uk>, David Kreil writes:
>
>Hi,
>
>>From what I can see so far, they are simply overwritten with zeros - is that 
>right? If so, the blackening feature would be much weakend, as once can read 
>up to 20 layers of data even under random data (and more under zeros). I would 
>be most grateful for comments, or suggestions of where/how one could extend 
>the code to do a secure wip of the key areas. Also, I know practically nothing 
>of how I could to best get FreeBSD to physically write to disk 
>(configurability of hardware cache etc permitting).

On a modern disk there is no sequence of writes that will guarantee
you that your data is iretriveable lost.

Even if you rewrite a thousand times, you cannot guard yourself against
the sector being replaced by a bad block spare after the first write.

If your threat-analysis indicates this is a serious threat for you,
you should arrange for simple physical destruction of your disk to
be available.

Most modern disks have one or more holes in the metal only covered
by a metalic sticker.  Pouring sulfuric acid through those openings
is a good start.

--

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk <at> FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
(Continue reading)

Permalink | Reply | 13 comments |
headers
David Kreil | 5 Sep 2004 01:32
Picon
Picon
Favicon

Re: gbde blackening feature - how can on disk keys be "destroyed" thoroughly?


Dear Poul-Henning,

Thank you very much for your comments!

> >From what I can see so far, they are simply overwritten with zeros - is
> >that 
> >right? If so, the blackening feature would be much weakend, as one can read 
> >up to 20 layers of data even under random data (and more under zeros).
> >I would 
> >be most grateful for comments, or suggestions of where/how one could extend 
> >the code to do a secure wipe of the key areas. Also, I know practically
> >nothing 
> >of how I could to best get FreeBSD to physically write to disk 
> >(configurability of hardware cache etc permitting).
> 
> On a modern disk there is no sequence of writes that will guarantee
> you that your data is iretriveable lost.
> Even if you rewrite a thousand times, you cannot guard yourself against
> the sector being replaced by a bad block spare after the first write.

Good point. In the rare chance event that this happens, it would indeed be bad 
news as an attacker would then only have to scan the bad blocks for possible 
copies of the key.

> If your threat-analysis indicates this is a serious threat for you,
> you should arrange for simple physical destruction of your disk to
> be available.
> 
> Most modern disks have one or more holes in the metal only covered
(Continue reading)

Permalink | Reply | 11 comments |
headers
Poul-Henning Kamp | 5 Sep 2004 14:13
Picon
Favicon

Re: gbde blackening feature - how can on disk keys be "destroyed" thoroughly?

In message <200409042332.i84NWxC17377 <at> puffin.ebi.ac.uk>, David Kreil writes:

>> On a modern disk there is no sequence of writes that will guarantee
>> you that your data is iretriveable lost.
>> Even if you rewrite a thousand times, you cannot guard yourself against
>> the sector being replaced by a bad block spare after the first write.
>
>Good point. In the rare chance event that this happens, it would indeed be bad 
>news as an attacker would then only have to scan the bad blocks for possible 
>copies of the key.

He still has no way of recognizing the key though...

>A simple improvement on the present situation would already be if
>the keys were not overwritten with zeros but with random bits. I
>don't know how difficult it would be to attempt to physically write
>random bits multiple times but it would much strengthen the feature
>apart from the rare cases when the sectors of the masterkey have
>been remapped into bad blocks.

Please read the paper, there is a reason why it is zero bits.

>What do you think? Is the required effort disproportional to the
>intended value of the blackening feature?

Blackening adds no significant incremental security imo, on the
other hand it is feasible to implement it, so I've put it on the
todo list.

--

--
(Continue reading)

Permalink | Reply | 9 comments |
headers
David Kreil | 5 Sep 2004 16:26
Picon
Picon
Favicon

Re: gbde blackening feature - how can on disk keys be "destroyed" thoroughly?


Dear Poul-Henning,

> >> On a modern disk there is no sequence of writes that will guarantee
> >> you that your data is iretriveable lost.
> >> Even if you rewrite a thousand times, you cannot guard yourself against
> >> the sector being replaced by a bad block spare after the first write.
> >
> >Good point. In the rare chance event that this happens, it would indeed be
> >bad 
> >news as an attacker would then only have to scan the bad blocks for possible 
> >copies of the key.
> 
> He still has no way of recognizing the key though...

Right, he'd have to try them all.

> >A simple improvement on the present situation would already be if
> >the keys were not overwritten with zeros but with random bits. I
> >don't know how difficult it would be to attempt to physically write
> >random bits multiple times but it would much strengthen the feature
> >apart from the rare cases when the sectors of the masterkey have
> >been remapped into bad blocks.
> 
> Please read the paper, there is a reason why it is zero bits.

Sorry, forgot.

> >What do you think? Is the required effort disproportional to the
> >intended value of the blackening feature?
(Continue reading)

Permalink | Reply | 7 comments |
headers
Alfred Perlstein | 9 Sep 2004 05:06
Picon
Favicon

autofs available for FreeBSD 4, 5 and 6.

Autofs has been integrated into FreeBSD 6.

There is also a standalone tarball that will compile and run on
FreeBSD 5 as well as FreeBSD 4.

The most recent one is available here:

http://people.freebsd.org/~alfred/sources/autofs/

If you want to get an idea on how to use it, see the libautofs.3
manpage.

You can also check out the example driver program under
/usr/share/examples/autofs/driver (under FreeBSD 6) or the driver/
directory (from the tarball).

If you want to use the tarball, just extract it and run
  make depend all install
from the top level directory.

Have fun!  AMD guys, let me know where we go from here!

The only thing I have not implemented is trigger timeouts inside
the autofs.  I'll get to it eventually though.

--

-- 
- Alfred Perlstein
- Research Engineering Development Inc.
- email: bright <at> mu.org cell: 408-480-4684
_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |

Gmane