🌐 Chapter 12 — Internet Security Protocols & Standards Cheat Sheet

🗺️ Big Picture — What This Chapter Covers

Internet Security Protocols
│
├── 📧 Email Security   → MIME, S/MIME, PKCS, X.509
├── 🔐 Transport Security → SSL/TLS (Record, Handshake, Alert, Heartbeat)
├── 🌍 Network Security → IPsec (ESP, AH, IKE, Transport/Tunnel Mode)
│                         L2TP/IPsec (VPN)
└── 🎟️ Authentication   → Kerberos (AS, TGS, TGT, Realms)

1. Email Security — MIME & S/MIME

MIME (Multipurpose Internet Mail Extensions)

• Extension to RFC 822 (the original email format — To, From, Subject, ASCII text only)
• Adds new header fields to support attachments, HTML, binary files, multimedia

S/MIME (Secure/MIME)

• Security enhancement to MIME — built on RSA Data Security technology
• Provides: Confidentiality + Integrity + Non-repudiation

$\boxed{\text{S/MIME} = \text{MIME} + \text{Sign/Encrypt capability}}$

📬 Analogy: MIME is a plain envelope — it defines structure. S/MIME is a tamper-proof sealed envelope with a wax seal — proves who sent it and hides the contents.

S/MIME Content Types

PKCS Standards (Public-Key Cryptography Standards)

🔑 Analogy: PKCS #11 = keeping your key physically locked in a safe (no copies). PKCS #12 = keeping it in a password-protected file on your computer.

S/MIME Full Process: Bob → Alice

Step 1: Plaintext message (unsigned)
Step 2: Bob signs with his PRIVATE KEY   →  RSA/ECC + SHA-2 (Digital Signature)
Step 3: Message + Signature encrypted     →  one-time session key (Triple DES / AES)
Step 4: Session key encrypted             →  Alice's PUBLIC KEY (El Gamal / RSA)
Step 5: Everything converted              →  Radix-64 (Base64) for email transmission

S/MIME Functions Summary

X.509 Certificate — Key Fields

🪪 Analogy: An X.509 cert is like a national ID card — name, photo (public key), expiry date, and an authority's signature proving authenticity.

S/MIME uses X.509v3 certificates — you must import the receiver's certificate (to get their public key) before you can encrypt to them.

• Email content → encrypted with symmetric key (e.g., AES)
• Session key → encrypted with receiver's public key (from their X.509 cert)

Gmail S/MIME

• Admin must enable S/MIME for the Workspace domain via the Gmail S/MIME API
• Certificates must be uploaded; must use PKCS #12 file format
• Must meet current cryptographic standards

2. SSL / TLS

What Is SSL/TLS?

• One of the most widely used security services on the internet
• Operates between Application Layer and Transport Layer (above TCP, below HTTP)
• HTTP + TLS = HTTPS

🚇 Analogy: TLS is like a secure tunnel beneath a city street — all traffic using the road (HTTP, FTP, etc.) can route through the encrypted tunnel underneath.

SSL vs TLS Comparison

🔑 Key fact: SSL v3.1 = TLS v1.0

Protocol Version Timeline

TLS Protocol Stack

┌──────────────────────────────────────────────────────┐
│  Handshake │ Change Cipher Spec │ Alert │ Heartbeat  │  ← TLS Sub-Protocols
├──────────────────────────────────────────────────────┤
│                   Record Protocol                    │  ← TLS Core
├──────────────────────────────────────────────────────┤
│                        TCP                           │
├──────────────────────────────────────────────────────┤
│                         IP                           │
└──────────────────────────────────────────────────────┘

TLS Three Core Services

$\boxed{\text{TLS} = \text{Authentication} + \text{Data Integrity} + \text{Encryption}}$

TLS Session vs. TLS Connection

TLS Record Protocol — Step by Step

Application Data
  ↓ 1. Fragment — split into manageable chunks
  ↓ 2. Compress — (optional, older versions)
  ↓ 3. Add MAC — Message Authentication Code (integrity check)
  ↓ 4. Encrypt — Encrypt the whole thing
  ↓ 5. Append SSL Record Header
  → Send over TCP

MAC vs. HMAC vs. AEAD

AEAD — Authenticated Encryption with Associated Data

AEAD combines confidentiality + integrity in one operation. No separate MAC needed.

Encryption:

$\boxed{(C, T) = \text{AEAD.Enc}_K(N, P, A)}$

Decryption:

$\boxed{P = \text{AEAD.Dec}_K(N, C, A, T)}$

TLS 1.3 AEAD Guarantees:

• IND-CPA — Indistinguishability under chosen-plaintext attack (confidentiality)
• INT-CTXT — Integrity of ciphertext
• Replay protection — via sequence numbers in the nonce

TLS 1.3 Cipher Suites (Only 5!)

Forward Secrecy

Each session uses a unique ephemeral session key. Even if the private key is stolen later, past sessions cannot be decrypted.

🔒 Analogy: Like using a different padlock for every package you send. If someone steals your master key later, they still can't open old packages — each was locked with a unique, now-destroyed key.

Handshake Protocol 🤝 (Most Complex Part of TLS)

Used before any application data is transmitted. Negotiates algorithms, authenticates parties, and establishes keys.

4 Phases:

Phase 1 — Establish Security Capabilities
  Client → Server: client_hello  (TLS version, cipher suites, Client Random)
  Server → Client: server_hello  (selected cipher suite, Server Random)

Phase 2 — Server Authentication & Key Exchange
  Server → Client: certificate, server_key_exchange, [certificate_request]
  Server → Client: server_hello_done

Phase 3 — Client Authentication & Key Exchange
  Client → Server: [certificate] (if requested)
  Client → Server: client_key_exchange (premaster secret, encrypted with server's pubkey)
  Client → Server: [certificate_verify]

Phase 4 — Finish
  Both sides: change_cipher_spec → finished

Session Key Formula

$\boxed{\text{Session Key} = f(\text{Server Random},\ \text{Client Random},\ \text{Premaster Secret})}$

Both client and server compute this independently — must match!

Change Cipher Spec Protocol

• Simplest TLS sub-protocol
• Single message = 1 byte (value = 1)
• Signals: "We are now switching from unencrypted → encrypted communication"
• Before this byte: cipher is "pending". After: cipher is "active"

🗣️ Analogy: Both sides agree to "switch to code language." Once you say the magic word (the 1 byte), all future messages use the new cipher.

Alert Protocol

• Sends TLS-related alerts to the peer
• Messages are compressed and encrypted
• Each alert = 2 bytes

Heartbeat Protocol (RFC 6520, 2012)

• Periodic signal to confirm the peer is still alive
• Generates activity during idle periods (prevents TCP timeouts)
• Enabled during Phase 1 of Handshake
• Each peer declares whether it supports heartbeats

💓 Think of it like a "ping" — "You there?" → "Yes, still here!"

SSL/TLS Attack Categories

⚠️ Note: You cannot attack the core algorithms (RSA, AES) directly — they're still secure. Attacks exploit implementation or protocol flaws.

3. HTTPS

• HTTP + TLS = HTTPS (RFC 2818)
• The HTTP client also acts as the TLS client
• URL begins with https://, uses port 443
• Built into all modern web browsers
• Closing HTTPS → TLS closes connection → TCP connection closes

SSL Certificate Types

Note: Level of cryptography is the same — only the validation process differs.

Certificate Signing Request (CSR)

• A Base64-encoded block of text generated on the server
• Contains the public key + identifying details (domain, organization, location)
• Submitted to a CA to request a signed certificate

🏢 Analogy: HTTPS is HTTP wearing a security badge — every packet is encrypted and authenticated before it leaves the building.

4. IPsec

What Is IPsec?

• Provides security at the Network Layer (Layer 3) — transparent to applications above
• Used to secure IP packets between hosts or networks — most commonly in VPNs
• Authentication and encryption included natively in IPv6; also available in IPv4

$\boxed{\text{IPsec} = \text{Authentication} + \text{Confidentiality} + \text{Key Management (IKEv2)}}$

IPsec Components

✅ VPNs need both authentication AND encryption → always use ESP

Security Associations (SA)

• A one-way relationship providing security for traffic flow
• Two-way secure exchange = two SAs (one per direction)
• Uniquely identified by: Destination Address + SPI

ESP Packet Format

┌──────────────────────────────────────────┐
│     Security Parameters Index (SPI)      │ ← Authenticated
├──────────────────────────────────────────┤
│           Sequence Number                │ ← Authenticated
├──────────────────────────────────────────┤  ┐
│         Payload Data (variable)          │  │ Encrypted
├──────────────────────────────────────────┤  │ + Authenticated
│         Padding (0–255 bytes)            │  │
├────────────────────┬─────────────────────┤  │
│    Pad Length      │    Next Header      │  ┘
├──────────────────────────────────────────┤
│      Authentication Data (variable)      │
└──────────────────────────────────────────┘

Transport Mode vs. Tunnel Mode

📨 Analogy: Transport Mode = seal the letter, leave the address visible. Tunnel Mode = put the sealed letter inside another envelope with a new address — original is completely hidden.

IKE (Internet Key Exchange) — Phase I

IKE establishes Security Associations (SAs) — the secure channels IPsec uses.

Step 1: Peers exchange info on encryption methods/algorithms
Step 2: Each side generates a DH private key (from random bits)
Step 3: Each peer computes a DH public key from its private key
Step 4: Public keys are exchanged
Step 5: Each side computes shared secret = DH private key + other's public key
Step 6: Peers exchange identities and certificates (encrypted)
  → IKE SA established ✅

L2TP/IPsec — VPN Stack

L2TP alone = no encryption. Always pair with IPsec.

Original Data
  → PPP (Point-to-Point Protocol)
  → L2TP (encapsulates PPP frames, UDP port 1701)
  → IPsec ESP (encrypts everything)
  → IP packet → Internet

🚇 VPN analogy: L2TP digs the tunnel. IPsec puts an armored car inside it. IKE gives both drivers the same key so they can communicate securely.

5. Kerberos

What Is Kerberos?

• Trusted third-party authentication service — developed at MIT
• De facto Internet standard for remote authentication
• User must prove identity for each service they access
• Servers also prove their identity to clients (mutual auth)

🎡 Analogy: Kerberos is like an amusement park. You check in at the main gate (AS) → get a wristband (TGT). At each ride, show the wristband at a booth (TGS) → get a specific ride ticket. No need to prove your identity at every single ride — just use the ticket!

Key Players

Kerberos Server = AS + TGS

Kerberos Authentication Flow

Step 1: User logs in, workstation requests service
Step 2: AS verifies user's rights
         → creates TGT + session key
         → encrypted with key derived from user's password
Step 3: Workstation prompts user for password → decrypts TGT
         → sends TGT + Authenticator (name, IP, timestamp) to TGS
Step 4: TGS decrypts and verifies
         → creates a ticket for the specific application server
Step 5: Workstation sends ticket + Authenticator to the App Server
Step 6: App Server verifies ticket and Authenticator → grants access
         (optionally returns Authenticator for mutual authentication)

🔑 Sending password directly over the network = dangerous. Kerberos never sends the actual password — only encrypted tickets.

Kerberos Realms

• A realm = one Kerberos server + its registered clients + application servers
• Different organizations = different realms

Multi-realm requirements:

• Kerberos servers must share a secret key with each other
• Must trust each other's KDC (Key Distribution Center)
• Participating servers must accept auth from the other realm

Kerberos v4 vs v5

Kerberos Performance Notes

• Large installations: Very little performance impact if properly configured
• Best practice: Put Kerberos server on a separate, isolated machine
  • Prevents security effects from other apps on the same machine
• Multiple realms → created for administrative reasons, not performance

6. Summary Table — Protocol Comparison

7. Key Formulas & Facts to Remember

$\boxed{\text{Session Key} = f(\text{Server Random},\ \text{Client Random},\ \text{Premaster Secret})}$

$\boxed{(C, T) = \text{AEAD.Enc}_K(N, P, A) \quad \text{(TLS 1.3 encryption)}}$

\boxed{\text{Nonce (TLS 1.3)} = IV \oplus \text{seq_num}}