 What we've covered in the course so far, we started with encryption, that is the concepts of encryption and one of the main uses for encryption is for confidentiality, that is I have a message, I want to send that message to someone else and I want to make sure that no one in between can read my message. I want to keep my message private or confidential. We started with symmetric key encryption. So we went through the classical ciphers and some of the real ciphers, symmetric key encryption and remember that both the source and the destination must have the same shared secret key. So it's called symmetric key encryption, sometimes it's called secret key encryption or shared key encryption or even there's some other names as well. But the one where we have a same key at both source and destination, one key. And then we went and introduced public key cryptography where we have two different keys. They are related though, the keys are generated and related and we can use them in opposite order in some cases where we encrypt with a public key and decrypt with a private key or the other way around, decrypt, encrypt with a private key to sign a message and to verify decrypt with a public key. And that's when we move on to authentication and we spoke about hash functions can be used in authenticating messages and also there are other ways to authenticate messages. We can authenticate messages using normal encryption because if it successfully decrypts with symmetric key encryption then it's an indicator that it was encrypted with the right key and by the same person who has that key. And we saw the last topic very quickly last week was on message authentication codes, an alternative for getting some short representation of the message that we use for authentication. So hash functions, message authentication codes used for the same purpose authentication. And that this next topic after we go through this next topic covers the main operations that we use in cryptography. There are some others but these are the main ones so encryption in the different forms and authentication that are the main operations we have available. This topic is about how do we distribute keys? How do we make sure that the correct users have the correct keys? So it's a problem that we've mentioned throughout the other topics. For example with shared secret key encryption somehow I need to get the key to the other person. That's a problem and public key cryptography is a way to overcome that problem but public key cryptography has its own limitations in key distribution as well. So now we're going to talk about if we have keys, secret keys or public private key pairs like you did in the assignment, you generate your own key pair, how do we get them to the other person or the other entities and how do we do it in a secure manner? That's managing keys and distributing keys. And we'll go through some general concepts with key distribution and some issues and then we'll go through some different cases. One, as you see it's not so clear here but we'll see that we'll look at if we've got symmetric key encryption, two users need the same shared secret key. I want to communicate with you with symmetric key encryption. We both need the same secret key. What's one way for those two users to securely exchange a key? What's the name of one algorithm that allows two users to securely exchange a secret? Diffie Hellman, you just did it in your assignment. In your assignment, you exchanged a secret between two users. You were one user and then I created this other user, your friend. And using Diffie Hellman, you exchanged some public values. So you generate your own key pair, exchange the public values and then derived the secret. And the secret that you derived should be the same value as the secret that the other user derived. That's how Diffie Hellman key exchange is used. That's one way to exchange a secret. There are others. So we'll go through different ways to exchange secret keys using both symmetric encryption and asymmetric encryption. And then we'll talk about how to exchange public keys. We've set up until now with public key encryption the advantage is I generate my own key pair, private and public, and then I tell everyone my public key. The concept sounds simple. The problem is how do you know it's my public key when I tell you? Someone could pretend to be me and publish Steve's public key, put it on a website and say this is Steve's public key, but in fact it's someone else's public key. So we also have problems with how to distribute public keys. So let's get started. First some general issues or some assumptions that we're going to make. Symmetric key encryption fast, it's good for encrypting a large amount of data. You have a file, you want to encrypt all the data you send across a connection. When you're downloading a file or using a secure shell for a terminal, then symmetric key encryption is normally used for that because it's fast. It can be implemented and run quickly when we have a large amount of data. It requires a shared secret key. The alternative asymmetric or public key cryptography doesn't work so well or is very inefficient when we want to encrypt a large amount of data. Therefore it's not very often is it used to encrypt a large amount of data. It can be, but it's slow. Therefore public key cryptography is mainly used for authentication, whereas symmetric key cryptography mainly used for encrypting data and often we combine them. We use symmetric key encryption to encrypt the data and public key encryption to provide authentication. The issues that arise that we need to cover is how do we share a symmetric key, a secret key, how do we get one from one user to another and then how do we distribute public keys. First, consider the case where we want to distribute or share secret keys and we're going to use symmetric key encryption to do so. So I cannot just send you a key by email. If I generate a key, I cannot send it to you. If I want to communicate across a network, across the internet, if I cannot write it down or send it in post, if I need to send across an electronic network, then I would need to encrypt that key, okay. And then the question is what key do I use to encrypt the key that I'm going to send you? Well in this case we're going to cover, we want to share a secret key using symmetric, a secret key to be used for symmetric key encryption and to share that key we're going to encrypt it using symmetric key encryption. So the issues or how do we do that, what's our aim, two entities share the same secret key, that's what we want to achieve. Now one of the principles that we'll introduce in this topic is that we don't want to use one shared secret key forever, okay. That is two users exchange a secret key, we communicate for a day using that key, encrypting our data with that key. For security reasons it makes sense to change that key on a regular basis. Do not use that same key for the next three years. Why? Because the more times you use that key, the more opportunity the attacker has for trying to discover that key. Either using a brute force attack or using some other analytical attack. Or just trying to find your key via other methods of seeing what you've written down on a piece of paper and so on. So a general principle is that you don't want to use a key for too long. You want to change keys on a regular basis to make it harder for the attacker to try and find your key. Given that, how do we exchange a secret key? Different options and some of them are related. Four options listed here. First one, A, physically delivers a key to B, okay. I want to communicate with one other user. I write my key, I select a key, I write it down on a piece of paper, and I give it to that other user, not via the network. So I physically give them the piece of paper or somehow deliver the key to them physically. So we do not send the key across the network, okay, in that case. If I physically deliver it. Possible, very inconvenient. It's okay if I want to do it to communicate with a group of students. We could do that. But if I want to communicate with people on the other side of the world across the internet, it's not very convenient. And especially if I want to communicate with people now, right now, rather than having to wait a week to send by a post, then physical delivery of keys is not very convenient. It's time-consuming and it consumes a lot of effort. But it's possible. An alternative of that is that A and B want to share a secret key. They both need the same secret key. An alternative is to involve a third party, some other user, C. And get them to deliver the key. So for example, in our class, let's say all the students want to communicate securely. So one student, A, needs to exchange a secret key with another student, B. Rather than going direct to the other student, what you could do is that one student comes to me, the third party, C, and I give them a shared secret key. And when the other student wants to communicate with that one, they come to me as well, and I tell them the key that I gave the other person. So I, the third party, distribute the keys to the end users, those that want to communicate. That can be more convenient in some cases, say, in an organisation to have some third party, some central entity, to manage the keys and to distribute them. Still involves physical delivery, though. It's done not over the network, but via some other means. Then the next two, options three and four, related, in fact, depend upon the previous ones. If A and B already have a key that they've shared, then they can create a new key, encrypt that with the old key, the one they already have, and send it securely across the network. So in that case, if the two users have already shared a key, then quite simply, one user generates a new key, encrypts it using AES, triple depth, whatever, encrypts it using the old key and sends it across the network. And even if someone intercepts that on the network, they will not be able to see the new key because they don't have the old key, okay? So that's one approach, encrypt the key when we send it across the network. For that to work, A and B must already have a key. How do they get that? How do they get the key to start with? Anyone? Use one or two, okay? So in fact, this one, option three, and you'll see option four as well, depends upon one or two taking place in the past. So the option then is two users physically deliver a key. So both A and B have a key using option one. And then now A and B already have a key. So later when they want to use a new key, remember our principle, change keys frequently, when we want to have a new key, then they can use the old key and encrypt that and send it across the network encrypted. And number four is similar, except we involve a third party. That is, let's say A and C have a shared secret key already. B and C have a shared secret key already. Then when A wants to communicate with B, then C, this third party, can generate keys and send the same key to both A and B securely across a network. Again, it involves some physical delivery before we can get started. Let's compare them briefly. We'll see some of them take place in the later slides. Of course, option one and two, manual delivery or physical delivery, it's not very convenient. It's only really possible if there are only a few entities involved. So physical delivery may be, for example, the administrator of the network going around to every computer and programming in a key, typing in a key. So let's say in SIT, if we want to use encryption to communicate between all our PCs and laptops, then when you register your network, you have to go to the computer center and they type in the key to be used. So that's another form of manual delivery that is some human involvement in that. It only works when we have a small number of users or entities involved. Because as the number of users it grows, it takes much more effort to distribute those keys. And also across a small scale, that is it doesn't work across the globe. You cannot physically go to every computer, only say inside an organization it's convenient. So manual delivery in option one or two, option three or four require some initial distribution of keys. In option three, it requires the two users to distribute keys. And in option four, involves the users to have a key shared with user C and C distributes the keys. There are some issues that arise in that in option three, for example, when we encrypt our new key using the old key. Well, if someone discovers the old key, then they can find the new key. That's a potential problem in that case. The discovery of the initial key means that the attacker can also discover the subsequent keys. So we need to be careful how we use that. Using a third party is practical when we have large networks. For example, a large organization, because it's easier to have that entity distribute the keys than to have all the end users contact each other. We'll see some examples or some simple calculations in that shortly. So some general ways for how to distribute keys. We'll go through some of them in more detail. Let's say we're going to do manual delivery. And we have a network. Then one of the questions that arises is where do we perform the encryption if we want to securely communicate across that network? We'll describe these two. We'll use this example network to describe them. So this is a picture of a network where we have 10 hosts, the squares, A through to J, 10 computers in this network, small network inside SIT, for example, and some switches connected together and some routers. So small network, not very realistic, but we'll use it for our example. So we want to communicate between the hosts in a secure manner. That is, when A wants to communicate with J, for example, there's an application on computer A, wants to send some data to the application on computer J, we want to make sure that that data is encrypted so that if someone comes into our network and listens, tries to intercept the packets sent across this link, even though they can intercept the packets, they shouldn't be able to obtain the data. That's our goal. For example, here's our network. Let's say these links from CDE to the switch are actually wireless links using wireless LAN. They're not cables, but a wireless link. So CD and E are laptops and the switch is some wireless access point. Therefore, when E sends some data to someone else, they send it across a wireless link to the access point, the switch here. Same as my laptop sending wirelessly to an access point. It's very easy for someone to be sitting outside and to intercept and receive whatever I send. Whatever E sends across the wireless link, it's very easy to intercept all of those messages. Similar with a wired link, it's a bit harder to intercept, but it's possible. The difference with a wired link is that you need to be physically nearby to intercept. So let's say the wired link from this PC that goes into the socket on the wall and goes to a switch downstairs. Let's downstairs, it's upstairs. No, it's same floor, two rooms down in the computer center. So it just goes down there. How do you intercept what I send from this PC? If this is PCJ, how do you intercept it? What are you gonna do? You're an attacker, malicious user, break into our network. What do you need to do to intercept the packets that I send? It's across a wired link. Cut the wire, okay? All right, yes, basically. Let's say you've got your own laptop. You sneak into this building or a nearby building and one option is this blue wire here, this LAN cable. If normally we send our packets across here, if you can put a device, cut the wire and put a device in the middle that takes a copy of everything that's sent across there and sends it to your laptop, then you've intercepted everything that this computer sends. So it's possible, except you need physical access to this network to do so. Whereas with wireless LAN, it's a bit easier because with wireless LAN, I send to the access point, but my signal goes everywhere. You can sit outside, possibly even downstairs in the cafeteria and intercept my messages. We want to stop that. Here's our network. Assume an attacker can intercept along any link. How do we stop them from accessing our data? That's the question. Well, we use encryption. We encrypt our data. When he sends data, it encrypts it. So that even if someone intercepts across the link, they cannot see the contents of the data. Now the question is that we're trying to, we're going to address here is where do we encrypt? What are the options for, at what locations in the network do we encrypt? First option we'll consider is, let's go, let's say end-to-end encryption, called end-to-end encryption. First option, let's say every computer encrypts the data, every host. For example, when E wants to send to J, E takes the message that they want to send to J. They encrypt it using AES, RC4, whatever they choose, assuming they've distributed keys. We'll come back to that in a moment. They encrypt it, they send it across this link to the switch. The switch does its normal job of sends it to the router to switch for, router for, switch six, and it arrives at J and J decrypts. This is what we call end-to-end encryption in that it's the end hosts, the two points that are communicating that are doing the encryption and decryption. So that's one option. Another option is that have encryption being performed across every link. So, E wants to send some data to J. What happens is that the LAN card on E, when it has that data, it encrypts the data and it encrypts it with a key which is shared with switch two. Encrypts the data, sends it across the link to the switch. Then the switch decrypts the data, gets the original data back, the plain text, and then the switch encrypts it again to send across the next link to router one. And then the router one decrypts and then encrypts again to send across the next link. And we keep going until switch six receives the data, encrypts and sends across the link to J, J, the LAN card decrypts and gets the original data. That's link level encryption. We encrypt on each individual link. Which one do we use? Well, what are the advantages and disadvantages of each? Both of them provide our security from our attacker that tries to intercept on a link. Some attacker listens on this link. In both of those cases, whatever is sent across the link will be encrypted. So the attacker will not be able to get the message. With end to end encryption, E encrypts, J decrypts, across this link between switch two and router one, whatever is sent across there is encrypted. Contents cannot be seen. Same with link level encryption. Switch two encrypts, sends to router one, and if someone intercepts, again, the message is encrypted, they cannot see the plain text. So that objective of securing the data is achieved. How many keys do we need if we use link level encryption in this case? So with link level encryption, each endpoint of each link must exchange a secret key. E to send to switch two. Both E and switch two must have one shared secret key. How many keys are needed in the network? Not just for the path from E to J, but assume anyone else wants to communicate as well. So how many keys are needed if we use link level encryption? Someone's got 20, I can't remember the answer. Anyone? Where do you get 20 from? The number of links, okay? You count the number of links. And if you count, I can't remember, how many, one, two, three, four, five, you count all the links and 20 links there. For every link, each endpoint of that link has a shared secret key. So E shares a key with switch two. D shares another key with switch two, a different key. And C with switch two, and also switch two with router R1. So there are four keys shared there. Let's record how many we have with link level encryption. In our example network, we need 20 keys. What if we want to use as an alternative end-to-end encryption between hosts? How many keys do we need? That is, E wants to be able to communicate with J or any of the others. And similar with the other hosts. How many keys do we need? Count them or calculate. Anyone have an answer? But for end-to-end encryption between the hosts, we'll come to another special case later between applications, but between hosts. End-to-end, between hosts. How many keys would we need if we use this approach? Someone's got 25, I don't think it's enough. It's a few more than 25, but not many. How do you calculate it? I don't want you to count them all. You could, but what do you consider? Consider there are 10 hosts here. A through to J, there are 10 computers. So how many keys does A need to share with other hosts? A with B, A with C, A with D, up to A with J. So there's nine keys there. What about B with others? B needs to share nine keys with others. But in fact, one of those keys is shared with A, so we just count eight keys. And C, there's a key shared with A, there's a key shared with B plus seven others. And then add them up for the rest. And what's the answer? Not factorial, 45 in this case. You add them up. Nine plus eight plus seven. And to make your life easier, sometimes it's nice to remember a general formula. If we have, it's the number of pairs between these 10 devices. So let's say if we had just A, B and C, how many pairs will A to B and C, C to B? We have three in this case. If we have four devices, we have six pairs. And there's a general formula for that. How many pairs between N entities? And it's N by N minus one over two, where N is the number of entities. For example, 10, 10 by nine, which is 90 divided by two is 45 in this case. So if we used end-to-end encryption for this network, we'd need to share 45 keys. If we increase the number of hosts in this network from 10 up to 20, if we had 20 hosts, we'd need, what is it? About 200 keys. 190 keys, I think. 20 times 19 is 380 divided by two is 190. If we had 20 hosts in the network, let's say more hosts attached to this switch two, another 10 hosts attached to switch two, with end-to-end encryption, we'd need to share 190 keys. But with link-level encryption, if we attached another 10 hosts here, we'd need just 30 keys, another 10, because there'd be another 10 links to this switch. So in general, with link-level encryption, the number of keys that we need to exchange is much less than if we use host or end-to-end encryption. And that's the advantage or an advantage of link-level encryption. If we want to manually set up the network and manually program in keys, it's possible in this network with link-level encryption. What we do is for each computer, when the network admin, they set up the computers here, they program in a key. And same with a switch, there's a key programmed in for each link. That's possible for a small network. But to allow any host to communicate with any host, okay, with 10 hosts, 45 keys possible, increase it to 20 hosts, 190 keys, it means you need to program in 190 keys throughout that network. So as you increase your network to 1,000 hosts, then you need something like 500,000 keys to program in. So the number of keys grows rapidly in that case. So in link-level encryption, manual delivery of keys may be possible for small networks. End-to-end encryption, not so feasible. What's the advantage of end-to-end encryption then? Link-level encryption has this advantage of you don't need so many keys to be distributed. Why would we use end-to-end encryption? Why do you think you'd use end-to-end encryption in this case, instead of link-level encryption? Advantage of link-level, less keys, that's a good thing, but there's a bad thing. Anyone? Think about what the steps are to send from E through to J. With link-level encryption, take your data at E, encrypt, send it across the link, decrypt at the switch, get the original plain text, encrypt it again, and send the ciphertext across the next link, and do that at each device, correct? Two things. At each device, we need to encrypt and decrypt a performance issue, that is at the switch, we need to decrypt and then encrypt again. That takes time. And then at this router, we decrypt what we receive and then encrypt again with a different key to send across the next link, so performance is an issue. With end-to-end encryption, we encrypt at E only, and only decrypt at J. What else, so performance? Security, because in general, it's more secure using end-to-end encryption because we decrypt at the switch. So in memory at the switch, it receives a packet, the ciphertext, it decrypts, it has the plain text in memory, and then encrypts that plain text again and sends the ciphertext. So at some point inside the switch, the plain text is visible. So if an attacker can get physical access to the switch, they can potentially see the data, similar with each of the other devices in the network. If the attacker can get physical access to the devices, they can see the contents of your plain text. So that's the bad thing about link-level encryption. If we can secure the devices, then it can be a possible approach. For example, it's not very easy for you to get access to the switches in SIT because you need to go into the computer center and they have a door lock on that, okay? So they have another form of security. But if you don't trust the people who run the computer center in that they may want to intercept something that you're sending to someone else, then link-level encryption is not suitable in this case. Now consider communications across the internet. That is, this is a much larger network. And to end encryption, we have many more hosts. We need many more keys. That's a bad thing. But link-level encryption, if I want to communicate between my laptop and some server securely, I must trust that all the internet service providers between my laptop and the server are using link-level encryption and that no one is accessing their switches and routers and so on. I don't trust anyone in the internet to do that. So it's not suitable for a large network, link-level encryption. It's only suitable for small networks when, for example, one organization runs all the links. So summarize that. Link-level encryption encrypt across individual links. Each link endpoint shares a secret. The intermediate devices must decrypt and encrypt. That's some performance penalty. That's bad for performance. And for security, we must make sure that all links and devices support encryption. If this link didn't encrypt, then my data from E to J, I would not consider secure. Even if these links encrypt, if one of them doesn't, then all the attacker has to do is intercept on that link and they get my data. So we must have all links support encryption. With end-to-end encryption, the endpoints, the hosts encrypt the data. Now, the endpoints may be either the computer, the host itself, or in some cases the application on that computer. My computer runs multiple networked applications. A web browser and an email client. Rather than my computer encrypting all data, the web browser encrypts data and sends it to a web server. Separately, my email client encrypts data and sends it to an email server. So that's at the application level. Each pair of hosts or applications must share a secret key and hence there are many more keys needed. But the advantage is that it doesn't rely on intermediate devices for security. We don't have to trust everyone inside the network. You just need to trust the endpoints. And that's what's generally used in the internet for secure communications. What if I have on all of those 10 computers three different applications running? Three different networked applications. For example, one of the applications on E may want to communicate with its corresponding application on J. But at the same time, another application on E may be communicating with a corresponding application on I and someone else. So let's say there are three separate applications on each of those 10 computers. How many keys do we need? When we just had host to host, we needed a 45 keys. What if we have security or encryption between applications? How many keys do we need? Assuming three apps per host. Anyone with an answer? In fact, I'll accept two different answers. It depends on different conditions. Anyone calculate the simple answer? Three applications per host. We said with host to host, we had 45 keys. Three applications per host. Let's consider E and J, for example. There are three applications on each of those computers. Well, it depends on our assumption. If we assume that this application A, these are the applications, A will only want to communicate with A on this computer. A will, the application A will not want to communicate with the application B or C on this computer. So A with A, B with B and C with C. If that's the case, for example, A is a web browser, here it's a web server. This is an email client, email server, instant messaging, instant messaging. Then it's just three times 45. The number of keys would be three times 45. Is it 35? If we allowed A to communicate with application A, B or C on another computer, and also on all the other computers, what's the answer? If any application could communicate with any other application, then each pair must share a separate secret key. So how many keys do we need? How many entities do we have communicating? Maybe not the final answer, how would you calculate it? Again, three times 10 use that formula, correct. Effectively, we have three applications on each of the 10 computers. We have 30 entities that need to communicate. There are 30 different applications in the network. Each can communicate with any other. So one communicates with 29 others and so on. Using this formula, N equals 30. 30 times 29, it's about 450. 30 by 30 is 900 divided by two is 450, it's less than 450. So in this case, 450 keys or up to 450 keys are needed. And in many networks, we want to communicate securely between applications. Even in this small network, if we want to allow that, with just three applications, hundreds of keys are needed, depending upon the assumption, 135, 450. The point is with end-to-end encryption, we cannot rely on manual delivery of these keys. We cannot rely on someone passing around a piece of paper or going to every computer and programming in each key. We need some way to automatically deliver those keys because there are too many of them. So we need some automatic key distribution. And one approach is to use a key distribution center, some other device in the network that all of the entities trust. So we say a trusted third party, some other entity. Everyone else trusts them and they assist in distributing the keys. And we have different types of keys. And this is common terminology for different systems. We have our data that we send between entities. So the data sent between E and J is encrypted using a session key. To get this session key, the KDC distributes it to E and J. So although it's not on the diagram, let's say there's some other computer here, a key distribution center, a KDC. So what happens is that KDC distributes session keys to each entity that wants to communicate automatically across the network, not manually. And for the KDC to send a session key to E, it must be encrypted. And it's encrypted using a master key. So each host or application shares a master key with the KDC. And when we want to use a session key, we encrypt it using the master key and send it to the entity, E, J, one of those hosts. And then they use the session key to encrypt their data. So we have two levels of keys, master and session keys. In our network, let's say there's a KDC, a special server attached to router one. How many master keys do we need? How many master keys? Where the master keys are used to communicate securely between a host and the KDC. If A wants to get a session key from the KDC, they use the master key to encrypt that session key. So how many master keys would be needed in this example? What was that? Five, no. 45, no. 10. 10 master keys. Why 10? One shared between the KDC and A. Now I'm assuming between hosts here, not between applications. One between KDC and B and so on and KDC and J. One for each host or entity that wants to communicate. And then what happens using some protocol and we'll see an example soon when E wants to communicate with J, what happens is they go to the KDC and say I want to communicate with J. And the KDC creates a session key. Creates a session key to be used between E and J. And the KDC encrypts that session key using the master key shared with E, sends the session key across the network to E. And similar, encrypts the same session key using the master key shared with J and sends that to J. So that both E and J receive this session key across the network, it's been encrypted. So whoever intercepted any messages will not be able to see the session key. It was encrypted with the corresponding master key. So the distribution of the session keys is automatic. It's done over the network. Whereas the master keys are normally distributed manually. That is, we program into the 10 computers the master key. With manual delivery, we can do it when there's just a few number of entities involved, when there's a few keys. With session keys, it's better to automatically distribute them because there may be many session keys. In our case, we need, in our simple case, we need 45 potential session keys. And we have 10 master keys. Master keys would be manually delivered, whereas the session keys would be automatically delivered across the network. And the session keys are encrypted using the master key. So we've increased the total number of keys to 10 plus 45 session keys, 55 keys in total. But importantly, only the 10 master keys need to be manually delivered. And all of the session keys can be encrypted and sent across the network. Master keys can be distributed manually. Session keys are encrypted with the master key. And our data is encrypted with a session key. That's the idea of a KDC. We can look at this hierarchy of keys in this diagram. That is, when we have data, we want to send it across the network. We encrypt it with a session key, which provides cryptographic protection of that data. If anyone intercepts the message, they cannot see the contents because it's encrypted. Similar, whenever we want to send a session key across the network, we encrypt it with a master key. And therefore, anyone who intercepts that packet, that message, will not be able to see the contents, the session key. It's protected. And then we have master keys. They are not sent across the network. They must be delivered in some other, using some other mechanism, some manual delivery. For example, the user goes to the KDC and they type in the master key. Or maybe more convenient, that you go to computer center, computer center runs the KDC, the computer center gives you on a piece of paper the master key, or programs into your computer. So the master keys are delivered not across the network, but via some other secure channel. And this hierarchy makes it possible to use end-to-end encryption in a network. Although we may need thousands or millions of session keys, they are all distributed automatically across the network using some protocol. It's just the master keys which are delivered with manual delivery. Here's an example of a protocol that delivers keys between a KDC and the two users. Let's go through it. Let's get started now and after the break, we'll do some analysis of possible attacks. We have three entities. A wants to communicate with B. So computer A wants to send some data to B securely across some network. They could be anywhere in the network. They could be inside SIT's network or in the internet. So A is going to initiate some data communications to B, who's the responder. And there's this other entity, the KDC. And the KDC is trusted by A and B. And before anything happens, their assumption in this case is that there is a master key shared between the KDC and A and another master key shared between the KDC and B. Let's record them. And the notation used in this diagram, the master key is K, A and KB. They're the two master keys. Which means, and they were exchanged before this. They were exchanged manually somehow. That is, user A went to the KDC, the KDC selected a master key, stored it and told user A. And did the same thing with user B. Different keys. A only knows its master key. No one else's. The goal is for A and B to get a session key. So what we want is a session key, and in this case called KS, shared between A and B. So when A sends data to B, they will encrypt that data with a session key. So this is a protocol that assumes the master keys have been distributed and the goal is to distribute the session key between A and B. And there are five steps involved. In fact, the steps of distributing the key are the first three, step one, two and three. The last two are just for some extra authentication. Let's go through the steps and as we go introduce some of the notation. The first thing is that, so this is done over the network. So send some special packet. A sends a message to KDC saying, I want to communicate with B. Please generate a session key for me. That's the idea of message one. Saying I'm user A, I want to communicate with user B. Can you please create a session key and send it to me? Now the notation given here or what information is needed in that message, we need something about the identity of user A, IDA, that's who's making this request. The identity of the other user that we want to communicate with, IDB. N1 is what's called a nonce value. These are described on the next slide as well, a nonce value. The idea, we'll see the use for the nonce as we look at attacks, but one idea is one use is to prevent replay attacks so that we can identify this request. If it's replayed later, we'll be able to distinguish if it's the same as a replayed one or not. So we can sometimes think of as some unique identifier for the message or for the request. Often it could be a random number, maybe a time stamp. So some value that should be different each time we make a request. So if A sends a request to the KDC, five minutes later they send another request, they should have a different nonce value. If they use random numbers, long random numbers, they just generate a new nonce and of course it should be different similar with a time stamp, that something records the time, the down to seconds or milliseconds. So a nonce value, we'll see that come up in other protocols as well. But let's say just a random number for this example. Send it to the KDC. When the KDC receives this, they recognize this is a new request. It's not one of the old ones, it's not a replay of the old request because they see it's a new nonce value coming from user A. And what they do is that they generate a session key, KS. And then they send back this response. So in this protocol, the KDC chooses the session key that A and B are gonna use. So at the end of this, A will know KS, B will know KS, and KDC will also know KS. That's acceptable because we trust the KDC. So the assumption here is that A and B don't care if the KDC can see the contents of the messages, they trust the KDC. So the KDC generates KS and sends that back in a response. And the response really has two parts. The first part, and we see the E here is we apply encryption, some cipher using some key. So the first parameter of the encryption is the key used and then the second is the plain text. So the first part here, and I'll write it on the board to make it a bit bigger, we encrypt using the master key of A, all of the data inside square brackets, KS, IDA, IDB, and the nonce. That's the first part of that message, message two. This is the plain text and it's encrypted with the master key key, key KA. What is the plain text? The plain text is the requested data, IDA, IDB, nonce, and one, same values as what was sent in step one, as well as the session key, the key that A and B are going to use. Encrypted with a master key, KA means only user A can decrypt because only A has K, A. A and KDC, the KDC sent this message. So when A receives message two, it decrypts using its master key and when it decrypts, it checks the values. Do these values, IDA, IDB, N1, match what I sent in message one? To just check that this is the correct response for the message that I sent. And also it learns the session key, KS. So after step two, user A knows the session key. User B doesn't yet. User B doesn't know anything's happened. Message two comes in two parts. We see a concatenation here, the second part. The second part I'll draw underneath is encrypt with KB, KS and IDA. That's the second part of message two. Can user A see the contents? User A cannot see the contents of this part. It's encrypted with the master key of B. So even though it's sent to A, message two, this last part here, user A cannot read the contents of that message. It's encrypted to using the master key of B. What's inside we'll see is the session key and the identity of A. But A cannot see that. All A does is takes that ciphertext, because this is ciphertext, and sends it as is in message three. They send it to B. So you see message three is just the end part of message two, this part. So all that's happening is that the KDC is sending the session key to both A and B. The way it does is it sends it to A and A fords it on to B. And message three, when B receives that, B can decrypt because B has KB. They decrypt and B learns the session key and they can check. This session key is to be shared with user A because inside this third message is the identity of user A. So really what KDC does is generates a session key and distributes to both A and B. And it's just that the second part goes via A. B is certain that this message can be trusted because it's encrypted with the master key and it shared that master key with the KDC. So it knows that the KDC generated this session key. And it knows that the KDC said that this session key KS is to be used with A, no one else. User A could not have modified that message because they didn't have KB. So that's the key distribution steps, those three steps. The last two will go through later for authentication but once that's completed, A knows KS, B knows KS. Now they can take their data and start encrypting using KS to send their data encrypted across the network. So an example of key distribution using KDC. Always a question on the exam about this or something similar, easy one to ask questions about. It captures many concepts in the simple protocol. Any questions on how it works so far? We'll go through four and five in a minute or later. Why is this part? So in question two, KDC sends all of this to A. It's in two parts. Think of the first part is the part that goes to A. The second part is the part that goes to B. And the idea is that inside is of course the session key but also some information to indicate that this in the nonce indicates this response, message two is a response to message one. It's not a replay or we can detect if it's a replay because we would, user A would know the nonce value it sent. B doesn't need this. B doesn't need the nonce value. B doesn't need its own identity. Okay, so why did we include ID, A, ID, B because they were in the first message. That was A telling KDC, please generate a session key for me and B. All B needs is a session key and the identity of the other user. So long as it came from the KDC, B will trust it. So there's authentication happening here as well as secrecy or privacy. Is it a bit clearer now? B doesn't need the first part. It's only for A to check and receive KS. Easy so far. Make sure you're aware of the notation that's used, the identity, a nonce value, encrypt with a, it's clear on the board maybe, encrypt with a key, encrypt with a key, that plain text. And our normal assumptions hold that is you can only successfully decrypt if you have the key. So only A can decrypt the first part and only B can decrypt the second part. And that also provides authentication, yeah? Okay, what are the last two steps? These are just some authentication to check that message three is not a replay. A replay attack involves an attacker taking a previously sent message. Let's say three has been sent to B and they've received that. There's no four or five. Assuming there's no four or five. If three had been sent to B, an attacker can intercept this, but they cannot read the contents because it's encrypted with KB. They cannot read the contents, but they could replay it at some other stage to try and fool B into using it again, possibly because they wanna get B to use the same session key and maybe perform some other attack. Get B to keep using the same insecure session key. So a replay attack involves resending message three. How the attacker can take advantage of that depends on what happens after that. But what the message four and five do is allow A and B to detect if that's a replay. Because what happens if it's a replay, what B does is responds encrypting with KS some other nonce value, N2. So B chooses a random number, N2. Encrypt it with a session key. The attacker should not know the session key. Because the session key was encrypted before, we assume the attacker doesn't know the session key. So B sends this random number encrypted with a session key. Who can decrypt it? The attacker cannot, A can decrypt it because A has the session key. But if A didn't send the first message, it will not reply to message four. It would detect something's gone wrong. So if we don't send message three but we receive message four, then that's an indicator of possibly a replay attack. If A did send message three, B checks. It's like a check saying, did you really send this message? And A sends back a response saying, yes, I really did send message three. And four and five cannot be faked or generated by an attacker because they involve encryption with a session key. And the attacker doesn't know the session key. The idea is that N2, some nonce value, say some random value, the response five, you see on your notes, it's a function of N2. For example, increment N2 by one. And there's no way for the attacker to guess what N2 was. It's a large random number. They cannot guess what it was because it would take a brute force attack. So unless the attacker knows KS, they will not be able to repeat. They will not be able to perform steps four and five to perform a replay attack. So if there is a replay attack, either step or either A will not respond with message five and then B, when they don't receive message five, will detect something went wrong. They'll detect some attack and then take some other approach. So four and five are just there to prevent an attack on some of the replaying messages. Steps one, two, and three are distributing the key. If there was no chance for a replay attack, then I think steps four and five would not be needed. Let's have a break. Let's look at this a bit more after the break and look at some other ways to do key distribution.