Understanding the secret_provision_start_server API

[ishaangandhi]

Are measurements from the SGX quotes verified before the secret is sent with the secret_provision_start_server API? That's what would make sense to me logically. Additionally, based on my understanding of RA-TLS, the connection only opens once the measurements are verified (per Gramine's docs).

However, I see in the source code that you are supposed to check against "expected values."

gramine/CI-Examples/ra-tls-secret-prov/secret_prov/server.c

Line 46 in af7caa9

puts("[ WARNING: In reality, you would want to compare against expected values! ]");

If that is true, how would you even check against expected values? Doesn't this defeat the point of the security policy?

Thanks!

[ishaangandhi]

Additionally, the docs for the verify_measurements_cb_t m_cb say:

Callback for user-specific verification of measurements in client's SGX
quote. If user supplies NULL, then default logic of RA-TLS is invoked.

Does this mean you can use the default logic of RA-TLS or provide your own logic? Is there a way to use the default logic and then your logic to, for example, verify the identity of the enclave with MRENCLAVE? That would seem very useful to me.

[ishaangandhi]

Oh I get it now. If you pass NULL, the required MRENCLAVE is taken from an environment variable, as I found out from the logs:

WARNING: The default enclave verification hook is being used, but RA_TLS_MRSIGNER is not set. This is deprecated and will become an error in the future. If you wish to accept any value, please specify RA_TLS_MRSIGNER=any explicitly.
WARNING: The default enclave verification hook is being used, but RA_TLS_MRENCLAVE is not set. This is deprecated and will become an error in the future. If you wish to accept any value, please specify RA_TLS_MRENCLAVE=any explicitly.
WARNING: The default enclave verification hook is being used, but RA_TLS_ISV_PROD_ID is not set. This is deprecated and will become an error in the future. If you wish to accept any value, please specify RA_TLS_ISV_PROD_ID=any explicitly.
WARNING: The default enclave verification hook is being used, but RA_TLS_ISV_SVN is not set. This is deprecated and will become an error in the future. If you wish to accept any value, please specify RA_TLS_ISV_SVN=any explicitly.
WARNING: Neither RA_TLS_MRSIGNER nor RA_TLS_MRENCLAVE are specified. This will accept any enclave and provides no security whatsoever.

[dimakuv]

One important thing to note here: gramine/CI-Examples/ra-tls-secret-prov/secret_prov/server.c is just an example. You are supposed to write your own secret provisioning server application for your own production usages. So you can replace the logic in this callback with your own logic:

gramine/CI-Examples/ra-tls-secret-prov/secret_prov/server.c

Lines 36 to 50 in af7caa9

	static int verify_measurements_callback(const char* mrenclave, const char* mrsigner,
	const char* isv_prod_id, const char* isv_svn) {
	assert(mrenclave && mrsigner && isv_prod_id && isv_svn);
	pthread_mutex_lock(&g_print_lock);
	puts("Received the following measurements from the client:");
	printf(" - MRENCLAVE: "); hexdump_mem(mrenclave, 32);
	printf(" - MRSIGNER: "); hexdump_mem(mrsigner, 32);
	printf(" - ISV_PROD_ID: %hu\n", *((uint16_t*)isv_prod_id));
	printf(" - ISV_SVN: %hu\n", *((uint16_t*)isv_svn));
	puts("[ WARNING: In reality, you would want to compare against expected values! ]");
	pthread_mutex_unlock(&g_print_lock);
	return 0;
	}

Ideally, you would replace the above dummy snippet with your own code that will check MRENCLAVE and other measurements against whatever you have as a policy and "golden" values.