Re: Ipsec encryption key when using digital certs

I still don't like it :( But that's just me :)

Hashes from different documents don't have to match. What has to match
is the calculated hash by the sender and bey the receiver, where the
sender one is protected by encryption.

And by different CAs I was not referring to hierarchy. You can honour a
certificate from an altogether different CA if you know its public key.

Signed content is not encrypted. A certificate is a public key and
identity content, signed.

-Carlos

Brian McGahan @ 15/04/2012 09:28 -0300 dixit:
> > Brian,
> I don't follow this step, and what you mean by "authentication strings".
>
> That's what the hash is. Its a string that has to match for the
> authentication to succeed.
>
> > In fact, it would follow from your explanation that both endpoints
>> should have certificates from the same CA, which is not the case.
>
> Right, this would be the most simplistic case, where all certs come from
> the same CA. Of course in a real design you can have subordinate CAs,
> levels of hierarchy, cert chains, etc. but in the end the logic is still
> the same that you decrypt what the CA signed with their private key by
> using their public key, in order to find the authentication string
> inside (the hash).
>
> Brian McGahan, CCIE #8593 (R&S/SP/Security)
> bmcgahan_at_INE.com <mailto:bmcgahan_at_INE.com>
>
> Internetwork Expert, Inc.
> http://www.INE.com
>
> On Apr 15, 2012, at 7:16 AM, "Carlos G Mendioroz" <tron_at_huapi.ba.ar
> <mailto:tron_at_huapi.ba.ar>> wrote:
>
>> 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 <mailto:tron_at_huapi.ba.ar>> LW7
>> EQI Argentina

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