[OpenAFS] my afs wish list

[Jon Bendtsen]

Ryan Underwood wrote:
> On Mon, Apr 28, 2003 at 10:53:09PM -0400, Derrick J Brashear wrote:
> 
>>-Multiple encryption types. For real, not just jury-rigged into rxkad.
> 
> 
> What about strong encryption on the data streams?  I would think
> something like blowfish would be fast enough for real security without
> compromising performance.
> 
> Of course, I haven't been following whatever work is going on in that
> area, but AFAIK we are just xoring when fs setcrypt is on. (?)

Why just encrypt the data streams? Actualy i think that encrypting the
datastreams might not be the best option, since it would introduce extra
encryption/decryption, costing cputime. My suggestion is to store the
files (encrypted) on the server, but to the server, they are just 
another file with a strange name. (sort of like cryptfs does). Then you
would let the klient do the en/de-crypting. The client probably has alot
more cpu power than the server, especialy if the server has to serve 
23089233489723734 clients (or there about).

I encrypt my files on the server, such that if someone steals the server
or i have to replace a dead or just too small disk, i dont have to worry
about people getting my data because i know they are encrypted. Now, of
course this doesnt protect me against people snooping on the network, so
i want the network transfers to be encrypted as well. Naturally if 
people can steal the server, it will be alot easier to steal a client, 
which has the cache... So that would be encrypted as well...
But this opens up for alot of waisted encryption work, possibly 6 
levels, but it could be just 4:

	1: server disk -> diskdecrypt -> openafs_server
	2: openafs_server -> AFScrypt -> tcp/ip
(    3: tcp/ip -> VPNencrypt -> ethernet    )
(    4: ethernet -> VPNdecrypt -> client tcp/ip    )
	5: client tcp/ip -> AFS decrypt -> openafs_client
	6: openafs_client -> diskencrypt -> local_cache

So, how to we trim this down? Well, my suggestion is to make the
encryption so some levels can be thrown away, but still offer
protection against: stealing the server, stealing the client, and 
snooping on the network between the client and the server.


The idea is that the server just serves the files. The client handles
all the encryption and all the decryption. The client decrypts stuff
going into ram, and encrypts stuff going to localcache, or the server.
This also has the advantage that you distribute the processor load to 
the client because the server just stores files.

Naturally we dont want all the data to be compromised if one client is 
compromised, or even if the server is compromised. So we might want one
key for each user, but no, thats not good enough, because then either 
you cant share your encrypted files with other users, or, they would 
have to have your key, which would not be so good. We cant have multiple 
keys for each files, because that would use alot of space. So we will 
have to do something else.


My idea is to encrypt the files in a directory with the same key.
Like AFS has one ACL for the hole dir, lets have one key for the
hole dir. When the user authenticates him-/herself to the AFS server,
the AFS server also responds with a key to decrypt the files. There
is a different key for each subdir, but thats all handled automatic.
So, when the user asks for a file, the server sends the encrypted file
to the client, which decrypts it in memory and parses it on to the
users programs. When the program saves, the client encrypts the file
and sends it back to the server.

So, you change the ACL for a subdir... Just create a new key, encrypt
all the files in that subdir. The client does this.

The user/client would have some sort of keyring which resides in the
AFS system, and is given to the user when authenticated. It is sort of
pgp. You encrypt your keyring so only you have access, and then you are 
given the key to a file (directory) if the ACL says you can have access 
to that file. If your access is removed, you still have the old key, but 
the files are just reencrypted with a new key. (problem: what if someone 
else is editing a file, and the ACL and thus the key is changed? it 
would have to be handled as well). (problem: we might use alot of keys, 
and can we really reuse a key? the encryption would need to have ALOT of 
possible keys, i dont think 2^32 posibilities are enough).


Also my suggestion would have the advantage that you dont have to
encrypt all your files. Only the sensitive ones. This gives fast
access to non-sensitive files, and secure access to sensitive files.
And further more, we dont need to change the server side, just the 
client. I guess this will make it easier and faster to develop the 
encryption. Besides, it is my impression that people would rather trust 
a new client, than a new server AND client.




JonB
ps: i accidentialy emailed this only to Helmut Springer almost 3 weeks 
ago. Cant we have a reply-to: openafs-info@openafs.org added ? so a
reply is all there is needed.