6 ms·

Why Confidential Computing Is a Game Changer

107 points by nellydpa 6y ago

russfink 6y ago
Homomorphic computing is not mentioned...?
- topspin 6y ago
  It's a product announcement by a Google employee and they're not selling homomorphic computing. They're selling a different product.
- ackbar03 6y ago
  Im not a cryptography expert but from what i've learnt about homomorphic encryption in my courses its nowhere close to being usable at reasonable speeds
  - Joker_vD 6y ago
    Yeah, turning 1 bit of plaintext into 20 MB of ciphertext kills any hope for "reasonable speed". I have a toy functional language implementation that has no built-in data structures whatsoever, and even it in the end represents a bit only as an 8-byte closure.
    - ssmiler 6y ago
      Maybe in batched HE schemes. In https://github.com/tfhe/tfhe https://github.com/tfhe/tfhe the ratio is much smaller, 2.5kB per plaintext bit.
- anonymousDan 6y ago
  This is actually practical for general workloads. Homomorphic encryption not so much (although there have been advances for machine learning inference recently)
- gumby 6y ago
  Several orders of magnitude slower. Run in in a Secure Enclave (like SGX) you run at full speed.
  - llarsson 6y ago
    Better speed, yes, but also, SGX has been broken in different ways and just a few days ago, Apple's secure enclave for phones was broken, too. These are extra obstacles along the way, but not insurmountable walls.
- ilaksh 6y ago
  Why would people downvote the most insightful comment? Surely it is on topic to mention the next level of protection? I believe that we need a new paradigm for voting in threads because people are consistently using it poorly.
brunoTbear 6y ago
Nelly!
RcouF1uZ4gsC 6y ago
> Under the hood, Confidential Computing environments keep data encrypted in memory, and elsewhere outside the CPU. Data is decrypted within the CPU boundary by memory controllers using embedded hardware keys that a cloud provider does not have access to. I don’t know how much that buys you. If the threat model is that the cloud provider cannot be trusted, can’t the cloud provider just run your software on a machine that did not encrypt memory. After all they control the machines and schedule what code runs on the machines. How could you even detect an attack like that? EDIT: Unless you are using some theoretically secure system such as fully homomorphic encryption, if the organization that physically controls the machine your code runs on wants to compromise you, they can.
- anonymousDan 6y ago
  Look up remote attestation. Essentially it allows you to verify you are talking to your code inside an enclave/encrypted VM.
  - darkwater 6y ago
    I'm reading about it here https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attestation https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attes... but maybe it's not the best link. From what I understand from Wikipedia, remote attestation works in the scenario in which you are the producer of the TCP enclave, or trust it. And you can know that the software running in there is that specific copy, not a tampered one. But in this case I think OP was claiming that the google checkbox/dmesg message could be just fake/placeholders and you would not know (unless you can really inspect the internals). Am I getting something wrong?
    - gcommer 6y ago
      If you trust the CPU vendor to not be colluding with your cloud provider, and that the cloud provider hasn't found and exploited a hardware or software vulnerability in the enclave, then a successful remote attestation is a cryptographic proof that you are executing your code unmodified without the cloud provider being able to see either your code or (with careful delivery) your data. There are additional side channel concerns such as RAM bus sniffing; it looks like the EPYC processors handle that by encrypting all memory accesses. Additional concerns include memory access patterns and power usage monitoring; I don't see these mentioned in any of AMD's SEV whitepapers but they can (with great care) be mitigated in your software. Disclaimer: I work for Google but nowhere remotely related to this (I know only publicly available information about this product); I happened to do very similar research work 6 years ago in grad school.
theamk 6y ago
A somewhat more technical explanation: https://cloud.google.com/blog/products/identity-security/introducing-google-cloud-confidential-computing-with-confidential-vms https://cloud.google.com/blog/products/identity-security/int... This using a feature in AMD processors which protects one VM from another, by encrypting memory with VM-specific key. I think the idea is that even if hypervisor is compromised, there is no way to access running data of the machine. From the practical standpoint, you still have to trust Google's infrastructure. Here is a key quote: > all GCP workloads you run in VMs today can run as a Confidential VM. One checkbox—it’s that simple. The video confirms it -- you click on the checkbox while creating VM, it starts as usual, you ssh into it as usual, the only sign that you are protected is a line in dmesg output. So there is nothing "game changing" about this -- your threat model is mostly the same, but your attack surface is slightly reduced. The biggest threats (misconfigurations and network attacks on vulnerable software) are still there, and are not changed in any way at all. And you have to keep absolutely trusting your cloud provider, too. It looks like the main point of this whole project is to satisfy government regulators, big bosses, security consultants and to check boxes on security evaluation worksheets.
- anonymousDan 6y ago
  No you don't. Look up remote attestation.
