[HN Gopher] Toward Confidential Cloud Computing
___________________________________________________________________
Toward Confidential Cloud Computing
Author : hacksilver
Score : 37 points
Date : 2021-03-13 12:25 UTC (10 hours ago)
(HTM) web link (queue.acm.org)
(TXT) w3m dump (queue.acm.org)
| jnwatson wrote:
| Confidential computing is one of those "nerd snipes". It is
| really interesting from a technical challenges and academic
| research perspective.
|
| Practically, hyperjacking or compromise through the cloud
| provider is really low on the list of security issues.
| ENOTTY wrote:
| I think Confidential Computing undersells the idea of "Attested
| Computing". For example, when users send data into the cloud,
| remote attestation can give them some confidence that data will
| be used according to the terms of consent.
| doodlebugging wrote:
| Good paper so far but I wonder whether we got the final version
| of it.
|
| In the Confidential AI section we encounter ??? as if there is an
| incomplete thought or more to be added here.
|
| >The enclave may, for example, enforce differential privacy by
| limiting the number of times the model is queried and adding
| noise to their results. ????
|
| I thought this might be a one-off but I made it into the Key
| Management and Attestation Services section and found several
| more clustered.
|
| >The TEE may then use these credentials to access tenant data. It
| may, for example, present a token issued by the attestation
| service to obtain the current decryption key from an HSM. ????
|
| This one even has an incomplete sentence at the start.
|
| >Thus, the service can support precise, stateful policy
| statements of the form, ???This task must run within an SGX
| enclave, on an Intel SGX v2.1 platform, deployed in the German
| Azure data center, in a VM allocated to the tenant, supported by
| certificates that are valid as of today,??? rather than just,
| ???This task must run within an enclave.???
|
| Near the end in the Code Transparency discussion there is another
| case where perhaps they intended to phrase something differently.
|
| >The code transparency service can also be used to mitigate
| software supply chain?? attacks, because it provides auditable
| provenance and chain-of-custody for a software bill of materials
| (SBoM).
|
| There is a lot of great information in this paper about the
| direction that is currently being taken to build a system where
| cloud data can be reliably guaranteed to be encrypted and
| protected from unauthorized access using hardware and software
| tools. I am no expert on this but I do follow emerging trends and
| research just for the opportunity to learn outside my own
| discipline.
|
| I see in the biographies that most of the authors are associated
| with Microsoft. Perhaps the corrected version of this will come
| on the next Patch Tuesday? (LOL)
|
| That is not intended as a knock on Microsoft. I have used
| Microsoft OSes, software tools, and hardware (still use a Windows
| Phone in fact) since the mid-1980's when I was in college. When I
| saw Russinovich on the author list I knew that the quality of the
| work would be pretty high. I have a high level of trust in him
| and the tools that he has built over the years.
| JW_00000 wrote:
| I think the question marks are artifacts of converting the
| article to HTML. The PDF linked at the top doesn't have them,
| and in some places they correspond to "curly quotes".
| eqvinox wrote:
| > _At the lowest level of the stack, the hardware must be able to
| provide a TEE (trusted execution environment) that isolates the
| code and data of a given confidential workload from any other
| code running in a system--including code running at the highest
| privilege levels. [...] This in turn requires a hardware root of
| trust to hold the platform root secrets and signing keys, and a
| public-key infrastructure to endorse these keys. [...]_
|
| Uh... no... what "the hardware must be able to provide" is a
| platform that _I_ , the cloud user, trust. It's nice that the
| manufacturer installed some hardware key somewhere, but that just
| means the manufacturer can maybe trust this key. If the NSA or
| China wants my data, they'll just supply-chain-attack and replace
| whatever entity contains these keys with something else. The
| manufacturer might be able to determine that this replacement
| happened / trust is no longer established, but _I can 't_.
|
| And, unfortunately, supply chain attacks like this are exactly
| what we're seeing, e.g. https://arstechnica.com/tech-
| policy/2014/05/photos-of-an-nsa...
|
| NB: you don't even have to replace the TPM/Processor/... with an
| identical, tampered component. You just need something that
| behaves the same as far as I can see. It could be some huge-ass
| FPGA board programmed to emulate shit and I wouldn't be able to
| tell as long as they got the emulation right. After all I can't
| go physically inspect the server...
| bpye wrote:
| How would you know to trust the platform you are running on
| without some sort of hardware key and attestation? You need to
| be able to determine from your guest that you are running in
| this confidential environment rather than in some emulation,
| and I don't know of any other way to do this than attestation.
|
| Additionally we are not talking about separate TPMs today much
| of the time, rather there will be some environment on the same
| package or the same die as your AP providing this TEE so you
| cannot trivially intercept that bus.
| ENOTTY wrote:
| What features of a hardware platform would cause you to trust
| it?
| gruez wrote:
| >NB: you don't even have to replace the TPM/Processor/... with
| an identical, tampered component. You just need something that
| behaves the same as far as I can see. It could be some huge-ass
| FPGA board programmed to emulate shit and I wouldn't be able to
| tell as long as they got the emulation right.
|
| Getting the emulation right is nontrivial because you also need
| to extract the hardware key that's on the processor, otherwise
| remote attestation won't work.
|
| Also, there are plenty of use cases for confidential computing
| that don't involve hiding from the NSA. For instance, if you
| simply don't want amazon (or their workers/contractors) to see
| your data.
| throwawaysea wrote:
| We need not just confidential computing but censorship proof
| computing. I don't think the "cloud" is the model to grant either
| because it is centralized.
| bpye wrote:
| What do you mean by this? A cloud provider can always choose to
| not run a VM, how would we provide censorship proof compute?
___________________________________________________________________
(page generated 2021-03-13 23:03 UTC)