Here is what I have done:
- Generated my own SSL keys (db, KEK, PK) x (cer, key)
- Removed existing signatures from kernel, GRUB, shim (and all other EFI binaries in
/boot) and signed them with my own certificate (db).
- Rebooted and enrolled my certificates in UEFI (which moved it to User Mode).
So far so good. I was hoping that starting from this point, an adversary has only two ways of changing my bootloaders (GRUB):
- Go to UEFI and disable SecureBoot (=> needs a password)
- Compromise my private KEK key (or PK), which authorise changes in db (or KEK) EFI variable, which will allow adding another certificate, which can sign another bootloader.
What happens in reality, is shim DOES detect that GRUB is compromised/modified, it shows this:
ERROR Verification failed: (0x1A) Security Violation <OK>
and then, when I press
<OK>, it happily offers me to add another key(!)
Press any key to perform MOK management Enroll key from disk
Obviously, it breaks entire "chain of trust" - it makes all previous steps useless, in some sense it is a backdoor (I understand that it is trying to be helpful, too helpful probably...).
- Am I right? Maybe I missing something or misunderstood something? I had an impression that only owner of keys can replace bootloaders/EFI/kernels (otherwise, EvilMaid attacks become possible, stealing LUKS passwords becomes an easy task, and so on...)
- Are there workarounds? Can I remove MokManager (
mmx64.efi) completely? Is it possible to remove the behaviour, make it "less helpful"?
Just in case you were wondering, what about
grub.cfg / initrd... - I am using standalone version of GRUB that checks GPG signatures of everything it loads (