Replay attack
A replay attack is an attempt to resubmit an intercepted, valid message or credential in order to trigger an action a second time or at a different recipient.
A signature proves that a message is unchanged, but not that it arrives for the first time and at the right recipient. Whoever intercepts a signed payment instruction could, without protection, resubmit it any number of times. Defense comes from claims that bind a message to a time, a recipient and a one-time identifier: iat and exp for time, aud for the recipient, nonce or jti for uniqueness.
With agents, the risk is especially high because they send many messages automatically and evidence travels across several systems. Every party accepting evidence should therefore check whether it is fresh, intended for it and not yet used.
Example
An attacker intercepts the signed presentation of a mandate that an agent submitted to shop A and submits it to shop B. Because the key binding JWT names shop A as recipient and carries a time, shop B rejects the presentation.
How it differs
Tampering changes a message; a replay reuses it unchanged. The signature helps against tampering; against replay, time, recipient and one-time identifiers help, which are themselves signed.
In practice
- Require a recipient and a time in every piece of evidence, and reject deviating or old evidence.
- Store used identifiers such as jti or nonce for the duration of validity and reject repetitions.
- Keep validity periods short so the window for a replay stays small.
Role in KYA
For SD-JWT VC, KYA verifies the key binding JWT with recipient and time, and for HTTP signatures the signature parameters. Whether an identifier was already used can only be known by the accepting party, because KYA stores no state.
Related check: Agent and principal (subject_agent_binding). Do all parts name the same agent, is the principal named, does the agent hold the bound key?
Frequently asked questions
What is a replay attack?
Resubmitting an intercepted, valid message. Because it is unchanged, the signature alone does not help; claims on time, recipient and uniqueness are needed.
How does a nonce protect against replay?
The nonce is a one-time value that the recipient specifies or stores. If the same value appears again, it recognizes the repetition and rejects it.
Does short validity protect against replay?
It narrows the time window but does not remove the risk. Within validity, recipient and one-time identifiers are also needed.
Can KYA detect a replay?
KYA checks recipient and time in key binding JWTs and HTTP signatures. Whether an identifier was already used must be recorded by the accepting party itself, because KYA stores no state.