[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH] Enable partman-crypto to work with keys on removable devices



On Mon, May 19, 2008 11:16, Max Vozeler wrote:
> On Tue, May 13, 2008 at 08:02:28PM +0200, David Härdeman wrote:
>> I'm also planning to use some of the infrastructure of the patch to add
>> support for two-factor keys (ask a passphrase, hash it, get a keyfile
>> from usb stick, xor the two together, use that as the key) and
>> smartcards (I've already ordered the hardware, dunno when I'll get it).
...
> If we plan to add second factors do you reckon we should
> still support non-wrapped plain keys?
>
> I worry a bit that the security implications of plain keys
> will be difficult to convey to users inside the partman UI,
> and so they might get a wrong sense of security.
...
> Will the user instinctly grasp the implications correctly?
>
> If not, perhaps we should
>
>   a) not offer plain keys at all?
>
>   b) offer plain keys only to be stored on encrypted devices?
>
>   c) name it "Plain key on removable device
>      (DONOTUSEUNLESSYOUKNOWWHATYOUAREDOING!)" or something? ;-)

Alternative b) is the same as keydev with password if we're talking about
encrypted root (so it's actually the same as alternative a)).

I actually see this as more of a documentation issue. I don't see that
much of a problem with unencrypted keys on external storage.

Personally I have one laptop where I use a key on a usb stick together
with a password to boot (support for that is not in a state where I want
to commit it to cryptsetup just yet) and one where I use a plain keyfile
on a usb stick.

In order to judge the merits of both approaches, the different threat
scenarios must be understood.

  Encrypted keyfile on a usb stick:

The key can be retrieved from kernel memory by an attacker who has managed
to get root access to your computer while it is running (dmsetup table
--showkeys).

An attacker who has root access or $your-user-id access to your computer
while running can get at your personal data in /home, which on 98% of all
laptops (for details on how I came up with that statistic, see
http://www.dilbert.com/fast/2008-05-08/) is what is really valuable to
you.

If you lose your usb stick, the encryption should keep the key safe
against brute-force attacks, but I would still recommend any user that
lost his key to do a new installation using a new key just to be
sure...the encryption buys the user time to do so.

  Non-encrypted keyfile on a usb stick:

This opens up (as far as I've been able to come up with) two additional
attack scenarios:

First, if the usb key is left attached to the computer after boot
(probably not that uncommon), an attacker who manages to gain access to
$your-user-id can also get the key to the harddisk (since you probably
have privileges to mount the usb key). This can be mitigated by either
removing the key, not allowing regular users to mount the key or using an
fs which allows for proper permissions and setting the keyfile to be root
readable only. In any case, if an attacker has access to $your-user-id,
they have access to your /home and (using the above statistics), most
users would be fubar:ed already.

Second, if you lose the key and the laptop together, an attacker has the
opportunity to boot the computer. I consider this to be the major
disadvantage. This can be solved by separating computer and usb key e.g.
while traveling (usb key goes in pocket of your pants, computer is in a
laptop bag). Someone who holds you up at gun point to get both key and
computer would have to know there was a key and could probably use the
threat of violence to get key, computer and passphrase from you if they do
know and you use the key and keydev approach.

An added benefit of unencrypted keys is that it allows for encrypted
partitions on e.g. servers and other headless devices. Insert key, boot
server, remove key.

So I think unencrypted keys is mostly a case of user education and not
something we should disable. partman-auto-crypto is for the user who does
not want to understand the details :)

-- 
David Härdeman


Reply to: