[Cryptography] Hyper-V claims to protect tenant secrets ??

Henry Baker hbaker1 at pipeline.com
Fri Oct 2 10:25:25 EDT 2015


At 07:29 PM 10/1/2015, Jerry Leichter wrote:
>> Microsoft claims that it can protect tenant VM secrets with Hyper-V.
>> 
>> Doesn't this violate some non-obfuscatability theorem?
>
>No.
>
>> I was under the impression that the only truly *safe* way to do cloud
>> computing was via some reduction-to-circuits scheme, which is hopelessly slow.
>> 
>> BRK3457: Protecting Tenant Secrets in Hyper-V (80 minutes):
>> 
>> https://a248.e.akamai.net/f/248/3922/10/video.ch9.ms/sessions/ignite/2015/BRK3457.mp4
>
>You might want to watch the talk a bit before being snarky.  The basics are pretty simple and follow a familiar pattern:  The VM image is encrypted, and the key service will only hand a key to an attested-good hypervisor image running on attested-good hardware.  Of course, the attested-good hypervisor has to enforce an appropriate policy, e.g., not allow anyone to attach a debugger to the shielded VM.
>
>This is just virtualizing the notion of attested boots of trusted OS's.  At a very high level, nothing new to see here.  Actually making it happen takes tons of detailed work.

I watched the entire video, and no snark was intended.

It would appear that whichever cloud service utilizes this Microsoft technology has *literally* handed over the (encryption) keys to their kingdom to Microsoft, and the cloud service provider no longer *owns* and/or *controls* 'their'  cloud machines in any real sense.  This cloud service provider is merely providing real estate & electricity for his zombie Microsoftbot machines.

The acid test: can the cloud service provider -- no matter where located -- keep Microsoft from handing over cloud customer data to Microsoft itself or anyone that Microsoft designates -- e.g., FBI/NSA/GCHQ ?  No.

So while Microsoft itself may challenge DoJ in court re a Microsoft cloud machine in Ireland, any other cloud provider using this Microsoft technology is at the mercy of Microsoft receiving a secret NSL; Microsoft would have little standing to challenge such an NSL for some third-party cloud service.

The cloud customer, on the other hand, will trust this cloud service to the same extent that they trust Microsoft today.  For some customers, trusting Microsoft may be better than trusting cloud service provider A**z*n, but they still have to trust Microsoft.  In particular, both the cloud service provider and the cloud service customer must *trust Microsoft*, even for running non-Microsoft (e.g., Linux) code, because Microsoft has locked down the boot sequence on these machines.



More information about the cryptography mailing list