---
title: Signature Replay Vulnerability (SRV)
url: https://www.emergentmind.com/topics/signature-replay-vulnerability-srv
type: topic
---

# Signature Replay Vulnerability (SRV)

Signature Replay Vulnerability (SRV) denotes a class of failures in which an artifact that was previously valid under an authentication or verification procedure remains reusable outside its intended scope. Across the literature, that artifact may be a digitally signed message, an HMAC-tagged packet, a local IoT command carrying a valid `sign` field or token, an OCSP response, an off-chain authorization for a smart contract, a recorded wake-word or command accepted by a voice interface, a copied return-address/MAC pair in backward-edge control-flow protection, or a replayed synthetic utterance whose physical re-recording masks the spoofing cues learned by an audio detector [2401.12184] [2511.09134] [1609.03047] [1904.06591] [1902.00888] [2505.14862]. The unifying condition is not mere duplication of traffic, but acceptance of stale or transplanted authenticated material because freshness, one-time-use semantics, or context binding is absent, weak, or misapplied.

## 1. Conceptual definition and distinguishing features

In its narrow cryptographic sense, SRV arises when a verifier accepts a previously authenticated or signed input more than once because the authenticated material is not bound to a nonce, timestamp, sequence counter, session, device identity, chain, contract, or other execution context. Consumer IoT makes this distinction explicit: naïve replay resends cleartext or encoded commands that were never authenticated, whereas SRV reissues an already authenticated or signed local command because the signature or token remains valid beyond its first use [2401.12184]. Smart-contract work formalizes the same problem at the application layer: a contract may verify an ECDSA signature correctly, yet still be vulnerable if it does not enforce one-time-use or proper domain binding, producing the archetype of “one signature, multiple payments” [2511.09134].

The OCSP literature extends SRV from simple reuse to signature repurposing. There, the responder signs $s=\mathrm{Sign}_{sk}(H(m))$ for a predictable `tbsResponseData` structure. If $m$ is predictable, insufficiently unique, or collides with another message $m'$ such that $H(m)=H(m')$, then the same signature $s$ verifies for both $m$ and $m'$ [1609.03047]. In this setting, replay and collision-assisted misuse are both failures of context binding.

Other domains use the term more broadly but preserve the same logical core. In voice-driven systems, replayed audio is accepted as genuine because the interface does not distinguish a prior legitimate utterance from a live one [1904.06591]. In audio deepfake detection, SRV denotes the phenomenon whereby replaying and re-recording a synthetic utterance through a loudspeaker–room–microphone path alters the acoustic signature that the detector has learned to treat as spoofing, so the deepfake appears bona fide [2505.14862]. These usages move from cryptographic signatures to physical or learned signatures, but still center on reusability of previously valid evidence outside its intended verification context.

## 2. Principal manifestations across technical domains

The literature documents SRV in protocol security, consumer IoT, smart-contract authorization, control-flow integrity, message authentication, and audio systems.

| Domain | Replayed artifact | Immediate failure mode |
|---|---|---|
| Consumer IoT | Local command, token, ciphertext, or `sign` field | No freshness binding; static tokens; stateless command processing |
| Voice-driven interfaces | Recorded wake-word or command audio | Replay accepted as genuine speech |
| OCSP | Signed `tbsResponseData` or stale signed status | Weak context binding; predictability; collision/replay of valid responses |
| Smart contracts | Off-chain ECDSA signature | No nonce, no `usedSig`, no deadline, or weak EIP-712 binding |
| Backward-edge CFI | Valid $(RA,\mathrm{MAC})$ pair | Independent per-return authentication permits reuse |
| Message authentication | $(m,\mathrm{HMAC}(K,m))$ pair | Integrity without freshness |
| Audio deepfake detection | Re-recorded synthetic utterance | Replay channel masks spoof signatures learned by detector |

These manifestations are structurally related but operationally distinct [2401.12184] [1904.06591] [1609.03047] [2511.09134] [1902.00888] [1602.02148] [2505.14862].

