<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: Additional security for laptops...
From: Bill Cox <bill,AT,viasic,DOT,com>
Date: Sat, 18 Jan 2003 14:53:05 +0100
In-reply-to: <CJELIEBEFNCJAOMOOMNNIEBOCKAA.les@futuresource.com>


I like several of the ideas mentioned so far.  I'm going to some of them 
a try.  Here's the summary of what I'm considering:

- The cipe key is still in /etc/cipe/config.cipcb<#>, but it's weakly 
- Mods to ciped decrypt the key using a user provided password.
- Our source code lives on a CFS drive (Cryptographic File System) 
encrypted with Blowfish (for speed)
- The long CFS key lives on the cipe server, and is accessed with the 
same user-provided key used to decrypt the cipe key

The javaring stuff sounds good, but extra hardware is involved, so I 
think I'll put that off for now.

The mods to ciped to decrypt the password are to help protect the actual 
key.  By modifying ciped, the actual static key is never available 
outside of ciped.  Simple xor-ing of the user's password over the static 
key field in the options file is good enough, so long as the actual 
static key is truely random.  This feature would also usefull with 
pkcipe, but since I configure our laptops at the office, the need for 
public key encryption is lessened.

-- Bill Cox

Eric Hopper wrote:

>On Fri, 2003-01-17 at 14:07, Damion Wilson wrote: 
>>In short, removing the key from the computer gives you the best opportunity 
>>prevent both the facilitator (computer) and the accessor (static key) from 
>>being obtained at the same time and, IMHO, that's stronger security than 
>>reliance on passwords.
>It depends on your purpose.  If the information on your laptop is
>intrinsically valuable, making sure that an attacker cannot run a
>password guessing attack in the privacy of their own laboratory is good.
>If the information is CIPE keys, or some such, then it doesn't matter so
>much.  The real goal of encrypting CIPE keys using a password is to
>prevent an attacker from gaining privileged access to your network.
>Presumably, if the person on the road's laptop is stolen, they will
>report it fairly quickly.  If they're also kidnapped (or worse), you
>will lose contact with them, and presume the laptop is stolen.  Then,
>you can arrange it so none of the information on the laptop will give
>privileged access to your network.  This means that the laptop's keys
>only have to resist attack for a few days.  A decent password is fine
>for this.
>If the information on the laptop is intrinsically valuable, then you
>have a somewhat different situation.  Then, you need a strong secret
>protecting that information, one that cannot be guessed until the
>information is no longer valuable.
>One way of accomplishing this that doesn't require any special device of
>any kind is to arrange it so that the strong secret can only be gotten
>by first gaining privileged access to your network.  You store the key
>protecting the filesystem with the sensitive data on a server on your
>network that can only be gotten to through the VPN.  You can even make
>this server require the another password before it will give up the
>strong secret.  This requires no special device, and is of comparable
>Another way is to have an external device that normally is not left
>connected to the computer to have the strong secret on it.  This could
>be enforced by having the computer refuse to respond to user input as
>long as the device was connected.  Or, you could have the device spit
>out the strong secret as a long hex string the person had to type on the
>In order for the external device to work well, it should internally
>protect the strong secret with a weak secret, like a password.  It
>should be highly resistant to physical attack (tampering).  And, it
>should scramble the strong secret after a certain largish number (say
>30) wrong guesses of the weak secret.
>Have fun (if at all possible),

<< | Thread Index | >> ]    [ << | Date Index | >> ]