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

How Local Attestation Prevent Man in the Middle Attack

He__Yi
Beginner
1,292 Views

Hi!

I'm new to Intel SGX. Recently I've been confused about how to prevent man in the middle attack (of another enclave) in local attestation.

For example enclave A needs to attests itself to enclave B, it follows following procedures:

(1) A sends a request to B.

(2) B sends its measurements(Mr_b) and attributes(Attr_b) to A as a challenge.

(3) A calls EREPORT to generate A's report, compute its MAC using a key derived from Mr_b and Attr_b. Sending the report and MAC to B.

(4) B calls EGETKEY(report), using its own (Mr_b) and (Attr_b) to generate the key, then compute the MAC of A's report. Compare this MAC with the MAC it received. If correct, it means a success in attestation.

 

Now assuming there is an enclave/application C in middle (in the same platform or even outside the platform), who can read A's report and MAC. Since A's report and MAC are in plaintext, and exposed in the API (the sgx_dh_msgx_t data structure), an untrusted application can easily obtain it. Then C can pretend that the report and MAC belong to him. And by sending these to B, C can make B believe C is A.

The DH key exchange process without signature happening along with local attestation can also not prevent A-B communication from man in the middle attack. Therefore, C can successfully obtain the symmetric key computed from DH key exchange.

 

Essentially, A must sends its REPORT and MAC to B through untrusted platform (OCALL). Anyone can hijack this REPORT and MAC to claim it belongs to him...

Could you help me figure out which part did I miss?

Thank you!

0 Kudos
1 Solution
Dr__Greg
Super User
1,292 Views

Hi Yi, I hope this note finds your week going well.  I have been meaning to reply to your post for some time and just found the time to compose a response.

Lets see if I can help my dear friend Scott amplify on his response.  In his post he referred to a reprint of the HASP paper that discusses the generation of sealing keys and both local and remote attestation.  I would recommend reading that paper very carefully, in particular pay attention to the diagram at the beginning of section 3.  Also work through and understand the two numbered sequences after figure three.

At the big picture level, the security of local attestation hinges on the ability of an enclave to generate a symmetric key based on its identity characteristics.  When an ENCLU[EREPORT] instruction is executed, a set of enclave identity characteristics that the report is to be sealed against is submitted to the instruction.  In turn, the report generation instruction causes a report to be generated that includes its own identity characteristics.

Here is the structure that is generated by the ENCLU[EREPORT] instruction:

struct SGX_reportbody {
        uint8_t cpusvn[16];
        uint32_t miscselect;
        uint8_t reserved1[28];
        struct {
                uint64_t flags;
                uint64_t xfrm;
        } attributes;
        uint8_t mrenclave[32];
        uint8_t reserverd2[32];
        uint8_t mrsigner[32];
        uint8_t reserved3[96];
        uint16_t isvprodid;
        uint16_t isvsvn;
        uint8_t reserved4[60];
        uint8_t reportdata[64];
}

This structure is in essence 'wrapped' by the processor in the form of the following data structure:

struct SGX_report {
        struct SGX_reportbody body;
        uint8_t keyid[32];
        uint8_t mac[16];
}

The processor, when generating the report, creates a symmetric key based on the identity characteristics of a verifying enclave that is requesting the attestation report.  The symmetric key is used to generate a Message Authentication Code (MAC) based on the AES128-CMAC algorithm. The resulting MAC value is placed in the mac element of the latter structure.

Modifying the contents of the reportbody structure in any way changes the value of the MAC that is computed.  The value is also dependent on the symmetric key that is used to seed the AES128-MAC algorithm.  In SGX think of this symmetric key as a method of authenticating the enclave that can verify the integrity of a report.

The following structure is passed to the ENCLU[EREPORT] instruction in order to set the identity characteristics of the enclave that can authenticate the report:

struct SGX_targetinfo {
        uint8_t mrenclave[32];
        struct {
                uint64_t flags;
                uint64_t xfrm;
        } attributes;
        uint8_t reserved1[4];
        uint32_t miscselect;
        uint8_t reserved2[456];
}

The verifying enclave that is requesting attestation of an attesting enclave provides the latter enclave with a copy of the SGX_targetinfo structure that the verifying enclave generates.  This latter structure is used by the attesting enclave to generate the report that will be returned to the verifying enclave.  The processor will use the identity characteristics to derive the symmetric key that generates the MAC over the reportbody structure data.

