Key Distribution

CA642: C RYPTOGRAPHY AND N UMBER T HEORY
Symmetric Key Distribution
9.1
Key Management
Keys
There are two main types of key used in cryptography:
Static keys (long-term keys): these are keys which are to be in use for a long
time period. The compromise of a static key is usually considered to be a major
problem.
Session keys (short-term keys): these are keys which have a short life-time, and
are usually used to provide confidentiality for the given time period. The compromise of a session key should only result in the compromise of that sessions
secrecy and it should not affect the long-term security of the system.
A weak key is a key that, when used with a specific cipher, makes the cipher behave in
some undesirable way.
Key Distribution
Possible approaches to key distribution:
Physical distribution: this is not scalable and the security no longer relies solely
on the key.
Distribution using symmetric key protocols.
Distribution using public key protocols.
If we have n users each of whom wish to communicate securely with each other then
secret keys.
we would require n(n1)
2
One solution to this problem is for each user to hold only one key with which they
communicate with a central authority, so n users will only require n keys.
When two users wish to communicate they generate a session key which is only to be
used for that message; this can be generated with the help of the central authority and
a security protocol.
Key Generation
1. We can generate a key at random.
Most cryptographic APIs have facilities to generate keys at random.
These facilities normally avoid weak keys.
2. We can derive a key from a passphrase.
These are pieces of text that can be transformed into a key (usually by
applying a hash function or a cipher).
Geoff Hamilton
They need to be easy to remember, but they should not come from a limited
key space that is easy to search.
They should not be subject to a dictionary attack.
Their big advantage is that they can be easily remembered so keys do not
need to stored.
There are a number of standards for deriving a symmetric key from a
passphrase e.g. PKCS#5.
Key Generation
The key generation may make use of a salt, which is a known random value that is
combined with the passphrase.
With any passphrase system, an attacker can construct a table of possible passphrases
and mount a dictionary attack.
By using a salt, constructing a table of possible keys will be difficult, since there
will be many possible keys for each passphrase.
An attacker will thus be limited to searching through a table of passphrases and
computing the key for the salt that has been used.
The key generation may also require a number of iterations.
This makes the computation of the key less efficient.
An attacker performing an exhaustive search will therefore require more computing resources or more time.
9.2
Key Distribution
Key Distribution Using Symmetric Key Protocols

In the following protocol descriptions, we use the following notation:
Parties/Principals: A, B, S, E.
We assume the two parties who wish to agree a secret are A and B, for Alice
and Bob.
We assume that they use a trusted third party (TTP), denoted by S.
We assume the presence of an attacker E, for Eve.
Shared Secret Keys: Kab , Kbs , Kas .
Kab denotes a secret key known only to A and B.
Nonces: M, N, Na , Nb .
Nonces are numbers used only once; they should be random.
Na denotes a nonce originally produced by the principal A.
Geoff Hamilton
Timestamps: Ta , Tb , Ts .
Ta is a timestamp produced by A.
When timestamps are used we assume that the parties try to keep their
clocks in synchronization using some other protocol.
The statement:
A B : M, A, B, {Na , M, A, B}Kas
means A sends to B the message to the right of the colon consisting of:
a nonce M
the name of the party A
the name of the party B
the message {Na , M, A, B} encrypted under the key Kas which A shares with S,
so the recipient B is unable to read the encrypted part of this message.
We make the following assumptions:
A and B only share secret keys, Kas and Kbs with the trusted third party S.
A and B want to agree a session key Kab for communication between themselves.
This new session key should be fresh i.e. it has not been used by any other party
before and has been recently created.
An attacker can intercept any message over the network, stop it, alter it or change
its destination.
An attacker can distribute their own messages over the network.
9.3
Wide-Mouth Frog Protocol

The Wide-Mouth Frog Protocol is a simple protocol invented by Burrows.
The protocol transfers a key Kab from A to B via S.
It uses only two messages but has a number of drawbacks:
It requires the use of synchronized clocks, which can cause a problem in implementations.
It assumes that A chooses the session key Kab and then transports this key over
to user B.
This implies that user A is trusted by user B to be competent in making and
keeping keys secret.
This is a very strong assumption and the main reason that this protocol is
not used much in real life.
Geoff Hamilton

The protocol can be viewed as follows:

