Cryptographic primitives protect individual messages. Protocols decide which messages to accept, from whom, and when. Protocols can fail even when every cryptographic operation works correctly, so focus on what each protocol proves, to whom, and what it leaves open. For authenticating people, focus on how each method fails and which defense matches which attack.

Security Protocols and the Adversary

A security protocol is a sequence of messages exchanged to achieve a goal, such as proving an identity or agreeing on a key. Protocols are analyzed against an adversary that controls the network. It can read, record, delete, delay, reorder, replay, and inject messages, start protocol runs with any party, and take part as a legitimate user with its own keys. It cannot break the cryptography.

An adversary in the middle (AiTM), also called a man in the middle (MITM), relays traffic between two parties who each believe they are talking directly to the other.

Key Establishment

Key establishment gets a shared secret key to the parties that need it, and only those parties. Pairwise keys grow as \(n(n-1)/2\), and they do not help two parties who have never met. Know the four approaches:

• A pre-shared key is distributed out of band. It works for small groups and is hard to change.

• A trusted third party shares a long-term key with every participant and issues session keys to pairs.

• Public key transport has one party generate a secret and encrypt it with the other’s public key.

• Diffie-Hellman key agreement lets two parties compute a shared secret from public values. It must be authenticated to resist an active attacker.

Replay and Freshness

A valid MAC shows that someone holding the shared key produced the message, and a valid signature shows that the private-key holder did. Neither shows when the message was produced or whether it was already accepted. A replay attack reuses a valid message outside its original context.

A message is fresh if the receiver has evidence that it belongs to the current exchange or an acceptable recent period. Know the three mechanisms and their costs:

• A nonce is a value used once. The party that wants assurance picks an unpredictable nonce and accepts only a reply that includes it under a MAC or signature. A nonce protects only the party that chose it.

• A timestamp avoids an extra round trip but requires clocks that agree within a tolerance. A replay inside that window succeeds unless the receiver remembers recent messages.

• A sequence number requires both sides to keep state and agree on how to handle gaps and restarts.

A freshness nonce ties a response to a current request. It is different from an AES-GCM nonce, which must never repeat under the same key, and from the per-signature value in ECDSA (the elliptic-curve signature algorithm), which must never repeat and must also be kept secret.

Challenge and Response

In challenge-response authentication, one party sends a fresh nonce, and the other returns a value only a key holder could compute, such as an HMAC of the nonce. The key never crosses the network, and a recorded response will not answer a new challenge. In one-way authentication, one party authenticates the other. In mutual authentication, both do.

A reflection attack works when both directions use the same key and computation. The attacker sends the challenger’s own nonce back in a second session and uses the answer in the first. The fix is to make the two directions distinguishable, by including the responder’s identity or using a different key in each direction.

Authenticating at the start does not protect later messages. If they are unprotected, an attacker can take over after authentication, which is session hijacking. An authenticated key exchange establishes shared keys and authenticates one or both participants, and those keys can then protect the messages that follow.

Key Distribution with a Trusted Third Party

A key distribution center (KDC) is a trusted third party. It shares a long-term key with each participant, which reduces the number of long-term keys from about \(n^2/2\) to \(n\). Every participant trusts the KDC to keep those keys secret and to give each session key only to the parties it was created for. Because the KDC knows every key, it can read any session it sets up and impersonate any participant, so an attacker who compromises it compromises everyone. A ticket is an encrypted credential that one party forwards to another and cannot read or change.

In each of these protocols, Alice wants to communicate with Bob, and Trent is the trusted third party that shares a long-term key with each of them and issues their session key. Understand how this family of protocols developed:

1. A basic protocol. The server sends Alice a session key and a ticket for Bob. Nothing establishes freshness, so a recorded ticket can be replayed to Bob indefinitely.

2. Needham-Schroeder (1978) adds Alice’s nonce, which shows Alice that the server’s reply is fresh, and a handshake that shows Bob that someone holding the session key is responding now.

3. The Denning-Sacco attack (1981): an adversary who recovers an old session key replays the old ticket to Bob and answers his handshake. Neither nonce tells Bob that the key itself is new.

4. The Denning-Sacco fix puts a timestamp inside the ticket, so Bob can reject old tickets himself, at the cost of synchronized clocks.

The general lesson is that evidence of freshness and of key possession has to be bound to the intended participant. Alice’s nonce does not protect Bob, and proof that someone holds a key does not show that it is the intended party.

Kerberos

