- Let's talk about confidential computing.
You wanna use public cloud services
to minimize upfront costs
or maybe to rapidly develop cloud native applications.
But these applications are gonna deal
with confidential information.
Not only do you want to encrypt the storage used,
but you also want to prevent any cloud operations teams
from getting access to that data,
even if they've got physical access
to the data centers themselves.
One way that we enable this is with a set of technologies
that we call IBM Cloud Hyper Protect Services.
Hi, I'm Chris Poole.
I'm a senior solutions architect
in the IBM Hyper Protect team.
In this video,
I'm gonna talk a little bit about what you can do
to ensure your customer's data stays confidential.
And then, I'll introduce a simple application
that demonstrates basic use case
and I'll show you how it works.
Now, part of an overall solution
to protect your data is to encrypt it.
But now, you've transformed the problem
into the problem of how do I secure my keys?
One way to help resolve this issue
is to employ an HSM,
a hardware security module.
This is a physical card,
a small lockdown computer that's been engineered
to be tamper-resistant.
You can store your keys in there,
and nobody, even with physical access to the system
is gonna have access to your data or your keys.
The hyper protect variant of this,
your own discrete slice of an HSM,
coupled with a secured software stack
is called the IBM Cloud Hyper Protect Crypto Services.
Before making use of HSMs,
they have to be initialized with a master key,
which has got ultimate trust and power.
Once done, the HSM is primed for use.
The crypto service and the HSM that uses
is a little different from others on the market,
and that it has the model of keep your own key,
not just bring your own key.
What this means is that we never see your key data
during the initialization process
so you don't have to extend your trust model.
But it also means that you have to go through
this initialization process yourself
that we call the key ceremony.
Once initialized,
the HSM can store root keys or standard keys,
which in turn can be used with technologies
like envelope encryption,
to be able to protect your client's data in object storage,
in databases or things like TLS certificates.
Let's do the key ceremony now.
One popular way of doing this
is with our trusted key entry command line interface.
But another way is to use smart cards
and a smart card reader.
These cards in turn can be used
to store master key data in them across multiple cards
so that you can take the different cards
and place them securely in different locations
and have them owned by different trusted people
within your organization.
Let's use these smart cards and initialize the HSM
I'm gonna use for the demo.
First, let's do the first card.
For brevity, I'm not showing the full process here.
(keyboard typing)
Once that's done,
I can repeat this whole step
with another card or another few cards
to be able to split the master key
across these different devices.
I don't need these cards for day-to-day use of the HSM.
Only for the initialization process
and for any future administration.
So I can take these cards.
Give them to different trusted people in my organization
and have them securely store them
at places like bank faults.
Then, later on,
if I want to do any administration of the HSM,
I can bring the people and the cards back together
so that we can perform these operations.
So the initialization has been done.
Now, let's talk about the demo.
In my organization,
I've got different teams
who each own their own set of cloud native applications.
For cost reduction,
I want them to all be able to write
to a consolidated database.
But I want to be able to isolate the data
between the different teams.
So one team can't read the data from another team.
So what I'm gonna do here in a very simple way
is to have some different applications,
take some input data and encrypt it with a different key,
one per team,
before storing it in the shared database.
This database, by the way,
is another of the Hyper Protect Services.
The confidentiality requirements obviously transfer across
to the long-term data storage.
So we have database flavors
that also run within secure enclaves.
So the data and the logs are encrypted
and there's no underlying machine access.
So let's deploy the applications.
I've containerized them into a virtual server instance.
And you guessed it.
Another secure enclave
that we call Hyper Protect Virtual Servers.
In this way,
the runtime data is also protected.
And only I,
with the SSH key injected at service creation time
can access the applications.
Let's stand up a Mongo database instance on the backend,
then SSH into the virtual server,
start up the applications and connect it all together.
So the data flow is simple.
The applications expose the Web UI.
They receive that information.
Make use of a key port from the crypto service at runtime
to encrypt the data
before storing it in a database on the backend.
Let's add some data and use the applications.
So I'm entering some data here.
Storing it in the database.
And then, I can go to another screen
and confirm that I can retrieve that data from the database
using the key it has in memory to decrypt the data
within the application runtime.
It's all end-to-end encrypted during transport and at rest.
Let's switch teams,
meaning we'll pull a different key from the crypto service,
a different application,
and let's store that data before checking we can read it.
We can.
But now, let's try to read the data
from the first team's application.
It's encrypted.
We can't read it.
We've consolidated our data pool,
but we've still kept the teams isolated.
So these are the IBM Cloud Hyper Protect Services,
helping my data to stay confidential.
So let's summarize what we've just done here.
We deployed a secured virtual server;
We created a lockdown database;
And we created an instance
of the Hyper Protect Crypto Services,
and then initialized its HSM.
Using these three different services,
we deployed an application.
It's able to take data from the end-user,
encrypt that using different keys for different teams
from the crypto service before pushing that encrypted data
into a consolidated database.
In turn, this creates a cohesive,
confidential computing platform on IBM Cloud.
Thank you for watching.
If you've got any questions,
please drop us a line below.
If you want to see more videos like this in the future,
please like and subscribe.
And don't forget,
if you want to learn more
about the IBM Cloud Hyper Protect Services,
please check out the links below.