Handling SGX verification non-terminal results

[imlk0]

During SGX verfication on some older hardware it may respond with SGX_QL_QV_RESULT_OUT_OF_DATE error, which is actually a non-terminal result, meaning that whether or not to trust is left to the user. We need to provide the user with this interface in librats to confirm that the error is exempted.

librats/verifiers/sgx-ecdsa/verify_evidence.c

Lines 276 to 284 in 5ac0f98

	case SGX_QL_QV_RESULT_CONFIG_NEEDED:
	case SGX_QL_QV_RESULT_OUT_OF_DATE:
	case SGX_QL_QV_RESULT_OUT_OF_DATE_CONFIG_NEEDED:
	case SGX_QL_QV_RESULT_SW_HARDENING_NEEDED:
	case SGX_QL_QV_RESULT_CONFIG_AND_SW_HARDENING_NEEDED:
	RATS_WARN("verification completed with Non-terminal result: %x\n",
	quote_verification_result);
	err = SGX_ECDSA_VERIFIER_ERR_CODE((int)quote_verification_result);
	break;

[JamesMenetrey]

Hello, Great idea!

To provide some thought material, I used librats on some not-that-old hardware, which returned SW_HARDENING_NEEDED. This was the expected result on that platform because that hardware is permanently affected by INTEL-SA-00334, even with the latest microcode updates.

Interestingly, this case should be considered a warning, as the developers have to _ evaluate the potential risk of an attack on these platforms and whether the attesting enclave employs adequate software hardening to mitigate the risk_.

This means that even though the attestation process may result in one of these cases, it should not be considered as an erroneous situation, but as you said, be left to the users to assess whether this must be regarded as ok or not.

Source of this issue: https://community.intel.com/t5/Intel-Software-Guard-Extensions/Receiving-ISV-Enclave-Trust-Status-as-Enclave-NOT-TRUSTED/m-p/1194130#M3844

Cheers

[imlk0]

Hello, Great idea!

To provide some thought material, I used librats on some not-that-old hardware, which returned SW_HARDENING_NEEDED. This was the expected result on that platform because that hardware is permanently affected by INTEL-SA-00334, even with the latest microcode updates.

Interestingly, this case should be considered a warning, as the developers have to _ evaluate the potential risk of an attack on these platforms and whether the attesting enclave employs adequate software hardening to mitigate the risk_.

This means that even though the attestation process may result in one of these cases, it should not be considered as an erroneous situation, but as you said, be left to the users to assess whether this must be regarded as ok or not.

Source of this issue: https://community.intel.com/t5/Intel-Software-Guard-Extensions/Receiving-ISV-Enclave-Trust-Status-as-Enclave-NOT-TRUSTED/m-p/1194130#M3844

Cheers

Thanks for your feedback, we are considering adding options to address this.