In a Challenge-Response (C-R) authentication protocol, why is simply sending a certificate insufficient to prove identity?

Because an attacker can intercept the certificate and replay it later — a certificate proves the existence of a key pair, not that the sender currently possesses the private key.

* Bob sends a fresh nonce; only the real Alice can sign it, and freshness blocks replay. *

Naive (broken) protocol:

1. A → B: "I am A. Here is my certificate."
2. B verifies the certificate is valid

Problem: Eve intercepts Alice's certificate. Next time, Eve sends the same certificate to Bob, pretending to be Alice. Bob accepts because the certificate is valid — but Eve sent it!

Proper C-R protocol:

1. A → B: "I am A, prove you are B by signing this random nonce $N_A$"
2. B → A: "Here is $\text{sig}(N_A)$ with my certificate" (B signs the nonce with B's private key)
3. A verifies the signature on $N_A$ using B's public key from the certificate

Why this works:

• The nonce $N_A$ is fresh and unpredictable — Eve cannot prepare a valid signature in advance
• Only the real B possesses $K_{priv,B}$, so only B can sign the nonce
• The challenge (nonce) prevents replay — each authentication session uses a different random value

Key principle: In a C-R protocol, the verifier always asks a question (challenge) that only the authentic party can answer (response). Cryptographically, this means signing or MACing a random bitstring.

Go deeper:

• Challenge-response authentication — the protocol family behind identity proofs.