How to circumvent compromised CPUs in major FOSS operating systems

Question

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?

Answer 1

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.

Answer 2

There is no way circumvent a malicious CPU.

Malware can run at different layers on modern compute systems. From top to bottom; Application level, user-mode, kernel-mode, boot-sector, firmware and finally microcode. To understand the true significance of these levels, a layperson would first need to understand the process which occurs every time their machines boot up: Power is applied; a program called the BIOS boot program runs; it's job is to play any microcode updates into the CPU and find the boot device; the boot device runs it's boot-sector; the boot-sector finds the kernel and loads it into memory; the kernel starts the first user-mode process (init or smss); initial user-mode process starts up all the processes. Now that all the computer people are fast asleep from that 101 lesson, everyone else can hopefully understand the significance. The lower you are in that chain of processes, the easier it is to control/modify everything above.

Security professionals are used-to (and downright tired of) dealing with malware at the top 3 levels on a daily basis. The bootsector stuff has caught on in the past few years and everyone knows about stuff like Kon-boot or Vbootkit, etc. but it's still not really widespread. Firmware is even more esoteric. BIOS is a type of firmware, the most advanced type of firmware in most systems. There are only a handful of companies in the world who write these BIOS programs. Most computer manufacturers license their BIOS from these companies. Apple of course makes their own because think different and stuff. BIOS malware would (seemingly) have to be very specifically targeted for a particular version of a particular vendor's release, etc. As far as resources, you have Phrack #66 which outlines how to create malicious VMware and Award BIOS, the Maux firmware project, and in 2009 there was that case of those used Dell servers which had BIOS rootkits. This was the first 'wild' case of a BIOS rootkit. The next major case was Mebroni in 2011.

Now look, not to get political, but anyone who tells you the CPU microcode attacks is the domain of "tin foil" and all that.. these people are naive as hell. They have no idea what an empire does every single day to maintain it's power. They have no idea what sort of things go on in the dark in this world. These are the same people who in 1940 would have said that the atomic bomb is a myth and inconceivable. Absolutely the future of 'cyber-war' aka State Sponsored Cyber Terrorism or state sponsored hacking or whatever you want to call it.. absolutely the 'end all' is malicious CPU Microcode. This is as insidious as you can get. The reasons for pursuing the CPU microcode vector in the context of "cyber war" are the very same reasons why nuclear weapons were developed in the context of kinetic war. Think back to the Second World War and the Manhattan project. If the Atomic bomb, more specifically multistage thermonuclear bomb, is the "end-all" game-changer in the vector of, physical, kinetic war then malicious CPU microcode is it's cyber equivalent. The same vigor an obsession with which nation-states pursued atomic weaponry is likely being applied today in developing the end-all cyber weapon.

Now as I mentioned before the microcode updates don't 'stick.' This means they have to be 'played' into the CPU on each bootup. There are some ways around this however. Anyway, your post is essentially asking how an OS.. which is only kernel level and up can protect you from attacks down on the lower levels like bootsector, firmware such as BIOS or specifically CPU microcode. My suggestion is to use old hardware and don't apply the microcode updates where applicable. Funny enough Intel just released a microcode update for the whole 'i' line not to long back. These updates get packaged in with Microsoft updates on the Windows side. Also the updates are obviously encrypted.. and the encryption algorithm is a tightly held corporate secret. If you're really interested in this type of stuff I can get really deep into it, but I think I've posted enough for here. There are people who have tried to reverse engineer microcode updates.. and other stuff like that.. research/researches.. I can link you to some stuff if you want. Anyway.. IMHOP only a state actor.. pretty much only the USA/Israel could pull off something like this.. anyway.. the MIPS architecture CPUs coming out China look promising. Depending on the way this war on general computation goes I might switch to MIPS 100% in the future. Besides, it run's Linux.

Just consider that yes, according to many attributable and non-attributable sources, the NSA is indeed working on the microcode vector.. and YES they ARE working WITH the vendors themselves.. namely Intel. Don't take my word for it.. Steve Blank a well know and well respected silicon valley insider came out earlier this year with a hot-button article which has been dismissed by many of naive types I described earlier. In the articles he outright says straight up.. The US government and Intel are working together on malicious microcode. And from the perspective of the NSA, it makes perfect sense to do so.