The fact that modifying the observed public key doesn't change timing is not surprising: If the CPU is intended to verify the integrity of the microcode update using public-key cryptography, then the public key used to verify the signature must already sit inside the CPU itself. Everything else would be pointless.
The function of the public key inside the update is still somewhat mysterious. Conceivably, the signing public key is part of the microcode, and so it would be logical to have a field in the microcode update that can be used to change that signing key as part of the microcode update (so that subsequent updates can be signed with a new key). There are problems with that theory as well, especially that the author was unable to verify the supplied signature with the public key in the microcode update.
> This chart appears to also show artifacts from running this system on a multi-core system (note that the i5 2520M is a quad core processor, and that four main trend lines can be seen).
Errata: The article states that Intel Core i5 2520M is a quad core processor, but its a dual core hypertheraded design.
I'd been searching for a while to try and learn something about the microcode updates - what they did etc. No wonder I didn't find much, Intel have them locked up very tightly.
Not surprising, because of all the implications that bad microcode updates could have (and some of the DRM technology in newer models, like TxT, also relies on microcode); I've heard rumours that no single person at Intel has knowledge of the entire microcode update mechanism. There's probably several layers of obfuscation applied too, and despite there being very good evidence that e.g. RSA-2048 or some hash function is used, it's possible that it was deliberately a diversion from the actual checking that goes on. Transistors are cheap enough to Intel that embedding a complete separate CPU core inside (with a different architecture) to do things like this would be very easy.
On the other hand, I wonder how much government agencies know about this mechanism and ways they can make use of it; reverse-engineering the actual process from inspection of the die might take so long that it would never be practical. This is really security through obscurity, but it looks like Intel is betting on processors being so large and complex (and superseded relatively quickly) that reverse-engineering becomes infeasible.
Who would even have the knowledge to reverse engineer something like a modern intel processor other than ex-intel engineers? Would they even be able to do it in a reasonable timeframe(<5 years)?
Yes, there are a few people: I could not do it myself but I've worked with one or two who definitely could. You very probably cannot afford them, or their labs. And I doubt they would want to post or share their results openly, so though I am curious, I do not think I shall ask.
Why would someone? Perhaps a competitor wants to know if their design is being ripped off, or if a patent is being violated? Perhaps it is for other reasons sometimes. One simply does not ask about clientèle, you understand.
I gather it is mostly incremental work: as vendors seldom do from-scratch redesigns, most of the reversing is not from-scratch either.
The function of the public key inside the update is still somewhat mysterious. Conceivably, the signing public key is part of the microcode, and so it would be logical to have a field in the microcode update that can be used to change that signing key as part of the microcode update (so that subsequent updates can be signed with a new key). There are problems with that theory as well, especially that the author was unable to verify the supplied signature with the public key in the microcode update.