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?

Asked by user10198 (1 )
Dec 03, 2013 at 21:08