 So, we've talked about two different types of cryptography, we've looked at symmetric key cryptography, where we have a shared secret key, both entities, A and B must have the same key, one encrypts with a key, the other one can only successfully decrypt if they have the same key, and of course this key must be secret, and then we looked at public key cryptography where we have two different but related keys, and we encrypt with one and encrypt with the other in the key pair, and we've seen public key cryptography used in two different ways, one for confidentiality, I encrypt with your public key such that only you can decrypt with your private key, and the other approach is for authentication where I encrypt with my private key as a form of signature, I sign the message with my private key such that you can verify it came from me because you can use my public key to decrypt. We want to go back and address the issue of how do we get the keys to other people, and not just how to get the keys to other people, but what's the best way to use keys to keep track of keys for both symmetric and public key cryptography, so this is about key management, we'll go through some general issues with key management and then we'll look at how we can distribute secret keys for symmetric key encryption, and we'll see that one way to distribute a key, and when I say distribute I usually mean distribute across a network, communications network, one way to distribute the key is to encrypt it, but that leads to this recursive problem of if I need to encrypt the key with another key how do I distribute that original key and so on, so we'll see the solution for that, and the other way to distribute keys is to make use of public key cryptography, because one of those two keys can be public, we can use that to encrypt, so we'll see how to distribute secret keys using symmetric key encryption, and then how to distribute secret symmetric keys using asymmetric encryption or public key encryption, and then look at a related issue of okay if you how to get someone else's public key, and that will lead us to something that's relevant for websites is certificates on websites and how they distribute keys. Some challenges with key management of course is how to share a secret key, so secret is used for symmetric key encryption, both sides must know the same value and no one else should know that value, so how to distribute or how to share a secret, that's one challenge we have. With respect to public key cryptography, another challenge is how do I get someone's public key, it sounds easy just publish it, okay I have a public key I put on my website, but then we have a problem if you want to obtain my public key how can you be sure that it is my public key and not someone pretending to say it's Steve's public key, because if they can do that then they can defeat some of the security mechanisms, so distributing public keys is a challenge. The other thing is when to change keys, and we'll see that many schemes will take advantage if we don't just use one key forever, especially for symmetric secret keys, you may use one key and use that to generate another key, and then use that other key maybe for five minutes and then change the key, choose another random key, so how to change keys and how often should we change keys. Now just be aware when I say secret key I refer to a shared secret key used for symmetric key encryption, not a private key which is using public key encryption, so really three names for keys, a secret key, a public key and a private key, the public and private keys go together in a pair, the secret key is that shared by two entities in symmetric key encryption. Some of the things that we'll assume or the principles that we'll work on when we look at some of the solutions for key management are that we will assume that there are many users that want to communicate in most of the scenarios we consider, and they want to communicate securely across the network, so by securely here they want to have confidentiality, they want to have authentication, so they need to use cryptography, so they need keys, and many users mean it's not just two users wanting to communicate, if it's just two people wanting to communicate usually it's not so hard to distribute keys, but it's when it's hundreds of users, thousands or millions of users wanting to communicate across the internet for example, then the challenges that will go across become relevant. So let's assume that there are lots of people, lots of users, and they all want to be able to communicate across the network, and let's assume that an attacker can intercept anywhere in the network, so we'll show some pictures shortly, but some communications network assume the attacker can intercept from where I send the message, I send it from my computer, and it goes across the network to your computer and you receive it anywhere between our two computers, somehow the attacker can intercept and get a copy of what was sent. Somehow, well there are different techniques and I think most of you know one way to intercept messages, if you're using Wi-Fi, when I'm sending wirelessly from my laptop to the access point, because it's broadcast nature of communications my signal propagates in all directions, so when I transmit up to the access point, someone sitting in the backer room can intercept that message, so it's quite easy to intercept in a Wi-Fi network. If it's a wired network, how do you intercept someone else's data? Let's say I'm using the wired ethernet cable that plugs into the wall there and goes out to the gateway or router for SIT and out to the internet, how would you try to intercept my data communications? What would you need to do? Change the switch so if you could maybe before I arrive for the lecture, maybe the socket here that the cable plugs into, maybe you put a special device inside that socket, a small say embedded computer that reads everything that comes into that socket and then sends it on across the rest of the network. So you need some way to tap into the link or the network and there are different ways to do that with wired links. You could maybe find the LAN cable and again insert some small device which I would not notice that receives the signal, uses TCP dump or similar to record the packets, save them or send them somewhere else and let the data pass through so that I don't notice that it's not getting through, that it's being intercepted. So with a wired network you need some physical access to the network. Maybe if you could get access to the computer center, the switching room down on the third floor, this cable goes to a switch down there, if you could sneak into that room then again you could intercept the traffic. So again it's under a number of conditions, it's possible for an attacker to intercept either on a wired or a wireless network and we'll assume that they can. The other thing that we don't want is we don't want to have to force our users to manually interact to exchange keys. So we have say 40 people in the room, let's say we need to exchange keys with each other. By manual interaction I mean go up to someone and say okay let's write down a key, some 128 bit value, write it on a piece of paper and give it to the other person and they keep that secret. This manual exchange of keys is very inconvenient. What we want is some automatic exchange of keys such that the human isn't involved but the piece of software running on their computer does it for them. That's what we would like, otherwise with large networks it's just not going to be manageable. But we will see that in many cases we require some manual interactions but we want to limit the number of them. So the physical exchange of keys is possible but we don't want to do it so often. And finally a principle that's used and we'll see it used in different schemes is that the more times we use a key to encrypt our data, the more chance the attacker for discovering that key will make that assumption. That is let's say I have a key and I encrypt every message I send using Wi-Fi from my laptop to the access point. So every packet that sent is encrypted with that key. And the point here is that I would like to change the key on a regular basis because this principle is saying that we'll assume the more times I encrypt using the same key, even though the data is encrypted it gives a higher chance that the attacker may be through to some weakness in the algorithm, higher chance for them to find the key. So that suggests change your keys on a regular basis. Don't use the same key forever just to be safe. So before we look at how to distribute keys let's look at the problem of especially manually distributing keys. Let's consider a example network. This picture shows 10 hosts, 10 computers, A through to J. And connected via some switches, these SW rectangles, switch one, switch two, so some LAN switches and some routers, R1 and R4, just a simple small network. So the users, the end users, the humans would be using computers A through to J and the switches and routers are just part of the network to support the connections. So one of the things that we need to consider is if we're going to encrypt our communications in the network where should we perform the encryption? There are basically two different approaches. Let's say we want to allow A to communicate to B, then the two approaches for where to perform encryption are A could encrypt the data, send the data, the cipher text to the switch, the switch could decrypt that and then encrypt again, using a different key possibly, and then send the new cipher text to B and B decrypts that. Or if we wanted to send from A to F, A encrypts the data, sends to the switch, the switch has the correct key to decrypt, decrypts the data, encrypts again to send on to the router R1, which decrypts, which encrypts again to send a switch 3, decrypt encrypt and so on until it is received at F, which finally decrypts. That's one approach and maybe not the obvious one that people think about, but that's one approach called link level encryption. Every link in the network we apply encryption separately. The other approach is what we call end-to-end encryption or host-level encryption, where if A wants to send to B, A encrypts the data, sends the cipher text to the switch, the switch does not decrypt, it simply forwards on the cipher text to B. B receives and does the decryption. Or if A wants to send to F, A encrypts, sends to the switch, which forwards it on to the router across the path to switch 5 and then F receives and only F is the one that can decrypt. That's end-to-end encryption. Which one's better? End-to-end or maybe a better question is what are the trade-offs? What are the advantages of the first one, link-level encryption and what are the advantages of the second one, end-to-end encryption? Which one would you want to use in this network? Link level, let's consider link level where we encrypt separately on every link. What's the problem with that? Many encrypt and decrypts, that is encryption and decryption takes some time. There's some performance hit of doing it. For example, to send from A through to F, we must decrypt at the switch, switch 1, and then encrypt. Every packet that goes through switch 1, switch must decrypt and encrypt. That decreases the performance of the data delivery because it takes time to do that. That's a problem. The intermediate devices must perform the decryption and encryption. They must support the algorithms and they must do it fast, otherwise our performance slows down. There's a disadvantage. What is an advantage of doing link-level encryption? Hard to see. We'll come to that in a moment, the advantage. What's another disadvantage? You could tap into the switch. What happens inside switch 1 is A encrypts inside the computer. Let's say I am A, someone at the back is F. I encrypt inside my computer, so some software does it for me, sends across the link to switch 1. Switch 1 inside the computer, it's got a CPU, decrypts, gets the plain text, it's stored in memory, and then also inside the computer, encrypts again, and then sends the new cipher text on to router R1. There's a problem there that for a short period of time, the plain text was available in memory inside the switch. If someone had physical access to that switch or it compromised that switch, again, they can potentially get the plain text. This process of inside this device, decrypt, get the plain text, encrypt again, has this limitation if someone gets physical access to the device, they can get access to the plain text. Of course, there are the advantages of doing the end-to-end encryption. We don't have to trust the device. That is, even if someone compromises the device, they still can't see our plain text because A encrypts, only F can decrypt, even if someone accesses the switch. What else is a problem with link-level encryption? So yes, we need to trust the devices. If they're compromised, our communications from between A and F can be compromised. What else is a problem? We need to also trust the links, actually. That is, we need to make sure that the encryption is used across every link in the path that I use. In this small network, not so hard. If we control the network, that is, this is the network inside SIT, we can set up all our devices to use encryption across every link. But now think of the internet. This is internal for SIT and this is our ISP going from router 1 to router 2 and this is someone else's network. From the perspective of the end-hosts, A and F, they must trust that the network operators, like the internet service provider, performs the encryption. You must trust the people who run the links. Of course, in large networks, that's not possible to trust everyone who runs the links. We've seen three disadvantages of link-level encryption and we haven't been able to answer the advantage. We'll see in a moment, but maybe the hint is it's not used very often apart from in small networks. We'll see that when we come to the advantage. Two different approaches. Encrypt at the end points for those communicating or encrypt across each link in the path between those end points. Link-level encryption versus end-to-end encryption. And here we'll see the advantage of link-level encryption. Same network. For link-level encryption first, calculate the number of keys that are needed in the network. How many keys are needed in the network? Here's our network again. Link-level encryption, where we're going to encrypt across each link separately. So for each link, A encrypts with one key, the switch decrypts with the same key. If we're using symmetric key encryption, so for the link between A and switch one, we would need one key, shared between the two end points of that link. And then the switch encrypts again with a different key to send to the router R1, which decrypts and encrypts again to switch three and so on. If we use a different key for every link, how many keys do we need in the network? Someone can count. How many links? Look at the number of lines between devices. Anyone get a number? 20? There are 20 links in this network. So for example, A to the switch one, B to switch one, there's two, switch one to router one is three and so on. Just add up the links. There are 20 links. And what we can do with link-level encryption is we could use a different key for each link. We could have a special case where we use the same key across all links even. But remember this principle, we don't want to use the same key over and over again. So typically we'd use different keys on each link. Let's consider that. So how many keys we'd need is 20 in that case. How would we distribute the keys? Well, what's the way to distribute the keys in this small network? There may be some automatic ways, but let's try manual distribution. What we could do is that the person who runs the network, so say it's the network inside our campus, the computer center, they set up the switch and they set up the computers and the routers. What they do when they set them up is that they go to the interface and enter in the key that is used at both end points of each link. So that would be what I call manual distribution of the keys. The human is involved in setting maybe programming into each device, they're a correct key. It could be possible because we have 20 links, we have really 20 keys that need to be programmed into what is it, 40 devices. So with link level encryption, encrypt across each link using a separate key, we need a total of 20 keys and we could distribute them in a manual manner in that the administrator who runs all the devices programs it in. If you grow this network to not just 20 links, but maybe across whole the Thomas Rungsick campus, maybe 1,000 links, 1,000s of links perhaps, then for sure more than 1,000s, then the number of keys needed is the same as the number of links in the network, but manual programming in them in becomes a hard task. That is the administrator needs to go to every device and log in to that device via the web interface or via some interface and type in the key and then go to the other end point of that link and type in the same key. So manual distribution even in such small networks becomes a pain for a human user to do. So we need some automatic way. The fewer keys that we have to distribute, the easier it is to distribute them and the easier it is to do manual distribution to have the human involved. Let's say that we want to do host to host encryption or end to end encryption and between the hosts first, that is the hosts are A through to J, they are our 10 computers. So if A wants to send to B, A will encrypt, the switch doesn't do an encryption or decryption, it simply forwards on on to B and B decrypts. So if we want to allow any host to communicate with any other host, how many keys do we need? Try to count the number of keys needed in this case. Start simple. How many keys does computer A need to communicate with any other computer in the network? Nine. A needs a key shared with B so that when AMB communicate, they can encrypt. A needs a key shared with C, D, E, all the way through to J, so A needs to share with nine others. Let's say that when we send from A to B, we use one key and when we send from B back to A, we use the same key because it's the same pair of entities. We can use the, in both directions, use the same key. So B already has a key shared with A in that first nine that we counted. B needs to share also with C, D, E through to J, another, what, eight keys needed and C needs to share with seven others and D with six others and so on and the total number of keys. How many pairs are there? This is what we finished on in the lecture last week, those statistics and probability. There's one equation that's very useful to remember here. So it's really nine plus eight plus seven plus six to the end, which it's not factorial, they're just adding. It's N times N minus one divided by two. N is the number of entities involved. So here, there are 10 times nine divided by two, 45 keys. You can check that. So just check if you want to list all the possible keys. A to nine others, B to eight others, C to seven others and so on. If you add them up, you'll get 45. More keys are needed if we want to do end to end encryption here. And that's starting to lead to the disadvantage of end to end versus link level. This is one reason why link level encryption can be used because we could manually distribute those keys by having the administrator program them into the devices. With a small network, that would be manageable. If we want to allow all the computers to communicate, end to end, we need 45 keys. Not so many more double, but still may be manageable. Sometimes, though, we would like to not just encrypt for every computer, we'd like our applications to encrypt data. So on computer E, for example, there may be several applications running at the same time, several networked applications. And they may want to encrypt separately amongst those applications. So when E sends to D, with encryption for each host, they just need one key for all data sent between E and D. But sometimes we'll encrypt per application. So let's say there were five applications on E and five applications on computer D, then in some cases the applications will maintain separate keys. So there would need to be a key shared between application one on D and application one on E, application two on D and application two on E, and application five on D and application five on E. For example, the application may be your web browser on your computer, wants to talk to the web server on another computer. That uses one pair of keys, a one key. Your email client on your computer to the email server on the same other computer uses a different key. Often applications will have their own encryption approaches and therefore would need a separate key. Let's consider that as another case and calculate the number of keys. Let's say there were, for example, five applications on each computer. How many keys would we need in total in the network? And there are two different approaches to this, or there's two different ways to think about it. First let's keep it easy. Let's say the application on each computer will only communicate with its corresponding application. So if I draw that, let's say if this is D and E, there are five applications on each running pieces of software. So this pair of applications would need a key to be shared. This pair of applications would need a separate key. So let's say web browsing, email, instant messaging, voice, and some database application. All between the same pair of computers but different applications. So we'd have five keys for between D and E. Now we need to consider D to A, D to B, and all the other combinations of pairs of computers. So how many keys in total in this case? There are 45 pairs of hosts. We would need five keys per pair. So five times 45 in this case. Often networked applications will use their own form of encryption. They'll design and select on their own and therefore may have separate keys amongst the applications even on the same pairs of computers. So we're trying to count how many keys would be needed and then we'll make some conclusions about, well, can we manually distribute those keys by using humans or do we need to automatically distribute them using some communications protocol? And let's consider one last case. Similar five applications but any application can communicate with any other on the same computer. If I draw that for example the two computers E to D, they each run five applications. The application one on D would share a key with application one on E. Application one on D would share a key with app two and so on. That is we're not limited to be between the same types of applications. Maybe there were five instances of a transport based application using TCP and the key was for each TCP connection. And similar application two on D would share with the other five on E. I will not try and draw that. If that was the case, how many keys are needed in total? Any of the five applications must share with any other of the five applications on any of the other computers. Anyone tell me the answer? So just a different scenario in this case any application can talk to any other application. Any questions? Do you have the answer then? How are you going to find the answer? It turns out it's really the same as host to host but instead of having 10 hosts, we really have what, 50 applications. And any pair needs to be able to communicate with a separate key. So application one on D to application one on E, application one on D to application one on C and so on. If you look in total, there are 50 applications on all of those computers. They all need to have a pair. They all create a pair and each pair needs its own secret key. So there are 50 applications. So the total number of keys would be 50 times 49 divided by 2. 1,225 keys. Which one is used? Well it depends upon the network and how the computers are set up but commonly it would be between applications, one of the last two in many systems. What do these numbers mean? They give us an idea that depending on how we use encryption, it indicates whether it's possible to manually distribute keys or not. And again by manually distributing keys humans go to the device and go to another person and tell each other the correct key and enter it in. If there were 20 keys, that would be possible to manually distribute those 20 keys amongst the different devices. If there are 1,225 keys to be distributed, then that's probably not possible. It's just not convenient for someone to go around to everyone else and exchange all the keys for each application. And of course expand this network into not just 10 hosts, but up to let's say inside our campus, we have something like 400 hosts, 400 computers. If we wanted link level encryption it would need one key for every link, I don't know, hundreds of keys. If we wanted host to host end to end encryption, just between the hosts, with 400 hosts it becomes what 400 times 399 divided by 2, which is 80,000 or something or even more. The point is with end to end encryption, there are too many keys to distribute to allow for manual distribution. We must have a way to automatically distribute the keys without the human being involved. So how do we do that? How do we distribute keys automatically? Distribute secrets. You know of one approach, you've done it already. What's the name? Starts with D. Diffie Hellman. Diffie Hellman is a protocol for automatically exchanging a secret between a pair of entities. So Diffie Hellman key exchange, we've seen. That is a public key cryptographic algorithm for key exchange. If you remember in the lecture we did a man in the middle attack against Diffie Hellman. It's possible to do a man in the middle attack. So we'll see later we'll return to a man in the middle attack and see that there are some limitations there. We need to use it in a different manner. Can we use symmetric key cryptography to support our automatic exchange of keys? That is, we have a central computer that creates the keys for us and encrypts the keys and sends it to each computer using some protocol. That would be desirable. Something creates all the keys or, so either a central computer creates all the keys and sends it to A, B, C, D up to J, sends all those 1,225 keys and then they use them in the network. That's the type of approach that we'd like to have where that's all automatic. Let's see how that works. So we calculated the numbers just returning here. Link level encryption. We encrypt data across the individual links. It has some problems in that it adds extra requirements on the devices and we must trust the links. So it's only really suitable in networks, inside networks where there's one operator, one owner and they can be sure that everything internal is encrypted. But if you want to apply link level encryption it doesn't make sense in a network which has multiple owners or multiple operators because you need to trust the other one is not viewing your traffic. So in larger networks end-to-end encryption is used like the internet for example. The problem with end-to-end encryption is that with many end points there are many keys needed and we need an automatic way to distribute those keys. And let's look at the approaches we have. First, let's go through all of them. Manual exchange of keys. So this uses the human to distribute the keys. It's possible but when there's maybe more than hundred keys it becomes too inconvenient. And with end-to-end encryption there's highly like to be thousands of keys necessary. So manual exchange of keys is only really possible when there's a small number of keys to be exchanged. Tens of keys maybe. So option two, what we do is we have two different types of keys. We have what we call a master key and we'll allow the users to exchange a master key using a manual approach but then we'll generate or calculate session keys which are then used for encryption of our data. So we'll see a scheme that uses a combination of manual distribution as well as automatic distribution. The idea is that the master key between say a certain set of users is manually exchanged. Then there's some protocol that a session key is generated and then encrypted using the master key and sent to the recipient that needs it. So the session keys will be sent across the network and as we know if we're going to send anything across the network it must be encrypted. So to send a session key across the network we'll encrypt it using the master key under the assumption that the master key has already been manually distributed. So we'll see in some of the upcoming schemes we'll distinguish between a master key and a session key. We'll compare the approaches after we see one of the schemes. In particular we'll see the key distribution center. The third approach which we already know about as an example is to use public key cryptography. Diffie Hellman is an example or simply using RSA. User A encrypts some secret, some symmetric key with B's public key and only B can decrypt. So option one, manual exchange of keys not possible when there's a large number of keys needed. Option two, manual exchange of master keys and then using symmetric key encryption encrypt session keys using the master key and automatically exchange the session keys. So this uses symmetric key encryption. Option three, use public key cryptography such as Diffie Hellman and other schemes. And with public key cryptography one of the major challenges becomes how do I know that the public key of Steve is in fact Steve's public key, not someone pretending to be him. So we'll cover that issue. And that's what this, the remainder of the, this topic covers, those three or the last two options. Starting with option two we'll look at how do we use symmetric key encryption to distribute symmetric keys. And I think we'll get straight to an example. We'll go to an example, we'll come back to those few slides that we'll skip over after the example. For the example which is on the next slide, the next picture, just some notation we'll talk about here. In this simple example we've got two entities that want to communicate, A and B and they've got some ID. And I'll denote that as IDA and IDB. So something that identifies that entity in the network. For example, an IP address and port number to identify an application or maybe some unique string to identify a human or whatever entity is trying to communicate. We'll have a master key denoted as KM where that master key in the picture that's coming up is shared between A and B. We'll also have master key specific to, I think in later slides, not the next one, specific to each user, KA and KB. And we'll introduce a session key, KS, and then we'll see some nonce values, N1 and N2. And I'll explain them once we use them in the system. Here's a way to automatically exchange session keys between pairs of users using symmetric key encryption. This approach assumes A and B both have a master key. They both know in advance a key KM. So the steps are, A wants to communicate with B. And to communicate with B, the aim is to get a key that they both know. But they already know the master key KM. What we'll do coming back to one of our earlier principles, let's not use the master key to encrypt the data. Let's use another key to encrypt the data to meet this idea that don't use the same key too often. We'll use a master key to encrypt the session key and then use a session key to encrypt the data so that later we can change the session key quite easily by just generating a new one and encrypting it using the master key. So we'll do some analysis of that in a moment. So let's write down what we know as we go through this protocol. As known in advance, we assume in this case that A knows KM and so does B. So that's before any of these steps. And this diagram shows the protocol as an exchange of three messages. A sends the first message to B, we'll see the contents. B responds and then A sends the third and final message to B. So this is an automatic way for exchanging a session key but it assumes that they both have a master key up front. A sends the first message which contains its identity and some nonce value. A nonce value, in this case N1, a nonce value is a number that we'll use only once. Nonce means number used only once. And it's usually either a random number, so what value? It's a random number, maybe a date or time stamp, maybe a counter. So when I say we only use it once, if it's a random number, I choose a random number and that's the nonce. The next time I need to send such a message, I'll choose another random number and therefore I haven't used the previous one again. Similarly if it's a time stamp, I send this first message and I include a time stamp in there. That's the nonce value. Tomorrow I send the same message again from A to B but it will have a different time stamp, a different date and time. Or if it's a counter, N1 is zero in the first case. The second time I need to send this message I set it to one and then two and so on. Now eventually it will repeat but if we have it large enough then it will be unlikely for a long time. So we'll see the use of it shortly. It's commonly used to identify that this is not a repeat and there's no, may thought, replay attacks. So first message, A sends to B. I am A and I want to communicate with you and a nonce value. B will reply and the reply of B, what B does is it generates a session key. So it calculates a session key KS, which can simply be a random number. If we're using say AES 256 it generates a random 256 value and it's going to send the session key to A here, combined with A's identity to confirm this first message was A, I'm sending it to A, I am B and this F of N1 means some function on the nonce that we receive from A. For example the function could be plus one. The way that we could use the nonce value is that let's say N1 here was a random number. Can someone choose a random number for me? Thank you. There's a random number. A chose that and sent it in the message as well as its ID, something that identifies computer A. When B responds this F of N1 is some operation on the one that it received and it may be for example add one, so this value may be 46322. In addition B chooses its own nonce value N2, another random number that's N2 and we'll see it comes back in a moment. So when we say here a function of N1 it means some operation which is known by both sides as part of the algorithm what the operation is, for example increment. It's useful for both A and B in identifying that these messages belong to this specific transaction that they're not replays from old ones, they're not fake messages. We'll see in a moment how they can be used. So this response message contains the session key, the identities of A and B, some function on the received nonce value and a new nonce value chosen by B, but since we're sending that across the network we can't send it in the clear, we must encrypt it and that's why here we encrypt with the master key KM. The idea was to get the session key between A and B. We encrypt that session key with the master key. When A receives message 2, A can find the session key, it decrypts and gets KS. Importantly when it receives message 2 it checks the values it received in the nonce. A sent nonce 46321. When it received the response it was 46322, since A knows that that function is the increment, A knows that the person who received it received the one that I sent. It's some confirmation that this response is for the message I just sent. It's not for some other one I sent 10 days ago or yesterday, it's for this one I just previously sent. So it serves as some identifier or some sequence number so that A can keep track of this message 2 is a response to message 1. Because what could be happening in a network is that A is sending many of these message 1s to B or to other entities. So it may be doing it in parallel for different applications to repeat this process. If A wants three session keys with B it can send three of those first messages but that all have a different nonce value. And A would be able to confirm and correspond the response value with the original one based upon the 46322 or the equivalent number. Now we've achieved our aim. A knows the session key. The final step is again some form of authentication of saying here's the nonce value 18467 and A applies some function on it let's say increments it and encrypts that with the session key and when B gets it B confirms that A got the session key. So this can act as confirmation and we'll see if someone tries to do an attack because B expects to get this confirmation it can if it doesn't get the confirmation of the encrypted value 18468 then it knows something's gone wrong. B must receive 18468 encrypted with the session key. If it doesn't then something's gone wrong. So that's the protocol. The goal was to distribute a session key. Why did we need it? Why not just use KM? Not KS. That's the first question you should have. What's the answer? KM is a master key shared between A and B only. KS is a session key shared between A and B now after. Why did we need these three steps? Why didn't we just use KM? The idea is that again this idea don't use the same key too often. So one way to get around that is you have a master key. With a master key you use that to encrypt session keys. Let's say every five minutes you want to repeat this because you want to change your key. What you do is you don't change your master key you change your session key on a regular basis. So the way we could do this is that let's say A and B manual exchange a master key today. Then every day they go through this process using the same master key of generating a new session key. And the data that they use, the data that's encrypted between A and B is encrypted with a session key. So not shown in this diagram but the next step once we have a session key any data is encrypted with KS. So the data between A and B is encrypted with the session key. The session key was encrypted with the master key. The master key was manual exchange that took a lot of effort that's inconvenient but we only do it once maybe today and not for the next year. But the session key now we can automatically update or change the session key by applying these three steps say every day. Tomorrow I do these three steps and get a new session key, the next day a new session key. And this gives us this feature of regularly changing the session keys for this principle of don't use the same key too long. So we actually have a hierarchy of keys, a master and a session key. The nonce function, so the nonce value, the way for choosing it and the function we apply on it usually would be part of the algorithm. So this is a general, this is the general algorithm or protocol but a specific implementation may choose the way of encoding the identity, the messages and the nonce value. So it would be known by A and B as well as by the attacker. So it's part of the algorithm. Not the nonce value but how to create it. So yes you know it's encrypted, you know for example that someone chose a random value, so if the nonce, let's say A and B decided to use a random value for the nonce like I did in the example. The attacker knows they chose a random value but they may, because it's a random value they cannot predict the next one and in the scheme that we saw what can the attacker do. If the attacker pretends to be A and sends message 1 to B, what will happen? Can the attacker send a message to B and get B to respond to A. If the attacker sends message 1 to B they can say okay here's the ID of A. The sender is not A but they're pretending to be A. They can choose a nonce value and when B sends back a reply to A it contains the nonce value that A chose and it's encrypted with KM. What happens next? The attacker could intercept and try and decrypt but they can't decrypt because they don't know KM so that doesn't work. Remember all of this is encrypted with KM and we're assuming the attacker doesn't know the master key so the attacker cannot decrypt this and see the session key. If this message made it way back to A, A could decrypt and they would see that here's a nonce value or F of the nonce value of a message that I didn't send. So A would recognize that this response message 2 is not correct in that it's a response to a message that I never sent therefore I detected something's gone wrong and maybe I can inform B in some other way saying you received a message from someone but it wasn't me because I never sent message 1. So the nonce value can be used in that case because for example that A will recognize the nonce in this case. That is in this case, the normal case, A is expecting a response containing 4, 6, 3, 2. If it's not something's gone wrong, if the attacker created this first message they would choose a random number and B would send it in the response or an increment of that and A would detect it because it wasn't expecting such a response so it's used to identify what's expected and what's not. It's useful also in the final confirmation in the third message as well. A replay attack could be attempted by the attacker. Let's try, maybe we'll try and draw it again to finish today. Let's try a replay attack on that one. Let's just assume that the first message is sent from A so K, M is known by A and B and let's say A sends the first message, identity of A and the nonce value, let's choose a random number, let the nonce value set just a value that we chose, B sends back the response. I will not write it all but we'll summarise it's encrypted using K, M. It contains K, S, the identities, the nonce value incremented and another nonce value. I haven't drawn the identities there. And then the third message, so this is the normal approach. What do we do? Encrypt using K, S in this case, some operation on the second nonce value. So this is the normal exchange between A and B. A sends a message saying I am A and the nonce value N1 is random number 44896. When B sends back the response, A will check. Does it contain 449897? Because we sent one with 44896, yes it does. So this message 2 is a response to the message 1 which I sent, which is all good. And also of course contains the session key and then we do a final confirmation. We encrypt using the session key, the modification of the second nonce chosen by B. Let's see if what we do is at a later point, maybe that was today, let's say we change session keys every day, tomorrow or at a later time. What if the attacker replays the second message? What will happen? We'll try some different cases. What if the attacker replays the second message? That is the attacker, our malicious user sends to A the contents of this message. They don't know the contents or they may not but they can replay the message because let's say it's a packet sent across the network. The attacker has intercepted that packet in the previous day. Now they just re-send that exact same packet. Even though it's encrypted they cannot see the contents. What happens at A in this case? Can it decrypt? A can decrypt the message and then what do they do? They check the nonce and what do they discover? This is yesterday's nonce. This is one that I'm not expecting. So this is the use of when they decrypt this message they receive it, they find here's a message containing nonce 44897. I didn't send in the last few minutes. I didn't send 44896 so it keeps track of what it last sent and realizes this is a replay. So that's the first use of the nonce or another use of the nonce where a replay of a message can be identified. It's like a sequence number. We can identify duplicates or replays. So that doesn't work from the malicious user's point of view because A would detect that. What else can the malicious user try to do then? Try to get A or B to accept a message which comes from the malicious user. What would you need to do? Some of you may be asking why do that? Why would the malicious user send this message? What's the benefit? Maybe the malicious user has found out what KS was and they want to get A to keep using KS because maybe through some other means they did find the session key and they want to make sure A keeps using it so that they can further decrypt what's being sent by A. So there's a possible reason for trying this from a malicious user's point of view. Try and think full A into think use this session key. It's a good one but in fact it's one that's been compromised in the past. Anything else the malicious user can try to do? What can you try? What's the purpose of the third message? Again, to confirm. Okay, can the malicious user take advantage of this or what does this prevent if the malicious user does something? So what we'd like to do and a good way to understand why these steps are needed is to look at what if something goes wrong? What if the malicious user changes it? Will it be detected? And if it is, then it indicates that the scheme is good. If it's not detected it indicates that's a potential flaw in the scheme. If the malicious user, we haven't drawn it but if they tried to send this first message pretending to be A, it would be detected in that the response that comes to A, A would realize, ah, I didn't send that first message. Similar with a replay here. I'll leave you to be malicious. Yes, give me a malicious approach. Right, so another case. What if the malicious user, or not try and draw it, the malicious user sends this first message pretending to be A and then B sends the response back to the malicious user. What can the malicious user do then? They can't decrypt it because they don't have KM. Okay, so they could try to do that. The malicious user sends the first message to B, B responds, the malicious user gets the response but the malicious user cannot do anything with it because they cannot decrypt it because they don't have KM. Remember KM is only shared between A and B. Alright, let's try and finish up. Why use this scheme again? What we'd like to do is use a master key on a, ah, we don't want to use the master key very often. Okay, but we'd like to change keys very often. So what we do is we use the master key to encrypt a session key and we change the session key very often and we encrypt our data with a session key and this is towards the principle of don't use the same key for too long and that's what this scheme allows. How many, let's consider to finish, how many, let's say a network of 100 users using that scheme, how many master keys are necessary? A network of 100 users, so there's not just A, B, C and so on, there are 100 in total. In total how many master keys are necessary? A had a master key with B, A would have a master key with C and so on and the total you'd calculate is what? 100 times 99 divided by 2. Remember that formula, it's very useful, which is what? About almost 5,000, 10,000 divided by 2. These are manually exchanged. So the master keys are not sent across the network because we've got nothing to encrypt them with, so there must be manually exchanged and that's the problem there. How many session keys? Well, the same number of session keys but they exchange automatically, that is we use that protocol to exchange the session keys and they can be therefore easy to change. So in this case the same number of session keys as master keys but the master keys, we think we do it once when we start our network and we keep the same master key for a long time, we just don't use it very often. We only use it to encrypt a session key, let's say we change the session key every day. So for every piece of data we send for that 24 hour period we use one session key and then we change the session key for the next day and change it again and then again and every day we just use our master key once or twice to exchange the new session key. So the automatic exchange of session keys means that we can easily do it again and again and again but the manual distribution of the master keys is the problem in that a lot of keys need to be distributed via some manual approach. So this scheme is okay but the number of keys that need to be distributed using a manual approach is maybe too many in this example. It only works when there are few nodes, maybe tens of nodes, 100 nodes it's getting a little bit too large. So what we'll see on Friday is a centralized scheme which cuts down on the number of master keys needed. We can still use session keys but will reduce significantly the number of master keys and that's important.