Site hosted by Angelfire.com: Build your free website today!

 

 

 

 

 

Session Keys


 

Table of Contents

Table of Contents. 2

Introduction: 3

Modern Encryption Systems and Session-keys: 3

Encryption Using Shared Secret: 4

Enhancing Security by Using Session Keys: 4

Generating and Distributing Session Keys: 5

Generating  Keys Using Diffie-Hellman Key Exchange: 7

Kerberos V4: 8

Distributing Session keys in Kerberos: 8

Using Session key to Obtain Service-Granting Ticket and Session keys for Server-Client communication: 9

Using Client-Server Session Keys to Obtain Service: 9

Limitations of Session-Keys in Kerberos 4 and Improvements in Kerberos 5: 10

Secure Socket Layer: 10

Conclusion: 12

 


 

Introduction:

Session keys, as the name implies, are keys used by communicating parties for the duration of a virtual circuit or transport connection. Session keys can also be termed temporary keys or one-time use keys. Usually after a session, these keys are discarded and not used again This not only saves the master keys to be shared among parties on common medium but also provides securer communications due to always changing shared keys. This paper will look at different systems that rely on shared secret, authenticated public keys such as Diffie-Helman etc. and will study their implementation in various protocols like Kerberos and Secure Socket Layer or SSL.

Modern Encryption Systems and Session-keys:

Encryption techniques can be broadly divided into two categories: single-key encryption and public-key encryption. Single-key encryption, also called as conventional encryption, makes use of a secret key to encrypt and decrypt messages. It remains by far the most commonly used method of the two. Public-key systems use two keys, one public and the other private. Any one of these two keys can be used to encrypt and the other to decrypt.

Modern encryption model can be called a hybrid of public and conventional methods which makes use of both public-key and conventional encryption approaches to establish secure sessions. Modern encryption systems do not share secrets openly on the channel. Instead, session keys are formed for the duration of session and are used for encrypting the data. This is done to avoid using the increased number of resources required to process public keys for each packet of data sent and take advantage of simplicity of conventional methods by generating and sharing new keys on the fly for each session.

Encryption Using Shared Secret:

Two parties sharing a common secret is the most prevalent conventional scheme used for exchanging encrypted data. Previously, the shared key used to be a single secret key that would be used for encryption of all the messages. Though it is a very simple scheme, it suffers from the following disadvantages and hence is not suitable for modern day encryption requirements:

  1. The cipher produced for a given text is same. If same types of messages are exchanged for each session, it becomes increasingly easy for eavesdropper to find the key.
  2. As the number of communicating parties increase, number of shared secret increases. For N parties involved, N(N-1)/2 secrets are required, with the result physical transportation of shared secret becomes a nightmare.
  3. If the sender is unknown, it is too difficult to decrypt the received cipher.

Nowadays, dynamically generated session keys solve most of the above problems as described in the next section.

Enhancing Security by Using Session Keys:

This section shows how session keys are used to enhance security of a system that is based on a static shared secret. Most modern system use this scheme in one form or the other. In a nutshell the scheme says “if A and B each has an encrypted connection to a third party C, then C can deliver a key on the encrypted links to A and B for their use”. The scheme features a Key Distribution Center or KDC. The user or an end system shares a master-key with the KDC. If N users participate in the system there are N keys maintained by KDC instead of n(n-1)/2 as discussed earlier. This key can be distributed e.g. physically to the KDC. Later requirements for encrypting sessions are hence greatly reduced.

Generating and Distributing Session Keys:

Lets assume a party A wants to establish a secure session with party B. To do this, A requires a one-time session key to encrypt the data over the connection. A and KDC share a secret key KA. Similarly, KDC and B share secret key KB. The secure channel establishment goes through following steps:

  1. A issues a request to KDC for a session key for its communication with B. Request message from A to KDC contains: identity of A and B and a unique identifier N1, for this transaction. This unique identifier is referred to as a nonce. This nonce differs in each request and is generated randomly.
  2. The KDC responds back with a message encrypted using KA.  Since only A and KDC share this secret, A knows that the message is authentic. The message for A includes following two items:
    1. The one time session-key Ks, to be used for the session with B
    2. The original request message, including the nonce, to enable A to match this response with the appropriate request.

