Keepassxc: Interest in integration with OnlyKey

[onlykey]

It would be great if we could collaborate to add a new feature to support OnlyKey. This would allow each individual entry to be encrypted with a key and have the key stored safely offline. This would be similar to smartcard integration but unlike smartcards/tokens OnlyKey supports simplified driverless operation. How I visualize this working is on the setup screen have a forth option under "Challenge Response" where there is a checkbox for "Use OnlyKey".

Then when a new entry is created it is encrypted with a public key (RSA or ECC). When a user attempts to access each entry the ciphertext is sent to OnlyKey for decryption, user enters challenge PIN, plaintext is returned to app. For more info and some demos of existing apps to see how it works check this out.

[M-Pixel]

Does OnlyKey have a MCVE? A simple yet thoroughly commented C or C++ program that just does exactly and only this - encrypt then decrypt a message using OnlyKey - would make integration with KeePass (and other open source programs) a highly plausible community endeavor, potentially even a weekend project.

[michaelblyons]

Interested parties may also want to watch #2064.

[droidmonkey]

Completed with #3352

[schlomie]

I'm not certain this FR is addressed in #3352. Maybe @onlykey can correct me, but I think #1257 is asking for a new feature where separate key material is kept on the OnlyKey, and KeepassXC delegates the decryption of individual entries to the OnlyKey (much like how password store integrates with gpg smartcards.) #3352 expands the supported list of HMAC devices beyond just Yubikeys.

Not asking for this ticket to be re-opened, but there does appear to be some disparity. I'm not sure what @onlykey is asking for here is feasible or reasonable with the KPXC's current implementation, but it would be a pretty cool feature.

[droidmonkey]

What was asked for is infeasible with kdbx based databases and would require a complete rewrite of the application. You can achieve something similar by creating multiple database files that are encrypted by different challenge response slots on the onlykey.

[schlomie]

Yup, figured it would be infeasible.

Your solution would produce something _similar_, but doesn't really accomplish the same goal. The idea of offloading the decryption of individual entries to OnlyKey would allow the key material to reside only ever on the OnlyKey with absolutely no way of ever recovering them. Key protection would be greatly increased.

In fact, I would envision @onlykey could/would generate the decryption keys on-demand, similar to how they generate SSH keys, based on some inputs, allowing the "storing" of an unlimited number of entry decryption keys that are never seen outside the OnlyKey. Furthermore, every single entry in the database would have its own, unique, never-known decryption key. If your passphrase, keyfiles or master key were ever compromised, an attacker would only get a listing of the entries in the database. Secrets would still remain secret.

Of course, I may be way off from what @onlykey envisioned with this FR, but that's how I read it.

That said, no, you are absolutely right. This idea would completely break the kdbx file format and would no longer be keepass compatible. An implementation like this would be its own password manager unto itself.

Anyway, thank you for all your efforts! I'll stop bothering you now.

[onlykey]

@schlomie Yes, you are correct using challenge and response is not the same thing as encrypting and decrypting each entry individually. The idea behind this feature is that adding OnlyKey support with challenge and response is a small, easy to implement change while the original request as mentioned would be really nice to have but really hard to implement. It probably would be feasible to in the future implement a way to encrypt each entry (requiring user to press device each time logging in) but this would not be a small, easy to implement change. To keep data compatible with KBDX file format you would have to do something like encrypt the data, then encode the data in a format that works for KBDX, base 64 would probably work. Not feasible for now but possible.