pem-dev
[Top] [All Lists]

Revised "RFC [FORMS]" draft

1992-04-10 14:21:00
Jim --

      2. Protection against an attack where a user requests a certificate
         with someone else's public key. The user signs the (name, public
         key) combination, proving that the user has the private key and is
         not replaying someone else's signature.

At the risk of missing something obvious in an open forum, I do not
understand this.

Here's the attack. Suppose I'm the one carrying out the attack, and
you're the victim, and further suppose that certificate requests carry
a prototype certificate (as in the old [FORMS]).

1. You generate an RSA key pair, construct a prototype certificate
   containing your public key and send a certification request (old
   style) containing the prototype certificate and your signature on
   some "innocuous" text. The certification authority signs a
   certificate and returns to you an ordinary privacy-enhanced
   message. Everything's okay so far.

2. I take *your* public key and my name, construct a prototype
   certificate, and send a certification request (old style)
   containing the prototype certificate and *your* signature on *your*
   certification request. The certification authority doesn't
   necessarily know I've taken your public key, so it signs a
   certificate with my name and your public key and returns it to me.

3. You prepare an ENCRYPTED privacy-enhanced message whose plaintext
   is something sensitive, impersonal, and containing a shared secret,
   like

       Please mail me by regular mail the specifications on X-Y
       satellite project. As we discussed, the codeword is SAX.

   The recipient of the message decrypts it and sees that you're the
   signer (because you've attached your certificate). Since you gave
   the correct codeword, the recipient sends you the specifications
   by regular mail.

4. I take your ENCRYPTED message and replace your certificate (and
   "Originator-Asymmetric-Info:" field) with mine. The recipient of
   the message now sees that I'm the signer, since you and I have the
   same public key! Now of course if it was a MIC-ONLY or MIC-CLEAR
   message, I could've made a new signature on my own; the attack
   doesn't give anything new. But since it's an ENCRYPTED message, the
   recipient may assume falsely that I really do know the codeword,
   and may send me the specifications. (By regular mail, I hope, since
   if it's by PEM then only you can open it; I don't have your private
   key.)

The point is that a recipient may be "tricked" into believing that the
signature on an ENCRYPTED message establishes the identity of the
signer. It doesn't. It establishes only the signer's public key.
Therefore, it is important to ensure in the certification process that
no signer is given a certificate for someone else's public key. Since
there are likely to be many certifying authorities, not all
coordinating through a central database, a cryptographic method such
as signing the subject name with the private key is essential.

The prototype certificate had no signature, and the "innocuous text"
had no name. The new [FORMS] draft solves the problem with a signature
on the public key and name.

-- Burt


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