Confidential computing is the idea of securing data while it’s in use, and I’ve been pretty dismissive of the concept for a while now.
Securing data in transit via TLS/SSL? Yes, that makes sense. Securing data at rest? OK, sure, for laptops, desktops, and servers in your company data center, that makes sense. Securing data with a cloud provider? That’s less sensible to me, under the theory that if someone manages to steal the right drive from an AWS facility and get it out of the building without dying, they kinda earned it. But in the interest of not prolonging discussions with auditors, I’ll enable securing data with a cloud provider so they can check the box and leave me alone.
I draw the line at securing computing data while it’s loaded in RAM and being operated upon by the CPU (yes, yes, and the chipsets and cache levels and whatnot; leave me alone, that’s not the point I’m making). It’s always struck me as being a little too tinfoil hat brigade for most companies to consider adopting. But given how much folks like AWS and Google and Azure talk about it, someone’s wrong about confidential computing here — and it’s possible that it could be me.
So in this screed, I’m going to lay out my reasoning against confidential computing, an initiative I view as a marketing ploy meant to calm cloud skeptics’ security paranoia. I invite you to prove me wrong. After all, there’s no better way to have your ideas checked for coherency than by blasting them out to a hundred thousand people on the internet! Let’s begin.
Threat modeling for confidential computing
Every security step you take should presumably be rooted in a threat model that you’re guarding against. This is true for most security precautions. I don’t want randos on my coffee shop’s Wi-Fi network (or, y’know, the NSA) to be able to see my data as it passes from my phone or laptop to the internet, so TLS makes sense there. I don’t want someone to steal my laptop and get access to all of my client data, so encrypting that disk at rest likewise makes sense.
But what I can’t figure out to save my life is the threat model for intercepting my data while it’s being used by a server.
A blog post by Azure CTO Mark Russinovich says the purpose of confidential computing is “preventing data access from cloud operators, malicious admins, and privileged software such as the hypervisor.” That premise is borne out by a variety of other sources, to the point that I’m comfortable using it as the definition I’ll argue against.
The ‘threat’ of malicious admins
Let’s start with the “malicious admins” angle, since it’s the most easily dispensed with. I’m hard-pressed to imagine a scenario where a malicious admin has access to the operating system at a root or superuser level, can see and modify the running code that’s in production, but won’t also be in a position to work around whatever confidential computing implementation the provider offers and the customer has implemented. On some level, you’ve gotta trust your administrators. At more advanced levels of customer sophistication, you also audit the heck out of everything done in sensitive environments, and compound that with a separation of duties among team members. At some point, that malicious admin would require a full-out conspiracy to make headway.
The ‘threat’ of privileged software
Not trusting hypervisor-level separation cuts to something a lot more germane to the confidential computing narrative that’s attempting to sway the reluctant-to-adopt-cloud market. If you don’t trust tenant-level separation (which you should absolutely not on Azure), then you need to either go for EC2 instances with dedicated tenancy or not be in the cloud at all. If that level of separation can’t be relied upon, then the entire premise of cloud security has failed us, and the industry’s implosion is simply awaiting a big enough breach.
The ‘threat’ of cloud operators
“Preventing data access from cloud operators” is the argument that exposes the entire confidential computing initiative as the farce it is. The big three providers all attest and have been audited by third parties to verify that, across all offerings, they enforce controls that detect and/or prevent cloud operators’ attempts to access customer data, outside of clearly defined exceptions. Cloud providers all give assurances that there are encryption options that render your data inaccessible to them. And ultimately, you have to trust your cloud provider — because if you don’t, the entire house of cards comes tumbling down.
Trusting your cloud provider
I have to trust that AWS does what it says it does about security. I have to trust that there isn’t some fringe case, “if” statement in its business logic that routes my requests to a “special” subsystem that behaves identically to everyone else’s, except without the security controls. I submit requests to AWS’s API, and I get a response that looks correct, but I have to trust that result came about because AWS is doing what it says it does and not returning a result that appears the same via some parallel insecure system that also gives AWS unconditional and undetectable access to my data.
If I trust that AWS is being honest about its controls and how its systems work (and I do), then all of this confidential computing fuss is pointless.
If I didn’t trust that AWS is being honest about basic cloud security, visibility, and access, then I absolutely should not trust AWS with my data or workloads. I don’t see much of a middle ground here.
Confidential computing is attempting to take another bite at convincing folks who don’t believe that cloud providers can be trusted that there are ways that you can still run sensitive workloads on top of untrustworthy providers. I don’t believe that’s possible.
Confidential computing is pretty ridiculous
If you’re keeping tally at home, that’s three out of the three “threats” that we ruled out. If none are a concern, then you certainly don’t need to spend the time, money, or effort implementing confidential computing as a solution.
Frankly, cloud providers may be undermining themselves with confidential computing initiatives. Either the big three are trustworthy or they’re not; asking for money to pinky-promise that they won’t access data while it’s being used implies that they might otherwise sneak a peek at customer data. Kowtowing to cloud doubters isn’t a strong play for cloud providers that are already on top of reasonable security measures.
I believe confidential computing is an area of cloud that can be safely ignored. You either trust your cloud provider, or you believe your cloud provider is lying to you. If you think AWS, Google Cloud, and Azure are lying to your face about all their other security measures, then why would you believe anything they say about confidential computing?
But I seem to be the odd man out on confidential computing. If I’m wrong, tweet me @QuinnyPig so we can have a proper debate.
