There are several reports about hardware based attacks on IT-security as for instance those here:

duckduckgo-search using "nsa intel backdoor" easily yields much more comparable results and I am unsure if this is indeed a threat or if it is simply extreme paranoia. I have to admit that it makes much sense to me to temper with a cpu as if the concept works passwords by definition must be accessible in most cases, as the cpu will sooner or later "work" with them. Another thing that makes me think that there is some truth to the CPU-backdoor idea is that with the high level of complexity (millions of transistors) it is imho not out of the question that a certain subpart of the chip can be decicated to backdoor purpose while not making it a very obvious thing.

My question is if the concept "to embed a backdoor in a CPU (or bios chip)" is not something to really be eventually considered?

  1. Is it possible to do it?
  2. If done, what are the implications upon further security measures like disk encryption or linux security modules kind of access control?

Assuming it cannot be finally decided if there is or is not a CPU backdoor, what would be a reasonable approach to encounter the problem, manufacture own cpus? i.e. Open source hardware?

  • 2
    Voted to close as largely opinion based since likeliness is a subjective term Aug 8, 2013 at 6:54
  • maybe likeliness is against your strict pure "stick to the rules"-thing for asking question. Sorry. asking "is it possible is not. I will if needed -and possible- edit the topic. The concern inside the question is valid I would recomend against closing. thank you Lucas Aug 8, 2013 at 7:17
  • 1
    @humanityANDpeace the problem with you question is that we cannot talk about concrete things but can only guess. This is not a good thing for the SE network. We will not be able to give one definitive answer...
    – Uwe Plonus
    Aug 8, 2013 at 8:21
  • There are rules you should abide them. This distincts stackexchange from other sites like yahoo answers. If you want to hold a discussion feel free to use the chat rooms. But please avoid asking these questions as they are not practically answerable with facts. Aug 8, 2013 at 9:38
  • 2
    The question is not false, but it is not suited for this website. As said take it to a chatroom. Aug 8, 2013 at 11:03

3 Answers 3


There is no actual evidence of any backdoor and it would be nigh impossible to check anyway, save by "opening" the case and inspecting all the transistors one by one, with an electronic microscope -- there are billions of them, so this is not feasible. Backdoors of that magnitude tend to be revealed by disgruntled insiders, not by external analysis.

However, we can discuss the physical possibility. The articles you link to are confused messes of poorly used terminology, based upon some misunderstanding of about three concepts. These are:

  • microcode updates;
  • reflashable firmware;
  • hardware random number generators.

Microcode is instructions for a CPU-within-the-CPU. This relates to the traditional way CPU were implemented: a number of elementary blocks, which, for each instruction, are activated or not; the microcode describes the "activation sequences". Microcode can be thought as the software implementation of an emulator which interprets the opcodes in RAM that we think of as "machine language". However, in modern CPU, most opcodes are "hardwired" and microcode is used only for complex operations like fsin (computes the sine function on a floating point operand in x86 CPU). This answer contains a much more detailed description of what microcode is and what it can do.

In the CPU, the microcode is stored in ROM but is copied upon boot in a small static RAM element (still within the CPU), which is faster but also updatable. Thus, upon boot, the OS can upload some new microcode into the CPU, and it will be used until next poweroff. OS do that. The microcode format is very specific to each version of each CPU, it is not standard, it is not documented, and it is protected by unspecified cryptographic algorithms, so that a microcode update is, from the point of view of the OS, an opaque blob straight from Intel or AMD.

Microcode opens the possibility of a hidden backdoor. The CPU, by itself, has no network; it runs within the context of the current RAM and hardware and the OS orchestrates all communications. If a backdoor is planted in the machine, it still has to be exploitable from the outside, otherwise it is useless. the story, here, hinges on the opaqueness of the blob: supposedly, the NSA, working with Intel, could craft some specific microcode update which, when uploaded into the CPU, makes it scan the RAM to explore the OS kernel structures and alter them, adding a more common software-based backdoor. This microcode update would then be handed over to Microsoft, to be included in the next Windows update. In that case, Microsoft would be the victim, their OS unwillingly pushing the backdoor code into the CPU.

Such activity is risky, because of the possibility of detection of the runtime manipulation of OS code and structure. It suffices that some amateur somewhere plays with DMA to dump physical RAM into some other device and then uses a debugger to explore the live OS code. Spy agencies, as a rule, abhor risk. Thus, while theoretically possible, I deem the planting of a microcode-powered backdoor rather improbable: not that it cannot be done (it can), but it seems exceedingly hard to do properly. In my opinion, NSA would resort to such games only if easier paths have been closed, and it turns out that they have not. See below.

Firmware updates are actually out of scope of the question. This is not about the CPU or Intel; this is about pushing malicious code into the various Flash chips in the hardware elements which have such chips -- namely, many peripheral but not the CPU itself. Some demonstration called Rakshasa was made and gained some fame, although the implications are rarely well understood or explained. In particular, it does not take any kind of NSA-like political power to make such a virus; quite the contrary: pushing code into reflashable firmwares is open to everybody who could get his own malicious code to run on the machine with sufficient privileges. In that matter, what NSA or Intel could do, some schmuck programmer in Moldavia could do, too.

(I apologize if you are a Moldavian developer and felt offended.)

