Protocol Security Verification Questions

Learn to analyze cryptographic protocols for correctness: trace through message flows, verify each step accomplishes its goal, check that participants end with correct shared secrets, ensure authentication properties hold. Understand common protocol flaws: missing authentication, improper key derivation, incorrect ordering of operations. Be able to explain protocol logic: why must key exchange happen before encrypted communication, why do we need nonces, why does one-way functions matter for passwords.

HardTechnical

46 practiced

Case study: The Needham–Schroeder public-key protocol was shown to be vulnerable by Lowe's attack. Explain the Lowe attack trace in detail, show why BAN logic and early informal analyses failed to catch it, and describe Lowe's proposed fix. Finally, explain how modern formal tools (e.g., ProVerif, Tamarin) would detect the flaw and what intruder model they use.

Sample Answer

**Situation & short summary**The Needham–Schroeder public‑key (NSPK) protocol intended mutual authentication using nonces and public keys. Gavin Lowe showed an active man‑in‑the‑middle attack allowing an intruder I to impersonate A to B by replaying messages.

**Lowe attack trace (detailed)**1. A -> I(B): { Na, A }_{K_B} — A thinks she’s talking to B, sends nonce Na encrypted under B’s pubkey, but to I who forwards.2. I(A) -> B: { Na, A }_{K_B} — I initiates fresh session with B, forwarding A’s first message (appears from A).3. B -> A: { Na, Nb }_{K_A} — B replies to A (but actually to I acting as A) containing Na and new Nb.4. I -> A: { Na, Nb }_{K_A} — I forwards B’s reply back to original A.5. A -> I(B): { Nb }_{K_B} — A encrypts Nb to B’s key, believing she’s talking to B.6. I(A) -> B: { Nb }_{K_B} — I forwards Nb to B and completes session; B believes he’s talking to A, but is interacting with I.

Result: B authenticates A, but I learned Nb and can impersonate A to B later.

**Why BAN logic and early informal analyses missed it**- BAN logic idealises messages (removes origin and binding info) and assumes honest recipient association; it cannot model message reuse across concurrent sessions or active interleaving by an attacker.- Early proofs assumed freshness/binding implicitly: they didn’t model the intruder’s ability to relay messages between concurrent sessions or to initiate sessions under others’ identities. Thus the lack of explicit session identifiers/agent binding was not captured.

**Lowe's fix**- Add explicit identity into the second message: B -> A: { Na, Nb, B }_{K_A}- And A -> B: { Nb }_{K_B}Including B inside the encrypted reply binds the nonce to responder identity, preventing the attacker from confusing which responder produced Nb.

**Modern formal tools detection & intruder model**- Tools like ProVerif and Tamarin encode protocols in formal languages and attempt to prove secrecy/authentication properties under the Dolev–Yao intruder model: attacker controls the network, can intercept, forge, replay, and compose messages but cannot break cryptography (perfect encryption).- They automatically explore interleavings and concurrent sessions; both tools can find Lowe’s trace: - ProVerif: finds an attack by deriving a correspondence failure (authentication property violated). - Tamarin: produces an explicit attack trace and can reason about stateful properties and complex equational theories.- These tools succeed because they model active adversary capabilities and session interleaving missed by BAN-style idealisations.

**Takeaway for protocol design**Always bind nonces to agent identities and session context; use formal analysis under Dolev–Yao and multiple concurrent sessions to catch replay/relay attacks.

MediumTechnical

56 practiced

How would you check that a protocol correctly separates keys for encryption and MAC to avoid key reuse? Describe both specification-level checks (what the spec must state) and implementation-level tests (unit tests, key derivation checks, runtime assertions) you would run.

Sample Answer

**Brief approach**I would verify separation at two layers: the protocol specification (what must be true) and the implementation/tests (prove it is enforced and not accidentally reused).

**Specification-level checks**- State explicit key roles: e.g., "K_enc for AEAD encryption; K_mac for HMAC-SHA256." - Define the KDF label/Info strings and salt per-key: e.g., HKDF-Extract(PRK, salt); HKDF-Expand(PRK, L, "enc") -> K_enc; HKDF-Expand(PRK, L, "mac") -> K_mac. - Require independent domains: distinct lengths, counters, or algorithm identifiers. - Mandate key lifetime and usage constraints (never use K_mac for encryption and vice versa). - Include test vectors that show derived keys differ for given inputs.

