Transport-layer security (TLS)

Widely deployed security protocol above the transport layer!
It is supported by almost all browsers, and web servers.

TLS provides:

• Confidentiality via symmetric encryption
• Integrity via cryptographic hashing
• Authentication via public key cryptography

TLS protocol

1. Handshake: Alice, Bob use their certificates, private keys to authenticate each other, exchange or create shared secret.
2. Key derivation: Alice, Bob use shared secret to derive set of keys.
3. Data transfer: Stream data transfer! Send data as a series of records.
4. Connection closure: Special messages is used to securely close connection.

Initial handshake

1. (Bob establishes TCP connection with Alice.)
2. Bob sends t-tls hello to Alice.
3. Alice sends public key certificate to prove that Alice is really Alice.
4. Bob sends Alice a master secret key MS encrypted with Alice's public key, which will be used to generate all other keys for TLS session.

TCP + TLS handshake requires 3 RTT before client can start receiving data!

TLS keys

It is considered bad to use same key for more than one cryptographic function.
TLS use different keys for MAC (message authentication code) and encryption.

• $K_c$: encryption key for data sent from client to server
• $M_c$: MAC key for data sent from client to server
• $K_s$: encryption key for data sent from server t oclient
• $M_s$: MAC key for data sent from server to client

Keys are derived from key derivation function (KDF).
It takes master secret (and some addition random data) to create new keys.

TLS encryption

Recall) TCP provides byte stream abstraction.

Problem: Message integrity can happen only after all data received!
Solution: break stream in series of records!
Each client-to-server record carries data's length and a MAC, created using $M_c$.
Finally, the whole record is encrypted with $K_c$.

Problem: re-ordering and replay attacks are possible.
Solution: Use TLS sequence numbers and nonce!
When duplicate data arrives, ignore it.

Problem: Truncation attack is possible. (Attacker forges TCP connection close segement to close connection in the middle.)
Solution: Record type! Record now have a type field, where type 0 indicates data and type 1 indicates close.

TLS 1.3

• Unlike TLS 1.2, which had 37 cipher suites to choose from, TLS 1.3 has only five cipher suites to choose from.
  • 4 of them are based on AES. TLS_AES_256_GCM_SHA384 is widely used, even in network cards!
• It requires Diffie-Hellman (DH) for key exchange, instead of RSA. (TLS request occurs too frequently, but RSA is too slow.)
• It combines encryption and authentication algorithm for data rather than serial encryption, then authentication. (Called authenticated encryption)
  • No MAC needed!

TLS 1.3 handshake

TLS 1.3 handshake need 1 RTT.

1. Client hello: guesses key agremment protocol, parameters, and indicates cipher suites it supports.
2. Server hello: Chooses key agreement protocol, parameters, cipher suite, and sends server-signed certificate.
3. Client checks server certificate, generates key, then makes application request.

However, 0 RTT handshake is possible if we're resuming earlier connection!

1. Client sends encrypted application data together in client hello message.
   Application data is encrypted with resumption master secret, which was used in the previous connection.
2. Server verifies resumption master secret is valid, then sends (encrypted) response together in server hello message.

0 RTT handshake is vulnerable to reply attacks!
But maybe it is OK for client requests that doesn't modifies server state. (e.g. HTTP GET requests)

IPsec

IPsec provides datagram-level encryption, authentication, integrity for both user traffic and control traffic. (e.g. BGP, DNS messages)

• Transport mode: Only datagram payload is encrypted and authenticated
• Tunnel mode: Entire datagram is encrypted and authenticated.
  Encrypted datagram is encapsulated in new datagram with new IP header, tunneled to destination.

IPsec protocols

• Authentication Header (AH) protocol: Provides source authentication and data integrity, but not confidentiality. (i.e. plain text)
• Encapsulation Security Protocol (ESP): Provides source authentication, data integrity, and confidentiality.
  Obviously more widely used than AH.

Security associations (SAs)

Before sending data, security association (SA) is established from sending to receiving entity.
Ending, receiving entities maintain state information about SA. (Just like TCP, TCP endpoints also maintain state info!)
IP is connectionless, but IPsec is connection-oriented!

SA stores:

• 32-bit identifier Security Parameter Index (SPI)
• Origin SA interface
• Destination SA interface
• Type of encryption used & encryption key
• Type of integrity check used & authentication key

IPsec datagram

We assume that we are using tunnel mode ESP.
IPsec datagram encapsulates original IP datagram.

• ESP header has SPI and sequence number.
  • Sequence number prevents replay attacks; If datagram with same sequence number is arrived, replay attack happened.
• ESP trailer has padding for block ciphers.
• MAC in ESP auth field is created with shared secret key.

ESP tunnel mode actions

Sender router:

1. Append ESP trailer to original datagram.
2. Encrypt the datagram using algorithm & key specified by SA
3. Append ESP header to front of the encrypted datagram.
4. Create authentication MAC using algorithm & key specified by SA
5. Append MAC to the payload
6. Create new IP header and its field, then address new IP datagram to tunnel endpoint.

• For new SA, sender initializes with sequence number 0.
• Each time datagram is sent, sender increments sequence number.
• Only packets in window are tracked for duplicates.
• If duplicate is found, replay attack happened!

Security of tunnel mode

Trudy cannot do anything!

• She can't see original contents of datagram. (including headers!)
• She can't flip bits without detection. (integrity!)
• She can't replay a datagram. (sequence number!)
• She can't masquerade as router using router's IP address. (actually possible, but Trudy cann't guess correct SA state/key at all)

IPsec security databases

Security Policy Database (SPD)

For given datagram, sender needs to know if it should use IPsec, and which SA to use.

SPD instructs what to do!

Security Association Database (SAD)

Endpoints holds state of SA in SAD.
When sending/receiving IPsec datagram, router accesses SAD to determine how to process it.
Receiving router can examine SPI in IPsec datagram, then index SAD with SPI.

SAD instructs how to do it!

Internet Key Exchange (IKE)

We cannot manually establish IPsec SAs for every connections!
e.g. VPN has hundreds of endpoints.

We use IPsec IKE for establishing SA! Handshake will establish SA automatically.
IKE authenticate with either PSK or PKI.

• PSK (Pre-shared secret): Both sides start with shared secret. Run IKE to authenticate each other and to generate IPsec SAs, including encryption and authentication keys.
• PKI (Public/private keys and certificates): Both sides start with public/private key pair and certificates. Run IKE to authenticate each other, then obtain IPsec SAs.

IKE has two phases!

1. Phase 1: Establish bi-directional IKE SA (different from IPsec SA).
   • Aggressive mode: Use fewer messages.
   • Main mode: Provides identity protection and is more flexible.
2. Phase 2: Use ISAKMP to securely negotiate IPsec pair of SAs.