Key Management

Key distribution basicsSearch on YouTubeBookmarkSaved

Why key management is hardSearch on YouTubeBookmarkSaved

Key management and key distribution are complex topics. They include three types of issues:

• Cryptographic issues.
• Protocol issues: which party sends which message, and in which order.
• Management issues: who stores, changes and revokes the keys.

The two scheme types have different needs:

Frequent key changes can be desirable. They limit the data that an attacker gets from one broken key.

Distribution alternativesSearch on YouTubeBookmarkSaved

Two parties $A$ and $B$ need a shared symmetric key. The slides give four alternatives:

1. $A$ selects the key and physically delivers it to $B$.
2. A third party selects the key and delivers it to $A$ and $B$.
3. If $A$ and $B$ communicated previously, they use the previous key to encrypt a new key.
4. If $A$ and $B$ each have secure communications with a third party $C$, then $C$ relays the key between $A$ and $B$.

Key hierarchySearch on YouTubeBookmarkSaved

Systems typically use a hierarchy of keys:

The slide figure shows three levels:

• Data gets cryptographic protection from session keys.
• Session keys get cryptographic protection from master keys.
• Master keys get non-cryptographic protection. They can be distributed in a non-cryptographic way, such as physical delivery.

Symmetric keys with a KDCSearch on YouTubeBookmarkSaved

Key distribution scenarioSearch on YouTubeBookmarkSaved

Figure 14.3 shows how a KDC gives a session key $K_s$ to initiator $A$ and responder $B$. $A$ shares master key $K_a$ with the KDC, and $B$ shares $K_b$.

1. $A \to$ KDC: $ID_A \,\Vert\, ID_B \,\Vert\, N_1$. $A$ asks for a session key for $B$ and adds a nonce $N_1$.
2. KDC $\to A$: $E(K_a, [K_s \,\Vert\, ID_A \,\Vert\, ID_B \,\Vert\, N_1]) \,\Vert\, E(K_b, [K_s \,\Vert\, ID_A])$.
3. $A \to B$: $E(K_b, [K_s \,\Vert\, ID_A])$. $A$ forwards the part for $B$. $B$ now has $K_s$ and knows the peer is $A$.
4. $B \to A$: $E(K_s, N_2)$. $B$ sends a new nonce $N_2$ under the session key.
5. $A \to B$: $E(K_s, f(N_2))$. $A$ applies a function $f$ to $N_2$, for example "add 1", and sends the result back.

Steps 1 to 3 are the key distribution steps. Steps 3 to 5 are the authentication steps.

Key distribution issuesSearch on YouTubeBookmarkSaved

• Large networks need hierarchies of KDCs, but the KDCs must trust each other.
• Session key lifetimes must be limited for greater security.
• Automatic key distribution on behalf of users is possible, but the users must trust the system.
• Decentralized key distribution is an alternative to one central KDC.
• Controlling key usage: the system can limit what each key is used for.

Symmetric keys with public keysSearch on YouTubeBookmarkSaved

Why use public keysSearch on YouTubeBookmarkSaved

Public-key cryptosystems are inefficient. Thus they almost never encrypt data directly. They encrypt secret keys for distribution. After the exchange, both sides use fast symmetric encryption for the data.

Merkle's simple schemeSearch on YouTubeBookmarkSaved

Merkle proposed a very simple scheme. It allows secure communications, and no keys exist before or after the exchange.

1. $A \to B$: $PU_a \,\Vert\, ID_A$. $A$ makes a new key pair and sends the public key and her identity.
2. $B \to A$: $E(PU_a, K_s)$. $B$ makes a session key $K_s$ and encrypts it with $PU_a$.

$A$ decrypts with $PR_a$ to get $K_s$. Then $A$ discards $PU_a$ and $PR_a$, and $B$ discards $PU_a$.

Man-in-the-middle attackSearch on YouTubeBookmarkSaved

This very simple scheme is vulnerable to an active man-in-the-middle attack. Figure 14.8 shows the attack by Darth:

1. $A$ sends $PU_a \,\Vert\, ID_A$. Darth intercepts it.
2. Darth makes his own key pair and sends $PU_d \,\Vert\, ID_A$ to $B$.
3. $B$ sends $E(PU_d, K_s)$. Darth intercepts it and computes $K_s = D(PR_d, E(PU_d, K_s))$.
4. Darth sends $E(PU_a, K_s)$ to $A$.

At the end, Alice, Bob and Darth all share $K_s$. Alice and Bob do not know that Darth has the key.

Confidentiality and authenticationSearch on YouTubeBookmarkSaved

This scheme protects against the active attack. $A$ and $B$ already have each other's public keys.

1. $A \to B$: $E(PU_b, [N_1 \,\Vert\, ID_A])$. $A$ sends her identity and a nonce $N_1$.
2. $B \to A$: $E(PU_a, [N_1 \,\Vert\, N_2])$. $B$ returns $N_1$ and adds his nonce $N_2$. Only $B$ can read message 1, so this proves the responder is $B$.
3. $A \to B$: $E(PU_b, N_2)$. $A$ returns $N_2$, so $B$ knows the initiator is $A$.
4. $A \to B$: $E(PU_b, E(PR_a, K_s))$. $A$ signs $K_s$ with her private key and then encrypts it with $B$'s public key.

In step 4, the outer layer gives confidentiality: only $B$ can read $K_s$. The inner layer gives authentication: only $A$ can make that signature.

Hybrid key distributionSearch on YouTubeBookmarkSaved

A hybrid scheme keeps a private-key KDC:

• The KDC shares a secret master key with each user.
• The KDC distributes session keys with the master keys.
• Public-key encryption distributes the master keys. This is especially useful when the users are widely distributed.

The rationale:

• Performance: public-key encryption is slow, so the system uses it only for the rare master key updates.
• Backward compatibility: the existing KDC scheme stays in use with few changes.

Distribution of public keysSearch on YouTubeBookmarkSaved

Four methodsSearch on YouTubeBookmarkSaved

Public announcementSearch on YouTubeBookmarkSaved

Users distribute public keys to recipients or broadcast them to the community at large. For example, users append PGP keys to email messages, or post them to news groups or email lists.

The major weakness is forgery. Anyone can create a key, claim to be someone else, and broadcast it. Until the forgery is discovered, the attacker can masquerade as the claimed user.

Publicly available directorySearch on YouTubeBookmarkSaved

Users get greater security when they register keys with a public directory. The directory must be trusted and must have these properties:

• It contains $\{name, public\text{-}key\}$ entries.
• Participants register securely with the directory.
• Participants can replace their key at any time.
• The directory is periodically published.
• The directory can be accessed electronically.

The directory is still vulnerable to tampering or forgery. For example, an attacker who gets the directory's private key can issue false keys.

Public-key authoritySearch on YouTubeBookmarkSaved

The authority tightens control over the distribution of keys from the directory. It has the properties of the directory. Each user must know the public key of the authority, $PU_{auth}$. Then users get any desired public key from the authority securely.

The slide figure shows seven messages:

1. $A \to$ Authority: $Request \,\Vert\, Time_1$.
2. Authority $\to A$: $E(PR_{auth}, [PU_b \,\Vert\, Request \,\Vert\, Time_1])$.
3. $A \to B$: $E(PU_b, [ID_A \,\Vert\, N_1])$.
4. $B \to$ Authority: $Request \,\Vert\, Time_2$.
5. Authority $\to B$: $E(PR_{auth}, [PU_a \,\Vert\, Request \,\Vert\, Time_2])$.
6. $B \to A$: $E(PU_a, [N_1 \,\Vert\, N_2])$.
7. $A \to B$: $E(PU_b, N_2)$.

The timestamps show that each reply from the authority is fresh. Messages 6 and 7 authenticate $A$ and $B$ to each other.

The method has two problems. It needs real-time access to the directory when keys are necessary. The directory may also be vulnerable to tampering.

Public-key certificatesSearch on YouTubeBookmarkSaved

Certificates allow key exchange without real-time access to the public-key authority.

• A certificate binds an identity to a public key. It usually has other information, such as the period of validity and rights of use.
• A trusted public-key or Certificate Authority (CA) signs all the contents.
• Anyone who knows the public key of the authority can verify the certificate.

X.509 certificatesSearch on YouTubeBookmarkSaved

X.509 authentication serviceSearch on YouTubeBookmarkSaved

• X.509 is part of the CCITT X.500 directory service standards. X.500 uses distributed servers that keep a database of user information.
• X.509 defines a framework for authentication services. The directory can store public-key certificates. Each certificate holds the public key of a user, signed by a certification authority.
• X.509 also defines authentication protocols.
• X.509 uses public-key cryptography and digital signatures. The algorithms are not standardised, but RSA is recommended.
• X.509 certificates are widely used. There are 3 versions.

The slide "X.509 Certificate Use" shows how the CA signs a certificate:

