opensgx
opensgx copied to clipboard
Remote Attestation Implemented Incorrectly
I was implementing secret provisioning on top of the remote attestation code provided. I have found the following issues in the code:
- You are attempting to sign a SHA-256 digest with a 128-bit RSA key in the quoting enclave. RSA cannot be used to sign data larger in size than the key. Fixing this would involve either using SHA-1 (not recommended) or using larger RSA keys.
- As per the Intel SGX spec, the signature is stored in place of the mac in the report structure. However, you declared that as a 16-byte buffer this is smaller in size than 256-bits required for the signature (assuming an RSA key of 256-bits). I fixed this by utilizing a second structure that I called
quote_t
because I found a few instances where the size ofreport_t
is hard coded . This also allowed me to specify a larger signature size that can be used with an RSA-2048 key. Bear in mind that RSA-128 is trivial to break. - The calls being made to
rsa_sign
andrsa_verify
specifydata_len = 0
which is only allowed when you define the type of the md used as input to the function. However, you are not doing so and as a result the signature is being generated over a buffer of size 0 and verified over a buffer of size 0. If you check polarSSL's source code, this returns success without carrying out any computation. I would suggest defining the type of message digest instead of using thearbitrary_data
flag. - Finally, this is more of a gripe I have with your implementation than an actual issue, however, the quoting enclave, according to Intel's spec, has a known public key. This indicates that the keys in use are not ephemeral. However, you are generating RSA keys on every execution of the attestation process. I may have missed something while reading the spec, but if not, I think that utilizing a pre-computed key will make the attestation execute faster on QEMU and also adhere more to the original spec.
N.B.: I can generate a pull request if you wish with the modifications I outlined but it will contain the provisioning code as it is intermingled in the remote attestation process.