Yes, but you'd expect the key (Keys/FW/.priKey) to be accompanied by some useful metadata (naming the entity the key belongs to, and a certificate from microsoft validating the key) to be added to the firmware image, wouldn't you? And if there's only certificates containing "DO NOT USE" text?
But certainly, I have no idea about all that. If someone could post commands how to verify (or at least dump) connection between DER encoded RSA keys and the PK/KEK/db/dbx files (which seem to have a 40byte header, then, again DER data)... that could shed some additional light on these matters.
There'd be no reason to expect the firmware signing key to have any relation to any of the certificates used in Secure Boot. They're used for separate purposes.
Comments
Yes, but you'd expect the key (Keys/FW/.priKey) to be accompanied by some useful metadata (naming the entity the key belongs to, and a certificate from microsoft validating the key) to be added to the firmware image, wouldn't you? And if there's only certificates containing "DO NOT USE" text?
But certainly, I have no idea about all that. If someone could post commands how to verify (or at least dump) connection between DER encoded RSA keys and the PK/KEK/db/dbx files (which seem to have a 40byte header, then, again DER data)... that could shed some additional light on these matters.
There'd be no reason to expect the firmware signing key to have any relation to any of the certificates used in Secure Boot. They're used for separate purposes.
You may have to remove the === BEGIN/END blah === header and run the result through 'base64 -d' first.
The private key should list 'P', 'Q', and the 'modulus'. If the modulus is the same as in the public key, it's the same.