Open brianddk opened 1 year ago
We can't use any of that code since it's C# and we are C++. As long as Trezor supports a standard way to perform HMAC challenge response we could support it.
As long as Trezor supports a standard way to perform HMAC challenge response we could support it.
Yes the CipherKeyValue API is standardized and used by Trezor and KeepKey. This would be similar to how Yubikey's HMAC-SHA1 standard is used by both YubiKey and OnlyKey.
If there was bandwith for KeepassXC to consider FIDO2 hmac-secret support, then compatible hardware would include Trezor, Yubikey and anyone else that lists compliance with either CTAP 2.1 or FIDO 2.1. The FIDO Alliance certification page lists a dozen or so FIDO 2.1 devices.
The details for both approaches, CipherKeyValue, or hmac-secret are mostly hashed out in the older issues, but I was just curious as to whether either of these methods would be up for consideration again.
https://github.com/keepassxreboot/keepassxc/discussions/10378
I think there are two usecases to integrating Trezor devices
The benefits of using a trezor hardware wallet is that if the trezor gets lost or breaks, a user can buy a new trezor wallet, enter in the seed phrase and it will work to unlock your database unlike a Yubikey were each key holds an unique key which cannot be backup.
This would be very nice to add additional security to my wallet, and not rely purely on the master password.
Hi, is there any way to know if this went ahead?
I agree that using Trezor as a key file would be much more secure than the Yubikey's challenge-response solutions. I'll give you some facts about why it's worth integrating Trezor as an optional key file in Keepassxc:
Although the Yubikey is highly secure, it needs to expose part of its secret to function as an authentication key, which theoretically increases the attack vector, especially in more complex scenarios. In the case of Trezor, the secret (bip39 seed) never leaves the device. Trezor uses a challenge-response authentication process, where the secret (such as the BIP39 seed) is never exposed or transmitted, remaining securely stored on the device. This is a big difference compared to devices like the Yubikey, where the secret can be exposed externally during authentication.
Unlike physical keys that can expose the secret when responding to the challenge, Trezor keeps the seed (or other type of secret) stored offline and never reveals it, making the process even more secure.
This is pending support for Fido2 -- see #3560 and https://github.com/keepassxreboot/keepassxc/pull/10311
Summary
Last year Keepass2Trezor plug-in was released to the Keepass plugin page. The feature allows the Keepass database to be unlocked using Trezor for challenge and response.
Examples
The relevant bit of code is the call to CipherKeyValue which performs the challenge / response to the Trezor. This will filter the parameters through an HMAC followed by an AES encryption to complete the challenge / response. You can see the path in the firmware here and the official documentation on the API call is spelled out here: cipherKeyValue.html
Context
I realize that the use of Trezor's CipherKeyValue came up a 6 years ago in issue #746 , but with the release of the Keepass2Trezor plugin last year, maybe it's time to revisit the discussion. If not, then the topic of Trezor support could stay on the discussion open in issue #3560 regarding FIDO2 hmac-secret challenge / response.