topic Re: DCAP/ECDSA and IAS in Intel® Software Guard Extensions (Intel® SGX)

Re: DCAP/ECDSA and IAS

ArminD — Thu, 28 Apr 2022 09:54:27 GMT

I actually have a related question, let me know if I should post it as a new question instead.

So, in the Commercial License table (https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/request-license.html) , the third row says that it is possible to have a third party Launch Approver but still use the Intel Attestation Service.

Do I understand it correctly, that this only works for processors which support both EPID attestattion and FLC (and due to FLC probably also ECDSA attestation)? My understanding is that "third party Launch Approver" means "Custom Launch Enclave" and thus "requires FLC".
Would this mean that I can swap out the Launch Enclave for a custom one, but keep the rest of the infrastructure the same (Intel provided aesmd, quoting enclave, provisioning enclave, ...) and continue to use EPID with the Intel Attestation Service, or would this require additional modifications? IIUC the launch enclave gets a whitelist from the aesmd (https://github.com/intel/linux-sgx/blob/e1a37bdc381672509e49e34885730437366194e4/psw/ae/ref_le/ref_le.edl#L47), so I guess one would either need to provide some dummy no-op implementation for this ecall (and do the actual work in another new ecall), or one cannot use it with the standard aesmd? The point is, I am asking how to implement this combination (FLC + EPID), as I only found that FLC is mentioned in combination with ECDSA.
I am also curious whether there is
- an actual use case behind this combination, or whether
- it is just listed in this table because it is technically possible due to how the building blocks are laid out but a reasonable SGX setup would not want to use it in practice (the point that FLC is mostly/only mentioned together with ECDSA/DCAP points to this one). As in "Well, technically you can do it, but don't do it."

Thanks again!

Re:Re: DCAP/ECDSA and IAS

JesusG_Intel — Fri, 29 Apr 2022 22:23:28 GMT

Hello ArminD,

Xeon Scalable processors do not and never will support EPID attestation so you cannot use IAS to attest Xeon Scalable processors.

Xeon E-series processors with FLC do support EPID so that row in the commercial licensing table applies to Xeon E-series processors, not Xeon Scalable. The Xeon E-series 2200 and 2300 processors support FLC/DCAP and EPID.

The launch enclave approver has nothing to do with attestation so messing with the launch enclave has no effect.

In Summary, if you have Xeon Scalable with FLC, you must use ECDSA attestation with a DCAP infrastructure. If you have a Xeon E-series processor with FLC, then you can use EPID attestation with IAS.

Sincerely,

Jesus G.

Intel Customer Support

Re: DCAP/ECDSA and IAS

ArminD — Tue, 03 May 2022 11:54:03 GMT

Hello JesusG_Intel,

thank you for your answer. I think I put my questions into the wrong context in the other thread, sorry for that. Right now our product uses classic EPID attestation on CPUs without FLC, but me and my team had to look at the broader attestation landscape. Currently we have not yet purchased a Xeon Scalable processor.

I struggle to formulate the question, as I am not really sure what it is that I don't know. The thing is, I (think that I) understand the classic EPID attestation on let's say my i5-6300U from 2017, we successfully used the classic EPID attestation with our commercial license - this covers the last row "Launch Approver=Intel & Attestation Model=Intel Attestation Service". And from the training material on DCAP (e.g. the five videos on the network builders page with the first being [1], and the documentation from [2]), I get the picture of how to realize/setup/implement the components required when I would go with the row "Launch Approver=Third Party & Attestation Model=Third Party" if I had a Scalable 3rd gen Xeon.
The question is probably, how to go the other two routes which are stated in that table: "Launch Approver=Intel & Attestation Model=Third Party" and "Launch Approver=Third Party & Attestation Model=Intel".

Now, you wrote that the "Launch Approver=Third Party & Attestation Model=Intel" row applies to the Xeon E-series, as it supports both EPID attestation and FLC. But does that mean that I should implement a custom Launch Enclave to make use of the "Launch Approver=Third Party" characteristics? (I understand that the Launch enclave does not influence to the attestation scheme.) Because if I just use the Intel provided pre-built Launch Enclave, then I think that I am actually in the "Launch Approver=Intel" scenario again, right? I just got the impression that if I modify the launch enclave, then I cannot make use of the other existing infrastructure (like the aesm service), so end up with having to use DCAP again to implement the infrastructure around my custom launch enclave, and as I understand it by using DCAP I also have to use ECDSA attestation (so I landed in the "Attestation Model=Third Party" scenario, having skipped over the "Launch Approver=Third Party & Attestation Model=Intel" row). I think that I haven't seen any material on how to reach the two mixed ThirdParty+Intel rows, or it maybe is that I actually don't fully understand what the "Launch Approver" column means (I read the description of "Launch Approver" on that page).

Do you understand my problem? If what I write sounds illogical, then maybe a first good step would be if you could tell me what sentences don't make sense.

Thank you for your patience,

Armin

[1] https://networkbuilders.intel.com/university/course/introduction-to-intelr-sgx-data-center-attestation-primitives-intelr-sgx-dcap
[2] https://download.01.org/intel-sgx/sgx-dcap/1.12.1/linux/docs/

Re:Re: DCAP/ECDSA and IAS

JesusG_Intel — Tue, 03 May 2022 22:20:15 GMT

Hello ArminD,

The "launch approver" is the entity that signs the Launch Enclave and sets the launch policy, which determines which enclaves can be loaded and which cannot. See this article for more information on Launch Control Policy Providers, Launch Enclave, and Flexible Launch Control.

You can find more detailed information in the Intel Software Development Manual, section 38.1.4 Intel® SGX Launch Control Configuration, page 4309.

To become a third-party launch approver, you must do three things on a server platform that supports FLC:

In BIOS, set the launch control to third party locked mode and manually enter the hash of the public key you use to sign the launch enclave, as described here.
Create your own Launch Enclave and sign it with your public key
Modify the DCAP driver so that it allows only your enclaves to launch.

Step 3 is the tough one since modifying the driver taints the kernel and you will have to maintain the driver. Most, if not all, people use the SGX DCAP driver built into Linux kernel 5.11 and above.

Remember that the launch approver has nothing to do with the method of attestation - ECDSA vs EPID.

I broke apart your questions and answered them individually...

Q: how to go the other two routes which are stated in that table:

"Launch Approver=Intel & Attestation Model=Third Party"
- A: Use DCAP with ECDSA attestation with Intel-provided packages, no modifications. Use processor with FLC support.
"Launch Approver=Third Party & Attestation Model=Intel".
- A: This will use EPID attestation. You can be your own launch approver as described above.

Q: But does that mean that I should implement a custom Launch Enclave to make use of the "Launch Approver=Third Party" characteristics?

A: You can theoretically implement a custom launch enclave but will have to maintain your own DCAP driver.

Q: Because if I just use the Intel provided pre-built Launch Enclave, then I think that I am actually in the "Launch Approver=Intel" scenario again, right?

A: Correct.

Q: I just got the impression that if I modify the launch enclave, then I cannot make use of the other existing infrastructure (like the aesm service)

A: Incorrect. The AESM will pick up your modified launch enclave as described here:

"Note: Building with ref-LE is replacing the standard LE in both the build process and also in the aesm_service, the aesm_service will load and configure only the ref-LE if the PSW is built with the flag BUILD_REF_LE=1. And the BUILD_REF_LE=1 is also building the LE shared object (ref_le.so), the ref-LE white list generation tool and a sample white list created with the tool and the test keys."

Q: so end up with having to use DCAP again to implement the infrastructure around my custom launch enclave, and as I understand it by using DCAP I also have to use ECDSA attestation (so I landed in the "Attestation Model=Third Party" scenario, having skipped over the "Launch Approver=Third Party & Attestation Model=Intel" row).

A: Incorrect. You can use your own launch enclave, which the AESM will pick up, and you can continue to use EPID. You can use either ECDSA or EPID with your own launch enclave.

Sincerely,

Jesus G.

Intel Customer Support

Re:Re: DCAP/ECDSA and IAS

JesusG_Intel — Mon, 09 May 2022 19:27:16 GMT

This thread has been marked as answered and Intel will no longer monitor this thread. If you want a response from Intel in a follow-up question, please open a new thread.