I often find myself forgetting a lot about certain topics in cybersecurity that I have studied at some point. I recently revisited basic encryption concepts which led me down a rabbit hole this past weekend. Today’s blog post will cover what I studied; this includes symmetric encryption, asymmetric encryption, Diffie-Hellman Key Exchange, TLS Handshake, Kerberos, and Onion Routing.

Symmetric Encryption

In order to understand complex processes that involve encryption, it is always best to take a step back and really define what the original problem that we are trying to solve is. From there, we can pinpoint what the issues are and why alternative methods and improvements on encryption were created.

To begin with, let us outline the reason why encryption is necessary. Let’s say that Alice wants to send Bob some confidential information over the Internet. The Internet is not a safe place and it is highly likely that at some point during its journey from Alice to Bob, that confidential information may be viewed by someone else. Since Alice only wants Bob and herself to be able to read this confidential information, she encrypts her message, sends it to Bob, Bob decrypts the message and can now read it. In addition, if someone was eavesdropping and tried to read the encrypted message during its transit, they would only see gibberish since the message was encrypted.

Sounds useful, right?

Let’s begin with taking a look at symmetric encryption.

Symmetric encryption (in its most bare-bones form) is the simplest to understand. We have Alice and Bob who want to talk to each other without others being able to eavesdrop. They agree on a shared secret (more commonly referred to as a session key). This session key can encrypt data and decrypt data that has been encrypted with it. Both Alice and Bob will each have this session key (for the sake of example, let’s say that Alice generates the session key and sends a copy to Bob). Alice encrypts her plaintext message using the session key, sends it to Bob, and he decrypts it with his session key to read the message. Nobody can eavesdrop and decipher these encrypted messages without having the corresponding session key.

However, the session key was sent over the Internet (or any untrusted network for that case) when Alice sent it to Bob. This means that this is vulnerable to a MitM (Man-in-the-Middle) attack since a threat actor could just sit between Alice and Bob when Alice sends the session key over. Then the threat actor can decrypt any message sent from Bob to Alice and vice versa.

NOTE: This does not mean that symmetric encryption cannot be secure. We will learn more about this in the Diffie-Hellman Key Exchange and Kerberos sections.

Asymmetric Encryption

Since the previous example of symmetric encryption is not secure, another approach to encryption was introduced called “asymmetric encryption” (also commonly referred to as Public Key Cryptography). In asymmetric encryption, Alice and Bob each have a public-private key pair. Their public key is used to encrypt their messages, and their private key is used to decrypt messages encrypted with their public key.

In the diagram above, Bob sends Alice his public key over the Internet. Alice then encrypts her plaintext message with Bob’s public key. She sends the encrypted message over the Internet to Bob, who decrypts it with his private key. For Bob to send encrypted messages back, Alice would need to send over her public key.

Note that it would not matter if a threat actor was eavesdropping since a public key would be of no use to them. They would want the private key since it decrypts the messages sent between Alice and Bob. However, this does not stop a MitM attack from being dangerous. How does Alice know that the public key she has received belongs to Bob? We will look into this in further detail in the TLS Handshake section.

Note: Bob would not be able to encrypt using his private key so Alice can decrypt it with his public key that he sent over because that public key was sent over the Internet, therefore a threat actor with Bob’s public key would be able to decrypt his messages that are encrypted with his private key.

Diffie-Hellman Key Exchange

Let’s go back to the idea of symmetric encryption – having one key for encryption and decryption. Since asymmetric encryption is typically a lot slower than symmetric encryption, a secure method for both parties to obtain the same session key without it being exposed on an untrusted network was devised. We call the most popular of these processes the Diffie-Hellman Key Exchange.

Since this key exchange process involves Alice and Bob generating a public-private key pair, the Diffie-Hellman Key Exchange is categorised as an asymmetric algorithm even if neither side is receiving the other’s public key to encrypt their messages and end up with a shared/session key.

This is the Diffie-Hellman Key Exchange:

1. The initial shared secret is agreed on by Alice and Bob (it is ok to share it publicly since it will not be used to encrypt, nor can this information be used to derive any confidential information in the encryption process). The shared secret is made up of two components (g and n; g is a small prime number, n is a large one).
   
   
2. Bob and Alice generate a public-private key pair. The private key numbers are random (a for Alice, and b for Bob).
   
   
3. Both Alice and Bob combine their private key with the shared secret. The way the private keys are combined with the shared secret is as follows:
   
   Alice: g^a % n
   Bob: g^b % n
   
   
4. These private key and shared secret combinations are sent to one another and then mixed again with their private keys. So we get:
   
   Alice: g^ab % n
   Bob: g^ab % n
   
   They both end up with the same key without it having been exposed to the Internet. The only thing that was sent across the Internet was the initial shared secret (g and n), and g^a % n and g^b % n. The only way to derive the session key is by also knowing the values for a and b (the private keys).
   

TLS Handshake

Now that we have covered a secure way for two nodes to obtain the same session key for encrypted communication, we will take a look at a very common and practical example where the Diffie-Hellman Key Exchange is used.

