My primary system used to be a Librem 15 from Purism using a trusted boot (PureBoot) model where the boot process uses the smartcard (Librem Key) to verify that the files have not changed in an unencrypted boot partition (purism basically ignores the laptop line so I consider it not a good value for the much higher cost). I have moved to UEFI based systems which use secure boot. All systems use encrypted Linux OS partitions with smartcard based decrypt. The secure boot 'works' with linux but I dont think it is actually protecting anything. The boot partition is still vulnerable to evil maid attacks.
smartcard pin for auth
fallback to passphrase in all smartcard enabled processes
boot
login
sudo
secure boot that actually pays attention to what it is booting (for Linux)
encrypted partitions
Ideally, I type the smartcard PIN to get access. Smart Cards are designed to prevent brute force attacks. As long as I keep the smartcard secure and keep the PIN private I have reduced risk for my data and systems. When secure boot is fully implemented risk will be reduced further.
The smart card is used to open (decrypt) the LUKS container holding the root filesystem. The system prompts for the PIN associated with the smartcard.
If the smart card is not plugged in the systems allow me to type the passphrase for the LUKS container.
I use the smart card and PIN for login to the systems. Both console and Graphical logins accept smartcard PIN with passphrase fallback. Elevating access through cli sudo and graphical sudo prompts also uses the smartcard and PIN with passphrase fallback.
I'm also storing my data on an external device and backing it up online using encrypted backups. The smartcard is used to access this data.
I'm using keepassxc to store passwords with some of the browser based extensions to make use and management of them easier.
In theory I would try to use the Librem key to manage passwords since some of the smartcards have password management as a feature. My Librem Key is limited to 16 entries and I'm not sure how to do get it to store passwords. The docs for the Librem key--and Nitro key it is based on--are almost worthless on this aspect and google searching brings up noise.
found this. maybe it will help me get certificate based auth working: https://ubuntu.com/tutorials/how-to-use-smart-card-authentication-in-ubuntu-desktop#1-overview. Never finished c plugin. Now that systemd is swallowing another feature (cryptsetup management) I'll see how they are managing keys. Hopefully Pottering implemented something sane this time but I'm not holding my breath.
taking a break from smartcard work for a while. the next major issue will be the C plugin for cryptsetup to extract the key data from the json data in the header.
FINALLY!!! I was able to get everything working by using libpam-p11. I had to create a certificate and fix some dependency issues but all of the functionality I want is working. I documented it all.
The only thing I really want to change is how the gpg key is stored.
created merge request to get cryptsetup-smartcard upstream. It was rejected. The short story is that the code is not a part of cryptsetup. It is just bash scripts that call cryptsetup. I plan to complete the C plugin version of it and submit.
In addition, the maintainers all but demanded that I use the systemd implementation of smartcard integration. This shows a lack of understanding of what I am doing. Systemd is not in most Linux boot processes which is the main use case for me. In addition, I am reducing complexity for integrating smartcards and LUKS which systemd may also benenfit from.
Posted example code for putting gpg protected key into LUKS2 header.
I had to update both systems to Kubuntu 21.04. In addition, I modified the boot process so that if the smartcard is not available the process falls back to passphrase. This is more complicated than it should be. I still don't have graphical login or prompts working with smartcards though I have tried a few more experiments.
I finally have the Librem 15 booting Kubuntu 20.10 using pureboot and using the librem key for hard drive access on boot. I would still like to
modify decrypt_gnupg-sc to fall back to passphrase
smartcard for login
smartcard for screensaver unlock
smartcard for graphical sudo prompts
try qubes
In searching the web I found very little on using smartcard with screensavers in linux
https://docs.oracle.com/cd/E37838_01/html/E67470/scard-sctoscreensaver.html (solaris + gnome)
https://www.suse.com/c/configuring-smart-card-authentication-suse-linux-enterprise/(suse)
Though I would revisit the post from 2020-4-12 and give a status update.
I am not trapped in gnome since I'm no longer using pureos. YAY! I have lost the login using a PIN but there is potential to get it working with stock gdm. This means I have to type the passphrase for login. I use KDE for the desktop and don't think the KDE screensaver will work with a smartcard (yet) so password is needed there also. Of course any graphical sudo also requires a passphrase which has always been the case. I still use the pin+smartcard for bootup and command line sudo.
I coded around the smartcard locking which was causing it to not be found by subsequent processes. In my standard processes I kill the processes if the card cannot be found which allows the next step to work. I still have to type the PIN twice but that's ok. I think I'll need to build a daemon to help with those issues and because I'm having to use sudo a lot for these processes.
Finally, have Kubuntu 20.10 with encrypted root but not using librem key yet. Major mistakes on re-install:
heads requires separate boot partition
did not install grub bootloader which does not generate the grub.cfg file which is required by heads
I thought the grub files would be created even though I was skipping the bootloader install onto the disk. Grub is installed after all. Had to manually run grub-mkconfg. I also hope to patch heads to allow not having a separate boot partition.
Ugh! Re-installing has been a nightmare. Heads won't boot anything else I install so I tried PureOS 9 again but ran into a bug so that it won't install with encryption. Not having disk encryption is NOT an option. I started documenting the heads environment. Hopefully someone benefits from my pain.
PureOS is trashed enough that I can't get any work done with it. I plan to reinstall something else. I know I can get most of the librem key features working with Kubuntu and I plan to try Qubes.
Came across another discussion related to gpg and locking the smart card issue where the gpg author clearly states that the card-timeout option has never allowed a card to be unlocked after X time. It was only used in conjunction with another option and has not done anything since version 2.1 was released. Meanwhile the rest of the world is trying to figure out what is locking the card when it is launched so that we can use it without unplugging it multiple times.
The problem seems to begin after poldi is used by pam as part of the sudo command. It is likely that pam+poldi is the culprit. Ugh. Looks like poldi has a copy of scdaemon.conf? Looks like systemd is launching scdaemon so maybe it's systemd? This is stupid.
Came across a discussion about smart card daemons related to always on vs launch on demand in this thread. Doesn't solve anything but might be useful in researching fix for the 'who owns the card' problem.
I have KDE and Kubuntu 20.04 installed but almost nothing working for smart cards. I can use my custom setup for LUKS on USB but sudo, sddm, gdm, etc are not using the smart card or failing when trying.
I did get the smartcard working for encrypted root but secure boot is not fully setup. I tried using the bios menus to sign some of the UEFI code but still get messages that validation fails. It still boots which is good for this interim period while I get everything working.
I never got the smartcard to work with centos and I got sick of not having tools I needed to work so I abandoned it. Centos is OK but tracks so far behind debian based distros that installing anything created in the last 5 years is next to impossible. I guess you can call that 'stable'.
The elevated access feature of the desktop environments do not use the smartcard which means any time I need to elevate privileges I have to drop to a shell. not a problem for me but this will never be mainstream or even practical with these kinds of issues--and there are still many issues with smartcards.
I have NOT been able to get KDE to run on PureOS 9. I really miss KDE. Working in gnome is limiting and annoying in so many ways. I repeatedly have to find workarounds for things that I can do in KDE by default like tiling windows in corners. I have a big monitor and can fit a good sized window in each corner. Gnome only allows windows style snap to left and right but there is a gnome extension called gTiles which is an OK workaround.
I'm also trying to get a second system which is not Purism hardware half secured with the librem key. That system uses UEFI and dual boots with Windows.
There is an ongoing battle between GnuPG and the rest of the world regarding exclusive access to the smart card. See my writeup for details.
After a few more days I realize that having really strong passwords stored in a password manager on the desktop makes using them on a phone really difficult. I'm can move to a model where less important sites used from the phone get weaker passwords but that still leaves primary sites. Would rather have better integration with keepass and my phone. or something. Might need to use really long sentences for passwords that I can actually type out in a phone keyboard.
After a few days of using the Purism system my observations are:
+ passwords are rare
i have only typed passwords a few time as part of troubleshooting issues. This approach is working OK but it adds overhead such as more waiting for things to catch up and near constant unplug/plug + type pin. AND i haven't even implemented killswitch features to auto shutdown the vulnerable data after a period of time. YMMV
- smart card systems are flaky
Sometimes the card is not detected after having just used it a few minutes before. maybe there's a timeout issue? This happens on PureOS 9 and CentOS 8
Generally this is fixed by physical remove and replace of the smart card.
- gnome integration with smart card is really flakey
The most problematic so far is the gnome screensaver. It will sometimes detect the smartcard and other times not ( 50/50?). Perhaps this is related to the flakiness of smartcards in Linux? The fix for command line access ( unplug/replug) only works 20% of the time for gnome screensaver.
- get rid of the gnome keyring password
One of the most annoying 'features' of both KDE and Gnome is the keyring. The reason that it is annoying is because the stupid utility asks for a password on your first login but who can remember what their first password was on a system? Since most other systems encourage us to change the user password frequently and the keyring utility leaves the password at the initial one I can never get into it long term and ALWAYS end up deleting the keyring. That happens a few weeks after I get tired of ignoring the prompt and getting access denied because I don't know what the keyring password is.
GOOD NEWS!!! Since my new setup uses encrypted drives (where the keyring is stored) I don't need a password on the keyring. This works for me because I'm the only user of the system. I just set the password to empty on gnome keyring. (dont know about kde yet). I'd rather not use the keyring at all.
A better approach would be to integrate the keyring utility with the smart card so that unlocks work the same as the other subsystems I am modifying. A search for this finds mention of it on this page but it links to a DEAD howto. Idiots. https://wiki.gnome.org/Projects/GnomeKeyring/SecurityFAQ . There is a lot of bad blood between gnome keyring and pgp. gnome keyring has been a bad boy and can hijack gpg agent. And GPG takes an exclusive lock on the smart card which makes everyone unhappy. I'm going to defer this till later.