pem-dev
[Top] [All Lists]

Multiple uses of public keys a hazard?

1993-10-27 09:49:00
Steve,

Dr. Yair Frankel (a member of my staff who has written several 
landmark papers on cryptographic schemes for quorum
cryptography) and I were reviewing a contribution to the ABA
workshop on notarization and nonrepudiation which we are
working on, when we suddently discovered what might be
a new threat. We haven't worked it out completely, and maybe
it is just a half-baked idea, but I thought it might be worthwhile 
to expose the possibility to others to think about as well.

One of the threats that was brought up farily early in the PEM
architecture days was the possibility that if the user is allowed to
generate his own public/private keys (which seems like a good
idea, generally) and then bring the public key to the CA in the 
form of a prototype certificate, then there was the possibility 
that a devious user (that nasty Alice) might try to claim authorship
of a message originally signed by innocent Bob, by taking Bob's
public key and incorporating it in her own certificate.

To counter this threat, we added the requirement for the user
to actually sign a piece of innocuous text in order to establish
the fact that he or she actually possessed the private key. 
(Unfortunately, this signed text isn't included in the certificate,
so we have to take the CA's word for the fact that the CA software
checked this point.)

However, this does not prevent the user from apparently 
IMPERSONATING HIMSELF by switching the certificates 
used to validate the message, if the same public/private key
pair is used for both certificates. (This might occur even if
a smart card implementation is used, unless the certificate, and
not just the key, is contained in the smart card. But how many
smart cards do you want to have to carry around?)

At first glance, this seems nonsensical. What could the user gain?
Maybe nothing. But let's consider this carefully.

The potential danger lies in the possible/probable/debatable use 
of a certificate to establish or connote more than the simple identity 
of the user, in particular the user's affiliation and other "role" 
type issues that may be vouched for by the CA (and indirectly by the
PCA, to the extent that the PCA policy matters).

For example, suppose that the user receives a certificate from
a PCA that is part of a "commercial" hierarchy, and he uses the
public key in that certificate to purchase some stock. Is there 
any way that he could wait a day to see whether the stock goes 
up or down, and then repudiate his purchase by claiming that
the alleged signature was based on a Persona certificate
(that happened to have the same public key) that either wasn't
his or clearly wasn't intended for use for commercial transactions?

Vice versa, is there any way that someone could sign something
with a certificate from a low assurance CA, and later substitute a 
high assurance certificate in order to imply a stronger claim?

(All this is based on the fact that the Originator-Certificate and/or
the Originator_ID_Asymmetric fields are not directly bound to the
message itself, and therefore can be substituted or altered without 
violating the signature validation process.)

(I sometimes find myself wishing that the public key itself were the
DN, and all of the rest of the information merely additional attributes
signed by the CA. Then it would be at least conceivable that we 
could look up the public key and see if it were a duplicate.)

As I say, this may just be a red herring.   But I would feel more
comfortable if someone could develop an argument that would 
"prove" that there is no problem, without having to argue that
all that a certificate is "supposed" to mean is the identity of the
user in any case.

Bob




<Prev in Thread] Current Thread [Next in Thread>