1. CS480 Cryptography and Information Security
6/27/2018
CS480 Cryptography and Information Security
15. Key management
Huiping Guo
Department of Computer Science
California State University, Los Angeles

2. Outline Distribution of symmetric keys Distribution of asymmetric keys
Key-distribution center (KDC)
Using a symmetric-key agreement protocol to create a session key
Distribution of asymmetric keys
Certification authorities for public keys
Public-Key Infrastructure (PKI)

3. Symmetric-key cryptography
Advantages
Symmetric-key cryptography is more efficient than asymmetric-key cryptography for enciphering large messages
Disadvantages
Large number of keys are needed
Symmetric-key cryptography, however, needs a shared secret key between two parties
If Alice needs to exchange confidential message with N people, she needs N different keys
If N people need to communicate with each other, how many keys each people have to keep? How many keys in total?
The distribution of keys is another problem
The sender and the receiver need a way to exchange a secret key
If Alice wants to communicate with 1m people, how can she exchange 1m keys with 1m people
We need an efficient way to maintain and distribute keys

4. Distributing keys in symmetric key schemes
Use Key-Distribution Center (KDC)
Use public key schemes

5. Key-Distribution Center: KDC
To reduce the number of keys, each person establishes a shared secret key with KDC
KAlice: the secret key shared between Alice and KDC

6. Session Keys A KDC creates a secret key for each member.
This secret key can be used only between the member and the KDC, not between two members
If Alice needs to communicate with Bob
A KDC creates a session key between Alice and Bob using their keys with KDC
The keys of Alice and Bob are used to authenticate Alice and Bob to KDC and to each other before the session key is established
After the communication is terminated, the session key is no longer useful
A session symmetric key between two parties is used only once

7. First approach using KDC

8. First approach using KDC
Alice sends KDC
IDAlice||IDBob
KDC sends Alice
EKA(KAB||EKB(IDAlice||IDBob||KAB))
Alice sends Bob
EKB(IDAlice||IDBob||KAB)

9. Problem with this approach
No authentication between Alice and Bob
Replay attack
Eve can save the message in step 3 and replay it later

10. Needham-Schroeder Protocol

11. Needham-Schroeder Protocol
Alice sends KDC
IDAlice||IDBob || RA
KDC sends Alice
EKA(RA|| IDBob ||KAB||EKB(IDAlice||KAB))
Alice sends Bob
EKB(IDAlice||KAB)
Bob sends Alice
EKAB(RB)
EKAB(RB-1)

12. Needham-Schroeder Protocol
RA is used
for KDC authentication
to ensure freshness of the session key
attack (without nonce): Trudy stole the session key from Bob and records old KDC’s reply to Alice; Trudy waits for a new request to KDC from Alice to talk to Bob and plays back old KDC’s reply impersonating KDC
RB is used
for key confirmation and mutual authentication

13. Otway-Rees Protocol

14. Otway-Rees Protocol Alice sends Bob
IDAlice||IDBob|| R || EKA(IDAlice|| IDBob|| R ||RA)
Bob sends KDC
EKA(IDAlice|| IDBob || R ||RA)||EKB(IDAlice|| IDBob || R ||RB)
KDC sends Bob
R ||EKB(RB||KAB) || EKA(RA||KAB)
Bob sends Alice
EKA (RA||KAB)
EKAB(message)

15. Otway-Rees Protocol RA and RB are used to R is used
Provide freshness guarantee for Alice & Bob
Authenticate KDC
R is used
To bind Alice, Bob, and the session.
Having separate RA and RB is not necessary for security, though it’s good for functional separation of nonces and uniformity of KDC messages.

16. Symmetric key agreement
Alice and Bob can create a session key between themselves without using a KDC
This method of session-key creation is referred to as the symmetric-key agreement
Diffie-Hellman Key Agreement

17. Diffie-Hellman Key Agreement
Alice and Bob agree on global parameters:
Large prime integer p
g: a primitive root
Alice generates a key pair
chooses a private key (number): x < p
Compute her public key: R1 = gx mod p
A sends R1 to Bob
Bob generates a key pair
chooses a private key (number): y < p
Compute his public key: R2 = gy mod p
Bob sends R2 to Alice

18. Diffie-Hellman Key Agreement
The Shared session key for Alice and Bob is KAB:
Alice computes
KAB = R2 x mod p
Bob Computes
KAB = R1 y mod p
If Alice and Bob subsequently communicate, they will have the same key as before, unless they choose new public-keys

