Use TPM 2.0 PCR binding to allow password-less unlock after reboot on Linux

While I currently have no systems with the required TPM 2.0 chip, this is certainly a technology which 1Password should support on all platforms.

I don't think having to re-type a passphrase after reboot is that onerous. There are other features I'd prefer prioritized, one of them being easier setup of FIDO/U2F as an authentication mechanism so that, after my system locks, I don't have to retype the master password. _That's_ a pain.

+1 on this. Confirmed my system (Bazzite/Fedora Atomic, KDE) has a fully functional TPM 2.0:

 /dev/tpm0 and /dev/tpmrm0 present, PCRs available.

The systemd-cryptenroll precedent is exactly right; the hardware/software plumbing is already there on modern distros, 1Password just needs to hook into it the way it already does for Windows TPM.

Hello folks! 

Thank you for the feedback! I can see how it would make a real difference when using 1Password for Linux and I've submitted a feature request for our team to consider.

We really appreciate you taking the time to share how we can improve 1Password on Linux!

-Dave

Another Linux data point in support of this, plus two mechanisms besides TPM that would each solve it.

On 1Password 8.12.36 (Ubuntu 24.04 base, X11/XFCE, YubiKey via polkit/pam_u2f) system unlock works reliably within a running app session, but the key does not survive a restart — every cold start needs the account password first:

Sys auth status NotReady   <- right after app start; only password is offered

Attempting to unlock with master password.

Adding system unlock key. Verifying keysets can be decrypted.

Sys auth status Ready   <- from here on, security-key unlocks work

System unlock proceeding with DeviceEnclave backend.

The only backends that ever appear in my logs are MemoryEnclave and DeviceEnclave, and secret-tool search service 1Password returns nothing, so the key looks memory-only. One detail worth flagging: the app already has a security-key provider concept — the very first enrolment logged "Adding system unlock key for SK provider" — but that enrolment is gone after a restart too.

It is also worth noting the Windows equivalent already ships and has been confirmed officially: in "Stop requiring masterpass after every restart" an employee wrote that "there is an additional option to allow Windows Hello to persist through restarts if you have a hardware backed Trusted Platform Module (TPM) 2.0 in your device". My Linux machine has the very same TPM 2.0 at /dev/tpmrm0 — only the platform support is missing.

Besides TPM sealing as proposed above, either of these would also fix it on Linux:

FreeDesktop Secret Service (gnome-keyring / KWallet), unlocked by PAM at login — the usual place Linux apps keep this kind of state.

FIDO2 hmac-secret: derive the wrapping key from the security key itself, requiring touch and optionally the FIDO2 PIN. Key material never leaves the token, and it also covers people who want a PIN rather than a fingerprint. My YubiKey Security Key NFC (fw 5.7.1) advertises hmac-secret and clientPin.

Ideally an opt-in setting under Settings → Security rather than a default — some users will prefer the current memory-only behaviour.