The PCE security checks are insufficient on a Flexible Launch Control system

[amluto]

The PCE code is, as far as I can tell, designed to reveal the PPID only to trusted, Intel-signed enclaves. The relevant code is:

https://github.com/intel/linux-sgx/blob/bf22963411f8cd1e8d01989eb9979e0b114871ff/psw/ae/pce/pce.cpp#L109-L111

This seems to be intended to go along with the corresponding code in the launch enclave:

https://github.com/intel/linux-sgx/blob/bf22963411f8cd1e8d01989eb9979e0b114871ff/psw/ae/le/launch_enclave.cpp#L221-L238

However, it's insecure on a Flexible Launch Control system, since there is no guarantee that an incoming report came from an enclave that was approved by an Intel-signed launch enclave.

One way to fix this wold be for pce.cpp to directly check the MRSIGNER of the report.

[bodzhang]

The PCE was designed to reveal the PPID to any enclave approved by the SGX Launch Control Policy Enforcer to access the PROVISION_KEY (privacy implication, as the enclave specific PROVISION_KEY, or the PPID, which is based on the PCE's PROVISION_KEY, can be considered a HW-based platform identifier that stays unchanged after SW/BIOS reset and SW re-installation). On non-FLC systems, Intel's Launch Enclave with a white listing policy is the SGX Launch Control Policy Enforcer, and it only approves specific Enclaves from Intel (the Provisioning and Quoting Enclave for EPID remote attestation scheme, signed by a specific Enclave Signing Key owned by Intel) to access the PROVISION_KEY. On FLC systems, the kernel owned Launch Enclave or the kernel itself can be the SGX Launch Control Policy Enforcer and decide which SGX enclave can access the PROVISION_KEY and PPID.

[amluto]

Are you sure that this design was intentional? I agree that the privacy concern is a bit dubious given that any running enclave with access to a PROVISION_KEY can identify the platform, but there seem to be users of SGX who think that the PPID is secret.

Also, if I look farther down the file, I see this code in the certify_enclave function:

https://github.com/intel/linux-sgx/blob/bf22963411f8cd1e8d01989eb9979e0b114871ff/psw/ae/pce/pce.cpp#L252-L255

it looks like, on an FLC system, the net effect is that the PCE can be induced to sign literally any message, which looks a lot like a trivial complete break of the attestation mechanism. Am I missing something?

[bodzhang]

Yes, depending on the SGX Launch Control Policy Enforcer to manage the privacy implication of PPID is the intended design of PCE. The comment line in the code cited only reflects the effect of the policy enforced by the Intel LE with white listing on non-FLC systems.

PCE is responsible to sign the enclave identity of the calling enclave (as long as the calling enclave can invoke the PCE interface, and for privacy implication, the PCE design makes sure only enclave approved to access PROVSION_KEY can invoke the PCE interface). Any SGX Remote Attestation scheme built upon the PCE infrastructure is supposed to check the identity of the calling enclave (typically, the Attestation Enclave(s), such as Intel's Provisioning Enclave for EPID-base remote attestation scheme), not just the evidence that PCE signed that data. The White Paper at https://software.intel.com/sites/default/files/managed/f1/b8/intel-sgx-support-for-third-party-attestation.pdf likely has more info on this topic.

[ghost]

I think what Andy is aiming is a situation where the entity implementing the RA scheme is an adversary e.g. a bot net controller or something like that. Not a situation where the entity is someone using SGX for something legit.

[amluto]

I think what Andy is aiming is a situation where the entity implementing the RA scheme is an adversary e.g. a bot net controller or something like that. Not a situation where the entity is someone using SGX for something legit.

That too, although I mostly just misunderstood the purpose of the code, and I misread the certify_enclave() function. The comment "//only PvE could use the interface which has flag SGX_FLAGS_PROVISION_KEY" is not particularly helpful. It sounds like the intent is that only the code in psw/ae/pve can pass the test, which is not the case.

[ghost]

OK, I've only read the whitepaper pointed out by Bo and https://software.intel.com/en-us/download/intel-sgx-intel-epid-provisioning-and-attestation-services. Did you find the place where the MRSIGNER is checked now that you've studied the code further, or?

[haitaohuang]

PCE does not check MRSIGNER of the calling enclave. See 3.1.1.1 in white paper pointed to by @bodzhang. PCE is not enforcing policy for access to PCK, rather it relies on LE selected by OS ( or Launch Control Policy Enforcer as termed above) for that purpose.

[amluto]

I think the point is that MRSIGNER is not checked by design. If I'm understanding the whole design correctly, Intel has a master list containing the root provisioning key for every CPU they've produced. [0]. The PCE is willing to sign quotes on behalf of any PROVISIONING-capable enclave, and the idea is that the launch policy will restrict the PROVISIONING attribute to users and enclaves that it wants to give this ability to.

[0] Somehow, Intel has or can produce the public key associated with the private key derived from each (CPUSVN, ISVSVN) tuple for the MRSIGNER=Intel PCE. Either they pre-generated them all, or they have the root provisioning key. I don't think I would have designed the system in the latter way, since leaking that list would allow attestations to be forged forever, and I don't think it's possible to recover without producing entirely new CPUs. I could imagine alternative protocols in which Intel merely possessed the ability to create an attestation certificate, or where there was a different proof that the enclave would submit to Intel such that Intel would be willing to create the certificate. But the latter might be hard to support with the current ISA.