Initialization vector for AES-GCM

[Rafal_W_]

The official GCM specification at http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf 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:

https://github.com/01org/linux-sgx/blob/master/sdk/tseal/tSeal.cpp#L72

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

https://github.com/01org/linux-sgx/blob/master/sdk/tseal/tSeal.cpp#L147

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

[Ofir_W_]

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 7.3.17.1  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)

Ofir