This protocol works as follows:
1. On obtaining the first message the trusted third party S decrypts the last part of
the message and checks that the timestamp is recent.
2. This decrypted message tells S to forward the key to B.
3. If the timestamp is verified to be recent, S encrypts the key along with its own
timestamp and passes this encryption on to B.
4. B decrypts this message and checks the time stamp is recent, and can then recover
both the key Kab and the name A of the person who wants to send this data using
this key.
9.4
Needham-Schroeder Secret-Key Protocol

The Needham-Schroeder Secret Key Protocol was first published in 1978.
A significant feature is that it does not use timestamps and it is the basis for many of
the server-based authentication and key distribution protocols developed after 1978.
One of most highly studied protocols ever; its fame is due to the fact that even a simple
protocol can hide security flaws for a long time.
Serious weaknesses with the freshness of keys have been uncovered.
Objectives:
1. To allow A and B to be authenticated.
Geoff Hamilton
2. To allow S to generate a session key Kab that is bound to the authentication

process and is only known to A, B and S.
Needham-Schroeder Secret-KeyProtocol

1. A sends its identity, the identity B of the entity it wishes to communicate with
and a nonce Na to the server S.
2. S performs the following steps:
It generates a session key Kab for use by A and B.
It constructs Bs token {Kab , A}Kbs that only B can decrypt.
It constructs As token {Na , B, Kab , {Kab , A}Kbs }Kas that contains Bs token
and that only A can decrypt.
It sends As token to A.
3. A performs the following steps:
It decrypts its token received from S using the key Kas that it shares with S.
It checks the nonce Na and name B in the token are the same as those sent
to S in step 1.
It records the session key Kab for future use.
It relays Bs token to B.
Geoff Hamilton

4. B performs the following steps:
It decrypts its token received from S via A using the key Kbs that it shares
with S.
It records the session key Kab for future use.
It challenges A by sending a nonce Nb encrypted using the session key Kab .
5. A performs the following steps:
It decrypts the message sent from B using the session key Kab and checks
that the result is the nonce Nb . Note that this requires Nb to be redundant.
It then encrypts the value Nb 1 using the session key and sends it to B.
Finally, B decrypts the message sent by A in step 5 and checks that the result is Nb 1.
Analysis:
This protocol provides mutual authentication of A and B, and allows a session
key generated by S to be shared by A and B.
The server S must be trusted; it has access to all keys.
In step 1 we use a nonce Na to prevent a replay attack i.e. A checks that Na
appears in the token returned by S in step 2.
In step 1, A identifies itself and the entity B it wishes to communicate with.
Since this message is not protected in any way, an attacker could substitute its
own identity for B. Provided the attacker could also intercept messages 3-5, it
could impersonate B to A.
This attack is prevented by S including the identity of the other party in
As token i.e. A checks that S has supplied information that allows A to
authenticate B.
After step 2, A knows that S has participated in this run of the protocol and that
Kab is fresh.
After step 3, A and B have a shared session key Kab . Clearly, S knows this key,
but because it was protected using Kas and Kbs , no other entity knows the key.
We trust S not to misbehave.
After step 3, B knows that Kab is a key shared by A and itself. However, B does
not know if Kab is fresh.
Geoff Hamilton
In steps 4 and 5, A and B perform mutual authentication i.e. they prove to each
other that they have the session key and that they are participating in this run of
the protocol.
The nonce Nb needs to be redundant so an attacker cannot replace the message in step 4 with some arbitrary ciphertext.
In step 5, A encrypts Nb 1 since the encryption of Nb is already available.
Note that A can repeat steps 3-5 as often as it wants i.e. it can use the same
session key for multiple communications.
Attack 1: Compromised Session Keys
Assume that an adversary E observes a legitimate protocol exchange between A
and B.
E can capture Bs encrypted token in step 3 of the protocol.
If E can compromise the session key Kab , then E can follow steps 3-5 of the
protocol and impersonate A to B.
Note that E can take as long as it wants to compromise the session key.
So even though determining the session key may be computationally hard,
the design of this protocol gives an adversary an unnecessarily long time to
attempt to find the key.
Attack 2: Compromised Server/User Keys
If the key Kas that a user A shares with the server S is compromised, then an
adversary E can use steps 1-2 of the protocol to obtain session keys and tokens
for as many other users as it wishes.
E can then impersonate A to one of these users at any time by completing steps
3-5 of the protocol.
Even if A determines that the key Kas has been compromised and generates a
new key, E can still use the session keys and tokens that it obtained earlier.
The problem with this protocol is that B has no way of knowing if the session
key is fresh.
There are two ways of resolving this problem:
1. Have B interact with the server S so that it knows that the server is participating in the protocol.
Geoff Hamilton
In the existing protocol, steps 1-2 effectively authenticate S to A since