The yummy part, though, is in the possibility of rigging the PRNG. All crypto-related activities, in particular key generation, ultimately come down to the production of pseudo-alea which should be indistinguishable from pure randomness. Operating systems do that by gathering hardware events such as precise timing (to the nanosecond) of the arrival of hardware interrupts. Hardware interrupts occur for every key stroke, mouse movement, network packet, and so on. There is an assumed "jitter" in the exact timing of these occurrences, which (that's the crucial point) cannot be measured outside of the computer with enough precision, so that's "unknown data" (for the attacker) which can be used to power the PRNG.

Gathering hardware events like that is challenging in some contexts, especially virtual machines in servers, fresh upon boot (since they only have fictitious hardware, they tend to be much more reproducible, leading to a guessable PRNG state). To make things better, CPU vendors now provide hardware RNG which include some specific electrically unstable circuitry (like a Zener diode in reverse): such hardware is integrated in the CPU, accessible from VM, and produces "true randomness" with an acceptable rate.

Internally, the random events from the randomness-generating circuitry is first post-processed in a specific circuit which turns the physical measures into a sequence of bits which can be handed to the OS (which will then use hash functions to obtain a seed for its PRNG). It is conceivable that the post-processing stage be modified so that:

  • the hardware RNG will look random, and be indistinguishable from true randomness;
  • unless you know some secret "key" also embedded in the circuit, which would allow to unravel the system and rebuild the random events;
  • and even if the circuit was completely reverse-engineered, it could still look like a perfectly honest mistake, not a deliberate rigging.

So this would give a "backdoor" which leaves no trace (no need of microcode updates to push through the OS updates), is not detectable from the outside, and even comes with plausible deniability. Practical implementation would be a kind-of hash function which "unfortunately" includes a carry-propagation bug which reduces the internal state to something like 50 bits or so, thus within range of exhaustive search. The reference implementation of bcrypt had such a bug, and nobody saw it for several years, despite the implementation being software and opensource (!), and yet nobody supposed that the bcrypt author did it on purpose.

If I were the NSA or some other similar agency, and I wanted a backdoor in every computer on the planet, I would do it through the hardware RNG. This is the low-risk path.

  • There have been backdoors like the ones in chinese produced routers Aug 8, 2013 at 12:06
  • @Thomas Pornin Thank you for your enlightening review and answer. I liked it very much! Aug 8, 2013 at 12:13
  • Backdoors in modern hardware is a given. The hardware recommendations from libreboot.org will help protect you. Feb 24, 2016 at 3:36

Is it possible to do it?

It is definitely possible to do this.

If done, what are the implications upon further security measures like disk encryption or linux security modules kind of access control?

You are basically screwed if your hardware is compromised. You can never be sure any methods you use are actually working.

Assuming it cannot be finally decided if there is or is not a CPU backdoor, what would be a reasonable approach to encounter the problem, manufacture own cpus? i.e. Open source hardware?

You can certainly manufacture your own CPUs. You also have to manufacture your own GPUs, RAM, hard disk, network cables and so on....

I think it would be easier to lock yourself inside a cabin in your nearest woods with a shotgun and wait for the NSA to come knocking eh?

  • thank you @Terry for you input. Nonetheless I would enjoy a little less ridiculation. The concern is valid. It is imho ignorant to discard a threat and its implications only upon it is hard to act 100% on it. The suggestion of "the lock-in in a cabin in the woods" is not that helpful at all. why? Aug 8, 2013 at 7:20
  • Maybe suggesting a "honeypot/traffic" monitoring approach involving several distinct hardware components would be a more helpful suggestion. After all making hardware backdoor costs totally comprising all main cpus manifacturere is driving costs high. I am uncertain but I think it would be better then leaving society for good. Aug 8, 2013 at 7:27
  • It's highly complex attack to do and while possible would require large cooperation from different companies. Honestly I find the question a bit ridicule because you can predict the outcome quite easily yourself. Aug 8, 2013 at 9:40
  • Recent events with regard of spionage networks NSA's prism and GCHQ Tempora show that such an extend is not entirely unthinkable. Also how many CPU manufacturers do we have? On a level of PC cpus there is mostly Intel and AMD chips. Also I cannot wholy see the point about the questions "bad quality" it basically asks, can hardware (i.e. cpus) have backdoors yes/no? It is clear that by asking the question I most likely have no conclusive answer myself. Still the question is clear and not as bad as suggested. sorry Aug 8, 2013 at 10:54

In short, no. Even backdoors in hardware would still need to communicate through ethernet adapters, routers, IDS and more which are always under scrutiny - they would shortly be detected and we'd know about it, just like new malware.

  • thank you @user2089851 Because of course the scrutiny itself cannot be tempered? Because the communication will be very obvious allways? If the hardware is hacked what makes you certain that the backdoor will not only be very rarely used? Given the higher investment of planting a hardware backdoor it makes sence to argue that it is better hidden. Can you backup your statements agains those objections? Aug 8, 2013 at 11:50
  • 1
    Not neccessarily: if an attacker would tamper with a hardware RNG (also comes with some modern CPU's) used for cryptography, or could influence the enropy sources the OS uses to seed its PRNG with, then they could make the device in question generate numbers that are indistinguisible from random numbers, but are still predictible to the attacker. You could only find out about this by examining the inner workings of the random number generator or entropy sources (which may be incredibly difficult or expensive) but you cannot detect it by simply examining the in- and output of your machine. Aug 8, 2013 at 12:03
  • This doesn't seem to be a backdoor... Aug 9, 2013 at 10:56
  • I can think of a UEFI/BIOS/firmware backdoor that stores private keys, handed over by OS-level backdoors in flash, EEPROM, NVRAM or hidden HDD memory areas to be extracted by physical access of intelligence agencies. Further any attacker wouldn't be that reckless to send passwords via TCP/IP to iameval.gov. They could also "encode" it in timing differences of innocent, periodic DNS requests or such. Weakening the HRNG was already mentioned. Jan 1, 2016 at 17:17

Not the answer you're looking for? Browse other questions tagged .