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.
This is a very powerful attack model. Virtually no cryptographic system,
whether public key, secret key, or even a one time pad, could be secure
against such an attacker. If the attacker can get in and modify the
set of trusted certs, he can probably also modify the software that
checks them. He can weaken the generator of session keys, or arrange
to log messages and access them later. He has many ways of getting
access to the data beyond adding certs. This is not a threat for which
is reasonable to expect a cryptographic defense, and it is not an issue
specifically related to PKIs.
The lack of clear analysis of the threat model in the "risks" being
discussed makes it hard to evaluate how seriously to take them. If the
goal is simply to raise fear, uncertainty and doubt about using public key
cryptography, the authors have succeeded. But if they want to enlighten
potential users about concerns which are serious and specific to the
use of PKIs, they do not make that distinction clear.
In fact the entire thrust of the article is against a poorly defined
bogeyman, the PKI. What is this beast which is being critiqued? All we
really learn is that it is being sold by security companies in a slick
"sales pitch" which purports to guarantee security. There is no technical
description of what the PKI is and how its weaknesses are manifest.
In fact, a PKI is fundamentally any system which allows you to determine
whether a public key is suitable for a given purpose. It can be as simple
as a personal collection of public keys you know are good for specific
purposes, or as complex as a full set of certification hierarchies with
cross certification and automated policy translation. Carl Ellison
himself is the chief designer of the Simple PKI. Presumably he does
not mean to say that he has misled potential users into taking on ten
new risks by his work on this protocol.
By using this generic term "PKI" the authors leave a great deal of
confusion about which systems they are criticizing. Some of their
"risks", such as the one quoted above, would apply to all of these
PKIs, including SPKI. Others are more specific to current X.509 based
hierarchical certification systems. Some don't address the PKI at all,
but worry about things like user interfaces, criticisms that can be
directed at virtually any form of security software.
Rather than a hodgepodge of "risks" which pertain to many aspects of
cryptographic systems beyond the public key infrastructure, it would be
more useful to see a clear description of the kind of PKI the authors
want to criticize, followed by a discussion of the issues which arise in
the practical use of such systems. This would provide useful information
to the potential purchaser or user of a PKI system. As presented, the
article is likely to raise confusion and concern, but not to lead users
to ask enlightened questions.