**Implementation-level tests**- Unit tests: derive keys with protocol KDF and assert bitwise inequality and differing lengths/algorithms.

python

# python unittest pseudocode
k_enc = hkdf_expand(prk, info=b"enc")
k_mac = hkdf_expand(prk, info=b"mac")
self.assertNotEqual(k_enc, k_mac)

- Property tests / fuzzing: random PRK/salts ensure K_enc != K_mac across many inputs. - Conformance tests: verify AEAD uses only K_enc and MAC verifies with K_mac; mock crypto libs to record which key is passed to which API. - Static analysis: scan code for reuse of same variable/key across encryption and MAC callsites. - Runtime assertions: in debug builds assert key IDs/tags match expected purpose before use; fail-open only for tests. - CI checks: include the spec test vectors and unit tests in CI and enforce coverage for KDF/key use paths.

**Edge cases & reasoning**- Ensure labels are long/unique enough to avoid collisions; prefer string labels with context (protocol/version). - For pre-shared keys or raw secrets, require an Extract step to avoid related-key attacks. - If using AEAD, treat auth tag as part of AEAD and avoid separate MAC unless needed; if separate MAC used, ensure independent key.

EasyTechnical

50 practiced

Explain why a key-exchange must typically complete before sensitive encrypted communication begins. Provide two concrete failure modes that can occur if a party starts sending encrypted sensitive data before the key exchange has been authenticated or completed.

EasyBehavioral

46 practiced

Tell me about a time you discovered a protocol-level vulnerability or bug in a cryptographic implementation. Use the STAR method (Situation, Task, Action, Result). Focus on how you traced message flows, reproduced the issue, and validated the exploit's impact.

EasyTechnical

46 practiced

A protocol designer uses K1 = H(shared_secret || 1) and K2 = H(shared_secret || 2) as two separate keys for encryption and MAC. What checks would you perform to ensure this KDF usage is secure? Mention domain separation, output length, PRF assumptions, and how truncation affects security.

Sample Answer

**Brief verdict**The construction K1 = H(shared_secret || 1), K2 = H(shared_secret || 2) can be OK but needs careful checks: domain separation, output length vs security goals, strong PRF assumptions for H, and safe truncation rules. I would perform the checks below.

**Checks to perform**

- Domain separation - Ensure the “1” and “2” are encoded unambiguously (fixed-length or with a separator) so H(ss||1) ≠ H(ss||10). - Prefer explicit domain strings (e.g., H(... || "key|enc") and H(... || "key|mac")) or use HKDF-Expand with different info labels for robust separation. - Verify inclusion of protocol context (session id, role, algorithm id) so keys are bound to purpose and session.

- Output length and algorithm match - Confirm H output length ≥ required key lengths (e.g., 256-bit key for AES-256). - If H produces longer output than needed, derive then securely truncate; if shorter, use a KDF that yields more material (HKDF/HMAC-DRBG).

- PRF assumptions - Treat plain hash(x) as a PRF only with justification: prefer HMAC or HKDF which have established PRF/PRF-extract+expand guarantees. - If using raw hash, show security reduction or move to HMAC/HKDF to avoid relying on unclear assumptions.

- Truncation effects - Truncating a PRF output reduces security exponentially with number of bits removed. Never truncate below the desired security level (e.g., keep ≥ 128 bits for 128-bit security). - Account for birthday and collision bounds: if H has n-bit output, collision resistance ~2^(n/2). For MAC keys, ensure chosen length prevents practical attacks.

**Concrete recommendation**Use HKDF:

text

PRK = HKDF-Extract(salt, shared_secret)
K1 = HKDF-Expand(PRK, info = "enc|session|role", L = key_len)
K2 = HKDF-Expand(PRK, info = "mac|session|role", L = mac_key_len)

This gives formal domain separation, adjustable output length, and relies on well-studied PRF properties.

Unlock Full Question Bank

Get access to hundreds of Protocol Security Verification interview questions and detailed answers.

Join thousands of developers preparing for their dream job.