- lxgr 6y ago
  > So there is nothing "game changing" about this -- your threat model is mostly the same, but your attack surface is slightly reduced. If done correctly (using attestation, as mentioned here already), this can reduce the attack surface significantly. Right now, you need to both trust your cloud provider to not introduce backdoors for themselves or some government _and_ to keep doing so until the end of your business relationship with them. Ideally, with trusted/confidential computing, you only need to trust the vendor to initially do as they say and not outright lie to you (e.g. by making the checkbox a no-op). In many ways, this would protect a cloud provider from themselves. Of course, with the current implementation non-successes like Intel's SGX, one could argue that this is merely kicking the can of trust down the road to the hardware vendor, but as far as I understand it, this is not an inherent flaw of the idea of trusted computing but rather a specific implementation.
aspenmayer 6y ago
But you don’t have to take my word for it. https://cloud.google.com/compute/confidential-vm/docs/monitoring https://cloud.google.com/compute/confidential-vm/docs/monito... https://confidentialcomputing.io https://confidentialcomputing.io
- theamk 6y ago
  > Firmware that is signed and verified by Google's Certificate Authority establishes the root of trust for Secure Boot, which verifies your VM's identity and checks that it is part of your specified project and region. What was the threat model again, could you remind me? /s
gcommer 6y ago
tl;dr of confidential computing: In normal cloud computing you are effectively trusting the cloud provider not to look at or modify your code and data. Confidential computing uses built in CPU features to prevent anyone from seeing what is going on in (a few cores of) the CPU (and in EPYC's case, encrypt all RAM accesses). Very roughly: These CPU mechanisms include the ability to provide a digital signature of the current state of the CPU and memory, signed by private keys baked into the CPU by the manufacturer. The CPU only emits this signature when in the special "secure mode", so if you receive the signature and validate it you know the exact state of the machine being run by the CPU in secure mode. You can, for example: start a minimal bootloader, remotely validate it is running securely, and only then send it a key over the network to decrypt your proprietary code. Effectively, it increases your trust in the cloud from P(cloud provider is screwing me over) to P((cloud provider AND CPU manufacturer are both working together to screw me over) ∪ (cloud provider has found and is exploiting a vulnerability in the CPU)). Disclaimer: I work for Google but nowhere remotely related to this (I know only publicly available information about this product); I happened to do very similar research work 6 years ago in grad school.
- rini17 6y ago
  Does this solve a real problem? Such as, hardware owner leaking stuff from VMs was an issue?
  - Reelin 6y ago
    You can't prove they don't spy on you for their own gain (financial or otherwise). A single rogue employee with physical access is all that's necessary otherwise. There are also plenty of small cut rate cloud providers out there without much in the way of reputation.
  - lxgr 6y ago
    The hypothetical possibility is enough to be a very real problem if decision makers perceive it to be. And unlike facetious data locality laws that equate physical location with logical control, confidential/trusted computing might actually be able to address their (in my opinion not unfounded) concerns.
reportgunner 6y ago
Eh why wouldn't it be a game changer.
nurettin 6y ago
Hardware based confidential computing is one thing. What we are kind of missing is encryption on the database layer where indexes are computed in a way where you can have fine grained control over who accesses which row. I am imagining a certificate chain based database index where you can't select data that your certificates (roles) don't allow and that is done quickly on the database layer so not even the admin can gain access.
- decisionSniper 6y ago
  The NSA's been working on something similar for years, cell-level security. Gotta have some way to compartmentalize the data I guess. https://en.wikipedia.org/wiki/Apache_Accumulo https://en.wikipedia.org/wiki/Apache_Accumulo
- FridgeSeal 6y ago
  I was thinking about just this thing recently, although more from a search perspective: notably, how do I build a full text search index where different users can see different amounts of the documents, ideally without storing multiple copies of the documents. I’m convinced there’s some clever data structures that might allow this to happen, but I haven’t found them yet.
  - hansvm 6y ago
    Without any additional constraints (e.g. that users/documents are clustered, that each user only has access to a small or large subset of documents, etc...) there aren't any great solutions. No matter the data structure, with n documents and m users you need on average at least nm bits in addition to the space to store the documents. Document insertion is at least an O(m) operation, and user insertion is at least an O(n) operation (for any fixed data structure on average across all possible user-document mappings of that size).
motohagiography 6y ago
This is important because tech is pervasive enough that it's just not reasonable to trust other people to manage cleartext data on our behalf anymore. You wouldn't believe the fights I've been in over encrypting databases where the resistance was because it would cut out the unofficial privileged access and impunity the DBAs and their managers had to the business data. The ability to look up someone's personal information in a data lake of millions of people is socially elevating and there are platform companies where snooping isn't a bug it's a perk of the job. Part of the reality of living in an increasingly lower trust society is that we need new tech to limit the power of strangers who manage our data. While the game changing aspect of this isn't instantaneous, if you aren't using one in 5 years you will likely have to assert why you aren't using a confidentiality system, and ideally within 10 there will be penalties for exploiting it.
- dastbe 6y ago
  sadly, confidential computing isn’t the answer to your desire. what they are iterating on here is the trust boundaries between your company and your infrastructure provider as well as your peers sharing the hardware.
- Metus 6y ago
  Could you use something like confidential computing to attest over http(s) what software is actually running on the server? This would offer a very interesting trust model together with reproducible builds, where you could have the CPU attest over http(s) that it is indeed the code base published on Github/Gitlab that is actually running on the server and receiving your data.
  - theamk 6y ago
    You'd have to attest a lot of things to get this to work. Who else has the access to the database? Are there backups -- and how are they protected? Are you sure the server's private SSL key is not shared with other, non-attested servers? Are there any unsafe CDNs that are used? You can kinda make it work with things like Protonmail which have heavy client-side encryption -- but this approach severely limits available features (for example, in Protonmail, you cannot search in message text).
mitchtbaum 6y ago
Google is The Source to Trust. (abcMT)aking all human-computing has with a passion you need to see, I will show you this. Believe. God Is Great. God Is Good. Let Us Thank Her for This Tool. By Her Hand We All Are Fed. One Cup
deleted 6y ago
[deleted]

107 points by nellydpa 6y ago

russfink 6y ago

Homomorphic computing is not mentioned...?

topspin 6y ago
It's a product announcement by a Google employee and they're not selling homomorphic computing. They're selling a different product.
ackbar03 6y ago
Im not a cryptography expert but from what i've learnt about homomorphic encryption in my courses its nowhere close to being usable at reasonable speeds
- Joker_vD 6y ago
  Yeah, turning 1 bit of plaintext into 20 MB of ciphertext kills any hope for "reasonable speed". I have a toy functional language implementation that has no built-in data structures whatsoever, and even it in the end represents a bit only as an 8-byte closure.
  - ssmiler 6y ago
    Maybe in batched HE schemes. In https://github.com/tfhe/tfhe https://github.com/tfhe/tfhe the ratio is much smaller, 2.5kB per plaintext bit.
anonymousDan 6y ago
This is actually practical for general workloads. Homomorphic encryption not so much (although there have been advances for machine learning inference recently)
gumby 6y ago
Several orders of magnitude slower. Run in in a Secure Enclave (like SGX) you run at full speed.
- llarsson 6y ago
  Better speed, yes, but also, SGX has been broken in different ways and just a few days ago, Apple's secure enclave for phones was broken, too. These are extra obstacles along the way, but not insurmountable walls.
ilaksh 6y ago
Why would people downvote the most insightful comment? Surely it is on topic to mention the next level of protection? I believe that we need a new paradigm for voting in threads because people are consistently using it poorly.

brunoTbear 6y ago

Nelly!

RcouF1uZ4gsC 6y ago

> Under the hood, Confidential Computing environments keep data encrypted in memory, and elsewhere outside the CPU. Data is decrypted within the CPU boundary by memory controllers using embedded hardware keys that a cloud provider does not have access to. I don’t know how much that buys you. If the threat model is that the cloud provider cannot be trusted, can’t the cloud provider just run your software on a machine that did not encrypt memory. After all they control the machines and schedule what code runs on the machines. How could you even detect an attack like that? EDIT: Unless you are using some theoretically secure system such as fully homomorphic encryption, if the organization that physically controls the machine your code runs on wants to compromise you, they can.

anonymousDan 6y ago
Look up remote attestation. Essentially it allows you to verify you are talking to your code inside an enclave/encrypted VM.
- darkwater 6y ago
  I'm reading about it here https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attestation https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attes... but maybe it's not the best link. From what I understand from Wikipedia, remote attestation works in the scenario in which you are the producer of the TCP enclave, or trust it. And you can know that the software running in there is that specific copy, not a tampered one. But in this case I think OP was claiming that the google checkbox/dmesg message could be just fake/placeholders and you would not know (unless you can really inspect the internals). Am I getting something wrong?
  - gcommer 6y ago
    If you trust the CPU vendor to not be colluding with your cloud provider, and that the cloud provider hasn't found and exploited a hardware or software vulnerability in the enclave, then a successful remote attestation is a cryptographic proof that you are executing your code unmodified without the cloud provider being able to see either your code or (with careful delivery) your data. There are additional side channel concerns such as RAM bus sniffing; it looks like the EPYC processors handle that by encrypting all memory accesses. Additional concerns include memory access patterns and power usage monitoring; I don't see these mentioned in any of AMD's SEV whitepapers but they can (with great care) be mitigated in your software. Disclaimer: I work for Google but nowhere remotely related to this (I know only publicly available information about this product); I happened to do very similar research work 6 years ago in grad school.

theamk 6y ago

A somewhat more technical explanation: https://cloud.google.com/blog/products/identity-security/introducing-google-cloud-confidential-computing-with-confidential-vms https://cloud.google.com/blog/products/identity-security/int... This using a feature in AMD processors which protects one VM from another, by encrypting memory with VM-specific key. I think the idea is that even if hypervisor is compromised, there is no way to access running data of the machine. From the practical standpoint, you still have to trust Google's infrastructure. Here is a key quote: > all GCP workloads you run in VMs today can run as a Confidential VM. One checkbox—it’s that simple. The video confirms it -- you click on the checkbox while creating VM, it starts as usual, you ssh into it as usual, the only sign that you are protected is a line in dmesg output. So there is nothing "game changing" about this -- your threat model is mostly the same, but your attack surface is slightly reduced. The biggest threats (misconfigurations and network attacks on vulnerable software) are still there, and are not changed in any way at all. And you have to keep absolutely trusting your cloud provider, too. It looks like the main point of this whole project is to satisfy government regulators, big bosses, security consultants and to check boxes on security evaluation worksheets.

anonymousDan 6y ago
No you don't. Look up remote attestation.
lxgr 6y ago
> So there is nothing "game changing" about this -- your threat model is mostly the same, but your attack surface is slightly reduced. If done correctly (using attestation, as mentioned here already), this can reduce the attack surface significantly. Right now, you need to both trust your cloud provider to not introduce backdoors for themselves or some government _and_ to keep doing so until the end of your business relationship with them. Ideally, with trusted/confidential computing, you only need to trust the vendor to initially do as they say and not outright lie to you (e.g. by making the checkbox a no-op). In many ways, this would protect a cloud provider from themselves. Of course, with the current implementation non-successes like Intel's SGX, one could argue that this is merely kicking the can of trust down the road to the hardware vendor, but as far as I understand it, this is not an inherent flaw of the idea of trusted computing but rather a specific implementation.

aspenmayer 6y ago

But you don’t have to take my word for it. https://cloud.google.com/compute/confidential-vm/docs/monitoring https://cloud.google.com/compute/confidential-vm/docs/monito... https://confidentialcomputing.io https://confidentialcomputing.io

theamk 6y ago
> Firmware that is signed and verified by Google's Certificate Authority establishes the root of trust for Secure Boot, which verifies your VM's identity and checks that it is part of your specified project and region. What was the threat model again, could you remind me? /s

gcommer 6y ago

tl;dr of confidential computing: In normal cloud computing you are effectively trusting the cloud provider not to look at or modify your code and data. Confidential computing uses built in CPU features to prevent anyone from seeing what is going on in (a few cores of) the CPU (and in EPYC's case, encrypt all RAM accesses). Very roughly: These CPU mechanisms include the ability to provide a digital signature of the current state of the CPU and memory, signed by private keys baked into the CPU by the manufacturer. The CPU only emits this signature when in the special "secure mode", so if you receive the signature and validate it you know the exact state of the machine being run by the CPU in secure mode. You can, for example: start a minimal bootloader, remotely validate it is running securely, and only then send it a key over the network to decrypt your proprietary code. Effectively, it increases your trust in the cloud from P(cloud provider is screwing me over) to P((cloud provider AND CPU manufacturer are both working together to screw me over) ∪ (cloud provider has found and is exploiting a vulnerability in the CPU)). Disclaimer: I work for Google but nowhere remotely related to this (I know only publicly available information about this product); I happened to do very similar research work 6 years ago in grad school.

rini17 6y ago
Does this solve a real problem? Such as, hardware owner leaking stuff from VMs was an issue?
- Reelin 6y ago
  You can't prove they don't spy on you for their own gain (financial or otherwise). A single rogue employee with physical access is all that's necessary otherwise. There are also plenty of small cut rate cloud providers out there without much in the way of reputation.
- lxgr 6y ago
  The hypothetical possibility is enough to be a very real problem if decision makers perceive it to be. And unlike facetious data locality laws that equate physical location with logical control, confidential/trusted computing might actually be able to address their (in my opinion not unfounded) concerns.

reportgunner 6y ago

Eh why wouldn't it be a game changer.

nurettin 6y ago

Hardware based confidential computing is one thing. What we are kind of missing is encryption on the database layer where indexes are computed in a way where you can have fine grained control over who accesses which row. I am imagining a certificate chain based database index where you can't select data that your certificates (roles) don't allow and that is done quickly on the database layer so not even the admin can gain access.

decisionSniper 6y ago
The NSA's been working on something similar for years, cell-level security. Gotta have some way to compartmentalize the data I guess. https://en.wikipedia.org/wiki/Apache_Accumulo https://en.wikipedia.org/wiki/Apache_Accumulo
FridgeSeal 6y ago
I was thinking about just this thing recently, although more from a search perspective: notably, how do I build a full text search index where different users can see different amounts of the documents, ideally without storing multiple copies of the documents. I’m convinced there’s some clever data structures that might allow this to happen, but I haven’t found them yet.
- hansvm 6y ago
  Without any additional constraints (e.g. that users/documents are clustered, that each user only has access to a small or large subset of documents, etc...) there aren't any great solutions. No matter the data structure, with n documents and m users you need on average at least nm bits in addition to the space to store the documents. Document insertion is at least an O(m) operation, and user insertion is at least an O(n) operation (for any fixed data structure on average across all possible user-document mappings of that size).

motohagiography 6y ago

This is important because tech is pervasive enough that it's just not reasonable to trust other people to manage cleartext data on our behalf anymore. You wouldn't believe the fights I've been in over encrypting databases where the resistance was because it would cut out the unofficial privileged access and impunity the DBAs and their managers had to the business data. The ability to look up someone's personal information in a data lake of millions of people is socially elevating and there are platform companies where snooping isn't a bug it's a perk of the job. Part of the reality of living in an increasingly lower trust society is that we need new tech to limit the power of strangers who manage our data. While the game changing aspect of this isn't instantaneous, if you aren't using one in 5 years you will likely have to assert why you aren't using a confidentiality system, and ideally within 10 there will be penalties for exploiting it.

dastbe 6y ago
sadly, confidential computing isn’t the answer to your desire. what they are iterating on here is the trust boundaries between your company and your infrastructure provider as well as your peers sharing the hardware.
Metus 6y ago
Could you use something like confidential computing to attest over http(s) what software is actually running on the server? This would offer a very interesting trust model together with reproducible builds, where you could have the CPU attest over http(s) that it is indeed the code base published on Github/Gitlab that is actually running on the server and receiving your data.
- theamk 6y ago
  You'd have to attest a lot of things to get this to work. Who else has the access to the database? Are there backups -- and how are they protected? Are you sure the server's private SSL key is not shared with other, non-attested servers? Are there any unsafe CDNs that are used? You can kinda make it work with things like Protonmail which have heavy client-side encryption -- but this approach severely limits available features (for example, in Protonmail, you cannot search in message text).

mitchtbaum 6y ago

Google is The Source to Trust. (abcMT)aking all human-computing has with a passion you need to see, I will show you this. Believe. God Is Great. God Is Good. Let Us Thank Her for This Tool. By Her Hand We All Are Fed. One Cup

deleted 6y ago

[deleted]