Kerberos applies these ideas to an organization’s network and is the default authentication protocol for Windows domains. Understand how the key distribution center is split into two distinct roles:

• The authentication server (AS) verifies the user at login, using a key derived from the password, and issues a ticket-granting ticket (TGT).

• The ticket-granting server (TGS) accepts the TGT and issues a service ticket for each service. The password is not needed again, which provides single sign-on.

A ticket can be copied, so by itself it does not prove who is presenting it. An authenticator, the client’s name and the current time encrypted under the ticket’s session key, proves that the client holds that key. Services reject authenticators outside a tolerance window and remember recent ones, so replays fail.

The KDC is the center of trust. It must be available to issue tickets, and it holds every user’s and service’s long-term key, so compromising it compromises the whole system. Tickets encrypted under keys derived from human-chosen passwords can be guessed offline, so service accounts need long random passwords.

Public Key Authentication and Forward Secrecy

A signature on a fresh nonce shows that the signer’s private key was used in this exchange, and the verifier stores only a public key. A signature on a nonce alone can still be relayed, so a complete protocol binds it to the intended parties.

In public key transport, the client generates a random secret, encrypts it with the server’s public key, and sends it, and both sides derive session keys from it. TLS through version 1.2 offered this with RSA. Anyone who records the traffic and later obtains the server’s private key can decrypt every recorded session that used that key for key transport.

Diffie-Hellman does not authenticate anyone. An adversary in the middle runs one exchange with each side and shares a key with both. The fix is to sign the exchange with a long-term key that a certificate binds to an identity. In signed Diffie-Hellman, the long-term key only signs.

A hybrid cryptosystem uses public-key cryptography to authenticate the parties and establish a key, then protects the data with symmetric authenticated encryption, because public-key operations are slow.

Know the three key lifetimes:

• A long-term key authenticates a party across many connections.

• An ephemeral key, such as a fresh Diffie-Hellman private value, is used only to compute the shared secret and is then erased.

• A session key is derived from the shared secret and protects one connection.

Forward secrecy means that compromising a long-term key does not expose sessions recorded earlier. Ephemeral Diffie-Hellman provides it, because the values that produced each session key no longer exist. RSA key transport and Diffie-Hellman with a reused private value do not.

TLS

Transport Layer Security (TLS) protects HTTPS and many other connections. A TLS 1.3 connection runs in two phases: a handshake that sets up keys and authenticates the server, and then protected data transfer.

Phase 1: the handshake. Know what each part contributes:

• The client proposes TLS versions and algorithms, and the server chooses among them.

• Ephemeral Diffie-Hellman values from both sides produce a fresh shared secret with forward secrecy.

• The certificate chain binds the server’s public key to its domain name.

• The server’s signature over the transcript hash, a hash of the handshake so far, proves it holds the private key for this connection.

• Each side sends an HMAC over the transcript, confirming that both derived the same keys and saw the same messages.

Signing the transcript ties the server’s identity to this connection. An adversary who substitutes its own Diffie-Hellman value, or edits the list of versions and algorithms in a downgrade attack, changes the transcript, so the signature fails. TLS 1.3 removed RSA key transport and Diffie-Hellman with reused private values, so certificate-based handshakes always provide forward secrecy.

Phase 2: data transfer. TLS divides the data stream in each direction into chunks called records and protects each one with authenticated encryption (AEAD) under keys derived from the handshake. Each record’s protection includes its sequence number, which prevents an attacker from replaying records or changing their order without detection. The application still reads and writes an ordinary stream of bytes.

A client reconnecting to a server can send data in its first message, before the server replies. That early data can be replayed and lacks forward secrecy, so applications should accept it only when replaying it is harmless. TLS on the web authenticates only the server. Mutual TLS (mTLS) adds a client certificate.

Authenticating People

Identification is claiming an identity. Authentication verifies the claim. Authorization decides what the authenticated party may do.

The three authentication factors are something you know (a password), something you have (a phone or security key), and something you are (a fingerprint or face). Multi-factor authentication (MFA) requires factors from different categories.

Passwords and Second Factors

PAP sends the password to the server. A web login does the same inside TLS, so the password is protected in transit, but the server still receives it. CHAP returns a hash of the password and a server challenge, so the password never crosses the network, but the server must store the password in usable form.

For logins that send the password, as PAP and web logins do, the server should store salted password hashes, not passwords. A salt is a random value stored with each hash. It makes identical passwords hash differently and makes precomputed tables useless, but it does not slow down guesses against one account. A password hashing function, such as bcrypt, scrypt, or Argon2, is deliberately expensive, with a cost that can be raised over time.

A one-time password (OTP) is accepted once. Most are an HMAC, under a key shared by the device and the server, of a changing value: a counter for an HMAC-based one-time password (HOTP), or the current 30-second interval for a time-based one-time password (TOTP), which is what authenticator apps compute. An older approach, a hash chain, gives each login the previous value in a chain of hashes.

Be able to match each attack to its defenses:

Current NIST guidance favors length over complexity: long minimum lengths, no composition rules, no forced periodic changes, and checking new passwords against a blocklist.

Passkeys

A passkey is a public-key credential bound to one site. At registration, the device creates a key pair and the site stores the public key. At login, the site sends a fresh challenge. Before the device will use the private key to sign it, the user must unlock the key locally, with a fingerprint or face scan on devices that have a sensor, or with a device PIN. The check happens on the device, so neither the biometric nor the PIN is sent to the site.

Passkeys resist phishing because the browser, not the user, supplies the page’s origin. A passkey is bound to its site’s domain, so a lookalike site cannot request it, and the signed response covers the origin, so a relayed challenge fails. Theft of the site’s passkey records exposes public keys, not private keys.

Synced passkeys are copied to a user’s approved devices through a provider such as iCloud Keychain or Google Password Manager, so the private key leaves the device that created it. The provider encrypts it end to end, but the passkey is then only as safe as the provider’s account and recovery controls. Device-bound passkeys, such as those on a hardware security key, never leave one device. The remaining risks are weaker account recovery paths and malware or stolen session cookies after login.

Biometric Authentication

Biometric authentication verifies identity from physical or behavioral characteristics. Matching is approximate. The system compares a new sample with a stored template and accepts it if they are within a threshold. A fingerprint template, for example, records the positions of minutiae, distinctive points in the ridge pattern.

Know the error rates and how the threshold trades them off:

• The false accept rate (FAR) is the probability of accepting an impostor.

• The false reject rate (FRR) is the probability of rejecting the legitimate user.

• A stricter threshold lowers the FAR and raises the FRR. A receiver operating characteristic (ROC) curve shows every combination of the two that a system can reach. For a given system tested under given conditions, the threshold only selects a point on the curve. A better sensor, matcher, enrollment, or capture conditions can move the curve itself. A deployment chooses an operating point based on what it protects.

Verification compares a sample with one claimed identity’s template. Identification in the biometric sense, a different use of the word from claiming an identity, searches every template to find who the person is. Each additional comparison is another chance for a false match.

A presentation attack fools the sensor with a substitute, such as a photograph or molded finger, and liveness detection tries to confirm a live person. Templates cannot be protected with ordinary hashing, because a hash does not preserve similarity. They need other protection, such as encryption and access controls on a server, or secure hardware on a phone.

A stolen biometric cannot be revoked, the same traits are presented to every service, and samples lack a canonical form, so matching is approximate and searching many templates is expensive. Biometrics work best as a local check that unlocks a key on the device, as with passkeys.

What You Don’t Need to Study

The following are not required for the exam:

• Incidents, dates, figures, organizations, and people’s names. Understand the failures and defenses the incidents illustrate. Protocol and attack names used in this guide, such as Needham-Schroeder and Denning-Sacco, are still required.

• Protocol notation, exact message contents, Otway-Rees, the sidebar on Needham-Schroeder public-key authentication, and anything in the appendix.

• TLS message order, message names, and version history.

• Password-hashing parameters, benchmark numbers, PBKDF2, and the specific NIST requirements.

• S/Key, and how hash-chain one-time passwords are computed and verified.

• The FIDO2 and WebAuthn standards, and how providers synchronize passkeys. Understand how a passkey is bound to a site, how the user unlocks it on the device, and how synced and device-bound passkeys differ.

• Hybrid post-quantum key establishment, which was covered with integrity.

• Kerberos operational details and the name Kerberoasting.

• Biometric enrollment and feature-extraction steps, the names of specific minutiae and ridge patterns, and the comparison of irises and fingerprints.

• Cancelable templates and how liveness detection works. Know what liveness detection is for.

• Equal error rate (EER), coercion, and differences in biometric accuracy across populations.

Focus your review on these:

• What each protocol proves, to whom, and what it leaves open.

• Which freshness mechanism a protocol relies on, and its cost.

• How the adversary in the middle is stopped in Diffie-Hellman, TLS, and passkeys.

• Matching password and second-factor attacks to their defenses.

• Biometric error trade-offs, and why a biometric cannot be revoked.