What is the remote user supposed to use/see?

[dimakuv]

This issue is for a: (mark with an x)

- [ ] bug report -> please search issues before submitting
- [ ] feature request
- [x] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

From the provided samples, it is unclear what the remote user (the user of MS Azure Confidential Compute VM) is supposed to use/see on her end. For example, I start my helloworld application on MS Azure in the SGX enclave from my laptop in Portland. What should run on my laptop? What should I receive on my laptop?

Do I receive the JSON file from the remote Azure VM, run validatequotes.core from my laptop, and receive JWT to my laptop? At which point I'm starting to trust the SGX enclave executing on the remote Azure VM?

[olkroshk]

Do I receive the JSON file from the remote Azure VM, run validatequotes.core from my laptop, and receive JWT to my laptop?

In these samples JSON files are used as a method of communication between executable retrieving quotes (genquotes_host) and application validating the quotes (validatequotes.core). Similar to the open enclave sample where the authors combine host1 and host2 "into one single host to eliminate the need for additional socket code logic to deal with communication between two hosts".

What should run on my laptop? What should I receive on my laptop?

The samples can be tested on a single host. For instance, it can be your laptop, if it has CPU supporting Intel SGX and runs Ubuntu 18.04, or you can create a Azure Confidential Computing (Virtual Machine) in MS Azure Portal, ssh into it, clone the repo and follow the instructions for Intel SDK based sample https://github.com/Azure-Samples/microsoft-azure-attestation/tree/master/intel.sdk.attest.sample#how-to-build-and-run or for OE SDK based sample https://github.com/Azure-Samples/microsoft-azure-attestation/tree/master/sgx.attest.sample#instructions-to-build-and-run-yourself

The validation part (validatequotes.core) can be tested separately (running on another host) by consuming JSON files generated by genquotes_host.

[olkroshk]

Adding @gkostal and @mssindhurid to add corrections or more information

[gkostal]

For instance, it can be your laptop, if it has CPU supporting Intel SGX

Intel SGX isn't sufficient for this example, which is demonstrating 3rd party attestation. Intel SGX with Flexible Launch Control is required for 3rd party attestation.

The SGX extensions for Linux documentation states:

NOTE: The above Intel(R) SGX driver requires Flexible Launch Control and Intel(R) AES New Instructions support.

The Intel announcement for 3rd party attestation services states that Flexible Launch Control is a hardware feature that's available on Intel Xeon E processors (a server CPU). I doubt your laptop is running such a CPU. You'll need to locate a machine or VM running on a supported Xeon E CPU. Azure Confidential Compute virtual machines meet this criteria.

I can attest (pardon the pun :-)) that the above is true -- I spent many hours a few months ago trying to get the genquotes_host application to run on my desktop machine in my office which has a recent Intel desktop SKU (i9 9900K) with SGX support. I failed because my CPU doesn't have Flexible Launch Control.

[dimakuv]

Sorry, my question was too vague.

My question is not about this particular sample, but about the actual envisioned workflow with Microsoft Azure Attestation service. As a user of the Confidential Computing VM, how do I/my applications actually use MAA? The whole premise of CC is to be able to verify the authenticity of the HW and my SGX enclave running on it. In a "classic" Intel SGX EPID workflow, this is achieved by the user receiving the SGX quote from the remote VM and manually validating it against the expected measurements and consulting the Intel's IAS web service.

What is the envisioned workflow with MAA and Microsoft Azure DCAP client? How do users gain trust in the remote VM and its enclaves?

[gkostal]

@mssindhurid would be the best source of information for your questions @dimakuv. Have you read through the public facing documentation for MAA here?

Strictly speaking, there is no requirement that MAA must be used for remote attestation scenarios. Some reasons that MAA may be included in remote attestation scenarios include:

• MAA transforms many diverse attestation technologies (e.g. Intel SGX, MSFT VBS enclaves, etc.) into a single JSON JWT claim format, allowing relying parties to make trust decisions based on a single simple format (i.e. JWT claims) instead of parsing/verifying a diverse set of attestation evidence.
• MAA can enforce authorization policy -- doing things like:
  • not issuing a JWT if deemed not appropriate for the circumstance
  • adding derived claims indicating results of policy orthogonal to the question "Is the hardware trusted?" -- for example, "Does the code running in the enclave represent a trusted build of SQL server?"
• MAA authorization is a single central location that an enterprise can use to define, enforce and audit authorization policy for all their remote attestation scenarios by ensuring all relying parties authorize via MAA JWT tokens.

[dimakuv]

Thank you @gkostal!

@mssindhurid Could you help with my questions on how MAA is envisioned to be used in remote-attestation scenarios? I am mainly concerned about Intel SGX and real-world usages.