1 2 Previous Next 18 Replies Latest reply: Jul 14, 2010 2:41 AM by Alkuin Melvin RSS

    RSA Key

    Pemasiri

      Hi,

       

      Though this is simple question, can someone explain what does mean when asking to;

      "generate a RSA key such that it will use a seperate key for encryption and a seperate key for signatures"

       

      does this mean we have to genrate two seperate keys, if yes how can it be.?

       

      thanks

        • 1. Re: RSA Key
          Zaher Hamiyah

          Hello,

           

          when you generate an RSA key, the router will generate two keys public and private.

          RSA uses a public key/private key combination. The public key in this pair can be known by anyone and can be distributed widely without issue to encrypt messages.

          As an example for Cisco VPN configuration using CA-based VPNs the following steps are used:

          -router generates RSA key pair

          -router sends a certificate request to the CA

          -CA approve certificate request

          -certificate is generated with requesting router's public key and CA signature

          -CA sends completed certificate to router

          -router stores certificate in NVRAM

          as you see here you have to generate RSA keys for this process.

           

          The following example is for generating and verifying RSA keys:

          Router(config)#ip domain name zaherhamiyah.com

          Router(config)#hostname zaher

          zaher(config)#crypto key zeroize rsa (removes previous RSA keys)

          Router(config)#crypto key generate rsa general-keys modulus 1024 OR

          zaher(config)#crypto key generate rsa ?

          general-keys Generate a general purpose RSA key pair for signing and

          encryption

          usage-keys Generate separate RSA key pairs for signing and encryption

          <cr>

          zaher(config)#crypto key generate rsa

          The name for the keys will be: zaher.zaherhamiyah.com

          Choose the size of the key modulus in the range of 360 to 2048 for your

          General Purpose Keys. Choosing a key modulus greater than 512 may take

          a few minutes.

          How many bits in the modulus [512]: 1024

          % Generating 1024 bit RSA keys, keys will be non-exportable...[OK]

          *Sep 10 21:09:29.947: %SSH-5-ENABLED: SSH 1.99 has been enabled

          zaher#show crypto key mypubkey rsa

          % Key pair was generated at: 20:27:24 UTC Sep 10 2008

          Key name: zaher.zaherhamiyah.com

          Usage: General Purpose Key

          Key is not exportable.

          Key Data:

          30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00AC02EA

          A1DA2A03 AB6FA318 2CF6747A CDECE0A0 AAB3CAAC B7459638 EA01B87E 904740C4

          0674ADB8 94D29D8A 6CF4FB61 8A84C2E3 EF3E9803 57EB55AE 44561A9D 887FA3B8

          3E673088 13775984 B080D222 45D12D59 68D180AA 7562DE81 C030CDED 80ADA933

          87CBD4E3 5914A58B 1DEDF713 DB976DC9 28FDAA67 D8A41A1D A6165554 15020301 0001%

          Key pair was generated at: 20:27:26 UTC Sep 10 2008

          Key name: zaher.zaherhamiyah.com.server

          Usage: Encryption Key

          Key is not exportable.

          Key Data:

          307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00A8D7BD 9CDD4F02

          9EC2B2C1 FD6CD09E D15BEEAF E7ACB939 7D731127 E01B8372 C5984A4B EABDB3C3

          B7955FE6 F388DC17 E9856856 0B72DA24 F263B744 6B3E468F 320AA96A 58853989

          3413A881 A4B4E200 1B93B35F 3346829C D6D41BEB D08F5F9E 73020301 0001

           

          Now for signatures, the sender will use the public key of the reciever to generate a hash value of the message he wants to send and then attachs this value to the message as a digital signature and when the message is recieved the reciever will generate the hash using the same public key and  compare the two results to make sure that the message has not been altered during transit.

           

          Sy,

          Zaher Hamiyah

           

           

           

           

          • 2. Re: RSA Key
            Kingsley - CCSP/CCIP/ CCNP/CCIE Security

            Yes, it will generate two set of keys. One will be used for signing and other for encryption. If you don't then one key is generated which will be used

            for both encryption and signing.

             

             

            With regards

            Kings

            • 3. Re: RSA Key
              Brandon Carroll - CCIE (Security)

              The simple answer is that you can generate general purpose keys vs. usage keys.  The usage keys are what you want so you have signing and encryption keys that are different.  General purpose keys use the same key pair for signing and encrypting.

               

              HTH.

               

              Brandon Carroll

              Ascolta

              • 4. Re: RSA Key
                Alkuin Melvin

                Hi,could someone tell me what is the difference between signature keys   and encryption keys in show crypto key mypubkey rsa ?

                • 5. Re: RSA Key
                  Tyson Scott

                  Brandon Answered it above with the difference between usage and general keys but here is a copy paste from the command reference:

                   

                  Special-Usage Keys

                  If you generate special-usage keys, two pairs of RSA keys will be generated. One pair will be used with any Internet Key Exchange (IKE) policy that specifies RSA signatures as the authentication method, and the other pair will be used with any IKE policy that specifies RSA encrypted keys as the authentication method.

                  A CA is used only with IKE policies specifying RSA signatures, not with IKE policies specifying RSA-encrypted nonces. (However, you could specify more than one IKE policy and have RSA signatures specified in one policy and RSA-encrypted nonces in another policy.)

                  If you plan to have both types of RSA authentication methods in your IKE policies, you may prefer to generate special-usage keys. With special-usage keys, each key is not unnecessarily exposed. (Without special-usage keys, one key is used for both authentication methods, increasing the exposure of that key.)

                  General-Purpose Keys

                  If you generate general-purpose keys, only one pair of RSA keys will be generated. This pair will be used with IKE policies specifying either RSA signatures or RSA encrypted keys. Therefore, a general-purpose key pair might get used more frequently than a special-usage key pair.

                  • 6. Re: RSA Key
                    Alkuin Melvin

                    Hi scott, thank you for your reply. I have more question though, the signature key and encryption key are public key right? cause i read somewhere in internet that private key couldn't be seen in the running configuration. And i have one more question, when is the signature keys will be used and when is the time the encryption keys will be used? Do you have any references for the encryption and decryption process? thx.

                    • 7. Re: RSA Key
                      Conwyn

                      Hi Alkuin.

                       

                      In general you encrypt data using the encryption key. To ensure the data has not be changed you use a hashing algorithm on the message and this is called the signature. You can not encrypt ESP-NULL but still have a signature such as RSA.

                       

                      Regards Conwyn

                      • 8. Re: RSA Key
                        Alkuin Melvin

                        Hi Conwyn,

                         

                        So the data will be encrypted using both signature key and encryption key at the same time and every time we send a message ?

                         

                        Regards

                         

                        Melvin

                        • 9. Re: RSA Key
                          Conwyn

                          Hi alkuin

                           

                          The data is encrypted with encryption key.

                          The IPSEC packet has an authentication field. This field is a hash of the data. The hash uses the signature key.

                          For example it possible not to encrypt the data but still have authentication to prove the data has not changed. This authentication uses the signature key.

                           

                          Regards Conwyn

                          • 10. Re: RSA Key
                            Alkuin Melvin

                            Hi Conwyn,

                             

                            Thanks for your explanation about the authentication field, so basically the data will be encrypted with encryption key, and after that the signature key will be used to hash the data for the signature. So when we trying to send the data, the encryption and signature key will be used together before sending the data. Am i correct ?

                             

                            Regards

                             

                            Melvin

                            • 11. Re: RSA Key
                              Conwyn

                              Hi Alkuin

                               

                              Ignore my previous posting.

                               

                              This is a better explaination in these articles by Andrew Mason. I have extracted part four to ease reading.

                              1: (http://www.ciscopress.com/articles/article.asp?p=25470)

                              2: (http://www.ciscopress.com/articles/article.asp?p=25477)

                              3: (http://www.ciscopress.com/articles/article.asp?p=25473)

                              4:  (http://www.ciscopress.com/articles/article.asp?p=25474)

                              5:  (http://www.ciscopress.com/articles/article.asp?p=25443)

                               

                              Regards Conwyn

                               

                               

                              IKE Overview

                              Internet Key Exchange (IKE) negotiates the IPSec security associations (SAs). This process requires that the IPSec systems first authenticate themselves to each other and establish ISAKMP (IKE) shared keys.

                              NOTE

                              A security association (SA) is a relationship between two or more entities that describes how the entities will use security services to communicate securely.

                              In phase 1 of this process, IKE creates an authenticated, secure channel between the two IKE peers, called the IKE security association. The Diffie-Hellman key agreement is always performed in this phase.

                              In phase 2, IKE negotiates the IPSec security associations and generates the required key material for IPSec. The sender offers one or more transform sets that are used to specify an allowed combination of transforms with their respective settings. The sender also indicates the data flow to which the transform set is to be applied. The sender must offer at least one transform set. The receiver then sends back a single transform set, which indicates the mutually agreed-upon transforms and algorithms for this particular IPSec session. A new Diffie-Hellman agreement may be done in phase 2, or the keys may be derived from the phase 1 shared secret.

                              Figure 1 shows the role that IKE takes in the IPSec VPN creation process.

                              Figure 1 The function of IKE.

                              IKE authenticates the peer and the IKE messages between the peers during IKE phase 1. Phase 1 consists of main mode or aggressive mode. (These modes are described later in this article.) Potential peers in an IPSec session must authenticate themselves to each other before IKE can proceed. Peer authentication occurs during the main mode exchange during IKE phase 1. The IKE protocol is very flexible and supports multiple authentication methods as part of the phase 1 exchange. The two entities must agree on a common authentication protocol through a negotiation process.

                              IKE phase 1 has three methods to authenticate IPSec peers in Cisco products:

                              • Pre-shared keys. A key value entered into each peer manually (out of band) and used to authenticate the peer.

                              • RSA signatures. Uses a digital certificate authenticated by an RSA signature.

                              • RSA encrypted nonces. Uses RSA encryption to encrypt a nonce value (a random number generated by the peer) and other values.

                              A common value used by all authentication methods is the peer identity (ID), which helps identify the peer. Some ID values used are as follows:

                              • IP address of the peer (four octets), such as 172.30.2.2.

                              • Fully qualified domain name (FQDN), such as student@cisco.com.

                               

                              Pre-Shared Keys

                              With pre-shared keys, the same pre-shared key is configured on each IPSec peer. IKE peers authenticate each other by computing and sending a keyed hash of data that includes the pre-shared key. If the receiving peer is able to independently create the same hash using its pre-shared key, then it knows that both peers must share the same secret, thus authenticating the other peer.

                              Pre-shared keys are easier to configure than manually configuring IPSec policy values on each IPSec peer. But pre-shared keys don't scale well because each IPSec peer must be configured with the pre-shared key of every other peer with which it will establish a session

                               

                              RSA Signatures

                              RSA is a public-key cryptosystem used by IPSec for authentication in IKE phase 1. RSA was developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adelman.

                              The RSA signatures method uses a digital signature setup in which each device digitally signs a set of data and sends it to the other party. RSA signatures use a certificate authority (CA) to generate a unique-identity digital certificate that's assigned to each peer for authentication. The identity digital certificate is similar in function to the pre-shared key, but provides much stronger security.

                              Each initiator and responder to an IKE session using RSA signatures sends its own ID value (IDi or IDr), its identity digital certificate, and an RSA signature value consisting of a variety of IKE values, all encrypted by the negotiated IKE encryption method (DES or 3DES).

                               

                              RSA Encryption

                              The RSA-encrypted nonces method uses the RSA encryption public key cryptography standard. It requires that each party generate a pseudo-random number (a nonce) and encrypt it in the other party's RSA public key. Authentication occurs when each party decrypts the other party's nonce with a local private key (and other publicly and privately available information) and then uses the decrypted nonce to compute a keyed hash. This system provides for deniable transactions. That is, either side of the exchange can plausibly deny that it took part in the exchange.

                              Cisco IOS software is the only Cisco product that uses RSA-encrypted nonces for IKE authentication. RSA-encrypted nonces use the RSA public key algorithm.

                               

                              Certificate Authorities and Digital Certificates

                              The distribution of keys in a public key scheme requires some trust. If the infrastructure is untrusted and control is questionable (such as on the Internet), distribution of keys is troublesome. RSA signatures are used by certificate authorities (CAs), which are trusted third-party organizations. VeriSign, Entrust, and Netscape are examples of companies that are providing digital certificates. A client registers with a certificate authority; after the CA verifies the client's credentials, a certificate is issued.

                              The digital certificate is a package containing information such as a certificate bearer's identity: his or her name or IP address, the certificate's serial number, the certificate's expiration date, and a copy of the certificate bearer's public key. The standard digital certificate format is defined in the X.509 specification. X.509 version 3 defines the data structure for certificates, and is the standard that Cisco is supporting. Figure 2 identifies some key points of CA operation

                               

                              How IPSec Works

                              IPSec involves many component technologies and encryption methods. Yet IPSec's operation can be broken down into five main steps:

                              1. "Interesting traffic" initiates the IPSec process. Traffic is deemed interesting when the IPSec security policy configured in the IPSec peers starts the IKE process.

                              2. IKE phase 1. IKE authenticates IPSec peers and negotiates IKE SAs during this phase, setting up a secure channel for negotiating IPSec SAs in phase 2.

                              3. IKE phase 2. IKE negotiates IPSec SA parameters and sets up matching IPSec SAs in the peers.

                              4. Data transfer. Data is transferred between IPSec peers based on the IPSec parameters and keys stored in the SA database.

                              5. IPSec tunnel termination. IPSec SAs terminate through deletion or by timing out.

                              This five-step process is shown in Figure 3.

                              Figure 3 The five steps of IPSec.

                              Step 1—Defining Interesting Traffic

                              What type of traffic is deemed interesting is determined as part of formulating a security policy for use of a VPN. The policy is then implemented in the configuration interface for each particular IPSec peer. For example, in Cisco routers and PIX Firewalls, access lists are used to determine the traffic to encrypt. The access lists are assigned to a cryptography policy; the policy's permit statements indicate that the selected traffic must be encrypted, and deny statements indicate that the selected traffic must be sent unencrypted. With the Cisco Secure VPN Client, you use menu windows to select connections to be secured by IPSec. When interesting traffic is generated or transits the IPSec client, the client initiates the next step in the process, negotiating an IKE phase 1 exchange.

                              Step 1 is shown in Figure 4.

                              Figure 4 Defining "interesting traffic."

                              Step 2—IKE Phase 1

                              The basic purpose of IKE phase 1 is to authenticate the IPSec peers and to set up a secure channel between the peers to enable IKE exchanges. IKE phase 1 performs the following functions:

                              • Authenticates and protects the identities of the IPSec peers

                              • Negotiates a matching IKE SA policy between peers to protect the IKE exchange

                              • Performs an authenticated Diffie-Hellman exchange with the end result of having matching shared secret keys

                              • Sets up a secure tunnel to negotiate IKE phase 2 parameters

                              IKE phase 1 occurs in two modes: main mode and aggressive mode. These modes are described in the following sections.

                              Main Mode

                              Main mode has three two-way exchanges between the initiator and the receiver.

                              • First exchange: The algorithms and hashes used to secure the IKE communications are agreed upon in matching IKE SAs in each peer.

                              • Second exchange: Uses a Diffie-Hellman exchange to generate shared secret keying material used to generate shared secret keys and to pass nonces—random numbers sent to the other party and then signed and returned to prove their identity.

                              • Third exchange: Verifies the other side's identity. The identity value is the IPSec peer's IP address in encrypted form. The main outcome of main mode is matching IKE SAs between peers to provide a protected pipe for subsequent protected ISAKMP exchanges between the IKE peers. The IKE SA specifies values for the IKE exchange: the authentication method used, the encryption and hash algorithms, the Diffie-Hellman group used, the lifetime of the IKE SA in seconds or kilobytes, and the shared secret key values for the encryption algorithms. The IKE SA in each peer is bi-directional.

                              Aggressive Mode

                              In aggressive mode, fewer exchanges are made, and with fewer packets. On the first exchange, almost everything is squeezed into the proposed IKE SA values: the Diffie-Hellman public key; a nonce that the other party signs; and an identity packet, which can be used to verify identity via a third party. The receiver sends everything back that is needed to complete the exchange. The only thing left is for the initiator to confirm the exchange. The weakness of using the aggressive mode is that both sides have exchanged information before there's a secure channel. Therefore, it's possible to "sniff" the wire and discover who formed the new SA. However, it is faster than main mode.

                              Step 2 is shown in Figure 5.

                              Figure 5 IKE phase 1.

                              Step 3—IKE Phase 2

                              The purpose of IKE phase 2 is to negotiate IPSec SAs to set up the IPSec tunnel. IKE phase 2 performs the following functions:

                              • Negotiates IPSec SA parameters protected by an existing IKE SA

                              • Establishes IPSec security associations

                              • Periodically renegotiates IPSec SAs to ensure security

                              • Optionally performs an additional Diffie-Hellman exchange

                              IKE phase 2 has one mode, called quick mode. Quick mode occurs after IKE has established the secure tunnel in phase 1. It negotiates a shared IPSec policy, derives shared secret keying material used for the IPSec security algorithms, and establishes IPSec SAs. Quick mode exchanges nonces that provide replay protection. The nonces are used to generate new shared secret key material and prevent replay attacks from generating bogus SAs.

                              Quick mode is also used to renegotiate a new IPSec SA when the IPSec SA lifetime expires. Base quick mode is used to refresh the keying material used to create the shared secret key based on the keying material derived from the Diffie-Hellman exchange in phase 1.

                              Perfect Forward Secrecy

                              If perfect forward secrecy (PFS) is specified in the IPSec policy, a new Diffie-Hellman exchange is performed with each quick mode, providing keying material that has greater entropy (key material life) and thereby greater resistance to cryptographic attacks. Each Diffie-Hellman exchange requires large exponentiations, thereby increasing CPU use and exacting a performance cost.

                              Step 4—IPSec Encrypted Tunnel

                              After IKE phase 2 is complete and quick mode has established IPSec SAs, information is exchanged via an IPSec tunnel. Packets are encrypted and decrypted using the encryption specified in the IPSec SA. This IPSec encrypted tunnel can be seen in Figure 6.

                              Figure 6 IPSec encrypted tunnel.

                              Step 5—Tunnel Termination

                              IPSec SAs terminate through deletion or by timing out (see Figure 7). An SA can time out when a specified number of seconds have elapsed or when a specified number of bytes have passed through the tunnel. When the SAs terminate, the keys are also discarded. When subsequent IPSec SAs are needed for a flow, IKE performs a new phase 2 and, if necessary, a new phase 1 negotiation. A successful negotiation results in new SAs and new keys. New SAs can be established before the existing SAs expire, so that a given flow can continue uninterrupted.

                              Figure 7 Tunnel termination.

                              • 12. Re: RSA Key
                                Alkuin Melvin

                                Hi Conwyn, thank you very much for the article and your quick response. From the article you given to me, i know there are 5 phase of ipsec to complete. But, i am still curious is the signature key is just used in the beginning when we want to authenticate (IKE Phase 1), and after we have authenticated, we're not using the signature key anymore, instead we're only use the encryption key for sending the data.

                                 

                                 

                                Regards

                                 

                                Melvin

                                • 13. Re: RSA Key
                                  Conwyn

                                  Hi Alkuin

                                   

                                  I think the RSA keys are only used for the key exchange. This produces an agreed secret key which is used for the actual encryption of the data. The reason is public encryption is much slower than secret (symetric) key encryption.

                                   

                                  Regards Conwyn

                                  • 14. Re: RSA Key
                                    Alkuin Melvin

                                    Hi Conwyn, can i use you reference about those 5 phases when we talked about ssh encryption and decryption ? Or those 5 phases are only used when we talked about ipsec vpn ?

                                     

                                    Regards

                                     

                                    Melvin

                                    1 2 Previous Next