File: PkKek-1.README

package info (click to toggle)
edk2 2020.11-4
  • links: PTS, VCS
  • area: main
  • in suites: sid
  • size: 187,752 kB
  • sloc: ansic: 1,595,106; perl: 161,094; python: 125,339; asm: 18,555; cpp: 16,555; sh: 7,382; java: 6,173; cs: 3,822; makefile: 3,173; javascript: 1,744; xml: 635; pascal: 402; lisp: 35; sed: 5
file content (35 lines) | stat: -rw-r--r-- 1,718 bytes parent folder | download | duplicates (4)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
Background on these keys is described below:

On 09/30/14 20:00, Peter Jones wrote:
> We should generate a special key that's not in our normal signing chains
> for PK and KEK.  The reason for this is that [in practice] PK gets
> treated as part of DB (*).
>
> [Shipping a key in our normal signing chains] as PK means you can run
> grub directly, in which case it won't have access to the shim protocol.
> When grub is run without the shim protocol registered, it assumes SB is
> disabled and boots without verifying the kernel.  We don't want that to
> be a thing you can do, but allowing that is the inevitable result of
> shipping with any of our normal signing chain in PK or KEK.
>
> (* USRT has actually agreed that since you can escalate to this behavior
> if you have the secret half of a key in KEK or PK anyway, and many
> vendors had already shipped it this way, that it is fine and I think
> even *expected* at this point, even though it wasn't formally in the
> UEFI 2.3.1 Spec that introduced Secure Boot.  I'll try and make sure the
> language reflects that in an upcoming spec revision.)
>
> So let me get SRT to issue a special key to use for PK and KEK.  We can
> use it just for those operations, and make sure it's protected with the
> same processes and controls as our other signing keys.

---

We include Debian and Ubuntu keys generated in this manner - i.e.,
not in our normal signing chains, and where the public key was not saved.
The Debian key was generated using the following command, taken from
commit be9470b3c9 "OvmfPkg/EnrollDefaultKeys: enroll PK/KEK1 from the Type
11 SMBIOS table":

openssl req -x509 -newkey rsa:2048 -outform PEM \
            -keyout /dev/null -out PkKek1.pem