
Why Confidential Computing Is a Game Changer - nellydpa
https://www.darkreading.com/cloud/why-confidential-computing-is-a-game-changer/a/d-id/1338510
======
theamk
A somewhat more technical explanation:
[https://cloud.google.com/blog/products/identity-
security/int...](https://cloud.google.com/blog/products/identity-
security/introducing-google-cloud-confidential-computing-with-confidential-
vms)

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.

~~~
lxgr
> 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.

~~~
Reelin
> 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)

The cloud provider can't lie to you (assuming you know how to check, anyway).
There are instructions available to your code to have the CPU perform
cryptographic attestation regarding its current state. These instructions
can't be emulated because they involve producing a cryptographic signature
using a private key embedded in the hardware (which chains back to a root of
trust for the hardware vendor).

Basically, you can ask the CPU running your code "are you in confidential
mode?" and it will respond in the affirmative with a cryptographic
verification that chains back to the hardware vendor. You do this _before_
loading the encryption keys for your super sekrit data store over the network.

~~~
lxgr
Ah, I wasn't aware that AMDs implementation already supported attestation in
addition to just memory encryption.

~~~
Reelin
I feel the need to disclaim that I have no actual experience using SEV. Also
it looks like the attestation protocol may have been broken by attacking the
PSP firmware? I have no idea what the current state of affairs is,
particularly regarding the claimed firmware downgrade vulnerability.

[https://arxiv.org/abs/1908.11680](https://arxiv.org/abs/1908.11680)

[https://berlin-crypto.github.io/event/amdsev.html](https://berlin-
crypto.github.io/event/amdsev.html)

------
motohagiography
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.

~~~
Metus
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
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).

------
gcommer
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
Does this solve a real problem? Such as, hardware owner leaking stuff from VMs
was an issue?

~~~
lxgr
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.

------
nurettin
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.

~~~
FridgeSeal
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
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).

------
RcouF1uZ4gsC
> 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
Look up remote attestation. Essentially it allows you to verify you are
talking to your code inside an enclave/encrypted VM.

~~~
darkwater
I'm reading about it here
[https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attes...](https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attestation)
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
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.

------
aspenmayer
But you don’t have to take my word for it.

[https://cloud.google.com/compute/confidential-
vm/docs/monito...](https://cloud.google.com/compute/confidential-
vm/docs/monitoring)

[https://confidentialcomputing.io](https://confidentialcomputing.io)

~~~
theamk
> 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

------
reportgunner
Eh why wouldn't it be a game changer.

------
russfink
Homomorphic computing is not mentioned...?

~~~
ackbar03
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
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
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.

------
brunoTbear
Nelly!

