Re: hardware disk encryption?
From: atom smasher (ngbz_at_fhfcvpvbhf.bet)
Date: 10/16/04
- Previous message: gary: "Re: KRYPTOS - a case for 88 chars"
- In reply to: Paul Rubin: "Re: hardware disk encryption?"
- Next in thread: Juergen Nieveler: "Re: hardware disk encryption?"
- Reply: Carlos Moreno: "Re: hardware disk encryption?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 16 Oct 2004 11:49:05 -0400
Paul Rubin wrote:
>> what i'm really thinking of, implementation wise, is more like a hardware
>> RAID card that requires a passphrase as the computer boots up. a secret
>> passphrase has legal and logistical advantages over a physical token in
>> many situations.
>
> Its disadvantages are worse. You might forget the passphrase. You
> could write it down in the wrong place or tell it to the wrong person.
> Someone can beat it out of you. It's vulnerable to keystroke logging
> if the attacker can get at the software on the computer or if you
> enter the password remotely, etc.
=================
a token can be lost, destroyed or given to the wrong person. it can be
beaten out of you. it can even be pick-pocketed or left in a taxi.
keystroke logging software wouldn't quite apply here because this would
come on before the OS is running; one would have to compromise a point
between the users fingers and keyboard at one end and the BIOS on the other
end (as usual a spy camera could do the job). like i said, doing this
remotely presents a challenge, but it can be done.
i didn't mean to imply that secrets are _better_ than tokens. they both have
risks and as always the threat model must be evaluated for each situation.
in general i trust myself more with a secret than a token.
> It's better to use a tamper
> resistant hardware token; maybe that can get stolen, but at least you
> know it's gone. It can't be revealed or copied easily like a
> passphrase. Of course a combination of a token and a passphrase could
> be even better, depending on the application.
=====================
certainly a secret and a token have different strengths and weaknesses, but
it seems weird that a secret-based hardware system doesn't seem to exist
for encrypting HDs. the one thing that a secret still has to it's advantage
in the US is that it's protected by the fifth amendment. a token OTOH is
subject to being taken by force of law.
this seems to be missing, but it's archived -
http://web.archive.org/web/20030405075612/law.richmond.edu/jolt/v2i1/sergienko.html
since i'm thinking out loud, you're idea of combining a secret and token
gave me another idea: n/m secret sharing...
to decrypt the drive requires:
(lawyer && (CEO || CFO)) || (CEO && CFO)
etc...
- Previous message: gary: "Re: KRYPTOS - a case for 88 chars"
- In reply to: Paul Rubin: "Re: hardware disk encryption?"
- Next in thread: Juergen Nieveler: "Re: hardware disk encryption?"
- Reply: Carlos Moreno: "Re: hardware disk encryption?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