S is encrypting fresh data with the shared secret key Kas .
This was done in an expanded version of the Needham-Schroeder protocol. However, we will look at an improved protocol due to Otway
and Rees.
2. Include timestamps so that B can ascertain the freshness of the session key.
Kerberos does this by adding a validity period or lifetime for each
session key.
9.5
Otway-Rees Protocol
Otway-Rees Protocol
Otway-Rees gives freshness guarantees without using synchronized clocks.
Again, let us assume that:
We have a trusted server S.
Two users A and B who share secret keys Kas and Kbs respectively with S.
Objectives:
1. To allow A and B to be authenticated.
2. To allow S to generate a session key Kab that is bound to the authentication
process and is only known to A, B and S.
Otway-Rees Protocol
Geoff Hamilton
Otway-Rees Protocol
Analysis:
In this protocol both A and B perform mutual authentication with the server S
and S returns the session key Kab to each.
In the case of A we have:
S can authenticate A by decrypting {Na , M, A, B}Kas it receives in step 2.
A can authenticate S and obtain its copy of the session key by decrypting
{Na , Kab }Kas in step 4.
How does S ensure that the message from step 1 is not a replay?
Actually it cant!
However, this is okay, because an attacker replaying the message will
be unable to recover the session key Kab in step 4.
In this protocol, B relays messages to/from A. However, since these messages are encrypted using Kas , B cannot decrypt or modify them.
In the case of B we have a similar argument with {Nb , M, A, B}Kbs and {Nb , Kab }Kbs
Otway-Rees Protocol
In step 1, A generates two nonces:
Na which is used to prevent replay of Ss message back to A and guarantee
the freshness of the session key received from S.
The nonce Nb serves the same purpose for B.
M which acts as a transaction identifier that binds the information sent by
A and B together:
S can check that {Na , M, A, B}Kas and {Nb , M, A, B}Kbs have the same
value for M and therefore belong to the same transaction.
After the protocol has completed, A and B will share the key Kab .
If A and B use Kab to encrypt a communication, then they both have
ongoing mutual authentication.
9.6
Kerberos
Kerberos
Kerberos is a complete server-based authentication and key distribution system based
on the Needham-Schroeder protocol.
The main differences lie in the use of timestamps and lifetimes.
It was developed as part of project Athena at MIT and has been widely used in Unix
networks. The current version is 5.1.
It has been incorporated into Windows 2000.
Geoff Hamilton
10
Since it uses timestamps and lifetimes, there is a need for secure, synchronized clocks.
On a local area network (Unix, Windows 2000, Netware, ...) this is relatively easy to
implement.
As with Needham-Schroeder, entities share secret keys with a trusted Kerberos server.
Kerberos
Kerberos uses its own terminology:
The trusted server S is known as a Key Distribution Centre (KDC).
When a client A wishes to use a computing service B, the KDC issues a ticket
that can be used to access the services of B.
As we will see, this is essentially Bs token in the original Needham-Schroeder
protocol.
Tickets have a specific lifetime, but they can be renewed, post-dated, etc.
A significant use of Kerberos is to allow human users to logon to computer networks
and access computing services distributed throughout that network.
Kerberos also defines the precise syntax of the various protocols, but since we are only
interested in an abstract view of Kerberos, we will ignore such detail.
Kerberos
Geoff Hamilton
11
Kerberos
1. This step is similar to Needham-Schroeder in which A indicates to S that it wishes
to communicate with B; a nonce can also be used here to prevent a replay attack.
2. If S allows this access then a ticket {TS , L, Kab , A} is created; this is similar to the
token used in Needham-Shroeder. This is encrypted under Kbs and sent to A for
forwarding to B. A also gets a copy of the key in a readable form.
3. A wants to verify that the ticket is valid and that B is alive. A sends an encrypted
nonce/timestamp TA to B.
4. B sends back the encryption of TA + 1, after checking that the timestamp TA is
recent, thus proving B knows the key and is alive.
Geoff Hamilton

Key Distribution

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Key Distribution

Uploaded by

Copyright:

Available Formats

CA642: C RYPTOGRAPHY AND N UMBER T HEORY

Symmetric Key Distribution

CA642: C RYPTOGRAPHY AND N UMBER T HEORY