Re: SecureID vs Certificates

[George Capehart <capegeo () opengroup org>]

> Tony Miedaner wrote:
>
> Hi Folks,
>
> Kind of a high level questions on trade offs between SecureID or
> Certificates.  It would seem pretty obvious that SecureID is a better
> system BUT for many situations it would seem to me that certificates
> would be a reasonable form of two factor authentication.  Can anyone
> provide a good reason why not to use certificates over SecureID?

The degree to which you can trust the cert is dependent upon several
factors . . . among them the amount of due diligence done by the
registration authority in verifying that the entity that is requesting
the certification really is who they say they are, the degree to which
one can be comfortable that the cert has not been hijacked (snooped off
the wire, captured by a malicious proxy, lifted from an unprotected data
store, etc.).  Basically, to be able to trust a cert as a means of
authenticating a user, you've got to trust the registration process at
the CA, you've got to trust the Web, and you've got to trust the "owner"
not to do something stupid like not passcode-protecting his/her cert. 
You read the CA's CPS and auditors' statements and get enough
information to decide whether to trust the certification process.  If
you trust users and the Web, you have a stronger stomach than I do. 
Personally, if I had something that required SecureID as an
authentication mechanism, there's *NO* way I'd accept a cert in lieu of
the SecureID.  
> Is it even reasonable to classify certificates as two factor?

No.  Two factor is usually defined as something you have and something
you know.  *Even if* the user protects the cert with a passcode, all
that's doing is the equivalent of keeping your ATM card in your wallet
and your wallet in your pocket.  ATMs require two-factor
authentication.  That's why you have to present your card and then key
in the PIN.  That's also why SecureID users have to append the PIN they
chose to the numbers generated by the SecureID device.  Two factor
authentication with a cert would require the presentation of the cert
along with a PIN or something else.  A cert by itself would be no better
than an ATM card by itself . . .

> It is understood that if someone can take control your computer they
> may be able to use the cert.

Yep.  Especially if it's not passcode protected.  But it's not necessary
to take control of the computer to use the cert.  All that's required is
to be able to snarf it anytime between the time it leaves the computer
and the time it gets to its destination.

<DIGRESSION>
The original motivation for digital certificates was to provide a means
by which people who didn't know each other could exchange public keys
and be somewhat assured that the *public* key they were using really
belonged with the private key which was in the possession of the person
with whom they wanted to exchange information.  Lets say Dr. A is a
world-renowned oncologist who specializes in cancer of the larnyx and
Dr. B is an ear, nose and throat specialist who has a patient whom he
suspects has cancer of the larnyx.  Dr. B wants to send the lab results
to Dr. A, but, in order to protect the confidentiality of her patient,
she doesn't want to send it unprotected.  She wants to be sure that no
one but Dr. A can read it.  One way to accomplish that is to encrypt the
data using a key that only Dr. A can decrypt.  They /could/ use a
symmetric key, but Dr. A is at the Mayo Clinic and Dr. B is Tampa, FL. 
This is precisely the reason public key cryptography and digital
certificates came about.  Dr. A can create a key pair, take his public
key to the Mayo Clinic Certificate Authority, present his hospital
credentials to them and ask them to certify the public key.  Dr. A can
then send his cert to Dr. B who can then verify the certificate by
contacting the Mayo Clinic Certificate Authority.  She can then be
reasonably comfortable when she encrypts her patient's information with
the public key in the cert that only Dr. A will be able to decrypt it
(unless Dr. A has lost his private key or forgotten the passphrase |-P
).  So the rationale for PKIs and digital certificates was *not* to
provide authentication mechanisms.  It was to provide a mechanism of key
exchange.  While there is an element of identity in a cert, it is of the
name nature as the name on an ATM card, a credit card, etc.  It's a way
of associating a name with some other "business" information . . . a
bank account number, a VISA account or a public key.  Neither an ATM
card nor a credit card by themselves provide any authentication . . .
only when accompanied by a PIN or a signature do they become useful. 
Likewise digital certificates.  A cert in a vacuum provides no
authentication value at all.
</DIGRESSION>
> Any insight is much appreciated as always:-)

--
George W. Capehart                               Phone:  +1 704.277.4561
                                                   Fax:  +1 704.853.2624

"I'd rather have a bottle in front of me than a frontal lobotomy"
Anonymous
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards