Security: Secure communications


Every protocol we've studied believes what it's told. ARP believes the reply, DHCP believes the offer, DNS believes the answer, SMTP believes the sender, BGP believes the advertisement. Today we start building the machinery that lets a host stop believing and start verifying. Three primitives do nearly all the work — symmetric encryption, hash functions, and public key cryptography — and the rest of the day is about how real systems compose them: TOR for anonymity, TLS for secure web traffic, VPNs for remote access, and WPA2 for Wi-Fi.

One rule before we start: do not create your own cryptography system. Use vetted crypto. It is far too easy to make a subtle mistake, and a cryptosystem that looks fine is indistinguishable from one that is fine.

Slides from class

Files:

Additional information:

Agenda

These notes cover what "secure" means, then the three cryptographic primitives — symmetric encryption, hashing, and asymmetric encryption — and then four systems built from them: TOR, TLS, VPNs, and Wi-Fi security. Firewalls, intrusion detection, and penetration testing come later in the security unit.

Notes

What "secure" means

Worth deciding what we want before building anything. Properties you might want in "secure" communications:

The first three form the classic CIA triangle, with authentication usually added. Confidentiality means only the sender and intended receiver understand the contents (sender encrypts, receiver decrypts). Integrity means neither party's message can be altered — in transit or afterward — without detection. Availability means services remain accessible. Authentication means both parties can confirm the other's identity.

Security and anonymity are not the same thing. Security is the CIA properties; anonymity is unlinkability — the inability to connect a message to its sender or recipient. You can have perfect confidentiality with zero anonymity: an eavesdropper who can't read your traffic may still see exactly whom you're talking to, and that metadata is often the more sensitive fact. Who needs anonymity? Journalists, people living under repressive governments, and you — large companies track a great deal of what you do. (Related ideas: steganography, hiding the existence of a message inside something else, and LPI, low probability of intercept.)

The cast, and what the adversary can do

By convention, Alice and Bob want to communicate securely over a channel, and Trudy (intruder) or Eve (eavesdropper) is the bad actor. What can a bad actor do? A lot:

The language of cryptography

Notation we'll use throughout. m is the plaintext message. KA(m) is the ciphertext, m encrypted with Alice's key KA. Decryption with Bob's key recovers the original:

m = KB(KA(m))

Symmetric key cryptography

In symmetric key cryptography, Alice and Bob share the same key KS: encryption is KS(m) and decryption applies KS again.

Which raises the question that will occupy much of this lecture: how do Bob and Alice agree on a key in the first place? Key exchange is hard if they've never met, and harder still if they aren't connected to the Internet to check anything. (Lab 4 implements one answer at the physical layer, using RSSI.)

Substitution ciphers

In a monoalphabetic substitution cipher, each plaintext character maps to one ciphertext character. Write the alphabet, write a permutation of it underneath, and substitute: 

plaintext:  a b c d e f g h i j k l m n o p q r s t u v w x y z
cipher:     j h q a u c d f w n s e v m i o y z p r g l k x b t

The permutation is the key. A Caesar cipher is the simpler special case where the alphabet is shifted by a fixed amount, and the amount of the shift is the key.

You can do this from the command line, which makes concrete that encryption and decryption use the same key in opposite directions: 

$ python3 monoalphabetic.py         # generate a random a-z permutation
jhqaucdfwnsevmioyzprglkxbt

$ tr 'a-z' 'jhqaucdfwnsevmioyzprglkxbt' < plain.txt > cipher.txt   # encrypt
$ tr 'jhqaucdfwnsevmioyzprglkxbt' 'a-z' < cipher.txt > plain1.txt  # decrypt

The problem: frequency analysis. Because the mapping is one-to-one, a letter appearing 100 times in the plaintext appears exactly 100 times in the ciphertext. Letters change but letter frequencies don't, and English letter frequencies are well known (e at 12.7%, t at 9.1%, a at 8.2%, down to q and z at 0.1%). Guess that the most frequent ciphertext letters are the most frequent English letters and you have a foothold. That's the end-of-class exercise.

Polyalphabetic ciphers

A better answer: instead of one substitution alphabet, create N of them (say 1000), and encode the character at position i using the ith alphabet, wrapping around when i exceeds N. Now the same plaintext character maps to different ciphertext characters depending on where it sits, which flattens the frequency distribution.

Much more resistant to frequency analysis, but not immune: if the same N alphabets are reused repeatedly and the attacker collects enough ciphertext, frequency analysis works again on each position class. The German Enigma machine used the polyalphabetic principle. The key point: both sender and receiver must know the whole set of N alphabets.

Transposition ciphers

A transposition cipher rearranges the order of letters without substituting anything. Write the message into a matrix — here 4 rows of 12 — and read down the columns: 

nowrunalonga
nddontgetint
omischiefiam
goingoutxxxx

ciphertext: nnog odmo wdii rosn uncg ntho agiu leet otfx niix gnax atmx

(The trailing x's are padding.) Decrypt by writing the ciphertext back in column by column. Characters change position but are never replaced — so the letter frequencies are exactly those of the plaintext, but the letters are in the wrong places. Note that substitution and transposition are complementary: one hides what the letters are, the other hides where they are. Modern ciphers use both.

XOR

XOR returns 1 only when its inputs differ. Four properties make it ubiquitous in cryptography:

A ⊕ 0 = A
A ⊕ A = 0
(A ⊕ B) ⊕ C = A ⊕ (B ⊕ C)  (associativity)
(B ⊕ A) ⊕ A = B ⊕ 0 = B

That last property is the whole trick. Alice XORs her message with the key to get ciphertext; Bob XORs the ciphertext with the same key and recovers the message: 

Alice                          Bob
key:      10101010             cipher:   01101001
message:  11000011             key:      10101010
cipher:   01101001             message:  11000011

Eve sees the ciphertext, doesn't know the key, and recovers nothing. But two problems: raw XOR with a repeating key is vulnerable to frequency analysis, and it's vulnerable to a known plaintext attack. If Eve knows both a message and its ciphertext, then by the same properties she can XOR them to recover the key. So if Eve can get Alice to send a message Eve chose, and observe the ciphertext, she gets the key.

S-P networks

Here's the intuition behind almost all modern symmetric cryptography. A substitution-permutation network processes a fixed-size block of plaintext through several rounds. The key is expanded into several round keys by a key schedule algorithm, and the block is XORed with a round key before entering the round.

Each round has two components:

The output is XORed with the next round key and the process repeats.

A single S-box or P-box provides little strength. But a network with several rounds provides both confusion and diffusion, and produces the avalanche effect: changing one input bit should change roughly half of the output bits, so that flipping input bit i gives a 50% chance of flipping output bit j, for every j. Each output bit ends up depending on every input bit. Run the network in reverse to decrypt. AES is built on these principles.

Cryptographic hash functions

Start with a game. You and I each pick a number; if the sum is even I win, if odd you win. The protocol: you tell me your number, then I tell you mine.

That works only if you trust me, and you shouldn't — I go second, so I always win. Hashing fixes this, and seeing exactly how is the best way to understand what a hash function guarantees.

From CS 10 hashing to crypto hashing

In CS 10, a hash function mapped an object to a table index in 0..m−1: compute quickly and consistently, spread keys over the table, produce fixed-length output, and give different numbers for small changes.

A cryptographic hash function keeps all of that — deterministic, fixed-length output, a "fingerprint" of the input — and adds two crucial properties:

Plus pseudorandomness: change any bit of the input and the digest changes completely. So "my secret message" hashes to something like 061ef7d71233886440043538e4d91de3, and nothing about that string reveals the input.

The game, replayed

New protocol: I hash my number and give you the digest — a commitment. You then tell me your number. Then I tell you mine, and you verify by hashing it and comparing to the commitment.

Is that fair to both of us? Yes, and each property does one job:

One residual problem worth noting: if the range of numbers is small — 1 to 10 — you can simply hash every possibility and see which matches. The fix, as we'll see, is a random nonce mixed into the input.

Which hash function

MD5 (Message Digest 5), designed by Ron Rivest in 1991, was a popular choice until its collision resistance was broken in 2004. Still usable where collision resistance doesn't matter, but don't reach for it.

SHA (Secure Hash Algorithm) comes in generations. SHA-1 is a 160-bit function, not recommended after 2005, with an actual collision found in 2017 (two different PDFs with the same hash). SHA-2 has two popular flavors, SHA-256 and SHA-512, where the number is the digest length in bits, and has no known exploits yet — it's the most common choice today. SHA-3, new in 2015, works on entirely different principles, deliberately, in case SHA-2 is broken.

Computing hashes from the command line: 

$ md5sum plain.txt
6cc0536c2c4fae6e79dd7f3b7b338d3d

$ shasum -a 256 plain.txt
8496285a4cbb68b806510621c9f683c9f9d6a52fe9714cbfb354f718f990f6bd

$ shasum -a 512 plain.txt
bbb3001c9640b5fa96d5daa40717f07481410b782c4f5bbf2a1c2bd1542cfd52...

$ openssl dgst -sha512 plain.txt
SHA2-512(plain.txt)= bbb3001c9640b5fa96d5daa40717f07481410b782c4f5bbf...

Note the digest lengths: MD5 gives 128 bits (16 bytes), SHA-256 gives 256 bits (32 bytes), SHA-512 gives 512 bits (64 bytes) — regardless of input size. And note that the same input always yields the same output for a given algorithm (the two SHA-512 invocations agree), while different algorithms give unrelated outputs.

In Python, using hashlib (compute_hash.py): 

m = hashlib.sha512()
f = open(sys.argv[1],'r')
for line in f:
    m.update(line.encode("utf-8"))
f.close()
print(m.hexdigest())

The update pattern means you can hash a large file incrementally, and you get the same digest whether you hash line by line or hash the whole file at once. The C version (compute_hash.c) uses OpenSSL with the same three-step structure — SHA512_Init, repeated SHA512_Update, then SHA512_Final — compiled with gcc compute_hash.c -o compute_hash -lcrypto. All three approaches, plus the command line, produce identical digests.

Four use cases

1. Committing to a secret without revealing it. Our game, generalized. Hash the secret and publish the hash: disclosing it doesn't disclose the secret (irreversibility), and once published you can't change the secret without detection (collision resistance). Example: you've found a way to predict the stock market and don't want to announce your predictions in advance. Hash them, with a random nonce, and post the hash. Later, people can verify your predictions were what you claim. (Useful for Lab 4.)

2. Integrity verification. You want to know whether OS kernel files have been modified by malware. You could keep a spare copy of every file and compare — wasteful and impractical. Instead, hash them and store the 32-byte digests. Before running the code, hash it and compare; if it doesn't match, don't run it. The hash is equivalent to a duplicate copy for this purpose, at a tiny fraction of the size.

This is why downloads often publish a hash. But is that good enough? Only partly: comparing hashes tells you that you received the same bytes the site is serving, which is useful for checking a mirror against the primary. It tells you nothing about whether the site is trustworthy — a malicious site will happily publish the hash of its malicious file.

3. Password verification. Never store passwords in plaintext. Store a hashed version; to authenticate, hash what the user typed and compare. Linux keeps these in /etc/shadow: 

seed:$6$wDRrWCQz$IsBXp9.9wz9SGrF.nbihpoN5w.zQx02sht4cTY8qI7YKh00wN/...:17372:0:99999:7:::

The fields are $-delimited: the username, then 6 identifying the algorithm (1 = MD5, 5 = SHA-256, 6 = SHA-512), then the salt, then the password hash.

The salt is a random string, unique per user, mixed into the password before hashing. It defeats rainbow tables — precomputed tables of hashes for common passwords — because the attacker would need a separate table per salt. Linux also runs the hash 5,000 times, which a legitimate user logging in never notices but which slows a brute-force attacker by a factor of 5,000. Both defenses are about changing the economics rather than making cracking impossible.

4. Trusted timestamping (RFC 3161). You want to prove a document existed at a point in time, and you want non-repudiation. A Time Stamp Authority receives a hash of your document, signs the hash together with the current time using its private key, and returns a token. You can later prove the document existed at that time — assuming the TSA is trustworthy. Old school: publish the hash in a newspaper. New school: write it to a blockchain.

A scenario worth thinking about: you're pitching a startup idea to a venture capitalist you don't entirely trust, and want to prove you wrote your business plan before the meeting. Reputable VCs won't sign an NDA. So hash the business plan and store the hash in a blockchain, where it's timestamped. If you later need to prove you had the idea, produce the plan and let people check the hash.

Asymmetric cryptography

Symmetric crypto requires both parties to know a shared secret key, and the key exchange problem has no good answer within symmetric crypto. Asymmetric (public key) cryptography, from Diffie-Hellman in 1976 and RSA in 1978, takes a radically different approach: sender and receiver share no secret at all. Each party has a public key known to everyone and a private key known only to themselves.

Anyone can encrypt to Bob with his public key, and only Bob can decrypt:

m = KB−(KB+(m))

Never reveal your private key; freely publish your public key. This revolutionized a 2000-year-old field in which all cryptography had been symmetric — and similar ideas emerged independently and at roughly the same time in the US and (classified) in the UK.

RSA

RSA (Rivest, Shamir, Adleman) is the widely used implementation. Two requirements: the key pair must satisfy KB−(KB+(m)) = m, and given the public key it must be computationally infeasible to compute the private key. (Details of key generation are in the supplemental slides.)

One further property matters enormously: order does not matter.

KB−(KB+(m)) = KB+(KB−(m)) = m

Use the public key first and the private key second, or the reverse, and you get the same result. That symmetry is what makes digital signatures possible: encrypting with your private key produces something anyone can decrypt with your public key — useless for confidentiality, but proof that you produced it.

Digital signatures for integrity

Bob sends a digitally signed message by hashing it and encrypting the digest with his private key, attaching that signed digest to the message. Alice hashes the received message herself, decrypts the signed digest with Bob's public key, and compares. A match means the message wasn't altered and Bob produced the signature.

Note that we sign the hash rather than the message. Asymmetric operations are slow, and the hash is short and fixed-length, so signing a digest gives the same guarantee at a fraction of the cost.

Asymmetric keys alone don't give authentication

Here's a protocol that looks like it authenticates Alice. Alice says "I am Alice." Bob sends a nonce R — a number used only once, to prevent replay attacks. Alice returns R encrypted with her private key. Bob asks for her public key, decrypts, and gets R back. He reasons: no replay is possible because of the nonce, and only Alice knows the key that encrypts it, so this must be Alice.

But it isn't. Trudy mounts a man-in-the-middle attack, posing as Alice to Bob and as Bob to Alice. Trudy says "I am Alice"; Bob sends R; Trudy returns R encrypted with Trudy's private key; Bob asks for the public key and Trudy sends Trudy's public key; Bob decrypts successfully and authenticates Trudy as Alice. Everything checks out arithmetically. When Bob then sends a private message encrypted with what he believes is Alice's public key, Trudy decrypts it, reads it, re-encrypts it with Alice's real public key, and forwards it. Both Alice and Bob are satisfied, and Trudy has read everything.

Find the mistake: nothing in the protocol ties the public key Bob received to the identity "Alice." The crypto worked perfectly; the binding was never established. This is the same failure as ARP and DNS — believing a reply because it arrived.

Certification authorities

A certification authority (CA) binds a public key to a particular entity. An entity — person, website, router — registers its public key with the CA and provides proof of identity. (For a server, the CA might ask the operator to place a specific file on it and then confirm the file appears, demonstrating control of the server.) The CA then creates a certificate binding the identity to the public key, and digitally signs it with the CA's private key. The certificate says, in effect, "the CA asserts that this is Bob's public key."

When Alice wants Bob's public key, she gets his certificate — from Bob or anywhere else, it doesn't matter — and applies the CA's public key to it to recover Bob's public key. If she trusts the CA, and the key checks out, she can be confident she's talking to Bob rather than an impostor. And Bob never revealed his private key to anyone, including the CA.

Note where the trust went. We haven't eliminated the need to trust; we've concentrated it. Everything now rests on trusting the CA and on holding an authentic copy of the CA's public key, which your browser and OS ship with.

Session keys: using both kinds of crypto

Asymmetric encryption is computationally intensive — symmetric DES is at least 100 times faster than RSA. So real systems use each where it's strong:

  1. Use public key crypto, with certificates, to authenticate and to exchange a symmetric session key KS.
  2. Use symmetric crypto (AES) with KS to protect the actual data.

Which delivers all three properties: confidentiality from symmetric encryption under the session key, authentication from the CA's signature on the certificate (so no man in the middle), and integrity from MACs proving the message wasn't altered. This pattern — asymmetric to bootstrap, symmetric to carry the load — appears in every system in the rest of these notes.

TOR: the onion router

When you log on to a server, anyone sniffing along the way sees your traffic. Even if the data is encrypted, the metadata remains: source, destination, timing, volume. Can the source and destination be hidden too?

TOR (The Onion Router) obscures the message and both endpoints. It's one implementation of onion routing, originally developed by the US Naval Research Laboratory, and there are thousands of TOR nodes worldwide (including one in the Lebanon library).

How it works:

  1. The user picks TOR nodes at random to form a circuit — three by default. The first is the entry node, the last the exit node, which forwards to the destination server.
  2. Beforehand, the user does a separate key exchange with each node in the circuit using Diffie-Hellman, obtaining keys k1, k2, k3. No one else knows these keys, and no node knows the others' keys.
  3. The user encrypts the message three times — in layers, hence "onion." Only the first node can remove the first layer, and having done so it sees only that the message goes to the second node. It cannot read the message or learn the final destination.
  4. The second node decrypts its layer, still unable to read the message or destination, and forwards to the exit node.
  5. The exit node removes the final layer, learns the message and destination, and forwards it — but does not know where the message originally came from. It knows only the previous node.

The key property: no single node knows both the user and the server. The entry node knows who you are but not where you're going; the exit node knows where you're going but not who you are; the middle node knows neither. Each node remembers only which node a request came from, which is enough to route the reply back.

Downsides. It's slow — three extra hops plus three layers of crypto. And the anonymity is not unconditional: an adversary who controls both the entry and exit nodes can correlate traffic timing and volume to infer who is talking to whom. (In class: start the TOR browser, visit a site, and check the apparent location at ipapi.co — the exit node might be anywhere. File → New Circuit for this Site picks a different path.)

TLS

Transport Layer Security is the widely deployed security protocol sitting above the transport layer, supported by essentially all browsers and web servers as https on port 443. It provides confidentiality via symmetric encryption, integrity via cryptographic hashing, and authentication via public key cryptography — exactly the composition from the session key section.

A note on names: the predecessor, SSL (Secure Sockets Layer), was deprecated in 2015, and TLS 1.3 was published in 2018. People still say "SSL" when they mean TLS.

Structurally, TLS sits between the application and transport layers. Unprotected data comes down from the application; TLS handles encryption, decryption, and integrity checks; and protected data goes to the transport layer.

The handshake

Before communicating securely, client and server must agree on an encryption algorithm and key, a MAC algorithm, and a key exchange algorithm. Both sides must agree or the connection is refused. The TLS 1.2 handshake:

  1. Client Hello — the client sends the list of ciphers it supports (e.g. AES), a random nonce (to prevent replay attacks), and the maximum TLS version it supports.
  2. Server Hello — the server decides which cipher to use, sends its own random nonce, and names the TLS version.
  3. Certificate — the server sends its certificate, containing its public key signed by a CA. The client verifies it, which is what prevents a man in the middle, and now knows it's talking to the intended server. "Hello Done" ends this phase. (In some settings the client also sends a certificate; typically not on the web.)
  4. Pre-master secret — the client generates a random number, encrypts it with the server's public key, and sends it. Only the real server can decrypt it.
  5. Master secret — both sides combine the pre-master secret with the two nonces to produce a 48-byte master secret. Note that both nonces contribute, so neither side alone determines the key.
  6. Finished — each side sends an encrypted summary of all the handshake messages, and checks that what it received matches what it computed. This detects any tampering with the earlier, unencrypted handshake messages.

Records

After the handshake, data moves in records, each with a header and payload. The header carries the content type (alert, application data, heartbeat, or change cipher spec — 0x17 is application data), the TLS version, and the payload length. The payload holds the Layer 7 message plus a MAC: the sender computes it over the data, and the receiver recomputes and compares to detect modification.

Sending: take data from the application layer, add the header, encrypt the payload, hand the record to the transport layer. Receiving: take data from TCP, strip the header, decrypt, pass up to the application.

Crucially, the transport, network, and link layer headers remain visible to an adversary — the MAC address is needed for switching and the IP address for routing, so they cannot be encrypted. Only the application data is protected. So TLS does not provide anonymity. It provides confidentiality of the payload, integrity via the MAC, and authentication via the server's certificate. An eavesdropper still sees exactly whom you're talking to, which is the gap TOR and VPNs address.

You can inspect all of this in a browser: in Firefox, click the lock in the URL bar and select More Information. A typical connection reports ECDHE for key exchange (elliptic curve Diffie-Hellman ephemeral, generating a new private key per connection), RSA for authenticating certificates, 128-bit AES in GCM mode for encryption, and SHA-256 for hashing. Which prompts the question: why use AES for encryption rather than just RSA? Because RSA is far too slow for bulk data.

VPNs and tunneling

A LAN serves a physical location, but people outside frequently need access — working from home, traveling, partners and customers. One option is to give inside devices routable addresses (or set up port forwarding) and expose them to the Internet. The problem is attack surface: Netscout found exposed devices attacked within five minutes. Networks are often "hard and crunchy on the outside, soft and chewy on the inside," so exposing an interior device is worse than it sounds.

Instead: keep inside devices on non-routable addresses (10.0.0.0/8, 192.168.0.0/16), put a firewall at the border blocking direct connections inward, and expose exactly one machine — a VPN server. The VPN server authenticates outsiders and creates an encrypted tunnel, giving a remote user access to the LAN as if the device were inside. Goals: confidentiality, integrity, authentication, and — note — availability, since the VPN server is now a single point of failure.

TLS tunneling in three steps

The technique is TLS tunneling (also called TLS/SSL tunneling). Suppose two private networks, 10.0.7.0/24 and 10.0.8.0/24, with a tunnel app on each side.

Step 1: establish the TLS tunnel. The VPN client app exchanges credentials with the VPN server; each authenticates the other; TLS encrypts the traffic, and each TLS record carries a MAC to prevent tampering. Each side is configured to route traffic for the other's subnet through the VPN.

Step 2: forward IP packets. The VPN client takes the original IP packet, encrypts the whole thing — source address, destination address, and payload — and adds a new header addressed to the VPN server. The packet is routed across the Internet over the TLS connection from step 1.

Step 3: release the packets. At the VPN server, strip the new header, decrypt the payload, verify it wasn't changed, and send the original packet on to its destination on the other network.

The essential difference from plain TLS: TLS sits above the transport layer, so the source and destination IP addresses are exposed even when the payload is encrypted. In a VPN tunnel the original IP header is inside the encrypted payload, so a sniffer sees only a packet bound for the VPN server and learns nothing about the ultimate destination or the data. (An alternative approach, IPSec, does this at the IP layer; TLS tunneling is more common.)

Bypassing firewalls

The same mechanism has a second use. Imagine a country whose firewall inspects destination IP addresses and drops packets bound for blacklisted sites. Establish a VPN to a server that isn't on the blocked list — in another country, say. The firewall cannot see the real destination, because the original IP header is encrypted inside the tunnel; it sees only traffic to the VPN server, and allows it. Return traffic comes from the VPN server's address, also not blacklisted, so it's allowed back.

Note that this is the same technical fact viewed from two directions: hiding the inner destination is a security feature for a remote worker and a censorship-circumvention tool for someone behind a national firewall. The mechanism doesn't care which.

Wi-Fi security

An arriving mobile client must do three things: associate with the access point, perform mutual authentication with the network, and encrypt over-the-air frames — both during authentication and afterward for user data.

The sequence has two stages. First, discovery of security capabilities: the AP advertises its presence via a beacon frame (or the device sends a probe request), the AP states which forms of authentication and encryption it provides, and the device requests the ones it wants. At this point the device is not authenticated and no encryption keys are known. Second, mutual authentication and key derivation: the AP and mobile may already share a secret such as a password, and they use that shared secret plus nonces (against replay attacks) plus cryptographic hashing (for message integrity) to authenticate each other and derive a symmetric AES key for the session.

The standards, and two modes

The lineage runs WEP (Wired Equivalent Privacy), then WPA and WPA2 in 2004, then WPA3 in 2018.

Each comes in two flavors:

The infrastructure difference matters: in personal mode the authentication is between device and AP, while in enterprise mode it is mostly between the device and the authentication server, with the AP acting as a pass-through.

WPA2-PSK, phase 1: association

Packets 1–5 of a capture, with the password already known ("pre-shared") to both sides:

  1. The AP broadcasts 802.11 beacon frames.
  2. The client sends an 802.11 Probe Request.
  3. The AP responds with an 802.11 Probe Response.
  4. The client sends an 802.11 Authentication frame requesting Open System — that is, no password authentication.
  5. The AP responds with an 802.11 Authentication frame, status "Successful."

Note the name and note what has happened: despite frames labeled "authentication" and a successful status, no real authentication has occurred yet. This is only association.

WPA2-PSK, phase 2: the 4-way EAPOL handshake

EAPOL is Extensible Authentication Protocol over LAN. The client and AP now have an unsecured 802.11 session and both know the shared secret. The four-way handshake uses that secret and fresh nonces to generate a new one-time session key:

  1. The AP sends an 802.1x EAPOL message with nonce1.
  2. The client uses the shared secret and nonce1 to generate a reply carrying a MIC (message integrity code), and generates and sends nonce2.
  3. The AP checks the MIC — verifying the client's liveness — generates a new AES session key from the shared secret and MIC, and sends it.
  4. The client verifies the MIC, ACKs, and installs the AES session key. Both sides are ready.

Three things each element buys: the shared secret encrypts and provides integrity for the EAPOL messages; the nonces guarantee liveness and protect against replay; and the new one-time AES session key protects against brute-force attacks on the shared secret itself. And the critical property: the shared secret is never actually exchanged — both sides derive the session key from it independently.

802.1x enterprise

Enterprise authentication uses a three-party framework with its own vocabulary:

EAP runs primarily between the client and the authentication server, with the AP mostly a pass-through, and credentials stored at the client and the server. There are roughly forty different EAP protocols, differing in what credentials they use: passwords, certificates, SIM cards, tokens. Common ones include EAP-MD5, EAP-TLS, EAP-PEAP, EAP-TTLS, EAP-FAST, and Cisco LEAP. EAP-TTLS (Tunneled TLS, RFC 5281) establishes a TLS tunnel first and then carries the actual credential exchange inside it — the same bootstrap-then-protect pattern once again.

Exercises

To do before/around the next class:

Terms

Not a comprehensive reference — the textbook has much more — but these are the terms from Day 12 that will keep coming back.

CIA triangle
Confidentiality (only sender and receiver understand the message), Integrity (no undetected alteration), Availability (the service is reachable). Authentication (each party confirms the other's identity) is usually added.
anonymity vs. security
Security is the CIA properties; anonymity is unlinkability — being unable to connect a message to its sender or receiver. Encryption can protect content while leaving metadata fully exposed.
non-repudiation
The property that a sender cannot later deny having sent a message.
plaintext / ciphertext
The message m before and after encryption. KA(m) is m encrypted with key KA.
symmetric key cryptography
Sender and receiver share one key KS used for both encryption and decryption. Fast, but requires solving key exchange first.
substitution cipher / Caesar cipher
Each plaintext character maps to one ciphertext character; the permutation is the key. A Caesar cipher is the special case of a fixed alphabet shift.
frequency analysis
Breaking a substitution cipher by matching ciphertext letter frequencies to known plaintext-language frequencies. Works because a 1:1 mapping changes letters but not their frequencies.
polyalphabetic cipher
Using N substitution alphabets and encoding position i with the ith alphabet, so a repeated character maps to different ciphertext characters. The Enigma principle; still breakable given enough ciphertext and reused alphabets.
transposition cipher
Rearranging character positions without substituting them, e.g. writing the message into a matrix and reading down columns.
XOR properties
A⊕0 = A; A⊕A = 0; associativity; and (B⊕A)⊕A = B, which is what makes XOR encryption reversible with the same key. Vulnerable to known plaintext attacks, since message ⊕ ciphertext yields the key.
S-P network
A substitution-permutation network: the basis of modern block ciphers such as AES. A key schedule produces round keys; each round applies an S-box and a P-box and XORs the next round key.
confusion / diffusion
Confusion (from S-boxes) makes the key-to-ciphertext statistical relationship too complex to exploit; diffusion (from P-boxes) spreads plaintext redundancy across the ciphertext.
avalanche effect
Changing one input bit changes roughly half the output bits, so every output bit depends on every input bit.
cryptographic hash function
A deterministic function producing a fixed-length digest, with irreversibility (can't recover input from digest), collision resistance (distinct inputs give distinct digests), and pseudorandomness.
MD5 / SHA-1 / SHA-2 / SHA-3
MD5 (128-bit, collision resistance broken 2004); SHA-1 (160-bit, deprecated after 2005, collision found 2017); SHA-2 (SHA-256, SHA-512 — the current standard choice); SHA-3 (2015, different construction as insurance).
commitment
Publishing a hash of a secret to lock yourself in without revealing it. Irreversibility protects you; collision resistance protects the other party. Use a nonce when the input space is small.
nonce
A number used only once, included in a protocol to prevent replay attacks or to prevent brute-forcing a commitment over a small input space.
salt
A random, per-user string mixed into a password before hashing, so that identical passwords produce different stored hashes and precomputed rainbow tables are useless.
rainbow table
A precomputed table of hashes for likely passwords, used to reverse unsalted password hashes quickly.
trusted timestamping
RFC 3161: a Time Stamp Authority signs a document's hash together with the current time, so the document can later be proven to have existed then. Blockchains serve the same purpose without a trusted third party.
asymmetric (public key) cryptography
Each party has a public key known to all and a private key known only to them, so no shared secret is needed. From Diffie-Hellman (1976) and RSA (1978).
RSA
The common public key algorithm. Its key property here: order doesn't matter — applying the private key then the public key gives the same result as the reverse, which is what enables digital signatures.
digital signature
Hashing a message and encrypting the digest with the signer's private key. Anyone with the public key can verify both integrity and origin. The hash is signed rather than the message because asymmetric operations are slow.
man-in-the-middle attack
Trudy poses as Alice to Bob and as Bob to Alice, substituting her own public key. The cryptography verifies correctly; what's missing is any binding between a key and an identity.
certification authority (CA)
A trusted third party that verifies an entity's identity and issues a certificate binding that identity to its public key, signed with the CA's private key. Anyone with the CA's public key can extract and trust the entity's key.
session key
A symmetric key exchanged using public key crypto and then used with a fast cipher (AES) for the bulk of the data. Symmetric ciphers are on the order of 100× faster than RSA.
TOR (The Onion Router)
Anonymity network routing traffic through a circuit of (by default three) randomly chosen nodes, with a separately negotiated key per node and the message encrypted in layers. No single node knows both endpoints. Slow, and vulnerable to traffic analysis if one party controls both entry and exit nodes.
circuit / entry node / exit node
The chosen path through TOR, its first node (which knows the user but not the destination), and its last (which knows the destination but not the user).
TLS
Transport Layer Security: confidentiality via symmetric encryption, integrity via hashing, authentication via public key certificates. Sits between the application and transport layers; https on port 443. Successor to SSL.
TLS handshake
Client Hello (ciphers, nonce, version), Server Hello (chosen cipher, nonce, version), server Certificate, client's encrypted pre-master secret, both sides deriving a 48-byte master secret from the pre-master and both nonces, then Finished messages verifying the handshake wasn't tampered with.
TLS record
The post-handshake data unit: header (content type, version, length) plus encrypted payload and a MAC for integrity.
MAC (message authentication code)
A value computed over data that a receiver recomputes to detect modification. (Not to be confused with a MAC address.)
VPN (virtual private network)
An encrypted tunnel letting a remote device access a private LAN as if inside it, with a single exposed VPN server behind a firewall instead of many exposed hosts.
TLS tunneling
Encrypting an entire IP packet — headers included — and wrapping it in a new packet addressed to the VPN server, so eavesdroppers learn neither the real destination nor the data. The reason a VPN hides more than plain TLS does.
WEP / WPA / WPA2 / WPA3
The succession of Wi-Fi security standards, WEP being the original and long-broken one, WPA and WPA2 from 2004, WPA3 from 2018.
personal vs. enterprise Wi-Fi security
Personal (WPA2/3-PSK) uses one pre-shared password for all devices, negotiated between device and AP. Enterprise uses per-user credentials and an authentication server (RADIUS), with the AP as a pass-through.
EAPOL / 4-way handshake
Extensible Authentication Protocol over LAN. The four-message exchange in which AP and client use the shared secret plus two nonces to verify each other via MICs and derive a fresh AES session key — without ever transmitting the shared secret.
MIC (message integrity code)
The integrity value carried in EAPOL messages, computed from the shared secret and a nonce, proving the sender knows the secret and is live.
802.1x: supplicant / authenticator / authentication server
The client needing access, the AP relaying messages, and the server holding credentials and access rights.
EAP
Extensible Authentication Protocol: roughly forty variants differing in credential type (passwords, certificates, SIM cards, tokens). EAP-TTLS (RFC 5281) builds a TLS tunnel and exchanges credentials inside it.

Credit: Most information on this page is from Computer Networking: A Top-Down Approach, 9th edition by Kurose and Ross, or from Internet Security: A Hands-on Approach" by Du.
This page was generated by Claude from in-class slides.