[OpenAFS-devel] Re: openafs - proposed cache security improvement

[Marcus Watts]

> > In this case, spoofed servers.  Regular kerberos works because
> > it's not protecting a shared resource.  In this case, there's
> > a shared resource involved, so there needs to be something extra.
> > I hope you have your kerberos servers & file servers straight
> > in your head.
> 
> I have that straight I didnt have your proposal straight, because I
> was trying to twist it so it could with clients detached from the network
> at midnight which is always a fuzzy time. :) I am also very loosely using
> terminology which is confusing especially to programmers. =)
> 
> I was just kind of wondering is if you could use the shared key, to
> encrypt a file which stores a "master key", that could be used to "verify"
> credentials locally for the local user, which would probably be encrypted
> with a combination of the master key and the shared key. IF they have been
> previously authenicated which they have to do in order to create a "cache"
> of their actual files they wish to take with them. Their "cache"  could be
> accessed using a combination of the host shared key, and their password
> which would decrypt their "filesystem" (more like a loopback mounted
> filesystem.). Upon reconnection to the network they would have to
> authenicate once using the fake stored creds to verify their
> creds were actually legit, and once using their real creds to the actual
> server to get a regular connection, and to sync their "cache" with the
> fileservers.
> 
> I was also thinking that you could hack kaserver to store client keys,
> and transport encryption keys. It could store the client public user key
> to match it with the host key and an encryption key. (and of course put a
> TTL on those keys so they can be cleaned up periodically, and for
> security.) Which does require another server, but kaserver would
> just need to be modified. (well okay, it probably needs to be completely
> overhauled, but not for a prototype.)
> 
> Thus I have offered more confusion. :)

Ok.  For the encrypted cache -

In your case -- the thing to follow is the chain of whatever you do working
backwards from the encrypted data & key, to whatever resources you have on
the machine sitting there "cold".  If you can go from the "cold" state to
the unencrypted data entirely offline without entering any secrets, then
the machine possesses the entire state required to decrypt the data,
and somebody hoping to break in and steal contents need merely run that
path to recover the data.  If the user has to supply a password, then
you've added a key with about 40 bits of strength, depending on the
user's memory -- this is likely to be easy to brute-force.  Passwords
are generally increasingly problemmatical as computing speeds are
rising much more rapidly than biological evolution.  If your attacker
can gain physical possession of your machine, he can probably also do
something more sneaky like copy the encrypted data, install a key
sniffer and return it to you, in which case he doesn't have to guess
the key at all.

You mentioned kaserver.  kaserver is des-only today.
It would require serious modification in order to do kerberos 5
and to remove des, and so far at least, nobody's expressed interest
in doing that.  Storing things in kaserver or any remote server creates
its own problems, especially potentially large amounts of relatively
volatile data.  I'm very interested in avoiding central administrative
overhead, both human & machine.  The only reason a central machine
might need to track client public keys is if it were important to
vouch for the identity of the owner of those keys.  If that's not
important (and I claim this is so is both for anonymous file access, and
for file access that will also be authenticated via kerberos), then
there's no reason for any central registry of client public keys.
The only time the client need provide its public key is when
it actually intends to use it to establish a secure data path to
some server -- in my proposal that would be at startup time to
acquire a secure anonymous token.  That also conveniently means the
client doesn't even need to bother storing its public/private key;
it can just generate a new one each startup if that's easier.

In your case -- I think you might be proposing to encrypt the
cache using a key stored in kaserver.  This is a slight elaboration
of the local password scenario -- now the attacker has to trick
kaserver (or whatever) into surrendering possession of the key.
The mechanism here whatever it is is likely to be very specific
to your laptop environment.  An unattended server in a closet should
probably not be waiting for the user to enter a password,
and a shared multi-user machine in a pool of similar such machines
should certainly not be doing so.

If I wanted to secure the cache and I wanted to make it particularly
useless for an attacker, I would generate a symmetric key & keep it in
memory.  I'd encrypt the cache contents under that key.  Upon reboot,
I'd generate a new key and flush the cache.  If I could, I'd ensure the
cache manager's key is in non-swappable memory.  I'm making a tradeoff
here; slower startup time, but considering the security I gain, that's
pretty minor.  Of course, I'll also need to modify the bios settings so
that I can't select "hibernate" and inadvertently swap my key out to
disk.  "suspend" is probably not much better.  A sufficiently
sophisticated attacker might be able to open the case and swap out the
CPU for some sort of plug-compatible memory reading device, and read
the suspended ram image without much trouble.  Come to think of it, the
"panic" routine probably ought to be hooked so that it wipes out the
symmetric key first.

				-Marcus Watts