Re: Ipsec encryption key when using digital certs

Brian,
I don't follow this step, and what you mean by "authentication strings".

In fact, it would follow from your explanation that both endpoints
should have certificates from the same CA, which is not the case.

The "key" to PKI is to understand that the identity of one entity is
conveined by the the knowledge of its public key. Once I know for sure
that a given public key is the one that corresponds to an entity (router
in this case), I can be sure (authenticate) any material, included that
used for generating shared keys to be used in simetrical ciphers.
But this is not trivial because some fake A' can come and say "this is
the public key for A" and then fool anyone. This is also true for CAs.
And there is no secure way of "knowing for sure" using protocols alone.
You need and out of band warranty that you have a common trust point,
and that knowledge comes, usually, by comparing some hash of the
certificate of the TP, usually a common CA.

The process of validating a certificate is by hash checking. The
certificate has a hash encrypted by the CA private key. The router can
recompute the hash and compare it to the decrypted hash (that it can
decrypt because it has the other's router CA public key). This encrypted
hash is what we call a signature.

Once you know for sure the other endpoint public key, you could just
generate a random secret, cipher it with the public key and send it in
the clear. The only one able to descipher it would be the intended
endpoint (because it is the one holding the corresponding provate key)
and now both ends have a "shared key" to be used for simetrical cipher.

The whole thing is that simetrical ciphers are *way* cheaper to
implement, i.e. faster to crypt/uncrypt.

Hope this helps.
-Carlos

Brian McGahan @ 14/04/2012 20:34 -0300 dixit:
> With CA based authentication, both you and I generate both public and private keys,
and then we then get the public key of the CA server. Next we both send
our public
keys to the CA server, who adds some authentication strings to them, and
then encrypts
them with the CA's private key. The result of this is our signed
certificates.
Remember that something encrypted with a private key can be decrypted
with a public key.
This means that if I give you my certificate (which was signed with the
private key of
the CA) you can decrypt it by using the CA's public key, and find the
authentication
strings that the CA added. You then decrypt your own certificate with
the CA's public
key, get the authentication strings, and compare it against mine. If
these strings match
it means that both our certificates were signed by the same CA, and the
authentication is
successful.

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net