cnvogel on AMI-Bios Sourcecode and UEFI Signing Key leaked?

Comment on AMI-Bios Sourcecode and UEFI Signing Key leaked?

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 13y

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 13y

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 13y

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 13y

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 13y

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 13y

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 13y

You are right. This could mean that the key just works on developer boards and is not the one used in production.

Comments