Confidentially Speaking

Hello, this is Anton and Tim from a new Cloud Security Podcast by Google. I'm involved with security product and solution strategy at Google. You can find me on Twitter as Anton_Chuvakin. Tim, on to you.

Hey folks, I'm a product manager here at Google and I look after wrangling our threat detection products. You can find me on Twitter @tmdpck. I had to go without vowels because there are enough other Tim Peacocks in the world.

And as a funny starting point, this was supposed to be called Weathering Cloud Security, but hey, we like descriptive names here. So now it's going to be officially called Cloud Security Podcast. Exciting, eh? This is our first episode, and our plan is to talk about cloud security both within and outside Google Cloud. We're going to invite interesting guests like Nelly today with a unique point of view on cloud security and securing the cloud. We expect to publish an episode every few weeks. Please let us know if you like this duration, about 25 minutes, and planned frequency. You can get this podcast at Google Podcasts or wherever else you get your podcasts. Tim?

We think you'll enjoy this podcast if you like thinking critically about trends in cloud compute, if you enjoy contrarian takes, And if you can tolerate the occasional pun slipped quietly into the mix. You will have the opportunity to hear from security experts inside and outside of Google on how they're tackling cloud security challenges, get stories about scars we've earned the hard way, and hear from teams that are building the next generation of tooling here at Google.

Perfect. And today our guest is Nellie Porter. She leads our confidential computing work here. Hey, Nellie, tell us more about yourself, and we also have some questions for you. Hopefully it'll be fun.

Thank you so much, Anton and team, for having me on your first podcast. I'm super honored. I'm Nelly Porter. I am Group Product Manager with Cloud Security team working on confidential computing. I have some experience with also hardware, firmware, and our hypervisor, so ready for the run.

So how about you tell us more about the origin for this idea doing confidential computing in the cloud?

Confidential computing, I think, was in crypto minds of so many people for many, many years. It started with the dreams, what if we would be able not only ingest data to the cloud encrypted and store this data fully encrypted? We don't want to create graveyards of this data, we want to Index it, query it, do something useful. What if it would be possible to process this data also protected? It's where confidential computing came to playing this 3rd step in this end-to-end data protection.

So it does sound like there's an origin story there. So I want to start from an obvious question that kind of makes sense for every security technology. What risks are mitigated by this new approach to computing?

So one of the risks and few things that's very important on confidential computing or considering confidential computing for public cloud is understanding that we all deal with a lot of sensitive data. And our customers need to entrust this sensitive data to cloud providers. Previously, it was super easy. Customers processed the data, collected this data, worked on it on-prem, and they knew who is accessing that, who is responsible for putting the plug and deal with any security incident. And it was very clear responsibility about who is protecting the client's data, the user's data, and their own data. Now times is changing and customers have themselves in all different places, on-premises, on edge, and on the cloud. So the whole world of who is responsible on this shared responsibility model is becoming very, very difficult. So confidential computing, trying to protect this data end-to-end, as I explained earlier, and it's what customers see as one of the risks of limiting visibility of cloud providers, and everybody else on their multi-tenant environments to ensure that their data end-to-end in the space and in the state that they expect it to be.

So when it comes to limiting visibility, are there places where we're not limiting visibility with this approach?

Oh yes, Tim. So imagine you encrypted your data on-premises and you hold the keys. Now you uploaded this data in, let's say, Google Storage bucket. Simple. And it's sitting there doing fantastically well. But now you need to do something with this data, as I said. Let's say you need to train your model on this data. Now you load this data in your environment and, oh gosh, now it's not protected. Now memory where your data resides is not encrypted. Now imagine that somebody maliciously or mistakenly crash your application. Oh my God, the dump has the whole secrets of your data flowing around. You absolutely don't want that. It's exactly what we're trying to do. We're trying to ensure that your data is always protected in whatever state it is, and less and less people have opportunity to make mistakes or maliciously expose your data.

Nelly, you said training models. A Google person would probably wanna do that on something like a TPU in the cloud. Are we planning to extend these kinds of memory protections to TPUs that we're building as well?

Absolutely, because not only customers are using CPUs where we started to see hardware catching up with the goals that we have, but also GPUs, TPUs, FPGAs, anything, we called it accelerators, have to understand and respect privacy and confidentiality of the data that they process. In our industry, we working with multiple industry vendors and companies in Confidential Computing Consortium that we formed together with Intel, Microsoft, and others to address these specific requirements, because Google alone would not be able to accomplish that. We need to ensure that all vendors GPU, CPU, all of that will follow this year.

