This is some notes regarding secure boot quirks and misc issues I encounter.
Microsoft Authenticode apparently relied on crc in ancient iterations. This is important because this implies padding has no effect on checksums, thus the resulting X509 certificate we append to the binaries.
However with cryptographic checksums these do affect the resulting checksum.
This is with Trammells checksum patch:
λ signtest » sbsign --hash-only ./fwupdx64.efi # No certificates
λ signtest » sbsign --hash-only ./fwupdx64.efi.signed.gosign # Has certificates
This is made more explicit with
λ signtest » pesign --hash --nopadding --in ./fwupdx64.efi
λ signtest » pesign --hash --padding --in ./fwupdx64.efi
This implies that if you where to enroll a SHA256 sum into the
database, the checksum would be different depending if the binary has an
certificate or not. "Yay".
sbverify doesn't need to care about this distinction since it will never
actually have to deal with unsigned executables. Thus it can only care about the
Secure Boot uses two types of signatures. PKCS7 and CMS.
CMS is mandated by Microsoft Authenticode
- MOK was invented by SUSE (see mjg blogpost)
- MOK gives back the key management control to users and/or security admins
- shim was written for security pivot
- Can't be GPL licensed since the key material is part of the source
- loads the grub2 binary
- user enabled db autorization list
- UEFI program to manipulate the MOK database
- Userspace utility to issue requests to MokManager