Support KeePassXC compatible hmac sha1 challenge-response using Android keystore

[onlykey]

We recently worked with KeePassXC to add OnlyKey support for challenge-response, so now you have two options, YubiKey or OnlyKey for challenge response with KeePassXC.

While these issues mention support of challenge-response through other 3rd party apps:
#137
#8

I wanted to suggest a different approach that would allow users to use all Yubikey models, not just the NEO, and OnlyKey. The idea is to keep using the device of your choice on desktop OS with KeePassXC but on Android don't use the device, instead use the Android keystore. This would be a lot more user friendly and avoid lots of potential technical issues like NFC issues, USB issues, etc. Here is how it would work:

• On Yubikey (or OnlyKey) device you load your HMAC SHA1 key
• You use your device with KeePassXC or KeePass on desktop OS with challenge and response (v4 KBDX)
• On mobile you use an app like KeePassDX and have the option to import an HMAC SHA1 key in the app by typing it in (or maybe by QR code, typing would be fine for first run)
• KeePassDX imports this key to the android key store and protects it with fingerprint

So now you can open your KBDX on desktop OS with your device, or on Android with a fingerprint. The Android keystore according to this supports HMAC SHA1 so you would be able to generate the challenge-response in the app, with the key never leaving the Android keystore - https://source.android.com/security/keystore/features

I think from a user experience perspective this would be a game changer. All that is required is a fingerprint on mobile and its backwards compatible with KeePassXC.

[buckket]

Saving the HMAC-SHA1 key to the mobile device itself defeats the whole purpose of having a removable(!) second factor.

Don’t get me wrong, for some users this way of doing it might be okay, but in my opinion the other proposal, i.e. using the challenge-response method via NFC / USB seems to be the safer solution.

[rugk]

For the reasons given by @buckket I'd close this a dupe of #8. Or basically, not implement it.

The point of 2FA is a second factor. I think #805 (and others) etc. already make use of Android internal biometric features, so I don't know whether this issue would have any advantage.

From a usability standpoint I can currently only make guesses, but if you have your database secured by a USB key that is in(?) a keychain in your pocket, you can also hold it next to it and NFC-unlock the database. After all KeePassDX now does not lock the DB each time you go somewhere else or so.

[mario-tux]

If one want an unlock mechanism based on a strong cryptographic key stored in a tamper-proof device the only choices are: android internal biometric feature or yubikey. I one want to syncronize the database on computer and mobile devices: the only choice is yubikey: how I can unlock the database on the computer with the android internal biometric feature?
Options like unlock with a memorable-passphrase or use a strong key stored in a tamperable usb key are weaker.

This is just my opinion and why I use the yubikey in challenge-response mode (no cloud or network communication!).

[rugk]

Well… fair point. Though one solution would be to always go the safe way and use your FIDO-key also for the mobile.

Also I'm quite unsure whether this would even technically be possible. You cannot extract a key from a YubiKey or so. Maybe at initialization KeePassDX would have to load the same key into the Android keystore and the FIDO-key, but hmm… dunno.

[onlykey]

Saving the HMAC-SHA1 key to the mobile device itself defeats the whole purpose of having a removable(!) second factor.

This line has been blured some with built in secure elements, the secure element within a mobile device is similar to say using a TPM on a workstation or Touch ID on your Mac. Also mobile providers are now using built-in security keys for FIDO2 authentication using this - https://www.theverge.com/2020/6/24/21301509/apple-safari-14-browser-face-touch-id-logins-webauthn-fido2 so its yes it is used for 2FA

The point of 2FA is a second factor. I think #805 (and others) etc. already make use of Android internal biometric features, so I don't know whether this issue would have any advantage.

The advantage is that it would be compatible with desktop OS Keepass like KeepassXC, Android biometric is not so you would have to have two copies of your password database. The advantage of using HMAC SHA1 is compatibility, its already implemented on both Keepass and KeepassXC so people can sync the same database between mobile and desktop OS and have a seamless experience. If you don't need compatibility with desktop OS then sure Touch ID would be fine.

[rugk]

FIDO2 authentication using this - https://www.theverge.com/2020/6/24/21301509/apple-safari-14-browser-face-touch-id-logins-webauthn-fido2

Note that this uses passwordless login, i.e. FIDO2 with two factors, the TPM (something you have) and face/fingerprint authentication (something you are).

