 And we're focusing on how to distribute shared secret keys or symmetric keys. So again, symmetric key cryptography, like AES, triple desks, both sides need the same key. And for that to work, we somehow need to, what usually happens is one side chooses a key, say a random key, and then gives it to the other side. But when we give it to the other side, we must make sure that no one can intercept and find that key. So the problem is, how do we distribute a shared secret key or a symmetric key across a network? Or the approaches we're looking at currently are using symmetric key encryption. Generate a shared secret key and encrypt it before we send it to the other side. Encrypt it using symmetric key encryption. But we have this recursive problem. If I need to encrypt my shared secret key with another shared secret key, how do we get that other shared secret key to the other side? We'll encrypt it with another shared secret key. But how do we get that to the other side? So we have this recursive problem. And the way that we solve it is we assume that some of the secret keys are manually distributed. By manually, it may be I write it down on a piece of paper and I go to the other person today and give them the shared secret key. And then later, we use that key to encrypt a new key. And we can do that second step automatically by sending packets across the network. So there's the manual distribution. And it may not be writing on a piece of paper. It may be taking a USB disk to a special computer, which copies across the key in a manual step. But then after that, we use that key to encrypt other keys. And with that, we arise two different types of keys. We talk about master and session keys. So we'll distinguish. We'll say a master key is one that we'll use to encrypt another key. And that other key we'll refer to as a session key. So usually the master keys exchange manually. So I need a master key shared with someone else. We'll come together and exchange that master key manually. But then we will use that master key to encrypt a session key and exchange it automatically across the network by some protocol that does it on our behalf, our computers do it. And then when we want to encrypt the data, we encrypt the data with a session key. So encrypt session keys with the master key, encrypt your data with a session key, this hierarchy of keys. And you could have multiple, more than two levels if you want. The idea is that the master key, it's very inconvenient to exchange because of the manual process, but we don't do it very often. So it's not so bad. We only do it say once at the start of the system. We come together between two users and exchange a master key. We keep that master key, but then we use it to exchange automatically a session key and we can change that session key on a regular basis. So let's say every day we change the session key. That's to achieve this principle, don't use the same key forever. Use it, change it as often as possible. So session keys will exchange using some protocol. So our software on our computer will automatically exchange with the other computer and will usually change on a regular basis. Master keys that we exchange manually and not so regular as few times as possible. How regular? What is the lifetime of a session key? Well, it depends upon different factors. So different applications or systems will use a different lifetime. But the trade-offs are, coming back to one of our earlier principles, the less, the more we use a key, the greater the chance for the attacker for discovering the key. That was one of our earlier principles. So from that we say the shorter the lifetime of a key, the less we use it, the more secure. So we want a short lifetime for security purposes. In other words, I'd like to change the session key as often as possible. But the problem with that is that every time we need to change session keys, there must be some exchange of messages to do that. There's some protocol that takes place and introduces some communication overhead as well as some small delay in our communication. So change the session key as often as possible to be more secure, but not too often such that the overhead of doing it is too much. Some examples of how session keys are changed. For example, you have an application that uses TCP. Like web browsing, email, file transfer, they use TCP. And we know with TCP, before you send data, you set up a connection. How do you set up a TCP connection? What's it called? Three-way handshake, sin, sin, act, act. I know you're learning it. You've learned it with Dr. Conwood, okay? You're experts on TCP. You set up a connection and then you send data. And then when you finish sending data, you close the connection with what? How do you close a TCP connection? What type of message? Fin for finish, okay? There's a special fin message in TCP to finish a connection. And then if we want to communicate between the same application to the same server, we'd open another connection, exchange our data, and then close the connection. So in TCP, we have concepts of connections. For example, if I want to send an email from my computer to the email server, then my computer will create a TCP connection, send the email, then close the connection. Or if I want to download a web page from a web server, my computer will create a TCP connection to the web server, request the web page, receive the web page, and then close the connection. So the connections are usually short-lived. Depends on the application, but maybe seconds, minutes, maybe they are longer in some cases. But often they're quite short, seconds, minutes, maybe hours. So one way to change keys is for every TCP connection. That is, I want to encrypt the data I'm sending using TCP. Then what I do is I create a new session key for each TCP connection. I connect to the web server to download a web page. For that request that I send to the web server and the response I get back, I will use one session key for the encryption between me and the web server. Then I close my TCP connection, and maybe a few minutes later, I access the same web server, download another web page. So when I create the new TCP connection, I will get a new session key, and encrypt with a different key in this case. So one common way to consider the lifetime of session keys is related to the protocols being used. For example, TCP has connections. So every TCP connection use a new session key, or it could be over a set of connections. UDP, how does UDP work? Is there a three-way handshake? UDP is much, much simpler than TCP. You just send the packets. There's no concept of a connection in UDP. I just send the packet to the server. So in that case, if we consider what's called connection less protocols, then we cannot correspond the session key with the duration of the connection. We usually may have some fixed period or some certain number of packets. That is, I'm sending UDP packets. Every five minutes, create a new session key. Or every 1,000 packets I send, create a new session key. That could be set up with connection less protocols. With the trade-off being the more times we change the key, the better for security, but the larger the overhead of doing so. Because changing a key involves sending some packets across the network. What do we skip over here? This principle, change keys frequently. And we, last lecture, looked at one way to exchange a key in a decentralized approach. And today we'll look at a centralized approach. So just, we went through the notation in this picture. We had the decentralized approach. This assumed that the master keys were already exchanged. Before we send these three packets, A already knows the master key that it shares with B, and B also knows. Somehow, A and B got together in the past and exchanged one master key. In this picture it's denoted as KM, the master key between A and B. So assuming we have a master key, then this scheme is used to exchange a session key. And the steps were A sends its identity and a nonce value to B, a number we use only once. B responds by encrypting a session key, KS, as well as the identities and the nonce values, encrypting that with the master key. Only A can decrypt that because only A has the master key. No one else does. No one, the intercepts can decrypt. And finally, A responds by confirming just a final confirmation that we've received it, like an acknowledgement, encrypting the nonce value. We said some function of the nonce. Let's just say increment by one. It doesn't have to be complex with a session key. These three steps are to exchange a session key. So we may do this now, and then five minutes later we may repeat these three steps with a new session key. But still using the same master key. And then five minutes later do it again. New session key using the old master key to encrypt that. With the AIM, the session key is only used for a short period of time before we change it. And the master key is not used very often. It's only used when we apply these three steps. We only use the master key in one case here, here. So let's say every five minutes we do these steps. We're only using the master key once every five minutes. So this principle. Don't use the same key too often. The advantage of this, compared to the next approach we'll go through, is it's decentralized. The two entities, A and B, do it between each other. They don't rely on another entity, a third party. There's no central entity involved. The problem with this is the number of master keys that need to be manually exchanged. We looked at that case in a bit of detail, but let's just look at the number of keys. I think we calculated, but a simpler case to start today. We have, instead of A and B, let's say we have A, B, C and D. Three entities in our system. And we want to use this decentralized scheme. How many master keys do we need in the system? Not to the power of, well let's list them. How many master keys? Remember the master keys are exchanged manually, and we want to do that as little as possible, so we want to have as few as possible master keys, because it's very inconvenient to exchange them. So if A wants to communicate with B, they need a shared master key. I'll list it. Maybe we'll call it KAB. That's the master key between A and B. So the master keys, if A wants to communicate with B, they'll need to exchange a master key. If A wants to communicate with C, they would need a separate master key, and with A and D. If B wants to communicate with A, we already have a master key, KAB. In both directions we can use the same master key. But B wants to talk to C. They'll need a master key. Or B with D. And last one, C's already got a shared master key with B and A, but we'll need one with D. And D now has, in this list, master keys shared with A, B and C. So a total of six keys, if we have four entities. And you know the equation for calculating that with N entities. It's N times N minus 1 divided by 2. 4 times 3 divided by 2 gives us our six keys needed. There are six pairs, in this case. But if we have 100 users, not just 4, then it becomes 100 times 99 divided by 2, which is about 5,000 master keys needed. And that requires a lot of effort to exchange them, a lot of manual effort. So that starts to become inconvenient. So that's the problem with this decentralized scheme. Lots of master keys needed. So let's look at a centralized scheme that tries to overcome that problem. We'll use a central entity called a key distribution center, a KDC. Think of some special server that will distribute keys to the users, to the entities. We call the KDC a trusted third party. It's a third party. It's someone who's not normally involved in the data communications. They're just there to support the key distribution. And they are trusted. We'll see that the other users must trust this KDC. By trust, we'll see that the KDC will know the keys of other users. We'll see that as we go through the protocol. And we use the KDC by first manually exchanging a master key between each user and the KDC. So that's the manual step. And then when a pair of users want to communicate, A wants to talk to B, then they will exchange a session key between A and B but making use of the KDC. So the master keys are manually exchanged while the session keys are automatically exchanged. But we'll see, compared to the decentralized approach, much fewer master keys are necessary. We can see that immediately, in fact. Similar approach. Instead of exchanging master keys between each pair of entities with KDC, I'll draw it slightly differently with... So that was the decentralized approach. There's no central server or distributed approach. Let's try a centralized approach. And keep it simple. We still have A, B, C and D, four users. They want to be able to communicate with anyone. We also have a fifth entity, the trust of third party, the KDC, the key distribution center. The manual exchange of master keys is done between each user and the KDC. So between A and the KDC, we exchange a master key. And let me just confirm the notation we'll use. In the picture that we'll show in a moment, we'll call that key KA. So master, we'll just call it KA, meaning the master key exchange between A and the KDC. User B will exchange a master key with KDC. So with C and D. And then when, for example, A wants to talk to B, they'll automatically will see the protocol for A to exchange a session key with B. And the data that's sent between A and B will encrypted with that session key. How many master keys? In the centralized approach, we just need four master keys. In decentralized, we had six. In general, the decentralized approach, the general equation was N by N minus 1 divided by 2. If there are N users, N by N minus 1 divided by 2 master keys. In the centralized approach, how many master keys? If there are N users, we will need N master keys. Here we have four. We have four users, four master keys. If we had 100 users, there'll be 100 master keys. If we have 100 users in the decentralized approach, there's about 5,000 master keys. And you see that the advantage of the centralized approach is much, much fewer master keys need to be manually exchanged. So that's the good thing here. So what we'll look at next is that once we've exchanged master keys using a manual procedure, how do A and B exchange a session key using an automatic procedure? Using some network protocol, for example. What messages do they send to do that? So we'll assume that A knows KA. Let's list them here. Actually, we'll go back to decentralized. In the decentralized approach, what master keys does A know in this one? What master keys does it know? It knows KAB, KAC, and KAD. Everyone that we share with. Similar, B knows KAB, KBC, and KBD. We know the master keys that you're involved with the pair with. A does not know KCD, because A is not involved in that pair. It cannot know what they're using, and therefore A will not be able to intercept and decrypt messages encrypted with KCD. Now, in the centralized approach, what key does user A know, KA? That is shared with the KDC, so the KDC also knows that. B knows KAB, so does the KDC, and D knows its own master key, which is shared with the KDC. The point here is that each user just knows their own master key, but the KDC knows every user's master key. And this is why we say it's a trusted third party, because the KDC knows everyone's key. It can see what anyone else does. We'll see that when A wants to exchange a session key with B, the KDC will be able to decrypt that. The KDC will be able to intercept, if it wants to, the messages between A and B. So we must trust the KDC, that we know that they can intercept our messages and see the content. That's why we call it a trusted third party, which leads to one of the problems with this approach. If the KDC is compromised, then the whole system is compromised. Because if we trust the KDC, but then some malicious user gets access to the KDC, they have access to all of the user's keys, that's the problem. We'll return to that after we go through the protocol of A sharing a session key with B. Any questions before we look at this protocol? Here it is. So this is the automatic part. This is the part which is done by sending messages across the network between the three entities now. A and B. A wants to initiate communications to B. So A wants to send some data to B, and B probably will want to respond with data. So to do that, A and B need a shared session key. They both already have master keys, but they'll need a session key that they'll use to encrypt their data. And to get that session key, they follow these five steps. And we'll just make note of what we know in these five steps. Before these five steps take place, what is known by each entity? This happens after the manual exchange of master keys. So the master key known by A at the start is KA. And known by B is KB. And the KDC also knows KA and KB. That's known before these five steps. The aim is for A and B to have a session key. And in this protocol it will be denoted as KS. To be more precise, we could call it something like KS between A and B. What happens? The steps are numbered 1, 2, 3, 4, 5. So the first step, A wants to initiate communications with B. What they do is they first contact the KDC. They send a message to the KDC, IMA. I want to talk to B. And here's a nonce value. Let's say some random number that we haven't used recently. There's a high probability that we haven't used this number in sending such a message to the KDC in the past. Now, in practice, it would have been used in the past, but in most cases, but maybe a long time ago or very, very unlikely that this one's been used recently. So N1 is what we call a nonce. And the KDC receives this message and realizes, ah, A wants to talk to B. So they will need a session key. And what the KDC does, because it knows the master key of both A and B, it will create a session key, KS, and send it back in message 2 to A. But in a particular format, which we see here. So the KDC creates a session key. So I'll add that to the list of what's known now. KDC chooses KS. And in the message that they respond, there's really two parts, and it's all encrypted. So the first part is this, if you can see this part here. This is, if we look at the contents, it's the session key, KS, combined with the identity of A, the identity of B, and the nonce value from the first message. So this is a message that is going to go back to A and say, okay, you just requested a session key between A and B. The request contained nonce value 1, N1. Here's my response. Here is the session key, KS. And here are the values that you sent me in message 1. And so that no one can intercept and see the session key, all of that is encrypted with KA. KDC sends to A, and therefore encrypts with a key it shared with KA. The purpose of including the contents from message 1 is so that when A receives this, it knows this is a response to my previous request. And we may see later that if someone does a replay of the first message, then we'll normally be able to detect a replay attack on that. Because in a replay of the message, a new one, a fresh message, should use a different nonce value. If it's a replay, it will contain the same nonce value and we'll be able to detect that. So, user A can decrypt this part. It was encrypted with KA, A knows KA, therefore they can decrypt it. And when user A receives this part, they decrypt it and learn KS. So on reception of message 2, A now knows KS. The second part of message 2. This is KS combined with the identity of A, but encrypted with KB. Can A decrypt that? Why can't they? Encrypted with KB, only B can decrypt that. So the second part, even though it's sent to A, A cannot decrypt it. What's going to happen is in the third message, it will be forwarded on to B. So it contains the same session key, KS, and it contains the identity of A, the one who initiated this, but encrypted with KB. A does not know KB. It doesn't need to for this to work, and it shouldn't. So in the third message, if you look at the third message and compare it to the second, it's the second part. All A does, they cannot decrypt it, they just really copy and paste that part and send it in the third message. It's identical. When B receives the third message, it decrypts. B knows KB. When it decrypts, it learns KS. And it checks. KS is for me, B, to communicate with A, user A. It knows it's with user A, because the identity of A is included in that message. So B knows this session key is for me to use with A, and A only, not others. B gets that session key, and effectively now we've achieved our aim. Our aim was get a session key between A and B, and we've done that. A and B both know KS. Let's look at some things in terms of the attacker. Can the attacker see KS in the third message? Some other user that intercepts all messages. If you look at the third message, can another user see KS? No, why not? They don't know KB. Only B in the KDC knows KB. So the session key in the third message is confidential. In the second message is the session key confidential. Again, yes, KS encrypted with KB. Only B can decrypt that. KS encrypted with KA. Only A can decrypt that. So a third user, say C, cannot find the session key, because it's been encrypted with the master keys. So the session key is confidential, which is what we want. The last two steps are just some confirmation messages to be sure that this message is between the right pair of users. When B receives message three, it replies. It replies using KS to encrypt some other nonce value N2. B chooses a random number. N2 encrypts it with KS, sends it to A. Only A can decrypt that. Is that true? Who else can decrypt message four? B sends it. A can decrypt. Who else can decrypt? Anyone? The KDC can decrypt this. Remember, the KDC knows KS. But we trust the KDC. It's like, if I'm the KDC in the network, you trust me. You don't care if I decrypt all your messages? Well, in some cases. So the attacker cannot decrypt the fourth message. So they will not learn N2. And the final fifth message is the user A really confirms the reception of that fourth message saying, thank you for the fourth message, N2. And we apply a function on N2, which is, say, increment it by one. So if N2 was a random number, the attacker would not be able to learn that. They can't guess the random number if it's large enough. They cannot decrypt. And A increments that, say by one, applies a function and sends it back, and the responder checks, okay, I sent some random number to A. If we receive a response which decrypts and we get that random number plus one, then this confirms that we are communicating with A. Because only A could have decrypted this to learn the random number. Similar, when A receives message four, A knows it's communicating with B. Because the only person who can encrypt with KS is B in that case. So we use those last two steps to confirm who we're talking to. We may see them what happens if we have an attack shortly. So before this procedure, we assume we have master keys known by A and B. At the end of the procedure, we also learn the session key, KS. And our trusted third party also knows the session key. Now put on your attacking hats. What can you do as an attacker to try and defeat this scheme? Either learn KS or fool one of the others into thinking it's got the correct message which it's been modified or repeated. Can the attacker learn KS? KS, if we check, is encrypted with KB and KE, a KA in all of these messages. So the attacker cannot learn it unless they know KA or KB. So KS is confidential, that's good. So the other aspect of an attack we may look at is can the attacker, for example, replay or send a message and fool one of the other entities into thinking it's from the original entity? Let's try some different cases. And we'll not draw them, we'll just look at most of them quite simple. What if an attacker sent the first message pretending to be A? That is, the first message is not sent by A but some malicious user, but the contents of the message are IDA, IDB, N1. Can the attacker receive the response? Yes, the KDC will receive it. It doesn't know it's not from A. The identity says A. So it's from A. The response that comes back, can the attacker decrypt the response? No, because if this is the identity of A and the identity of B, the KDC will use KA and KB to encrypt the session key. So a first and attempt in an attack is to send a fake message 1. And that will not be of any use to the attacker because when they receive a response, they cannot learn KS. We can try and draw that. Let's consider some different attacks and then see why this is considered a secure scheme or what the flaws may be. What's the name of our attacker? Anyone? We'll call them I. I for the imposter. We used to call him Mao for the malicious user, but I is the imposter, the fake user. So we'll consider what he does. Not I in terms of me, but I as in terms of the imposter. I send to KDC the first message. Let's try. And I'm pretending to be A. So I set those three values. That's exactly the same as the original one. KDC sends back a response. I may not draw it all, but look at the protocol and what will the response be. Importantly, KDC receives a message thinking it's from A and it's going to go to B, so they'll encrypt the first part with KA and the second part will be encrypted with KB. If you compare that to the protocol, you'll see what's inside those encrypted messages. But of importance here, the response that comes back, which includes the encrypted session key, the imposter I cannot decrypt. They cannot use that information. So that doesn't really help them in that case. If they then send that message on to B, for example, let's see what they can do. So they don't learn KS. Let's say step three, they now send that on to B. What happens? That is, we've just done step two and now we send the second part on to B, which is this component. What happens next? B responds. Does B know anything's gone wrong? Does it know it's from the imposter? Not yet. It just received a message. Can it decrypt? Yes. It's encrypted with KB. So B decrypts. B learns. This is B here. This is the imposter. KDC. B learns KS. The KDC knows KS. It generated the value. It's inside these parts. I does not know KS because it cannot decrypt this. What happens next? B responds with message four. What is it? Encrypt. Using KS. Encrypt. Using KS. And two. Good. Message four is B takes the received KS. Chooses say a random number. Encrypts it. What happens next? What can our imposter do? We don't know the key. We don't know KS. So we can't decrypt this. We're trying to fool B into thinking that B is communicating with A. So authentication is really about from the normal user's perspective is they want to check and make sure nothing is unexpected. Nothing has gone wrong. So we want to detect if something does go wrong. So can the imposter send back a reply? B is expecting a reply. The normal protocol requires a fifth message that B must receive and check. The fifth message must be encrypted with KS and contain a function of N2. Let's say N2 incremented by 1. What can the imposter do? Send back the fifth message. They need to encrypt using something. Something. They need to encrypt N2 plus 1 with KS. They don't know N2 and they don't know KS. So what they send here, whatever it is is something that B will detect is wrong. Whatever they do, it will not be N2 plus 1 because I doesn't know N2 because it cannot decrypt this because it doesn't know KS. And similar that it will not be able to encrypt with KS because when B receives this message 5 it will decrypt and find that the contents of N2 plus 1 so that indicates to be error. Something's gone wrong. Our steps have not successfully completed. Don't trust this session key. Ignore what's just happened. So that's just one example of what if an attacker tries to modify something or tries to replay or tries to pretend to be someone else. In this case it was the imposter pretending to be A. It worked out. Maybe that was detected by B. Something was detected to be wrong. I'll try another one. Any suggestions of what our imposter can try to do? Let's just roll back a bit. Let's say we got to this stage same as before. Imposter sent message 3 to B. B responded with message 4. What if A receives message 4? The imposter did not intercept it. It went to A. What happens? A cannot decrypt it. So message 1 was from I to the KDC. Message 2 was back to I. The imposter. Message 3 was sent by the imposter. But for some reason if message 4 goes back to A the real A A doesn't know KS. It hasn't seen any of the other messages. Therefore it will detect an error. I've just received a message. I have no idea what KS. I cannot decrypt. Something's gone wrong. So if that happens again A detects it. So you can try different scenarios. What if A receives the second message? Again the imposter sends this message KDC sends it back. It doesn't go to the imposter but goes to user A. Again it detects this because of the nonce value. The response encrypted with the KA includes N1 but user A did not send a message containing N1 previously. So it will know that this is a response to a fake initial request. Let's see if the imposter can pretend to be the KDC. Normal user A sends the first message to the imposter thinking the imposter is pretending to be the KDC here. What happens next? First it can try and send back a response. What's the response contain? It should contain something encrypted with KA and when A receives the response it's going to decrypt and because the imposter doesn't know KA so if it tries to send a response the first part will be encrypted with some key it will not be KA so when A receives this response it will try to decrypt with KA because whenever I receive a response from the KDC it should have the first part encrypted with KA and A will detect that it will not decrypt. So that one won't work from the imposter pretending to be the KDC. Any other attempts? Let's try a man in the middle attack slightly different the imposter will intercept the messages between A and the KDC and see we'll get the similar behaviour. So A sends the first message the imposter intercepts it and is going to forward it on to the KDC the real KDC Let's try this. They use the original identity IDA and they change the identity to their own. You're correct well done. IDI So all the imposter does is change the identity of the recipient, the responder instead of B it will be itself the imposter. What does the KDC do? Try to do the next step and see what happens when it gets back to A So KDC has just got a request from A to I so respond the response will be encrypted the first part is encrypted with KA and let's just look in the slide what it is the response is the session key the identity of A the identity of the responder and N1 all encrypted with KA and then the second part So KDC received a message it takes that it generates KS and combines with the message it received IDA IDI we'll fit it in N1 and then all of that is combined with the second part KA what? KAI We don't need that because we'll see it when we do this So KDC received a message Initiator A Responder I therefore sends the response the first part is encrypted with KA the second part is encrypted with KA What happens next? What can I do? Can it learn the session key? Looking for the second part is the session key plus the identity of A So yes if it intercepts this the message can learn KS I knows KA so they can decrypt and learn the session key KS What can I do with that? Well if this message comes back let's say I doesn't doesn't modify anything Remember A initiated the message I has learned KS if this message comes back to A what happens what should happen so A is respecting is expecting a message to come back and then should forward on to B that's the normal behaviour so if KDC if this message is sent to I and I then forwards it as is it doesn't modify what does A do when it receives this message Do they trust it? Why don't they trust it? The IDs don't match okay user A sent a message IDA IDB it receives a reply encrypted with KA what's in this encrypted message the session key ID of A and ID of I the imposter so user A will recognise this this session key is not between A and B it's between A and I I did not request this I requested a session key for A to B so the user A detects if they receive this message as is they detect something's gone wrong okay that arises if this message comes back A will decrypt this part and see it's IDI here and detect an error so it will see IDI in the message and that tells A something gone wrong so then the question is can we modify it can the imposter modify the identity in that message can they modify this value it's encrypted with KA the imposter doesn't know KA so no they can't modify it not without going detected by A so they will not be able to modify the identity it is set by the KDC so this IDI is set to whatever the KDC received encrypt with KA and the imposter will not be able to modify it because they don't have KA to successfully encrypt it again so A is going to detect that wrong identity in the receiver any other approaches any questions so far we're just going through some of the different attacks that we could try as the imposter and seeing that they don't work they'll be detected eventually and that's trying to indicate that this is a secure scheme that attacks will be unsuccessful any other suggestions imposters a man in the middle attack which is successful good question so we'll get to that in a moment you can try other cases in this case so you try what happens if the imposter changes it and you find that it will be detected so in this case we've seen I think three or four cases there are a few others that can be attempted there is an attack that is successful on this there's an attack that involves a replay of message 3 so the imposter intercepts message 3 from a past communications and then later replays that message then if the attacker has learned the session key then the attack can be successful so there's a special case if the attacker does know KS then they can fall B into thinking that this is the correct session key let's try that and I think that's the only known attack against this scheme the imposter replays message 3 let's try so let's assume these five steps have happened between the normal users A and B but when they happened the imposter intercepted message 3 and took a copy so one last attack the attacker or the imposter has intercepted message 3 and we're going to send it as the imposter onto B this assumes I knows KS there's no way that they know it from the protocol exchange we saw that KS is confidential but maybe some other way they've through other means they've found KS which is require some maybe KS was sent using some other scheme and it was released or revealed to the imposter and KS was learnt by I then how can I use that what I does remember these users should change keys so they repeat this step they repeat this protocol to change keys so what I does is replays message 3 remember message 3 it was encrypted with KB it contain KS and IDA is that correct so that's message 3 I cannot decrypt this they don't know KB but they can replay it that is they intercepted using TCP dump in the past they recorded the packet and just copied those bits and sent it again at a later stage B receives this what does B do what's the normal behaviour for B can they decrypt yes B decrypts they learn KS then B does what responds message 4 in our scheme and we choose a nonce and we encrypt it with KS the imposter intercepts that and because the imposter we know we said from previous attack has learnt KS they can decrypt and find N2 and the imposter can send the 5th expected message they decrypt find N2 and then they encrypt again using KS and increment N2 for example send it to B and B thinks everything's okay so this attack is successful from the perspective of if the imposter replays message 3 after it was sent earlier and if the imposter knows KS through some other means then the imposter can fool B into thinking to use KS as the session key and now B uses KS to encrypt data and the imposter can decrypt that because it also knows KS how do we stop this attack change KS B uses whatever it receives in the 3rd message it thinks this KS was set by the KDC we trust the KDC I receive message 3 it contains some random set of bits let's use it what else can we do and we may not even check that this KS is the same as the previous one it may have been days ago we don't check that how could we stop this attack and it's a simple way how do we generally stop replays we could try to incorporate some additional timing information what we need there are different ways to do it but what we need is that B detects this as a replay it can include a nonce value or a time stamp inside this message as well so this message contains a time stamp today's date and time so that if it's replayed at a later date and time when B receives that replayed message it will detect this is the same message as I received this message has a date and time which is not current today so a simple way to stop replay attacks is usually to incorporate something inside the message that will identify that this message is a duplicate of a previous message a time stamp can work in many cases or some nonce value some sequence sequence number a time stamp in here cannot be modified if it's encrypted with KB imposter I cannot modify so if it's encrypted with KB it cannot be modified the problem with time stamps is that the clocks of the computers involved need to be as accurate as the time stamps are that is if this is happening on a these messages are being replayed at a microsecond level my computer clock may not be accurate and it will not work correctly but if this message is replayed tomorrow then my computer clock will be accurate enough to realise this is an old message not a current one so there is an attack on the basic protocol here but there is a way to defend it as well we haven't covered all the possible avenues for attack but we've covered several and it's a good way for you to understand the protocol is what happens if we try something else will it be detected and if you try different things you should eventually find that everything that we try as the imposter eventually gets detected so this scheme is used in networks which require usually the computers to share master to share session keys so let's say we have a network of servers or a network of computers which need to encrypt their data between each other so with a thousand computers in that network we cannot manually distribute the master keys because there's too many there's 500,000 master keys that need to be distributed so what we do is with a thousand computers we distribute the 1000 master keys manually to the KDC and then the KDC distributes the session key between pairs of users and an implementation of this in some networked applications it's still used in some networks Kerberos is the protocol that is used for this that implements this what's the problem one problem we must trust the KDC if the KDC is compromised returning to one of our earlier pitches where was it if the KDC is compromised that is the imposter can access the KDC the imposter learns the session keys and all the master keys so the KDC must be very secure let's say it's a server on our network if someone can physically get access to that server then that's a big problem because they can learn everyone's keys and that's the problem with any centralized security scheme that that central point becomes a point of failure there may be some performance problems every time two users want to communicate they need to send some messages to the KDC so the KDC the server has to be fast enough to be able to handle and process those messages so it doesn't slow things down but it's good in terms of there's fewer master keys to distribute to make it work even better where there's a large network many different thousands of users rather than one KDC you can have multiple KDCs and they all talk to a higher level KDC you can have a hierarchy for example you have a KDC for the land at this campus you have a KDC at other lands for part of the university and a central KDC for the entire university and it can distribute the load across different servers so we've looked at different approaches for getting a shared secret key between users the first one which we covered on Tuesday was the decentralized approach the users share a session key direct between each other and the second one covered today was a centralized approach where we go via the KDC the KDC is better in terms of fewer master keys are needed but worse in terms of we rely on the KDC what we'll look at probably next week is how to do a similar thing distribute shared secret keys but with public key cryptography or asymmetric encryption