debian/PkKek-1.README

   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