Key Exchange Problems - Computerphile

we had a few interesting questions on the difficult video so let's explore a little bit more about what we can do of difficult and what we can't do or shouldn't do with diffie-hellman so let's talk about man-in-the-middle attacks and how they're a real problem for diffie-hellman when it's used on its own and that's where we bring in RSA or public key encryption to help us we won't go over too much of difficult ghin right plenty of videos on that already but let's remember we've got good ol Alice and Bob and we have some shared parameters already so a generator G and a large prime number n and they're going to share some information and calculate a shared key so Alice is going to generate a private value a Bob is going to generate a private value B they're going to share and I'm going to simplify the notation you know a lot here too so we don't spend ages writing it out but Alice broadly speaking will send Bob G ^ a like this so G ^ a and Bob will send g ^ b and they use that both calculate G to the a B all modern it's a G to the a a B for what this allows us to do is share two values in public and use them to calculate with our private value something no one else can do right that's really helpful but what this doesn't do is provide any protection from someone sitting in the middle here and intercepting these messages so let's look at a different version of this where there's someone nefarious in the middle let's call him Shawn so same again Alice and Bob and now we have Shawn sitting in the middle now Shawn has control of this network that's the issue right so you can not only read the message but you can also intercept messages transmit messages again you know this kind of stuff so let's say you're a rogue admin or something like this so Alice produces her value a right so maybe bob is a server maybe bob is a shop and Alice's our client so she's going to send the initial message that says I'd like to talk to you let's establish a shared secret so alice is going to calculate G to the a and send it off to Bob now Shawn doesn't let her through that's the problem Shawn intercepts that message and stops it and pretends to be Bob from then on so Shawn comes in here and goes oh yes I'm Bob right and he isn't so he a private key s and a value G to the s and sends it back and as far as Alice knows this is Jesus yeah there's nothing in here but says this is particularly Sean Bob could have generated the same we're calling s but it's just a number it could have been projected by anyone so he sends its back they perform a normal key exchange and they end up with G to the a s so Sean has now an established shared secret with Alice so far so good now Sean then there knows that Alice wanted to talk to Bob originally so then Sean says my name's Alice can i establish a shared secret with you so Sean sends G to the S over to Bob and Bob goes are brilliant and sends off G to the B back to Sean and they establish a shared secret G to the s B or at BS or we know whatever right G to the s be what Sean has done by sticking himself in the middle here is calculate two different keys both of which he knows and he can then use him to intersect every single message then between Alice and Bob so Alice then sends some actual HTTP traffic or something like this encrypted with a key derive from this Sean can immediately decrypt it re-encrypt it with s be send it off to Bob and essentially act as a man in the middle of every step so every time a message is sent decrypt it read it do whatever you want change it we encrypt it and send it on this is a huge problem because diffie-hellman provides no way of stopping this that's not what it's designed for it's designed for two parties I suppose that trust each other to generate a shared secret if you start throwing other people into it the whole thing breaks this is where RSA and other public key crypto graphic schemes come in and rescue us to me straightaway diffie-hellman it's dead in the water if he was in real trouble here but luckily it isn't the only public key protocol we've got so this is what RSA does let's imagine that Bob is a server so he has a public key and a private key associate let's say RSA or DSA it's not important so we have Alice and Bob again I'm going to get tired of naming these I should have just put a and B Bob has a private key and a public key so remember that back to the video that Rob did on in private key and the things we discussed in the past anything you encrypt with key a can only being decrypted with key be like I'm wanna cry and so on the public key is given out freely it's not probably on Bob's certificate the private key he holds back so this time Alice wants to talk to Bob what we want to do is assure that no one is sitting in the middle of this conversation also as it happens we'd quite like for Bob to verify his identity because we want to make sure we trust his server so we can bring that in as well Alice sends G to the a over to Bob just as normal we're assuming but the generator in the and the prime number already been established we're not worrying about this Bob it's going to send over G to B but to stop anyone from sitting in the middle he's going to bring his private key and make sure that Alice knows only he could have sent that message he sends G to the B as well as a hash of this message or a digital signature of his message signed with his private key which would be you know something like a hash of G to the B that's too many brackets and then all signed by K private so if he signed it with his private key the only thing that can decrypt that make sense of it is his public yes that's right so what Alice will do is something called a signature verification so she will take G to be perform the exact same process and then apply the public key to his encrypted version and see if they match and if they do she knows that only he could have done that because only he has the private key this is assuming he hasn't given the private key away we hope we like to make that assumption of where their food breaks what he does by sending this over is Alice still get G to the B like she did before but she can combine a very to get G to the a B but Shawn or any other anyone else in the Paris I when the first people are available if they try and use a different value they won't be able to sign it with the private key that Bob had if they can that that's a real problem but they can't so Bob is able to send a message to Alice but not only shares his difficult parameter which is something that needs to be done anyway as part of the key exchange but also sign it to ensure that only he could have send that message now this is this is a fundamental part of a numerous internet key exchanges so the i ke protocol that's used in VPNs and the handshake using TLS or anytime you see HTTPS this is the kind of thing you're going to I mean in fact if we go to a standard website this is Google Chrome's security overview that is telling us what the handshaking TLS establishes as a cipher suite for our communication with this server and you can see we're using TLS 1.2 elliptic curve diffie-hellman and RSA so we're not using diffie-hellman key by native RSA in this kind of mechanism such that no one can be a man-in-the-middle and intercept our messages and interfere with them it does sound like we are potentially over complicating this I mean if we've got RSA why do we need diffie-hellman yeah you're right so technically speaking we don't technically speaking we can use RSA in let's say a TLS handshake and historically that's what's been done so what would happen in that situation is Alice would generate a shared key and encrypt it with Bob's public key so I took that way she knew only Bob could ever read that secret key and then they'd carry on the conversation the the issue is one of something called perfect forward secrecy so the problem is that if you did this if you if you used only RSA ever to perform encryption right then if anyone ever breaks that RSA key or hacks into deserve and obtains it or heartbleed turns up and gives it away then someone who's been recording messages between the two suddenly can decrypt everything they could maybe to go for all the handshakes so they can decrypt that symmetric key every time and decrypt every single historic message has been sent between Alice and Bob so diffie-hellman is are more of a kind of per session deal yeah diffie-hellman RSA keys have established and DSA keys were established over a long period of time let's say one or two years and to save us a real problem if they get broken we don't tend to use that for the actual encryption what we tend to do is generate something called an ephemeral diffie-hellman key if ephemeral meaning we do it pretty much every time and we generally we actually use them to generate the shared secret and we use RSA to provide this authenticity all right so it's a combination of both diffie-hellman gets us a very quick way to establish a shared secret but it's only used a few times RSA gives us a way of verifying Bob's identity and making sure there isn't a man in the middle and we don't tend to use RSA anyway for long term encryption because it's too slow for a whole message so that's why we'd use it to derive symmetric keys and use something like AAS which is much much faster and this prime is 2048 bits so our private key is going to be sum this is our a and this here is our G to the a mod n and they're roughly roughly the same size this will be slightly smaller

Channel: Computerphile

Views: 261,774

Rating: 4.9756064 out of 5

Keywords: computers, computerphile, computer, science, Dr Mike Pound, University of Nottingham, Diffie-Hellman, RSA, Key Exchange

Id: vsXMMT2CqqE

Length: 9min 17sec (557 seconds)

Published: Fri Dec 29 2017