[pve-edk2-firmware.git] / debian / PkKek-1.README

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