[Back] A Simple Key Distribution Centre (KDC) has a long-term key generated for Bob and Alice. When Bob and Alice want to communicate, the KDC generates a session key for them and uses their long term key to pass the session key:
Simple Key Distribution Centre (KDC)
One of the most expensive things for a company to resolve is a trust infrastructure breach, and where encryption keys are compromised. Unfortunately, many companies still use PKI (Public Key Infrastructure) for their infrastructure, and where the usage of digital certificates - and their static keys - can cause many problems.
So what is the solution? Well, a Key Distribution Centre (KDC) is one of the best to overcome the nightmare of dealing with digital certificates, especially in a world of IoT (and where you might have billions of devices). Within this, we define a highly secure trust infrastructure, and which will protect the encryption keys that we use:
We need a trusted person - Trent. In this case, let's say that Trent to create a safe deposit box, and for Alice to put some money in, and for Bob to withdraw it. If Alice sends the key in the post, she will not know if Bob has actually received the right key. So Bob and Alice each create a key for a padlock, and then pass the key to Trent. He then gets a request from Alice to create a new key, and he takes Bob's key and takes a picture of Alice, and adds the date on it. He then puts this in a box, and the new secret key. He then locks this box and puts Bob's padlock on it. He then gets another box, and puts the box for Bob into their, along with the new key. He then locks the box, and adds Alice's padlock, and send it to her. She opens it, and takes out the key. She then puts the money in the safe deposit box, and sends the other box to Bob. He opens and checks Alice's photograph, Trent's signature, and date that the photography was taken. He takes the key out, and goes and gets him money:
So let's look at a simple example of the KDC. Within the KDC, Bob and Alice will have a long-term key (KEK - Key Encryption Key) and which is generated for them (or where they register their own long-term key). We can change this key at any time, or have a regular refresh. If Alice wants to communicate with Bob, she sends a request with her ID, and Bob's ID. The KDC then creates a random key and then encrypts it with Alice's KEK, and sends it to her. It will also encrypt the session key with Bob's KEK, and send that to him. Bob and Alice then decrypt the received value with their long-term keys, and they will have the same session key:
Some sample code used is given next. In this case we are just using a 128-bit key, and using MD5 to take a hash of the 128-bit random number:
import hashlib import sys import binascii import Padding import random from Crypto.Cipher import AES from Crypto import Random msg="test" def encrypt(word,key, mode): plaintext=pad(word) encobj = AES.new(key,mode) return(encobj.encrypt(plaintext)) def decrypt(ciphertext,key, mode): encobj = AES.new(key,mode) rtn = encobj.decrypt(ciphertext) return(rtn) def pad(s): return s extra = len(s) % 16 if extra > 0: s = s + (' ' * (16 - extra)) return s rnd = random.randint(1,2**128) keyA= hashlib.md5(str(rnd)).digest() rnd = random.randint(1,2**128) keyB= hashlib.md5(str(rnd)).digest() print 'Long-term Key Alice=',binascii.hexlify(keyA) print 'Long-term Key Bob=',binascii.hexlify(keyB) rnd = random.randint(1,2**128) keySession= hashlib.md5(str(rnd)).hexdigest() ya = encrypt(keySession,keyA,AES.MODE_ECB) yb = encrypt(keySession,keyB,AES.MODE_ECB) print "Encrypted key sent to Alice:",binascii.hexlify(ya) print "Encrypted key sent to Bob:",binascii.hexlify(yb) decipherA = decrypt(ya,keyA,AES.MODE_ECB) decipherB = decrypt(yb,keyB,AES.MODE_ECB) print "Session key:",decipherA print "Session key:",decipherB
A sample run gives:
Long-term Key Alice= 9997205ef32f910d094b11b5f02ffe23 Long-term Key Bob= c2d0b8ac3567ac1f7305d223cecf3cbe Encrypted key sent to Alice: 2c4ebf8e8748cb11065bb3cba7869c1af9d877c08805b2232ad4c7d8b2f987d5 Encrypted key sent to Bob: 8d9d34a0cf2385a328643e83c11f5523b9d241db50d2e534c563dbbac9bb08ba Session key: 0ff7556d5a49f4f84f1b7e7c61c7c869 Session key: 0ff7556d5a49f4f84f1b7e7c61c7c869
We can see that Bob and Alice end up with the same 128-bit encryption key. They can then use that to encrypt their messages. The session key, in the best case, should change for every session, but could stay valid for a given amount of time.
We can enhance the method by sending back Bob’s encrypted session key, and for Alice to pass this onto him. Bob will know if the key is correct, as Alice will not be able to generate the right session key that she encrypts with (and that he can decrypt):
The following is an outline presentation [slides]: