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

Subject: Re: Additional security for laptops...
From: Damion Wilson <dwilson,AT,ibl,DOT,bm>
Date: Fri, 17 Jan 2003 22:46:52 +0100
In-reply-to: <CJELIEBEFNCJAOMOOMNNIEBOCKAA.les@futuresource.com>

I actually have done just that. It holds the whole cipe config in its nvram 
and will only provide it when given the correct password.

DKW

On Friday 17 January 2003 05:20 pm, you wrote:
> Hi.
>
> If the only data encrypted is the key itself (a truley random sequence
> of bits), then there is no way to verify that the key has been cracked,
> other than to try it out by connecting to the cipe server.  This is
> something we could potentially defend against on the cipe server end
> (max tries, or time-lags).  If we encrypt the whole config file, then
> hackers would easily know when they had found the right password,
> because the keywords (ME, PEER, etc) show up in the decrypted file.
>
> We could encrypt the key in the config file directly (in the KEY field),
> and have ciped ask for the password when it starts (if given the
> apropriate flag).  Then, ciped would decrypt the key in memory, and it
> would never apear on the disk in visible form.
>
> An external javaring also sounds good to me, but I'd like to use it in
> conjunction with a user provided password.
>
> -- Bill Cox
>
> Damion Wilson wrote:
> >They can, and it's not a bad idea. The javaring approach uses an embedded
> >microprocessor (running Java) which can run any code you like.
> >
> >However, whenever you use a password, it requires a stored representation
> > of the password to compare against such as the crypt()'ed passwd field of
> > the /etc/passwd file. This representation provides an opportunity to
> > 'crack' the mechanism if it can be obtained. One way hash functions help
> > a lot but physically preventing keys from being obtained, hashed or not,
> > is a better approach. Encrypting the key using the password directly
> > requires that the password be a large and unique enough value to prevent
> > easy cracking. Using the password as an accessor to a larger decryption
> > key (PGP approach) still leaves the problem  that the means to decrypt
> > and the decryption key are in the same place. It's almost like hiding the
> > house keys in the rain gutter when you go out. It's much better to take
> > the keys with you (randomising their location with respect to the house).
> >
> >In short, removing the key from the computer gives you the best
> > opportunity to 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.
> >
> >Bruce Schneier's writings explain these things far better than I ever
> > could.
> >
> >DKW
> >
> >On Friday 17 January 2003 02:41 pm, you wrote:
> >>>From: Damion Wilson
> >>>
> >>>Instead of all that, why not put the key on a USB solid state disk ($20)
> >>>or use something like a JavaRing ? Why not put the whole CIPE config on
> >>>the thing ? Run ciped-cb from inittab and it'll keep dying until the key
> >>>becomes accessible.
> >>
> >>Do those have a mechanism for getting a password from the
> >>user?  Someone stealing the laptop might get it with the
> >>device connected.
> >>
> >>---
> >>  Les Mikesell
> >>   les,AT,futuresource,DOT,com
> >
> >--
> >Message sent by the cipe-l,AT,inka,DOT,de mailing list.
> >Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe cipe-l" in body
> >Other commands available with "help" in body to the same address.
> >CIPE info and list archive:
> > <URL:http://sites.inka.de/~bigred/devel/cipe.html>





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