Intel® Software Guard Extensions (Intel® SGX)
Discussion board focused on hardware-based isolation and memory encryption to provide extended code protection in solutions.

Leaking Attestation Verification Report

Rosłaniec__Piotr1
865 Views

Hi,

I have a question about the security of the Attestation Verification Report, as described in IAS API docs:

Does the attestation report, or any part thereof, contain sensitive data? I.e. data that, once shared outside RA context/parties could serve to create an attack vector or otherwise compromise the integrity of RA. Are there any security guidelines specifically related to handling attestation reports from IAS?

Best regards,

Piotr R.

0 Kudos
1 Solution
Dr__Greg
Super User
865 Views

Good afternoon, I hope everyone is having a pleasant weekend.

I had been meaning to reply to this thread but was blocked by the need to get a code drop supervised and delivered.  The coronavirus has slowed up our work in the Far East so I'm taking advantage of some slack time to catch up on a few of these threads.

With respect to data security provenance there are two fundamental concepts:

  • Confidentiality
  • Integrity

I'm arguably preaching to the choir, but as a quick review, a confidentiality requirement means that a security vulnerability will exist if data is divulged to parties that are external to a security context.  An integrity requirement implies that a security vulnerability exists if data can be modified by third parties to a security context.

The elements of the data structure that define an enclave quote are as follows:

  • version
  • sign type
  • EPID group identifier
  • Quoting Enclave security version
  • basename
  • Enclave report structure
  • EPID signature length
  • EPID signature

The enclave report structure embedded in the quote structure consists of the following elements:

  • CPU security version
  • MISCSELECT value
  • enclave attributes
  • enclave measurement
  • enclave signing key signature
  • configuration identifier
  • software product identifier
  • software security version
  • configuration security version
  • report data

None of these data element have confidentiality requirements, in other words, disclosing the true value of this data to a third party does not compromise the integrity of the enclave attestation process.  In fact, the majority of these fields need to be publically available in order for a relying party to verify that the attestation report is from a known enclave and vendor.

What is a requirement for secure attestation, is a guarantee that none of these data elements have been modified by a party that is external to the relying and verifying parties.

The structure elements of the quote, including the members of the report structure. are protected by the EPID signature.  The Intel Attestation Service (IAS) has access to the 'public' component of the EPID group key that allows IAS to verify that the signature has been generated by a member of the 'group'.  The EPID provisioning process/protocol is constructed in a fashion that enables Intel to know that the signature could only have been generated by a Quoting Enclave (QE) running on a known Intel platform.  The local attestation process provides a guarantee that the QE received the enclave report structure from an enclave that has been loaded and initialized on the same platform.

Intel signs the attestation report with a private asymmetric key (RSA) and provides the public portion of the key in the form of a certificate with the attestation report.  In addition to the signing certificate, Intel provides an authority certificate that verifies the signing certificate.  The authority certificate can be independently downloaded from Intel if there is a concern over accepting the certificate stack that is returned with the attestation report.

This trust chain does not require that any elements covered by the chain be confidential in order to ensure the veracity of the attestation process.

The only potentially sensitive data is the information in the 'report data' member of the report structure.  This is a 64 byte field that can be used to convey data of confirmed origin and provenance to a relying party.  This field is open form and was engineered to deliver the public portion of an Elliptic Curve Diffie Hellman key that can be used to establish an ephemeral asymmetric key between the enclave and a relying party.  The Intel SDK uses this field to convey a NIST P-256 (prime256v1) public key to a relying party while our Secure Runtime Development Environment (SRDE) uses the field to exchange Curve25519 public keys between two enclaves that are establishing a security context to support inter-enclave communications.

By definition, this public key does not need be confidential in order for the key exchange to be securely conducted.  What is required is that the authenticity of the key be verified in order to avoid the possibility of a Man-In-The-Middle (MITM) attack against the security context that is being established.  The authenticity is a function of an integrity guarantee that the ECDH public key could not have been modified after its production inside of an enclave.

