3 ms·

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

by taway2012 13y ago

AsymetricCom 13y ago
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.
caf 13y ago
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.
- 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 ago
    I'd think you sign with private key and verify with pu lic key.
  - caf 13y ago
    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).
    - taway2012 13y ago
      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.

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

AsymetricCom 13y ago

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.

caf 13y ago

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.

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 ago
  I'd think you sign with private key and verify with pu lic key.
- caf 13y ago
  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).
  - taway2012 13y ago
    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.