About Replay Attacks

Replay attacks attempt to reuse valid evidence into a new context. VVP offers best-in-class protections against attacks like these.

Protection 1: timing

STIR passports are JWTs that carry a signature, a timestamp (the iat field), and an expiration (the exp field). VVP requires that these values in the STIR passport be managed carefully to minimize risk from replays.

Before a VVP passport is signed, a current timestamp is generated and inserted into the passport's iat claim. An expiration date is also generated and inserted into the exp claim. Valid calls must take place on or after iat, but before exp — so the paired values establish a validity window. Any attempts to replay a passport must take place within this window, or they are rejected out of hand.

STIR suggests small validity windows, but does not recommend specific values or enforce further constraints. RCD and BCID passports leave this validity window equally unspecified. SHAKEN becomes more explicit about what values might be good but still does not enforce. VVP recommends 15 seconds — just long enough for a SIP INVITE to be routed and trigger the handset to ring — and requires that the validity window not exceed 60 seconds.

Protection 2: phone numbers

STIR passports (including VVP) also contain orig and dest phone numbers. Besides creating a validity window, signing a STIR passport also commits the caller to making a call from orig to dest , not between other phone numbers.

However, SIP routing doesn't use orig and dest; the originating number in SIP is stored in a From header on the SIP INVITE, and the destination number is stored in a To header. STIR does not require From and orig to correspond, or To and dest to correspond. However, VVP closes this vulnerability (as does SHAKEN); an attacker cannot replay an intercepted VVP SIP INVITE unless they are willing to route the call between the same orig and dest as the legitimate call.

Protection 3: call reason

Like RCD, VVP allows a call to carry branded information. An attacker cannot change the call reason when replaying a legitimate VVP passport. If the original call had no call reason, the replayed call must also have no call reason. If the original call had reason X, the replayed call must also have reason X. This further narrows the possible scope of an attack.

Additional protections

A determined and unusually capable attacker might still have an exploitable vulnerability, IFF:

• They find all of the other constraints acceptable. That is, they're attempting to conduct fraud within a 15-second validity window, using exactly the same two phone numbers, with the same call reason.

• They can prevent the legitimate call from ringing (so a replay attempt would be perceived by the callee as the only incoming call, instead of a second, redundant call).

• They can intercept SIP responses from the callee, inserting themselves into the streaming media handshake.

If callers and callees (or service providers for these parties) correlate CDRs, they will eventually detect a simple hijack of the streaming media, because callers will think calls ended quickly, whereas callees will think it continued. Such comparison is made more likely by VVP's ability to carry settlement evidence, because settlement requires agreement about whether a call connected. But this does not address the risk of replays used to construct a persistent MITM instead of a one-time hijack on the streaming channel. If the party conducting the replay attack can lurk in the streaming channel, but allow correct media to flow to correct parties most of the time, VVP has one more tool at its disposal. The verified party in a VVP conversation (often the caller, possibly the callee, or possibly both) has an AID and an agent that's capable of communicating on behalf of the AID's controlling party. This constitutes an out-of-band channel. It can be used to compare each party's views of ongoing communication. By periodically exchanging hashes of media packets, the parties can detect any tampering with media. If they detect a problem, or if they want to eliminate any risk of MITM eavesdropping, they can switch to a more secure channel like the one provided by Trust Spanning Protocol in SPAC mode.