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

Initialization vector for AES-GCM


The official GCM specification at states that the initialization vector should be unique for every GCM encryption operation using one key. However, the Remote Attestation SDK sample uses a zero IV for GCM encryption.

Moreover, the SDK function sgx_seal_data_ex also uses a zero IV:

...the IV is then passed unchanged to sgx_seal_data_iv:

Is there something I'm not getting here (I'm not a cryptography expert after all)?

0 Kudos
1 Reply

TL;DR: The encryption sealing key is always different, therefore it is OK to use the same IV. 

More details:

Notice that in sgx_seal_data_ex there is a variable called keyID. This variable is filled with random values using a call to sgx_read_rand which is a wrapper to the RDRAND instruction (using true entropy source, see chapter  in the SDM, volume 1). keyID is copied to a field in tmp_key_request, which is passed on to the function sgx_seal_data_iv, implemented in tSeal_internal.cpp.  sgx_seal_data_iv calls sgx_get_key which is a wrapper to the EGETKEY instruction. The keyID is used by EGETKEY to ensure a fresh encryption sealing key is generated. 

Conclusion: a different sealing key is used every time, therefore it is safe to use a constant IV in the AES-GCM.

Why is that so? The NIST document specification of AES-GCM sets a maximum limit on number of invocation of AES_GCM with IV length of 96 bits. The limit is 2^32. To avoid a limit on the number of invocation of the sealing key, you can generate a new key every time.

(If anyone has a different interpretation, I'd be happy to stand corrected)


0 Kudos