TREZOR Integration

[prusnak]

There is a hardware wallet called TREZOR which is capable of doing non-concurrency related things such as encrypting/decrypting stuff.

I am starting this meta-issue to explore various possibilities of integrating this device into KeePassXC.

TREZOR has its own Password Manager, which is unique because it does not use master password. This is possible, because TREZOR can generate various keys on the fly in a deterministic manner. Passwords in each database row are encrypted again using a different key, meaning that if you decrypt one password, the rest is still encrypted and thus protected from malware. This is not true for all password managers I have seen and thus a big advantage.

Integrating TREZOR as second factor (meaning it just adds entropy to master password) or using TREZOR to provide master password completely, are also options, but not as interesting as the first one.

My question is the following: is it possible to modify KeePassXC in a way that

a) master password is fetched from the device rather than typed by the user? (device will get filename as a parameter, so it can return different master passwords for each file)

b) each password is encrypted again using a key provided by the device (again, device will get position in tree or some other identifier to be able to generate different keys for every database entry)

I am able to design solution when it comes to TREZOR (i.e. how to get the communication right, what to send into the device and how to interpret the results), but I am quite clueless about what is possible or not at the KeePassXC side of things.

[tungfa]

+ would it be possible to save the keeptssxc '.kdbx' file on a TREZOR ? that would be amazing and save me another devise to schlep around ! tx

[TheZ3ro]

Integrating TREZOR as second factor (meaning it just adds entropy to master password) or using TREZOR to provide master password completely, are also options, but not as interesting as the first one.

I think this is possible, like we have done with the Yubikey.

The first option instead isn't very trivial to implement without knowing how it works, do you have some specific documentation I can look up?

Anyway, not having a TREZOR makes thing more difficult

[prusnak]

Internals of our password manager are documented here: SLIP-0016. It uses function we call CipherKeyValue documented here: SLIP-0011.

TL;DR: TREZOR derives all keys from its master entropy (256-bits) using CKD (child-key derivation) function, creating a so called deterministic hierarchy of keys (documented here: BIP-0032). Once you have this hierarchy you can use function CipherKeyValue(hierarchy_path, key, value) to perform various operations. This functions derives the private key using hierarchy_path and combines this with string stored in key to compute AES encryption key. This enckey is then used to encrypt/decrypt value, which is returned.

As for not having TREZOR, send me post addresses of developers that might be interested in implementing this feature to my email (stick@satoshilabs.com) and we'll get it sorted out. :-)

[droidmonkey]

My fear, as i stated before, is there are hundreds of these things. We cant possibly support them all. We need to support common standards, not individual solutions. If the solution doesn't meet the standard, not really our issue.

[junderw]

I agree that we should support standards rather than individual devices.

However, I think this issue is about prusnak wanting to create some sort of optional plugin for keepassxc.

FYI prusnak is the creator of the TREZOR device.

[Bertrand256]

@prusnak Although the idea of integrating KeePassXC is very interesting, I have one concern about the point A from your initial message.

Using a filename as a parameter is probably not the best solution, because changing the filename (which is sometimes useful) will also alter the master key, which will prevent the data from being correctly decrypted.

[prusnak]

I think this issue is about prusnak wanting to create some sort of optional plugin for keepassxc.

Right, I was trying to get some pointers about the internal architecture of KeepasXC.

[prusnak]

Using a filename as a parameter is probably not the best solution

Right, if there is a place for storing some kind of "nonce" in the data format, we can use that.

[Bertrand256]

I, unfortunately, do not yet know KeePassXC internals, but I'm going to explore the topic because I am (and I know some other people also) very interested in having KeePassXC integrated with Trezor.

[vsund]

Would be also nice if we could seed the password generator with some entropy from a Trezor (or other external devices). There's a get_entropy method in trezorctl.