Super-UEFIinSecureBoot-Disk VS ssh-tpm-agent

You can edit UEFI drivers from the operating system's bootloader, and you can even flash the UEFI itself from the OS in most computers. While secure boot. Failing that, you can shim a preloader between the bootloader and the UEFI and load arbitrary drivers despite secure boot, like is done here : https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk

Any sufficiently motivated attacker can make a UEFI rootkit happen, and it's in the wild right now. TPM really do offer no protection to users, either against userspace malware, or rootkits. It's purely about DRM.

Badabing badaboom

I was able to get around this by using a signed grub bootloader instead. What I did was modify a minimal grub disk from here to point to my manjaro installation using the partition uuid in its grub config. Its basically used to bypass secure boot and chainload the default unsigned grub2 which will start the system.

Try this if you want FreeBSD on a Secure Boot PC. I do this on my work PC.

This project works pretty good getting around the forced secure boot with the VCS: https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk

I've been hacking on `ssh-tpm-agent` which allows you to create or import TPM sealed keys. This is practical as it prevents key extraction and it has dictionary attack protection which allows you to have 4 digit pins instead of passphrases to protect your private keys.

https://github.com/Foxboron/ssh-tpm-agent

Currently hacking up better support for `HostKeyAgent` and `HostKey` for `sshd`.