 So, the last example of internet security in this case will consider SSH, Secure Shell. And it's something that I think you have used either as homework tasks, you may have needed to use Secure Shell. In this course, if you've taken the lab, you've used it on a number of occasions. What do we use Secure Shell for? So, some background. What's the purpose? What's this application used for? Remote access. So, remote access, what do you mean by that? So, what do we do with this remote access? Access what? Access any other computer that's running a Secure Shell server to do what? Download web pages? Run commands. So, we run commands on another computer. Well, we need to understand, well, what do we mean by a shell and then Secure Shell? So, in a number of operating systems, we can interact with the computer via running commands, text-based commands. And we say that the software that interprets the commands we type in is a shell, shell software. So, when I log into my computer, of course, I can open up, you all know, a terminal and I can type in commands. And those commands are executed on my computer to interact with the computer. The software that specifies the syntax of the commands and what each command should do is referred to as shell software. The shell interprets those commands. And there's different types of shells. So, we know, or you know, you've done it before, when I run a command on my computer, so I'm actually on my own laptop at the moment, lsstar.jpg, ls list the files on my computer and the star.jpg says list all the files which end with .jpg. And it shows me that command lists three files. Okay, so this is just an example of using a shell, but this is on my computer. And this is common in Unix-type operating systems, so Linux, OSX also supports shells. What about Windows? Do you have a similar feature in Windows? Yeah, you do. The old one was the command prompt. So you had the, well, before that, MS-DOS was before you even have a graphical interface. You interpreted commands, and in newer versions, or the more powerful one in Windows is called PowerShell now. So PowerShell is something that allow you to do complex things like this in a Windows environment. So, we can do that on our own computer. Of course, when we have network access, you think, all right, well, if I can do it on my computer, when we have multiple computers under our control, it would be nice if I could run commands remotely on another computer. That is, I could sit at my computer and run a command on another computer. And the concept was originally called a remote shell. So instead of using the shell to execute a command on my computer, I would remotely run a shell program on another computer. And there was a program called RSH, remote shell. And remote shell would allow you to specify which other computer you want to run a command on, and which command you want to run, and you would do that. The problem with remote shell is it had no security. Everything we did when we had to maybe supply username and password to authenticate ourselves with that remote computer, it was unencrypted. And all of the commands we sent to that other computer and all the responses that came back was unencrypted, therefore, there were some security problems. And secure shell allow us to run commands on another computer but do it in a secure manner. And one basic way that we can use secure shell, let's use the program secure shell and then run commands on some remote computer, which one, ICT server, which I have an account on, and run a command there saying, run this command, lsstar.jpeg, but not on my laptop, but run it remotely on this other computer, ICT. And it asked me for my username and password for ICT, so I need to be able to verify that I have access. Not anyone can run commands on that remote computer. And I get the response that comes back. So what happened here was that when I ran this command, it communicated with the ICT server and to do everything securely, there was some key exchange and setting up a secure connection. And then once everything was set up, the command lsstar.jpeg was sent to that remote computer, the ICT server, it was executed on the ICT server and the results of that command were sent back to my laptop. And the results was, there's one file called finish.jpeg. And when that command lsstar.jpeg was sent to ICT and the results were sent back, that was all encrypted. So if someone captured the exchange then, they would not be able to see which command I sent there. Similar, they should not be able to see my username and password when I logged in. So that's what SecureShell does, allows us to run remote commands but in a secure manner. Now you may not use it like this in some cases, you may not run a single command, you may use it in an interactive manner where you actually don't specify a command, you just log in and then you can interact with that remote computer. You can run many commands. Now I'm actually executing commands on that ICT server. So that's how you may have used it in the past. So how does it work with respect to security? Well there's SecureShell defines how we do the key exchange and how we do the encryption for the secure data transfer. It consists of multiple different phases and different protocols, there have been different versions. Despite the close name between SecureShell SSH and SSL they are different and we know that for SSL there's an implementation called OpenSSL, there's an implementation of SSH called OpenSSH. Again despite the similarities in the name they are completely different so don't get confused between SSL and SSH. So with SecureShell normally what we do is when we connect to a remote computer we use TCP, a transport protocol that provides us unencrypted communications between client and server, provides all the reliability such that if we send a message and something goes wrong in the internet it will be retransmitted automatically by TCP. So that's a normal transport protocol used by remote access applications. So what does SSH do? It adds a sublayer on top of that the SSH transport layer protocol that whenever we send something across the internet using TCP and IP the transport layer protocol of SSH will ensure it's encrypted. So it will make sure that every piece of data we send between client and server will be encrypted. But to do that we know we need a key at both client and server, a shared secret key so there's other steps. We need to do some authentication, check that we're communicating with the right person and that they're allowed to access that server. So there's an authentication protocol and that we'll see has a username password for login and there's the key exchange as well. So that's performed also in the authentication. We make sure that we can use say a Diffie-Hellman key exchange protocol so that we can have a shared secret key. So we'll go through an example to illustrate that and then say show a couple of extensions or usage scenarios of secure shell. First the authentication. Let's have a look at the example again. So I want to access ICT server, sorry, this one, shorter. The authentication in this case is by username and password. That is how does the server know it's someone who's allowed to access it? Well the server or the secure shell authentication protocol is now prompting me for a password. I supply the password, I type in the password on my computer, it's sent to the server and the server checks that password that I supplied against one that was set up on the server in that case. So I need an account on that server and that account comes with it, a username and password. So that's one form of authentication. The server authenticates the client because the client supplies their username and password which were registered in the past. How does the client authenticate the server? How does the client know it's communicating with the correct server? Let me make a couple of changes. I'll connect to a different server. I have one of my own that's outside of our area, we'll see later, sandylands.info, I'll log in, I have an account on the server. I try to log in, what's this say? And some of you may have seen this if you've used secure shell in the past. The authenticity of host, sandylands.info, that is the server I want to connect to, identify with this IP address, can't be established. So we're talking about how do we authenticate people and now my software is saying I cannot authenticate the server. I don't necessarily trust it. And it's saying the server has this fingerprint which is some... It has a key, DSA is used for signing, it's the digital signature algorithm. So it has a key and this is the hash of that key, the short interpretation. And it says are you sure you want to continue? What do I type? No, I cannot access the server. So this is a warning message saying I cannot authenticate the server. The client is not sure that the server, sandylands.info, that you're trying to contact, is in fact sandylands.info, or maybe it's someone doing a man in the middle attack between our client and the server. So that's our problem that we have and it's come up in SSL and in any scheme that we use public key crypto to exchange keys, what if a man in the middle attack occurs? We need some form of authentication. This is saying that we have no form of authentication yet. So maybe I want to trust that a man in the middle attack is not taking place. I believe that it's unlikely. So if I try again and ask me, are you sure? And I type yes, I trust it, then I can access that remote server. So now I'm logged into the remote server. So this warning message was saying, well, I can't authenticate the server. It could be someone doing an attack, I don't know. In the first case, I type no, I don't trust it, so I couldn't log in. But the second case, I type yes, let's trust it. And now I'm logged into my remote server. So we need some way to authenticate the server, but I think many of you have seen such messages. The first time you access a remote server, you often see this message, meaning there is no authentication of the server. The client can't be sure it's talking about the right server. It could be a man in the middle attack taking place now. Now when I'm securely issuing commands on my server, maybe someone's intercepting them and seeing what I'm sending. So I don't know, so that's the problem there. We'll look at a couple of the solutions in a moment. So we have this issue of authentication. For client authentication, down the bottom, there's password based. Now does the server check it's the right client? The client submits its password and the server already knows the password because the client had an account established on there in advance. And they check them and then the client is authenticated. That's common, that approach. How does the client authenticate the server? Well, we saw it doesn't or it couldn't in those two examples. We needed to somehow trust that it was the right server. So there's no formal way to authenticate. But there are some ways to authenticate the server. And the way that we should use it is that we use public key encryption. And the approach is that if the server has its own key pair, public private key pair, and if the client already knows the server's public key, then when they perform the key exchange, and we commonly use Diffie-Hellman for a key exchange, the server can sign the messages with its public key. So here's the second point here is an important part. Assume the client knows the server's public key. So if I knew the server's public key in advance and loaded it into my client, then when I connect to the server, it will not prompt this warning message saying, are you sure? Because I trust the public key of the server. And this is key-based authentication, it's referred to. Let's try. Let's have a look at some of the setup of the client and server to see that. In SecureShell, your client or your configuration of the user accounts, there's a directory called .ssh. And inside there are some files, some configuration files for your SecureShell software. And the first two, which already exist on my computer, I've already created them, these two, IDRSA and IDRSA.pub. IDRSA.pub is my public key certificate using RSA. So in the past, I created my public-private key pair using RSA, and they are stored in two files, the public one in IDRSA.pub, and IDRSA with no extension is my private key. Don't look at that, that should be kept private. So this is a file, and if you looked inside that file, you'll see my RSA private key. And how was it generated? Well, you know how to use OpenSSL to generate a RSA key pair, and it can generate the files, and that's just inside those. So I have my own key pair. Similar, the server has its own key pair, and other computers that use SecureShell can have their own key pair. What else can be used here? Let me access this time when I try to SecureShell in the sandylands.info, it automatically logged me in. Why? And why was there no warning first? Well, there was no warning because I previously accepted it, I said yes before I trusted. And when I say yes, I trusted in the known host file are the hosts or the servers that you've contacted in the past, and some key information of them. It's very hard to see, but one of the known hosts and it starts here. This is the key of the server that I trust. So this is the public key of the server for sandylands.info, so that the next time I try to log into it, because I already trust it now, it will not prompt this warning, are you sure? Do you want to continue? It only prompts once, and then it saves the information. So this is one of the known hosts which I trust. There may be others there. What is this information? Actually it's, maybe I've got that wrong, it's here. It's hard to see because it's wrapped around a line, but it's inside here is the public key of the server. It's just encoded in some way that we can save it as text, but it's the public key of the server, and I receive that, the server sent it to me. The question was, how does my client know that this is the public key of the server? How did I know? The server sent me their public key. How did I know it wasn't modified by a man in the middle attack? Well I didn't, that was why the warning came up. The warning says, the server has sent me their public key. I don't know if it's trusted or not. I said, yes, let's trust it. So I manually trusted it, and as a result, my software saved the key in this file, this known host. From now on, it's trusted, okay? But of course that's a security flaw in that it could have been a man in the middle attack. So that's how it works in practice. The client usually records the value for later use. What else can we show before we look at the exchange? When I access the ICT server, it asks my user, or my password, it assumes my username is the same as on my client, and it works. So this is password-based authentication at the client. There's an alternative which is key-based authentication. So to summarize the authentication techniques, a common approach for the server to authenticate the client is password-based. The user at the client supplies their username and password. And for the client to authenticate the server, the server sends its public key to the client. Well, unless we've set something up in advance, there is no authentication because a man in the middle attack could take place, and we give this warning message so we must manually trust the value. Well, what I really should do is when I get this warning message, is check the fingerprint that was supplied. If I remove my known hosts, let's delete these, I remove the known host so I no longer recognize any of the other servers, and I log into sandylands.info here. How do I be sure that it's the right public here of the server? I can check this fingerprint manually via some other means with the server's fingerprint. So if I can access the server via some other means and check its fingerprint there, there's a file that shows it, see if it matches this one, then I trust the public key, then I've manually verified. But until I do that, it's still a chance of a man in the middle attack. So with secure shell access, unfortunately, that men in the middle attacks are possible, and because many people will type yes here, then we're not sure if a man in the middle attack is taking place or not. We need some out of band manual verification. So enough examples on the command line, let's look at the exchange that takes place. So the communications protocol, in summary what we do, client and server, they establish a TCP connection. This is this SIN-SINAC act saying, we're about to exchange some data using TCP. But before we send any commands, like ls-star.jpeg, we set up the secure connection and the messages here summarize what takes place. We'll see them in a capture in a moment, but first there's some short messages from client to server and back saying, this is the version of the protocol we're using and the version of software, just to say that this is what I'm going to use. And if the server doesn't trust that version, it can reject the message and not connect. Then there's some initialization of the key exchange saying what algorithms are we going to use. So we'll see those messages. Then there is the key exchange. So again, we can use different algorithms to perform a key exchange. So this is to exchange a secret key. We will see an example where we use again, Diffie-Hellman, our favorite key exchange algorithm. It's an easy one to follow. Once we perform the Diffie-Hellman key exchange, both client and server have a shared secret key. Now that they can tell each side, let's change keys. Let's go from the key exchange steps to now using this new shared secret key to encrypt our data. And I think the service requests we will not see, but after this, we have encrypted data back and forth. So let's see that via a capture. And this is a capture I did a couple of years ago. It's so that the addresses may be different now, but we'll see that in summary, what's my laptop's IP address in this case? Anyone want to guess? My laptop or my client in this case? 192.168.1.5 and the server was 203.131.209.82. At that point in time, that was the IP address of the ICT server. And I accessed the ICT server. I think I did it from my office at that point in time. So remember the 203 address is the server, the 192 address is the client in this case. And this is the secure shell messages that we see here. And in summary, what do we see? There's two messages at the start. The server tells the client what protocol it supports and the version of the software it supports. And similar, the client sends a message to the server saying what versions I support. Because the server may be set up to say, don't allow a client that's using a version lower than this value to connect because it may believe that older version is insecure. So that's an important thing with software when they use different versions of software, we may believe that some are insecure so there's some exchange to verify or to check whether you allow that. Then there's this key exchange in it, exchange from client to server and back. And we'll see in those messages, these are specifying what algorithms that we were planning to use. One of those algorithms will be Diffie-Hellman to say to exchange a secret that's used Diffie-Hellman and we see there are four messages there. And the first two are saying, let's agree upon some Diffie-Hellman parameters. What are the Diffie-Hellman parameters we should agree upon? We should be experts on Diffie-Hellman now. What are the parameters that we should agree upon before we use Diffie-Hellman? If you look in the next slide, I think we have one of Diffie-Hellman for a minute. If you go forward in your slides, just one or two slides, you'll see Diffie-Hellman. If you go forward, I've repeated this slide, showing Diffie-Hellman. Remember, there are two public parameters, alpha and q in our notation. So we need to know them. And they are public, anyone can know them. They don't need to be encrypted when we exchange them. And that's what these two messages are about. They're saying let's agree upon or what parameters are we gonna use? Which public values are we gonna use? And then these two messages will do the public here exchange, y of the server will go to the client and the y of the client will come back to the server. So that will be the Diffie-Hellman exchange. Once we've exchanged our Diffie-Hellman public values, the two y values, each side can independently calculate the shared secret key, k. So that happens after this step. So they calculate a shared secret key, k. Similar to SSL, they generate, they use that as a master key and generate another key from that. And then the client says, let's use that new key to encrypt our data and we'll use a symmetric key algorithm. So the client sends a message saying, let's change from the key exchange part to the data encryption part. And from then onwards, everything sent between client and server is encrypted using one of the algorithms chosen in the previous messages and using the keys which were generated from that Diffie-Hellman key exchange. So in our capture, we see all the other packets are encrypted packets. When we look at them, we would not see the contents of those messages. It just looks like random bytes. So there's the encrypted packet. And what would be inside there? If I could decrypt it, some of that will be the exchange of the username and password. Remember, the user sends the password to the server. That would be in one of these packets. I don't know which one. And the commands that I send to the server would be in those packets and the responses the server sends back will be in some of those packets. But it's all encrypted and that's the purpose of setting up the secure shell connection. So we'll look briefly in the first eight or so messages. The first two are quite short. Quite short. It's just the server saying this is the protocol I support, secure shell version 2.0 and the software I'm using and it's open secure shell, open SSH version 4.7 P1 and so on. So just the versions that they support. And similar, the one that comes back from the client. Is what the client uses. And assuming that they're both are okay with using those two versions, they continue. So the next message is from the client, 192.168 to the server, the key exchange in it. Let's have a look at that. Inside here are the algorithms that the client is proposing to use. Key exchange algorithms, KEX, key exchange. This is the client saying to perform a key exchange, I want to use one of these algorithms and it lists them here. I can't see all of them, but Diffie, Helman, Group, Exchange, Shell 256 and there are others here. So this is the client saying, these are the algorithms I support for key exchange. And similar, there's algorithms for encryption and for max message authentication codes. The server host key, this is for verifying the server. So what type of key do we expect from the server? Encryption from client to server, what algorithms I support, AES128, counter mode and others. And in the other direction, we can support other algorithms, usually they're the same in both directions and what MAC algorithms do I support? And what compression algorithms do I support? HMAC with MD5, HMAC, UMAC, so different MAC algorithms there. And compression, we may compress or not, none or use a particular compression library. So you see similarities with secure shell, a secure sockets layer. We exchange the versions we support, we agree upon parameters and we say what algorithms we support. This is sent from client to server and then what does the server send back? It says the list that it supports. And it's hard to see here because it's not shown clearly by Wireshark, but if we look at this long payload here, you'll see that it's also contains those strings, Diffie, Hellman, GroupExchange and so on. So it doesn't show very nicely but the list of algorithms that the server supports are sent in this message back. Note it is a list, unlike SSL where the server chooses and sends that choice back here, the client says the list it supports, the server sends back the list they support and they independently choose one from that list. I think there's an algorithm that says choose the first one on the list that both of them support and they should therefore choose the same values of those algorithms. Hence, after this step, they know what algorithm they'll use for key exchange, for encryption, for max and compression. Now they do the key exchange. The algorithm they chose in this case was Diffie-Hellman. Diffie-Hellman, GroupExchange, I think is the extension here, but quite simply, it's the one that we know. The first message is saying it's used to agree upon the public parameters. The public parameters, there's the alpha and q in our knowledge of Diffie-Hellman. We need to, both of us need to know what is q and what is alpha. In the capture we have here, they're denoted slightly differently. It's a bit confusing. I think this slide says that in the capture, q is actually listed as uppercase p and alpha is g. And alpha is referred to as the group. So the mathematical theory refers to that as a group. So when we find p and g in this capture, we'll know that's q and alpha in our knowledge of Diffie-Hellman. So what's happening is that the client is sending first a message to the server saying what group do you want to use? What range of alpha values can we use? Not what particular value, but a range of values. It says what's the minimum and what's the maximum? That's the idea here. And then the server sends back a response using a group of five. That's the value chosen and a modulus of this value. p is q, g is alpha. Remember we take the alpha, raise it to some power, mod by q. Well, we take g, raise to some power, mod by p. So just different variables here. So now we know the public parameters that we're gonna use for Diffie-Hellman. And the next two messages are exchanging the public keys. So we know the two public global parameters. Client sends its public key. And it's denoted as e in this capture. Remember the client calculates y of the client using Diffie-Hellman and sends that to the server. Here it is, this is the value in this case. It's called the client e. It's the public value of the client. And the next message, the server calculates its public value and sends it back. And it's denoted as the server f. So e and f correspond to our y of the client and y of the server. Just to summarize on that. So remember Diffie-Hellman, the algorithm we've denoted as alpha and q as global public parameters. They agreed upon in the first two messages. Then we exchange public keys, y of the client, y of the server. They were exchanged in the last two messages which were called e and f in secure shell implementation. That mapping of those values is listed here. So just different people give different variables to refer to those values. Almost done. So we've done the Diffie-Hellman key exchange. What else do we see in this message? What's interesting in this message? Mac, right? Signature. Remember our problem with public key exchange? Man in the middle attacks. I receive someone's public key, how do I know it's theirs? So we need someone to maybe sign that public key and then the receiver can verify it. So this message includes the public key of the server, f, but that is signed using some private key and the signature is also included in this message. Here's the signature. So we know to stop men in the middle attacks, we can't just trust the value of f we receive, we need to have it verified or the way that we achieve that is someone signs the value of f and then when the client receives f, it will check the signature and see if it matches. Who's signed the value of f or what key did they use to sign f? What type of key do we use to sign? We use a private key to sign. Whose private key was used to sign this? Maybe an RSA key, but whose, which entity signed this? The server signed its own value in this case. So the server generated f and signed it themselves using their own public private key pair, an RSA key pair. So when the client receives this to verify, if it was signed with the server's private key, what did the client use to verify? The server's public key. Where does the client get the server's public key? That's our problem and that's why we get this warning message in secure shell. When we get a public key from the server, the server sends their public key unsigned to us. So yes, I need to verify the signature of the Diffie-Hellman public key. And as the client, I need to know the RSA public key of the server to verify that. The RSA public key is included in the message that is sent from the server to the client, meaning if someone performed a man in the middle attack, they could modify that themselves. Let's try and draw that to see what's happening there. We're not draw all those messages, but illustrate what's happening with the signatures. And I'll try to be clear with the keys that are known. There's, the server has its own key pair. We'll denote as the RSA public key of the server and the RSA private key of the server. And in the Diffie-Hellman key exchange, we're not show all the messages, but the key exchange part of the messages. The client sent its Diffie-Hellman public key to the server. This was the value, and we've got different notation. This was the value, sometimes we'll denote it as YC or in the capture it was called E. So the Wireshark software called E. In our general Diffie-Hellman algorithm, we've called it Y, the public value. To be more precise, I'll say it's the Diffie-Hellman public key of the client. And what came back was the Diffie-Hellman public key of the server. And the notation we've seen is YS or in the capture it's called F. So different notation, but meaning the same value. When the client receives the public key, the Diffie-Hellman public key of the server, it doesn't know if it's the correct one or not, so it needs to be signed by someone. So we also have a signature inside this message. The signature, remember to sign something, we take the data, encrypt it with a private key. So this message from server back to client contains the Diffie-Hellman public key signed. Signed using what? The RSA private key of the server. Any questions? We need to be clear now, we've got two types of public-private key pairs, Diffie-Hellman and RSA, but we have the same concepts. When we sign something, we use a private key, we verify with a public key. We're using the Diffie-Hellman public-private values to do a key exchange. We're using the RSA public-private values to sign one part of that key exchange. So what the server did is it took the Diffie-Hellman public key and signed that with its own RSA private key, sent that signature in this message and here it is in the capture, the signature component of it. Here's the public key, Diffie-Hellman public key and here's the signature. And here is the RSA public key of the server because the client doesn't know that in advance. The server knows it's public key, the client doesn't know it. The client will need the RSA public key to verify the signature. So upon reception, it goes through the verification steps and to verify we decrypt using the RSA public key of the server, the signature component. Compare that decrypted value with the Diffie-Hellman public key that was received. So in some cases when we access the server it prompts the warning, in some cases it doesn't. So why is that? Well, why do we get a warning maybe? Well, what's the problem here? In this second message receive, what's the problem for the verification perspective? What could someone do to do an attack? The problem is that the RSA public key that the client is using to verify is sent by the server. If it was an attacker, the attacker could send that themselves and modify it to whatever they like it to be. So again, because this RSA public key of the server is received in this same message there's no way from the client to know maybe this is a man in the middle who has changed the Diffie-Hellman public key. They have changed the RSA public key and they've created the correct signature and when we verify it passes the verification. So the problem is the RSA public key of the server was sent from the server in the clear unsigned and received by the client. Hence my software, when it receives this prints a warning message. I can't trust this. Someone has sent me an RSA public key but I'm not sure if it's the correct one or not and it presents this warning. Do you wanna continue? If you type yes, then your software stores this RSA public key for later use. It now trusts it. But if you say no, then you cannot log in because you do not trust this RSA public key. So it's the RSA public key used to verify the signature which is important here. The same problem happened with HTTPS and SSL. We use Diffie-Hellman, we use RSA. How was the problem solved with HTTPS? How did the client, when the client received a Diffie-Hellman public key of the server, it was signed? How did the client verify? Let's have a look. When the client received the Diffie-Hellman public key, YS, in this key exchange message, it needs to verify it was signed with the private key of the server, the RSA private key. So therefore the client verified with the RSA public key of the server. That's the same step as what we're seeing. Why did the client trust the RSA public key of the server in HTTPS? What's the thing that's important? What do we trust? Why do we trust the RSA public key of the server? The certificate authority or the certificate. That is, in HTTPS, we use the RSA public key of the server to verify the Diffie-Hellman public key. Why do we trust the RSA public key of the server? Because it was signed by the authority, the certificate authority, in the certificate that we received. The certificate contains the RSA public key of the server. The same as in SSH, the server sends its public key to us, but the difference with the certificate that public key is signed by someone else, in Secure Shell, that public key is not signed by someone else. And since in the HTTPS, we trust that someone else, the authority, we trust the RSA public key of the server and hence can verify the Diffie-Hellman public key. In this case, we receive the public key, the Diffie-Hellman public key, we receive the RSA public key, but we don't have a way to trust the RSA public key explicitly. That's why we get the warning message. And if we manually check, we can answer the yes or no and if we say yes, then we do trust it. So in fact, very similar mechanisms, just a difference in who do we trust. If we do trust, then they generate a key and let me see if I used any particular notation. Let's find one more here. We're almost done. Assuming we trust the RSA public key, the end result is that we get a shared secret key, K. And it's known by both sides. That was the purpose of doing Diffie-Hellman, get a shared secret key. And then we can use that to do the data encryption. Similar to SSL, we don't use that key directly, we generate some keys from that. And this shows some other steps to generate those keys. So we have a value K that we obtain from Diffie-Hellman. What we do is we take some other values, combine them together, hash them to generate a subkey, or in this case, an encryption key from client to server. And we do that in other steps to generate some other keys. So we saw this in SSL as well. We have a master key from that. We can calculate hashes of that master key and some other strings to generate some subkeys. And we do that here. Where we take a hash of the master key, K, some hash value, another hash value, H, which is down below, some fixed strings, C means the character C here, and a session ID which is obtained from the initial message exchanges. Where this H value, the hash, is obtained from hashing all of these things. The public, or the IDs of the different entities, I think this should be ID of the client, ID of the server. M is the protocol version, that very first message. The public key of the server and the public Diffie-Hellman values and the secret key. Again, the exact details are not so important, but here we're using hash algorithms to generate subkeys. And we can change some of those strings. For example, if we change C to another letter, we'll get a different value. The hash of two different inputs produce two different random outputs. And that finishes our key exchange because after that, the client says, let's use these new keys. You've just generated a new session key, K, C to S, and similar for the other direction. Let's use them to encrypt. What do we encrypt? What algorithm do we use to encrypt? The next packet, what algorithm is going to be used? How would you find the answer in your exam? This packet, encrypted request packet. Tell me how to find the answer. Look where, where do you want me to look to find the answer of what algorithm was used to encrypt this packet? You may not see it on the screen. Tell me where to look. It's encrypted with some algorithm. The client and server need to know that algorithm. So where would you look in this capture to find the name of that algorithm? Where is it? Which message would I look in to find the name of the algorithm used? Which one? The first one, the first two just contain the versions of the protocol. There was nothing useful about algorithms in the first two. So what algorithms use to encrypt my data? The key exchange init messages contain the list of algorithms that I support from the client's perspective for key exchange and for encryption. Okay, for encryption from client to server, the client wants to use either AES128 in counter mode or AES192 in counter mode, or if you scroll across you'll see many others. And the server in its key exchange init message says the algorithms I want to support and it's hard to see in Wireshark because it's not shown explicitly but it's under this, it's in this list. If you see on the right here you'll eventually see some AES192 counter, AES256 counter and so on. So these key exchange init messages, client says the algorithms it supports, server says the algorithms it supports, they choose the first one in the lists which both of them support. Is there a reason there is, the server supports all of these, all right? The server says I support this list of algorithms and in this order of preference, right? It prefers the first one but it will support others. It depends upon what the client supports. So as long as the server considers them all to be secure then it can say it supports them and they'll choose the best one that the highest preference for each. So you could find the algorithm from those two lists. You'd need to look in there and see which one is common and at the highest point for the encryption and you'll see probably it's AES, AES128 or one of them. I think they both support AES128 counter mode so that would be the algorithm. Everything after that is encrypted with AES128 in counter mode and you will not see the exchange of username and password for the login or the messages sent between client and server. Any questions on secure shell? In particular the key exchange and setup. The order sent by the client is what it prefers. The server sends back a message, the list of algorithms in the order that it prefers. So they both indicate their preferences from that. I think the algorithm is defined that says choose the highest preference that is in both of them. Maybe with giving priority to the server if there's a conflict. So there's an algorithm that says how do you choose from those two lists? If they both support AES128, CTR at the highest preference they'll use that. If not, they'll find the next one that matches. Any other questions about secure shell? This is our second example of internet security. You'll see there are similarities though with SSL. Let's come back to our slides and see what we've missed. So we've gone through the steps of the setting up the secure connection and then after that we can encrypt data. We didn't see a service request. I think that's not so common. There are some algorithms that define how to generate the sub keys from the master key K. Many different algorithms are supported. So this is the list of ones which I think are supported. So they can use whichever is preferred. Some are required, some are recommended. That's normal Diffie-Hellman, but in the packet capture it used different notations. So it used these values just so we could compare them. And we've gone through the capture. This just illustrates when we encrypt the data, let's say using AES how it's done, where we have the original data, we may compress that. If we use a compression algorithm, we take that compressed data, we make the packet a fixed length so we may have to add some padding because when we encrypt, we need to encrypt a particular size to be efficient so we may pad it out. Add some header information like the packet data length and the packet length. Encrypt all of that and calculate a MAC of all of that with a sequence number at the front and we get the final packet which is sent containing the ciphertext and the MAC at the end. And that's what we saw in the capture, this part. Of course, when we see this, we cannot work out what the payload is.