Secure Boot

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

λ signtest » pesign --hash --nopadding --in ./fwupdx64.efi
./fwupdx64.efi 788408ea495d2cd55f6d2d3b5e5d56e130c738917068f9e40b07d69ae79dfd51
λ signtest » pesign --hash --padding --in ./fwupdx64.efi
./fwupdx64.efi 33c1bfe9f9d60822df8c099f88ee841ded43f80471b71a9c2ec65a9a4a2ec132

This implies that if you where to enroll a SHA256 sum into the db security 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 padded binaries.

Eventlogs and OpROM


Secure Boot uses two types of signatures. PKCS7 and CMS.

CMS is mandated by Microsoft Authenticode

Security Expectations in Linux

Secure Boot History

  • 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


  • shim
    • loads the grub2 binary
  • MOKList
    • user enabled db autorization list
  • MokManager
    • UEFI program to manipulate the MOK database
  • mokutil
    • Userspace utility to issue requests to MokManager