19. Example Alice & Bob wish to set up a session key:
They Agree on prime p=353 and g=3
Alice
Chooses: x = 97
Computes: R1= gx = 397 mod 353 = 40
Publishes: R1 = 40
Bob
chooses y = 233
Computes: R2 = gy = 3233 mod 353 = 248
Publishes: R2 = 248
Compute the shared session key
Alice: KAB= R2x mod 353 = mod 353 = 160
Bob: KAB= R1y mod 353 = mod 353= 160

20. Public key distribution
In asymmetric-key cryptography, people do not need to know a symmetric shared key
Everyone shields a private key and advertises a public key
Announcing a public key

21. Public key distribution
Problems
It’s subject to forgery
Eve creates a key pair and publicly announced the public key as Bob’s public key
Eve can fool Alice into sending her a message that is intended for Bob
Eve can also sign a document with the corresponding forged private key and make everyone believe it was signed by Bob

22. Trusted center
A more secure approach is to have a trusted center retain a directory of public keys
The directory is dynamically changed
Each user registers in the center, prove his/her identity and inserts his/her public key into the directory
The center publicly advises the directory
The center also responds inquiry about a public key

23. Controlled Trusted Center
Controls are added on the distribution of the public keys to achieve a higher level of security
The public-key announcements can
include a timestamp
be signed by an authority to prevent interception and modification of the response

24. Controlled Trusted Center
Sigcenter(T||PUBob)

25. Certification Authority
The previous approach can create a heavy load on the center if the number of requests is large
The alternative is to create public-key certificates
Bob wants two things
Everyone knows his public key
No one accepts a forged public key as his

26. Certification Authority
Bob goes to a certification authority (CA)
CA binds a public key to an entity and issues a certificate
The CA has a well-known public key
The CA checks Bob’s identification
It asks for Bob’s public key and writes it on the certificate
The CA signs the certificate with his private key
Bob can now publish his certificate
Anyone can use CA’s public key to verify CA’s signature
The public key on the certificate is Bob’s public key

27. Certification Authority

28. X.509
Although the use of a CA solves the problem of public-key fraud, it has created a side-effect
Each certificate may have a different format
X.509 is used to remove the side-effect
X.509 is a way to describe the certificate in a structured way

29. X.509
format of a certificate

30. X.509 Certificate Renewal Each certificate has a period of validity
If there is no problem with the certificate, the CA issues a new certificate before the old one expires.
In some cases a certificate must be revoked before its expiration

31. X.509 Certificate Revocation
In some cases a certificate must be revoked before its expiration
The revocation is done by periodically issuing a certificate revocation list (CRL)
The list contains all revoked certificates that are not expired on the date the CRL is issued
When a user wants to use a certificate, she first needs to check the directory of the corresponding CA fro the last certification revocation list

32. Certificate revocation format

33. Public-Key Infrastructures (PKI)
PKI is a model for creating, distributing and revoking certificates based on X.509

34. Trust Model
It’s not possible to have just one CA issuing al certificates for all users in the world
There should be many CAs, each responsible for creating, storing, issuing and revoking a limited number of certificates.
The trust model defines rules that specify how a user can verify a certificate received from a CA

35. Trust Model
PKI hierarchical model

36. PKI hierarchical model
There is a tree-type structure with a root CA
The root CA has a self-signed, self-issued certificate
The root CA is trusted by other CAs and users for the system to work
PKI uses the following notation to mean the certificate issued by an authority X for entity Y
X<<Y>>

37. CA Hierarchy Use A obtained a certificate from CA X1
6/27/2018
CA Hierarchy Use
A obtained a certificate from CA X1
X1 <<A>>
B obtained a certificate from CA X2
X2 <<B>>
If A doesn’t know the public key of X2, A cannot verify B’s certificate.
If the two CAs have securely exchanged their public keys, A can verify X2’s public key
X1<<X2>>, X2<<X1>>
A gets the certificate of X2 signed by X1.
A gets the certificate of B signed by X2
A uses a chain of certificates to obtain B’s public key
X1 <<X2>> X2 <<B>>
Stallings Figure 14.5 illustrates the use of an X.509 hierarchy to mutually verify clients certificates.
Track chains of certificates:
A acquires B certificate using chain: X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>>
B acquires A certificate using chain: Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>