AES-GCM IV reuse

[bas-d]

Hello,

Thank you for the clear blog on Android Keystore authentication, very helpful. However, I think it's not a good idea to store the IV in sharedPreferences and reuse it for subsequent encryption operations with AES-GCM, as this exposes ciphertexts to a known-plaintext attack.

Proof of concept: The following plaintexts have been encrypted with the demo-app:

P1: With AES-GCM you should not reuse C1: bCqRKGQjnr07Qnk4WW5jeo9ARrEgdvFuHv0Wjxoz+fv3Q9+wsZaAQLpL8CzqAyhuNQ==

P2: The initialization vector C2: byuAYC0Mspp/ZFYcA3Z4ZsBdDqgweeEhAsGcqLwfNjq0Mtq

The second plaintext can be derived by doing P2 = C1 ⊕ C2 ⊕ P1

An alternative approach could be to generate a fresh IV for each encryption operation and prepend it to the ciphertext.

For reference, the following key and IV were used for the example, above: Application Key: 59F20FB3213DDE76F4D4F6598F70771035AB3F10DBF3D968B474C3A6B6786D08 IV: A4C8A8392FEEBC671D21FA3E71C8E8E7

Cyberchef recipe:

From_Base64('A-Za-z0-9+/=',true)
XOR({'option':'Base64','string':'byuAYC0Mspp/ZFYcA3Z4ZsBdDqgweeEhAsGcqLwfNjq0Mtq'},'Standard',false)
XOR({'option':'Latin1','string':'With AES-GCM you should not reuse'},'Standard',false)

[deus-ex-silicium]

Hello, Thank you for bringing this to our attention, we appreciate your contribution and we will fix the reuse issue in the near future.

The known-plaintext attack assumes that an attacker has the ability to encrypt his plaintext. In the context of the application this means that an attacker would need to share (compromise) the same hardware keystore as the victim. If this requirement is satisfied, any other kinds of attacks are not necessary since an attacker could use his access to the keystore to also decrypt any ciphertext.

GCM + IV reuse is still a theoretical issue here and a deviation from security best practice that we want to fix, especially since this application is meant to serve as a reference for other secure implementations.

[bas-d]

If the attacker would have the ability to encrypt his plaintext, it would be a chosen-plaintext attack. In this case, just knowing a single plaintext and the corresponding ciphertext allows the attacker to decrypt all other ciphertexts that have been encrypted with the same key and IV.

Anyway, good to hear it will be fixed!

[deus-ex-silicium]

Thanks for making the distinction clear, the issue should be fixed now. We appreciate your contributions and are glad you enjoyed the blog post.