> ...but it's possible that the microcode for an AES round opcode could be intentionally flawed
I guess that you mean that it'd still give correct output, but somehow leak the key (incorrect output seems simple to detect, unless it happens for a very small set of keys, and then it seems mostly useless).
I wonder: what ways of leaking the key off the machine would you expect? I (but I'm probably not devious enough) don't see ones that aren't overly complex and don't require additional compromised peripherals. Do you?
Timing. Perhaps a malicious microcode could introduce key-dependent delays into AES encryption/decryption? That's a pretty long shot, though; given my understanding of modern CPUs it's unlikely to be possible.
Another hypothetical attack: the AES instructions could be modified to store plain text and/or keys in cache, with a specific set of innocuous opcodes and register values triggering a readout of the data. This would allow one VM on a physical server to steal keys or data from another VM on the same server.
It seems unlikely, though, due to the probability that an adversary that controls both CPU microcode and VM placement probably has access to the hypervisor.
I guess that you mean that it'd still give correct output, but somehow leak the key (incorrect output seems simple to detect, unless it happens for a very small set of keys, and then it seems mostly useless).
I wonder: what ways of leaking the key off the machine would you expect? I (but I'm probably not devious enough) don't see ones that aren't overly complex and don't require additional compromised peripherals. Do you?