Trust Anchors

I keep noticing the same thing whenever a signing system actually breaks. Nobody asks what broke technically first - the question that comes up, almost every time, is who actually did this. That's worth sitting with for a second, because JWT, mTLS, HSM-backed signing, blockchain transactions, all of them lean on the exact same assumption underneath: a valid signature means the matching private key produced it. What differs, completely, is how each system defends that assumption - and that's exactly where most misunderstandings start.

The assumption itself

Verification is the easy part. You run something like:

Verify(signature, message, public_key) == true

and it either comes back true or it doesn't. RSA, ECDSA, Ed25519 - these have been picked apart by cryptographers for decades now and hold up fine when implemented correctly. Nobody actually breaks a signing system by breaking the math anymore.

What that equation doesn't tell you is who the public key actually belongs to, or whether the matching private key is still sitting only where it's supposed to. Cryptography proves a key pair produced a signature, that's all it proves - it says nothing about identity. Everything past that point depends on something bolted on afterward, something I'll just call a "trust anchor" for the rest of this. And this is exactly where JWT, TLS, HSMs, and blockchain part ways - not in the math, in what gets bolted on.

The math never fails on its own. Every real incident later in this piece happens in that second layer.

JWT: trust whoever runs the endpoint

A JWT verifier usually doesn't hardcode anything. It pulls public keys from a JWKS endpoint the issuer exposes over HTTPS, so the trust anchor here is really just whoever controls that URL - nothing more romantic than that.

Which is convenient - rotate a key and every service that fetches the updated JWKS starts validating against it automatically, no manual redistribution needed. Fine for a system with a hundred internal services talking to each other, and probably the reason most people don't think about it twice.

The catch shows up at revocation, and it's the part people forget until they need it. A token that's already been issued stays valid until it expires, full stop. Rotating the signing key stops future tokens from validating against the old key - it does nothing to the ones already circulating. You could argue short expiry windows paper over this, and they do, mostly, but that's a mitigation, not a fix - the format itself still has no undo button. If you need to kill a token immediately, you're reaching for a blocklist or an introspection call, because JWT was never designed to say no to something it already said yes to.

TLS: trust gets delegated up a chain

TLS solves the same problem by handing the decision to someone else entirely. Your OS ships with a set of root CAs already trusted, a server's certificate chains back to one of them, and the client checks the whole chain instead of deciding on the spot whether to trust this particular server.

That's what makes TLS work at internet scale - nobody manually vets every website they visit. And unlike JWT, there's an actual revocation story here: CRLs and OCSP exist precisely so a CA can say this cert is dead before its expiry date. In practice it's patchy - plenty of clients skip OCSP checks for speed, CRLs go stale - but the mechanism at least exists, which is more than JWT can say.

The real fragility sits upstream of any single certificate, though: the whole model assumes CAs behave. When one doesn't, the damage isn't contained to one site. DigiNotar found this out in 2011 - an intruder got into its CA servers in June, started issuing rogue certificates in July, and by the time browsers pulled the trust anchor entirely, the fraudulent certificate list ran past five hundred entries, including one for *.google.com used to intercept roughly 300,000 Iranian Gmail accounts.^[1] DigiNotar was bankrupt within weeks. Not because the crypto broke - because the organization behind the trust anchor did.

HSMs: trust a physical boundary instead of a person

Hardware Security Modules take a different angle entirely: stop worrying about distributing public keys, just make sure the private key physically never leaves the device unencrypted. An application can't read it off disk or memory - it sends a signing request in, the HSM signs internally, only the signature comes back out.

Key rotation is well-supported here too - generate new keys inside the boundary, retire old ones, all through a standard interface like PKCS#11.

Here's the part that actually surprised me the first time I worked with one: almost nobody breaks the HSM itself. Every compromise I've read about traces back to the process wrapped around it instead - someone gets signing permissions they shouldn't have, an approval workflow gets bypassed, an admin credential leaks somewhere boring. The hardware will faithfully sign whatever request reaches it correctly authenticated, because distinguishing "authorized" from "should have been authorized" was never its job - and it's not really fair to expect it to be.

Blockchain: no institution to ask

Blockchain drops the institutional layer almost entirely. Anyone can pull the ledger and check the same cryptographic evidence everyone else is checking - no CA vouching for wallet ownership, no HSM required for consensus to work.

That transparency is the whole appeal. It's also where things get unforgiving: there's no CRL equivalent, no issuer who can invalidate a stolen key's signatures. A correctly signed transaction is valid according to protocol, full stop, whoever's holding the key that produced it.

The Ronin bridge hack in March 2022 is a useful case here, and it's more interesting than "key got stolen, funds gone." Withdrawals needed sign-off from five of nine validator nodes. Attackers, later attributed by the FBI to North Korean state actors, had compromised four validators run by Sky Mavis directly and a fifth belonging to a third-party DAO that, months earlier, had been added to an allowlist for a since-abandoned arrangement and never removed.^[2] With five signatures in hand they forged two withdrawal transactions and moved out roughly $625 million. Nobody noticed for six days - not because the chain hid anything, every transaction was sitting in plain sight on Etherscan the whole time - but because there was no mechanism watching for "this set of signatures, while individually valid, shouldn't have been possible together." The math was never the weak point. The process for deciding who was allowed to hold five keys was.

Same primitives, different bets

Two of those four have names and dates attached because they actually happened and got investigated. The other two don't, not because they're less real, just because "an admin credential leaked somewhere boring" doesn't make headlines the way *.google.com does.

None of these designs is wrong, exactly. JWT optimizes for operational ease. TLS optimizes for delegating identity checks at scale. HSMs optimize for keeping the key itself physically out of reach. Blockchain optimizes for not needing anyone's permission to verify. Each one is trading revocability for something else - speed, decentralization, simplicity - and none of them get to keep all three. That's not a flaw in any single design, it's just what the trade-off looks like once you actually draw it out.

Which loops back to where this started. Every one of these systems fails in the same shape - not at the signature check, but around it, in whoever runs the endpoint, whoever staffs the CA, whoever approves the signing request, whoever gets added to an allowlist and forgotten about. So when something breaks and the question in the room is who actually did this, that's not a distraction from the technical failure - most of the time, it already is the technical failure, just wearing an organizational chart instead of a stack trace. If you're designing a new signing system, the algorithm choice is usually the easy twenty percent. How much revocability you're willing to give up for how much decentralization - that's the part worth spending real time on.

Sources

[1] Fox-IT, Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach, 2012; Council on Foreign Relations, "Compromise of certificate issuer DigiNotar."

[2] Halborn, "Explained: The Ronin Hack (March 2022)"; The Record, "More than $625 million stolen in DeFi hack of Ronin Network," March 2022.