In that case I would suggest to add an external passphrase-protected key
storage module (because a solid nonbruteforceable passphrase is too long
to rationally remember and to routinely enter, so to deter bruteforce we
have to have the real long key stored in a way that can't be queried too
many times). Then add the key querying and secure boot method directly
into the computer's BIOS (see the Etherboot project which describes the
ways; some of the possibilities involve patching and reflashing the BIOS
image). Then use Linux or other suitable system configured to run from
such end-to-end encrypted disk. The key storage module itself also may
allow having a data destroy button on it.
The BIOS hack may allow an alternate format of the hard drive partition
table, with the record for the encrypted partition omitted and stored in
the configuration EPROM instead. Or perhaps even in the key token. Or
anywhere else. It won't withstand a good scrutiny, as the partition is
still visible as an unused chunk of disk (which is an uneconomical
behavior, and therefore suspicious, at least in forensic context). For
making this more believable, a hack of the firmware of the hard drive
itself would be needed; a 100GB model then could pose as a 30 GB model
until unlocked with a vendor specific command, and pass even direct
interrogation of the disk via the ATA interface, requiring a well-equipped
forensic laboratory to even uncover that the disk is not what it claims it
is.
For security reasons, you may also like to modify this idea a little more
and add a duress partition on the disk on which a believable looking
minimal installation of something runs. With the proliferation of random
laptop checks on the borders, this may give you an easier pass through
than the most sophisticated access denial system by the means of faked
request compliance. You will attract less scrutiny if you will look
uninteresting. A tightly locked up laptop looks interesting.
I am not sure how is disk access handled in virtualization environments.
If it is not transparent, and the OS that runs the virtual machine handles
the disk accesses (and therefore encryption), you can even run Windows by
running them in the virtual machine.
Beware: once you connect the machine to the Net, or to a LAN in general,
all the safety is drastically reduced, because the applications have
access to the unencrypted data. Same applies to offline attack vectors
like eg. trojan horses. The code running on the machine also has to be
easily auditable. Perhaps running from a read-only partition with a known
hash. This is a lot of work to achieve, but a must if your threat model
involves compromise attempts. With a possible refresh from a known-good
system image.
Therefore a well-secured machine may be unsuitable for general use, as it
will make it either way too easy to compromise, or way too cumbersome to
use. If you have need to handle so badly confidential data, I would
consider contemplating using two computers, one for the sensitive data and
one for normal browsing/use. The approach with the duress partition may
allow using the machine in insecure settings (and an attempt to compromise
the encrypted data will not succeed - without the key the data on the
encrypted partition may be damaged, but not compromised).
On Fri, 23 Mar 2007 cont..._at_yahoo.co.uk wrote:
>
> Thanks to you all...but
>
> I actually was looking for a zeroizing,purging,distroying way
> while the HD is still inside the PC !
>
> In my case there is no time to disassemble the PC and
> ...remove the harddisk,
> ...and insert it into a degausser or heavvy shredder/puncher.
>
> Also such heavvy mechanical destroyers are to expensive
> Also...it should work on a laptop while travelling.
>
> Maybe that was not to clear from my initial question.
>
> Anyway...i still say a Solid State Drive (SSD) with a single
> erase-all button will do the job and kill all data in no-time
> on top of that i would use good encryption.
>
> Now the search is for a fairly lowcost unit that does that.
>
>
> Greetings
>
> contranl
>
>
> On 22 mrt, 22:27, d..._at_geer.org wrote:
> > 20 seconds _at_http://www.jpl.com/products/DT/DT-500N.html
> >
> > 18 seconds _at_http://www.jpl.com/products/DT/DT-2000.html
> >
> > 10 seconds _at_http://www.jpl.com/products/DT/DT-1500.html
> >
> > 7 seconds _at_http://www.jpl.com/products/DT/DT-1000.html
> >
> > --dan
>
>
> >
Received on Sat Mar 02 2024 - 00:57:18 CST