1. The CA computes a hash code $H$ of the unsigned certificate (user ID and the user's public key).
2. The CA signs the hash code with the CA's private key.
3. The CA appends the signature to the certificate.

A recipient verifies the signature with the CA's public key.

Certificate formatSearch on YouTubeBookmarkSaved

A Certification Authority (CA) issues each certificate. The certificate contains these fields:

Obtaining a certificateSearch on YouTubeBookmarkSaved

• Any user with access to the CA can get any certificate from it.
• Only the CA can modify a certificate.
• Certificates cannot be forged, so they can be placed in a public directory.

CA hierarchySearch on YouTubeBookmarkSaved

• If two users share a common CA, they are assumed to know the public key of that CA.
• If not, the CAs must form a hierarchy.
• Certificates link the members of the hierarchy, so a user can validate other CAs.
• Each CA has certificates for its clients (forward) and for its parent (backward).
• Each client trusts the certificates of its parents.
• A user of any CA in the hierarchy can verify a certificate from any other CA in it.

Certificate revocationSearch on YouTubeBookmarkSaved

Each certificate has a period of validity. A CA may need to revoke a certificate before it expires, for example:

1. The private key of the user is compromised.
2. The user is no longer certified by this CA.
3. The certificate of the CA is compromised.

Each CA keeps a list of revoked certificates, the Certificate Revocation List (CRL). Users must check certificates against the CRL of the CA.

The CRL contains the signature algorithm identifier, the issuer name, the "this update" date and the "next update" date. For each revoked certificate, it gives the user certificate serial number and the revocation date. The CA signs the full list.

Version 3 extensionsSearch on YouTubeBookmarkSaved

Users need more information in a certificate, for example email or URL, policy details and usage constraints. Version 3 does not name new fields explicitly. It defines a general extension method. Each extension has:

1. An extension identifier.
2. A criticality indicator.
3. An extension value.

There are three classes of certificate extensions:

Public key infrastructureSearch on YouTubeBookmarkSaved

PKIX modelSearch on YouTubeBookmarkSaved

A Public Key Infrastructure (PKI) is the set of hardware, software, people, policies and procedures that create, manage, store, distribute and revoke certificates. PKIX is the PKI model based on X.509.

The slide figure shows these PKIX parts:

• End entity: the PKI user.
• Registration authority: an optional entity that does some administrative work for the CA.
• Certificate authority: issues certificates and CRLs.
• CRL issuer: an optional entity that publishes CRLs for the CA.
• Certificate/CRL repository: the store from which end entities retrieve certificates and CRLs.

PKIX management functionsSearch on YouTubeBookmarkSaved

1. Registration
2. Initialization
3. Certification
4. Key pair recovery
5. Key pair update
6. Revocation request
7. Cross certification

The end entity uses the first six functions with the RA or CA. Cross certification happens between two CAs.

Quick self-testSearch on YouTubeBookmarkSaved

What are the four key distribution alternatives for symmetric keys?

$A$ selects the key and physically delivers it to $B$. A third party selects the key and delivers it to $A$ and $B$. $A$ and $B$ use a previous key to encrypt a new key. A third party $C$ with secure links to both relays the key.

Compare session keys and master keys.

A session key is temporary. It encrypts data between users for one logical session and is then discarded. A master key encrypts session keys and is shared by a user and the KDC. Master keys get non-cryptographic protection, such as physical delivery.

Give the five messages of the KDC key distribution scenario.

(1) $A \to$ KDC: $ID_A \Vert ID_B \Vert N_1$. (2) KDC $\to A$: $E(K_a, [K_s \Vert ID_A \Vert ID_B \Vert N_1]) \Vert E(K_b, [K_s \Vert ID_A])$. (3) $A \to B$: $E(K_b, [K_s \Vert ID_A])$. (4) $B \to A$: $E(K_s, N_2)$. (5) $A \to B$: $E(K_s, f(N_2))$.

How does Merkle's simple scheme work, and why is it vulnerable?

$A$ sends $PU_a \Vert ID_A$. $B$ returns $E(PU_a, K_s)$. The public key is not authenticated. Darth replaces $PU_a$ with $PU_d$, reads $K_s$, and forwards $E(PU_a, K_s)$ to $A$. Then all three share $K_s$.

Give the four messages of secret key distribution with confidentiality and authentication.

(1) $E(PU_b, [N_1 \Vert ID_A])$. (2) $E(PU_a, [N_1 \Vert N_2])$. (3) $E(PU_b, N_2)$. (4) $E(PU_b, E(PR_a, K_s))$. The outer layer of message 4 gives confidentiality. The inner signature gives authentication.

What is hybrid key distribution and why use it?

A private-key KDC shares a master key with each user and distributes session keys with the master keys. Public-key encryption distributes the master keys. The rationale is performance and backward compatibility.

Compare the four methods of public key distribution.

Public announcement is open to forgery. A public directory is still open to tampering or forgery. A public-key authority needs real-time access. Certificates signed by a CA allow key exchange without real-time access to an authority.

List the fields of an X.509 certificate.

Version, serial number, signature algorithm identifier, issuer name, period of validity, subject name and subject public-key info. Then the issuer and subject unique identifiers (v2+), extensions (v3) and the signature.

When must a CA revoke a certificate, and how do users find out?

There are three cases. The private key of the user is compromised. The user is no longer certified by the CA. The certificate of the CA is compromised. The CA puts the certificate on its CRL. Users check the CRL.

Give the seven PKIX management functions.

Registration, initialization, certification, key pair recovery, key pair update, revocation request and cross certification.