Part of the trust model is that it's a third party's keys and hardware that we're exposing to a customer. How do we achieve that same kind of trust relationship with Google-developed hardware like our TPUs? Is there going to be an open industry standard on that?

We hope that it will happen and we will follow the same model that we have, for example, with Titans. So let me introduce you another model we first develop our secure silicon to address very specific security problems that were not possible before. So the whole world was trying to figure out how to deal with trusted platform modules, TPMs. But TPMs had significant problems. And the reason why? Because they were sidecars. They were sitting on the side, listening on what is happening, and postmortem decided if they need to take the action and stop machine or VM from booting or not. So we decided that it's not acceptable. It's why we come up with Titans, our designed silicon, to ensure that we can sit in between and making our decisions after we will see the first instruction, to ensure that we're doing something super obvious to everybody. Before execute, check the things that you trust to execute. So we've done that. Now Titan is OpenTitan, is the standard that we contributing to all industry. And I think with TPU and security of TPUs, it will become the same thing. But it's too early to say. We are still in early stages of this development.

Okay, that makes sense. And let me kind of turn it back to the question about gaps. So obviously, confidential compute covers many of the gaps in normal cloud computing, but are there any residual gaps, or are there any residual risks perhaps, Moreover, I would go out on a limb and say, are there new risks that are introduced by that approach? So for example, reduced visibility of data may mean some things are harder to monitor. Tell us more about what things really aren't fixed and what things are perhaps newly introduced.

The goal for us, do not introduce too much residual issues with confidential computing. And that's why, for example, we've done a lot of investigation of what was possible with confidential computing from CPU perspective, from hardware. Confidential computing based and built on top of hardware, and it's what we want to ensure that it continues as the case. And the early introduction of confidential computing capable hardware or CPUs required, for example, customers to rewrite their app or refactor it to more secure and less secure things. And a lot of customers understanding the value that confidential computing can bring to the table, but simply cannot afford or rewrite the application. It's why Google in particular, we decided to take a different approach and go with the models that incredibly easy to use, to ensure that our customers would not have those barriers to cross and to go through to be able to do that. So I think one of the biggest challenges that we still have to address How we will convince the industry and compliance regimes that confidential computing is helping in multiple fronts? Because it's very emerging, very new technology. And as usual, when it's new technology, it has so many questions, what it does and how it's actually exposed. Do we have gaps?

Absolutely.

There is no solution that will be the magic bullet that will make all of us happy. But it's additional tool in our toolbox of defense in depth that we have to take super seriously and invest as much as Google and Amazon and AWS are trying to do.

I think that's a really key point, Nelly, that there aren't magic bullets in security. And if you really want to secure a server, the best thing to do is unplug it, put it in a box of concrete, and throw it off the Golden Gate Bridge. That's really your only option to have something ultimately secure at the end of the day. So—

And ensure that nobody is flying and again, trying to get it out of there and bring it back.

Yes, you gotta make sure you drop it at night where nobody can see. So thinking ahead about where this is going, what kinds of organizations do you think this is an absolute must-have for? Like, who are you most excited to have be adopting this technology?

First, we're honestly targeting very regulated and compliancy heavy organizations. And no surprises, it's financial sector, fintech companies, very, very clear on the value of encryption, very clear on the value of processing memory protection, government, public sector, healthcare, all of that. What we didn't anticipate that multiple verticals that doesn't have significant regulation and compliance requirements are also very interested in this technology and mostly to anticipate privacy concerns with their tech for their clients and their users. So they see it as an additional way to create this cryptographic isolation in public cloud that will allow them to guarantee to their own clients and their own users that they're doing everything possible to protect the sensitive data. Also, one of the interesting use cases that we started to see, and in particular with COVID-related situations that we have right now, a lot of small research organizations trying to collaborate on super sensitive data. And prior to confidential computing, you cannot make it possible because you need to have ability to share your very sensitive datasets among multiple parties, ensures that none of them will have access to this data, But results will benefit all of them and us. And that's why confidential computing, we see significant uptake for this specific research and work that organizations are going with.

To kind of like return us briefly to the previous point we started making, I mean, admittedly, there's a pretty lively business in cloud computing. Companies spend billions with us, with the other cloud providers. So, Clearly, even those companies are using the cloud. So for the workloads you described today, before confidential computing is adopted en masse, what are the alternatives? Like, what are they migrating from? Is it all on-prem? Is it they just like accept the risks? Like, how are people solving the same problems today?

