Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
amluto opened this issue Nov 26, 2018 · 8 comments

Comments

Projects
None yet
4 participants
@amluto
Copy link

commented Nov 26, 2018

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:

if((report->body.attributes.flags & SGX_FLAGS_PROVISION_KEY) != SGX_FLAGS_PROVISION_KEY){
return PCE_INVALID_PRIVILEGE;
}

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

// Only Provision Enclave is allowed to be EINITed with the privilege
// to access the PROVISIONKEY, which is signed with fixed signing key
if((se_attributes->flags & SGX_FLAGS_PROVISION_KEY))
{
for(i = 0; i < (sizeof(G_SERVICE_ENCLAVE_MRSIGNER) / sizeof(G_SERVICE_ENCLAVE_MRSIGNER[0]));
i++)
{
if(0 == memcmp(&G_SERVICE_ENCLAVE_MRSIGNER[i], mrsigner,
sizeof(G_SERVICE_ENCLAVE_MRSIGNER[0])))
{
break;
}
}
if(i == sizeof(G_SERVICE_ENCLAVE_MRSIGNER) / sizeof(G_SERVICE_ENCLAVE_MRSIGNER[0]))
{
return LE_INVALID_ATTRIBUTE;
}
}

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

This comment has been minimized.

Copy link

commented Nov 26, 2018

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

This comment has been minimized.

Copy link
Author

commented Nov 26, 2018

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:

//only PvE could use the interface which has flag SGX_FLAGS_PROVISION_KEY
if((report->body.attributes.flags & SGX_FLAGS_PROVISION_KEY) != SGX_FLAGS_PROVISION_KEY){
return PCE_INVALID_PRIVILEGE;
}

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

This comment has been minimized.

Copy link

commented Nov 26, 2018

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.

@jsakkine-intel

This comment has been minimized.

Copy link
Contributor

commented Nov 26, 2018

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

This comment has been minimized.

Copy link
Author

commented Nov 27, 2018

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.

@jsakkine-intel

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2018

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

This comment has been minimized.

Copy link
Author

commented Nov 28, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.