You are not logged in.
We have some machines that require certain secureboot certs, and we also require the microsoft one to NOT be present.
The steps to do this on most BIOSes are weird (clear everything, reboot, disable secureboot, reboot, set flag that allows upload, reboot, upload, reboot, enable secureboot)... but manageable. Things work fine. Booting anything with the MS certs would fail secureboot, and with our keys would pass.
Until we have BIOS updates from HP. Most HP machines will reinstall the MS certs. No big problem. It still kept ours. We just had to redo the dance.
Except, this time we have a BIOS update and I looked around before resetting everything, and here is the weird part.
Despite being able to boot anything signed with the MS certs (windows 10 and 11 install. shim, etc) using efi-readvar I can only see my corp certs! it doesn't show the MS ones.
# efi-readvar
Variable PK, length 1351
PK: List 0, type X509
Signature 0, size 1323, owner abc
Subject:
CN=gcb Platform Key
Issuer:
CN=gcb Platform Key
Variable KEK, length 1359
KEK: List 0, type X509
Signature 0, size 1331, owner abc
Subject:
CN=gcb Key Exchange Key
Issuer:
CN=gcb Key Exchange Key
Variable db, length 1371
db: List 0, type X509
Signature 0, size 1343, owner abc
Subject:
CN=gcb Signature Database key
Issuer:
CN=gcb Signature Database key
Variable dbx has no entries
Variable MokList has no entries
is this normal? What is allowing the microsoft signed code to run here?
Offline
I can see a "KEKDefault" value in efi but doesn't seem to be related
# efivar -l | grep KEK
abc-KEK
abc-KEKDefault
# efi-readvar -v KEKDefault
variable KEKDefault is not a UEFI secure boot variable
# efi-readvar -n abc-KEKDefault
GUID: abc
Name: "KEKDefault"
Attributes:
Boot Service Access
Runtime Service Access
Value:
00000000 a1 59 c0 a5 e4 94 a7 4a 87 b5 ab 15 5c 2b f0 72 |.Y.....J....\+.r|
00000010 ce 04 00 00 00 00 00 00 b2 04 00 00 31 6b a9 f5 |............1k..|
00000020 a0 db aa 4f a4 2a 7a 0c 98 32 76 8e 30 82 04 9e |...O.*z..2v.0...|
00000030 30 82 03 86 a0 03 02 01 02 02 10 01 3b d6 74 4b |0...........;.tK|
00000040 b8 84 9b 30 49 7c b2 21 d0 aa 13 30 0d 06 09 2a |...0I|.!...0...*|
00000050 86 48 86 f7 0d 01 01 0b 05 00 30 3d 31 0b 30 09 |.H........0=1.0.|
00000060 06 03 55 04 06 13 02 55 53 31 10 30 0e 06 03 55 |..U....US1.0...U|
00000070 04 0a 13 07 48 50 20 49 6e 63 2e 31 1c 30 1a 06 |....HP Inc.1.0..|
00000080 03 55 04 03 13 13 48 50 20 49 6e 63 2e 20 4b 45 |.U....HP Inc. KE|
00000090 4b 20 32 30 31 36 20 43 41 30 1e 17 0d 31 37 30 |K 2016 CA0...170|
000000a0 31 32 30 30 30 30 30 30 30 5a 17 0d 33 33 30 31 |120000000Z..3301|
000000b0 31 36 32 33 35 39 35 39 5a 30 5a 31 25 30 23 06 |16235959Z0Z1%0#.|
000000c0 03 55 04 03 0c 1c 48 50 20 55 45 46 49 20 53 65 |.U....HP UEFI Se|
000000d0 63 75 72 65 20 42 6f 6f 74 20 4b 45 4b 20 32 30 |cure Boot KEK 20|
000000e0 31 37 31 12 30 10 06 03 55 04 0b 0c 09 43 4f 44 |171.0...U....COD|
000000f0 45 2d 53 49 47 4e 31 0b 30 09 06 03 55 04 06 13 |E-SIGN1.0...U...|
00000100 02 55 53 31 10 30 0e 06 03 55 04 0a 0c 07 48 50 |.US1.0...U....HP|
00000110 20 49 6e 63 2e 30 82 01 22 30 0d 06 09 2a 86 48 | Inc.0.."0...*.H|
...
The values are reported as
file -k ...
PGP Secret Sub-key -\012- OpenPGP Secret Key\012- data
not that familiar with pgp envelopes for certs and keys. So let's download the actual KEK (mine) and compare
$ strings KEK.bin
gcb Key description ...
... few other short strings
$ strings KEKDefault.bin
HP Inc.1
HP Inc. KEK 2016 CA0
170120000000Z
330116235959Z0Z1%0#
HP UEFI Secure Boot KEK 20171
...
{KAH
Washington1
Redmond1
Microsoft Corporation1;09
2Microsoft Corporation Third Party Marketplace Root0
110624204129Z
260624205129Z0
Washington1
Redmond1
Microsoft Corporation1*0(
!Microsoft Corporation KEK CA 20110
...
Is KEKDefault value used as a secureboot key somehow? Is this standard or a crazy HP custom thing? I've seen KEKDefault on HP and Dell and always assumed it was used to reset the keys on the bios.
Offline
confirmed with sbverify the binaries i assumed were only signed with MS cert are indeed only signed with the MS cert.
Offline
Bump. anyone seen this elsewhere?
The BIOS seem to accept the MS cert if i'm booting a payload signed with it. But if I boot something signed with the keys I actively configured, it will lie that it doesn't have the MS root certs.
I didn't have much time to investigate this further as it is a back up device that didn't have to be used still... but that is weird. Next i plan to figure out how to debug things in windows (which is the EFI payload that does boot under secureboot and is only signed by the MS keys) and investigate what I see from there.
Offline