So I am hoping that all of you have not only an encrypted root disk, but also UEFI secure boot enabled. I am guessing that most of you have enabled that with the default (Microsoft) keys. Here I will outline how I changed methodology on my portable, and some of the challenges I ran into.
First, lets talk about the models of security. Encryption. You want your entire disk (100%) encrypted. This means when you turn the PC on, you must present a password (which is different than your login password, and predates it, it comes up very early). This is before your operating system loads. You want this password to be a) different than your login password, b) strong. It should be 30+ characters in length. Its a passphrase. What full disk encryption ensures is that when (yes when) your PC goes walkabout and ends up on ebay, that there is no change that randoms get access to your Snap archive (you know what i’m talking about).
Loading …OK, so that is what most of us consider “the big risk”. Its enough right? Wrong. What if a bad actor wants access to that disk? They could insert new bad firmware or bootloader in the chain, and then when you enter your password, they are in. Google ‘rootkit‘. What you really need is to make sure that the system is not tampered with in addition to not being read. And that is where secure boot comes in.
What secure boot does is create a chain of trust. Your machine boots, the bios is signed, it loads some keys from a trusted platform module (tpm). These keys are used to check that the first stage bootloader is not modified, and then it checks the next stage, etc. So each level attests the next level is trusted. Typically these keys are ‘default’ and managed by Microsoft, allowing you to load the Windows 10 bootloader, and onwards. But what if you don’t run Windows? Well, Canonical has a signed-shim (signed by Microsoft, and then it will load grub). And this signed-shim turns out to be not so strong. In fact, well, read the salty twitter stream on the subject, and, weakened the world.
OK, my tinfoil hat is starting to adjust properly, you mean that I have this risk and I should not trust the upstream Microsoft keys (cuz who else has those? Is there maybe some clipper-chip key escrow controversy etc?). Seems up my alley, how hard can it be to create a couple of self-signed certs and some passphrases?
Um, a bit. Since we are using Linux here, we are also using grub. So I need to get a signed copy of grub. And all the modules. And the config. OK, no problem, we can create a grub ramdisk, a sort of initrd, and make a single bundle of grub plus this with all modules, signed. And then we can insert the PK/KEK/db keys into our BIOS.
Fortunately, as you would imagine in the FOSS world, there is a plethora of partial solutions out there, all of which have some troubles 🙂 So I picked one, forked it on Github, and ‘fixed’ it. Here you go. What this does is ‘redirect’ update-grub, grub-install so that everytime a new kernel is built/installed, grub is updated and re-signed. The keys are stored in /etc on the full-disk-encryption, so safe.
OK, once this is in place, my PC will only boot my signed code, all the way up. Along the way it will ask for the encryption keys for the disk.
How could someone attack this?
Well, I need a BIOS supervisor password to prevent someone disabling secure boot. So that needs to be strong. If you want to be scared of this, google ALAA4ABA. No really. Did you do it? Sigh, some sort of ‘magic algorithm’. If someone can reset my date to a specific one, they can reset my password. Grr.
How else? Well, my disk now has /efi (vfat, not encrypted, but signed) and /boot (on the encrypted root). But I had to move /boot there, it defaulted to the non-encrypted part. This means someone could tamper with the old kernel there, and maybe trick me into re-signing it on the next run.
So… for those who have already enabled secure boot with your own keys, maybe comment on how you achieved it?
For those who have not enabled secure boot, I would recommend at a minimum enabling the ‘default’ keys, they work with Linux (at least Ubuntu, not sure on others) and also Windows.
For MAC users? Your immense sense of smugness is your primary (and only) protection. Only the iMac Pro supports security, so I would assume all your bases are belong to us.
For some of you, you will be using Microsoft BitLocker. I don’t think this should make you feel very strong.
Leave a Reply