Representative cases are concrete. In consumer IoT, Meross smartplug and Meross Garage Opener carried a `sign` field that remained valid on reissue; Nanoleaf’s companion app used secure HTTP locally but its local API exposed a fixed token; Tapo smartplug replay worked until reboot because a new key was negotiated only on restart [2401.12184]. In voice-driven interfaces, Amazon Echo executed replayed orders and IoT control, while Google Home verified only the wake-word and then accepted subsequent commands in another person’s voice [1904.06591]. In smart contracts, the literature distinguishes Cross-chain Replay Attack, Cross-project Replay Attack, Contract Account Signature Replay, Signature State Management Issue, and Signature Malleability Attack as five SRV families [2511.09134]. In backward-edge CFI, the vulnerability appears when returns are protected by storing $\mathrm{MAC}_K(RA)$ or similarly weak context, allowing a previously observed valid pair to be copied back onto the stack before a return [1902.00888].

## 3. Failure mechanisms and threat models

The most common mechanism is absence of freshness. IoT studies attribute successful replay to missing nonces, timestamps, or sequence counters in authenticated fields; static API tokens or session identifiers that do not expire or rotate; and devices that do not track used freshness values [2401.12184]. The smart-contract literature describes the same pattern as omission of nonce consumption, per-signature usage tracking, or deadline checks [2511.09134]. The HMAC literature states the principle directly: HMAC provides integrity and origin authentication, not freshness, so the exact same pair $(m,\mathrm{HMAC}(K,m))$ is accepted again if resent later [1602.02148].

A second mechanism is insufficient context binding. Smart contracts require domain separation through `chainId`, `verifyingContract`, and a function-specific `TYPEHASH`; omitting these enables reuse across chains, contracts, identities, or functions [2511.09134]. OCSP signatures cover `tbsResponseData`, but the response is not bound to the requester, the Nonce is optional and may be mirrored from the requester, and certificate identification is based on `serialNumber`; predictable timestamps and attacker-controlled variability create conditions in which a responder behaves as a signing oracle [1609.03047]. Consumer IoT studies describe analogous weaknesses as poor session binding, missing transport security, or message authentication computed over message content alone rather than over freshness materials or device/session identifiers [2401.12184].

A third mechanism is stateless verification. Stateless command processors accept a command based solely on syntactic correctness and a valid `sign` field, without validating state transitions or prior receipt [2401.12184]. In control-flow integrity, naïve MAC-based schemes authenticate each return address independently; a copied pair remains valid wherever the same input is rechecked. Zipper Stack counters this by chaining return addresses through a protected register, with
$$
Top_i=\mathrm{MAC}_K(RA_i \parallel Top_{i-1}),
$$
so every valid return is bound to the exact prior chain state rather than to the return address alone [1902.00888].

Threat models vary by domain but share a common posture: the adversary can capture valid artifacts and later reinject them. In IoT, the attacker is on the same LAN, can sniff traffic promiscuously, and can inject packets [2401.12184]. In voice systems, proximity may be physical or achieved acoustically through another IoT device, and Amazon Alexa “Drop-In” was used to relay recordings into Google Home [1904.06591]. In smart contracts, the adversary can observe signatures on-chain and replay them where consumption semantics are absent [2511.09134]. In backward-edge CFI, the attacker can read and write process memory and even know the MAC key, but cannot modify a small set of privileged CPU registers [1902.00888].

## 4. Detection methodologies and empirical evidence

The most extensive empirical study in consumer IoT is REPLIOT, a device-agnostic methodology that runs on the access point and automates a Training Module, Attack Module, and Detection Module [2401.12184]. Traffic is captured with `tcpdump`, pre-processed with Pyshark, and novelty detection is trained over transport-layer payloads using Local Outlier Factor, Isolation Forest, and Elliptic Envelope. During replay, flows are replayed in reverse order, and the detector examines only the first $j$ responses in the queue, empirically $j=3$. On 41 consumer devices, 21 of 41 devices (51%) did not support local app↔device communication, and of the 20 devices with local connectivity, 15 (75%) were vulnerable to replay. All 15 were exploitable in the Non-Restart scenario, and 14 remained exploitable after restart. With Local Outlier Factor, detection accuracy ranged from 0.98 to 1 across devices and both scenarios [2401.12184].

Voice-driven interface work uses higher-order spectral analysis (HOSA) rather than supervised learning [1904.06591]. Replay is modeled as
$$
y(t)=h(t)*x(t)+\sum_{k=2}^{K} a_k [x(t)]^k+n(t),
$$
or, in discrete Hammerstein form,
$$
y[n]=\sum_{p=1}^{P}\big(h_p[n]*(x[n])^p\big)+v[n].
$$
The detector uses 1024-sample frames, 50% overlap, 1024-point FFTs, Rao–Gabr optimal window smoothing, and Hinich Gaussianity and linearity tests. Replay recordings exhibited significant intermodulation distortion spread in magnitude and phase spectra, every non-silence frame of the replay recordings failed Gaussianity and linearity tests, and less than 35% of non-silence frames failed these tests for direct speech [1904.06591]. The same study demonstrated cross-device replay from Alexa “Drop-In” into Google Home.

