Re: Ipsec encryption key when using digital certs

Sadiq Yakasai @ 15/04/2012 12:46 -0300 dixit:
> Carlos,
>
> I am not sure I agree with you on 'honoring a certificate from a
> different CA, if you know its public key' in this context.
>
> How can you have multiple CA root certificates in a single trustpoint on
> a Cisco router? Unless I am missing something here. Under a single
> trustpoint, you can have 2 certs right? A CA root cert and a personal
> one. If a router is authenticating ISAKMP using rsa-sig, then you are
> basically using one trustpoint, right?

You are missing something. One trustpoint corresponds to one CA.
But you can have multiple trustpoints defined in a router, and an ipsec
profile can use all of them to verify a certificate.
Quoting cisco:
If no trustpoint is specified in the ISAKMP profile, all the trustpoints
that are configured on the Cisco IOS router are used to validate the
certificate.

> Also, can you explain more what you mean by ' Signed content is not
> encrypted. A certificate is a public key and identity content, signed.'?
> AFAIK, a digital signature on an X.509 certificate is in fact encrypted. No?

No.
Encryption is a tool that serves many purpouses, mainly authentication
and confidentiality (plus non-repudiation).
Confidentiality is the easy one to understand. There you have raw
content and encrypted content, and the latter you can't
understand/see/decode. Usually when someone says "that's encrypted", he
is referring to this function, i.e. confidentiality.

Authentication is more involved, and is usually performed by signing.
Signing refers to encrypting a hash, which in turn refers to functions
that somehow condense key features of some content in a smaller piece.
The hashing algorithms create a small (usually fixed length)
representation of whatever content you whant to protect. This algo is
public and we commonly use MD5 (128 bits hash) and SHA (160 bits hash).
Good property of a hash is that is you change the "protected content"
then the hash changes, with high probability (But not necesarilly).
In fact many documents do have the same hash, but it is computationaly
complex to create a document with any given hash, so tampering with a
hashed document is hard (but not imposible).

So what the CA does is take your data (domain name, geographic data, and
public key plus some cert data like issue date and certificate
purpouse), creates a hash of all this and encrypts it. You receive all
the data (coded but not encrypted) plus the encrypted hash (AKA the
signature). You can recreate the hash on your own and compare that with
the one provided by the CA, decrypted by you. If both agree, you have a
high confidence that the certificate was not tampered with and then,
that this public key corresponds to the identifying data (domain name ?)
that it says, because you trust the CA.

>
> Maybe you can explain more what you mean here and educate us more please.

Please do let me know if this makes sense now.

>
> Thanks!
> Sadiq

-Carlos

>
> On Sun, Apr 15, 2012 at 4:14 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar
> <mailto:tron_at_huapi.ba.ar>> wrote:
>
> 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 <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>
> <mailto: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> <mailto:tron_at_huapi.ba.ar
> <mailto:tron_at_huapi.ba.ar>>> LW7
> EQI Argentina
>
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>> LW7
> EQI Argentina
>
>
>
> Blogs and organic groups at http://www.ccie.net
>
> ___________________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/__list/CCIELab.html
> <http://www.groupstudy.com/list/CCIELab.html>
>
>
>
>
>
>
>
>
>
>
> --
> CCIEx2 (R&S|Sec) #19963

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