> 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.
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...
>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.
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.
Being able to order two (with minimized overlap in order procedure) and comparing them to establish a baseline. Then installing my own keys into it before shipping them of to a hoster who puts them in a rack.
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.
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.
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”.
A few days ago, a post about Intel hardware accelerated homomorphic encryption might show a better way: if an OS is running but the server cannot know what’s running, then you no longer need to trust that hardware.
It’s trusted computing on untrusted hardware.
It’s similar to how you send encrypted TLD traffic over untrusted networks.
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.
This is simply not possible. Even if you could get enough radio line of sight p2p nodes online to bypass centralized fiber backbone providers, the government in charge of the land your towers are on can still shut you down. The only censorship free computing is purely locally networked. There are no global communication channels that can't be blocked.
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...