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.
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.