Notes on Intel Microcode Updates
inertiawar.com
inertiawar.com
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.
There's also an engineering reason to avoid doing this: persistent memory cells based on silicon have a limited number of write cycles.
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.
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.
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.
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.
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.
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.
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.
Am I missing something?
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).
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.
Plus, NSA has the capability to reverse engineer chips at the physical level.
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.
This is looking through the microscope to determine whether a forest is on fire.
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.
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.