Once again, I boldly place my professional reputation on the line with
unreliable cryptographic analysis...
[Disclaimer: this is a (probably faulty) _cryptographic_ review. It has
nothing to do with which solution will better meet your business needs /
threat model / value sweet-spot etc]
For more than you ever wanted to know about the crypto behind SecurID, hit
this:
http://www.mail-archive.com/cryptography-digest%40senator-bedfellow.mit.edu/
msg03392.html
If you don't know Vin McLellan by reputation - that "he knows his stuff" is
probably one of the more significant understatements I've made this year.
Precis: SecurID relies on a hash with a secret algorithm. It has been
reviewed by many hardcore crypto guys under NDA. It's pretty safe. The
obvious "side channel" attacks against tokens are stealing them, bribing the
user, finding the PIN attached to the token with tape etc etc.
NOTE that many SecurID setups do not use the pinpads - they send the PIN
over the wire with varying degrees of security. In these cases, a stolen
token can be considered to be stolen access. [1]
Digital certs are a much thornier problem. Yes, a large enough private key
with a working authentication protocol should give you auth that is as
strong as RSA (8 days to go!). In real life, though, that's not how you'd
attack such a system. The attacks would be:
1. The private key is stored on the users' hard drives. Steal the laptop and
extract it.
1a. It's probably encrypted. D'oh. It will be encrypted (most likely) with a
"strong" cipher (let's say IDEA) which has as its key the hash output (let's
say SHA-1) of a passphrase. What does this mean? Well, we trust IDEA and
SHA-1. They're strong. We don't trust users to pick good passphrases though.
The real entropy in a Digital Cert system, assuming a stolen laptop, is
therefore the passphrase.
2. Attempt implementation attacks against the gateway system to see if it
"leaks". This is what's technically known as "complicated crypto stuff", but
as an _example_ of what I'm talking about, read up on Bleichenbacher's PKCS1
attack against RSA here:
http://theory.stanford.edu/~dabo/abstracts/RSAattack-survey.html
3. "Other" boneheaded implementation attacks. Saying "We use Digital
Certificates" is not enough to make a secure authentication protocol. People
make dumb mistakes all the time. Crypto should always be evaluated in the
context of the protocol. This makes it _imperative_ that any auth scheme
that uses certs be evaluated as a complete process. I should repeat that. If
you want to know if you have a secure protocol, evaluate the ENTIRE protocol
- do NOT assume that strong crypto will save you. I'd give examples, but
time/space problem and all that...
It's much harder to screw up the _protocol_ with SecurID (Is the access-code
correct for this token at this time? Yes? Done.)
> -----Original Message-----
> From: Paul D. Robertson [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 12 September 2000 7:45 AM
> To: Steve Smith
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: Token vs. Certificates
>
>
> On Mon, 11 Sep 2000, Steve Smith wrote:
>
> > Does anyone know which is better?
>
> The one with racing stripes!
Good to see you back, Paul! However, you should know that SecurID must win -
red ones go faster. ;)
Cheers,
[1] Yeah, that's a huge simplification. If you picked it up then you know
enough to work out the risks for yourself.
--
Ben Nagy
Network Consultant, Volante Solutions
PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
