Hi Jean-Pierre,

Thanks for your comment. To give a bit more context, this is used in a secure bootloader, which loads the encrypted application from flash and decrypts it into internal memory (but it does not expose the plaintext). Both the key and IV are derived from an ECDH operation (so I cannot see either of them), and the IV is indeed 16-byte long.

If I understand it correctly, when using AES in GCM mode, the input ciphertext is simply XOR’ed with the encrypted counter. For a 16-byte IV I believe this is more or less: *output_plaintext = input_ciphertext ^ E( hashed_iv + counter )*. If I had the ciphertext and the plaintext I would be able to XOR them to calculate the encrypted iv+counter, so I could mount an attack. But because the bootloader does not expose the plaintext output, I could possibly attack the XOR operation, but at most I would be able to extract the encrypted counter, not the IV or key. Am I making any sense?

On the other side, you mentioned that the GHASH function can also be attacked. Do you know if I would be able to do it given that I cannot control the input plaintext? I can predict some bits of it (the zeros and IV length), but those are fixed so I don’t think I can extract any statistical knowledge from them?

The only option that I can think of is to:

- Capture N traces of the decryption of the first 16 bytes while feeding random ciphertext, and attack the XOR to try and extract the encrypted counter
- Repeat this M times at different offsets, to try and extract M different encrypted counters
- Use these M traces with now-known-encrypted-counters to attack AES-ECB as usual

This might work if I can extract enough leakage from the XOR operation, but it would still require M*N traces. In my tests so far I need in the order of 500-2000 traces to break the bare AES implementation, so I can expect this approach to easily require more than 1M traces.

Does this make any sense? Am I missing an obvious simplification of the problem, or a better approach to it?

Sorry for the long exposition and thanks again for your response

Thanks,

Jose