Whenever we connect to a website, you may notice that the vast majority of the time we are using the HTTPS protocol. This means that a TLS handshake has taken place, authenticating the web server to the client and encrypting traffic to and from the web server.

Note: This will cover the TLS 1.2 handshake. TLS 1.3 speeds up the handshake and forces the client and server to agree on a smaller range of more secure cipher suites.

The diagram above illustrates the process of a TLS handshake.

These are the steps in a TLS handshake:

1. The client initiates a TCP three-way handshake to connect to the web server.
   
   
2. The client sends a Client Hello message (includes their latest supported TLS version, and the cipher suites they support).
   
   
3. The server returns a Server Hello message (includes the selected TLS version, selected cipher suite, and a certificate digitally signed with their private key along with their public key).
   
   
4. The web server sends a Server Hello Done message (this denotes that the web server has sent the client what it needed to send).
   
   
5. The client verifies the certificate with the CA (Certificate Authority) that issued it in order to verify that the web server is who they say they are.
   
   
6. The client generates and sends a shared secret encrypted with the web server’s public key.
   
   
7. End up with the same secure session key via the wonderful magic of a Diffie-Hellman Key Exchange.

In summary, a TLS handshake is a key exchange preceded by a verification of the server’s authenticity.

Kerberos

Encryption in an Active Directory domain network implements symmetric encryption. This is because exchanging keys securely (asymmetric) with every server in the domain network results in a large number of keys being generated and it very quickly turns into a mess. This means that we cannot exchange keys using the Diffie-Hellman Key Exchange since that is asymmetric given its requirement of public-private key pairs. So how do we solve this?

In order for clients to securely access resources and servers in a domain network, we have one server that everyone trusts and has session key shared with. This server is responsible for handing out short-term keys. That way we reduce the number of keys used and maintained.

The server that everyone trusts is called the domain controller. It is responsible for almost everything in the domain network, but it primarily deals with authentication requests. The domain controller also acts as a KDC (Key Distribution Centre) made up of an AS (Authentication Server) and a TGS (Ticket Granting Server). Clients that are part of the domain network already have exchanged keys securely with the Authentication Server, meaning that their communication is encrypted.

These are the steps in the Kerberos authentication process for a client to access a file server (for the sake of example):

1. The client asks the AS if the client can speak to the TGS.
   
   
2. If the AS says “yes”, it will send the client a session key to talk to the TGS as well as a TGT (Ticket Granting Ticket). The TGT is encrypted by the AS with a session key that it shares with the TGS. Inside of the TGT is a copy of the session key the AS sent the client. Additionally, a TGT will contain a timestamp and a lifetime so that it cannot be reused. TGTs are essentially short-term keys.
   
   
3. The client asks the TGS if it can talk to the file server that it wants to access. This message is encrypted with the session key that the AS gave the client. The client also sends the TGT to the TGS. The TGS can decrypt the TGT since it was encrypted by the session key that the AS and TGS share. Then the TGS can use the session key inside the TGT to decrypt the client’s request to talk to the file server.
   
   
4. If the TGS says “yes”, it will send the client a session key to talk to the server as well as another TGT. The TGT is encrypted by the TGS with a session key that it shares with the file server. Inside of the TGT is a copy of the session key the TGS sent the client.
   
   
5. The client asks the file server if it can talk to it. This message is encrypted with the session key that the TGS gave the client. The client also sends the TGT to the file server. The file server can decrypt the TGT since it was encrypted by the session key that the TGS and the file server share. Then the file server can use the session key inside the TGT to decrypt the client’s request to talk to the file server.
   
   
6. The file server will send the client a response with a timestamp PLUS 1. This is done as a final check to make sure that the client is legitimate.

So every time a client wants to ask for another ticket (TGT) to access some other server in the domain network, it asks the TGS.

Onion Routing

The final topic I would like to cover is onion routing. This is another client-server encryption model.

When a client sends a message to a server on the Internet, the message “hops” from one router to another until it reaches the final server. Onion routing differs from what we have looked at so far in the sense that typically a malicious actor can sit in between Alice and Bob and eavesdrop. If the connection is encrypted securely, the malicious actor cannot understand what is being said. However, onion routing provides anonymity by not even allowing a threat actor to know who is sending what to who (it is possible but very difficult).

1. The client starts off by simply doing a key exchange with every router it hops through – we will use the diagram above with three routers to illustrate this.
   
   
2. The client encrypts their message with the session key for the exit node (the router just before the server), and does the same with the session keys of the other routers all the way down to the gateway node (the first router). This means that the client’s message is encrypted with multiple layers of encryption – not unlike an onion.
   
   
3. As the encrypted message passes through these routers, each layer of encrytion is peeled off until it reaches the server.

It is key to understand that each router only knows who sent them the encrypted message and to who they need to forward it to after decrypting their layer. The only way for a threat actor to learn who is visiting a server via onion routing is by eavesdropping between the client and the gateway node, and the exit node and the server. If the threat actor can correlate the timing of messages sent from the client to the gateway node and map them to a similar frequency as messages being sent from the exit node to the server, then it is possible to unveil the anonymity of the client and server in question.