Information Security
aes hardware nsa
Updated Wed, 01 Jun 2022 16:38:07 GMT

How to circumvent compromised CPUs in major FOSS operating systems

As Matthew Green puts it, "the NSA has been ... Working with hardware ... vendors to weaken encryption and random number generators." At this stage, however, there is little public knowledge of which specific hardware products have been compromised by such efforts, and in which ways. That makes it difficult to know how to respond to such news, when making purchasing/deployment decisions, if one wishes to avoid using compromised functionality. (A rare case which is publicly "known" is the Dual_EC_DRBG random number generator used by various products, although apparently not by the RdRand instruction available on some Intel CPUs.)

For example, if it were the case that the AES or AES-NI functionality available in some Intel and AMD CPUs has been compromised, but the rest of the CPU behaves expectedly, then avoiding the compromised functionality would not necessitate avoiding those CPUs: it would be sufficient just to avoid using the relevant instructions.

My questions are:

  1. Can that be done in the OpenBSD Cryptographic Framework (OpenBSD/FreeBSD/Illumos/etc) and in the Crypto API (Linux), and if so, how?
  2. Given that:

    • suspect hardware is pointless in cryptographic applications, and
    • on-chip AES or AES-NI is pointless except in cryptographic applications,

    do you think CPUs with AES or AES-NI are now pointless?

  3. Have I got the wrong end of a stick here?


The AES instructions have to produce the proper output. If they were tampered with in a way that changed output, it would be detected very quickly, and there have been no reports of that. This limits the scope of tampering considerably (to side channels and such), and I can't see that being readily exploitable by the NSA.

A random number generator is a different beast. It's possible that while it looks to you and I like a random stream, it has some special property that the NSA can use to predict it. RdRand and Dual_EC_DRBG are both under suspicion.

So a practical step is to use additional random number generator instead of (or in addition to) RdRand. Most crypto libraries already do this, or can be configured to (more info)

That's probably the only reasonable countermeasure. In theory a backdoored CPU can do anything: leak your plaintext directly to the NSA, store your keys permanently on the chip, etc. But there's nothing you can really do about that.

Comments (4)