The MSA Key Leak: Why Your “Double Key” Wasn’t a Deadbolt#
We’ve all spent time dissecting the post-mortem of the Microsoft MSA signing key heist (Storm-0558). It’s one of those incidents that remains relevant for architectural teams because it didn’t just break a lock—it forged the master blueprint for the entire security desk.
In looking back at the past assessments of the impact, one claim keeps resurfacing: Even Double Key Encryption (DKE) was potentially compromised.
At first glance, that feels like a stretch. The whole value proposition of DKE is “Hold Your Own Key” (HYOK). We have the second key on-premises, tucked away in our network, accessible only via our own non-Microsoft VPN. If Microsoft loses their half of the puzzle, the maths says our data should still be a brick.
But after digging into the mechanics of the “Identity Pivot,” the reality is a bit more sobering. Here is why DKE wasn’t the “get out of jail free” card many assumed.
The Identity Crisis at the Security Desk#
Think of DKE as a high-security vault that requires two separate physical keys held by two different people.
To get your document open, you first have to visit the Security Desk (the Identity Provider). You show your ID, and the clerk hands you a “Permission Slip” (a signed JWT token). You then take that slip to the Key Master (our on-premises DKE service).
The Key Master doesn’t know you personally; his only job is to look at the Permission Slip, verify the Clerk’s signature, and—if it looks authentic—hand you the second key.
The encryption maths here is still perfect. The problem is that the “Master Key” stolen by Storm-0558 was the Clerk’s Signature Stamp.
The attackers didn’t need to pick the lock on our vault. They simply sat down, stamped their own Permission Slips for any user they wanted, and walked up to our Key Master. Our DKE service looked at the “valid” signature and, as designed, handed over the keys.
Why the Network Perimeter Didn’t Stop It#
I’ve heard the argument: “But the attacker isn’t on our network. They can’t even see the Key Master!”
While a non-Microsoft VPN and a hidden listener provide excellent network-level security, they don’t solve for a total collapse of the Chain of Trust:
- The Compromised Guest: If an attacker uses a forged token to access a user’s Exchange Online, they are already “authenticated” in the eyes of the M365 ecosystem. If they manage to compromise an endpoint that is already connected to the VPN—or leverage a persistent session on a hybrid-joined device—they are effectively standing at the Key Master’s window inside our house.
- App-Only Bypass: Many DKE implementations allow certain service principals or “app-only” permissions for background tasks. If an attacker can forge a token for an application that already has a designated route into the network, the VPN becomes a moot point.
The Architect’s Takeaway#
This incident highlights a critical distinction we have to maintain in our security models: Data Privacy is not the same as Identity Integrity.
DKE is a brilliant solution for Data Privacy. It ensures that Microsoft (or anyone who subpoenas them) can’t peek at your files. However, it was never designed to protect against a compromise of the Identity Provider (IdP) itself.
If the foundation of your trust (the signing key) is gone, the walls you build on top of it—no matter how many keys you use—are standing on sand.
The Lesson: We can’t view encryption in a vacuum. A “Double Key” is only as secure as the “Single Identity” used to authorise its release. Moving forward, the focus has to shift towards Contextual Authorisation—where the Key Master doesn’t just look at the signature on the slip, but also checks the context of the request before handing over the keys.