SGX attestation verification #195
Comments
cmickeyb
added
enhancement
|
Yes, and I agree. This must probably happen both in the pservice and pdo-tp. |
|
Changing this to an enhancement. Currently PDO TP encodes a specific "policy" while verifying attestation reports. The ask seems to be make the policy more robust (such as checking more of the fields of the attestation report, or etc.). @bvavala @g2flyer Could I please request to add details about what other fields on the attestation report make sense to be verified in the context of PDO? |
prakashngit
added
enhancement
|
If I understand, the concern is that the PDO TP does not currently check whether the enclave runs in SGX DEBUG mode or production mode. For protecting confidential data, it is expected to run SGX in production mode. We will assume that this is an enhancement to PDO to be supported by a future commit. This is consistent with our current assumptions that PDO is not meant for production use. |
|
I'm definitely fine with tabling the issue. Calling fixing a security project to ensure that it runs in secure mode an enhancement seems to me pretty euphemistic, so glad we removed the enhancement tag. |
…tion verification report is checked. Adding notes about the fact that currently we do not check whether the enclave runs in SGX debug mode or not. The corresponding issue can be found at hyperledger-labs#195 Signed-off-by: Prakash Narayana Moorthy <[email protected]>
…tion verification report is checked. Adding notes about the fact that currently we do not check whether the enclave runs in SGX debug mode or not. The corresponding issue can be found at hyperledger-labs#195 Signed-off-by: Prakash Narayana Moorthy <[email protected]>
…tion verification report is checked. Adding notes about the fact that currently we do not check whether the enclave runs in SGX debug mode or not. The corresponding issue can be found at #195 Signed-off-by: Prakash Narayana Moorthy <[email protected]>
We are not verifying - in pservice during secret provisioning and in eservice during enclave registration - all report fields for attestations, in particular we are not looking at the debug flag and (less crucially) the mode bit which has security implications:
SGX_FLAGS_DEBUG/0x0000000000000002ULLin the report's attribute) turned on would enable an adversarial host of an enclave to see all enclave data and change it's behavior. So in secure mode a verification of the attestation, e.g., at enclave registration, should ensure this bit is 0.SGX_FLAGS_MODE64BIT/0x0000000000000004ULLin the report's attribute) determines whether the enclave runs in 32-bit and 64-bit mode, correspondingly changing the semantics of a given measurement (MR_ENCLAVE). While tricky to achieve, it could be in theory to have code which runs in both 32-bit and 64-bit mode but exhibits completely different (and potentially adversarial) behavior. Hence to be on the safe side and as our code always is supposed to run only in 64-bit mode we should ensure that this flag is 1.The text was updated successfully, but these errors were encountered: