# Cryptographic Protocols

### Message Authentication Codes

- Provide integrity and authenticity - not confidentiality
  - Protecting system files
  - Ensuring messages haven’t been altered
- Calculate a keyed hash of the message, then append this to the end of the message

![1653664490.png](img/1653664490.png)

#### HMAC

- Double hashing in HMAC avoids length extension attacks
- $HMAC(k,m) = H((k\oplus opad) || H((k\oplus ipad)||m))$

![1653664591.png](img/1653664591.png)

#### Authenticated Encryption (AEAD)

- It’s common to attach MACs to the end of ciphertext, that this is now usually built into ciphers as part of AEAD mode
- You’re often able to authenticate non-encrypted “associated” data too

![1653664720.png](img/1653664720.png)

## Transport Layer Security

#### SSL/TLS

- TLS is a protocol that provides *authenticated* and *encrypted* sessions
- Secure Socket Layer (SSL) came first, then after `v3.0` it became TLS
- Transport Layer Security has two layers
  1. The record layer
     - Using established symmetric keys and other session info, will encrypt application packets, very like IPsec
  2. The handshake layer
     - Used to establish session keys, as well as authenticate either party - usually the server using a public key certificate

##### TLS Handshake

- The TLS handshake allows us to
  - Establish the master secret
  - Resume sessions
  - Authenticate the identity of the server or client
- This is for TLS 1.2 - ECDHE_RSA
  - Elliptic curve with Diffie-Hellman ephemeral with RSA

![1653665054.png](img/1653665054.png)

**ClientHello**

```
Random nonce: f3bc12ad...
Supported Ciphers
{
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
}
[Extensions]
[Session ID]
```

**ServerHello**

```Hell
//Pick maximum version client and server can both do
Version: 1.2
Random Number: 16cf43a...

//Server chooses the suite out of the ones listed in client hello
Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[Session ID]
```
Random nonce used to stop replay attacks

**Certificate**

The server sends its public-key certificate to the client

> **Client verification**:
>
> The client checks that the public key certificate is valid using a root certificate

**ServerKeyExchange**

```
Elliptic Curve Diffie-Hellman Parameters:
	Named Curve: secp256r1 (0x0017)
	DH Public Key: bG
```

Digital Signature calculated over the DH parameters

> **Authentication**:
>
> The client checks that the digital signature is valid

**[Certificate Request]**

Optional request for a certificate and singature from the client - only used in mutual TLS

Imagine two banks communicating where both parties need to prove their identity.

**ServerHelloDone**

Signals that there are no further messages to be sent

**ClientKeyExchange**

DH Public Key: aG

![1653666093.png](img/1653666093.png)

**[Certificate]**

Optional client certificate, verified by the server using PKI

**[Certificate Verify]** 

Digital signature computed over the bytes send in the handshake so far

**Change Cipher Spec**

Signals the change of cipher suite, in this case from no encryption to the agreed encryption

This can also be done when renewing keys

**Finished**

A MAC computed over all handshake messages. Verifies that server and client see the same messages.

Mitigates man-in-the-middle attacks

##### TLS 1.3

**Efficiency**

- Handshake shortened
- Change cipher spec removed
- Key exchange sent early in hello messages

**Security**

- All ciphers except AEAD removed
- Public key and key exchange separated from cipher suites
- Some handshake messages are encrypted

## Public Key Infrastructure

#### Why do we  need PKI?

![1653666858.png](img/1653666858.png)

#### Digital Certificates

- If we want to use public key cryptography, we need *trust*
- We can use a trusted third party in order to *verify the ownership of a public key*
- Primarily managed through Public Key Infrastructure (PKI)
- Certificates usually held in `X509` format

###### Certificate Issuance

- A server has a public key that they want people to trust
- Using some subject details, the server creates a Certificate Signing Request (CSR)
- A Certification Authority (CA) uses this to create and sign a certificate

###### Certificate Use

- The server can supply signatures using the public key, backed by the certificate when requested (during the TLS handshake)

![1653667138.png](img/1653667138.png)

###### Chains of trust

- To verify the trust in `server.com` certificate, we need to examine the signing certificate

![1653667196.png](img/1653667196.png)

- In many cases, the chain involves multiple certificates
- Chains always end in a root certificate, located on your machine

![1653667247.png](img/1653667247.png)

##### Who manages the Root Certificates?

- Major OS vendors operate *root certificate programs*
  - Apple for iOS and OS X
  - Microsoft for Windows
- Mozilla maintains root certificate store
  - Used in linux & firefox