Thus A can verify that its original request was not altered before reaching the KDC and because of the nonce, it is not a replay of some previous request.

In addition, the KDC message includes two items intended for B (sent to B by A later):

1)      The one-time session key, Ks, to be used for the session

2)      The identifier of A, IDA

 These items to be sent to B are encrypted using KB, hence B will know they have been originated by KDC.

  1. B on getting the message for A, B knows that the other party is A in the session and session keys are authentic. This means the session keys have been securely exchanged between the two parties.
  2. Using the session key Ks, B now encrypts and sends a nonce N2, to A.
  3. Also knowing Ks, A responds with some f(N2).

The above steps not only make sure the original message is not a replay but also authenticate each party to the other.

                          

 

Disadvantages:

 

  1. KDC is required to setup connections between parties. KDC going down means no parties can communicate.
  2. A single KDC is not sufficient for larger networks, a multi-level hierarchy of KDC should be provided.
  3. Should the number of parties grow, the number of N grows up.
  4. Physically transporting keys may be cumbersome.
  5. The scheme does not scale well with connection-less protocols like UDP.

Generating  Keys Using Diffie-Hellman Key Exchange:

Diffie-Hellman key exchange algorithm enables two users to exchange a key securely over the communication channel. The key can then be used by both parties to encrypt and decrypt data. This algorithm is limited to the exchange of the keys. No KDC or central authentication server is required.

Lets assume two parties A and B want to establish a shared secret. Assume there are two publicly known numbers: a prime number q and an integer α, which is a primitive root of q. User A selects a random integer XA < q and computes YA =  α XA  mod q. Similarly, user B independently selects a random integer XB < q and computes YB = α XB  mod q.

Each side keeps the X value private and makes the Y value available publicly to the other side. User A computes the key as K = (YB) XA mod q and user B computer the key as K=(YA) XB mod q. These two calculations produce identical results:

K = (YB) XA mod q

   =  (α XB  mod q) XA mod q

   = (α XB) XA mod q

   = (α XA) XB mod q

   = (α XA  mod q) XB mod q

   = (YA) XB mod q

 Thus, the two sides have exchanged a secret key. Note at the  start of each session, both A and B can come up with a new value for XA and XB.

Disadvantages:

Diffie-Hellman algorithm doesn’t guard against replay attacks. There is no protection that the key must change for all new sessions.

Kerberos V4:

Kerberos is an authentication protocol that is used in distributed environments in which users at workstations wish to access services on servers distributed throughout the network. Using Kerberos, servers are able to restrict access to authorized users and are able to authenticate request for service. Kerberos makes extensive use of Session keys to provide secure channel between the involved parties.

Distributing Session keys in Kerberos:

The first step in any Kerberos authentication is to obtain a ticket-granting ticket. This ticket enables the client to get access to the server (TGS) that grants tickets for using different services. The steps can be summarized as follows:

1)      Client -> Authentication Server: ID of Client || ID of TGS || TimeStamp1

2)      Authentication Server -> Client: Ekc [ Session Key to be used between Client and TGS || ID of TGS || TimeStamp2 || Lifetime2 || Ticket to be used by client to access TGS]

Where,

Ticket to be used by client = Ektgs [ Session key to be used between client and TGS || ID of client || Client Address || ID of TGS || TimeStamp2 || Lifetime2]

The client asks the authentication server (AS) to grant a ticket access to TGS. The AS responds back with a message that contains the ticket. The whole message is encrypted with a key derived from client’s password. The encrypted message also contains session key to be used between the client and TGS for their communications. The session key being encrypted using client’s password as a key, can only be read by the client. Similarly, the same the Session key sent to TGS is encrypted by TGS’s password.

Note that the session keys generated in this process will be used for further encryption.

Using Session key to Obtain Service-Granting Ticket and Session keys for Server-Client communication:

Once the session keys have been obtained from the AS, the client proceeds and sends the ticket to the TGS. As mentioned above, the ticket contains the session key for TGS. Lets see the message exchange in this step of obtaining service-granting ticket from the TGS:

