New Crypto Key Storage Options in the Google Cloud Platform (Cloud Next ’18)


[MUSIC PLAYING] IL-SUNG LEE: Thank you very much
for joining me for a lovely, I guess, really foggy
Thursday morning. My name is Il-Sung Lee. I’m a product manager
with the Google Cloud. I’m actually based in New York. So I had to fly out here. And thanks for
coming for joining us to talk about the new
crypto key storage options for the Google Cloud Platform. I just want to ask
people here, so how many people here
care about crypto? OK, so you guys are
all in the right room. So that’s fantastic. That’s a great start. What I’d like to talk
about on this talk right now is that I’d like
to start talking about the new key
storage options that we’re going to provide
with the Google Cloud Platform. Now, how many people think they
know what the new key storage options are going to be? Anyone have a guess? OK, [INAUDIBLE]. So you guys were
listening, so fantastic. I want to tell you, this
is really, really thrilling for me to be up here to be
able to talk about this. For so long, I’ve had to
actually not talk about this and tell people I
work on something that I can’t tell you
about, including my wife. And then my wife
would keep asking. I’d tell her that
I can’t tell you. And now I can tell her and
she’s like, I don’t understand. And so hopefully you guys
can understand a little bit better than my wife can. So that would be fantastic. I’ll also talk about some new
key types and capabilities that we can do. And then we’ll just start
generally discussing things around how to help satisfy
compliance requirements, what we’re talking
about, and how to help meet internal
security requirements. All right. Does that sound good? All right, cool. So let us start off with
kind of an overview. We always do these overviews. And I promise to make this
as least painful as possible. But if you’ve ever talked to me
before, and did I mention this? Yes, I did. I work in New York. I am the product manager for
a lot of the key management in the cloud. And so I’ve talked to probably
some of you, at least, and discussed some of the
current key management options. So if you take a
look at this scale, you have that scale
of controller keys. And on the far right side,
you have no real control. And on the far left
side, Google really has no real control
over the keys. So on the far left side,
default encryption. That’s the thing
where we provide you with the encryption of your data
at rest, whether you want it or not. Now, we’re a little bit
authoritarian that way. But you guys don’t
have a choice. When you put the data
up into our cloud, it has to be encrypted. We don’t really allow
you not to encrypt it. And so what happens is that
you’re putting your data up to the cloud. We have this elaborate system
by which we break up your data. We shard it or break
it into chunks. And then we individually
create random encryption keys for each single one. And those encryption keys
get regenerated every time you update that data. And they get sprayed
out to the data center. So if you attended the talk
that Maya and I did yesterday, we talked a little
bit more about this, so won’t go too much into it. But you know, the keys
that actually protect each of those chunks is
protected through a key that’s in our internal
KMS system that’s protected through
elaborate keying system. And I think the thing I said
yesterday was that ultimately, that key actually gets stored
in physical media in case of a complete global disaster. And it’s known by 20 or less
people in Google, I believe. And I’m not one of them. So if you try to come and
extort me, then I know nothing. No. The next thing on that
list is that if you want to go a little
bit more into control, we have Cloud KMS. And this is where it’s
basically external instantiation of our KMS system. So we’re now providing you with
the capabilities of actually creating a AES 256 symmetric key
to do encryption of the data. I mean, you can do creation,
deletion, rotation, all the things you expect to do. In addition to that,
we’ve been integrating this with various
different services, our so-called customer
match encryption keys. And then next to that, we
have the customer-supplied encryption keys if you
really want to have more control over your keys. And in that feature, we actually
don’t keep your keys at all. So when you actually put
data up in your GCS bucket, for example, then you need
to provide a secret that we use to help encrypt the data. And then every time you
want to access that data, you have to re-provide it. And we use that secret
to help decrypt the data and then we get rid of it. It never gets stored anywhere. It definitely
doesn’t go to disk. It’s only in memory. So it’s something that’s
available for GCS and GCE, but not for other services. One of the main
problems is that when we say we don’t keep the key,
we really don’t keep the key. And so if you lose a key,
there’s absolutely nothing we can do about it. And if you don’t
provide the key, there’s really nothing we
can do about your data. So for services that require
us to do background operations, such as like impaction,
for example, which some of the services
do, we can’t help you because those things
are going to fail. We don’t have the
key to do that. So as a result, it’s only
available for GCE and GCS. And we’ll likely
not go beyond that. And then finally, on the
far right side– and this is something that
some people have done. I see some people here
who might have done this. But basically, this
is where you want to keep your own keys
in your own device that you want to have complete
control over and insurance and everything else. And so you will provide the HSM. And we’ll help you
host it somewhere close to one of our data centers. And we can help set up the
high-speed interconnect, provide a super low
latency connection to this. Obviously, the
downside to this is that you are still responsible
for buying the devices. You have to still operate them. You have to make sure that
they’re all clusterized, everything else, and that your
application will basically connect directly to it. So you’re not really leveraging
the cloud services directly for this. And feel free to
ask any questions as I go along the way. And if you feel like
using the mic, go ahead. Otherwise, just shout it out. So now I’d like
to introduce Cloud HSM, the thing that my wife
doesn’t really understand. But I tried. So this guy fits right in
the middle of the scale. So it gives you a
little bit more control over your keys or KMS in
the sense that you now have a service where it’s
protected by a hardware security module. How many people here
know what an HSM is? Wow, you guys are awesome. Yeah, so they give
you the insurances of what an HSM provides. So we can’t get
the key material. I mean, all the
things like that. Tightly bound to the hardware. And it basically gives you
more options now for your KMS. So let’s start off with– it sounds like most of you guys
know about this, but just kind of indulge me and
I’ll just try to make sure everyone’s kind of a level
set and explain what an HSM is. So an HSM is a Hardware
Security Module. So it basically is
a physical device for managing keys and
performing crypto operations. It does a little bit more
that, but essentially that’s what it’s really used for. And people like these things,
largely because they can create keys that are non-exportable. The hardware will
provide some guarantees that once you create the
key inside this thing, it’s not exportable, kind of. I mean, the vendors like to
allow the keys to move around between their own devices. But you can’t export
anything else. And then they provide tamper
evidence and tamper resistance. So if you try to break
into one of these things, then they’re saying that they’ll
probably be able to notice and they’ll record it. And if you actually try to
compromise and you get close, then it’ll do things
like exert all the keys so the keys are completely
wiped from the system. And the other thing
is that they come with FIPS 140-2 certification. And– yeah, please. AUDIENCE: Why not three,
if it’s a hardware device? IL-SUNG LEE: Sorry? AUDIENCE: You haven’t
achieved FIPS level 3 yet if you’re doing penetration? IL-SUNG LEE: Well,
the FIPS level 3– FIPS 140 dash level 3
dictates some other conditions around what you have
to provide and such. HSMs typically provide
level 2 or level 3. Right? AUDIENCE: [INAUDIBLE] IL-SUNG LEE: Yeah. And I’ll talk a little bit
more about this, as well, for our service. But this certification
is important. It’s a certification
that comes up by NIST in the US government. It’s the only real good
certification that’s available for crypto modules. And that’s what it defines. So as a result, a
lot of people depend upon using FIPS as
a kind of a gauge to whether this is adequately
implemented or not. And so again, like you
asked, for level 1, you can do this with software. Typically for anything
greater than that, you need a hardware
module, like an HSM. Now, in terms of main
use cases, lot of people use this for
regulatory compliance. So if you’re doing
things like you’re in the financial industry,
maybe the health care, you do some payments,
things like that, you likely do require to have
something that actually has some high bar
around protection of keys. Maybe you have specific
NIST FIPS requirements. Then these HSMs become
extremely valuable. Another thing is is that
whether it’s right or wrong, people feel more safe with
putting their keys in hardware devices because of some of the
properties I listed before. And so if you have
high-value keys, for example, like perhaps the keys for
your top signing cert, then you may want to
put it into an HSM, just to make sure that you
have that extra assurance that they’re protected. Make sense? You guys now know as
much as I do about HSMs. So that’s great. Now, what’s Cloud HSM? So Cloud HSM is
basically taking the HSMs and making it into
managed service. And when I say managed,
I’d like to kind of clarify what Google’s definition
of managed is. So managed means that basically
we do everything for you. The only thing you
have to worry about is the API for doing the
logical, application-level API interaction. So when we manage
it, it means that you don’t have to worry
about any of the hardware or the infrastructure or
anything else like that at all. We’ll make sure that the
patching of the hardware is all done by us. If there’s any kind of
availability concerns, we’ve fully
clusterized everything. We have a very smart layer
that actually makes sure that it’s completely available. If there’s scaling
issues, we autoscale. We just basically restart– that was a really
interesting story. Yeah, we basically are able to
scale pretty much horizontally with any kind of workload
that you bring along. So there’s no
concerns around that. And they’re also rooted
in physical HSMs. So the key material is not
available outside of HSMs, which means that you can’t get
access to the key material, but neither can we. And if you take a
look at that diagram there, the way that
you think about this is that the Cloud
HSM feature actually leverages the exact same
API frontend as Cloud KMS. So if you’re familiar
with Cloud KMS, and I’ll show you
in a demo later on, it’s actually as
simple as just flipping a flag when you create the key. And all of a sudden,
everything else that you have in
terms of the APIs you use, the client
libraries, this works, except that the keys are in HSM. And I’ll also explain to you and
in a demo about how we actually prove to you that
the keys are actually in the physical device. So in the diagram
here, going back to that, when a request
comes in from a client, they go to the KMS service. And the KMS service knows that
this key is a software key. So we go down to the
software key backend. We do the operations there. Or if it’s a hardware
key, then all the requests get routed to the
hardware layer, which actually goes to the
individual hardware node. We obviously use some
smart logic there in terms of picking
the right node. And in that case, all
the crypt operations and all the key creations
and everything else actually happened
right in the hardware. It’s not that we’re
doing the software. These things actually
happen in the software– I mean, the hardware. Now, why should
you use Cloud HSM? Again, I’ll say this a
lot because this is what a lot of customers care about. But compliance comes up
very, very, very often. So if you have a
compliance need, whether you want to or not,
it’s going to come up again. Now, regionalization is another
really, really cool feature that we provide as part
of the new product. So if you create a
key within Cloud HSM, then that key is actually
cryptographically bound to the hardware devices
within that region. So suppose I go and create
a key in US Central 1. Those hardware devices
in US Central 1 are the only ones that are
able to use our crypto key. And so the way that we have
things architected right now is that the keys
are always stored in one of our highly
available [INAUDIBLE] systems. And those things can actually
move the keys around. And in fact, we don’t
provide any guarantees around the location
of those stored keys. But the keys themselves
are protected by the HSM, or at least HSM keys. So they can only
be used, unwrapped and used by those HSMs. HSMs in a different
region cannot use them. Right now the Cloud HSM
feature is currently in alpha, soon to go into beta. And right now we’re
located in US Central 1. But we will be releasing the
beta across the United States and then slowly start
rolling out globally. So this is something
that you should be able to see around the world. Yes, please? AUDIENCE: You mentioned that
the Cloud HSM keys are regional. What about the regular KMS? Are those also region-specific? Or are they stored in the cloud? IL-SUNG LEE: The
question is whether the same regionalization
guarantees happen with KMS keys, KMS keys. The answer is no. So the Cloud KMS keys, when
you actually create the keys in a certain region, they
will be very likely served from that region. But the system, in order to
provide availability or to– suppose that a certain
region goes down. It is able to serve that
key from different regions, if necessary. AUDIENCE: Can I ask– IL-SUNG LEE: Yes, please. AUDIENCE: So that means that– I think you mentioned it
but I want to clarify, is that with Cloud HSM you
will not get high availability across regions? IL-SUNG LEE: Yeah,
so the question is does that mean
that with Cloud HSM, we don’t get availability
across regions? That’s actually my next bullet. So right now,
we’re in one region because we’re in the alpha. And then beta, we’ll come
up with more regions. But we will actually provide
support for multi regions. So this means that, just
like Cloud KMS right now, we’ll have a global
region and we will have a US region, Europe
region, and Asia region. And what these
multi regions mean is that when you create a
key within, for example, the US region, then
that key can actually be served out of any of the HSMs
within those multiple regions. So it’s up to you. You can actually choose
how granular you want this. Over there, please. AUDIENCE: Could you help
explain the context of alpha? IL-SUNG LEE: Oh, sure. I’m sorry. So the question is, can we
explain the context of alpha? So alpha for us is
generally, but not always, a closed release. So we have a subset of people
who are actually using it. They’re testing it, providing
some close interactive feedback. And then when we
get to beta, beta is the point at which we
actually release it publicly where we will provide full
support for the product. We’ll provide– you can actually
put production workloads and everything on it. The one thing that
we don’t necessary provide until we go generally
available is the SLA. Yes? AUDIENCE: [INAUDIBLE] IL-SUNG LEE: The question
is whether anything that– the features that we’re
mentioning right now would be cut from the beta? No, no. The answer’s no. Everything that I’m
talking about here is definitely stuff that we
will be providing in the beta. Question? AUDIENCE: When will HSM
be globally available? IL-SUNG LEE: Yeah. Question is when will HSMs
be globally available? I can’t answer that right
now, because it depends upon schedule around when we
can actually start deploying the hardware to other things. The cloud HSM has been a
very interesting project, at least for my career,
because it’s not only software, but there is a strong
hardware component to it. And so especially
since we’re dealing with cryptographic
devices, as well, there’s some
increased sensitivity. So what we will do is
that we will actually start rolling these
things out depending upon what our hardware operation
schedule and everything else is. And we’ll have to
figure this out. But I don’t have that
answer right now. Yes? AUDIENCE: Is the Cloud HSM
a partition or a shared partition? IL-SUNG LEE: That’s
a good question. So the question is whether
the Cloud HSM is a partition or a shared partition. We don’t follow the
traditional model that you may be used to
from using a regular HSM. We’re not providing you
with a dedicated partition. Basically there’s– it’s
a multi-tenant service. So the only tenant for
these HSMs is Google. And we will manage the
separation of your keys and everything else for you. And this is a little bit of
a difference from the way that things happen from your
original, traditional model. But what this allows
us to do is it allows us to develop an
extremely flexible and scalable type of service that
allows us to provide this fully managed
type of features that we hope that you’ll enjoy. All right? Next slide. So now I want to talk a little
bit about the key features. So three things I want to
point out specifically. I want to talk a little
bit about asymmetric keys. And I think pretty
much everyone here should understand what that is. Statement attestation,
right this is basically the validation
that you have a key in the HSM. And then CMEK, or Customer
Managed Encryption Key Integration. OK, let me talk about each
one of these individually. So asymmetric keys,
up till now KMS has only provided support
for symmetric keys. So you had one choice. You can do AES 256 to encrypt
data, do envelope encryption, or do encryption
with other services. But that doesn’t cover all
use cases, necessarily. And so now we’re going to
allow you to actually create different types
of asymmetric keys and support things
like code signing. This comes up every so often. People want to
sign certain things and they want to make
sure that the signing keys reside in the HSM itself. It’s very, very typical. And it makes a lot of sense. And certificate
authorities, as well. I mean, if you work
for an enterprise, then chances are
that, for example, you have internal,
non-authoritative CAs. And they’re probably
doing things like dishing out X.509
certificates to all your laptops and
everything else that happens in your enterprise. And so that’s something
where you can actually take those valuable
keys, all the root keys, and stick them
into our cloud HSM. Now we are providing
different types of keys and key sizes for
signature verification. So as you can see
there, we provide RSA 2k, 3k, and 4k keys. And in addition, we’ve support
a couple of elliptic curve with two different types of
NIST curves, so P256 and P3A4. Now, for decryption
purposes, you can actually use RSA
keys for decryption. So if you choose
to actually decide that I want to do some kind
of PKI type of environment, then that’s available
for you, as well. And I want to put
that out there’s a box on the bottom right
corner that this is also available for cloud
KMS and software. So everything that
I’ve discussed here in terms of asymmetric
keys, you’re free to do this, as
well, in software if you choose to
just use something that’s more globally distributed
and cheaper and faster. Any questions about that? All right, cool. Now, statement attestation. This is where we provide
you with the confidence that your keys were actually
created in the HSM itself. We could always say that,
yes, please trust us. But we thought
that you guys might feel a little better about
being able to trust something more than my word for
it, standing up here on this pedestal. So what the statement
attestation is is that it’s a cryptographically
signed statement from the actual HSM hardware. And we’re not using
any kind of Google developed or branded hardware. We’re actually using
third-party hardware that’s created by a
third-party manufacturer. And so the device
itself will provide you with a cryptographically
signed statement that says that this key was actually
created within our hardware boundary, within the FIPS
boundary, which is probably something important. Yes? AUDIENCE: Can you share it with
a third-party HSM manufacturer? IL-SUNG LEE: The
question is can we share it with that third
party HSM manufacturers. It’s Cavium. Cavium. There’s no point
in trying to not say it because when you
actually look at the attestation statement. You’re going to
see the signature. And you’re going to see that
it’s not a Google signature. Now, the signature
can actually be– [MUSIC PLAYING] I’m really sorry, I’m not sure– [LAUGHTER] I’ll tell you what it is. I’m doing demo on
this laptop later and they told me
that in order to keep the screen from
locking that I should play YouTube in the background. So I have Schubert
running in the background, in case you’re
wondering what that was. OK. AUDIENCE: Can we
listen to [INAUDIBLE]?? IL-SUNG LEE: Well, the talk’s
not going that badly yet, so we’ll see. So that statement of attestation
could be verified manually. The manufacturer will
publish the format of what the attestation
statement looks like. And we will provide scripts
that you can download. They’ll just be Python scripts. You know, fully, you
can take a look at it and make sure it doesn’t just
say printf everything’s OK. So you can download
those and you can use this to actually
verify key attributes. And speaking of that, I’m
going to go and give you a demo of this right
now where I’ll show you how to go and create
an asymmetric key and verify that it actually was
an asymmetric key in the HSM. So if you wouldn’t mind
switching to my laptop? OK, so can you just see
this, or is this too small? AUDIENCE: [INAUDIBLE] IL-SUNG LEE: Is that better? AUDIENCE: [INAUDIBLE] IL-SUNG LEE: Yeah. I wish there was the
quick option from Magoo. But you know what? Let me just do it this way. So is that better for everyone? Can you guys see? All right. So I created a key ring. I already did this
because I didn’t want to step through
everything in its gory details. But I create a
keyring, US Central 1, which is where our current
alpha HSMs are staged. And so this is actually–
one other preface is that this is the alpha UI. The beta UI is
very, very similar, but it’s a little bit different. But it’s not going to
be marginally different that you’re going
to be confused. So I’m going to create the key. And you’ll notice right away, if
you’re familiar with Cloud KMS already, that things are a
little bit different now. So I’ll create a key
that says HSM demo key 1. And I now have the choice
of actually choosing different types of key purposes. So I can choose a symmetric
key, which is the default. Or I can create an
asymmetric key with– RSA asymmetric key for signing. Or I can create an
RSA asymmetric key for decryption, so encryption
decryption, or an ECKey. So let’s create an RSA key. And then it gives you the option
to choose different types. There’s a bug in the UI. There should also be a 3k
key listed there, as well. But you can choose 2k, 4k. And then you have
one other option, which is the protection level. This is a key. This is where you can
actually say that I want to go and create the HSM key. And so that’s all
you have to do. Yes, question? AUDIENCE: Just a quick question. IL-SUNG LEE: Yeah, please. AUDIENCE: With respect to
cost that you have there, $0.06 a month, based
on storage construct that you guys execute,
you shard the data out, it’s assumed that we’re
going to use the same key across the shards, right? Or not? IL-SUNG LEE: It depends. It depends. AUDIENCE: If not, are we
getting charged $0.06 a month– IL-SUNG LEE: No, this
is on a per key basis. So if you choose to– and I’ll
show you a demo of this later. But when you actually associate
the key with, for example, a GCS bucket, then regardless
of how many buckets you protect with it, it’s
charged on a per key basis. AUDIENCE: [INAUDIBLE] IL-SUNG LEE: Sure, sure. No problem. All right so I chose
protection-level HSM. And then I created. And I’ve already created
a ton of these keys. So that’s why it’s
kind of busy over here. But you can see here that– which one was the one I created? Yeah. HSM demo key, right? And– AUDIENCE: [INAUDIBLE] IL-SUNG LEE: Demo key 1 there. So you can see right there
that it actually create the key and it says that’s an asymmetric
key using RSA signing. And if you click into
this, it comes up with the key versions enabled. Now, one other thing I
want to point out here is that if you look
down at the bottom, you’ll see that there’s a
couple more options now. So– oh, you can’t
really see it. I’m sorry. But there’s a Get
Public Key option. And right beneath
that, if you can get past the letters
overhead, it actually says Get Attestation. So that’s where you can download
the attestation statement. And you can also do this
through the G Cloud command. So let me just do
it through G Cloud. And I’ll show you a quick demo
after this thing connects. OK. So what I’m going to show you is
I’m going to show you a script. I was going to kind
of walk through this rather than see you guys type
on stage and make mistakes, I want to show you through
a script how things work, essentially. And I’ll walk you through
doing a signing operation. Plus, I’ll show you how
to actually validate that attestation. So if you look here, so
now what we’re going to do is that we are going to create– sorry. We’re going to go
create an EC3A4 key. And so you can see
that right here. That’s one of the options. And it’s got a purpose
of EC signatures. And so that’s going get created. So the next thing
we’re going to do is we’re going to
retrieve the public key. OK, so a simple thing to do. And also another
thing I should mention is that when we create
the key, we actually requested the attestation file. That’s what the dash
dash attestation file is. And then the next thing
is that we actually just request a public key. And so that’s going to
download that, as well. And there’s a public key. It’s Base64 encoded. And the next thing we do is we
just create some dummy data. So foo in some file. And what we’re
going to do now is that we’re going to go and call
the HSM to actually go and sign the key. I’m sorry, sign the data. And so in this case, we’re using
the ECKey that we just created and passing it the data. Now, it’s going to come
back with the JSON file. And the JSON file provides one
of the fields called signature. So this right here is the
Base64 encoded signature. Now, my apologies to
the people in the back. But you don’t really need to
see what the actual values are, obviously, right? It’s just Base64 encoded
on this signature. And so right now the next
thing that I’m going to do is that I’m going to
actually extract that, put that signature to a file. And then I’m going
to use OpenSSL. So the OpenSSL is
now running locally. And it’s going to verify that
that signature corresponds to the data that we just signed. And hopefully it
says verified OK. It says verified OK. So the signature
that we generate with the HSM, Cloud
HSM, corresponds to what OpenSSL just verified. Now that we’ve done
that, let’s just say that we want to make sure
that we’re actually using the proper key in the HSM. And we want make sure that
it’s not some software key. So we have that attestation file
that we just download, right? And what this Python script that
you can download off the web does is that it actually
takes this set of certs, this cert bundle,
and it actually verifies that the signature
associated with the attestation statement corresponds with
the certs in the cert bundle. Kind of make sense? OK. And– oh, sorry. Oh, I didn’t install the
Python Handler for OpenSSL. So we’ll skip that for now. But essentially what
that comes back with, it says it’s verified. And then the next
thing that we have is that we can actually query
the different attributes within the
attestation statement. And so if you look
through– and I just want to point out a few things,
that there’s a lot of things here. Oh, geez. I hope you guys can see. There you go. OK. There’s a few things I
want to point out here. One is that if you look at
this, there’s an ID field here. This ID field is
basically a concatenation of a random string plus the
SHA hash of the actual key ID. So you can verify that by
matching the two together. And actually, the script
will help you do that. And then there’s a EKCV. That’s a public key. That’s a hash, to SHA 256
of the public key itself. So you’ve already
downloaded the public key. You can verify the hash against
what the HSM is reporting. And this gives you a nice
cryptographically strong way of actually validating that
they correspond with each other. And this is something
you can obviously do only for asymmetric keys. One other thing I
want to point out here is that if you look in the
private key attestation statement section, there is
a file called extractable, right there, and
it’s set to zero. And what that’s saying is
that the HSM is confirming that the key is not exportable. So we now have proof
directly from the hardware that the key that you’re
trying to refer to is actually not
extractable, as well. Yeah, please? AUDIENCE: If we don’t get
this attestation statement, is it in the log files for HSM? IL-SUNG LEE: The actual– which one? The attestation statement? Because you can download the
attestation statement any time you like. AUDIENCE: OK. IL-SUNG LEE: Yeah. You don’t have to do it
right at key creation. The other thing is
that you can also use this to actually
help validate that the resource name
matches what was reported in the attestation statement. And the Python script
here helps you do this. And so it verified here that
the keys match in attestation. And then another
thing it’ll do is that it’ll match that the public
key that you’ve downloaded matches the hash that’s in the
attestation statement, as well. And so you can do that, as well. And it comes back and
says that it matched. So this is a really, really
a cool way of actually– you know, especially if
you’re a crypto nerd– to be very secure
and really, really feel comfortable with the
fact that I am actually talking to the hardware device. I’m talking– I’m using a
key that I think I’m using. Yeah, question? AUDIENCE: Will there be
an actual integration with YubiKeys keys or
hardware [INAUDIBLE] universal key management? IL-SUNG LEE: So the
question is whether there will be any kind of
integration with YubiKeys or any kind of personal
integration with Cloud HSM. If you’re talking
about doing things like being able to bring your
keys up and put store them into the HSM and such,
then that is something that we’re strongly looking at. We don’t have anything
available right now. But if this is something
that’s interesting to you, please come up later and we
can chat a little bit more. Yes? AUDIENCE: [INAUDIBLE] IL-SUNG LEE: The question
is whether this will be supported on a mobile device. This is a cloud service. So as long as you can access
it through the internet, you can access it
anytime you like. AUDIENCE: [INAUDIBLE] IL-SUNG LEE: Well, that’s–
the question is because this is HSM, whether we need
a physical connection. No, the whole point
of the Cloud HSM is that we’re providing
a cloud feature. So we’re backing it using
hardware devices that we’re putting into our data center. But we’re exposing it
as a cloud service. So basically it’s a
web endpoint for you. OK, question? AUDIENCE: [INAUDIBLE] can I
do both with the same key? IL-SUNG LEE: The
question is, can you use the same RSA key for
both encryption and signing? No, you can’t. The way that it’s
set up is that you need to actually state the
intention of the key when you initially create it. AUDIENCE: [INAUDIBLE] IL-SUNG LEE: Right. So the comment is
that you can usually use the same key for,
for example, email for doing both signing
and encryption. That is true. The way that we’ve
designed this right now is that we want to make
an explicit intention around to know what the keys are used
for so that we can actually limit the scope of
what the keys can do. If there’s a reason that you
think that we should be able support both with
the same key, then I’m very happy to hear this. And we can talk about
this in the future. Yeah. Thank you. Yeah, please. AUDIENCE: [INAUDIBLE] IL-SUNG LEE: So the question is
whether the asymmetric software keys or GA or– I mean, sorry, if they’re
out or what’s the status. Currently right now they
are in the same situation as Cloud HSM. They’re in alpha. And so when Cloud HSM
becomes available in beta and becomes public,
you can expect to see the asymmetric keys being
available in software, as well. OK. All right. So that was a demo, actually,
for just showing you the attestations and making
sure that we can actually prove this. Is there any questions
around the demo? All right. Can we switch back to
the slides, please? Thank you. Yes, please. AUDIENCE: [INAUDIBLE] IL-SUNG LEE: I’m
sorry, is the tool– AUDIENCE: A paid service. IL-SUNG LEE: Oh is
it a paid service? Do you mean the Python scripts? AUDIENCE: Yeah. IL-SUNG LEE: So
the Python scripts that we use to
actually verify it, it’s not going to
be a paid tool. It’s going to be
something that we’re going to allow you
to freely download. And it will be
something that will be published on the
web where there will be a link for you download. AUDIENCE: [INAUDIBLE] IL-SUNG LEE: Yeah,
so the question is whether the actual process of
generating a key and verifying is a paid service. Yes. So Cloud HSM will
be a paid services, just like Cloud KMS is. So you will be charged to
do the signing operation. But the verification service
operation that I showed you was actually done on local
client using OpenSSL. So that’s something that
you would do on your side. We’ve not yet heard anyone who
had a valid reason for doing verification on the HSM itself. But it didn’t quite
make sense to us. But if there is,
I’d love to hear it because it eluded us so far. AUDIENCE: Not even in
FedRAMP environments? IL-SUNG LEE: Not even in
FedRAMP environments, that’s true, because typically you
don’t have those signature verifications happen outside–
the signing operation is the thing that’s
really, really important. Yes. AUDIENCE: So where
do you kind of envision this product,
both for personal users and for enterprise users? IL-SUNG LEE: The question
is whether I envision this for enterprise and personal– AUDIENCE: But where? Like, where do you kind
of see a personal user might use Google HSM? IL-SUNG LEE: Oh, I see. So the question
is, where I would envision someone who uses this
for personal use, perhaps? You know, I’ve got
to be quite honest, I haven’t heard
of a lot of people who really feel like using
HSMs for personal use. There’s typically not anyone
who has a personal reason to have something that’s
very, very secure like this. Now, that being said,
this is a managed API. It’s on a per usage basis. So if all you’re doing
is creating a single key and doing a few
operations, it’s not going to cost very much at all. And so you’re perfectly
welcome to do that. But I’ve only met
one person I know that plays with HSMs for fun. It’s one of our PMs. He works out of Kirkland. And he likes to
buy them off eBay and has a whole
garage full of them. And I don’t know. I don’t think there’s
something right in his head. But I think that he– because no one does
that for fun, right? But you know, I envision that
this will be very popular with a lot of enterprise users. For personal users,
I can see it if you need to do something
like you want to host your certs, for example. And you need to actually just– you just want to make
sure that’s in something you feel a little bit more
secure about because it’s up in the cloud. But it’s totally up to you. Yes? AUDIENCE: Will this be available
for Marketplace integrations? [INAUDIBLE] IL-SUNG LEE: Yeah. The question is
whether this will be available for
Marketplace integrations. No. Not the way that
it is right now. But anything’s
possible in the future. Yes, question? AUDIENCE: Will it be available
for separate instance of HSM or will it be a
multi-tenant [INAUDIBLE] IL-SUNG LEE: Oh, the question
is whether this will always be multi-tenant, or it can be– yeah. Right now, this is
envisioned to be purely a multi-tenant service. The reason is that
in order for us to provide the amount of scale
and flexibility that we have and kind of design it
to be basically exposed as an API service, it
was necessary to make a multi-tenant. And also economies of scale,
and all the other great reasons people use the cloud. But yeah, that’s
a great question. It’s multi-tenant. Yes. AUDIENCE: [INAUDIBLE] IL-SUNG LEE: Yeah. So the first question
is, will the HSMs be available in all regions? The HSMs will be
available globally. And it may or may not be
available in all regions. And so as I said
before, it’s not as easy as deploying code
and pushing out software because there’s a lot
more process involved in trying to get devices
put into the data center. But we will make sure that’s
represented in the places where it’s most
valuable to people. And so if there’s
a particular area that you guys care
about a lot, then I encourage you to come
and talk to me afterwards and we can chat more about this. And then the second question
was whether this can be integrated HashiCorp Vault. It already can. It already is because
essentially, HashiCorp Vault is already integrated
with our Cloud KMS. And as you just saw,
the only difference between Cloud KMS and Cloud
HSM is a flag when you actually create the key. So to HashiCorp Vault,
it looks like just like a regular KSM key. All right. So the final thing
I want to talk about is the CMEK integration, or
Customer Managed Encryption Keys. So this, I think, is a
really, really great feature because a lot of people
put data into the cloud. And they want to make sure
that they have some control over those cloud services. And right now what you can
do is that you can actually put data in BigQuery, for
example, which is already GA. And you will be able
to actually associate the encryption key
that ultimately protects the data in Cloud KMS. And consequently,
since Cloud KMS is integrated with Cloud
HSM, in a Cloud HSM key. And it’s available not
only for BigQuery, but also for Compute Engine,
which is in beta, also for Cloud Storage and Dataproc. And so what I’d
like to do now is I’d like to actually show you
a quick demo of how this works and how simple it is. And so if you’ve already used
Customer Managed Encryption Keys already, then this
is probably something that you’ve already
gone through. But I think it’s kind of
neat to actually realize that everything is being
protected, ultimately, by a key in the HSM. If you can switch over, please. OK. So what we’re going
to do is we’re going to first start off
back in the KMS console. And remember that when we’ve
actually used Customer Managed Encryption Keys, we’re
talking about symmetric keys. So let’s go and create
a symmetric key here. Let’s just call it HSM demo– whoops– demo sym key. And it’s going to
be a symmetric key. And we’ll put it in
hardware because that’s what you guys are
all here to look at. And I’m going to create it. So HSM– I apologize
for all the keys but– so here’s a key that
we just created. And I’m just going to go
through and I’m going to– well, I guess I don’t need to
do this, but I’ll do it anyways. So what I’ll do is
that I will now go to create a new bucket in GCS. And I’ll just say that
this is an HSM demo– bucket– whoops, bucket two. Because I might have
already created bucket one. Require regional, US Central. And here’s the thing. In advanced settings, you can
actually go right from the UI and choose to say that I want
this to be managed by Google, which is the default
encryption, or you can choose to say that I want to
use customer managed encryption keys. And remember, it doesn’t
care whether it’s a KMS key or an HSM key. And so all you have to do is
say, customer managed key. I’m going to select the key. And just to be faster, I’m going
to type in the actual key name. I do that. And it’s nice enough
to actually tell you that in order for this to work,
the service account associated with your instance of GCS
needs access to that key. And it will actually
do that for you. So I’m going to hit Grant. And so now I have
created this bucket. Whoops. Did I miss– oh,
I’ve already got two. AUDIENCE: [INAUDIBLE] IL-SUNG LEE: Oh, you’re right. You’re right. This always bugs me about this. I should go and talk to them. There you go. Yeah. So I’m just going
to upload a file. It’s going to be a stupid
file, like sample text. I think that if I
recall, this file, all it says is
that this is data. Let’s see. There you go. Test data for bucket. So now what I’m going
to do is I’m going to actually go to KMS now. And this key that we just
created, this HSM demo sym key, I’m going to go there. And you can see that– oops. I’m going to go
to the key itself. And you can see on the side here
that it lists the permissions. And sure enough,
you can see the fact that the service account for
GCS was already added there. That was done automatically. So I’m just going to
copy this, just so that I can add it later. And I’m going to delete it. And so I have now effectively
deleted this access. So what happens now? So what happens is that
now when I go back to GCS, and I try to go and
read any of the the data on that bucket,
first of all, GCS does its own permission
check and says, yeah, you guys are good. Now let me figure out
which data encryption keys I need to decrypt. And it’s going to
send that over to KMS. And then KMS is going
to go and see those keys and say that, OK, let me see if
you’re allowed to decrypt this. And it’s going to see that
you’re not allowed to do this. And it’s going to give
you access denied. Or at least that’s what
we hope will happen. It usually takes around a
minute or so for the changes to propagate. So you might have to try
this a couple of times. So let’s see if it
works right now. Yeah, it works. So we’ll give it a
few more seconds. AUDIENCE: Quick question. So you just created a DEK. Is there a KEK-DEK model
for this [INAUDIBLE]?? IL-SUNG LEE: So the question
was, I just created a DEK. Is there a DEK-KEK model. I actually didn’t create a DEK. I actually created a KEK. So it’s a data encryption key. It’s keys that actually
encrypt the base data. And then above that,
the second level key is a key encryption key. When you talk about customer
managed encryption keys, you’re always talking about
that second-level key encryption key. And so what happens is that in
a normal case, in a GCS bucket, you have the bucket
encrypted with local keys. And then it goes up
to the internal KMS. In the CMEK model, that
goes to Cloud KMS, instead. So when you need to
decrypt those keys, it actually goes and
contacts Cloud KMS and says, can you please use
this specified key to encrypt my data
encryption keys. AUDIENCE: So you just link
the KEK and then [INAUDIBLE] IL-SUNG LEE: Correct. So now if I do this, I
think it’s enough time, you get the permission
denied on Cloud KMS key. It’s really small. I’m sorry. But that’s what
it says up there. And people in the front
can attest to it, as well. Now basically I just proved
that it works the way it does. You now can you use
your keys to actually have some granularity
around control of your data. So now if you go
back to Cloud KMS and decide that we’re going
to re-add the permission, and we’ll give it back the
encrypter decrypter role, add that, then we
expect to see that this is going to work again. And sure enough, it works again. So it’s as simple as that. So this is not
really anything new if you’ve been using customer
managed encryption keys. But it’s just a quick
way of showing you that really nothing changes. You’ve just been able to use an
HSM key to secure your data out in GCS. And I’m looking at
the time right now, so we’re running out– I was going to do the
same thing with BigQuery, but it’s essentially
the same thing, as well. You can actually just use
BigQuery, associate it with the HSM key,
and then remove permissions and all of a
sudden, things start to break. OK. So going back to the slides. Now to summarize,
what we learned today is that you can actually
use some of the things that we provided now to
help meet your compliance objectives. Previously before, if
you came to us and said, do you have anything
that can help me satisfy the requirements for a
FIPS 104-2 level three device or three crypto manager,
then we didn’t have an answer. But we now can actually tell
you, please use Cloud HSM. The devices are
all FIPS validated. You can meet your security
requirements around the keys. If you have more
strict requirements around saying that I want
to make sure that there’s extra security around
some of the keys that I put in the cloud,
there’s an option for you. And also, because it’s a
fully managed service– and I like to stress this– you don’t have to
worry about a anything around your key management. Sorry. You only have to worry
about your key management, not around your HSM management. And finally, you can now
actually go and use it for a lot more things. You have that CA that you
want to move up to the cloud because you want it
close to your workload? Now you can do it. So it’s all possible for you. And with that, I
think we’re done. We have a couple of minutes
but I’d like to thank everyone. And if you have any
questions, please let me know. Yes. AUDIENCE: Are you
considering any encryption in transit [INAUDIBLE] IL-SUNG LEE: Yeah,
good question. So the question is
whether we’re were considering any use with
encryption transit certificates and such. So right now we don’t
have something like that. That is an area that
we’re interested in. But the answer is
right now none. Any other questions? Yes. AUDIENCE: [INAUDIBLE] IL-SUNG LEE: That’s
a tricky question. So the question is,
some 95% [INAUDIBLE] time frame but which
it moved to beta? You know, I’d love to tell you. But unfortunately,
I’m only allowed to say it’s coming soon. And so I’ll just
say coming soon. Yeah, I’m sorry. Yeah, all I’ll say is
keep watching our Google blog, or the G Suite blog. And just keep monitoring it. Hopefully you’ll be pleasantly
surprised sometime soon. Yes. AUDIENCE: Last question. IL-SUNG LEE: Yeah, please. AUDIENCE: Can you
set an account flag variable that will only allow
HSM keys, as opposed to KMS keys? IL-SUNG LEE: Good question. So can you set some
kind of variable that only permits you
to create the HSM keys? You will be able to do
this through IM conditions. So you can set a condition that
only authorizes you to actually create keys with certain flags. So this will be something that
you’ll be able to implement. Great. Well, thank you
very much, everyone. [APPLAUSE] [MUSIC PLAYING]

Add a Comment

Your email address will not be published. Required fields are marked *