1 2 Previous Next 15 Replies Latest reply: Apr 8, 2019 11:14 PM by Juergen Ilse CCNA R&S RSS

    Private and Public keys in Certificate

    Kingsley - CCSP/CCIP/ CCNP/CCIE Security

      Hi all

       

      With digital certificate authentication between Party A and B trying to establish an IPSec connection, the private and public keys are used which is used as following

       

      CA server Private Key - Used to encrypted the hash (signature) attached to the party's certificate.

      CA server Public key - The IPSec peer decrypts the hash using CA public Key which it got from the CA server's root cert.

      Party A Private Key - The party A encrypts the hash using it's private key

      Party B Public Key - The Party sends it's public key to party B in the certificate. Party B used the public key to decrypt the hash.

       

      Party B calculate the hash of the Party B certificate and compares it with the hash received. If the hash matches, authentication is successful.

       

      The same happens vice versa to authenticate Party A

       

      Is my understanding on the private and public purpose is correct?

       

      I have been working this for a long time but not able to get the exact picture.

       

      RFC 2409 is very user friendly readable version :-)

       

       

      With regards

      Kings

         
        • 1. Re: Private and Public keys in Certificate
          Zakir A. Khan - CCIE RS

          From my usderstanding:


          1. Party A generates a private/public key pair.
          2. Party A generates a certificate request (PKCS #10) with CN/OU/O/L/SP/C information and sends it to CA server by signing (hash+encryption) it with the private key.
          3. The CA server decrypts the digital signature with Party A's public key to validate it. If valid, the CA server uses a composite of PKCS #10 information and CA information to generate identity certificate for Party A.
          4. Then CA server performs a hash algorithm on that identity certificate, encrypts that hash using the CA server`s private key, and appends it to the identity certificate.
          5. The CA server sends this identity certificate and the root certificate (which includes the CA server public key) to party A.

          6. Party A installs root certificate first. Then Party A uses CA server`s public key from the root certificate to validate the signature of Party A`s identiy certificate.

          7. Party B also goes through the above mentioned procedure

          8. IPSec peers (Party A and Party B) exchange  the identity certificates during IKE negotiations. Party A uses the public key from the root certificate to decrypt the hash of Party B`s identity certificates. Part A also re-computes a hash of the received Party B`s identity certificate. If the decrypted and re-computed hashs match, the certificate is valid.

          • 2. Re: Private and Public keys in Certificate
            Ryan Hicks

            Zakir is correct, with the addition of expiration and CRL/OCSP checks before a valid determination is made.

             

            The public key is used by others to encrypt messages to the owner, and the owner uses its private key for signatures (to be decrypted by anyone), and decryption of messages sent to it by others.

            • 3. Re: Private and Public keys in Certificate
              Kingsley - CCSP/CCIP/ CCNP/CCIE Security

              The following two are correct, no doubt about them

               

              • The private key is used for encryption with signature which provdies non-repudiation.
              • When the party excahnges the cert, the CA's public key is used authenticate which is used decrypt the hash.

               

              My question is where is the party's private and public used?

               

              I have read in some documents that when the party sends request to the CA server, it uses the CA server's public to encrypt (got from the root cert) the request and then CA server uses it's private key to decrypt the request.

               

              http://book.soundonair.ru/cisco/ch13lev1sec5.html

               

              In some documents, I have read that the request is encrypted by the party's private key and CA server uses party's public key to decrypt it. Your version seems to be same but I am not sure on hash part of it.

               

              Is there any Cisco doc or RFC for this?

               

               

              With regards

              Kings

              • 4. Re: Private and Public keys in Certificate
                Zakir A. Khan - CCIE RS

                My question is where is the party's private and public used?

                 

                As I mentioned earlier, Party's privaye and public keys are used only when the party sends certificate request to the CA server.

                 

                Party generates a certificate request (PKCS #10) with CN/OU/O/L/SP/C information. It is just like a letter. Then the party runs the hash algorithm on that letter to generate a hash of it.  After that, party uses it's private key to encrypt that hash and appends that encrypted hash at the end of that letter and sends it to the CA server.

                 

                When the CA server receives the certificate request from the party, the request has two parts. First part is the request itself, And the second part that encrypted hash. The CA server computes a hash of the first part. Again,the CA server uses the public key of the party to decrypt the second part (the encrypted hash) to retrieve the hash. If the computed (1st part) and the decrypted (2nd part) hashs match, the certificate request from the party is valid..

                • 5. Re: Private and Public keys in Certificate
                  Kingsley - CCSP/CCIP/ CCNP/CCIE Security

                  Thanks.

                   

                  With regards

                  Kings

                  • 6. Re: Private and Public keys in Certificate
                    Rashid Siddiqui, CCNP, CVOICE, ITIL

                    Although this explanation is very basic, and i think we all know,

                     

                    Just to restate, if i want others to know "I am X", i will encrypt this message with my Private Key --> Since others have my public key --> when others will apply my known public key --> They will come to know --> This message is from X.

                     

                    Party A's Private Key will be used when it communicates with CA --> And CA want to validate the request indeed came from A.

                     

                    Part A's Public Key will be used by any other party B, C or D, to decrypt --> What A has sent - In Assymetric Method.

                     

                    CAn anyone explain to me, about the concept behind "MD5 Authentication". I always get it confused.

                    • 7. Re: Private and Public keys in Certificate
                      Kingsley - CCSP/CCIP/ CCNP/CCIE Security

                      MD5 authentication uses HMAC-MD5 which uses the data and key as input and gives a fixed hash ouput. This hash along with the data is sent to the peer. The peer generates the hash of the data and compares with the data. If the hash matches, the data is not been hanmpered.

                       

                      Now to my question.

                       

                      The logic of how private and public keys are used are very clear to me.  The question is where are CA and Peer pirvate and public key are used.

                       

                       

                      With regards

                      Kings

                      • 8. Re: Private and Public keys in Certificate
                        Kingsley - CCSP/CCIP/ CCNP/CCIE Security

                        Did some investigation.

                         

                        The certificate exchanged for authentication, is to claim that public key carried in the certificate is bounded to information in certificate and belongs to device or person who sent it.

                         

                        So basically, we are trying to authenticate the peer's public key.

                         

                        After a certificate exchange, if you issue "sh crypto key pubkey-chain rsa" you can see the public key installed.

                         

                        Now the peers after a successful authentication using digital cert, has installed each other's public key.

                         

                        What are peers going to do with the public keys? There should something else why would it be implemented like that.

                         

                         

                         

                        http://www.pgpi.org/doc/pgpintro/

                         

                         

                        With regads

                        Kings

                        • 9. Re: Private and Public keys in Certificate
                          Kingsley - CCSP/CCIP/ CCNP/CCIE Security

                          Snippet from http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1338498,00.html

                           

                          Although the sender's private key isn't used for authentication, it is required to decrypt the sender's message. Communication is only completed when the initiation message is decrypted; this can only be done with the private key, which only the user has access to.

                           

                           

                          The peer's private key are meant to encrypt messages.

                           

                          Does it mean that IKE Phase 1 MSG5, MSG6 and IKE Phase 2 messages are encrypted and decrypted by the private and public key? Said with this, it means skeyid_e will not be used for encrypted IKE Phase 1 MSG5, MSG6 and IKE Phase 2 messages .

                           

                           

                          The following are three keys generated from the shared secret arrived from DH exchange of IKE Phase 1 MSG 3 and 4 exchanges.

                           

                          SKEYID_e – For encrypting IKE messages

                           

                          SKEYID_a – For authenticating IKE messages

                           

                          SKEYID_d – Keying material used to generate encrypting and authenticating key for IPSec


                          With pre-shared authentication, the above three keys are used for sure.

                           

                           

                           

                          With regards

                          Kings

                          • 10. Re: Private and Public keys in Certificate
                            Kingsley - CCSP/CCIP/ CCNP/CCIE Security

                            Let me put my question in a simple form.

                             

                            Why are we trying to authenticate each other peer's public key along with their ID information using the digital signature signed by the CA?

                             

                            What is significance of the peer's public key after authentication?

                             

                             

                             

                            With regards

                            Kings

                            • 11. Re: Private and Public keys in Certificate
                              dickturpin

                              "Why are we trying to authenticate each other peer's public key along with their ID information using the digital signature signed by the CA?"

                               

                              Technically, you don't "authenticate each other peer's public key" - you have to take it on face value because that is what the peer sends over in his purported certificate. You verify two things: the correctness of the certificate (by using the CA's public key) and that the peer possess the corresponding private key (via IKE SIG payload).

                               

                              So "authentication rsasig" means: I will bring up a tunnel with (I) *any* peer who can present a certificate issued by one of my trustpoints and (II) can verify that he possess the corresponding private key.

                               

                              1. Peer B presents certificate: if not issued by Peer A trustpoint (CA) - goto END

                               

                              2. If issued by my trustpoint, verify correctness of certificate (using CA public key). If fail verification (bad cert)- goto END; if success it means we satisfy (I), i.e., peer B presents a valid certificate issued by one of my trustpoints.

                               

                              3. Now for (II): go through IKE Phase I, if success it means that peer B does indeed possess the private key corresponding to the certificate.  Hence you will bring up the tunnel.

                               

                              If fail, it means that the peer does not possess the private key.  For an active man-in-the-middle attack this is where you would realize you are talking to a fake party.

                               

                               

                               

                               

                               

                               

                               

                               

                               

                              "What is significance of the peer's public key after authentication?"

                               

                              After the peer has been authenticated in Phase I, the public key isn't needed anymore.

                              • 12. Re: Private and Public keys in Certificate
                                Kingsley - CCSP/CCIP/ CCNP/CCIE Security

                                You have mentioned that the digital certificate is used to verify that peer has the corresponding private key. It is done by using the public key, right? For that either, the peer should send a hash or any message encrypted with it's private key.

                                If the local peer can decrypt with that peer's public key found in the cert, then it verify's that peer has the corresponding the private key.

                                 

                                Can you tell me, what is thing that is being encrypted by the peer's private key. For sure the digital sig in the cert is encrypted by the CA's private key.

                                 

                                 

                                 

                                 

                                Technically, you don't "authenticate each other peer's public key" - you have to take it on face value because that is what the peer sends over in his purported certificate. You verify two things: the correctness of the certificate (by using the CA's public key) and that the peer possess the corresponding private key (via IKE SIG payload).

                                 

                                If fail, it means that the peer does not possess the private key.  For an active man-in-the-middle attack this is where you would realize you are talking to a fake party.

                                 

                                 

                                With regards

                                Kings

                                • 13. Re: Private and Public keys in Certificate
                                  Kingsley - CCSP/CCIP/ CCNP/CCIE Security

                                  The sender sign's it will his/her private key and the receiver verifies with the sender's public key. This is the case, where there is no CA server. For instance, we can consider the self-signed certificate. The signature in self -signed certificate is encrypted using the router's private key.

                                   


                                  With CA which is a third party signs the signature not the sender. This CA is trusted by both sender and receiver. Hence signature is encrypted by the CA not by the sender when CA servers are used.

                                   


                                  Snippets from http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_pki_overview_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1027184

                                   

                                   

                                  After each entity enrolls in a PKI, every peer (also known as an end host) in a PKI is granted a digital certificate that has been issued by a CA. When peers must negotiate a secured communication session, they exchange digital certificates. Based on the information in the certificate, a peer can validate the identity of another peer and establish an encrypted session with the public keys contained in the certificate.

                                   

                                   

                                   

                                  1. The end host generates an RSA key pair.

                                  2. The end host generates a certificate request and forwards it to the CA (or the RA, if applicable).

                                  3. The CA receives the certificate enrollment request, and, depending on your network configuration, one of the following options occurs:

                                  c. Manual intervention is required to approve the request.

                                  d. The end host is configured to automatically request a certificate from the CA. Thus, operator intervention is no longer required at the time the enrollment request is sent to the CA server.

                                  4. After the request is approved, the CA signs the request with its private key and returns the completed certificate to the end host.

                                  5. The end host writes the certificate to a storage area such as NVRAM.

                                   

                                   


                                  With regards
                                  Kings

                                  • 14. Re: Private and Public keys in Certificate
                                    Juergen Ilse CCNA R&S

                                    I think, that is correct. But since you can't check the correctness of the CA's keypair, if you get the certificate (including the CA's public key) from the CA itself (maybe you got it from a fake CA ...), the CA's certificate may be signed by another CA (so it can be checked the same way as the peer's certificate). If the peer sends it's own certificate together with that "intermediate" certificate and the "root" certificate (which may be received via another way and which we trust), the whole way from peer's certificate to the trusted root certificate may be checked. This collection of certificates has to include the whole "certificate path", otherwise the identity can't be checked.

                                    1 2 Previous Next