

Notes on Intel Microcode Updates (2013) - nkurz
http://inertiawar.com/microcode/

======
nhaehnle
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.

------
bestham
> 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.

------
muppetman
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.

Fantastic reading.

~~~
userbinator
_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.

~~~
Igglyboo
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)?

~~~
AlyssaRowan
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.

------
agumonkey
the author's other articles are worth reading too
[http://inertiawar.com/](http://inertiawar.com/)

