Tom, Steve, et. al:
The process of reading my email is beginning to consume a larger portion
of my day, mainly due to the endlessly circular arguments from pem-dev.
I have hesitated to add to this load, for I am not particularly religous
in my views. HOWEVER, it might be useful to add another viewpoint to
the symmetric/asymmetric argument. To summarize for those with a quick
delete finger, Steve is mostly correct, but Tom wins a couple of rounds.
Let me explain from my own perspective.
Although I am a big fan of symmetric key management for localized deployment
(smaller infrastructure, no royalties, etc...), it has two primary problems
that keep it from scaling well:
- it is inherently a real-time operation
- a KDS is entrusted with protecting the secret keys of all
clients that it serves. It must also protect the interchange
keys that it must use to communicate with other KDSs.
The very first time that I wish to communicate with some other user of
a symmetric key management application, I must go to an appropriate KDS
in order to receive the secret "traffic encryption key", TEK, to be
used in protecting our conversation. This implies that the KDS is
available via the network, both to service my request and to attack.
Contrast this with a (P)CA. Its services are not needed in real-time.
It can be locked up in a room with no network access and a cordon of
armed guards. Symmetric KM loses big here, it suffers from availability
problems and is far less secure.
If the individual with whom I wish to converse resides outside the realm
of my KDS, and if my KDS does not have an interchange key with my target's
KDS, then:
a) I cannot communicate with them securely.
or b) My KDS must establish an interchange key with the target KDS and
must do so using some channel that provides adequate
confidentiality. ANSI X9.17 and the appendix to Tom's book cannot
help us here.
For public key management, if the individual with whom I wish to converse
resides outside the realm of my PCA (regardless of the PEM RFCs, this will
occur - I cannot imagine the French government permitting RSA or the IETF
to act upon its behalf), I must obtain the certificate of my target or
a certificate of some CA in the chain above my target in any manner that
provides adequate authentication of that certificate, ala PGP. This
is easier to accomplish. Asymmetric scores a minor win.
If a KDS is compromised, the attacker will have access to all clients'
secret keys. This will enable them to eavesdrop on any conversation,
or impersonate any client. What is worse, it can do so without detection.
If a (P)CA is compromised, the attacker:
- has access to all clients certificates. So what, they are
freely available anyway.
- can create false CRLs.
- can create false certificates.
BUT, the attacker will not have access to any client's private key. Thus
an attacker cannot eavesdrop on any legitimate traffic, or impersonate
a client in an undetectable manner. They can impersonate a client by
creating a false certificate for that client, or cause a denial of service
by placing a certificate on a CRL. But these actions will leave a very
definite trail that can be corrected later. Symmetric KM loses big again.
The problems associated with having your secret or private key compromised
are quite similar. The CRL is a mechanism for avoiding transactions
with an imposter, or at least discovering them post facto. A similar
mechanism could be designed for symmetric KM. It would place a greater
load on the infrastructure, for a symmetric CRL would need to be signed
uniquely for each client requesting one. Call this a wash.
Charlie Watt
SecureWare, Inc.