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?
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.
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?