I purchased a cheap UEFI based system that works with Linux as a backup machine. Since I'm using the librem key to access my data on a USB stick it means I have to get some things working on the second system also but I'd really like to secure it as much as the first system.
Started the setup of JTPV but it did not work by just copying binaries. Apparently I have not made it intuitive enough....
Updated this page for the latest notes on using the UEFI system. Upgraded to Kubuntu 21.10. still same issues as always. Installer is marginally better with encryption but I still have to hack my way to using LUKS for encrypted root.
Still using Kubuntu. Upgraded both systems to 21.04 which removes some of the hacks but still dont have much smartcard support. I am using encrypted root with smartcard unlock on both systems. the Heads system also uses the smartcard for 'secure boot' aka pureboot. I recently modified the script that decrypts root to fallback to passphrase if the smartcard is missing.
I am using poldi for command line sudo to look for the smartcard. It also falls back to passphrase. Unfortunately, nothing else I want to use the smartcard for is easy to setup and some seem to be impossible. In particular I want to stick with KDE and sddm which seem to be lacking in smartcard support for screensaver and login. Even GDM and gnome are difficult to configure for this. I have been unable to make it work for the last year. Each time I try I document and feel like I'm getting closer but Holy Crap this shouldn't be this difficult.
Using Kubuntu on both systems. The Librem system uses pureboot and the backup uses UEFI. The librem key is used to decrypt /root on both and for command line sudo. Secure boot on the backup system is enabled but I'm not sure that it is doing anything. Neither system uses the librem key for logins or screensaver unlocks--this didn't work consistently in PureOS so will probably take a lot of work on my part....
Deleted Centos 8. Can't take it anymore. Also order a RAM upgrade. 4G of ram is fine if I'm just browsing and email--maybe video too--but I'm actively coding on this thing using vscode, docker, aws, postgres, etc. It's swapping so much that it freezes for a minute or two. Not even the mouse will move.
UEFI can work with secure boot and I'd like to have a chain of trust from boot to the OS but this is a challenge.
This has been relatively easy to access on multiple distros once I figure out all of the dependencies. I have to install opensc and export the public key for my librem key into the user account. Also I have to hack missing settings into subsystems since one of my librem keys is so 'new' and upstream only recently got the changes. It will be year or more before distros get these changes. (more for Centos/Redhat I'm sure).
Each distro I have tried so far handles smart cards differently from different package names to file locations and even different packages altogether. It's amazingly uncoordinated but that's typical for Linux distros. I guess I'll just wait for systemd to swallow smartcards like everything else and then all of them will be more aligned.
Started with Kubuntu 19.10, then Centos 8, now Kubuntu 20.04,20.10,21.04,21.10. Secure boot is not working but I do have the root partition of Kubuntu on LUKS. Since the root is encrypted I can be assured that no one has tampered with my OS when the system is off. Grub supports LUKS but the boot partition is not encrypted at this time. The UEFI process launches grub which boots Linux and then asks for the passphrase to unlock root.
One approach that does not seem feasible at this time is to get grub to use the librem key and a PIN instead of a password. Grub would need to ask me for a PIN--which should be easy since it already asks for a password--and it would need to use that pin to access the smart card. This is where it likely gets tricky. smartcard devices require a different driver for each and this code would need to be integrated into GRUB. Technically possible? License issues? Maybe a grub module loading system could work?
This is the first windows system I have ever purchased and boot into it rarely. Though Windows subsystem for linux is installed it cannot use USB so I still have to boot into actual Linux to do anything useful with librem key and my data. Also I'm uncomfortable plugging my encrypted data storage into Windows. You know, black boxes and all ...
I don't think I've plugged the librem key into windows yet.... maybe but that's not my target platform.
Early on I disabled secure boot to get Linux installed but the latest installers attempt to set it up. I can't tell if it is working. When it's messed up it still boots which seems to me that defeats the purpose of Secure Boot.....
Early on I also installed rEFInd to manage the boot process. When I turned secure boot back on it boots but shows a message saying that verification failed. This makes sense. To get it working again I have to put something verified into the boot process. I think it might be possible to sign the uefi processes in the EFI partition based on initial research but reFIND will likely never get signed by the Vendor (Microsoft) keys which are presetup for secure booting.
Since I have multiple EFI boot processes on this system I was using a bootmanager to assist. Ultimately I neeed to use the windows and linux boot loaders for secure boot.
rEFInd loads code from the uefi partition so there isn't much to do here. If I want to secure the boot process using it I'll need to have the system sign the uefi boot manager code using the bios secure boot features. not sure that this is possible.
My latest attempt at securing the system is to use an encrypted root partition. Grub supports unlocking LUKS by prompting the user for the passphrase. Unfortunately, I want to use the smartcard which is much more difficult and maybe impossible. This requires modifying the initrd to use the smartcard to get passwordless bootup. Even though root is encrypted /boot is not.
The path of least resistance is to separate /boot and leave it unencrypted. This allows the kernel and initrd to be booted which can use regular processes to access the smartcard and so on. Unfortunately this leaves an attack vector as the boot process is unsecured. Still looking for ways to have secure boot cover this use case. the EFI partition is also not encrypted and the boot process runs code from there.
+ PIN instead of passphrase on boot
- have sign kernel+ initrd on every update
I'm using unencrypted boot and secure boot. In addition, I may have the smartcard sign the kernel+initrd files on kernel update:
+ dont have to sign the kernel and initrd
+ assured that no one has modified kernel or initrd when the system is off
- smartcard unsupported? Have to type passphrase at boot
On EFI system, Grub is booted from efi which accesses /boot. Grub could access smart card to check signatures for kernel and initrd. If not matching, prompt user. If match, boot.
On Pureboot/heads system, heads boots the linux kernel from /boot. heads manages and checks signatures of files in /boot using smartcard.
This seems very unlikely from the research I have done. I would have to code it all myself. Given the complex ecosystem surrounding smartcards this seems like a lot of work. If secure boot is working properly this should not be necessary. The TPM used by secure boot should be secured like the smartcard having private keys that cannot be recovered.