On Fri, 2002-03-08 at 18:35, Jason A. Pattie wrote:
> Berend De Schouwer wrote:
>
> >>>*** A possible solution may be to create a VPN(IPSEC) betweeen the client
> >>>and the server. Allow the home directory to be mounted only through the
> >>>VPN.
> >>>
> >>A very good solution and one that is not too hefty to implement.
> >> However, how to you store "securely" the secret keys for each
> >>workstation? The only way that I can think of a solution for this is to
> >>have local storage in some form on the thin-client workstation.
> >>
> >
> >The etherboot bootprom?
> >
> Hmm. Interesting. I wasn't thinking of that as a solution (didn't know
> you might be able to do it that way). I was thinking primarily of
> Compact Flash or the like as local storage.
Don't you only need a little bit for the key? 128bit encryption is slow
enough for a file system.
>
> > Its not perfect (you can read it back, if you
> >can steal the chip or card.)
> >
> This is a given. If you steal someones hard drive, then you will have
> access to their data (unless they have encrypted the filesystem and not
> stored the passphrase on it anywhere).
>
> > The mkinitrd already allows ip=rom or
> >somesuch, so maybe the TFTP kernel can grab a key that way.
Sorry, I should have said mknbi-linux.
> >
> I would see this as being even more insecure than local storage.
> Someone can simply sniff the traffic for the ENCRYPTION key being sent
> to the client IN THE CLEAR. Right?
No. That is if its DHCP.
>
> Or am I missing something?
I was thinking along the lines of:
1. bootprom contains client-to-server encryption key and
server-to-client decryption key. Its burned in. [*]
2. bootprom does its normal "use DHCP to get IP"
3. bootprom examines DHCP response, and gets an IP and a TFTP path.
4. bootprom gets kernel and initrd via TFTP (plain -- no secrets).
5. client kernel asks bootprom for IP number.
(existing ip=rom option to mknbi-linux enables this, right?)
6. client kernel asks bootprom for keys.
7. client kernel starts encrypting network traffic.
The keys are never sent over the network. They are on the server's
harddisk, and in the clients bootprom only. I have no idea if this is
good enough for established VPN standards. Maybe you could simply run
all NFS packets through 3DES. I simply don't know.
Keys are small enough to put on the bootprom. The bootprom can be
instructed to put them in a specific spot in RAM before it executes the
nbi image it gets from TFTP. It shouldn't be too hard.
[*] server-to-client and client-to-server could use the same, or
different encryption, I suppose.
[*] You could do things like encrypt DHCP or TFTP traffic. But why?
[*] Since you can expect what the first few NFS packets look like (they
will be the same), you could do some data analysis on that traffic
to attack the keys, I think.
>
> --
> Jason A. Pattie
> [EMAIL PROTECTED]
>
--
Berend De Schouwer
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.openprojects.net
