KWallet Autologin: TPM, secure element, hardware features etc

In reply to this post about several Plasma issues (to keep stuff sorted)

To the point about: Why cant I unlock KWallet when using autologin?

KWallet, the password manager storing many things

  • wifi passwords
  • LUKS encryption passwords
  • probably SMB share passwords
  • some browser passwords, all in falkon afaik

has an encrypted file where these are stored. So if it is encrypted, how do you unlock it?

There is a service active that uses the PAM login mechanism from SDDM (the display manager, the first login screen where you also found so many bugs) and sends the password to kwallet.

There is some hashing etc in between but basically that.

The content is then loaded to RAM I think.

If you want autologin, you dont have a user password entered, meaning it is likely stored somewhere in plain text.

As this is only secure when using full disk encryption (LUKS), this would also mean such a kwallet could be stored in plain text.

In theory.

But KWallet is completely flawed. Any app can query any password, its basically “the X11 approach” and there are no permissions, no associated app IDs etc.

Do not store anything sensitive in KWallet, as it is damn insecure. Poorly it is integrated well, so the actual solution would be to implement some access control.

Then if KWallet access is secured, it has to be stored encrypted. How to do that with autologin? You would need some place where some secret is stored. This could be your TPM or a hardware USB key, Smartcard, Fingerprint etc.

That would be quite nice, but there are architectural changes that need to be done here that require interaction with the hardware.

Like Fingerprint / Pin unlock on a Google Pixel (with GrapheneOS): only with the secure element (a separated chip with own processor) and this second factor do you get the disk decryption key, loaded into a protected area in RAM. Even when using the same Pin for multiple user accounts, the key is different.

Without the secure element / TPM, you basically cannot unlock the phone. A reboot will clear the decryption keys from RAM.

I imagine touch-ID on macbooks works similarly, you have a dedicated chip with mini OS, that gets the second factor like your fingerprint or a pin, and then gives you the key.

Long story short: without hardware integration there is no chance for a secure passwordless login or KWallet unlock. And in certain scenarios also disk encryption.

BUT: this may be hardware specific, make OS features dependent on certain hardware subsets (like Win11 making tons of PCs obsolete, that may even now be an option for Linux), reduce flexibility like swapping disks, may complicate troubleshooting etc.

If your Android phone is bricked, your data is basically lost. This stuff is complex.

1 Like

Thank you for the in-depth reply. I do use LUKS, I thought if I didn’t but a KWallet password, that any application could read the wallet file or request any password, but you seem the suggest this is the case anyway?

Do you recommend I disable the option, in system settings, of “Enable the KDE wallet subsystem”?

I don’t understand why there is an entry for “Network Management”, I assume in this network passwords are found, if the KWallet key is in RAM to unlock it, or KWallet doesn’t provide security.

Do you recommend having the same password for user, as well as KWallet? Is having this a security risk?

The devs should fix/work on this ASAP, and that, something i do my best to never say, i dont want to create a burden or sound like a snob, but this is a big deal.

1 Like