Extended EPID Group ID and Third Party Verifier

[He__Yi]

Hi!

I've read from other threads that the Extended EPID Group ID in SGX RA MSG0 is 0 for IAS, and can be other numbers for third party verifiers.

I sort of interpreted this in two ways:

(1) The extended EPID Group ID field means ISV companies or individuals can build their own server, manage their own revocation list, and provide attestation services to a sub-group of Intel CPUs that they own.

(2) The extended EPID Group ID field means that EPID is a technique that can be applied by other HW manufacturers, who would like to use this framework and manage their own circuits.

Could you help me figure out which understanding is correct?

I don't know if (1) is possible, especially the generation of revocation list seems to require the verifier to know much about a CPU's secret. If (1) is correct, is there any procedures required (e.g. subscription et. al) for a company/individual to actually manage their own attestation server?

Thanks a lot! 

[Scott_R_Intel]

Hi Yi.

Your #2 is correct.  For SGX and IAS, Extended EPID GID can only be zero.  And yes, only IAS knows/can generate the SigRL. From the developer reference:

"NOTE: Currently, the only valid extended Intel® EPID group ID is zero. The server should verify this value is zero. If the Intel® EPID group ID is not zero, the server aborts remote attestation."

For customers who do want to run their own attestation service, we have recently created and released our Data Center Attestation Primitives.  This is an ECDSA based attestation solution that "allows providers to build and deliver their own attestation service instead of using the remote attestation service provided by Intel."  For more info on DCAP/ECDSA, see the text and links in the "Attestation Based on Intel® SGX DCAP" section of this web page:  https://software.intel.com/en-us/sgx/attestation-services

Regards.

Scott

[Junli_S_Intel]

Scott is correct, If customers want to run their own attestation server, the best solution was to use Data Center Attestation Primitives.  And by the way, revocation list maybe not means that CPU's secret has been exposed: we have different revocation level: private key revocation list, signature-based revocation list, epid group based revocation list.... 

[He__Yi]

Thanks a lot, Junli and Scott!

My understanding of DCAP/ECDSA is that

(1) It is designed for the cases that the enclaves are unable to access the internet (so it caches the Intel Certified Provisioning Service, and run Attestation Services locally).

(2) Since the service is based on ECDSA, it will lose anonymity, and also, it will not have the ability and flexibility to revoke a signature, an attestation key or a group. the functionality of DCAP/ECDSA is indeed the definition of attestation, which means no fancy stuffs like revocation list, or verifying the security properties in SGX PSW are updated.

Q1: So my question regrading DCAP is that, since now the attestation service runs in local, does it put the third party attestation service provider in risk that they might be outdated in knowing Intel Attestation Service's revocation list? For example, it might miss a microcode update, or even worse, could it be possible that someday a serious bug is found on some CPU architecture, then Intel decide to put all those CPUs (that belong to the same GID) on revocation list. Meanwhile, the local DCAP/ECDSA service will not know this and still trust those outdated CPUs?

Q2: More importantly, I guess in my case the enclaves actually are able to connect to the internet. Just that I'm wondering if the users are able to contribute to the revocation list, e.g. if we find something can not be trusted, or we choose not to trust something, could that be somehow reflected in the revocation service? E.g. could it be something like, we create our own revocation list, then combine it with Intel's revocation list, to customize a special trust group... Or in your perspective, user might have better ways in doing that, instead of contributing to the revocation list?

(Personally I guess it might not be possible for users to create or add contents to EPID's revocation list. The creation of revocation list seems to require some knowledge of the secrets...)

Thanks again!