rmhrisk

rmhrisk

@rmhrisk.bsky.social

Dropout. Father. I build things. Security, Cryptography, Engineering, Entrepreneurship. @peculiarventure + x-MSFT + x-GOOG ++. Also on @rmhrisk@infosec.exchange and twitter.com/rmhrisk

421 followers148 following179 posts

View full thread

There is also a recent piece, The Amnesia Cycle and Why AI Is Turning Developers Back Into Testers, about how AI is shifting software development from producing code toward judging generated output, and bringing some old testing disciplines back into focus.

There are now 370+ posts on the site across security, PKI, identity, cryptography, AI, compliance, and the occasional topic well outside those boundaries.

One recent example is The Verifier Never Showed Up, a long-form look at thirty years of digital identity programs, how they actually failed, and why adoption is usually decided by the part of the system nobody funds.

Thirty years of digital identity post-mortems and the cryptography was almost never the problem. I went back through the record. Germany put the eID function on 97% of cards and got 22% usage. The UK spent £233 million on Verify and shut it down.

View full thread

Thirty years of digital identity post-mortems and the cryptography was almost never the problem. I went back through the record. Germany put the eID function on 97% of cards and got 22% usage. The UK spent £233 million on Verify and shut it down.

View full thread

Something the credential unlocked that people actually wanted. And a use frequent enough to become a habit, because a credential somebody was issued and a credential somebody carries are different things.

Estonia got all three. It didn't build an identity system and go looking for uses. It built tax filing, prescriptions, and business registration, and made identity the way you reached them.

Thirty years of digital identity post-mortems and the cryptography was almost never the problem. I went back through the record. Germany put the eID function on 97% of cards and got 22% usage. The UK spent £233 million on Verify and shut it down.

Not one program in the set failed because the math was weak. What the failures were missing wasn't technical. It was three things, all outside the issuer's control. A verifier that already had a reason to verify.

For as long as my kids can remember, I told them they are students at Hurst University. No campus. No accreditation. Enrollment is automatic when you join the family. Graduation is harder. There is one requirement. By the time you leave the house, you should be able to build a future for yourself.

Take two systems with the exact same vulnerabilities. One loses its identity keys, the other doesn't. Yet every scanner, compliance checklist, and CVSS score will rate them exactly the same. We learned to scale security answers, but we never learned to scale the reasoning that produced them. 👇

Some of my more popular posts have focused on confidential computing, explaining TPMs, TEEs, secure enclaves, AI, and everything in between. With all the recent discussion about AI agents escaping "sandboxes," I realized there is a similar vocabulary problem here.

We use sandbox as though it describes a security property. But a container, a VM, a confidential VM, and a enclave are very different things. They expose different surfaces, were designed for different adversaries, and make very different promises when something inside is actively trying to get out.

So I decided to do another long-form technical field guide, this time on isolation and containment. I specifically talk what the different kinds of sandboxes actually protect, how they fail, and what it really takes to contain an "optimizer" like an AI agent. rmhrisk.github.io/containing-t...

rmhrisk.github.ioContaining the OptimizerOne word, “sandbox,” has erased the distinctions between container, VM, confidential VM, and enclave — which is exactly how AI gets sold as secure and private. A field guide to what each primitive pro...

For fifty years, systems became faster, larger, more interconnected, and harder for any one person to understand. Our response was to add audits, frameworks, controls, evidence, reports, certifications, regulators, and penalties.

View full thread

For fifty years, systems became faster, larger, more interconnected, and harder for any one person to understand. Our response was to add audits, frameworks, controls, evidence, reports, certifications, regulators, and penalties.

We expanded the obligations, but the underlying assurance model remained largely the same. I’ve spent much of the last year thinking about why that is, where the model is beginning to fail, and what a different one might look like. I finally pulled that thinking together into two long-form pieces.

Yesterday I wrote about the classical WebPKI, the certificate chains, CAs, and governance we’ve used for three decades. Today’s piece is about what ultimately replaces it.

View full thread

The response is Merkle Tree Certificates. A CA logs certificates into its own Merkle tree and signs the tree head. Each certificate carries a short inclusion proof. One signature covers the batch; the proof is the path.

Yesterday I wrote about the classical WebPKI, the certificate chains, CAs, and governance we’ve used for three decades. Today’s piece is about what ultimately replaces it.

Post-quantum signatures are too large for the classical model at web scale. A few hundred bytes of authentication material becomes many kilobytes, colliding with TCP congestion windows and other protocol limits. On many real connections the extra round trip costs more than the crypto itself.

The WebPKI has two core structures that are not the same shape. One is essentially a cryptographic graph of signed delegations. The other is a governance framework of accountability. Almost every major failure in its history sits in the gap between them.

I found myself explaining the WebPKI a lot recently, so I decided to put together a long-form deep dive on what I have been calling the “classical WebPKI”, more on that in the post where I also explore things like...

FIPS 140-3 validations give you a narrow, well-defined assurance boundary. But the real security story often lives in the code and dependencies just outside that boundary - bootloaders, firmware parsers, and the plumbing that actually feeds the crypto.👇

View full thread

The public record shows recurring patterns and gaps. Procurement and architecture teams should be pressing vendors hard on evidence, not just paper. 👇

FIPS 140-3 validations give you a narrow, well-defined assurance boundary. But the real security story often lives in the code and dependencies just outside that boundary - bootloaders, firmware parsers, and the plumbing that actually feeds the crypto.👇

AI is accelerating discovery of these issues at scale, and the last decade of supply chain incidents has made one thing clear, third-party firmware risk is among the largest unaddressed threats in high-trust systems. 👇

We built the WebPKI around buildings, cages, ceremonies, HSMs, and audits. Most of the compromises we worry about now don't live in any of those places. 👇

One of the developers at Peculiar Ventures needed to debug some smart card APDU traces recently. I have enough trauma from the 90s and 2000s that I felt compelled to build an AI-annotated APDU trace analyzer.

The WebPKI is something we all rely on every day, and most people do not even know it exists. What is interesting is that even those who do often do not understand it as well as they think they do. To help more people understand how it works, I put together the WebPKI Observatory.

webpki.systematicreasoning.comWebPKI Observatory — Certificate Authority Trust Ecosystem AnalysisQuantitative analysis of 96 trusted CAs: market share, concentration risk, compliance incidents, distrust history, and root program governance. Updated daily.