 So there are three steps to distribute the key the aim The aim is that a and b know the session key and that happens after step three Step four and five are just some extra checks They're called the authentication steps to check really B is checking With a did you really send this message? So B sends back message for which is has the meaning did you really send me message three or maybe someone else replayed it from before and If a really did send message three it will respond with message five If a didn't send message three it is an attack by some malicious user who replayed it That is it was sent before by it by user a but some malicious user intercepted and And then at a later time replay that Then when a receives message for it detects something's gone wrong If I didn't send message three, but I received message four then something's gone wrong And they'll take other steps to make sure that B is informed or they will not continue so that they will not use this session key similar if B does not receive message five then it assumed something's gone wrong Also, what's inside message four and five? Message four contains a nonce value Generated by B and two in this case so another for example random number a different random number B chooses a large random number Encrypts it with KS the session key Only a should be able to decrypt a malicious user should not be able to decrypt and find the nonce value and They should not be able to guess the nonce value because if it's a large random number It would take too long to guess so you very there's no no practical chance to guess it so if a malicious user did send message three and Receive message four and they try to respond with message five then they cannot send message five Because they don't know the session key and they don't know the nonce value Message five it says here f of n2 a function of n2 It can be any function a simple function like increment by one So B chooses a large random number and to check That it really did come from a then aim sends back some Modification of that large random number for example that large random number plus one if B doesn't get That correct modified number in a response then it assumes something went wrong So these are just to check that an attacker doesn't replay a message Note that the KDC doesn't send the session key direct to be in this case It doesn't need to to cut down on messages There's one message to KDC saying I want a session key to be KDC responds. Here it is. Here's the session key and A forwards on the part of that message that contains the session key that B can decrypt So as a response as a result of message three being received B has KS and Previously from message to a has KS. They have the session key When a now sends data to be so after step five everything's done. They start sending data They encrypt with what what do they encrypt their data with which key? Which key now they're sending data. What key are they going to use? They use the session key So remember the session key Session means your communication session for example, you're downloading a file from a web server So the session is that duration of that TCP connection while you're transferring data or Maybe if this is for example for voice communications the session maybe for a voice call a Session can be defined different ways, but it's usually for some Some group of communications can be multiple messages Maybe we use it today this session key and tomorrow if I want to communicate with B again I may follow these steps again and get a new session key because it's it's an advantage to Keep changing your session keys. Keep changing your keys Same as you change your passwords on your accounts on a regular basis You change your pin number your pin for your your ATM You change Well, not everyone change. There's that home lock But the idea is that if you change the key that there's less opportunity for the attacker to find that key So this uses the KDC when a sends data to be using the session key to encrypt Note that KDC can see the data It's possible for the KDC to encrypt as sorry to intercept any message sent from a to be If it's encrypted with a session key the KDC can decrypt that Because it was the KDC that generated the session key the KDC knows KS so a B and the KDC know KS and Therefore we must trust the KDC not to make use of that data So that's where we say it's a trusted third party That's the notation that was used So this approach involves we need this other server type entity in the network a KDC. So let's say All the computers in s it's land all the desktop PCs at least in the office Officers in the labs. We wanted to use encryption between all of them Then we'd have some special server that acts as the KDC and There will be a master key programmed into each computer shared with the KDC and Then there will be a protocol that when one computer wants to communicate with another the first one contacts the KDC the Katie across the land the KDC sends a session key and that first computer then forwards that session key onto the Destination computer and then the two computers send their data securely between each other using the session key to encrypt So we need some server or this this KDC in the network In large networks, you can have a hierarchy of KDCs because Let's say a large network SITs network. We have two campuses We have one kitty KDC in this campus a second one in the other campus to serve the users in that campus and we can have in fact the two KDCs can Obtain and distribute master keys via a top level KDC So we can have some hierarchy of KDCs that help in distributing the keys So one for each land or building and then a central one to exchange keys between hosts in different subnets and As you get larger you can have for performance reasons multiple KDCs and having multiple KDCs also Spreads the effort around It means that one KDC doesn't become a performance bottleneck and also means if one KDC is compromised then the others are not okay compromised if If someone can get access to this KDC a Malicious user then they can find all the master keys and all the session keys that the security of our system fails So we must keep the KDC secure usually physically secure if it's a server Because that's a key point of the network so having multiple KDCs means that if for example the KDC in Runksit is compromised someone gets access to it at least it means the Communications in this campus can still be secure so long as the KDC here is secure So there's advantages of having multiple KDCs. So a hierarchy of KDCs another concept How long should we use the session key for? Every time we want a new session key we must go through this step these five steps There's some communication overhead So every time my computer wants a session key with another computer we go through these steps We send some message to the KDC get a response If I want to change session keys, then we go through these steps again So there's a trade-off here. You want to change your session key as often as possible for security because the Fewer times you use the key it gives less opportunity for the attacker to discover the key So you want to change as often as possible But the more times you change the more communications overhead of implementing this protocol So there's some trade-off there Shorter lifetime of the session key the more secure but the more overhead of the communications The more impact on performance So when in practice do you change the session key? It depends on the application on the network some examples are You change you could have a session key for each TCP connection Every time you connect use establish a TCP connection from client to server For that connection get a new session key. That's one example Or you could do it on a time basis every day get a new session key Or every five minutes get a new session key the more often the more secure So depending upon your applications and what your security requirements are you can have a scheme to change session keys Using a KDC has a big disadvantage. You must trust the KDC So it's okay in an organization. That is all the users in SIT all the employees For communicating securely inside SIT We need to be able to trust the computer center who runs the KDC. That's okay Because we all work for the same organization. We must trust each other, but What if you are in a Circumstance where you do not want to trust some central third party the two entities want to communicate securely But they don't want someone else to know their key Because again the KDC knows the session key So you can vary Modify the scheme to be a decentralized approach There's no KDC involved so a protocol for exchanging Session keys The end result A and B have a session key KS The big difference here is that for this to work Each user must exchange a master key with each other user So in this example, there's a master key KM shared between A and B manually delivered in the past and If A wants to communicate with C Using the same approach there must be some master key exchanged between them and Then they use this protocol to exchange a session key So in this case, there are many more master keys That's the problem with a decentralized approach every user Exchanges a master key using manual delivery with every other user and we get we no longer have it our end by end Minus one divided by two master keys many master keys. Whereas in Our centralized approach we need one master key for every user and master keys Whereas with decentralized we need end by end minus one over two approximately in the order of n squared master keys, so That's the problem with a decentralized approach if you don't want to use the KDC you need many master keys You may ask well if we already have a master key then why use us why Perform this protocol if a has a master key with which stuff shared with B Why do we need to do this? What's the advantage? So this scheme assumes AMB all already know KM the master key So why perform these steps? So we can change the key that we use to encrypt our data frequently So this assumes a nodes KM and B nodes KM Let's write it down This decentralized scheme assumes that AMB have already shared a master key KM Then they follow these three steps and the result is that they both have a session key AMB share a session key KS Then when they want to send data they encrypt using the session key Why not not do these three steps and just encrypt our data with the master key Well, it's this concept of we want to be able to change our keys on a regular basis Let's say We've got a Million packets to send a million pieces of data Let's put some numbers to it a million packets to send between AMB if we don't use this scheme and AMB have some master key and we encrypt All of our data using that master key Then we can think of those one million packets. We've encrypted All of them using our master key. So if let's say we've used our master key one million times Now by using this scheme AMB share a master key But then they use that to generate a session key then what they do is that they encrypt their data with the session key Let's say we use a session key for just 1,000 packets and After encrypting 1,000 packets we change session keys and then encrypt the next 1,000 packets and then change session keys again then with session key one the first one We'd encrypt 1,000 packets and then we'd repeat this these three steps and get a new session key session key to and Encrypt a thousand packets and We do that a thousand times KS 1000 why a thousand because we have a million packets in total to encrypt So just put some numbers to it so we can compare How many messages? Using this approach how many messages were encrypted with the master key? So what we do is we have a master key Every time we want a new session key. We apply this protocol One of these messages message to we encrypt using the master key You see one and Three we do not So we use the master key just one time in this case We use it One time when we every time we change session keys. We use the master key once So the total number of times we send something across the network using the master key in this example is a thousand times One for each time we change the session key The result is By using this scheme we use the master key on total one thousand times We use session key one one thousand times session key two one thousand times and so on The less times we use a key the harder it is for the attacker to try and discover that key If we didn't use session keys, we use the master key one million times By using the session key we use the master key just one thousand times in this simplistic example That is we use it much less than in this case. So that's why we'd consider this more secure So yes using the master key allows us to change session keys But the problem with this approach We must Manually deliver master keys between each pair of users. So only very useful for small networks before we move on any questions about these schemes the KDC and the decentralized approach so those approaches were about getting a session key Between A and B and then they use symmetric encryption to encrypt their data And the way that we got that session key securely was we encrypted with a master key Also using symmetric key encryption that is The E in here is using symmetric key encryption AES triple desk, whatever Let's consider a different approach The goal now is to distribute a shared secret key same as before But to do that we will use asymmetric encryption. That is public key cryptography And we'll go through three different schemes for how to do that. We'll go through two ones that just a combination look Remember that with public key cryptography or asymmetric encryption We generally don't want to use it to encrypt all of our data So the idea is for the data we send between A and B use symmetric encryption You only use asymmetric encryption when you have a small amount of information to send because it's too slow otherwise So as you saw in your assignment one way to use asymmetric encryption is to exchange secrets exchange secret keys Let's go through some examples. One of them you've seen is Diffie helman, but let's go through some other ones Here's a very simple one. A Sends its public key to B and Its identity Saying I am user A. Here is my public key and B selects or generates a session key KS and Encrypts that session key with a public key of A Sends it back to A and now B has the session key B selected it and A can decrypt this message because A has its own private key No one else can decrypt this message because no one else has the private key A and Therefore the session key has been received by A and not no one else So this is a very simple way for A and B to get this shared session key KS It provides confidentiality for the session key It relies on public key cryptography this encrypt here this E. We're using something like RSA Using the public key of A to encrypt and you know if you use if B uses A's public key to encrypt Then only a can decrypt because only a has the corresponding private key So only a can decrypt and discover KS simple See if you can attack it There's a simple what's called man in the middle attack that can be performed in this case try and work it out You're the man in the middle between A and B. See how you can defeat this system Not a meat in the middle attack that we saw with double desk. This is a man in the middle attack Give you five minutes to see if you can break this system So what you can try and think about is okay if you are C in the middle And you could intercept these messages. What could you do to fool A and B? Into thinking they have a session key that's secret see if you can defeat this system So one way to do it is start drawing a diagram where you have a C and B and send some messages There'll be a bonus for the first person who can show me the correct answer before I draw on the screen On the board come on now use your brains and start performing an attack not correct yet So think you're the or there's an entity in the middle Entity C for example, what can they do sounds on the right track draw the picture Any attempts? Any solutions? People are on the right track on the right track Hint there should be there'll be four messages at the end First person to draw on the board will get the up bonus bonus Bonus for the next quiz the next in class quiz Next or the last one if you get it wrong you get a penalty No, no, no is he correct Is he correct? Doesn't work have a look see why or what happens when this man in the middle M Sends this second message Think about what what is this achieved? So there's a question should this be IDA or IDM It should be IDA because M is pretending to be a That's the idea masquerade So let's see if it works, and I think I don't even have to draw it because I think what you've got is correct so the idea is that A and B Need to get a session key ks and their their goal is that no one else knows the session key What the man in the middle attack does is that this man see intercepts the messages and tries to do something such that see also knows the session key and A and B don't know that anything's gone wrong. That's important that A and B think everything's gone correctly Because if they detect something's gone wrong, then they will not use that session key so a sends its as shown a sends its a normal original message the public key its own public key and Its identity so that's the original message and The man in the middle then Pretends to be a and the way that it pretends to be a is sends the identity of a but Sends a fake public key so We see here the identity of a and a fake public key that is the public key of this man in the middle so I'll copy your diagram and I've just called mine C so It's still the identity of a So B thinks it comes from a but the public key has changed. I call it public key of C B uses its own public key Sorry C uses its own public key the man in the middle uses their own public key So B is received a request really according to the protocol B receives a request. This is from a Here's the public key Generate a session key encrypt it and send it back Using the normal protocol when B receives such request it encrypts with the public key it received and Sends back the encrypted session key so B responds not knowing it's from C thinking it's from a and we encrypt using The public key of C in this case this public key. We received the chosen session key KS Leave your board leave it on the board Okay so B chooses KS the session key that it's going to use with a and Encrypts it using the public key that it received from a Well, at least the public key that it thinks it received from a but in fact it sees public key What does C do C decrypts because C knows the C knows the private key So decrypts and when it decrypts it gets KS So C knows KS and Now to make sure that a and B think nothing went wrong C sends a message to a encrypting using the public key of who of A Okay, the public key of a is known. So we encrypt using the public key of a The same KS Not a different one So when a receives this he thinks oh everything's okay. I will decrypt with my private key and I'll get KS and end result a Has KS and be have has KS. That's good from a and B's perspective and Nothing's gone wrong from a and B's perspective nothing. They can detect because a sent the expected message and Received the expected reply that is some key encrypted with a's public key Because it successfully decrypts with a's private key. They trust this receive message similar be receives a request Identity in public key encrypts with the public key the session key So a and B don't know anything's gone wrong The man in the middle now knows the session key So what happens next is a has some data to send to be a encrypts that data with KS So now a takes some data encrypts it with KS the session key sends the data encrypted with KS to be B receives it But at the same time C takes a copy and decrypts it Okay, because C has KS now anything sent between a and B encrypted with KS C also receives And a and B don't know Okay Okay, so what about be receiving this message the public key of C concatenated with ID of a You in your assignment you saw they were Diffie Hillman public keys We remember in the assignment one one step was to generate your public key and there were two values that in the public key Let's see if I've got one to show you an example Whose public key can I show you? Let me find an example public key and we'll see here. So Here's a public key So when B receives this public key as well as the identity of a This is a Diffie-Hellman public key. It can be any other type of public key How do you know whose user this is if you look at this? There's no information in there that says who's it is so When you receive this public key Okay, between the begin public key and the end public key when you receive that there's no Information in there identifying who it is It's the ID that identifies who it is So there's no way to just to know is this really a public key or is it? sees public key When B receives this message it doesn't it cannot tell it trust takes the identity. Okay, since the identity is a Then let's assume that the public key is that is that of a and that's the weakness in this scheme That B cannot confirm that this public key is in fact someone else's So B does not detect anything went wrong there So in this case this says the public key of Steve, but in fact It is not my key you if you look at them. They're identical in fact Just because the file name says Steve it's someone else's public key in this case Okay, so there's no way by just looking at the public key to know who's it actually is and That's the problem with distributing public keys We need some other way to confirm that this is in fact this user's public key. It's not something else someone else saying It's a user's public key, but it's in fact pretending to be someone else's public key. So This in this case was one user Saying here's Steve's public key, but in fact it wasn't my public key It was another user's public key pretending to be me. So this simple scheme for key distribution Does not work if we can have a man in the middle Who can intercept and and generate messages? It's only useful if there's no opportunity for an attacker to intercept and modify messages So if an attacker cannot insert messages, then this scheme works fine But if an attacker can intercept modify messages, then it's insecure When may they not be able to maybe the link if the link is secure It's an optical fiber link and there's no way for them to Create new messages on that link Then it's impossible for them to attack this scheme. So it's okay in some cases, but not all across the internet Not good because here's my computer. Here's the Facebook web server All someone has to do is get access to some ISP somewhere in the middle Somewhere in the internet intercept the message and modify the message and they can attack this scheme Modification or an alternative scheme and will we go through it? I think you can study this one in your own time It's just an alternative scheme also using public keys There are others as well. Okay, I want to get on to the next topic. This one's about done Diffie helman we saw was another way to use public keys to exchange secrets So we saw that in your assignment There's not much to say about this one Maybe the only thing to point out in this one. We provide some form of authentication We encrypt with a private key and a public key encrypting with a private key. Remember is signing something So in this scheme that uses both signing and also Encryption or confidentiality Again, this one assumes that the public keys are known and correct. So we see a encrypts with the public key of B Of course a must know the public key of B in this case So there's some assumption about what's known prior for this work Other ways for distributing symmetric keys is combined with a KDC so so you can use a Combination of the KDC for secret key distribution and also the public key distribution So we saw with the KDC. We assume the master keys were distributed manually on alternative and a foot an alternative to that is to use Public key encryption So to distribute the master keys use public key encryption using one of the schemes that we've seen And we'll see later some issues with Key distribution of public keys So the mainly that simple one and the man of the man in the middle attack is what I wanted to cover on on those alternatives Let's introduce the next topic and then show a few examples and then next week we'll finish on the next topic This is now different the previous approaches were about getting a shared secret to the other side Now we have this problem of how do we get public keys to the other person and we just saw a problem. We saw the problem that user B Received a message with the public key and they didn't know whose public key it was They just assume since it came with idea. It must be a's public key and that was the floor in this Key distribution scheme That's why it didn't work because be received a public key and there was no net way to be sure that it was in fact A's public key or M's public key So distributing public keys is not easy Because anyone can send out a public key and say this is Steve's public key So we need some extra mechanisms We'll go through and look at some general approaches and then some specific protocols for doing it So by design public keys are made public everyone can know them But we have this issue how do we ensure that a public key of a actually belongs to a and not someone Pretending to be a that's what we had the problem here different approaches and some of them are related public announcement post your public key on a website on a bulletin board or Print it out and put a stick it on your door of the office, whatever, but somehow announce your public key Or have some directory Some server that stores public keys and when you want someone else's public key You contact that directory that server and it gives you the public key of another user And then we'll see some some protocols related to those two public announcements so Okay, at the end of your email you include your public key the like the value that I showed for your Diffie helman public key You include This text at the end of your email or you include it on a web page or in some forum and then people know your public key It works except as we know How do we be sure that the public key being announced is actually for that user? It's not someone pretending to be that user Well Okay, you may say if you receive an email from Steve at SIT to you a CTH and it's got a public key Then you know it must be my public key, but I think we saw in one of the Earlier lectures that it's very easy to fake an email address so you can receive an email that looks like it's from Steve at SIT, but it's actually from some student and It's got a public key. You think it steves, but it's in fact someone else's so We need some way to To be sure that it's a user's public key Just making public announces announcements Not enough you could have some form of directory to automate this process You have a server and again each user Who has a public key publishes this their Key in some server and when you want another user's public key you contact that server and download their key Now this will work if If the users when they publish their key provide some form of identification Okay, let's say this is some special web server It's run by me and all the students need to provide their public key So what you do is you come to my office. You show me your student ID. I check your photo Okay, I'm I confirm this is actually you and this is your correct public public key So if there's some identification when the key is published in the directory Then when someone receives the key, they assure that it is the correct key So we need some way to ID the correct users Of course, we need to make sure that the directory cannot be compromised that someone could not put in a public key that is a fake or for some other user How can we automate this process? What protocol can we use to? Publish and obtain public keys of other users That's what we're going to cover in these two slides. We'll just introduce I think one of them So here's a way that we have users that want to communicate and To communicate they need to know each other's public key so B wants to know the public key of a and Similar a wants to know the public key of B in this case. We have this this directory. It's here. It's called a public key authority It's a case of publicly available directory and This protocol assumes that user a has published their key with the authority So the authority has a list of keys and then the protocol shows how do we obtain other users keys? Let's go through it So the assumption before any of these step steps happen is that a has gone to the authority and saying I am user a and here Is my public key? So let's take a record of who knows which keys at the start a knows its own public key and its own All right. We use lowercase a and B A knows its own public key and private key Every user knows their own key pair Sam is user B B knows PUB and PRB and Also, the authority has a key pair. So everyone has their own key pair in this protocol and Also, we should So we assume that each user has published their public key at the authority What that means is that a has gone to the authority and said here is my public key and We trust that so there's been some form of identification taking place there So the authority also knows PUA and PUB and Finally when you go to the authority and say here's my public key at the same time the authority Gives you their public key So user a knows the public key of the authority and so does user B This is the assumption at the start of this scheme The aim is for a and B to get each other's public key and to do it securely so they know for sure it is when B receives a public key that this is a is public key and Same for user a and it's quite simple to get started what happens is let's say a wants to communicate with B So a will need to know B's public key So a sends a request to the authority saying I want B's public key some form of request and Here we have some new notation t1 is a timestamp Similar to our nonce before it's used to identify this request a Different request at a different time would have a different value of the timestamp So a sends a request saying I need to know The public key of B so inside this request would be identifying a and B The authority looks for the public key of B and and Sends it back to a but importantly The public key of B, which comes back to a is signed by the authority When I say signed I mean encrypted with the private key of the authority Recall when we encrypt with a private key Anyone can decrypt, but it's a confirmation that it came from that user So a request B's public key in step one in step two The public key authority sends back B's public key because the authority has it it's stored in the directory and Importantly they sign it using their private key When a receives message to they verify the signature How do they verify it? How does user a verify the message to? using the Using the public key of the authority good Because it's encrypted with the private key of the authority that is signed by the authority when we receive it we decrypt So a decrypts using the public key of the authority which they already have and they trust And if it successfully decrypts that it means it must have been Encrypted with a private key of the authority which means it must have came from the authority It didn't come from someone pretending to be of the authority That's the purpose of this signature It's not from some malicious user saying here's the public key of B well We must trust that the message we receive in fact is the public key of B and we do that using the signature a Has now the public key of B and they know it's B's public key because they it was signed by the authority And they trust the authority The next step step three Because a wants to communicate with B. They send a message to be Confidential message encrypted with these public key Saying I am user a and I want to communicate with you and then B does similar to what a did requests a's public key and The authority sends B the public key of a So steps four and five Almost identical to steps one and two Except from B to the authority instead of a to the authority and after step five B knows the public key of a so after step after step two a Knows the public key of B and after step five B knows the public key of a They trust them because they were signed by the authority and we trust the authority in the system and Similar to what we saw in the KDC we have some final messages to prevent replay attacks some final authentication we see again sending nonce values and Responding with nonce values just to confirm this message actually came from you. It's not someone else replaying that message so this is a way for using an authority to Discover other users public key and be sure that That public key is of the correct user 15 minutes to go. We're okay Any questions on how we use of an authority? So think of this for example I'm the authority You come to me You show me your ID you show me your public key I store your public key and every student does that I store every student's public key So that happens at the start and at the same time when you come to my office. I also give you my Public key. I'm the authority So every student knows their own key pair and the authorities public key. That's the setup of the system Now when two students want to communicate They need each other's public key and Because you don't trust other students what you do is you contact me first you say I want student bees public key I Give you student bees public key and importantly. I signed that message. So you're sure it came from me You contact the other student Saying I want to communicate with you that triggers them to contact me the authority asking for user a's public key and I Give the student user a's public key signed by me and because you trust me Anything signed by me you trust the contents. What we'll do next week is go through an alternative provide similar features, but it performs better That is it's more practical practical to use in a large network and it's Certificates and this is what's used in the internet when you access secure web servers a digital certificate So we'll spend some time going through how we use a certificate. What is a certificate? what do they look like and What your web browser? How they store them and manage certificates? Let's do that next week We'll stop there and What you'll do What you'll do is So that you can be up to speed next week so we can go straight into certificates Make sure that you look at those these diagrams that we've gone through for KDC through to decentralized and finishing with this one so Given a quiz or given a exam question, which normally gives you such a diagram You're not expected to remember these diagrams, but given one such a diagram answer questions about what's happening What can go wrong so understand the notation and what type of attacks may or may not be possible? Let's continue that next week enough for today