In case of a FIDO2 key (without any integrated authentication mechanism like Trezor or so), the key is what you have. (and you may provide a second factor, i.e. usually your password which is what you know)

[onlykey]

Note that this uses passwordless login, i.e. FIDO2 with two factors, the TPM (something you have) and face/fingerprint authentication (something you are).

@rugk Keep in mind that your face/fingerprint data is secured by the TPM so might be able to argue it's just something you have (1 factor) if no password is required. Either way the two factors are very similar to the HMAC example, your password (something you know) and TPM (something you have). The difference is that the the HMAC response is actually used as part of your key used to encrypt your database so it has some additional advantages over authentication only i.e.

• I secured my account with FIDO2 key and SMS as fallback, I think I am really secure, however this is not really the case my account is only as secure as whatever the weakest authentication method is.
• I secured my account with a password and challenge response, there is no other method to access my account, the key to my database is derived from both my password and challenge response. Much more difficult to compromise in most threat models.

[J-Jamet]

On mobile you use an app like KeePassDX and have the option to import an HMAC SHA1 key in the app by typing it in (or maybe by QR code, typing would be fine for first run)
KeePassDX imports this key to the android key store and protects it with fingerprint

I think the idea is not bad but should not be directly implemented in KeePassDX.
My vision is to implement the Challenge-Response methods so that the answer is given by a separate application, a bit like YkDroid.
Here the idea would be to register the HMAC SHA1 key, either manually (by typing the key), or by connecting the OnlyKey in OTG and to be able to register this key in the Keystore of the device from the second application which will behave like an emulated OnlyKey in the eyes of the user.
If the interest is not to have to connect his key every time, then this is for me the best way to implement it.
It will allow the user not to get lost and to use the answer to the challenge in the same way as with a physical key at each connection (except that the key is retrieved internally from the KeyStore in the 2nd app).

[karlredman]

Note: I very much appreciate the efforts of everyone involved with this project. Thank you for your efforts -it matters (to a great deal number of people). Thank You.

Here's my perspective:

I see there is work going on with #8 -cool.

I just wanted to put my 2 cents in here on the topic as a whole. My priority is having an OTG (physical key) for challenge response. For me this provides the highest security -and I'm sure most will agree.

I think speculation on how the feature will be used is out of scope. It's the highest degree of security among the options. (period) -something I know + something I have. And, in the case of onlykey there is the possibility of having one PIN for a password for authorization and another PIN for authentication -both on the same key.

This is obviously not ideal security. I'm just saying that it's possible. And in that sense 'something you know' could be only your pin on a device (in this case onlykey) whereby you must have the key in order to enter both the password and the HMAC SH1 key via 2 separate PINs. At any rate, the phone with the app becomes also a 'something you have' -meaning that, in this scenario, you have to HAVE 2 things + KNOW (at least) 2 things. If the password is also randomized then only the 'somethings you have' + your 'something you know' PINs provides access.

[edit] Note: I'm grouping the database file into the phone content. The assumption is that access to the phone will occur and settings (like the cloud server that holds the database file for transfer) might be all considered as 'the same thing' relative to the overall integration. Depending on how a person manages access to their phone, additional or lessor security might be considered relevant. I just want to acknowledge that the file, itself, becomes a something you have only up to the point that someone else has a copy of it.

I'm nearly doing this kind of thing now. In practice it's a minor and rare annoyance to have to reopen my database. And, more so, it keeps me cognizant of having all of my 'things' around me.

I don't imagine most people would use the scenario I outlined above. However, refusal to provide the possibility severely restricts potential security and decreases the potential scenarios an attacker must calculate overall.

I want my maid, for instance, to be as confused as possible.

[Edit -additional scenario]:

In the case of, for instance, political activism it is entirely possible for police to force a person to use fingerprint and face authentication. Whereby, in the case of onlykey, authorization as a factor is restricted behind the user's PIN. In the same respect, passwords and PINs are not accessible to the legal system without express, with merit, court orders. Again, restricting the possibility of increased security makes little sense here -to me.

Regardless, the great deal of thoughtfulness that has gone into this app is impressive. And this is why I recommend it to my friends who either just want to be, as opposed to feel, more secure and those who have been involved in protests whereby police have tried to force them to unlock their passwords.

Hope this helps on perspective -criticism, etc. is appreciated.