Yes it one thing to get shim signed by Microsoft. Do remember
Microsoft is free to push out updates to the The Forbidden Signatures
Database(dbx).
Sign a new shim in case of current one being black listed for some
reason could take weeks/months from Microsoft.
The process to replace PK(platform key) and replace the KEK can be
done faster than getting a new shim.
Its also a safe guard against Microsoft changing the rules how shims
are constructions. Please be aware when Microsoft signing shims they
do not use the KEK that is used to sign the windows boot loader.
So windows bootloaders are signed with Microsoft Windows Production
PCA 2011 and debian shim will be signed with Microsoft Corporation
UEFI CA 2011.
https://technet.microsoft.com/en-au/library/dn747883.aspx
Now there is a line to OEM that should worry the heck out of us.
---On non-Windows RT PCs the OEM should consider including the
Microsoft Corporation UEFI CA 2011---
Key words "should consider" so making the "Microsoft Corporation UEFI
CA" key and everything signed by optional if it works or not.
Microsoft does not mandate OEM install "Microsoft Corporation UEFI CA"
only the "Microsoft Windows Production PCA" the one the debian shim
will not be signed with .So getting the shim signed by Microsoft
does not promise it works on every motherboard.
Manually installing Microsoft Corporation UEFI CA if OEM did not
include is replace PK(platform key) and upload new KEK set. At this
point might has well have the set of processes to install own KEK and
will require to provide users with the complete instructions to
replace the PK anyhow.
Also there appears to be no bug saying to put a system in place to
check that the shim had not been added revocation list as Microsoft
publishes it here http://www.uefi.org/revocationlistfile to allow
early response in case for some reason shim gets blacklist.
Secureboot is a mess. A single plan is not going to work.2 plans
are required.
1) A signed shim by Microsoft to reduce the number of people who have
to replace PK at first.
2) A plan to replace PK and use own KEK set containing the KEKs debian needs.
The interesting point from Microsoft OEM documentation is the
PK(platform key) rules.
Yes this is again
https://technet.microsoft.com/en-au/library/dn747883.aspx
1.3.3.3 PK generation
Two entries of very big interest.
--One per product line. If a key is compromised a whole product line
would be vulnerable--
And
--One per OEM. While this may be the simplest to set up, if the key is
compromised, every PC you manufacture would be vulnerable. To speed up
operation on the factory floor, the PK and potentially other keys
could be pre-generated and stored in a safe location. --
Debian is a product line or a OEM right so Debian install images can
ship with it own premade PK and KEK set/sets so user if required can
delete the PK and attempt an alternate functional set particularly if
the motherboard lacks the KEK the shim needs .Of course this does
not stop users making their own PK and KEK set latter and it not
against the rules to-do this.
Peter Dolding
