Ruben, welcome to the AWS Studio.
Thanks for joining us.
Thank you.
Thanks for having me.
Why don't you start with telling us a little bit more
about your background and role at AWS?
Of course.
I'm a Principal Solutions Architect.
I'm working to advise, support,
and help our customers transforming with the cloud.
I work with several telecom
and telecom customers, operators, ISVs.
That's what I do.
Wonderful.
I think let's just jump right into it.
Tell us a little bit more
about what confidential computing is and how does it work?
So let's say you are a telecom operator,
a communication service provider,
or an independent software vendor
that's acting as a supplier.
You are processing data from your workloads,
the services, and also the end users
to whom you are delivering the service.
This data can be sensitive in nature.
You might have text messages, call detail record, CDRs,
or customer identifiers.
And you want to be able to protect this data,
in transit, at rest, and also in use.
So the production of data in transit and at rest,
these are well documented.
Confidential computing is about protecting data
while in use.
And specifically at AWS,
we define confidential computing
as the use of specialized hardware
with the associated firmware and software
for the protection of data in use
while being processed from unauthorized access.
And so how do we enable this within the AWS ecosystem?
Right.
We have three key capabilities.
One, we have the AWS Nitro System.
Second, we have AWS Nitro Enclaves.
And we recently released the third capabilities,
the Nitro Trusted Platform Module, TPM.
So,
I mean, before we explain,
let me just take a step back,
because before we explain those three capabilities,
let's talk about two important dimensions
to better understand how we use them.
When you talk about unauthorized access,
you have to consider two dimensions.
Dimension one is protection from the cloud operator.
In the case of you working with AWS,
it's protection from AWS, from us.
You want to protect your data from us.
Dimension two is protection from yourself as a customer.
Let me give you examples.
This can be an admin of your workloads.
This can also be a supplier
or a third party that has been contracted
to do managed operations on your behalf.
And this dimension two also covers the cases
where you have a malicious admin,
a malicious third party that's posing as an admin, right?
So now let's get back to those three capabilities
because this is where you need those two dimensions.
The AWS Nitro System is the foundation
of all modern virtualization on AWS today,
and it's addressing dimension one.
With the AWS Nitro System,
there is no operator access to your data or your codes.
Now let's talk about dimension two.
This is where AWS Nitro Enclave comes in.
Nitro Enclaves are hardened, secured,
and isolated computing environments.
And they provide additional isolation capabilities
than what the Nitro System can provide.
This is addressing dimension two.
And finally, I mentioned we have the Nitro TPM.
This allows you to attest on the health
and integrity of your instances,
and this is a TPM 2.0 standard compliant device.
So confidential computing alone, it's vertical agnostic,
but let's talk about telco specific workloads.
What are you seeing and where do you think
some of those early use cases ought to be?
Yeah, absolutely.
All right, so as a telco,
you are processing sensitive data.
And you're processing since, I mean,
we've talked about text messages,
call detail records, billing records, and so on.
Now, let's think about dimension two, right?
Protection from third parties or supplier.
So this is a very prevalent scenario for telcos
because, first of all, it's a regulated industry,
and they are working in the context
of telecommunication acts that can require telecom data
to stay within specific geographic boundaries,
and that do require telecom customers to take specific care
and measures for the protection of the sensitive data.
They're also working in an environment
where they have suppliers
or they contract third parties for operation.
So you might be a global telco operator,
you have operation teams that are working abroad.
They might need to access,
in a specific geography, your workload,
and you want to make sure that the data
is appropriately protected.
You might also have a managed service provider
that's doing operation on your behalf.
And again, you need to ensure compliance
with the regulation.
And so that's where Nitro Enclave
offers an ideal combination
because you can safely protect sensitive data
while doing maintenance operation
while having somebody from the supplier side coming in
and maybe working on a workload for debugging purpose,
optimization purpose, and so on.
One prevalent use case or one way to look at it
or to think about it today is to look at Nitro Enclave
as a cloud native, software-based,
custom hardware security module.
For example, for the protection of cryptographic material
in the case of authentication on a 5G network
or the concealment of customer identifiers.
Mobile networks today, their security is built
on a lot of specific cryptographic operations.
And the combination of the flexibility
and the performance of Nitro Enclave is really ideal
for these type of use cases.
Beyond this, you can think about using Nitro Enclave
for protection of all things security.
Certificates, for example,
in the controlled plane of a 5G network.
Cryptographic material.
Think of it to protect further use of lawful intercepts.
The processing of customer specific data.
Think about the text message
that you may want to post process for filtering purpose
in case of phishing protection.
And everything that falls under telecommunication acts,
this is going to be appropriate.
One thing you mentioned specifically with cloud native,
and as the underlying 5G networks themselves
become increasingly cloud native and containerized,
how does the Nitro System
play into a containerized environment?
Right.
So, the Nitro System,
let's talk a bit more about what are Nitro Enclaves, right?
And how they work.
So we said Nitro Enclaves are hardened, secure,
and isolated computing environments.
They're essentially highly constrained virtual machines.
Their lifecycle, their existence is tied to an EC2 instance.
And we often talk about the parent instance.
Now, Nitro Enclaves, they have no networking,
they have no administrative access,
they have no permanent storage.
And the only way to access the enclave
is via its parent instance.
They're also coming with their own cryptographic keys.
And from a software deployment point of view,
we're basically using the docker format
to package applications for the enclave.
Now, they are not containers, right?
But we're using this format for its convenience
and its developer friendliness.
From a capabilities point of view,
Nitro Enclaves have really two key capabilities.
One of them is an attestation mechanism.
This can be used for the enclave to prove its identity,
for example, to another service.
And also to authorize what codes
can run on the enclave.
They also have a first class integration
with the AWS Key Management System, AWS KMS.
And this combination is extremely powerful.
Why is that?
Because you can ensure, for example,
that only an enclave has the ability
to decrypt a specific piece of data
that you might have encrypted.
So from a value perspective, Nitro Enclaves,
they can attest their identity, they can authorize codes,
they're extremely flexible.
We haven't really talked about this,
but you can use them with Graviton, with Intel,
with AMD CPUs,
and you have a lot of flexibility into sizing them
in terms of how much memory
and computing resources you want to have.
And they come at no additional cost, right?
So now to come back to really the cloud native,
essentially, they are interfaced
into the rest of the AWS computing ecosystem.
And that's a very powerful proposition.
Now, if you really like containers,
if you really like containers,
we recently released in November a plugin
that allows to expose an enclave to Kubernetes pods.
So that works either for EKS
or for any other managed Kubernetes.
I think you covered the building blocks really well here
of how Nitro System can apply more broadly
to containerized applications
and to existing AWS services and workflows at large,
but let's maybe transition to applications.
Somebody's going to ask, "Well, wait a minute,
does this work for mission critical applications?
Is that the right fit?"
Yeah, it does.
Absolutely.
Again, let's get back to what I said earlier
about integration into the broader EC2 ecosystem.
This is why it works.
You can load balance and you can scale Nitro Enclaves
via their parent instance.
You can automate their deployment and their life cycle
via continuous integration and continuous deployment
using the same tools and the same ecosystem
that you would use with EC2 or with EKS.
And from a performance perspective,
as I said, they're also super flexible.
You have the ability to decide how much memory
you want to assign to them,
how much computing power you want to assign to them.
So functionally, these enclaves,
they're inheriting the best practices and value proposition
of not only the parent instance, but the cloud itself.
[Ruben] Absolutely.
Completely.
[Robert] So let's dive even deeper.
Let's talk about an end-to-end use case,
a telco specific end-to-end use case.
Walk me through what the problem,
the customer problem would be,
how Nitro Enclave solves that problem,
and the potential impact it could have.
So let us talk about the scenario
in the case of a 5G network.
And specifically, let's talk about the scenario
where you want to protect the cryptographic material
that's being used for mutual authentication.
So we are going to dive a bit deep,
maybe use a few acronyms.
So we will unpack that.
So what is mutual authentication?
In a mobile network,
the network wants to authenticate the user, the subscriber.
Typically, that's going to be you and your mobile phone.
It wants to make sure that you are authorized
to use the network
and that you are the right person, so to say.
You have the right credentials.
The other way around is as well true.
As a user, you want to authenticate the network.
You want to make sure that you're accessing the network
you are expecting to access.
That's what's called mutual authentication.
Mutual authentication is based on the exchange
of a set of cryptographic values
called authentication vectors, AVs.
And the generation of these authentication vectors,
those AVs, is based on cryptographic operation
that is applied on a shared secret key
that is available to both the network and the user.
So when you start your smartphone,
the smartphone is going to take the shared secret key
within your SIM card, traditionally,
and it's going to calculate the authentication vector.
The network, in the network,
you have a database of shared secret keys.
A highly secured database,
onto which you are going to run cryptographic operations
to generate as well an authentication vector.
And if both values match, that's it.
The user and the network have authenticated to each other.
Now, where do you need Nitro enclave here?
Now, come back to the dimension two protection
from suppliers and third parties.
These database of shared secret, it's highly sensitive.
All right?
This is cryptographic shared secret material
that you want to protect.
So in our use case, we've built a proof of concept
where we are hosting the shared secret database
along with the cryptographic operations
within the Nitro Enclaves.
And this ensures that in case of maintenance operations,
optimization operations where a supplier
or a managed service needs to access the workload
that this database of shared secret
is always appropriately protected.
And we've also been able to validate high availability
via the load balancing of Nitro Enclaves.
Really appreciate the depth there.
I think it really appropriately characterized
the security that this type of new model
and architecture can enforce.
But maybe as an exercise, let's think big,
let's zoom out for a second.
As we look at the future of Nitro Enclaves on AWS
and confidential computing more broadly,
what does the next level of confidential compute
for telcos on AWS look like to you?
It's about giving our customers
the trust that they can operate in a safe
and reliable manner, their most sensitive workloads on AWS.
This is really what we're working on.
So I'm ready to start building.
Where should builders go
to learn more about confidential computing?
And then secondarily,
for the enterprise and the business decision makers,
what types of materials can they consume to learn more?
All right, so of course we have documentation
on AWS Nitro Enclaves.
There is a workshop that's available online
for anybody to just start and get to use Nitro Enclaves.
And it'll give you all the necessary know how
and starting points so that you can start experimenting
and developing with Nitro Enclaves for your applications.
If you're interested in the Kubernetes ecosystem,
just go to GitHub and you will find the code,
as well as tutorial as to how to build your very first
EKS cluster with the Nitro Enclave, Hello World.
So my recommendation is really try it out,
build, experiment, and if you want to discuss more,
reach out to us.
What I also really want to emphasize is,
if you're interested more into the overall security
of the AWS Nitro System,
there was a white paper released in November.
It's called "The Security of the AWS Nitro System."
I can really recommend it to anybody
who wants to get a deeper look into the innards of it.
It's fascinating.
I appreciate the reading list.
Wonderful insights, great discussion,
and thanks for joining AWS Studio.
Thank you very much.