If one reviews the somewhat complex remote attestation protocol the Intel SDK implements in order to support the Service Provider (SP) model, you will see there is no attempt to impart confidentiality onto any of the quoting and session information being arbitrated between a client and presumably a cloud based enclave through the 3rd party Service Provider.  What is implemented are integrity guarantees, via AES128-CMAC, that the information could not have been modified.

The SP model has, arguably, done a lot to confuse understanding of SGX remote attestation.  It is arguably much easier for two enclaves to conduct remote attestation between themselves then it is to coordinate the process through a stand aside third party.  If nothing else an inter-enclave model may have caused Intel's DCG and CCG to link arms and support rapid proliferation of SGX on both client and server platforms, but now I'm editorializing.... :-)

Hopefully the above information is helpful in furthering an understanding of these issues.

Best wishes for a productive start of the week.

Dr. Greg

View solution in original post

0 Kudos
7 Replies
JesusG_Intel
Moderator
865 Views

Hello Piotr,

Yes, the Attestation Report contains sensitive data, that is why it is cryptographically signed by Intel. In the IAS API docs, section 4.3, you can see the sensitive data the Quote contains. Additionally, this document contains more information regarding EPID-based Attestation Services and the attestation verification reports that may be helpful to you. There are also several recommendations in Intel SGX Developer Guide for protecting enclaves. In general, Intel provides documentation on the services and APIs it provides and high-level security recommendations, but each developer is responsible for implementing security best practices to further protect their enclaves and data.

Regards,

Jesus

0 Kudos
AB_
Beginner
865 Views

Garcia, Jesus L (Intel) wrote:

Yes, the Attestation Report contains sensitive data, that is why it is cryptographically signed by Intel. In the IAS API docs, section 4.3, you can see the sensitive data the Quote contains.



Which of those fields are sensitive exactly? And what does sensitive mean here? Confidentiality or integrity?

0 Kudos
JesusG_Intel
Moderator
865 Views

Hello Piotr,

Integrity is the key from the IAS report perspective, which is why it is signed with an IAS private key and verified by the service provider with the IAS public key.

The Verification Report from the IAS is what the service provider uses to determine if the enclave is running on a valid platform. The service provider is then responsible for validating the identity of the enclave itself. Every field, as defined in figure 4.2.1 of the Intel® SGX Attestation Service API Spec, is sensitive. If the Verification Report is compromised, it is possible that the service provider will mistakenly either accept or reject the enclave as valid.

Regards,

Jesus

0 Kudos
Rosłaniec__Piotr1
865 Views

Hello Jesus,

Thank you for your response. I understand general security assumptions of RA, so let me ask a more concrete question: Should the contents of the quote be considered confidential? May report fields such as MRSIGNER or MRENCLAVE be used outside of the RA context, for example, to implement custom attestation protocols?

Best regards,

Piotr 

0 Kudos
JesusG_Intel
Moderator
865 Views

Hello Piotr, yes, the contents of the quote should be considered confidential and can be used to implement a custom attestation protocol. I recommend you read the Intel® Software Guard Extensions Developer Guide pages 21 (Remote Inter-Platform Attestation) - 25 for more information.

Regards,

Jesus

0 Kudos
Dr__Greg
Super User
866 Views

Good afternoon, I hope everyone is having a pleasant weekend.

I had been meaning to reply to this thread but was blocked by the need to get a code drop supervised and delivered.  The coronavirus has slowed up our work in the Far East so I'm taking advantage of some slack time to catch up on a few of these threads.

With respect to data security provenance there are two fundamental concepts:

  • Confidentiality
  • Integrity

I'm arguably preaching to the choir, but as a quick review, a confidentiality requirement means that a security vulnerability will exist if data is divulged to parties that are external to a security context.  An integrity requirement implies that a security vulnerability exists if data can be modified by third parties to a security context.

