Consider storing Passkey credentials in the device Secure Element

[pingu-the-penguin]

Checks

• I have read the Wiki, searched the open issues, and still think this is a new feature.

Explain the problem clearly and succinctly:

Passkey credentials are currently not stored in the Secure Element and doing so would greatly increase the security of your credentials. Of course this depends on the security of your Secure Element.

Describe the solution you'd like:

For passkey credentials to be stored in the Secure Element. https://developer.android.com/privacy-and-security/keystore. This can be optional as it not all devices have a Secure Element or a particularly strong one but for devices such as Google Pixels with their Titan M2 Secure Element, this would be a massive addition.

This would be similar to what Google Password Manager and this app already do.

Describe alternatives you've considered:

No response

Additional context:

No response

[J-Jamet]

Currently, KeePassDX stores Passkeys like any other encrypted entry in your secure file database. It's the all principle behind KeePass, to store encrypted entries in a single secure file.

What you are proposing is to place the KeePass keys in the Secure Element, namely the dedicated chip in Android devices that securely stores the keys accessible via the Keystore. This is a good secure storage solution (and is actually used to link biometric fingerprints to your KeePass master key), but it has the drawback of only being usable on the device where the KeePass file is located. This means that your KeePass file cannot be used on another device or operating system to access your Passkeys, and it doesn't allow for easy backups to restore your keys, which is very problematic.

Google Password Manager uses a very simple solution to address this problem: saving Passkeys also on their servers.
This is obviously something that will not be done here, as the goal of KeePassDX is to remain completely local so that the user can securely manage their credentials themselves.

One solution would therefore be to save the Passkeys in the Secure Element and offer the user the option to back up these keys in a separate encrypted file for use elsewhere, but the basic concept would be exactly the same as that of KeePass with added confusion.

Another advanced solution, which could become widespread for KeePass files on Android, would be to store a temporary master key unique to the device in the Keystore to encrypt the .kdbx file differently. With this solution, the entire file (because there's no reason why other saved credentials shouldn't benefit) would be re-encrypted, accessible only from the device. A file export system would then allow the file to be converted back into an exportable encryption format readable on any device.

I'm considering this and it could be integrated into the dedicated FileSync file manager, but it would be very experimental and the gain would be minimal; it would really only be for the paranoid.

If you're worried about the current storage, you can simply adjust the current security level by changing the encryption of your .kdbx file by sparingly increasing the KDF (Key Derivation Function).

[J-Jamet]

Basically, what you call a Secure Element here is a term that can be globalized; in my opinion, it means that it is a secure space where credentials and sensitive elements can be stored.

• What you initially had in mind is Android's Strongbox, which uses security hardware directly in the phone.
• It could also be an external hardware key, like a Fido2 or a YubiKey.
• Or a strongly encrypted file, as is the case with a .kdbx KeePass file.

[ttunturi]

In my opinion in the case of passkeys it is a benefit that the key is stored in a way where it can not be copied or synced anywhere. The whole idea about syncing them came about quite recently when the tech giants like Apple and Google started directing the technology their way. The only actual use case for syncing keys is family sharing where you could share for instance an HBO subscription or whatever among family members.

Using the keys in a way they were originally used before the tech giants became involved gives them another level of credibility. Every party knows that each key is unique and cannot be copied or messed with. You could even potentially do full hardware attestation for phones as well as the keys are signed by the phone. I don't know if the Secure Element signing certificates are in the official FIDO metadata or not because I haven't tested it. To my knowledge there aren't even any Passkey Providers for phones that save the keys in the Secure Element and do it like it was done originally. Is it even possible anymore with phones as the registration ceremony is handled by the phone and not the Passkey Manager?

The synchronizable vs non-synchronizable doesn't even have to be one or the other. It could be user-selectable even on a per-passkey basis.

[J-Jamet]

The key synchronization option can be selected using the Backup-Compatible toggle.
Putting Passkeys in the Keystore is feasible while this toggle is enabled, but it would require checking the database and moving all entries one by one. The benefit is very minimal in my opinion and hard to do, even it is technically feasible.

[ttunturi]

What is important to one user isn't to another. Most users probably don't know there are different types. There is however a substantial difference in credibility between keys that are stored in a secure module and ones that are stored as files in the phone's filesystem.

In my opinion passkeys "done right" on a phone are not much different from hardware authenticators while synchronizable keys stored in the phone's filesystem are not much different from using a password via a password manager. Depends on the use case which one would be acceptable.