3)      Client->TGS: ID of server V client needs access to || Ticket for TGS || Authenticator Generated by Client to validate ticket

4)      TGS->Client: Encryption Using Session key[ Session key to be used between Client and Server V || ID of server V || TimeStamp4 || Ticket to be used by client to access server V ]

Where,

Ticket to be used by Client to access V =

Encryption using key known to server and TGS[ Key to be used between Client and Server V || ID of client || Address of Client || ID of Server V || TimeStamp4 || Lifetime4]

Hence the TGS in turn issues another Session key that will be used between client and server V that provides the service.

Using Client-Server Session Keys to Obtain Service:

The client now has a reusable service-granting ticket that it can use to access services from server V. When the client presents this ticket it also sends the authenticator. The server can decrypt the ticket, recover the session key and decrypt the authenticator.

5)      Client -> Server: Ticket for using services || Authenticator from Client

The above shows that all sessions are encrypted using session keys. The master keys or password derived keys are only use in the initial stages of connection thus preventing their continuous usage, which can jeopardize their security.

 

Limitations of Session-Keys in Kerberos 4 and Improvements in Kerberos 5:

Though there are many improvements Kerberos 5 makes over version 4 we will limit our discussion to improvements involving Session keys.

In Kerberos 4, each service-ticket includes a session key that is used by the client to encrypt the authenticator sent to the service that is accessible using that ticket. Additionally, the same session key may be used between server and client for other messages back and forth for that session. However, because the same ticket may be used repeatedly to gain service from a particular server, there is a risk that an attacker may replay messages from an old session to the client or the servicing server. In Kerberos 5, it is possible for a client to negotiate a new session-key or a sub-session key for each connection. A new access by the client would result in a new subsession key, thus greatly reducing the risk of replay attacks.

Secure Socket Layer:

SSL makes use of TCP to provide a reliable end-to-end secure service. SSL consists of two layers of protocols, namely, the SSL record protocol and upper layer protocol that include handshake, Cipher Spec and Alert protocol. Instead of discussing full SSL protocol suite we will focus on areas which involve session keys.

The first phase of SSL session establishment features two entities directly related to session keys, Random exchange and CipherSuite.

In phase I, a Random, consisting of a 32-bit timestamp and 28 bytes generated by a secure random number generator, is also sent by both parties to the other. These random nonces are different for both parties but later will be utilized to create a master secret session key.

Phase I of SSL session manily establishes the security capabilities during which Cipher Suite field is used to propose the server of different methods of exchanging keys e.g. RSA, Diffie-Hellman etc. In case of fixed Diffie-Hellman the server’s certificate contains the Diffie-Hellman public parameters, which involves the role of certificate authority that signs these certificates. However to keep things every securer, Ephemeral Diffie-Hellman is used. This technique makes use of Session or ephemeral keys. In this case, Diffie-Hellman public keys are exchanged, signed using sender’s RSA or DSS keys. The receiver can use corresponding public keys to authenticate the signatures. Of the three Diffie-Hellman options, this is the strongest option available. The same technique is also utilized during the Client authentication and key exchange phase of SSL setup.

In the last phase, called Finish phase, of SSL a master Secret key or a Sessoin key exclusively devised for this session is created

The shared master key is a one-time 48-byte value generated for this session by means of secure key exchange. The creation stages include:

1)      A pre-master-secret is exchanged

2)      The master-secret is calculated by both parties

For pre-master-secret there are two options. First is to use RSA during which a 48 byte pre-master key is generated by the client, encrypted with the server’s public RSA key, and sent to the server. Second is Diffie-Hellman in which both parties come up with a share secret key as described in the earlier in this paper.

Both sides now compute the master-secret using MD5 hashing algorithm. This is the stage where the Random generated in the first phase is also taken into account for generating master-secret or Session key.

This use of session key not only identifies each SSL session uniquely but also prevents against replay, man-in-the-middle attacks.

Conclusion:

Session-keys are a crucial part of nearly all modern encryption protocols and key exchanges. The more frequently they are exchanged, the securer the cipher gets. On the other hand, the distribution of session keys delays the start of any exchange and places a burden on network capacity. A security system must try to balance these competing considerations.