[SiebenHeaven]

I am pretty surprised how they allowed reusing IV. Unique IV is explicitly mentioned to be an assumption for AES GCM (first sentence in security section of AES-GCM wikipedia page)

How could anyone design TA (i.e application whose whole point is security and hence it runs in the secure mode) and allow user to set IV in the API?

[hannob]

> How could anyone design TA (i.e application whose whole point is security and hence it runs in the secure mode) and allow user to set IV in the API?

I mean... TLS did the same (in 1.2, it was fixed in 1.3). I co-authored a paper about it: https://www.usenix.org/conference/woot16/workshop-program/pr...

[SiebenHeaven]

Thanks for the pointer to your interesting paper.

My understanding is that TLS spec did not enforce non-repeating nonce, only suggested it and left it to implementers to decide which led to the vulnerabilities you explored.

This Samsung one here is in a way similar - the TEE API had a way for users of the API to set IV which it should not, TA should make sure the IV is not repeated.

Since you have done prior research in this area, is using a counter for IV still recommended even when IV is 12 byte? I assume chances of HW random number generator (which I assume exists on most phones today) colliding for 12 byte random number generation would be pretty low.

[PaulHoule]

My experience is the odds are greater than 50% that people designing a system do the wrong thing with the I.V.'s.

The NSA gave up on back doors, limiting the key size, etc. because people are too stupid to manage keys correctly.