Internet Security
===
Topics Covered: Intro Cryptography, Digital Signature, TLS

## Brief Overview
The basic idea of internet security is to ensure that only the sender and receiver can read and write messages to each other. No third-party is able to hijack their secure connection by intercepting or spoofing messages.

## Cryptography

The basic goal of the asynmmetric cryptography field is to come up with "keys" belonging to the sender and the receiver such that
$$
m = K_B(K_A(m))
$$
where $A$ and $B$ are the sender and receiver respectively and $m$ is the message. $K_A$ encrypts the message, and $K_B$ decrypts it.

### Why Not Symmetric?
Symmetric encryption is usually faster, and you only generate one key. Why don't we use it?

Say we choose to use it. How do we generate it? Maybe the sender can generate it and share it with the receiver. But how do we get it to the receiver when we don't have a secure connection set up? We can't encrypt it, because the receiver can't decrypt it yet.

### Public Key Encryption
In this form of asymmetric encryption, both $A$ and $B$ must create a private key $K_A$ and $K_B$, as well as a public key $K_P$ which they will share with each other. Both will create their own public keys and share them with each other, but we focus on one of them only for our examples. $A$ does not know $B$'s private key, and vice versa. Two requirements need to be fulfilled:
1. choose $K_A, K_B, K_P$ s.t. $K_B(K_P(m)) = m$, or $K_A(K_P(m)) = m$
2. given $K_P$, $K_A$ and $K_B$ should be impossible to figure out

### RSA
The important part about RSA is that $K_P(K_B(m)) = K_B(K_P(m))$.
- we can use our private key to encrypt something for $A$, and $A$ can use the public key to decrypt it, proving that $B$ sent it
- encrypting with public key means $B$ can read it with their private key
- **issue**: **computationally expensive** for large $m$ (won't go into algorithm here, based on factoring large prime numbers)

### Establishing a Session
The lecture 9 slides offer the exchange in writing. I'll try writing it down symbolically for anyone that found the slide as confusing as I did.

1. $A$ generates random session key $k_S$, computes $K_P(k_S)$. Send to $B$.
2. $B$ computes $K_B(K_P(k_S))$. By our first property, this is $k_S$.
3. Now $A$ and $B$ know $k_S$. Great. Now we just need to ensure that **if $B$ receives $k_S$, then it must have come from $A$**.

## Digital Signature
The digital signature is a hashed session key, signed by the private key. So in our above terminology, let $H(m)$ be a hash function satisfying the basic ideas of a hash function
1. Deterministic (for given $m$, $H(m)$ always produces the same result)
2. Given $H(m)$, cannot figure out what $m$ is.
3. Computationally difficult/impossible to find $m_1, m_2$ such that $H(m_1) = H(m_2)$.

$$
\text{Digital Signature} = K_B(H(k_S))
$$

Why does this guarantee that $k_S$ came from our connection? Let's say $B$ sends this signature along with the signature (and message) $k_S$ to $A$. $A$ can use the public key $K_P(K_B(H(k_S))) = H(k_S)$. If $A$ hashes $k_S$, they should obtain $H(k_S)$, meaning $k_S$ was not altered, and it comes from $B$.

## TLS
TLS (Transport Layer Security) uses symmetric key crypto, and ensures integrity using MAC (Message Authentication Checksum). Receiver checks the MAC and the associated data as it arrives. It functions similarly to the digital signature, where a key is shared between sender and receiver, and the tag is generated using this key and a hash function. A few notes:
- A session key is still generated, similarly to RSA as discussed above, and shared.
- MAC is generated from the session key using a hash function
- Receiver verifies the MAC to ensure data integrity

**TLS Protocol**:
Sender:
1. retrives message $m$
2. fragments message into chunks, each chunk gets a MAC
3. encrypt the chunks
4. transmit

Receiver:
1. read received data
2. decrypt the chunks
3. verify MAC for each chunk
4. reassmble chunks and deliver message $m$ to next protocol layer (HTTP for example)

From [Cloudflare Blog](https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/),

> A TLS certificate is issued by a certificate authority to the person or business that owns a domain. The certificate contains important information about who owns the domain, along with the server's public key, both of which are important for validating the server's identity.

Servers adhering to HTTPS are using TLS with HTTP, and are run usually on port 443.

For extra reference material, here is the TCP handshake modified to include TLS exchange. The client provides the server with what hash functions and ciphers it can use, the server will choose which they will use and send the client the certificate, which the client will verify. The session keys are either determined by a random number (as in example above) or using Diffie Hellman, which is described in depth on the lecture 9 slides.