Computer Security :: Lessons :: Key Management
For symmetric encryption to work properly, the two interested parties must share the same key, which must be protected from access by others. It is also desirable to frequently change that key to limit the amount of data compromised if an attacker learns the key. The strength of any cryptographic system, therefore, resides in the key distribution technique used to deliver the key to the two parties. Given parties A and B there are four ways a key can be shared:
- A can select a key and physically deliver it to B.
- A third party can select the key and physically deliver it to A and B.
- If A and B have previously and recently used a key, one party can transmit the new key to the other, encrypted using the old key.
- If A and B each has an encrypted connection to a third party C, C can deliver a key on the encrypted links to A and B.
For end-to-end encryption, some variation of the fourth option has been widely adopted. A key distribution center is responsible for distributing keys to pairs of users as needed. Each user must share a unique key with the key distribution center for purposes of key distribution. The use of a key distribution center is based on the use of a hierarchy of keys. At a minimum, two levels of keys are used. Communication between end systems is encrypted using a temporary key known as a session key. Session keys are transmitted in encrypted form, using a master key that is shared by the key distribution center and an end system or user.
The following diagram shows a key distribution scenario. The numbered steps are described below.
- A issues a request to the KDC for a session key to protect a connection to B. The message includes the identity of A and B and a unique identifier, N1, for the transaction, which is referred to as a nonce. The nonce must differ for each request, which is why it is typically a random number.
- The KDC responds with a message encrypted using Ka. A is the only one who can successfully read the message and A knows that it originated at the KDC. The messages includes two items intended for A:
- The one-time session key, Ks.
- The original request message including the nonce to enable A to match this response with the appropriate request.
- The one-time session key, Ks.
- An identifier of A (many times a network address), IDA.
- A stores the session key for use in the upcoming session and forwards B the information originating from the KDC, which is encrypted with Kb. B now knows the session key, the other party, and that the information originated at the KDC.
- Using the new session key for encryption, B sends a nonce, N2 to A.
- Using KS, A responds with f(N2, where f is a function that performs some transformation on N2.
For communication among entities within the same local domain, the local KDC is responsible for key distribution, but if two entities from different domains desire a shared key a global KDC can correspond with the two local KDCs. This concept can be extended to multiple layers. This scheme minimizes the effort involved in master key distribution because most master keys are those shared within a local domain by the local KDC. This limits the range of a faulty or subverted KDC.
A security manager must balance two competed considerations. One consideration is that the more frequently session keys are exchanged the more secure they are. However, the distribution of session keys delays the start of an exchange and places a burden on network capacity.
One choice in this situation is to use the same session key for the length of time a connection is open, using a new key for each session. However, this does not work in connectionless protocols where there is no explicit start/stop for the connection.
One approach to key distribution is illustrated by the following diagram:
Here are the steps involved in the above transparent key control scheme:
- One host transmits a connection request packet to the session security module (SSM) that performs end-to-end encryption and obtains session keys.
- The SSM saves the packet and applies to the KDC for permission to establish the connection.
- The KDC generates the session key and delivers it to the two appropriate SSMs using a unique permanent key for both.
- The requesting SSM can now release the connection request packet and a connection is established.
The above scenario is typical, but if the KDC becomes compromised then all key distribution is compromised. A decentralized key control system requires that each end system be able to communicate in a secure manner with all potential partners for purposes of session key distribution. A session key may be established by the following steps:
- A issues a request to B for a session key and includes a nonce.
- B responds with a message that is encrypted using the shared master key. The response includes the session key, an identifier of B, the function result using A's nonce, and another nonce.
- Using the new session key, A returns the function result using B's nonce.
The concept of a key hierarchy and the use of automated key distribution techniques greatly reduce the number of keys that must be manually managed and distributed. It also may be desirable to impose some control on the way in which automatically distributed keys are used. For example, in addition to separating master keys from session keys, we may wish to define different types of session keys on the basis of use such as:
- Data-encrypting key for general network communication.
- PIN-encrypting key for personal identification numbers (PINs) used in electronic funds transfer and point-of-sale application.
- File-encrypting key for encrypting files stored in publicly accessible locations.
Public-key cryptosystems can be inefficient so they are rarely used for directly encrypting sizable blocks of data. The typical use of a public-key cryptosystem is encrypting secret keys for distribution. The following simple scheme is used if A wishes to communicate with B:
- A generates a public-private key pair and transmits a message to B consisting of the public key and an identifier of A.
- B generates a secret key and transmits it to A, which is encrypted using A's public key.
- A decrypts the secret key using B's public key, which means only A and B will know the key.
- The public keys of both A and B are discarded along with A's private key.
The previous scheme is vulnerable to a man-in-the-middle attack as illustrated by the following:
- A generates a public-private key pair and attempts to transmit a message to B consisting of the public key and an identifier of A.
- The attacker intercepts the message and creates a new public/private key pair. The attacker's identity and public key are transmitted to B.
- B generates a secret key and attempts to transmit it to A, which is encrypted using the attacker's public key.
- The attacker intercepts the message and learns the secret key by decrypting B's message.
- The attacker sends the message to A, but now A, B, and the attacker know the secret key.
Another approach can be used assuming A and B have already exchanged public keys that can help prevent man-in-the-middle attacks:
- A uses B's public key to encrypt a message to B with an identifier and a nonce to uniquely identify the transaction.
- B sends a message to A encrypted with A's public key and containing A's nonce along with a newly-generated nonce from B. Only B could have decrypted A's message so the presence of A's nonce ensures the message is from B.
- A returns B's nonce encrypted using B's public key.
- A selects a secret key and encrypts it using A's private key and then B's public key.
- B decrypts the message to retrieve the secret key.
A final scheme is a hybrid scheme. This scheme retains the use of a key distribution center (KDC) that shares a secret master key with each user and distributes secret session keys encrypted with the master key. A public-key scheme is used to distribute the master keys. This results in greater performance as well as greater reliability.
There are four general techniques that have been proposed for distributing public keys: public announcements, a publicly available directory, a public-key authority, and public-key certificates.
The point of public-key encryption is that the public key is public so a public announcement for sharing a key makes sense. The growing popularity of PGP, which makes use of RSA, has led many users to share their public key in messages they post to community forums online. While this approach is convenient, the major weakness is that anyone could pretend to be user A and broadcast a public key. Until user A discovers the forgery the forger can read all encrypted messages meant for A.
A publicly available dynamic directory can be marinating by a trusted entity or organization. This scheme would include the following elements:
- The authority maintains a directory with a name and public key for each participant.
- Each participant registers a public key with the authority in person or using some form of secure authenticated communication.
- A participant may replace their existing key with a new one at any time.
- Participants could also access the directory electronically through a secure authenticated communication channel.
The directory scheme is better than public announcements, but is still vulnerable if an attacker succeeds in obtaining the private key of the authority.
The following diagram shows how a public-key authority could provide tighter security by better controlling the distribution of public keys in the directory:
- A sends a timestamped message to the public-key authority containing a request for B's current public key.
- The authority sends a message encrypted with the authority's private key (PRauth so A can decrypt it using the authority's public key. The message contains B's public key (PUB), A's original request, and A's original timestamp.
- A uses B's public key to encrypt a message containing A's identifier (IDA) and a nonce (N1).
- B sends a timestamped message to the authority request A's current public key.
- The authority sends a message encrypted with the authority's private key to B. The message contains A's public key (PUA), B's original request, and B's original timestamp.
- B uses A's public key to encrypt a message containing A's nonce and a new nonce (N2). Since only B could have decrypted A's message from step 3 the nonce ensures A that the correspondence is from B.
- A returns B's nonce, which is encrypted using B's public key.
Steps 1 through 5 above do not have to be completed every time in this scheme. A and B can cache their public keys for future use.
A final approach is using certificates that can be used by participants to exchange keys without contacting a public-key authority but in a way that is still as reliable as an authority. The following requirements are necessary for such a scheme:
- Any participant can read a certificate to determine the name and public key of the certificate's owner.
- Any participant can verify that the certificate originated from the certificate authority and is not counterfeit.
- Only the certificate authority can create and update certificates.
- Any participant can verify the expiration date of the certificate.
Each participant applies to the certificate authority and requests a certificate by providing a public key. The authority uses its private key to encrypt a timestamp, an identifier for the participant, and the participant's public key. Any recipient can then use the authority's public key to gain that information. The compromise of the authority's private key is not as serious as it is in other schemes. Certificates contain expiration dates so if they use a compromised key it will only be for a short period of time.
X.509 defines a framework for the provision of authentication services by a directory service known as X.500 to its users. Each certificate in the directory contains the public key of a user and is signed with the private key of a trusted certification authority (CA). X.509 is used in S/MIME for sending email, IP security, and SSL/TLS.
Public-key infrastructure (PKI) is the set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates based on asymmetric cryptography. The figure below shows the interrelationship among the key elements of the PKIX model, which uses X.509 to set up a PKI:
- End entity: A generic term to denote en users.
- Certification authority (CA): The issuer of certificates and certificate revocation lists.
- Registration authority (RA): An optional component that can assume some administrative functions from the CA.
- CRL issuer: An optional component that a CA can delegate to publish certificate revocation lists.
- Repository: A generic term used to denote any method for storing certificates and CRLs so they can be retrieved by end entities.
The PKIX also contains the following management functions:
- Registration: This is the process where a user first makes itself known to a CA prior to that CA issuing a certificate.
- Initialization: Before a client system can operate securely, it is necessary to install key materials that have the appropriate relationship with keys stored elsewhere in the infrastructure.
- Certification: This is the process where the CA issues a certificate for a user's public key.
- Key pair recovery: Key pairs can be used to support digital signature creation and verification, encryption and decryption, or both. There must be some way to recover these key pairs if they are lost.
- Key pair update: All key pairs need to be updated regularly and new certificates issued.
- Revocation request: An authorized person can advise the CA to revoke a certificate.
- Cross certification: Two CAs exchange information used in establishing a cross-certificate.