Session Keys – CompTIA Security+ SY0-401: 6.1


To provide a secure channel, both sides of the conversation need to share the keys that will be used during the session. In this video, you’ll learn about session keys and the different methods used to provide a secure exchange of session keys.

<< Previous Video: Public Keys and Private KeysNext: Block vs. Stream Ciphers >>


We know that if we’d like to protect data that we send across the network, that we’re going to want to encrypt that information. There’s two major ways of encrypting data. And there are advantages and disadvantages of each of those.

With asymmetric encryption there are actually two keys. There’s a private key that nobody gets to see. And there’s a public key that you could send to every one, that everyone in the world would have access to. You can share this public key and not have to worry about anybody gaining access to it, because you can’t decrypt information with the public key. You can only decrypt information with the private key.

This process of public and private key encryption, though, requires some additional resources. There’s a lot more CPU cycles that go into encrypting and decrypting this information. So although it is a very secure method of transferring information across the network, there is some overhead involved in being able to encrypt and decrypt the data.

That’s why, normally, whenever were sending information in real time we’ll use something like symmetric encryption. With symmetric encryption we use exactly the same key to encrypt and decrypt the data. In that particular case, we still need to share the information across the network on both sides. But if we need to send a symmetric key across the network then we’ll want to also add additional protection so that nobody can gain access to that key.

This is a relatively fast way to both encrypt and decrypt data. So it’s very common to use this whenever we’re sending information across the network in real time.

To be able to encrypt and decrypt this data we need to share the keys on both sides of the conversation. And we can either do this in and out-of-band key exchange or an in-band key exchange. An out-of-band key exchange means that we’re not sending the key over the network.

We would be doing this over a telephone. We would send a courier with the key on a piece of media, or written on a piece of paper. Or we may exchange the key in person with somebody and let them know that we’re going to use this key later to encrypt and decrypt information.

A much more common way to exchange keys is over the network with an in-band key exchange. Since you’re sending this over the network, you have to add additional protection to these keys so that if somebody does gain access to these packets they would not have the information they needed to be able to decrypt our private data. We very commonly used in-band key exchange when we’re sending a symmetric key. But we will use asymmetric encryption to encrypt the symmetric key and then send it across the network. Let’s talk a little bit more about how that works.

It’s very common to be this kind of fast security when we’re working on a website. We’d like to purchase something with a credit card, we want to be sure that entire transaction is encrypted. That particular functionality is something that’s handled via SSL or TLS. And we use this very fast encryption method using symmetric encryption to make that happen.

But before we can do this symmetric encryption we have to at least get that symmetric key across the network. And we have to do it in a way that ensures that the symmetric key can’t be read by anyone else. The best way to do this is to create a symmetric key that you then encrypt and send across the network. You would combine both symmetric and asymmetric encryption to make this happen.

The first step is that your client machine is going to create a symmetric encryption key. It’s then going to encrypt the symmetric encryption key using asymmetric encryption, and using the server’s public key to do that. That means when the server receives this information it’s going to decrypt it with its private key. And inside of that package, of course, is going to be that symmetric key that both sides will then be using to encrypt the data that’s used on both sides.

This is the session key that’s going to be in use. And as I mentioned, once that session is over, that key is thrown out. And if you need to perform another encrypted session a completely different key will be created, and the process happens all over again.

You also want to be sure that these keys are randomized and unpredictable. You don’t want to use a session key that someone can easily determine what the next one might be, because that would gain access to all of your encrypted traffic. Instead you want to completely randomize the keys so that every session is using a very different key than the one before.