5 ms·
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 k
by taway2012 13y ago
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.
Am I missing something?
- narag 13y agoI'd think you sign with private key and verify with pu lic key.
- caf 13y agoYou 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).
- taway2012 13y agoThanks, 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.