Audio deepfake detection shows a related but distinct form of SRV. ReplayDF contains 52,320 re-recordings derived from M-AILABS and MLAAD, spanning 109 loudspeaker–microphone combinations, six languages, and four TTS models [2505.14862]. Across six open-source detectors, replay consistently degraded performance. For public checkpoints, W2V2-AASIST moved from EER 10.6% to 24.8%; for the retrained ODSS version, EER rose from 4.7% to 18.2%, and adaptive RIR retraining reduced ReplayDF EER only to 11.09% [2505.14862]. The mechanistic finding is important: additive Gaussian/white/pink noise at 15–40 dB SNR barely affected accuracy, whereas real replay convolution caused 28–43 percentage-point drops for spoof, indicating that the dominant factor is the physical channel rather than additive noise [2505.14862].

In smart contracts, LASiR combines LLM-assisted static taint analysis with symbolic execution [2511.09134]. From 1,419 audit reports across 37 blockchain security companies, the study identified 108 with detailed SRV descriptions and classified five types of SRVs. Large-scale experiments covered 15,383 contracts involving signature verification, selected from 918,964 contracts across Ethereum, Binance Smart Chain, Polygon, and Arbitrum. The results reported that 19.63% of contracts that use signatures on Ethereum contain SRVs, and affected contracts held $4.76 million in active assets. Manual verification showed an F1-score of 87.90% for detection; on a labeled subset, Precision was 82.14%, Recall 95.83%, and F1 88.46%, with average detection time around 40 seconds per contract [2511.09134].

Protocol-level measurements in OCSP reveal broad structural exposure. The survey reported that 57.1% of assessed responders still used SHA-1, 41.4% used SHA-1 and supported scaling by Nonce or non-existent serial numbers, 74.3% supported either Nonce mirroring or unknown responses for non-existent serials, and all used one-second granularity for times [1609.03047]. These measurements do not themselves prove exploitation, but they define the predictable, attacker-scalable message space on which the autonomous collision attack relies.

## 5. Defensive constructions and mitigation strategies

The dominant mitigation pattern is to make authenticated messages fresh, unique, and context-bound. In consumer IoT, the recommended layers are per-message nonces $n$, timestamps $t$, monotonic counters $c$, anti-replay windows, challenge–response, transport security with mutual authentication, session binding to device identity, rate limiting, and secure defaults on local APIs [2401.12184]. The message-level prescriptions are explicit:
$$
tag=\mathrm{HMAC}_K(h(m)\parallel n \parallel t \parallel c),
$$
or
$$
s=\mathrm{Sign}_{sk}(h(m \parallel n \parallel t \parallel c)),
$$
with the device tracking used $(n,t,c)$ values and accepting only counters within a configured anti-replay window [2401.12184]. The same study warns not to rely on AP firewalls for local security and cites ENISA GP‑TM‑43 in support of device/software-resident defenses [2401.12184].

Smart contracts instantiate the same design principles through EIP-712 and EIP-2612-style patterns [2511.09134]. The mitigation set is: domain separation with `chainId` and `verifyingContract`, a function-specific `TYPEHASH`, per-owner nonces that are read and incremented atomically, optional `usedSig` mappings for defense in depth, deadline checks, signer-identity binding in EIP-1271 flows, and low-$s$/valid-$v$ enforcement through OpenZeppelin’s `ECDSA.recover` [2511.09134]. These measures are not interchangeable. `chainId` prevents Cross-chain Replay Attack, `verifyingContract` prevents Cross-project Replay Attack, identity binding prevents Contract Account Signature Replay, and nonce or `usedSig` state prevents Signature State Management Issue [2511.09134].

