It's amazing how much someone can determine about a "secure" system by poking at it, doing differential attacks, and timing attacks. Anyone trying to build something secure should take warning from this, especially since there are much, much more determined attackers.
As someone reverse-engineering the Z-80, I find this article interesting. Maybe 35 years from now, someone will post a full analysis of how this Intel chip processes microcode internally, answering all the questions raised by this article. It will be very interesting to find out if there's anything malicious in any microcode patches. Are there checksums of the microcode so you can make sure you're not getting "special" microcode updates?
Reply to mrb: I expect 90% of the purpose of the signature is to protect against untested or corrupted updates getting installed. (It would be a support nightmare if people installed microcode with errors.) Protecting against deliberate attacks is probably secondary; I doubt you could do a nontrivial attack without inside help.
To do that it would require some type of persistent memory on the CPU itself. You could open the chip and look for memory of this type, it requires certain special features to operate, and they're somewhat easy to pick out of a chip shot.
There's also an engineering reason to avoid doing this: persistent memory cells based on silicon have a limited number of write cycles.
I find analysis like this thoroughly fascinating. I wonder if the handful of Intel engineers who presumably crafted this would ever stumble into this post. Would they be impressed, or alarmed that someone is probing such a crucial mechanism?
Having talked with some Intel engineers about their microcode, they consider it a company secret that protects trade secrets about how their processors function and wouldn't say much of anything about it.
I suspect they would be slightly impressed that someone was able to find out as much as they did, but I don't think they would be overly surprised. I also suspect they would also be satisfied that this doesn't disclose anything sensitive about the contents of the microcode updates and just found out some information about the mechanism.
They definitely wouldn't be surprised that someone was probing microcode updates. A lot of us have asked them about it and they know people are interested about what's going on inside those blobs.
> I wonder if the handful of Intel engineers who presumably crafted this would ever stumble into this post.
They almost certainly will if they haven't already.
Yup, a lot of folks at the office enjoy skimming hacker news, ars technica etc. The number of people capable of actually signing microcode even in a company of 100,000+ is pretty darn small though.
You'd actually be surprised about how much effort goes into hardening things against attacks like those these days (timing attacks, differential power analysis etc). There's a lot of interesting work around on the best ways of mitigating those risks.
I wonder what is the attack scenario that the RSA signature of the microcode is supposed to protect? An attacker flashing a microcode that introduces specially-crafted bugs in certain instructions, in order to create backdoors?
That's one, but another scenario you forgot about is one where researchers would just fuzz the microcode update mechanism to try and figure out more about how the insides of the processor work. If you could get the processor to recognize your microcode updates as valid, you could determine information about how the processor deals with microcode internally by observing what changes after you send different update sequences.
Intel protects their trade secrets pretty fiercely and they don't talk about the processor's internal microcode representation. As much as many of us would really like them to let us know what's really going on inside there.
Bad drivers included with the original 8.1 preview builds had a habit of permanently bricking mobile 700 series gpus - I'm sure you could do the same with a microcode update! Imagine setting the default voltage to 5v and multiplier to something crazy high, and disabling thermal cutoff - unless you happen to be dumping LN2 on your cpu at the time, it's probably not going to survive!
Microcode updates shouldn't effect the thermal integrity of the processor.
Microcode updates update a specific part of the processor that does a specific thing, i.e. the translation between the input ISA and the processor's native microcode instruction set, it's not supposed to be a wholesale update of processor parameters. (But we don't know enough about the structure of microcode updates to be certain. But I think you're barking up the wrong tree here and likely should read up on how Intel processors actually use microcode.)
You certainly can brick a CPU by updating parameters like that, but you wouldn't typically update parameters like that via a microcode update.
My microcode experience is some years ago, and nothing nearly as complicated as modern Intel stuff, but depending on just what you can control, you might be able to induce excessive thermal gradients by working some bits flat out and disabling/not dispatching to others. I don't know if the effect would be anything like significant enough to cause damage, although I have seen an excellent project using thermal regional heating to "fingerprint" cores post-fab. I think that required some (but not excessive) physical layout constraints as well.
Modern Intel chips will automatically adjust their clocking if they detect that they're suffering thermal stress. Further, I'm not sure whether microcode has that level of control over dispatch. Especially given the trace cache design of Intel chips, it seems very unlikely that scheduling information would be encoded into the microcode instead of dynamically decided during the out of order execution.
Don't get me wrong, I'm not saying it isn't possible to affect the chip's thermal profile in any way via a microcode update, I'm simply saying it's not the simplest way to do it and I doubt that Intel protects their microcode as fiercely as they do because of thermal concerns.
Can somebody explain what extra security they gained by using an RSA-based signature as opposed to a straight-up HMAC (with the secret key burned into the CPU)?
This way all the CPUs out there contain the information required to verify an update, but not the information required to create a verifiable update. If there was a secret key burned into the CPU, you can be sure that it would eventually be discovered.
Maybe I'm missing something: the public key is present in the microcode update blob (according to the article), and CPU itself must have corresponding private key within it. The sender uses the public key to sign, the receiver uses the private key to verify.
If we stipulate that info burned into the CPU isn't secure against extraction, then an attacker can get the private key. Obviously, he can obtain the public key much more easily from then update blob.
And now they can generate malicious updates.
The security of even the RSA system seems to rest on the difficulty of extracting the private key from the CPU.
You do not sign with a public key; you sign with a private key and verify with a public key.
The presence of a public key within the update itself indicates that that public key must somehow be authenticated by the CPU. Two possible options are that the public key itself is signed by a master key, and the "master" public key is embedded within the CPU; or that the cryptographic hashes of all valid public keys are directly embedded within the CPU. The point of the second option would be to save area on the CPU die (a 256 bit hash can be saved in place of a 2048 bit public key).
Thanks, I think I understand now. The chip verifies the update using the public key present in the blob. But before doing so, it checks the public key against some whitelist of valid public keys.
The private key used to sign the blob is never present on the chip. Interesting. Seems pretty secure to me, and more secure than a straight-up HMAC.
Thanks for answering my questions. I know a little about symmetric crypto, and your explanation has been very useful to expand my knowledge.
Extra complexity. I imagine if there is a presumably existing secret key, that it's generated at run time by properties of the environment combined with the logic in the update to have known results for each chip, then matching logic is presumably part of an operation where the math is dependent on the key matching or "fitting". Thus you can get (some of) the security of an arbitrary length key without explicitly recording what that key exactly is.
You could spread out the mechanisms and various individual incremental tests of the "lock" throughout the update operation code so that an attacker would have to completely understand the entire codebase just to understand the locking mechanism instead of the locking mechanism being self contained function with a pass/fail output.
I would be quite impressed if NSA had the ability to write microcode updates themselves. I'd imagine they are not exactly trivial and require intimate knowledge of the actual silicon.
Which is why this guy is feeling around in the dark with bit-errors, because even though there are no secrets on the inside not a single one of intel's 104k employees is willing to throw this guy a bone. Right.
Donning tinfoil hat, NSA is just one part of USG. USG is one of hundreds of countries, zillions of criminal enterprises that would like to get intel's private keys and μcode format.
Given that intel is a large company the odds favor one/more external actors having access.
There's really no way to know without some sort of way for IDS to check μcode. Never going to happen due to the blackbox nature of closed, proprietary systems.
Or we could all just realize that for the time and effort of trying to write a backdoor into a general purpose CPU, which would need huge amounts of memory to be remotely capable of keeping track of code execution and to correctly make an OS remotely exploitable (you know, involving the network stack, probably TCP/IP and other things) rather then just crashing it...that it easier just to email someone an executable saying "I love you.exe" and wait for them to run it.
This is looking through the microscope to determine whether a forest is on fire.
Maybe, it will be one of the harder exploits to code, but very effective to disable certain apps or hide other backdoors. Reprogramming the microcode would be a virus-writer's dream come true, too. Knowing how to do it is probably very hard, as it is probably some RTL.
Intel started releasing reprogrammable microcode after the FDIV bug in the original Pentium made them replace a few hundred thousand CPUs. With programmable microcode, they could replace this operator.
As someone reverse-engineering the Z-80, I find this article interesting. Maybe 35 years from now, someone will post a full analysis of how this Intel chip processes microcode internally, answering all the questions raised by this article. It will be very interesting to find out if there's anything malicious in any microcode patches. Are there checksums of the microcode so you can make sure you're not getting "special" microcode updates?
Reply to mrb: I expect 90% of the purpose of the signature is to protect against untested or corrupted updates getting installed. (It would be a support nightmare if people installed microcode with errors.) Protecting against deliberate attacks is probably secondary; I doubt you could do a nontrivial attack without inside help.