begin quoting Andrew Lentvorski as of Thu, Aug 28, 2008 at 08:37:43PM -0700: > David Brown wrote: [snip] > >It's proprietary, but now documented. There is a 64-bit secret within > >each key. The secret must be given to the host software so it can > >verify the key sequence. > > And that's the part I don't like. > > Basically, if you manage to compromise the server, you can fake the > keyfob since the secret is now compromised.
Presumably it's the server that you're trying to protect, so once they've compromised the server, the keyfobs serve no purpose. I see your discomfort, however, as you can't fix the server without a tedious and painful process of rekeying all of the fobs. (Plus, there are now "new" attacks on hashing functions, so the "hash a secret" technique might not last for too much longer. Whee!) > Is there a way to do like public key crypto and have a public key on the > server and a private key in the fob that can both generate either a > matching function or verify that the token is correct when presented. The problem is, I think, that the way the fobs work is that the user needs a _short_ string to type in. Public-key crypto isn't secure for anything that small. Something a little bigger than 32 bits would let you encrypt a timestamp and nonce, but could be easily brute-forced. By the time you get to something with a big enough key, it's too big for the user to accurately transcribe. We're looking at what, a kilobyte of information for a user to transcribe for a moderate-sized key? > This sounds possible, but I don't have enough knowledge of the crypto > algorithms nowadays. > > An interesting question is: why doesn't the SecurID keyfob do this? It > seems like a vastly more secure procedure and you wouldn't have to > recall all the keyfobs. You could just generate new public keys. I think it's because to make it work with a 9-digit (or so) display, the key is so short so as to be useless. You want a sequence of apparently-random numbers, using a family of prng algorithms. If we could "standardize" on an interface, we could make a usb dongle act as a pipe, but that's mandating infrastructure, which pretty much defeats the whole purpose of the exercise anyway. -- Now, if our fob had an input capacity, we could go challenge-response! Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
