topic SharedSecret Inside/Outside enclave in Intel® Software Guard Extensions (Intel® SGX)

SharedSecret Inside/Outside enclave

kalogiannis__konstan — Mon, 13 Feb 2017 09:21:07 GMT

Hi,

I tried to generate the shared DH key inside the enclave using the ecc_compute_shared_dhkey but i noticed that the generated key is different from the one created by the IPP library in the code provided(same run). Using this generated shared key i continued the control flow of the server and generated the KDK,SMK,SK,VK keys but as hinted/expected the client failed to process msg1 with a MAC_MISMATCH error(cmac(smk,msg)).

I also tried to generate the shared key(inside the enclave) using the ipps functions(ippsECCPSharedSecretDH() etc.) but the key generated matched the one generated by the enclave's own function.

Am i doing something wrong or is this the intended behaviour??

Thanks in advance for any contribution.

Hi,

Rodolfo_S_ — Mon, 13 Feb 2017 10:41:32 GMT

Hi,

Could you clarify two things first?

Inside what enclave did you try to compute the shared key? What parameters are you using in the sgx_ecc256_compute_shared_dhkey?
What do you mean by "the client failed to process msg1 with a MAC_MISMATCH", since the sgx_ra_msg1_t doesn't have a MAC? The msg1 consists of only the GID and the SP's public key.

Quote:Rodolfo S. wrote:

kalogiannis__konstan — Mon, 13 Feb 2017 12:17:00 GMT

Rodolfo S. wrote:

Hi,

Could you clarify two things first?

Inside what enclave did you try to compute the shared key? What parameters are you using in the sgx_ecc256_compute_shared_dhkey?

What do you mean by "the client failed to process msg1 with a MAC_MISMATCH", since the sgx_ra_msg1_t doesn't have a MAC? The msg1 consists of only the GID and the SP's public key.

1. The enclave is in Prerelease x64. The server is running in release(tested in prerelease too). The function I'm utilizing looks something like this:

static sgx_ec256_private_t spPrivKeyBlob ={....};
sgx_ec256_public_t *remotepub = (sgx_ec256_public_t*)malloc(sizeof(sgx_ec256_public_t));
sgx_ec256_dh_shared_t *sharedkey = (sgx_ec256_dh_shared_t*)malloc(sizeof(sgx_ec256_dh_shared_t));
sgx_ecc_state_handle_t* myhandle = (sgx_ecc_state_handle_t*)malloc(sizeof(sgx_ecc_state_handle_t));

void ComputeShared(unsigned char* gX, unsigned char* gY,unsigned char* my_shared){
        ret = sgx_ecc256_open_context(myhandle);
        memcpy(remotepub->gx, gX, 32);
        memcpy(remotepub->gy, gY, 32);
        ret = sgx_ecc256_compute_shared_dhkey(&spPrivKeyBlob, remotepub, sharedkey, *myhandle);
        .
        .
}

I'm passing the public key of the client from the server application to the wrapper and then to the enclave like that:

byte[] my_shared = new byte[32];
myfunction(gaXLittleEndian, gaYLittleEndian,my_shared);

__declspec(dllexport) void myfunction(unsigned char* gX, unsigned char* gY,unsigned char* sharedkey){

2. Forgive me on this,that was a typo, I'm talking about the msg2 sent from the server to the client. The client then calls proc_msg2 to generate msg3 for the server. Proc_msg2 is the one failing with MAC_MISMATCH.

Edit while writing this:

Changing the sgx_ecc_state_handle_t to uninitialized and letting the open_context allocate the memory, ecc256_compute_shared gives me an 0x001(UNEXPECTED_ERROR) and fails. Everything else is unchanged from the above supplied paradigm.

Edit2:
Correcting the first's edit mistake(that gave UNEXPECTED_ERROR), the shared key generated falls to the same problem of the first approach.

Thanks in advance for an help provided.