I think today, people simply hesitate to bring this capability to the cloud. And the problem is, they're collecting enormous amount of sensitive data on-prem, and to process this in the environment on-prem, they have to acquire more and more capacity, and it's incredibly costly and doesn't provide any value. And we see it even on government and on the financial sector, where you would believe the money is not a problem, but a lot of things is how you manage this capacity, how you deal with this growing hardware demand that is multiplying every single day. So, for them, using cloud is absolutely paramount, but the data that they have is so sensitive that they cannot use cloud. So, we see huge demand and opportunity to enable those customers to bring the most sensitive data to the cloud. But also, we see a lot of customers that say, I have no idea. My data is gray. It may be sensitive, it may be not super sensitive, but it's definitely not public. I want to bring it in the cloud and use your confidential environment to process it. So we see all combinations of that.

The last type of client just basically goes and says, what is the best available security for my data? And obviously confidential computing is that. And they say, okay, I'll pick this one, right? That's roughly the scenario you described.

Why not, Anton? It's exactly what they're saying. Now, exactly the question you asked me previously, Why not? Is there any downside for me to not use it? It's like I don't need to change anything, easy to use, it's performant, the performance is very, very negligible latency I need to pay for that, and it's scalable. I can do everything that I can do from running my databases to Memcached projects to even Monte Carlo simulation that I do for financial sector, All of that I can do in those confidential environments. Why not try, test your water, validate your performance? Right now we available in general availability across 9 regions, and we're looking for your feedback, our dear customers, to see what else we need to add and how we can bring more services to confidential and more breadth in, as Tim asked, our hardware support.

Given what you just said, no performance impact, broadly available, no work on the user, keeps the data encrypted, can you explain how it actually works?

Absolutely. I will try to make it very, very clear. So confidential computing that I'm talking about is based on CPU capability. We build it based on AMD new generation of their CPUs, where they have very, very important extension. It's called Secure Encrypted Virtualization Extension. And this extension means that in hardware firmware combination, AMD is capable to generate the greatest keys that you always wanted. Those keys are ephemeral per a single VM. They're never stored anywhere. And the most important thing, they're not extractable. Software doesn't have access to those keys. Those keys are only and only used by memory controllers very quickly to decrypt cache lines when you want to execute instruction on your CPU and encrypt them back. So in CPU itself, the data is decrypted, but your memory continues encrypted. And it means every application that's running within this boundary can do exactly what they've done before. You don't need to change anything. It's like the fish conference room that we have in Google, as you can remember prior to COVID, put shades on that. You continue, you can do whatever you need, but you will be in cryptographically isolated space and none of the strangers passing by can see.

You mentioned AMD, so this technology depends on a specific CPU choice, it seems like. Could you give us a bit more on why this CPU was chosen?

Intel, as CPUs that we also very familiar with, have their own take on confidential computing. It's called Secure Guard Extension or Intel SGX. As I mentioned previously, we had investigated and worked on these specific offerings from Intel for many years, but what we found, the complexity of moving to this world is actually going to be a problem for very many customers. Because to be able to have and use this specific Intel SGX, what is called enclave, customers would have to partition their app. It's why I think it's 2 years ago we introduced open source projects that we call the Silo to help developers to make this transition easily. But still, when I was talking to so many customers, Honestly, when I started to talk about refactoring their applications or workloads, you needed to see the look in the faces that were very obvious for me. That's not something that they are going to do right away. So it was super obvious to us that we need to find solution that doesn't require these changes. And AMD had the solution for us. That's why working with them in very good partnership. We were able to bring confidential computing for GCP in this method.

That change-free nature of this project, I think, is just so close to magic. It blows my mind, Nelly, that you and AMD have been able to achieve that for our users here. That's just too cool.

Thank you so much, Tim. Honestly, as I said, it's like work of hundreds and hundreds of people from multiple companies for multiple years, and we finished up with a single checkbox. After this checkbox will be checked, customers would be able to run the confidential environments. I think the single checkbox is culmination of so many people, so much creativity and investments. It's what we've done.

With that, I just want to say I think I look forward to the era of no checkbox and everything is this way by default. Nelly Porter, thank you so much for joining us today on the first episode of the GCP Security Podcast. So happy to have had you come join us today. Everyone listening, thank you for tuning in to the first episode. Again, you can expect to hear from myself and Anton every couple of weeks, podcast episodes of about this length available wherever your podcasts are distributed.

Thank you so much, everybody, and thank you, Tim and Anton, for having me on your first podcast.

Thank you.