There are multiple ways to exchange keys, whether it’s public or private. I want to cover in band and out of band key exchange as well as other items related to key exchanges.
In band key exchanges mean it takes place within normal channel that you would use for the same system while out of band key exchanges means it utilizes a separate channel outside the system to authenticate. Great example of in band key exchange is “sending a key to a employee on a computer using work email”, while out of band exchange is “calling the employee on his or her phone or talking directly to the person to deliver the key”.
Google and other companies utilize out of band key exchange to authenticate users by sending them a text with a pass code. This is to ensure that the original channel is not compromised and to ensure that no one else but you is accessing PII.
While out of band key exchange is useful for authenticity, it’s time consuming. Also, it is susceptible to man in the middle attacks if the out of band channel is compromised. However, it’s highly unlikely.
The most common way to exchange key is, in band key exchange, which occurs a lot online. Since you are sending this online on a open network, you must encrypt it in case of compromise. We commonly use in band key exchange to send and receive symmetric key (I’ve talked about symmetric and asymmetric key here).
Let’s talk about an example of how this exchange works. I will be using SSL and TSL as an example, since it uses both symmetric and asymmetric key exchange. Say I went on amazon to purchase a new laptop. I want this transaction to go fast and easy, because that’s how service works.
1. The server sends a copy of its asymmetric public key.
2. Browser creates a symmetric session key and encrypts it with the server’s asymmetric public key, then sends it to the server.
3. Server decrypts the encrypted session key using its asymmetric private key to get the symmetric session key
4. Server and browser now encrypt and decrypt all transmitted data with the symmetric session key they shared. This allows for a secure channel because only the browser and the server know the symmetric session key. Since the session key is only used for that session, you’ll be protected from previous sessions that utilized different key
Session key is like ephemeral keys, which are the converse of a static key. They are temporary by nature in that they’re created/generated for each execution of a certain session.
This process is a good explanation for perfect forward secrecy. Perfect forward secrecy is something that is made/implemented to prevent a compromise of previous confidential message due o compromise of one other message. Since the session key only belongs to one session, this can be applied to only one messaging or a particular session, protecting you from other session that has a different key.