The elements of the data structure that define an enclave quote are as follows:

  • version
  • sign type
  • EPID group identifier
  • Quoting Enclave security version
  • basename
  • Enclave report structure
  • EPID signature length
  • EPID signature

The enclave report structure embedded in the quote structure consists of the following elements:

  • CPU security version
  • MISCSELECT value
  • enclave attributes
  • enclave measurement
  • enclave signing key signature
  • configuration identifier
  • software product identifier
  • software security version
  • configuration security version
  • report data

None of these data element have confidentiality requirements, in other words, disclosing the true value of this data to a third party does not compromise the integrity of the enclave attestation process.  In fact, the majority of these fields need to be publically available in order for a relying party to verify that the attestation report is from a known enclave and vendor.

What is a requirement for secure attestation, is a guarantee that none of these data elements have been modified by a party that is external to the relying and verifying parties.

The structure elements of the quote, including the members of the report structure. are protected by the EPID signature.  The Intel Attestation Service (IAS) has access to the 'public' component of the EPID group key that allows IAS to verify that the signature has been generated by a member of the 'group'.  The EPID provisioning process/protocol is constructed in a fashion that enables Intel to know that the signature could only have been generated by a Quoting Enclave (QE) running on a known Intel platform.  The local attestation process provides a guarantee that the QE received the enclave report structure from an enclave that has been loaded and initialized on the same platform.

Intel signs the attestation report with a private asymmetric key (RSA) and provides the public portion of the key in the form of a certificate with the attestation report.  In addition to the signing certificate, Intel provides an authority certificate that verifies the signing certificate.  The authority certificate can be independently downloaded from Intel if there is a concern over accepting the certificate stack that is returned with the attestation report.

This trust chain does not require that any elements covered by the chain be confidential in order to ensure the veracity of the attestation process.

The only potentially sensitive data is the information in the 'report data' member of the report structure.  This is a 64 byte field that can be used to convey data of confirmed origin and provenance to a relying party.  This field is open form and was engineered to deliver the public portion of an Elliptic Curve Diffie Hellman key that can be used to establish an ephemeral asymmetric key between the enclave and a relying party.  The Intel SDK uses this field to convey a NIST P-256 (prime256v1) public key to a relying party while our Secure Runtime Development Environment (SRDE) uses the field to exchange Curve25519 public keys between two enclaves that are establishing a security context to support inter-enclave communications.

By definition, this public key does not need be confidential in order for the key exchange to be securely conducted.  What is required is that the authenticity of the key be verified in order to avoid the possibility of a Man-In-The-Middle (MITM) attack against the security context that is being established.  The authenticity is a function of an integrity guarantee that the ECDH public key could not have been modified after its production inside of an enclave.

If one reviews the somewhat complex remote attestation protocol the Intel SDK implements in order to support the Service Provider (SP) model, you will see there is no attempt to impart confidentiality onto any of the quoting and session information being arbitrated between a client and presumably a cloud based enclave through the 3rd party Service Provider.  What is implemented are integrity guarantees, via AES128-CMAC, that the information could not have been modified.

The SP model has, arguably, done a lot to confuse understanding of SGX remote attestation.  It is arguably much easier for two enclaves to conduct remote attestation between themselves then it is to coordinate the process through a stand aside third party.  If nothing else an inter-enclave model may have caused Intel's DCG and CCG to link arms and support rapid proliferation of SGX on both client and server platforms, but now I'm editorializing.... :-)

Hopefully the above information is helpful in furthering an understanding of these issues.

Best wishes for a productive start of the week.

Dr. Greg

0 Kudos
Rosłaniec__Piotr1
865 Views

Good day everyone.

Jesus, thank you for the helpful references.

Dr. Greg, thank you for this extensive explanation.

I now understand how sharing report data fields could (not) impact the security of RA and thus my question is fully answered.

Thank you,

Piotr

0 Kudos
Reply