Protocol-oriented defenses against OCSP SRV focus on reducing predictability and removing catastrophic key reuse [1609.03047]. The proposed measures are to use dedicated OCSP responder certificates with `id-kp-OCSPSigning` and `CA=false`, increase time granularity or randomize `producedAt`, `thisUpdate`, and `nextUpdate`, disable mirrored Nonce and refuse to sign for non-existent serial numbers, impose client-side limits on acceptable `nextUpdate`, prefer stronger hashes than SHA-1, and, at the standards level, add responder-generated nonces and more specific certificate identifiers [1609.03047]. In this literature, disabling Nonce mirroring reduces attacker-controlled variability for collision search, but it also creates a tradeoff with anti-replay guidance; the tension is explicit rather than incidental [1609.03047].

The HMAC literature offers a clean replay-resistant construction based on time-scoped keys and unique message identifiers [1602.02148]. The time counter is
$$
T_c=\left\lfloor \frac{\mathrm{CurrentTime}-T_0}{T_s} \right\rfloor,
$$
with
$$
K_t=\mathrm{HMAC}(K,T_c), \qquad \mathrm{TMAC}(K,m)=\mathrm{HMAC}(K_t,m),
$$
and final authentication factors
$$
I=\mathrm{HMAC}(s,m), \qquad S=\mathrm{HMAC}(K_t,I),
$$
where $s$ is a unique message identifier recorded in a per-bucket replay cache only after successful verification [1602.02148]. Under the paper’s stated assumptions—secure HMAC, bounded clock skew, unique identifiers within the acceptance window, and correct state handling—this construction is claimed to provide “perfect resistance” to replay attacks [1602.02148].

Backward-edge CFI provides a structural answer to replayable authentication. Zipper Stack avoids per-pointer independence by authenticating the entire active call path as a MAC chain, protecting only the current chain anchor in a privileged register [1902.00888]. On FPGA, the hardware implementation reported average slowdown of 2.69% without cache and 1.86% with a MAC-result cache, with Shadow Stack at 2.36% [1902.00888]. In audio systems, defenses are correspondingly physical or signal-driven: HOSA-based replay detection can be inserted at wake-word and early-command stages, and the literature recommends complementing it with challenge–response, liveness checks, proximity or direction-of-arrival checks, and, for high-risk actions, second factors [1904.06591]. ReplayDF further indicates that channel-invariant training and real or high-fidelity simulated room/device responses are necessary, though not sufficient, for robust audio deepfake detection [2505.14862].

## 6. Conceptual boundaries, limitations, and open issues

SRV should not be conflated with adjacent phenomena. In consumer IoT, authenticated replay and naïve replay are analytically distinct: the latter succeeds because the device accepts unauthenticated LAN inputs, while the former succeeds because already authenticated material remains valid on reissue [2401.12184]. In smart contracts, transaction replay is a transaction-layer problem, whereas SRV is an application-layer problem in which a contract function accepts the same off-chain signature multiple times or across contexts [2511.09134]. Signature malleability is also not identical to SRV, although it can create replay-like effects by transforming one valid ECDSA signature into another valid signature for the same digest when $s$ and $v$ are not constrained [2511.09134]. In audio deepfake detection, replay vulnerability is not reducible to simple additive noise; the paper attributes the degradation primarily to convolutional and device effects [2505.14862].

Current detectors and defenses have domain-specific blind spots. REPLIOT marks TLS/QUIC and strong proprietary encrypted protocols as FAILED without deeper decryption; some functions are not externally observable; script creation remains manual; and failure to exploit a device is explicitly only a lower bound on vulnerability [2401.12184]. HOSA depends on device-specific calibration and is sensitive to ambient noise, reverberation, high-linearity playback chains, and very short utterances [1904.06591]. LASiR can produce false positives when unrelated state restrictions later block asset movement, and false negatives on inline assembly or non-standard crypto flows [2511.09134]. ReplayDF spans 109 setups, but real rooms, devices, distances, sound pressure levels, and placements remain unbounded; adaptive RIR augmentation improves EER but does not restore baseline performance [2505.14862].

Taken together, these studies characterize SRV as a recurring failure of freshness, uniqueness, and binding across multiple layers of computing systems. Whether the replayed artifact is a LAN command, an OCSP response, an ECDSA authorization, a copied return-address/MAC pair, or a re-recorded acoustic signal, the decisive question is the same: does verification attest only that the artifact was once valid, or does it attest that it is valid exactly here, exactly now, and exactly once [2401.12184] [1609.03047] [2511.09134] [1902.00888]?

Source: https://www.emergentmind.com/topics/signature-replay-vulnerability-srv