In typical practice the attesting enclave generates an Elliptic Curve Diffie-Hellman (ECDH) keypair and passes the public portion of the key to the ENCLU[EREPORT] structure.  The processor integrates this data into the reportdata element of the SGX_reportbody structure.

In the local attestation protocol that we implement in our Secure Runtime Development Environment (SRDE), the attesting enclave generates a 'null' report and uses the identity characteristics in that report to create an SGX_targetinfo structure that is returned, along with the SGX_report structure, to the verifying enclave.

Upon receipt of the two structures, the verifying enclave requests the generation of its report key with the ENCLU[EGETKEY] instruction.  The symmetric key is used by the enclave to verify the MAC value over the contents of the SGX_reportbody structure.  The verifying enclave also checks the values of the various identity characteristics of the attesting enclave in the SGX_reportbody structure in order to verify that the enclave that generated the report is the enclave that it believes it is.

Since the MRENCLAVE value tends to be too fungible, the most useful identity characteristics that are verified are the MRSIGNER value, the isvprodid or product id of the enclave, the isvsvn or security version of the enclave and the enclave attributes.  The most significant attribute is whether or not the enclave is running in debug or secure mode.

Just as an aside, the cpusvn element of the SGX_reportbody structure identifies the microcode level of the processor that essentially translates into the security level of the processor.  This is defined to be an opaque value that is only understandable by Intel.  It is included in order to support Intel's role as the 'Trusted Third Party' in remote attestation.

The important security predicate involved in all of this is that only an enclave with the identity characteristics provided to the ENCLU[EREPORT] structure can generate the symmetric key used to compute the MAC over the reportbody.  The attesting enclave, or an enclave attempting to mount an MITM attack, cannot generate the report key, they can only request that the processor generate a report that is sealed by the key.

An interposing enclave attempting to mount an MITM attack cannot change the contents of any of the identity characteristics in the SGX_reportbody structure without causing a perturbation in the computed MAC value.  In addition, it cannot generate the symmetric key on which the MAC is predicated.  If it were to attempt to abstract the reportdata element from the SGX_reportbody structure and generate its own report, that report would contain the identity characteristics of the interposing enclave and not those of the attesting enclave.

After conducting verification of the attestation report, the verifying enclave generates a random base point in the elliptic curve field being used and pairs that with the public key from the reportdata structure to generate its own public key.  It then uses the identity characteristics of the attesting enclave to generate its own report that contains this public key.

The resultant report is passed back to the verifying enclave that conducts its own verification of the identity characteristics of the verifying enclave.  If those checks pass the attesting enclave knows that the public key in the reportdata structure is valid and uses that public key in combination with the private key it had previously generated to determine the random base point value that the verifying enclave had chosen.

This random value serves as the basis for the creation of a security context between the two enclaves.  Typically this random base point is hashed in order to generate a symmetric key that is used to support authenticated encryption between the two enclaves.

So the security proof for the process would be essentially constructed around the following predicates:

Consistent with standard Diffie Hellman security theory, it is computationally infeasible for an interposing (MITM) entity to determine the random base point using the public key information that is passed 'in the clear' in the two reports.  The interposing identity also cannot modify either of the public keys without the action being detected by the resultant perturbation in the AES128-CMAC value that the change would engender.  Finally, the only entities that have access to the symmetric key used to seed computation of the AES128-CMAC value is the processor itself and the enclave whose identity characteristics are used to create the SGX_report structure.

Understanding these concepts are useful in understanding the security model surrounding remote attestation.  In remote attestation the SGX_reportbody structure is signed by the private portion of an Enhanced Privacy ID (EPID) group key that is provisioned to the platform by Intel.  The cpusvn value encoded in the SGX_reportbody structure allows Intel to determine the security level that the processor is running at which positions Intel to attest to whether or not the enclave is running in a secure environment.

I apologize for the length of this post.  Our SRDE packages all of these technologies up into high level predicates that allows the technology to be easily exploited to develop secure runtime environments.  Packaging all of this technology into higher level constructs obviously engenders a somewhat intimate understanding into how all of the gears interact to produce smooth motion... :-)

Hopefully all of the above information is useful to Yi and others in understanding the security predicates that SGX processor technology brings to both local and remote attestation.

Best wishes for a productive end of the week to everyone.

Dr. Greg

View solution in original post

4 Replies
Scott_R_Intel
Employee
1,292 Views

