 So, our challenge, user A maybe generates a shared secret. They want to get it to user B, so then they can use symmetric key cryptography to encrypt their data. And the approach we're going to use is encrypt that shared secret with public key cryptography. We've seen public key cryptography before, we've seen RSA and Diffie-Hillman for key exchange. This approach of using symmetric key encryption to encrypt data, but using public key encryption to encrypt a secret key is very common in practice today. And one of the reasons why we use the two encryption techniques is that symmetric key encryption is very fast compared to public key encryption, it's much, much faster. And we may have seen before, but I'll show again, I'll do a speed test with RSA. RSA is an example of using public key cryptography, OpenSSL does a speed test for us, it runs many encrypts, as many as it can using for 10 seconds in this case. And it will keep going, but in that case it did 44,000 encrypts in 10 seconds. And then it actually used a private key in the first case and a public key in the second case. What's the difference with RSA? Which one's faster? Using a public key or a private key, you may see the answer. Which one was faster? Which one did more per second? The public key, remember with RSA the public key, that E value, generally can be small. The D value, the private key is usually large because that needs to be kept private and no one can guess that. The problem with a large value is that when you raise to the power and that exponent is large, there's a very long calculation. So encrypting with the public key with RSA is much faster than the private key. Encrypting with the public key, well encrypting with the private key is called signing a message, we use it to sign a message. I use my private key to sign a message and the receiver uses my public key to verify. So the summary results say that with RSA, 1,024-bit RSA, we can do about 4,000 encrypts with the private key per second and about 68,000 encrypts with the public key per second. So in the order of thousands, tens of thousands per second, just get the right command. Now I'll encrypt with symmetric key crypto, AES, 128-bit and the EVP option says use my hardware, my CPU to do the encrypt, sorry, the hardware instructions specific for AES will see the numbers at the end. It's hard to directly compare because they're encrypting a different amount of data each. But with RSA, private key about 4,000 per second, public key about 68,000 per second with AES we're doing depends upon the size in the order of 500,000 or 500 megabytes per second. It differs in how we use these on the amount of the length of the data we're encrypting or if you look at here, we're doing about 9 million encrypts per 3 seconds or about 3 million per second with AES, with RSA, we're doing about 4,000 per second or 60,000 per second. So 3 million compared to thousands, AES is thousands of times faster than RSA. It's hard to directly compare but symmetric key encryption is much, much faster than public key crypto. Why do we care? Well, what we commonly do nowadays is to encrypt our data, which we want to do fast, we use symmetric key encryption but to get that symmetric key, that shared secret key from A to B, we'll use public key encryption or asymmetric encryption. And that's summarized here, asymmetric or public key encryption is generally too slow for encrypting a large amount of data. So there are different ways that we can use public key encryption, we'll go through a couple of examples. This is the first protocol and it's quite simple. User A and B want to communicate, they need a shared secret key, KS, so what happens is user A sends a message to B, message 1, saying I am user A, here's my identity, maybe it's a unique user name, it's an IP address, something that identifies user A in the set of users and sending A's public key, all right, so A says here's my public key, sends it to B and the meaning of this message is I want to communicate with you, please send me a secret key. When B gets message 1, B sends back a response, it contains the secret key, KS, but it's encrypted with the public key of A. By encrypting the secret key with the public key of A, who can decrypt that message to? Only A can decrypt message 2 because only A has the private key of A. Anything encrypted with a public key of A can only be decrypted by A, user A. So here's a simple protocol for exchanging a secret KS using public key encryption, encrypt, let's say using RSA using the public key of A. If someone intercepts the first message, nothing's encrypted, they can see the public key of A, well that's okay because it's public already, they can see the identity of A, again that's not secret, so intercepting the first message doesn't help. And if someone intercepts the second message, they see some ciphertext and they cannot decrypt that ciphertext because they would need the private key of A. So now we've exchanged a secret key using public key cryptography. As noted in the slide, it has a problem. It's subject to a man in the middle attack and we talked about specific man in the middle attacks when we looked at Diffie-Hellman, when we went through some examples. So what I want you to do now is to draw the man in the middle attack, the general one, not specific to Diffie-Hellman, but draw the exchange between A and B when there's a man in the middle, let's call them I, the imposter, in between A and B and see if you're the man in the middle, what are you going to do to perform an attack on this key exchange protocol? So spend five minutes here drawing the three nodes, A, the attacker, maybe the imposter I and B. A and B follow the rules of this protocol, but the imposter will try and do something else to defeat the system. Try it. User A is going to send the first message, but then our attacker is going to intercept that and modify something along the way. And when user B receives a message, it's going to send back a response according to message two. So let's see what happens. User A sends a message to B, but it's sent across the network and it's intercepted by user I, the attacker, intercept that message. What was it? What was the original one? User A sends its public key and its identity. I know the lecture picture uses uppercase A, but I simplify and use lowercase A for both cases. Let's just to be clear, before we continue, what do the users know in advance? What does user A know before it sends this message? I mean, they may know many things, but what's of importance for this protocol that it knows? It knows the private key of A and its own public key. You know your own key pair. So A knows P-U-A and P-R-A. Let's just make note of them. And similar B knows its own key pair, but it's not used in this exchange, so I will not write it down. A sends a message to B saying, I am A, here is my public key. But it doesn't get to be, but first user I intercepts it, maybe they tap into the network somewhere, they get that packet and now they modify that packet and send the modified packet onto B. What do they send? Remembering, what we'd like to do is the attacker is to find or to learn the secret key, KS. So what do they send? The public key of the attacker, the imposter I. So in addition, user I knows its own key pair, I has generated its own key pair, anyone can generate their own key pair, and it sends a message on containing the public key of I and the identity of A. There's no need to change the identity, we're still pretending to be user A. So when B receives a message, you can think, this is from user A, I'm going to send back a session key, so when I communicate with user A, we're going to use that session key to decrypt and encrypt our data. So B according to the protocol sends back a response, before it does that, B generates the session key KS, just a random value because we're going to use that, let's say for AES or for symmetric key encryption, so it can be a random sequence of bits, KS, and we cannot send that key in the clear, we must encrypt it, so we send encrypted using the public key of user A, which we just received in the previous message, which is this sequence of bits identified here, which is PUI in fact. We don't know it's the wrong public key, that's the problem here, and we saw this with the Diffie-Hellman man in the middle attack. We just trust that that first message received contains the public key of user A, but in fact it's not, it's been modified. The end result, can the attacker decrypt this message? Encrypted with the PUI, they have PRI, so yes they decrypt and they learn KS, the session key, and because we want A and B to still communicate using this session key, we send a message back to user A so that they don't know anything's gone wrong, that same session key KS can be encrypted with the public key of A, that's known by user I, because they received it in the first message, and they know KS, they encrypt it, and when A receives that, they successfully decrypt because they have PRA and learn KS, and A has a session key KS, B has a session key KS, they think everything is OK, now when they start to send data, so that was just the key exchange steps, then for example A sends some data to B, it's encrypted, let's say now using AES or another symmetric key algorithm and we use a secret key KS to encrypt that data, that's the idea of exchanging the session key, we'll then use that for symmetric key encryption, but when we send that to user B, our attacker user I can intercept that message, and they can successfully decrypt because they also know KS, A and B keep communicating using KS, the attacker can decrypt everything that they sent, so we have a problem in general with public key cryptography, when we receive a public key, we need to be sure it's the right person's public key, user B received a public key and a message, they weren't, the problem from this attack is that they don't know it's not user A's public key, any questions about the man in the middle attack in general with public key crypto, how to do it, why it works, you got it, how can we prevent it is a good question and that we'll cover in the next few slides or in a bit of depth, any other questions, so how do we prevent that is the obvious thing we need to look at because we still would like to use public key crypto, so we'll look at how to prevent it or different ways, we saw that same type of attack when we looked at Diffie-Hellman in detail, the same issue arose and similarly with any public key cyber, how do we know that the public key actually belongs to that user, so what do we do, we need some form of authentication, we need a way such that when B receives that first message it can verify that that message hasn't been modified, we need authentication and how do we authenticate, what are some different ways to authenticate, not just a hash but a MAC is one way to authenticate, remember we take the message and we calculate the MAC of that message using a shared secret key K, how do we get that shared secret key K, so the MAC needs a shared secret key but we're using the public key to exchange a shared secret key, so using a MAC doesn't really help us because we would need to have a pre-exchange shared secret key but that's what we're trying to do, exchange a shared secret key, so using a MAC doesn't help us, what do we do, encrypt what, encrypt the public key using what, encrypt using the public key of B but how do we know the public key of B, our problem here was that B didn't know the public key of A, A sent it in the very first message saying here I am user A here is my public key, so that was the very first step, A distributed its public key to B, so we can't rely on the distribution of the public key like that because someone can modify it along the way, how else do we authenticate, if MACs don't work or are not helpful, hash not just a hash but a hash combined with what, encrypt an encrypted hash value with a private key as a signature, if we sign a message we can authenticate, so what A could do is sign the message using its private key and then B could verify and use A's public key, that won't work because the problem is that we want to learn A's public key, we can't verify it if we don't have A's public key but a more common technique used today in the internet is that this public key of A is signed by someone else, someone we trust, so we have another entity that signs the public key of A saying this is the public key of A, signed using the private key of that other entity so that when B receives that signed public key it can verify that it is the public key of A and the signing of public keys will refer to it as a certificate or a digital certificate and that's what's used for secure web browsing today that a web server would have a signed public key but the details of that come up towards the end of this lecture so we'll arrive at how do we solve this, any other questions on the man in the middle attack before we move on, our simple approach of just sending the public key doesn't work, at least if it's possible for an attacker to modify and insert messages, of course if we already knew each other's public key through some other means we can still use public key encryption without signed messages and this is an example of a more complicated protocol to exchange a secret KS down the bottom is the thing that we're exchanging using public key cryptography, it still assumes that A and B know each other's public key so it assumes somehow magically A knows the public key of B and indeed it is the public key of B and B knows the public key of A, maybe they met each other privately and they had a printout of their public key in the exchange the manually so if we have manual exchange of public keys it can work and if we do have that manual exchange here's one way to exchange a session key KS and the reason we have these four messages here is to to confirm that there's no replay attacks, no modifications along the way, we will not go through in detail how it works you can see the first message that A sends a message to B saying I am A and N1 is a nonce value remember a nonce value is a number we use only once maybe it's a random number a long random number the attacker cannot guess what it would be in advance the very low probability that the attacker can guess that value so A chooses a random number N1 encrypts it with the public key of B, B can decrypt because B has the private key of B, no one can see the intermediate value no one can see N1 or the identity, B sends back a response just confirming and they include the same random number N1 in the response so this is used such that someone can't replay messages they need to be able to decrypt that to see what N1 would be if B or if an attacker intercepted message one they could not respond with message two because they would not be able to learn N1 we saw the use of nonces in the the key distribution center as well similar B generates its own random value N2 sends that back so these are just some authentication steps saying are you really user A and B if someone can send back message two it proves to A that it is B because the only person who can learn N1 is B so the only person who can send back message two which contains N1 is B so by receiving message two A knows it's communicating with B not some impostor in the middle and similar with the third message B knows it's communicating with A the only person who could send message three which contains N2 is the person who can decrypt message two which contains N2 who can decrypt message to user A because user A has the private key of A so the first three messages are just to confirm to each other you're talking to the right person that it's not an impostor in the middle and then the last one is the session key KS signed using the private key of A saying this is coming from A I as user A I confirm this session key was generated by me it's encrypted with A's private key and it's provides confidentiality by encrypting with B's public key no one can decrypt message four unless they are user B message four is encrypted with the public key of B therefore you need the private key of B to decrypt and B knows it comes from A because it's signed with a private key of A and the only person who can sign with the private key of A is user A so this is just one way to exchange a session key KS and the first three steps are for A and B to verify that talking to the right person authentication but still it doesn't solve our previous problem of how do we get a public key from A to B and vice versa because this scheme assumes that A knows P's public key and assumes that B knows A's public key so we still have that problem that we saw with the men in the middle attack so we're not look at the attacks on this scheme it's just one example of how we can confidentially and with authentication exchange a secret key but what we want to look at is how do we stop someone changing public keys how do we be sure that the public key we get is indeed of that person in the homework I think you generated your own keys is that right your public and private key pair and sent some information to me submitted some information you generated your own public and private key I think you use my public key to do one of the steps where did you get my public key from you remember the homework from a few weeks ago my public he was on the website I think you downloaded a file which contained my public key how do you know it was my public key see it you downloaded from a website did you confirm it was my public key well no you just trusted it was what could have happened maybe I posted my public key on the website when you access the website you download a file an attacker in the middle between the web server and your computer receive that message as you download of the file modified it along the way and sent their public key to you so that would have been a man in the middle attack and that would have been possible in that case because my public key was distributed with no form of authentication so that's the problem that we have how do we distribute public keys now posting on a website is not sufficient if we want true security so that's what we're going to look at how do we distribute public keys and once we know that we'll see why the man in the middle attack can be prevented any suggestions what would you do next homework if I put my public key on the website check with your friend but what if the attacker attacked your friend as well check with multiple people but what if the attack is intercepting everything from that website or even worse the attacker the attacker put their web their public key on the website check the MD5 hash so use some form of authentication as well what if the attacker changed that on the website as well so we have this problem of come come to the actual user and check maybe I on the office door I print out my public key after you download it you bring the laptop or your phone and you compare maybe not the entire value but a signature of the value and compare oh yeah they match that must be his because it's unlikely someone's gonna replace the piece of paper in my office but that manual checking is something we want to avoid in a network we want to do that automatically somehow