KWallet Autologin: TPM, secure element, hardware features etc

Brainstorm
, , ,
1

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.

2 Likes
2

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?

1 Like
3

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
4

I’m using a 2 in 1 laptop where I found useful to login using a fingerprint (the user password is set up and can be used instead, but is less practical to login/unlock when the physical keyboard is not in use).
The HDD is not encrypted because I’ve segregated the “sensible” data in a specific folder that I’ve encrypted using plasma vault.
I’ve decided to do so, because I want to have the possibility to make offline images of the hdd as a “disaster recovery mean” using clonezilla and I want to be able to retrieve files from such images. So I create images with dd, but I would not be able to do that or to retrieve files from them if they were encrypted with LUKS (is it correct?).

So for the moment I’m forced to use an empty password in kwallet (which I have set up to send a notice every time an application accesses to it). but that is something that I do not like very much. In any case I think that for the moment my configuration is sensible for a situation where the main threat is a remote breach (the sensible data are always encrypted and are decrypted only when I use them) and also in case the PC is stolen (the thief will just know my wifi passwords which are on the kwallet and which i could easily change in the home router).

For me it would be great if it was possible, somehow, to mimic the google mechanism if a TPM is present so that if a successful login with fingerprint is made, the kwallet get automatically unlocked using the password stored in the TPM. If it is possible in the fore sable future, it would be great if it was in any case possible to unlock the kwallet with the user password.

Indeed I think that the TPM should store a specific password different from the user login one and meant to be used only for kwallet, but in any case it should be possible to unlock the kwallet using the user password so that in case of migration to anew PC, the user can still use the saved credentials before he is able to reconfigure the new TPM with the kwallet password.

In case a TPM is not present other authentication devices (like specifically configured USB keys) could be used in a similar way.

What do you think?
Is my configuration sensible?
Is it possible in the future to have something as proposed or there is any security flaw in my reasoning?

5

You can use the LUKS pin as the Kwallet password. Systemd ships a PAM module for that.

6

Your configuration is safe when the device is stolen, but not against the so called “Evil Maid Attack”, where the attacker, without you knowing, replaces the Plasma Vault program with a faulty one that sends your files to him when you unlock the vault later.

But that’s hardly a realistic scenario for most.

7

But I’m not using LUKS. So I do not understand how I could use the LUCK pin for the kwallet. Can you clarify, please?

8

This is very important!

9

I just did a bigger donation to KDE e.V.

I am no coder but hope that people that can work on these critical security topics can get enough funding.

Currently, Android or macOS are worlds more secure. Like, I can unlock separate apps easily using my fingerprint. My user account is encrypted with the secure element.

The integration is also still lacking for apps, like PGP, 2FA, or others. You could use your secure element like a security USB key, but this is not done normally.

1 Like