Showing results for 
Search instead for 
Did you mean: 

Hardware for DCAP

Hi, how are you?
I'm planning to use DCAP to build a remote attestation platform.

So, I want to make sure which hardware supporting Remote Attestation with DCAP.
First of all, the CPU. It seems like only the Xeon E-21xx family have feature "SGX with SPS" and "new AES instruction". So I wonder if I should use the Xeon E-21xx family for Remote Attestation with DCAP.
Second is motherboard. Does motherboard have to have SPS feature to support FLC?

Third is the number of server to test Remote Attestation with DCAP. I wonder if I can perform Remote Attestation with DCAP on an application enclave which is on a virtual machine.

Tags (1)
0 Kudos
3 Replies

Hello Seung,

You do not need the new AES instructions for DCAP. If you require the new AES instructions for another reason then you can find the processors you can use at with this filter.

You do not need motherboard support for FLC. More information can be found in the article, An update on 3rd Party Attestation under the "What about Hardware?" heading.

Currenty, SGX virtualization only works with KVM and Xen Frameworks. Please click here for more information.




Hi @Garcia,

Thanks for your reply.

I mean that I want to build my own attestation verification service/ECDSA attestation.

In that case, don't i need to FLC supporting motherboard and processor that has new AES instruction features?

Super User

Good morning, I hope the week is going well for everyone.

I see there is another recent thread regarding third party attestation that has been started.  I will post reflections to that thread as well, as I anticipate all of this will get decidedly more confusing before this is all over.

The issue with respect to AES-NI instructions is actually moot.  I believe that hardware AES support has been in place since the release of the SandyBridge micro-architecture, so anything that is shipping with SGX hardware support is going to have hardware AES support as well.  To be clear though, hardware AES instructions are not a pre-requisite for building a third party attestation service.

If there is a desire, or business case, to build and support a third party attestation service you will want to have a hardware and firmware combination that supports Flexible Launch Control (FLC).  The only guarantees of that at this point are the Intel E3 Xeon platforms as well as the Pentium or Celeron NUC platforms that are based on the Gemini Lake SOC.  If you are spending money you will want to have a very direct conversation with your vendor regarding whether or not the hardware/firmware under consideration will support FLC.

The other issue for being concerned about FLC is that the Linux kernel driver for SGX, that is being proposed for mainline inclusion, will only work on FLC based hardware.  That driver will only have the option of being statically compiled into the kernel so if you have hardware that has locked launch control registers (non-FLC) that hardware will not be usable with Linux if that is your target platform.  So, without careful consideration to detail, it is possible to buy hardware that will not be useful in the long term.

From an ideological purity perspective, the decision to support only FLC hardware in the mainstream LInux kernel is understandable. There has not, however, been an intellectually honest discussion of the implications of that decision.  There are well documented security and privacy concerns with respect to having a completely unlocked platform.

We have been very active in these discussions.  If you search the Linux Kernel Mailing List (LKML) archives you will find the conversations we have had with respect to this issue.

The reason all of this becomes important, from a third party attestation perspective, is that without some notion of cryptographic launch control, the attestation will not be predicated on the notion of a hardware root of trust, which is largely the rationale for using SGX.  For example, in the proposed Linux driver, the root of trust is ultimately the discretionary access controls that are implemented on the driver device node by the operating system.

We proposed, in an SGX engineering meeting with Intel, what we believe would be an effective compromise.  This would involve allowing the lock state of the launch control registers to be a BIOS configurable option.  If the locked option is chosen an additional dialogue box would be available that allowed the hardware identity modulus values (launch control register values) to be specified.  This would seem to offer the best of both worlds and would prevent the accidental acquisition of platforms that would not be useful.

To be optimally useful the locked state of the launch control registers should also be made available as part of the platform attestation report.  That would allow a relying party to make a fully informed decision as to the security state of the remote platform.

In the meantime we are planning to try and assist the SGX community by releasing a driver overlay that implements some semblance of cryptographic launch control for the proposed driver.  This overlay allows the platform owner to configure lists of MRSIGNER values that are allowed to sign enclaves, implement launch enclaves or initialize enclaves that have the PROVISIONING bit set.  The platform owner has the option of 'locking' these lists which significantly decreases the security risk.  We also have work pending to allow TPM based verification of those lists which would provide some semblance of a hardware root of trust for SGX platforms using the proposed Linux driver.

Hopefully all of this is useful with respect to framing issues surrounding third party attestation and launch control.

The most fundamental takeaway is that if you are serious about working on this you will want to verify that you are purchasing a functional FLC hardware/firmware implementation.

If there is further interest in these issues we will keep this forum in the loop.

Have a good remainder of the week.

Dr. Greg