Key management

Key management deals with how secret keys in symmetric key cryptography and public keys in asymmetric key cryptography are distributed and managed.
Topics discussed in this section:

Symmetric-key distribution Asymmetric-key distribution

SYMMETRIC-KEY DISTRIBUTION
Symmetric-key cryptography is where a shared secret key between two people is used in order to communicate with each other. To exchange confidential messages with N people, one needs N different keys. However for N people to communicate with one another, a total of N(N-1)/2 keys are needed

Symmetric-key distribution
Each person in the group of N needs N-1 keys to communicate with the others but because the key are shared we need only N(N-1)/2

However this approach has two problems and they include N2 problem and distribution of keys . This is when the number of required keys for N entities is close to N2 . Since we need N(N-1)/2 keys this means that if we have 1 million people to communicate with each other then each person needs almost 0.5 million keys so in total 1 billion keys are needed.

Weve seen that the number of keys can be a problem plus the distribution of the keys. For example, if Alice wants to communicate with Bob she needs just one key. If she needs to communicate with 1 million people, she will need 1 million keys BUT how can she exchange 1 million secret keys with 1 million people. Efficient ways of maintaining and distributing secret keys are needed and are as follows:

1.Key Distribution Center(KDC)

we need an efficient to maintain and distribute secret keys thats why we use KDC . This is were each person establishes a shared secret key with a trusted party known as the Key Distribution key (KDC) in order to reduce the number of keys needed.

Key Distribution Center: KDC

A secret key is established between the KDC and each member. Process: Alice sends request to KDC, stating that she need a secret session key (temporary) with Bob. KDC informs Bob of Alices request. If Bob agrees, session key is created between the two.

Note

Secret key established by each member at the KDC is used to authenticate each member to the KDC and prevent impersonation from others

Creation of session keys

When KDC creates secret keys for each member, this key is used only between the member and the KDC but not between the two members. For two members to communicate with each other KDC creates a session key using their secret keys at the center, authenticates the members to the center and to each other then establishes a session between them. Once communication is terminated, the session key is no longer valid. NOTE: Session key is used only once per communication

Note

A session symmetric key between two parties is used only once.

Creation of session key between Alice(sender) and Bob(receiver).

Creation of session keys

Step1: Alice sends a plain text message to the KDC requesting a symmetric session key between herself and Bob. Message contains her registered id(Alice), Bobs id(Bob). This message is not encrypted but KDC doesnt mind.

Creation of session keys

Step2: KDC receives the message and creates what is called a ticket. Ticket is encrypted with Bobs key and contains Alices id, Bobs id and the session key. The ticket with a copy of the session key is sent to Alice; she decrypts it and extracts the session key. She can t decrypt Bobs ticket because it is meant for Bob. NOTE: Theres double encryption in this message i.e. ticket and entire message. In this second message Alice is authenticated to the KDC because she is the only one who can decrypt the message.

Creation of session keys

Step3: Alice sends the ticket to Bob then Bob opens the ticket and knows that Alice wants to send messages to him using the specified session key. NOTE: In this message Bob too is authenticated to the KDC because he is the only one who can actually open the message. Since Bob is authenticated to the KDC he is also authenticated to Alice in the same way Alice is authenticated to Bob since they both trust the KDC.

Kerberos
This is an authentication protocol at the same time a KDC that has become very popular. Three servers are involved in the kerberos protocol: Three servers are involved in kerberos protocol Authentication server(AS) Ticket-granting server(TGS) Real Data Server that provides services to others. In our example Bob is he server and Alice is the user

Relationship between kerberos servers

Relationship between kerberos servers

Authentication Server(AS): The AS is the KDC in the kerberos protocol. Each user registers with AS and is granted a user identity and password. AS has a database with all the registered identifications and passwords. AS verifies the user and issues a session key to be used between Alice and TGS and then sends ticket for TGS. Ticket-Granting Server(TGS): Issues ticket for the real server (Bob). It also provides a session key between user(Alice) and receiver(Bob). Kerberos separates user verification from ticket issuing so that user verifies id with AS just once and can later she can contact TGS multiple times to obtain

Relationship between kerberos servers

Real Server: The real server(Bob) provides services to the user(Alice). Kerberos is designed for client/server program such as FTP in which user uses the client process to access server process.

Operation of the Kerberos servers

Operation of kerberos servers cont

Client process(Alice) can access running process running on real server(Bob) in 6 steps: Step1:Alice sends her request to AS in plain text using her registered id. Step2:AS sends a message encrypted with Alice's symmetric key. The message contains two items: session key that is used by Alice to contact TGS and ticket for TGS that is encrypted with the TGS symmetric key . Alice does not know her symmetric key, but when the message arrives, she types her symmetric password. The Password and the appropriate algorithm together create the symmetric key if the password is correct. The password is then immediately destroyed; it is not sent to the network, and it does not stay in the terminal. Process then uses Alices key to decrypt message sent. Both session key and ticket are extracted.

Operation of kerberos servers cont

Step3: Alice now sends three items to TGS. The first is

the ticket received from AS then second is the name of the real server (Bob), the third is a timestamp which is encrypted by the session key. The timestamp prevents a replay by Eve.

Operation of kerberos servers

Step4:Now, TGS sends two tickets, each containing the

session key between Alice and Bob . The ticket for Alice is encrypted with session key ; the ticket for Bob is encrypted with Bob's key . Note Eve cannot extract session key between Alice and Bob because she doesnt know the session key or Bobs key . Step5:Alice sends Bob's ticket with the timestamp encrypted by session key for both Alice and Bob. Step6:Bob confirms the receipt by adding 1 to the timestamp. The message is encrypted with KAB and sent to Alice.

Using different servers: To receive services from different servers, Alice just needs to start from step3 to 6. Verification of her identity need not to be repeated.

ASYMMETRIC(PUBLIC)-KEY DISTRIBUTION
Asymmetric-key cryptography involves two keys; public key and private key To communicate with someone, one only needs the public key of that person Public key is open and available to everyone, however an existing private key is shielded from everyone and is kept private. This public key can be obtained by

Distribution of This is a nave approach to public keys Public Announcement:

announce the key publicly e.g. newspapers, internet, scream the key from the senate building etc. However, this approach is not secure because its subject to forgery and even impersonation. Trusted Center: More secure approach were the keys are kept in a dynamically updateable directory(like telephone directory) by a trusted center . Each user can select private/public key then keeps private key and deliver public key for insertion into the directory. Center requires that each user registered proves their identity.

Announcing a public key

Trusted center

Distribution of public keys

Controlled trusted center: This achieves higher level of security by including a timestamp that is signed by an authority to prevent interception and modification of the response of public key announcements. Example: If Alice wants to know Bobs public-key, she sends a request to the center including Bobs name and timestamp then center responds with Bobs public key, original request and timestamp signed with centers private key. Alice use public key of center that is known by all to decrypt the message and extract Bobs public key. Diagram below

Controlled trusted center

Distribution of public keys

Certificate Authority(CA):CA is a federal or state organization that binds a public key to an entity/person and issues a certificate. The previous approaches can cause a heavy load on the center when the number of requests is large so the alternative is to create public key certificates .

Certificate Authority(CA)
How CA works: Bob wants two things: he wants people to know his public key, and he wants no one to accept a public key forged as his. Bob can go to a CA. The CA has a wellknown public key itself that cannot be forged. The CA checks Bob's identification (using a picture id along with other proof). It then asks Bob for his public key and the puts it on the certificate. To prevent certificate from being forged CA also signs certificate using its private key. After this Bob can upload the signed certificate. If anyone wants Bobs public key, they download the certificate and use the public key of the CA to extract Bobs public key from the certificate. Diagram below

Certification authority

X.509 protocol
Though these certificates solve public key fraud it creates a side effect in that each certificates may have a different format. If one wishes to automatically download certificates belonging to different people, they may not be able to do so because one certificate may have public key in one format then another in another format e.g public keys for different certificates may be on different lines. To solve this, X.509 protocol was designed to describe the certificate in a structured way:

Fields on certificate as structured by X.509 protocol

Version Serial Number Signature Issuer Period of validity Subject Subjects public key Issuer unique identifier Subject unique identifier Extension Encrypted

PUBLIC KEY INFRASTRUCTURE(PKI)

In order to use public keys universally, we cant have only one KDC to answer all the queries. We need many servers and the best solution is to put the servers in a hierarchical relationship with one another. Therefore, the solution to public key queries is a hierarchical structure called Public Key Infrastructure(PKI).

PKI hierarchy

PKI hierarchy
At the first level; we have the root CA that certifies the performance of CAs in the second level Level-1 CAs operate in large geographical or logical areas Level-2 CAs operate in smaller geographical areas.

PKI hierarchy
In this hierarchy everyone trusts the root but people may not trust the intermediate CAs Example: If Alice wants to get Bobs certificate, she may find a CA somewhere to issue the certificate but she may not be trusting that CA. In a hierarchy Alice can ask the next higher CA to certify the original CA she has gone to. The inquiry may go all the way to the root.