Let's look at the data encryption key, or the DEK,
when we're talking about data storage.
There could be one of two ways in which the cloud customer is
engaging with encryption in their cloud workloads.
It could be what's called client‑side encryption,
where the encryption is being posed by means of some hardware device local to
the cloud customer or some application that they're using,
or it could be that it is server side where the encryption is taking place
on the platform that the user is consuming in the cloud.
It could also be a combination of the two.
As is the case inside of the Google Cloud Platform.
Their data encryption standard says that when a cloud
customer interacts with their cloud storage,
they are first going to be consuming a data encryption key.
Now there is a process of what's called KEK,
or key encrypting keys, otherwise known as key wrapping,
that occurs with all symmetric keys from the AES family.
The Google KMS is actually protected by means of a KMS master key.
Now this is not going to run on general production machines,
but instead, it's run on dedicated machines in each of the Google data centers.
That KMS master is further protected by means of what's called a root KMS.
So the KMS master key is an AES‑256‑bit key protected
by another key that's AES‑256 B, actually encrypted by that,
that is only running in memory.
This root KMS is actually only running in memory and not on disk. If in
fact there's failure of all these systems, to address a scenario where
all instances of the root KMS master key has to restart simultaneously
globally or somehow there's some separation between the root KMS and the
rest of the hierarchy, the backup would be needed from all distributed
systems. That's actually stored inside of a safe for a global restart.
Fewer than 20 Google employees are able to access these safes.