 So We have always said public keys are public, but we now have this issue Well, how do we really distribute them such that we know we've got the right one? It's not someone pretending to be a user Well different approaches public announcement yell it out So what I do I generate my public key and while we're in the class I read out the values Or maybe a signature of the values You download my public key. I read out the values and you confirm because you see it's me You trust it's me and see that that is my public key. Now, you know that you have my public key So some form of announcement That works on a small scale when you're physically close to people But it doesn't work on a large scale and across a large area Have some form of directory like a website where everyone uploads their public key and When you want to get someone it's public key you go to that website and download it But we have that problem. How do we trust that the attacker hasn't modified the values on the website and Then we'll see two more secure ways a public key authority and public key certificates Public announcements just send the public key across the network But we saw with the simple key distribution scheme that doesn't work because of a man in the middle attack if User a sends its public key to be There's no way for B to know for sure that it's got a public key. It could have been an attacker in the middle So That's the problem with that approach Now the announcement may be done via a network It may be via old means of publishing it on an email or a website or a newspaper Maybe a little bit more automatic use some special directory Where you publish the public keys in the directory in advance and When you want to let's say B wants to learn a's public key It contacts the directory and downloads a's public key But same problem we have how do we how does B know that it's got a's public key? We need some form of authentication So we'll arrive at using an authority What we'll do is that each user has their own key pair They're going to publish their public keys in the directory and The directory will call here the authority the public key authority and When a user wants to communicate with someone else, let's say a wants to talk to be a Will contact the directory or the authority here and say give me the public key of B a will contact be and B will also need the public key of a so it will contact the authority saying give me the public key of a You will get the public key of a and then they'll do some final authentication steps to check that they're communicating with the right entity This can happen automatically. So this is a protocol that can be run between the different computers involved So whenever a wants to talk to be it we go through these seven steps We'll go through them in some depth look at the messages and look at the Some of the design issues here some of the advantages and disadvantages of doing this remember the aim is that a knows B's public key and Also B knows a's public key if we know the public keys and we're sure they are the correct public keys Then we can use them to exchange secrets or whatever else we want to do later The aim is to exchange public keys Let's go through the steps and and keep track of what What we know and what we learn along the way First we'll list what is known by the entities before any of the messages are exchanged. So A wants to talk to be we're going to exchange these seven messages But before that we assume that a knows some information B knows some information and also the authority What do they know at the start? Everyone knows their own key pair. That's the first thing. So we'll list that a knows The public key of a and the private key of a B knows its own key pair and the authority also has its own key pair So we assume they know their own key pair But also before any of the exchange takes place We'll assume that the users have all published their public key to the authority That is the authority also knows Pua and Pub and they are the correct public keys An example being I'm the authority and Every student comes to my office. They show me their ID I confirm that stem and they show me or Electronically give me their their public key and as the authority I store that in some database So the authority knows the public key of a and the public key of B Our aim is for a to know the public key of B and B to know the public key of a what else When a went to the authority and gave The authority its public key the authority gave a The public here of the authority. So at the start a also knows P you of the authority and so does be I just list that here In other words every user must exchange their public key with the authority before this works If we have a million users, they must all exchange with the authority Now this scales okay because as you increase the number of users that the number of initial exchanges increases linearly So this centralized scheme like the KDC We need one manual exchange per user But that must take place securely in advance So now what we want to do is a communicate with any other user in this case B And we want to do that automatically because let's say we have a hundred users if there are a hundred users there were 100 manual exchange with the authority a exchange with authority B with the authority and the hundred users all did it centrally to the authority 100 manual exchanges, but now we want to allow any user to communicate with any other user They all need to do an exchange. How many possible exchanges are there? We are hundred users. How many pairs of users are there? If you remember from two weeks ago Anyone remember the equation if you have 100 users, how many pairs are there between them? 4,450 100 times 99 divided by 2 So about almost 5,000 so The reason we can use manual exchange with the authority in this case is because we only have 100 to do manually, but if we wanted to do manual exchange between the users We'd have almost 5,000 exchanges many more and that becomes too inconvenient so that's a It's okay to manual exchange with authority, but not between users Hence we use this protocol of seven steps to exchange between users First step a sends a message to the authority some form of request It doesn't say in this picture what the request is, but maybe it contains the identity of a and b So we just say a request think the request is saying I'm requesting the public key of B So the request actually may contain at least the ID of a and the ID of B What's T1 a timestamp? So we send a request to the authority. I'm user a saying I want to learn the public key of B and So that request should contain my identity. I am user a the identity of that Entity I want to communicate with B and a timestamp T1 Do we do not hear saying this request came at this particular time? Why do we have a timestamp? What's the general type of attack we try to defeat with timestamps? What's the name of the attack? replay attacks Hard to perform if there's a timestamp we send at this message now We include the current time very accurate if someone resends this message Five minutes later the receiver can easily detect. This has been delayed by five minutes or it's been replayed Let's not trust this recent message. Okay, so it provides some Some information to the authority that this is a current message and Also, we'll see it it comes back in the response So the a knows that the response message to Corresponds to a response to the initial request so it's like some sequence counter or some value that The receiver can check that it's not an old message or a replay of a message It's a request for the public key of B. The authority has the public key of B So it sends back the public key of B But we can't send it unauthenticated If we send a public key unauthenticated someone could intercept it and modify it So we see we authenticate that message The public here B Including the original request ID a ID B and the same timestamp and We encrypt that with the private key of the authority Encrypting with a private key is signing We sign the message or the authority signs this message Confirming this came from the authority When user a receives message to what do they do? Decrypt and the name of that process of decrypting we call starts with a V We verify so we say that the authority signs The public key of B How did they sign it they encrypted with the private key of the authority when a receives a signed message they verify to verify you decrypt with the public key of the sender and We said that a already has the public key of the authority so they can verify that this is indeed the Message that came from the authority When a receives message to they verify the message using a public key of the authority They find it passes the verification because it was encrypted with the private key of the authority It successfully decrypts with the public key of the authority therefore verification passes So they know the contents included are valid They've learned PUB so that's the first discovery of a message and as a result of that after message to We know PUB a knows PUB remember our aim a to learn PUB B to learn PUA Before we look at the next steps What if an attacker intercepted message to what could they do? Right if an attacker intercepts message to they can learn the public key of B Remember message to is encrypted with the private key of the authority Everyone knows the public key of the authority. It's public So this does not provide confidentiality Anyone can see the public key of B So the attacker can learn PUB they can learn the request and T1 So what they learn the public key of B we know that that's okay because it's the public key Can they try to modify anything? they intercept message to and They're trying to trick user a and to get a different public key They change PUB to PUI the public key of the imposter Will it work? Yes, it will work They intercept they can learn PUB they can change PUB to something else But when they send that modified message onto a what is a going to do a is going to verify Using the public key of the authority any message we receive from the authority the second one We verify with the public key of the authority And it will only pass verification if it was encrypted with the private key of the authority Therefore if an imposter tries to modify this message to along the way They can't encrypt it with the private key of the authority because they don't have it They need to encrypt with some other private key But when we try to verify with the public key of the authority it would fail the verification so Encrypting with the private key of the authority Means that if someone tries to modify it a will detect that modification and that's our authentication That's how a knows It's got the public key of B It hasn't been modified Any questions about the first two steps is just to get PUB to a I asked for it Authority sends it to me, but importantly it sends it to me signed by the authority We want to exchange public keys, so we keep going A knows the public key of B now a contacts B for the first time sending a message to be saying Let's communicate. Let's talk. It uses the public here B to encrypt Its own identity and a nonce value again a random value or some number that will only be used once and It's hard to predict by an attacker It's encrypted with a public key of B Therefore no one else can decrypt that message except B Only B can decrypt this message So if an attacker intercepts message three they cannot learn and one B receives this Realizes that a wants to talk to it Step four and five are similar to step one and two B now requests the public key of a from the authority The authority sends back a response containing the public key of a Signed by the authority B confirms and learns pu a it verifies message five and Learns pu Hey, so just to make that clear that the steps that are important here the public key Authority signs this message and when a receives it verifies and Similar with message five it's signed by the authority and when B receives it verifies The way that it verifies is using the public key of the authority which we assumed was known at the start after message five We've achieved our aim a knows the public key of B B knows the public key of a But we still have message six and seven and they are Used to to confirm that there are no replay attacks or no modifications along the way Like in the previous protocol where we want to be sure that we're talking with the right entity message three contained N1 The only person who knows N1 is a Let's say some random value Message six coming from B also must contain N1 If it contains the correct N1, then it confirms that B Was able to decrypt message three which confirms that message six comes from B If you can decrypt message three you must be B B also includes N2 in message six and A sends back that same N2 in message seven so when B receives message seven it knows it's talking to a So really three six and seven AMB checking are we talking with the right entity? We'll just jump back to one of the previous systems one two and three The purpose of those three messages a and B to confirm they're talking with the right entity Exactly same purpose as three six and seven here If you look closely they're using almost the same technique they send the nonce values Encrypted with the other entity's public key Questions on how do we use a public key authority to exchange public keys? Correct That all of information that that you send them all the public key that they're listed it's trustworthy like How do we kind of it you can pretty much do the same thing? Correct all of this assumes that the authority is trustworthy That is So at this so we're assuming that somehow before we did all this we have confirmed It's the right authority. This is this manual exchange. So Right it could be that in the example that I said you are the users I am the authority you trust me as a lecturer at the start of the semester you come to my office We provide some ID we do a manual exchange and I learn your public key. You learn mine as the authority then after that all semester we can use this protocol and Each student can talk to each other student using this protocol by automatically exchanging public keys But yes, we don't overcome this problem of we must trust someone Because We need to get started somewhere if we want to Exchange a shared secret key Across the network that it must be encrypted if we are going to encrypt it. We must have a key to encrypt it Well, we can use public keys, but our problem always with public keys. We must know it's the right public key And the only way to cryptographically do that is to have it signed by someone but if we sign a message we must have a public key to Verify that message so there must be some initial trust. There's no way around that here In this case the initial trust is a trusts the authority When I say trust here, I mean a has the public key of the authority and it knows for sure It's the correct one and that issue is a practical issue. That is how do we trust other entities? Maybe you trust a government or you trust your employer they they set up the system in advance such that we Have that initial trust built into the software or into the system We'll see that a little bit more with web security and digital certificates So let's summarize on the scheme here the aim a and b get public keys The assumptions every user trusts the authority and they've exchanged public keys with the authority That must be done manually in advance the automatic steps request the public key of B Receive the signed public key of B from the authority in message to a Verifies the signature of message to using the public key of the authority Message 3 is telling B that a wants to talk to it. So B does the same as message 1 and 2 it Requests a's public key from the authority the authority sends a's public key back, but signed B verifies message 5 Okay, it learns the public key of a 3 6 and 7 combined A and B checking are we talking with the right entity with this exchange? There's no way for an attacker in the middle to modify a message and Try and pretend to be one of the others for an attacker to pretend to be B from a's perspective or vice versa because These messages are encrypted with public keys We have confidentially confidentiality of those messages and because the contents are random numbers or nonce values The attacker cannot guess what they are in advance What's the problem with this we trust the authority is one problem We'll see we can't get around that if we want to use a centralized approach What's another problem? Maybe not a security problem performance wise performance a problem There are seven seven messages to be sent across the network to do this every time a pair of users want to communicate they Exchange these seven messages. So there is some communications overhead usually not large Let's say we need to do this every five minutes a wants to communicate with someone else they go through these Seven steps just send some packets across the network software does it for us But maybe performance with respect to the authority can be an issue the authorities like a server A and B are computers in the network every time any Computer wants to talk to any other computer We see the authority must receive a request sign a public key and send it back twice in fact So there's some load on this authority. It must sign two messages for every time a pair of entities want to communicate if we have thousands of users wanted to communicate There are many requests coming to the authority and the authority has to sign those requests and send them back So there's some performance bottleneck at the authority if this is slow If it can't respond quickly for a response then the communications between the users will be delayed So yes, some performance issue with the authority. It's we depend upon that and also some trust issue with the authority We can't overcome the trust issue We must trust someone to get started We can overcome the performance issue So we looked at using the authority to distribute public keys The authority can be the performance bottleneck everything goes through that entity that server if it's slow that whole system is slow You can speed things up by caching some of the messages the way to overcome that Every exchange goes to your authority is to use a concept called public key certificates