> Carl Ellison and Bruce Schneier write:
> > Certificate verification does not use a secret key, only public keys.
> >
> > Therefore, there are no secrets to protect. However, it does use one
> > or more "root" public keys. If the attacker can add his own public
> > key to that list, then he can issue his own certificates, which will
> > be treated exactly like the legitimate certificates. They can even
> > match legitimate certificates in every other field except that they
> > would contain a public key of the attacker instead of the correct one.
>
> While this is true, keep in mind that there is more to mounting
> a successful cryptographic attack than adding root keys and fake
> certificates. It is also necessary to intercept the messages which
> might have gone to the legitimate recipient, and possibly decrypt and
> re-encrypt them. All this implies an attacker who has at least temporary
> write access to the victim's computer, and long term read/write control
> over the communication channels he will use.
I do not believe this attack requires "long term read/write" access to
the victim's computer. If I want to get a forged certificate into a
clients Browser all I have to do is convince the user to browse my
secure server with Netscape (or another browser) that will prompt the
user to install my unrecognized root certificate.
Is this a cryptographic attack? No. But it certainly is made easier
by the use of PKI. The average (and even many security savy) users
are very quick to press the 'Ok' button when browsing the web because
their primary motivation is to get the information that they desire.
If that means accepting a certificate, or a cookies, or a
Java/Active-X applet, so be it. Even when this means that the
security of their system has been compromised.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
