On Thu, Aug 28, 2008 at 08:37:43PM -0700, Andrew Lentvorski wrote:
Basically, if you manage to compromise the server, you can fake the keyfob
since the secret is now compromised.
Yes, this is a weakness in the RSA system.
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.
This sounds possible, but I don't have enough knowledge of the crypto
algorithms nowadays.
Depends on the computing power available. Given the constraints at
the time the RSA SecurID was designed, it wasn't really possible to do
a public key algorithm in such a small battery-powered device. It
shouldn't be too hard to do now.
An 8051 isn't a particularly power CPU, and isn't all that fun to try
implementing large number arithmetic on. An RSA signature would
probably take minutes or even tens of minutes to compute.
The easiest implementation would be to embed a smartcard auth module
with the CPU and let the CPU generate the counter, ask for the
signatures, and print the result on a display.
The crypto part isn't all that hard, say you use RSA. The fob is the
only place the secret is stored, and the public key can be common
knowledge, but the server does know it.
The fob then usually just signs the counter. This can be done without
a hash if you have a reasonable source of randomness for the upper
bits (there are several tricks for this), although using the hash of
the count is easier to get right.
You probably don't want to be doing a full RSA signature every minute,
so this kind of fob would usually have a button on it. You would
press the button and it would grind away for a few seconds and give
you a result.
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.
Done with public keys, the keys can be just that, public. In fact,
they cannot be regenerated, since they are based on the secrets in the
fobs.
Part of the problem is that it breaks the SecurID revenue model. They
charge continually for the use of the fobs (which I guess makes it
seem less costly to lose a fob). If the fob is documented and uses
readily understood public-key algorithms.
This is pretty much exactly what the smart-card style two-token
devices do. Their disadvantage is requiring a reader (but it allows
an active challenge, instead of a clock synchronization). I have seen
fobs with keypads but that is annoying as well. The smartcards
usually have the primitives necessary to do the signature implemented
in hardware.
David
--
KPLUG-List@kernel-panic.org
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
