10 Faces of Blockchain Security (Part 4)

---

Signature Replay & Operational/Key-Management Failures

The final installment. The vulnerabilities in Parts 1–3 mostly had on-chain root causes. Part 4 crosses that boundary. One is a replay attack, where a cryptographic proof — a signature — gets reused out of context. The other is a case where the key management and operations outside the blockchain were breached entirely. Strikingly, many of the largest losses in history happened right at these “boundary points.”

---

9. Signature Reuse / Replay Attacks

The vulnerability

A signature is proof that “the owner of this key approved this message.” But if you don’t constrain the context in which a signature is valid, that same signature can be reused in a different context. Three common omissions:

1. Missing nonce → the same signature is resubmitted multiple times. E.g. one signature approving “withdraw 1 ETH” gets replayed for repeated withdrawals.
2. Missing chainId (pre-EIP-155) → a transaction valid on one chain remains valid on a forked chain. A real problem in the early ETH/ETC split.
3. Missing domain separator → a signature made for contract A also works on contract B.

Exploit flow

// Vulnerable: no nonce, no domain separation
function claim(uint amount, bytes memory sig) public {
    bytes32 hash = keccak256(abi.encodePacked(msg.sender, amount));
    address signer = recover(hash, sig);
    require(signer == authorizer, "invalid sig");
    payable(msg.sender).transfer(amount);   // same sig can be replayed infinitely
}

If anyone resubmits a once-issued valid sig to claim repeatedly, it passes every time because there’s no nonce. The approval happened once, but the withdrawal happens many times.

Defense pattern — EIP-712 structured signing

The key is to bind nonce + chainId + contract address into the signed data, so a signature is valid only for “this chain, this contract, this single execution.” EIP-712 standardizes exactly this scheme.

// Safe: EIP-712 domain separator + nonce + deadline
bytes32 public immutable DOMAIN_SEPARATOR;
mapping(address => uint256) public nonces;

constructor() {
    DOMAIN_SEPARATOR = keccak256(abi.encode(
        keccak256("EIP712Domain(string name,uint256 chainId,address verifyingContract)"),
        keccak256(bytes("ChainLabVault")),
        block.chainid,          // ← pins the chain
        address(this)           // ← pins the contract
    ));
}

function claim(uint amount, uint deadline, bytes memory sig) public {
    require(block.timestamp <= deadline, "expired");     // ← expiry
    uint256 nonce = nonces[msg.sender]++;                // ← single-use nonce
    bytes32 structHash = keccak256(abi.encode(
        keccak256("Claim(address to,uint256 amount,uint256 nonce,uint256 deadline)"),
        msg.sender, amount, nonce, deadline
    ));
    bytes32 digest = keccak256(abi.encodePacked("\x19\x01", DOMAIN_SEPARATOR, structHash));
    require(recover(digest, sig) == authorizer, "invalid sig");
    payable(msg.sender).transfer(amount);
}

Now resubmitting the same signature fails, because the nonce is already spent and produces a different structHash. On a different chain or contract, a different DOMAIN_SEPARATOR invalidates it too.

---

10. Private Key Theft / Bridge Hacks (Ronin, 2022)

The vulnerability

You can nail every defense so far, and it all collapses if the keys get stolen. From the contract’s point of view, a transaction with a valid signature is legitimate — it has no way to know the key was compromised. Bridges connecting multiple chains are prime targets precisely because they guard large sums with a small set of validator keys.

Exploit flow — Ronin (~$625M, among the largest ever)

Axie Infinity’s Ronin bridge used a multisig requiring 5 of 9 validators to approve a withdrawal. It looks robust on the surface — but the problem wasn’t on-chain. It was in off-chain key management and social engineering.

1. The attacker (attributed to North Korea’s Lazarus Group) targeted Sky Mavis employees with sophisticated spear-phishing using a fake job offer.
2. Through this, they stole 4 validator keys — one short of the threshold of 5.
3. But earlier, to distribute traffic load, Axie DAO had delegated one signing authority to Sky Mavis, and this delegation was never revoked afterward.
4. That lingering delegated signature became the 5th, meeting the threshold of 5, and the attacker withdrew the bridge funds.

The notable part: there was no bug in the smart contract. The 5-of-9 logic worked exactly as specified. What collapsed was the physical custody of keys and the lifecycle management of delegated authority.

Similar cases

• Wormhole (2022, ~$325M): guardian signature verification was bypassed via a deprecated function, minting 120K wETH illegitimately (an on-chain logic bug).
• Harmony Horizon (2022, ~$100M): with a 2-of-5 multisig, stealing just 2 keys was enough to drain funds.

Why bridges keep being the largest loss centers is clear: enormous funds concentrate in one place, and their defense depends on a handful of keys.

Defense patterns

• Sufficiently high thresholds: use a safer ratio than 5-of-9, and distribute each key across different organizations and physical locations.
• HSM (Hardware Security Module): isolate keys in hardware so they’re never exposed in plaintext in server memory.
• Delegation lifecycle management: always attach expiry to temporary delegations, and audit for revocation regularly. (Ronin’s decisive failure point.)
• Regular key rotation: rotate keys periodically to limit the useful lifespan of a stolen key.
• Trust-minimized architecture: fundamentally, prefer light-client / verification-based trust-minimized designs over bridges that rely on trusted validators.
• Anomaly detection + withdrawal limits/timelocks: impose delays and caps on abnormally large withdrawals to buy response time when an incident occurs.

---

Part 4 Summary

#	Problem	Point of failure	Notable case	Core defense
9	Signature replay	No context binding on signatures	(general pattern)	EIP-712 · nonce · deadline
10	Key theft / bridge hack	Off-chain key & delegation mgmt	Ronin, Wormhole	Thresholds · HSM · delegation expiry

---

Series Conclusion

The insights running through all ten cases:

1. Vulnerabilities span multiple layers. Code (1·2·3·4), economic design (5·6), consensus (7), authority boundaries (8·9), off-chain operations (10) — “code auditing” alone won’t stop even half of them.
2. The biggest losses came at the seams, not the code. The largest — Ronin, Wormhole, Harmony — arose from the system’s joints (bridges, key management, initialization, delegation) more than from pure contract bugs.
3. Defense must be layered. What the language solves (Solidity 0.8’s overflow protection), what libraries solve (ReentrancyGuard), what design solves (TWAP, EIP-712), and what operations solve (HSM, audits, monitoring) all have to stack together.

Blockchain security isn’t the problem of writing “one perfect smart contract.” It’s a systems-design problem of guarding trust boundaries across every layer — from code to economics to consensus to operations.

End of the “10 Faces of Blockchain Security” series. ChainLab — Chain Within Your Life.

Tags: BlockchainSecurity, EIP712, SignatureReplay, BridgeHacks, KeyManagement