Hello.

Please see the white paper at the link below to see if it answers your question.

https://software.intel.com/en-us/articles/innovative-technology-for-cpu-based-attestation-and-sealing

Regards.

Scott

0 Kudos
He__Yi
Beginner
1,292 Views

Hi!

Thank you for your reply! I read through some more documents. I can understand how Local Attestation is able to attest an enclave to be within the CPU, as EREPORT and EGETKEY need to use CPU specific data to generate the key. but I still couldn't figure out how local attestation attests an Enclave A to be itself, but not some other enclave running on the same CPU.

For example an enclave C runs by malicious attacker on the same CPU can preside in the middle, when everything of the system outside of those enclaves are compromised. C can build a secure connection through DH Key exchange with both A and B. After which C can retrieve secret data from both A and B.

Could you help me figure out where did I miss?

 

Thanks!

0 Kudos
Dr__Greg
Super User
1,293 Views

Hi Yi, I hope this note finds your week going well.  I have been meaning to reply to your post for some time and just found the time to compose a response.

Lets see if I can help my dear friend Scott amplify on his response.  In his post he referred to a reprint of the HASP paper that discusses the generation of sealing keys and both local and remote attestation.  I would recommend reading that paper very carefully, in particular pay attention to the diagram at the beginning of section 3.  Also work through and understand the two numbered sequences after figure three.

At the big picture level, the security of local attestation hinges on the ability of an enclave to generate a symmetric key based on its identity characteristics.  When an ENCLU[EREPORT] instruction is executed, a set of enclave identity characteristics that the report is to be sealed against is submitted to the instruction.  In turn, the report generation instruction causes a report to be generated that includes its own identity characteristics.

Here is the structure that is generated by the ENCLU[EREPORT] instruction:

struct SGX_reportbody {
        uint8_t cpusvn[16];
        uint32_t miscselect;
        uint8_t reserved1[28];
        struct {
                uint64_t flags;
                uint64_t xfrm;
        } attributes;
        uint8_t mrenclave[32];
        uint8_t reserverd2[32];
        uint8_t mrsigner[32];
        uint8_t reserved3[96];
        uint16_t isvprodid;
        uint16_t isvsvn;
        uint8_t reserved4[60];
        uint8_t reportdata[64];
}

This structure is in essence 'wrapped' by the processor in the form of the following data structure:

struct SGX_report {
        struct SGX_reportbody body;
        uint8_t keyid[32];
        uint8_t mac[16];
}

The processor, when generating the report, creates a symmetric key based on the identity characteristics of a verifying enclave that is requesting the attestation report.  The symmetric key is used to generate a Message Authentication Code (MAC) based on the AES128-CMAC algorithm. The resulting MAC value is placed in the mac element of the latter structure.

Modifying the contents of the reportbody structure in any way changes the value of the MAC that is computed.  The value is also dependent on the symmetric key that is used to seed the AES128-MAC algorithm.  In SGX think of this symmetric key as a method of authenticating the enclave that can verify the integrity of a report.

The following structure is passed to the ENCLU[EREPORT] instruction in order to set the identity characteristics of the enclave that can authenticate the report:

struct SGX_targetinfo {
        uint8_t mrenclave[32];
        struct {
                uint64_t flags;
                uint64_t xfrm;
        } attributes;
        uint8_t reserved1[4];
        uint32_t miscselect;
        uint8_t reserved2[456];
}

The verifying enclave that is requesting attestation of an attesting enclave provides the latter enclave with a copy of the SGX_targetinfo structure that the verifying enclave generates.  This latter structure is used by the attesting enclave to generate the report that will be returned to the verifying enclave.  The processor will use the identity characteristics to derive the symmetric key that generates the MAC over the reportbody structure data.

In typical practice the attesting enclave generates an Elliptic Curve Diffie-Hellman (ECDH) keypair and passes the public portion of the key to the ENCLU[EREPORT] structure.  The processor integrates this data into the reportdata element of the SGX_reportbody structure.

In the local attestation protocol that we implement in our Secure Runtime Development Environment (SRDE), the attesting enclave generates a 'null' report and uses the identity characteristics in that report to create an SGX_targetinfo structure that is returned, along with the SGX_report structure, to the verifying enclave.

