4 ms·
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 microsof
by cnvogel 14y ago
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.
- mjg59 14y agoThere'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.
- marshray 14y agoYou may have to remove the === BEGIN/END blah === header and run the result through 'base64 -d' first. openssl asn1parse (-text or -dump I forget) -inform (pem or der) -in [filename] 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.