5 ms·

I admit that I have no idea at all about all that UEFI signing stuff, but the only thing in the "Keys" directory that does not look completely like random data

by cnvogel 14y ago

I admit that I have no idea at all about all that UEFI signing stuff, but the only thing in the "Keys" directory that does not look completely like random data is this, and "DO NOT TRUST - AMI Test PK0" looks more like something I'd distribute among my development team for testing, but would definitely not be the real thing: $ strings Ivy_Bridge_018s/Keys/Variables/db 4}7Ve 0%1#0! DO NOT SHIP - AMI Test KEK0 110823215243Z 120823215242Z0%1#0! DO NOT SHIP - AMI Test KEK0 (...) $ strings Ivy_Bridge_018s/Keys/Variables/KEK 4}7Ve 0%1#0! DO NOT TRUST - AMI Test PK0 110823215221Z 120823215220Z0%1#0! DO NOT TRUST - AMI Test PK0 (...) $ strings Ivy_Bridge_018s/Keys/Variables/dbx 4}7Ve 0.1,0* #DO NOT SHIP - Microsoft Test KEK CA0 110506224835Z 121106224834Z0+1)0' DO NOT SHIP - Microsoft Test KEK0 (...) $ strings Ivy_Bridge_018s/Keys/Variables/PK 4}7Ve 0%1#0! DO NOT TRUST - AMI Test PK0 110823215221Z 120823215220Z0%1#0! DO NOT TRUST - AMI Test PK0 )MCn D5g( (...)

qb45 14y ago
Asymmetric keys do look like lots of completely random data. What you've found is likely some kind of fingerprints (hashes). If there are indeed some keys on this server they could be real, after all this code wasn't supposed to ever go public.
- 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 ago
    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.
  - marshray 14y ago
    You 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.
js4all 14y ago
Those are certs. The private key is in /018s/Keys/FW/.priKey and starts with: bash-3.2$ hexdump .priKey | more 0000000 30 82 04 a3 02 01 00 02 82 01 01 00 ed 71 d6 3f 0000010 21 ff 0b 45 63 a4 3d 87 1d 22 44 8f c9 b5 84 08 0000020 29 5b 59 dc 0f 30 d2 a9 4f 52 e1 f2 97 51 0b b5
- cnvogel 14y ago
  It's more readable with openssl rsa -inform DER -in Ivy_Bridge_018s/Keys/FW/.priKey -text But still, I don't know how to verify that this key is not the one refered to by the "DO NOT USE" certs (which, to me, sounds pretty reasonable to assume).
  - js4all 14y ago
    You are right. This could mean that the key just works on developer boards and is not the one used in production.

by cnvogel 14y ago

qb45 14y ago

Asymmetric keys do look like lots of completely random data. What you've found is likely some kind of fingerprints (hashes). If there are indeed some keys on this server they could be real, after all this code wasn't supposed to ever go public.

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 ago
  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.
- marshray 14y ago
  You 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.

js4all 14y ago

Those are certs. The private key is in /018s/Keys/FW/.priKey and starts with: bash-3.2$ hexdump .priKey | more 0000000 30 82 04 a3 02 01 00 02 82 01 01 00 ed 71 d6 3f 0000010 21 ff 0b 45 63 a4 3d 87 1d 22 44 8f c9 b5 84 08 0000020 29 5b 59 dc 0f 30 d2 a9 4f 52 e1 f2 97 51 0b b5

cnvogel 14y ago
It's more readable with openssl rsa -inform DER -in Ivy_Bridge_018s/Keys/FW/.priKey -text But still, I don't know how to verify that this key is not the one refered to by the "DO NOT USE" certs (which, to me, sounds pretty reasonable to assume).
- js4all 14y ago
  You are right. This could mean that the key just works on developer boards and is not the one used in production.