Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy, reliability, and compliance on the Microsoft Cloud Platform. Hey everybody, welcome to Episode 58. This week, it's a special episode. It's just myself, Michael, basically Sarah, Mark, and Gladys. They're all busy, so it's left down to me. But with that being said, it's also a, this week is a pet topic of mine. We're talking about some of the latest advancements in Azure confidential computing.
With me this week, I have two special guests. I have Run Kai and Vikas Bhatia, who are both here from the confidential computing team to talk to us about some of the latest innovations. Run and Vikas, welcome to the podcast. We'd like to take a moment and introduce yourself. Hi, Michael. This is Run. I'm coming from Azure Confidential Computing PM team. I'm leading Azure Confidential Computing in for a structured PM team. Nice to be here. Thanks, Michael, for giving us this opportunity.
Hi, everyone. My name is Vikas Bhatia, and I'm the head of product for Azure Confidential Computing here at Microsoft. Why don't we kick things off with probably the most obvious of questions? Could you explain what confidential computing is and why? Why confidential computing? Absolutely. That's a great question. I think that's where we should start. I think it boils down to customer's desire to own the data, have full control over their data during its entire lifecycle.
What that means is data gets created, data gets transferred, data gets stored, data gets computed upon. Given the elevated privacy and security environment that we're living in, customers are quite paranoid and becoming extremely sophisticated where they want to ensure that they have full control over their data during its entire lifecycle. Customers do already do a ton of this protection of the data.
Today, Microsoft spends over $20 billion over the next five years, which we've committed to on cybersecurity. That goes into making Azure the most trusted cloud platform. It ranges from strict physical data center security, data privacy, and even things like novel uses of machine learning for threat detection. Microsoft spends a ton of effort in protecting customer data.
Customers as well, they use the state-of-the-art techniques with a key that they own to encrypt their data at rest and encrypt their data in transit. What does that mean? When you encrypt your data at rest, what that means is you can come, you can take my laptop and run away with it. You're not going to get anything out of it because I'm using BitLocker. So my data is encrypted at rest.
Similarly, data stays encrypted at rest even when it's in the cloud, in one of the Azure servers, with a key that customers own. Similarly, data in transit. We don't really send HTTP traffic over the wire anymore. We do HTTPS, we do TLS. We do everything possible to make sure our data is protected while it is moving between two endpoints.
But data in use, so when data is actually sitting in memory, when it is actually being computed upon, that computation happens on data when it's entirely in the clear during the existence of our entire industry. Our technology industry hasn't had a technical solution to encrypt data when it is in use, when it is in memory, when it is actually being computed upon. And that's where Confidential Computing steps in.
So Confidential Computing is the ability for customers to protect their data when it is in memory, when it is in use, so that their data stays protected during its entire lifecycle. So while Confidential Computing is a valuable element to protect data and use, the key value of Confidential Computing is with Confidential Computing now, data doesn't ever have to be in the clear. So data is gonna stay encrypted as it is being generated, as it is being stored, as it is being transferred.
And now with Confidential Computing, it is gonna be protected in memory while it is in use. So that sounds all well and good. Encryption, protection of data while it's in use, but technically, how does this even work? It's a great question. So the way to kind of think about it, if you're gonna get technical, I'm gonna use this word, trusted execution environment or a TEE. Another word we use in our circles is an enclave.
But for this question that you asked me, I'm gonna go like really level 100 and say, think of a box. When you have a box with Confidential Computing, the only thing that you trust is what is sitting inside that box. All the computation that is happening inside that box, that enclave, that TEE, the trusted execution environment.
And the way it works is for an application, your application can, in certain use cases, create a trusted or an untrusted and an untrusted part of the application where the trusted part of the application is running inside the box. And only the code which has the keys to access the data sitting inside that box, only that code will ever get access to the data inside that box or that enclave.
So now the way this works in this scenario is a customer might choose to say partition their app as they do with Intel Software Guard Extensions, Intel SGX that we've had in Azure for a few years now, where what they do is they create a trusted part of their application and that trusted part of the application is what runs inside the enclave. That is the only thing that they trust. In our circles, we call it the TCB, the trusted computing base.
So the trusted computing base for the customer is now whatever's running inside that enclave protected by a key that the customer owns. So you know the next question is, don't you? So where is that key? And how is it protected and who has access to it? Well, that's a very good question. So the way we can think about Confresh Your Computing, we really think about it completely end to end.
While I mentioned that the computation happens inside the box, I didn't quite explain what happens to the keys and how do you trust what's inside that box, what sits in that enclave? So before I go into the keys, let me talk a little bit about attestation. Attestation is the fundamental concept of Confresh Your Computing. What attestation basically does is it proves to the customer that what you think you're running is what is running.
So customers get a cryptographic proof provided by the CPU that comes from Intel and AMD, where the computer's happening. So in this case, the attestation capability is something that allows customers the verification that before I release my important data to that enclave or that box, is it really what I expect it to be?
So the first element that I think we need to talk about is remote attestation, where customers can remotely attest the state of their environment before they release sensitive data to that environment or that enclave.
And Microsoft has a service called Microsoft Azure Attestation or the MAA service that we provide for free for customers that itself runs inside an Intel SGX enclave, the Secure Guard Extensions enclave, where we as Azure do not have access to anything running inside that attestation service. So you know that we are prevented from modifying your attestation report.
Now that you have an attestation report that tells you, okay, that enclave that I'm running against is running in this Intel or AMD environment and it has this version of operating system and so on, everything that you can do in your policies. Once that attestation report is with you, you can take it to a key manager and that key manager will then give you the keys that will only be securely released inside that enclave.
So this is a pretty important element here, Michael, which is we have fundamentally rethought the ways the keys should be managed. So we took our Azure Key Vault, AKB, which everyone loves and uses and it's phenomenal. It runs ton of customer workloads, but we took that and refactored it so that it can now run, it runs inside a enclave as well. So we as Microsoft are prevented from getting access to the keys that customers own.
So the way it would work to kind of tie the story together is customers would create an enclave, they would get an attestation report, hey, is this enclave really what I think it is? And once they get that attestation report, they go to the confidential key service, which is ManageHSM, and by the way, this ManageHSM service is an entire HSM that customers own.
So they get to the ManageHSM service and only then, based on the policy that the customer might put in place, is the key released and the key is securely released only inside the enclave.
So sorry, that was a super long explanation, but I think what it boils down to is that customers with confidential computing, with the attestation capability and a confidential key management service like ManageHSM have the assurance that their data is exactly running inside a compute environment that they can trust. And I think, and I'm running this maybe a question for you.
So we talk about essentially this trust boundary, and really what we're trying to do is keep that trust boundary as small as code as possible running inside of that trusted computing base.
And part of the attestation process, I presume, could be including like a digital signature to make sure that the code that is loaded into the enclave is correct, it's not been tampered with, because I mean, my guess is you, at the end of the day, you could load malware into an enclave, but the whole point of this attestation process is to make sure that that kind of thing doesn't happen. Is that all, are they all fair comments? Was I fairly accurate there? Yes, so Michael, that's true.
And also recently, Azure Confidential Computing introduced a new type of hardware-based trusted execution environment. Azure Confidential Virtual Machine actually is built upon third-generation AMD Epic processor, leveraging their security feature called SCVSMP, which stands for Secure Encrypted Virtualization, Secure Nested Paging. That is provide the VM memory encryption with integrity supporting.
So Azure Confidential VM has already been general available today, which offers a new type of VM series, which running on top of AMD, SCVSMP security features. And with that, that is new hardware-based enclave, which protect VM memory encryption and integrity protection. That is offer the guest protection to deny hypervisor and also other host management code access to VM memory and state, and protecting against operator access.
And most important thing, I think, we add different layers of protection for confidential VM. First of all, as we mentioned about the confidential VM using the SCVSMP, the security feature, to protect the VM memory encryption. One thing we need to notice that the VM memory encryption, the key, previously, Vickers talk about the key is very essential. The VM encryption key actually is generated inside of the AMD processors, and that, well, software cannot be read directly from that key.
That is fully protected from silicon perspective. And also, on top of that, we add different layers of protection, for instance, like OS for disk encryption. For today, Azure Confidential VM customer, they can opt in to choose OS for disk encryption. And the key to encrypt the OS disk can be either a platform manage key, which Azure manage key for you, or custom manage key.
And the custom manage key, actually, the customer can choose whether it is using the Azure Key Vault or Azure management Key Vault, which is running inside of SGX Enclave. And most important thing is these keys actually is cryptographically bounding with security key release policy, which means that is associated with attestation.
The key will not be released until the remote attestation kicked in, and all the code come back to the attestation result shows all the key release policy has been met. Then all the OS disk can be, the key can be released, and the OS disk can be decrypted, and the VM can be accessed. And remember, all the OS for disk encryption, the encryption happens actually before the VM first boot. So that is very, we are very proud of these features to be built on the confidential VM.
And lastly, also very important, as B.K.C.E. mentioned, is remote attestation capability. For Azure confidential VM, customer actually can, inside of the confidential VM, they can initiate the attestation request to choose to attest whether their VM is actually running on the AMD powered nodes, which has SEV SMP security feature turned off. There are three nuances in what you just said there that I really want to make sure people understand. And if I'm wrong here, let me know.
I just want to go through all three of these. The first one is you said the word operator. Operators don't have access to this stuff. That includes Azure operators, right? That includes the people who are on the management plane, the back end of Azure. They don't have access to this stuff either. Exactly. That is for the VM memory encryption that we talk about, all the keys actually is generated and reside inside of Silicon, and nobody else can read it directly. Exactly.
And that's my second point. The ultimate root of trust here is not Azure. It is not Microsoft in this example, it's AMD. Totally. And also, Azure Confidash Computing is aligned with definition of Confidash Computing consumption, that we are building the hardware-based Confidash Computing, which means customers do not need to trust Azure. They all need to trust its Silicon providers, like AMD, like Intel. Right. And then the last one is the attestation service is not the VM. It is not SGX.
It is something that is completely separate, that has no interest whatsoever in what that code is. But its job is purely to validate that it is correct. That is all it is. So this is not a self-policing environment. This is actually something that's outside of the environment, outside of this VM, outside of the SGX enclave that is validating that, yes, that VM is actually the correct image. And yes, that code that runs in this SGX enclave is the correct code.
And I think that's incredibly important, because without the attestation process, this whole thing kind of falls over. I mean, perhaps that's a strong word, but it's nowhere near as secure if we didn't have the attestation process. Yes. And one of the key differentiation of the confidential VM that built on in Azure is we built the capability of the remote attestation. Actually, we have two different attestation type.
One is platform attestation, which means even on Azure, we built the background attestation mechanism to make sure when we launch this confidential VM, it is really, truly running onto a CVSMP processors offered by AMD. But that basically, that process is opaque to the customers. Another attestation feature we announced is also the guest attestation, which means confidential VM customers inside of the VM.
They can challenge whether my VM is really truly running into the AMD powered CVSMP on silicon. So this is actually really cool. I mean, this opens up this whole notion of having a virtual machine as a trusted execution environment is really awesome for a number of reasons, I think. Number one, I mean, SGX is cool. Don't get me wrong. Although my extensive SGX has been writing basically a version of Hello World. But anyway, we've got to write custom code, right?
You can't just sort of lift and shift. If you're going to do SGX eyes something, you've got to modify the code and run a portion of your code inside of the SGX. And a really good example, I guess, is say, for example, a SQL server using always encrypted with secure enclaves, right? So part of the query processor actually runs in the enclave, which is super nice. But here what you've got, you've got an entire VM.
So obviously, the trust boundary is a little bit larger, because it's bigger than just a small enclave. However, there is a trust boundary around this VM. So now I can start loading workloads into that and have all the isolation that I would normally have using combination computing technologies like encryption and integrity checks and so on. But it supports these lift and shift scenarios now, which is really cool. I don't need to modify any of my code.
I was working just recently with a health care company, and they had a third party application that ran inside of a VM. And it's health. I mean, this is health care. I mean, they're dealing with sensitive health care information. And this would have been a perfect scenario, admittedly, this was a year ago. But this would have been a perfect example where they could run the specific workload, which came from a third party.
They could run it in the VM and have all the benefits of combination computing with no re-engineering. Exactly. And also what we are seeing for the Azure Confidential VM, which the top two scenarios that we can think about it for the use case is, number one, for the on-prem customers that they probably do not want to modify their code. They can migrate to the Azure Cloud.
And also, if for the super paranoid customers are very sensitive on the customer data, they even will give them the tooling that potentially they can just do every encryption of their data or OS disk at the on-prem environment. And then they launch the Confidential VM with encrypted OS disk. With that, there you can think about that. It's even more secure because every encryption environment happens on-prem. So that gives on-prem customer can migrate to the Azure Cloud.
Another scenario is for the existing Azure Cloud customers, they can just simply go to the Azure portal and double click a few buttons through the portal and they can launch Confidential VM. And all the workload previous running into the Cloud environment, they can just lift a shift to the Confidential VM. So I know that under Confidential Computing, we also have this thing called trusted launch. Does that fit into this in some way?
Trust launch actually provide the secure boot and also virtual TPM capabilities to customers. All the trusted launch features actually has been inherited from Confidential VM. Every individual Confidential VM from Azure will has its unique virtual TPM, which virtual trusted platform module. And this VTPM actually resides in higher privileged memory protected by the CPU from AMD, third generation, Epic processors. And customer can seal their keys or secret into the virtual TPM.
And also secure boot as well, customer can turn on the secure boot and make sure that all the drivers, kernels, and also book-through-kits is measured and also is meeting their requirement as well during the VM boot.
So the VTPM is essentially the virtualized TPM, or trusted platform module, is essentially very similar to what we have in say Windows 11 on a laptop or we have a TPM, trusted platform modules, to provide all sorts of security services for making sure that the boot is correct and making sure there's no bootkits and rootkits. So it's the same thing, but just in a virtualized environment. Exactly. OK. So Vikas, I have to ask a question.
I mean, what sort of broad offerings do we have here in the Confidential Computing umbrella? Yeah, so I think, Michael, like we know we Azure has been at the forefront of bringing Confidential Computing to the industry. We were one of the founding members of the Confidential Computing Consortium back in September 2019. And we took the bleeding edge of hardware available, whatever was available, and we took it to the cloud. And we got this ecosystem sort of going.
So I think in some ways right now, Azure has the broadest set of offerings and the deepest set of offerings for customers, no matter where they're coming from. So I talked a little bit about apps when I was talking about Intel SGX. And Run talked about confidential VMs where customers can move their applications without modification directly into a confidential VM.
But we also have solutions for confidential containers where customers can make their container confidential without changing a single line of code in certain cases. And so the way we got to think about it is we think about it completely end to end.
We think about it where we are first enabling a confidential platform, where we are enabling the basic IaaS layer with VMs, containers, and applications where customers can take their applications, sometimes existing, sometimes new ones, and bring them into a confidential environment to get that assurance, additional assurance that they need. But we don't stop there. So we touched a little bit about the confidential cloud where we are making the Azure cloud itself confidential over time.
While today we have infrastructure capabilities around Microsoft Azure Attestation Service, the Managed HSM Service, we also have actually going into general availability right now is the Azure Confidential Ledger where customers can use a confidential service for Tampa Proof Audit Logging, which we are seeing great pickup in compliance and audit related scenarios.
Additional services that we have in Azure are around Azure SQL always encrypted that runs in Azure, always encrypted with secure enclaves that runs inside an enclave environment itself. And overall, I think we are making capabilities that customers really want completely end to end. And it just doesn't stop there. We also have a rich and growing ecosystem of partners who are bringing capabilities that customers can leverage to make their journey into confidentiality.
In fact, we just released a huge set of webinars with our partners that customers can start listening to them on our conference computing website that I think we'll share later. But overall, the way to think about it, Michael, is customers have to decide what their security posture needs are, what their scale needs are, whether they have existing workloads. They want to bring it to confidentiality or start with new workloads. I think overall, in Azure, we've given that capability.
And this technology space is rapidly evolving. We are talking now in six months, if we talk again, this space is going to be even more different. I think it's constantly evolving. And we are pretty excited with what's coming online as well.
Yeah, I think over the next few months, we'll certainly see, as we start talking more about, not just confidential computing, but certainly the new VMs that have been made available, people moving some of their more sensitive workloads quickly to these confidential computing VMs. I think that's going to be absolutely magnificent to see that happening. And perhaps some environments may start to write their own custom code and use Intel SGX secure enclaves. I don't know.
But the key thing there is this whole notion of having a very tight, trusted execution environment, where you control the keys, the data is encrypted in memory, all the memory is encrypted, period. The keys aren't released until all the lights are green, that kind of thing. I think that's absolutely magnificent. So do we have any examples of how some customers are using, for example, the new VM types today?
Absolutely. And I think customers can go to aka.ms.azurecc, which is our confidential computing website on Azure to see what's going on. We also have another short link, aka.ms.accstories, where we are constantly publishing more customer stories about how customers are leveraging this technology. And this technology is maturing pretty fast. As Run mentioned, customers can essentially redeploy into a virtual machine. And suddenly, they're confidential without changing any source code.
And that, as you can see, is super powerful. I think by going to this website and checking out sort of where things our customers can learn a lot more and also get in touch with us, we're happy to help them as well. Well, let's start bringing this thing to a close. So one question we always ask our guests is if you had one single thought to leave our listeners with, what would it be? So let me take that.
So I think from one final thought, I think while this podcast may seem pretty technical and we went into a bunch of technical details, we have abstracted or we have attempted to abstract all the technical concepts away from you, unless we really want you to know them, like attestation. But I'd encourage the listeners to go to the Azure portal, go find the confidential VM sizes, which are EASV5 and DASV5.
Go to the Azure portal, select a gen2 image, select the operating system image that you want, and boom, review and create and go. You're good to go. You suddenly have a confidential VM that you can deploy into. It's as simple as that. So I'd encourage the listeners to go kick the tires, tell us what you think. This new technology is rapidly happening, and the more you get educated, the more beneficial it will be for you.
I know I just said a final thought, but I have to leave you with something as well. I remember talking to a customer, again, in health care. We're doing some SQL server stuff with always encrypted with secure enclaves. I'll show them how to set it up. I might have you on how it all hangs together. And then I went over to the Azure Attestation Service, and he said, what's that? And I said, that's the Azure Attestation Service. He says, what's that? So I explained what it did.
And he's like, you know what? I didn't even know that existed. But until you told me that it existed, the penny has just dropped as to how important that attestation service is. He said, he realized that the whole thing really hinges on making sure that we're dealing with the correct stuff. And that has to be done by something outside of the actual process itself. And that's the role of the attestation process. So it's interesting. It's a really good example.
I'm a big fan of explaining things to people about the stuff you know you know, the stuff you know you don't know, and then the stuff you don't know you don't know. And attestation was a really good example of the last point. All right, folks. Well, look, Rune and Vikas, thank you so much for joining us this week. You know, I just love this stuff. I think it's a fantastic technology. I know a lot of customers that I've worked with in the past are interested in it.
They were looking primarily at the SGX stuff because frankly, that's all that was available. But now that we have these confidential computing VMs from AMD, I think that is going to open up so many more workloads. So with that, let's bring this whole thing to a close. This has been an awesome conversation. Thank you so much for joining us this week. And to our listeners, thank you also for listening. I hope you learned a lot. I can almost guarantee you did.
So stay safe, and we'll see you next time. Thank you, Michael. Thank you, Michael. This was great. Thanks for listening to the Azure Security Podcast. You can find show notes and other resources at our website azsecuritypodcast.net. If you have any questions, please find us on Twitter at azuresecpod. Background music is from ccmixter.com and licensed under the Creative Commons license.