]>
Commit | Line | Data |
---|---|---|
a65627a8 TL |
1 | Background on these keys is described below: |
2 | ||
3 | On 09/30/14 20:00, Peter Jones wrote: | |
4 | > We should generate a special key that's not in our normal signing chains | |
5 | > for PK and KEK. The reason for this is that [in practice] PK gets | |
6 | > treated as part of DB (*). | |
7 | > | |
8 | > [Shipping a key in our normal signing chains] as PK means you can run | |
9 | > grub directly, in which case it won't have access to the shim protocol. | |
10 | > When grub is run without the shim protocol registered, it assumes SB is | |
11 | > disabled and boots without verifying the kernel. We don't want that to | |
12 | > be a thing you can do, but allowing that is the inevitable result of | |
13 | > shipping with any of our normal signing chain in PK or KEK. | |
14 | > | |
15 | > (* USRT has actually agreed that since you can escalate to this behavior | |
16 | > if you have the secret half of a key in KEK or PK anyway, and many | |
17 | > vendors had already shipped it this way, that it is fine and I think | |
18 | > even *expected* at this point, even though it wasn't formally in the | |
19 | > UEFI 2.3.1 Spec that introduced Secure Boot. I'll try and make sure the | |
20 | > language reflects that in an upcoming spec revision.) | |
21 | > | |
22 | > So let me get SRT to issue a special key to use for PK and KEK. We can | |
23 | > use it just for those operations, and make sure it's protected with the | |
24 | > same processes and controls as our other signing keys. | |
25 | ||
26 | --- | |
27 | ||
28 | We include Debian and Ubuntu keys generated in this manner - i.e., | |
29 | not in our normal signing chains, and where the public key was not saved. | |
30 | The Debian key was generated using the following command, taken from | |
31 | commit be9470b3c9 "OvmfPkg/EnrollDefaultKeys: enroll PK/KEK1 from the Type | |
32 | 11 SMBIOS table": | |
33 | ||
34 | openssl req -x509 -newkey rsa:2048 -outform PEM \ | |
35 | -keyout /dev/null -out PkKek1.pem |