Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Jul 2017 12:56:10 -0700
From:      Doug Hardie <bc979@lafn.org>
To:        Raimo Niskanen <raimo+freebsd@erix.ericsson.se>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Unusual Question
Message-ID:  <4B439F2B-B175-480C-8EEE-C200AA16A456@mail.sermon-archive.info>
In-Reply-To: <20170714095950.GA72707@erix.ericsson.se>
References:  <888578F8-AD68-4993-823C-152789F3C929@mail.sermon-archive.info> <b5b8a49e-804d-15be-25b7-ff7c29a5ae8a@holgerdanske.com> <20170714095950.GA72707@erix.ericsson.se>

next in thread | previous in thread | raw e-mail | index | archive | help

> On 14 July 2017, at 02:59, Raimo Niskanen =
<raimo+freebsd@erix.ericsson.se> wrote:
>=20
> This thread reminds me of the argument that you should always encrypt =
your
> hard disk.  For a remote site you could have the key on a key =
partition for
> some crypto systems.
>=20
> Then all you have to do is destroy the key, which is much easier.
>=20
> (For an SSD drive to protect against harcore forensics I do not know =
how to
> ensure that the data is gone, though)
>=20
>=20
> On Thu, Jul 13, 2017 at 09:44:30PM -0700, David Christensen wrote:
>> On 07/09/17 02:57, Doug Hardie wrote:
>>> I have a FreeBSD 9.3 remote server that needs to be purged.  I know =
that rm -rf / will remove all the directory entries, but I need to write =
over the drive.  I thought that dd if=3D/dev/zero of=3D/dev/ada0 might =
do the trick, but it gives an not permitted error.  The whole thing can =
crash and burn at the end.  This is an unmanned site so moving drives is =
not viable.
>>=20
>> If the machine has BIOS and the system drive isn't too large, write =
an=20
>> assembly program that fits into the MBR bootstrap code area to wipe =
the=20
>> rest of the drive, assemble the program, write it into the MBR, and =
reboot.
>>=20
>>=20
>> Bonus: the program deletes the MBR when done wiping the rest of the =
drive.

Encryption does not prevent object reuse.  It may delay it a bit =
depending on the strength of the key generation/algorithm used.  =
However, the data can be recovered.  Given enough horse power, or good =
information into the key generation process, the data can be made =
available.  In most cases, it's actually pretty easy.  Overwriting is =
the only method that makes the information non-recoverable (and still =
leaves the media useful).

Years ago in the USAF, we used to use a power sander to remove all the =
oxide from the disk.  It left a bright, shiny aluminum disk that had no =
information on it.  The bits were still there on the oxide particles, =
but the sander blew them all over the place and its highly unlikely that =
anyone could have gathered them all up, let alone put them back into the =
proper order.  One of those disks was made into a going away memento and =
is displayed here.  The other option was a thermite grenade which was =
tested and verified was extremely effective.  Even the platter vanished.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B439F2B-B175-480C-8EEE-C200AA16A456>