Upon receipt of the two structures, the verifying enclave requests the generation of its report key with the ENCLU[EGETKEY] instruction.  The symmetric key is used by the enclave to verify the MAC value over the contents of the SGX_reportbody structure.  The verifying enclave also checks the values of the various identity characteristics of the attesting enclave in the SGX_reportbody structure in order to verify that the enclave that generated the report is the enclave that it believes it is.

Since the MRENCLAVE value tends to be too fungible, the most useful identity characteristics that are verified are the MRSIGNER value, the isvprodid or product id of the enclave, the isvsvn or security version of the enclave and the enclave attributes.  The most significant attribute is whether or not the enclave is running in debug or secure mode.

Just as an aside, the cpusvn element of the SGX_reportbody structure identifies the microcode level of the processor that essentially translates into the security level of the processor.  This is defined to be an opaque value that is only understandable by Intel.  It is included in order to support Intel's role as the 'Trusted Third Party' in remote attestation.

The important security predicate involved in all of this is that only an enclave with the identity characteristics provided to the ENCLU[EREPORT] structure can generate the symmetric key used to compute the MAC over the reportbody.  The attesting enclave, or an enclave attempting to mount an MITM attack, cannot generate the report key, they can only request that the processor generate a report that is sealed by the key.

An interposing enclave attempting to mount an MITM attack cannot change the contents of any of the identity characteristics in the SGX_reportbody structure without causing a perturbation in the computed MAC value.  In addition, it cannot generate the symmetric key on which the MAC is predicated.  If it were to attempt to abstract the reportdata element from the SGX_reportbody structure and generate its own report, that report would contain the identity characteristics of the interposing enclave and not those of the attesting enclave.

After conducting verification of the attestation report, the verifying enclave generates a random base point in the elliptic curve field being used and pairs that with the public key from the reportdata structure to generate its own public key.  It then uses the identity characteristics of the attesting enclave to generate its own report that contains this public key.

The resultant report is passed back to the verifying enclave that conducts its own verification of the identity characteristics of the verifying enclave.  If those checks pass the attesting enclave knows that the public key in the reportdata structure is valid and uses that public key in combination with the private key it had previously generated to determine the random base point value that the verifying enclave had chosen.

This random value serves as the basis for the creation of a security context between the two enclaves.  Typically this random base point is hashed in order to generate a symmetric key that is used to support authenticated encryption between the two enclaves.

So the security proof for the process would be essentially constructed around the following predicates:

Consistent with standard Diffie Hellman security theory, it is computationally infeasible for an interposing (MITM) entity to determine the random base point using the public key information that is passed 'in the clear' in the two reports.  The interposing identity also cannot modify either of the public keys without the action being detected by the resultant perturbation in the AES128-CMAC value that the change would engender.  Finally, the only entities that have access to the symmetric key used to seed computation of the AES128-CMAC value is the processor itself and the enclave whose identity characteristics are used to create the SGX_report structure.

Understanding these concepts are useful in understanding the security model surrounding remote attestation.  In remote attestation the SGX_reportbody structure is signed by the private portion of an Enhanced Privacy ID (EPID) group key that is provisioned to the platform by Intel.  The cpusvn value encoded in the SGX_reportbody structure allows Intel to determine the security level that the processor is running at which positions Intel to attest to whether or not the enclave is running in a secure environment.

I apologize for the length of this post.  Our SRDE packages all of these technologies up into high level predicates that allows the technology to be easily exploited to develop secure runtime environments.  Packaging all of this technology into higher level constructs obviously engenders a somewhat intimate understanding into how all of the gears interact to produce smooth motion... :-)

Hopefully all of the above information is useful to Yi and others in understanding the security predicates that SGX processor technology brings to both local and remote attestation.

Best wishes for a productive end of the week to everyone.

Dr. Greg

He__Yi
Beginner
1,292 Views

Hi, Greg!

Thank you so much for your reply! It is really helpful!

Thanks to your help now I have understood what I have missed. Previously I didn't know how can B make sure A is indeed A, since the local attestation calls need to go through untrusted environment to get to the other side.

Now I've understood that B actually needs to check the REPORT sent by A to verify parameters like the Product ID and SVNs to make sure the one who MACed the enclave REPORT is indeed the one B wants to talk to. Malicious programs can not create an enclave C talking between A and B, since C would have a different Product ID.

This checking process is necessary in developing B's enclave program. Programmers need to be aware of the necessity of checking the fields in REPORT so as to guarantee the identity of A.

 

Thanks again!

0 Kudos
Reply