 And with the decentralized key distribution we assume each entity has shared a master key up front, manual exchange, and then we have a protocol that allows us to exchange session keys. The problem was the number of master keys that we need to share up front. Let's say we have five users, A, B, C, D and E. How many master keys do we need? We'll exam question or quiz. Ten, why ten? There are five users, there are five entities, so the number of pairs amongst those five entities, we can calculate as five times five minus one divided by two. Five times four divided by two are ten master keys. A has a master key with B, A needs to have a master key with C, D and E. So from A's perspective, the master keys it needs to know, K, A, B. This is a master key, we'll just list the master keys. K, A, C, K, A, D and K, A, E. They would be known by A. Similar B knows K, A, B. We're using one master key for communications in both directions. So there's four, but also we know that B already has a master key with A but needs also separate master keys with C, D and E. Four plus another three master keys, seven so far, C with D and E, another two, nine master keys and finally D and E must have a master key. So there are ten master keys in this small network, simple case. Each user has four master keys. So each user has a master key with the four other users, but in total we have ten master keys. As the number of users grows, the number of master keys in total grows rapidly. Let's show the concept of a centralized approach which will be implemented by the Key Distribution Centre, the KDC, which will see the protocol, but the approach is we still have our five users. The way that I draw them, that is the different location, is not related to the network structure, it's just to make it easier to show the relationship. We introduce a new entity. We have our five normal users and a special entity which will call the Key Distribution Centre, the KDC for short. This will be what we call a trusted third party. It's not a party or an entity involved in the communications between users, that is, A may want to talk to B, C, D or E. They don't want to exchange data with the KDC, they're not involved in the data exchange, they're just involved in the Key Exchange or the Key Distribution and we'll see that they need to be trusted. So we call this a trusted third party. If we don't trust it, we'll see that the scheme will not work. The concept of reducing the number of master keys is that A will exchange a master key with KDC, which I would write as K, A, KDC, but instead of writing K, A, KDC, just to note the master key, KA. The KDC will also have that. B will exchange a master key with a KDC, so will each other entity. So each user will have a single master key, while the KDC will have all of the master keys. B. And now we exchange manually. How many master keys in total? Here with our five users, we just have five master keys. One between each user and this special entity, the KDC. And they will also be manually exchanged. The benefit compared to the decentralized approach is that we have fewer keys that need to be manually exchanged. With decentralized, it was 10 between our five users or N by N minus 1 divided by 2. With centralized, we have just five keys, one per user or simply N. N is the number of users. If we have 1,000 users with the KDC, we have 1,000 master keys. But with decentralized, we'll have 1,000 times 999 divided by 2, about half a million master keys. So this is where the advantage of the centralized approach will come in. We have far fewer master keys that need to be manually exchanged. Once we exchange a master key with a KDC, then we'll see in the next few slides a protocol for distributing a session key. And a session key will be used between a pair of users. For example, A and B want to talk to each other. They need a session key. A and C want to talk to each other and they need a session key. So in both the centralized and decentralized schemes, the same number of session keys are needed, one for each pair. But with centralized, fewer master keys are needed. So we'll introduce the protocol for using the key distribution center. It's a trusted third party. It's another entity in the network we introduce, like a server. And we must trust it. We'll see why shortly. The users manual exchange master keys with a KDC. So that's necessary at the start. And then automatically obtain session keys to communicate with the other users. This shows the protocol for automatically exchanging the session keys. So you will see there are five steps. We'll go through them and then we'll look at some possible attacks or attempts to attack and see how the protocol defeats those attacks. But this doesn't show the exchange of the master keys. Before this takes place, every user has exchanged a master key with a KDC. This just shows the exchange for A and B to share a session key. So we'll go through the steps, explain them, what's known at the front. There must be a master key known by A and B. So initiate A has a master key and this scheme is denoted as KA. So this is before these steps take place. A knows KA. So does the KDC. That's a master key. And B knows KB. We'll see that becomes used. And so does the KDC. So there are two master keys for this exchange. One for A, one for B. And then A wants to talk to B. So to encrypt data between A and B, they're going to use a session key. They don't have a session key yet. So these are the five steps for obtaining that session key. The first three will distribute the session key. We'll see after the first three steps, A and B will have the session key. And the last two adjust, they listed here authentication steps to confirm that everything took place with the right entity. There wasn't some imposter or attacker in the middle trying to pretend to be someone else. So the first step is message number one. And it's between A and the KDC. A wants to communicate with B. So they will need a session key. So they don't contact B. They contact the KDC and say, I am A. I want to talk to B. And I want a session key as the meaning of this message. And it must contain the identity of A and B and a nonce value. Remember, a number used only once like a random number, a time stamp or a counter under the assumption that they're large enough such that they'll not be repeated. Or it will be practically impossible for the attacker to predict what the value is. So we send that first message to the KDC. It can be intercepted. Nothing's encrypted here. The KDC receives it and realizes, OK, A wants to talk to B. The KDC generates the session key. So they choose a random session key, KS. And so after the message two has been sent, the session key will be generated by KDC and sent back in message two. And so we'll add that to the list of what's known by KDC after it receives message one. It generates KS. That's the session key. And it sends it back, but you will see it's actually in two parts here. If you note carefully, there's a concatenation in the middle. So we can see that there's two parts of this message. The first part is here. And then the second part, they just concatenate it together. So we'll separate them into two. The first part shows the session key that was generated. So KDC generates a random number for the session key, KS. It includes it here. And then attaches the initial message. So KS combined with ID A, B and N1. And the idea of including the old message is so that A knows this is a response to the first message it sent. N1 will be included. Let's say N1 was a random number that A generated. It will be included in the response so A can connect this message received with the one it just sent. And it confirms that this session key is for use between A and B only. And this session key, of course, we cannot send it in the clear. It must be encrypted. And the KDC encrypts all of this with KA. So that's the first part of the response. When A receives that response, message two, the first part can be decrypted. It was encrypted with KA. User A knows KA. Therefore, user A can decrypt the first part and it sees. The first part contains ID A, ID B, N1, the value that A sent in the first message, as well as KS. So from the first part, A learns KS. Remember the idea or the aim of this scheme is that A and B both have a shared session key KS. It turns out the KDC also has it. It generated the value. The second message arrives at A. A learns KS, checks the N1 is correct. Note if N1 is wrong, that it doesn't match here, that it doesn't trust the message. We assume it's the same value. The second part in the message sent from KDC to A can A decrypt? Can A see the second part? No. The second part of that message was encrypted with KB. And KB is only known by the KDC and user B. So A cannot decrypt the second part. It doesn't know what's inside. It can guess. It knows the protocol, but it cannot decrypt it. But it doesn't need to decrypt. It simply sends that second part, as is, sends the ciphertext on to B. And if you look closely, message 3 is identical to the second part of message 2. So what happens is that when A receives message 2, they decrypt the first part, learn KS, and simply forward the second part on to B. They don't need to decrypt. They just take that ciphertext and send it on as is. When the third message arrives at B, this is the first time B has heard from anyone, they decrypt. B knows KB. The message was encrypted with KB. When they decrypt, they learn inside of that message, they learn KS. And importantly, they also learn that this KS is for you to communicate with A, because included in this message is the identity of A. And that's the key distribution steps. After message 3, we've achieved our aim of A knowing KS and B knowing KS. The last two steps are just some confirmation to check in the case that an attacker tries to replace the messages or tries to masquerade as someone else. So after message 3, B knows KS. It knows KS is to talk with A because this message included the identity of A. And it trusts this message because it was encrypted with KB and successfully decrypted. The last two steps, B chooses a new nonce value, its own nonce value, N2, say a random number, encrypts it with KS, sends it back to A. If it's the real A, not some imposter in the middle masquerading as A, if it's the real A, they should be able to decrypt because they should also have KS. So A receives message 4 decrypts because they know KS. They have KS. They learn N2 and they send a modification of N2 back to B to confirm. I received message 4 and to prove that I am A and I received message 4, I'm going to send back your same nonce value plus 1 as an example of the function. F of N2 means apply some known function on N2. It may be simply increment by 1. So B sends message 4, A decreases decrypts, message 4 learns N2 and sends an encrypted form of say N2 plus 1, whatever the random number plus 1, encrypts with KS back to B. When B receives message 5, it can decrypt and learns that A must have received my message 4. It's not someone else because they were able to decrypt message 4 and send me back message 5. If it was an imposter in between A and B, so I'm an attacker, they would not have been able to decrypt message 4 because they should not have had KS and if they couldn't decrypt message 4, they couldn't learn N2 and if they can't learn N2, they can't send back the function of N2. They don't know what it is. They can guess but our idea of a nonce value is it cannot be guessed by the attacker. The attacker cannot predict what the value will be. So using a random number or counter there is suggested. At the end result, A and B have a shared session key and they are sure that that session key is actually between A and B. It's not shared between someone in the middle pretending to be A or B. Easy protocol. Any questions on using a KDC? So the question is what if the attacker intercepts 4 and then sends back 5 because B expects that message 5 to come back. If they don't get it, then something has gone wrong. So what could the attacker do? If they wanted to do attack, they intercept message 4. Well, they can't decrypt it unless they know KS. They can't predict N2. Even if they do predict it, they can't encrypt it with KS. So they shouldn't be able to send back message 5 to do that final confirmation. But let's look at some different cases of what the attacker may try to do and see why these five steps allow the user to detect the attack. Before we look at some different attacks, any questions about the steps? What the notation means? So remember we've encrypted these parts with the master keys, KA and KB. When I draw the attacks, I may abbreviate some of them just to save a bit of time and space, but we'll try and draw some scenarios when an attacker is pretending to be someone else. First attack. Let's say we have user A and user A wants to communicate with B. So the first message, if you check, is ID of A, ID of B and N1. That's the very first message. Let's say for the attacker pretends to be the KDC, see what they can do. So instead of being the true KDC here who receives or intercepts this message is the attacker, the imposter here. I will not use M because sometimes in the other pictures we'll use M for the master key. So the imposter, they're masquerading as the KDC here. I will not use A because of the attacker. So here in this attack, the attacker is pretending to be the KDC. What can they send back? Pretending to be the KDC, the five protocol messages, the first one, A sends the identities and the nonce to the KDC, the first one KDC, what's the response? What does I send back? The session key, we've just done message one. What's message two in the diagram? So A expects the messages to follow the protocol sequence. It has just sent message one, so it expects message two to come back. So if the attacker wants to be successful in the attack it must send back a message to initiator A and A must think it came from the KDC. What can we send back? If you look at the general format, message two is some session key combined with the first message. Well the imposter knows what the ID values are. They choose a random session key, they know the ID values, they know N1 and all of that is encrypted. And then in the second part, if you look at the message, the second part of the response is the same KS concatenated with IDA. The attacker chose KS. They chose their own session key. With the hope that maybe A and B will use this session key and then the attacker can decrypt. So the second part is encrypt KS combined with IDA. What does the imposter encrypt this value with? Some key, what key is it not? Which it needs to be. It should be the key of A. It cannot be the key of A because the imposter doesn't know that. So let's say it's just KX and the second part should be encrypted with a key, the master key of B, but the attacker doesn't know the master key. Let's say it's encrypted with KY. When user A receives this message in response, it tries to decrypt the first part, it doesn't decrypt successfully. So we identify something's gone wrong. The attack is unsuccessful because the master key is used to encrypt message to the response. If the attacker tries to pretend to be the KDC, it doesn't know the master key. So that's a simple case. We can't pretend to be the KDC and intercept the first message and try to send back a session key because we don't know the master keys. So this attack doesn't work. What about a man in the middle attack? A slight variation of that one. So we'll look at three or four different scenarios of what if the attacker tries something? Why does it not work? The next scenario, we assume there's some user A, there's a real KDC. A will send the first message to the real KDC, but our imposter will intercept our attacker. The idea in this attack is that A will send message one to KDC, but before it gets there, the imposter will intercept it, learn the values and maybe modify it, send it on to the real KDC with the hope that when the session key comes back, if the imposter can learn the session key, then they can be successful. If they can learn the session key and AMB, don't know that they've learned it, of course. So what I'll try to do is modify that first message. Let's see what they can try. So A sends the first message to the KDC as before, IDA, IDB, and a nonce value. The imposter intercepts what can they do? Let's try if they change one of the IDs. They modify the message. It's not encrypted. Send the same nonce value. They could send a different one. They can change one of the IDs along the way. Let's say the ID was some unique identifier for A and B. They may change that to something else, maybe their own identifier. What could they try? You're malicious. What are you going to try? There's nothing to brute force here. This is nothing encrypted. Let's try if we, say, change the ID of B, keep the original ID of A as the sender, and instead of telling the KDC that this is destined or the exchanges between A and B would change the ID to that of the imposter, ID of I. So that's the value changed. KDC sends back a response. There's two parts, so it's quite long. Encrypt the first part with what? KA, and the first part is the session key and the identities. IDA, ID, what? Good. Let's see what they have. N1. And all that is combined with Encrypt with another key. What's the second part encrypted with? The KDC thinks this communication is between user A and the imposter I. The imposter I has registered its master key, so it will be encrypted with KI here. And what is it? It's the session key, KS, combined with the identity of the initiator. I can decrypt the second part. They learn KS. So they have learned the session key, and that's good from their perspective. That's one of their aims. Learn the session key that A and B are about to use. What happens next? So they can decrypt the second part of this response because it was encrypted with KI. They decrypt that, and they learn KS. Fine. Can they decrypt the first part? No, the first part was encrypted with KA, so the imposter cannot decrypt that. Let's say, of course they need to keep the exchange going. They still need the five messages to complete, so they forward on to user A. A is expecting a response. And this is still the second message. Let's write it all out. The first part is the same as what KDC sent. We can't quantify that. And the second part, we'll see what this key is in a moment. What's going to happen when A receives this response? Thinking it's from the KDC but actually being forwarded on by the imposter I. User A is going to receive the first part. It was encrypted with KA, so they can decrypt it. They decrypt the first part and they say, ah, nice, the session key for user A to be go between user I, there's a problem. When user A sent the first message, they said, I want to communicate with B. But here they get a message coming back from the KDC saying, this is a key to use between you and not B but someone else. So they don't trust this, or at least they're not going to use this session key to communicate with B. Why doesn't I put ID B here? Because they cannot decrypt that part. They don't know KA to decrypt it, meaning that if we modify it, it would not successfully decrypt. So they can't change something that is encrypted that they cannot decrypt. So as a result, user A is going to receive the first part and recognize, ah, that's not what I wanted. I wanted a session key between A and B, but this is a session key between A and imposter I. So don't use that. Now the second part, again, doesn't impact upon that. A will still detect. So the second part is, so it's still encrypted with KAI. So the detection happens because of this value. So two different variations where the imposter tries to pretend to be the KDC. It doesn't work. Any other suggestions of what we can do as the attacker on the KDC? Brute force doesn't work. Let's see what the attacker can try to do to maybe pretend to be between user A and B. After the first two steps have taken place, what can they do in between A and B? Any questions before I move this one? Let's try another case. Let's say the imposter pretends to be user A. We pretend to be user A. We send a message to the KDC. What's the response? We're not right at all. I think it takes a bit much time, but encrypted with KA, KS, and the other parts combined with encrypted with KB, KS, and ID of A. So this is the first two messages. Everything's the same as the normal protocol, but it was sent by user I, the attacker. What can the attacker learn? When they get message two, they can't learn anything about the session key. It was encrypted with KA or KB. So again, they can't learn the session key. They don't have the session key. Can they still try to send a message to B? Let's continue. Even though they don't learn the session key, let's see if they can send a message on to B pretending to be A, the third message. They can send the third message to B. They don't need to decrypt that. The third message is just a copy of the second part of the second message. And be careful there. Even in the normal case, when user A receives the second message, they don't decrypt this part. They don't decrypt this because they can't. They don't have KB. They just forward it on. Let's say it's a thousand bits. They just take those 1,000 bits and send it on to user B. So that's the same as the attacker does here. What does B do? B receives this third message. It's actually the first one that they've heard from. It's the first one they're involved with. This message was encrypted with KB. This is a B here. It's just this part. So they decrypt and they learn KS. And then according to the protocol, they send back a response. Message four in the exchange. Message four, we encrypt with KS, N2. N2 is another nonce value, independently chosen by B. Let's say a random number. What does the imposter do in this case? So these are the normal exchange of messages. The only difference is the imposter is sending them, not user A. The imposter has not learned KS because KS was encrypted with KA and KB and it doesn't have them. But it's continued. It's trying to think that maybe at least from B's perspective, the exchange was successful. They send the third message to B. B thinks, that's all right. I decrypted with KB. I learned KS. So I send back this fourth message, some random number N2 encrypted with KS. Let's say the imposter receives this before the imposter. What if user A, the real user A, received this fourth message? What if the real user A received the fourth message in this exchange? What would they do? You were the real user A and you received this fourth message. What do you do with it? Warned user B? Why? User A didn't send the first message. I will not draw it. If user A received this, it didn't go back to the imposter, then this is strange. This message came out of nowhere. I haven't initiated anything with the KDC. I haven't sent a message to B. So all of a sudden I receive this message. If I try to respond as the real user A, can I? No, because user A doesn't even know KS. User A wasn't involved in the first three messages. They don't know anything about KS, so they can't even decrypt this and learn N2. So if user A gets this, nothing will be able to be sent back and the exchange will fail. What if the imposter gets it? What can they send back? Message 5 needs to be sent to complete the exchange and message 5 encrypt some function of N2 with KS. What's our problem? I don't know N2 and I don't know KS. If I knew KS, I could learn N2. So the imposter still doesn't know KS. This fourth message is encrypted with KS. We cannot decrypt and therefore we cannot send back the fifth message correctly because the fifth message should be N2 plus 1, for example. If I don't know N2, I don't know N2 plus 1 and I can't decrypt that. Even if I could encrypt it, note that there are some attacks, chosen plain text attacks that get that allow us to get a cipher text for some given plain text, even without knowing the key. So there may be in some special cases the way for the imposter to ask someone to encrypt N2 plus 1 with KS. But they don't know N2, so they don't know N2 plus 1. So that's the role of the nonce here. The imposter doesn't know N2. They cannot send back message 5 and B will then disregard this KS. It never gets message 5 back or it gets it wrong and therefore realizes something's gone wrong. So the problem here is that the imposter doesn't know N2. They don't know what to encrypt. They could guess N2 was a random number. So if they guess N2 and add 1, maybe it will work if they can do a chosen plain text attack. But the chance of guessing N2 is practically impossible if we choose a random number with large enough. That's the idea of the nonce value. It cannot be predicted. Any other suggestions to attack this key distribution protocol? I think the main variations we've done in attack are pretending to be the KDC or pretending to be A. You can look at other variations and you'll see that if the imposter tries to pretend to be someone else or even modify messages, it will be detected by one of the entities involved. So this scheme of using the key distribution center is commonly used. It's well suited to large networks especially inside an organization because all the users must trust the KDC. Returning to our diagram showing the keys and what was known. The purple ones were known before the exchange and the grey ones are learned after the exchange. We say the KDC is a trusted third party. What does that mean? When A and B communicate, they encrypt their data with KS. The trusted third party or the KDC can decrypt everything A and B send to each other. A has some data. They want to send that to B. They encrypt using KS. KDC also knows KS so therefore the KDC can decrypt and see the data sent between A and B. This is the problem with this scheme. The KDC must be trusted. The KDC knows all of the keys. So it's useful in an organization where maybe we have some entity that we trust say within SIT all the computers exchange keys using a KDC under the assumption that all of the communications inside SIT we trust or we allow some central server to be able to decrypt all of that. Let's say the business communications so we allow someone else to encrypt our communications between A and B. In the internet maybe such a solution is not so useful because it means that the two users, A and B, must allow someone else to decrypt their data if they want to. So it's a problem that we need to trust that KDC. It's like if we want to allow all the students to communicate securely for all their information about their courses, their private messages, then I give you an application to install on your phone. You all use that and I'm the KDC and therefore I can decrypt all of your personal messages. Do you trust me? You trust me already because you've supplied your password for Moodle. I've got your password already. But with a KDC then we need to have some trust in it and in many large applications we would not trust that. But the benefit of the KDC is far fewer master keys need to be exchanged. To finish this part on how to exchange secrets using symmetric key encryption, we could extend the use of the KDC instead of having a single KDC, we could have multiple. They say one for each department and then have another hierarchy, a top layer KDC that is used between those sub-layer KDC. So you can use it in a hierarchy because one of the problems of the KDC is performance. Let's say we have a thousand users, every time they want to talk to each other they need to contact the KDC. So the server is a bottleneck with respect to performance. To overcome that bottleneck you can have a hierarchy, multiple KDCs. So that was about how to get secrets between users using master keys, a decentralized approach and a centralized approach. The next part is how to get secrets between users by using public key encryption or asymmetric encryption.