There are a lot of comments saying this isn't feasible. I disagree. I don't mean this as an appeal to authority, but, since people are attacking Steve Blank's background, I used to design CPUs, and I've done pretty much everything except low-level stuff like layout (which I only did in classes).

I have no opinion on whether or not there is a backdoor, but, here are some possible mechanisms.

1. Periodic SMI on steroids. Intel used to have a debug mode based on an SMI++ like mode, where the chip would periodically dump the entire state of the machine out to memory. That's not nearly as useful for debugging now as it was 15 years ago, but it could dump out compromising information to some buffer that your network card DMAs out.

2. RNG weakness.

3. Put the machine into ring 0, with no other changes.

4. Put the machine into ring 0, while transferring control to some address.

5. Access to the microcode patch mechanism.

It took me about 15 seconds to come up with those ideas (I thought of 4 when I wrote down 3). Regardless of what you think of the NSA, they have the of the best security people in the world. They can probably figure something out.

Any of these things could easily be triggered by a sequence of obscure instructions. There are plenty of userland instructions that are never used today. An arbitrary sequence of, say, 20 of them is likely to never be discovered even by brute force attack. If you're really worried, you can load up a few registers with some specific values, and now you've got a 192-bit keysize (or more, if you want).

If you want to keep it secret from the companies themselves, you're probably better off using a secret register key in some microcode instruction, since that would be relatively easy to surreptitiously sneak in after the official tapeout. Looking for a sequence of instructions wouldn't be technically difficult (I doubt the decoder/translator is on the critical path, but, Intel's might be custom, in which case it would be a lot of work to find spare space), but, it would be more work to sneak it in seamlessly. Then again, they almost certainly have free gates lying around so that post-silicon bugs don't require a full-layer tapeout to fix. You could write a program that edits the right mask layers to access those and patch your change in. But, if those actually get used for debug purposes, you'd lose the ability to make the change seamlessly, and, it's much more work than the first approach.

I suspect '5' would require restarting the machine, although you could design a mechanism that lets you hot-swap microcode. Doesn't seem worth it, though, considering how easy it is to compromise a machine if you control the hardware.