Support for Yubichallenge with KeepassXC DB

[jskvbinmv]

Databases created with KeepassXC and secured with password and Yubikey Challenge Response don't trigger the yubichallenge app. Instead they open the file browser dialogue.

Please add funcionality for KeePassXC databases and Challenge Response

[rmenessec]

@pp3345:

This is expected behavior. When no user mode driver (like ykDroid) is attached to the YubiKey, Android (precisely, the Linux kernel) will attach its own default USB-HID driver to which the YubiKey presents itself as a USB keyboard. Thus, Android thinks that there is a hardware keyboard attached and therefore doesn't show the on-screen keyboard.

That would depend entirely on what firmware you have installed, and what options are available in the Settings app. My Nexus 6 firmware keeps the OSK visible by default whether or not a physical keyboard is connected, although this option can be switched off.

Settings ⇒ System ⇒ Languages & input ⇒ Physical keyboard ⇒ Show virtual keyboard

Since regular user apps can also exercise a degree of control over whether or not the OSK is shown, this is something that could likely be worked around in KP2A for users who don't have a setting like this.

[pp3345]

@rmenessec That's indeed correct, though I believe that most Android ROMs have this option turned off by default. It might also be possible to implement a better workaround in ykDroid by using a background service that keeps attached to the YubiKey, though that could cause issues when other USB drivers want to use the YubiKey (e. g. Yubico Authenticator). I'll look into that.

[rmenessec]

@pp3345, wouldn't it be a lot easier to just add a non-default option to KP2A to force displaying the OSK during credential input? 😊

PS: I'm afraid I've had some trouble following the course of the development of support for the new challenge-response mechanism in KP2A. I can't find documentation outside this issue. I'd like to test this out and add my own results.

... So, is ykDroid a prerequisite for KP2A's challenge-response mechanism to work?

[pp3345]

@rmenessec Well, maybe it is, let's see what @PhilippC thinks ;-)

The current beta of KP2A has a port of YubiChallenge included, but additionally also supports ykDroid if it's installed. Generally, ykDroid will be necessary if you want to use USB instead of NFC, though ykDroid supports both. I'd appreciate some more testing for ykDroid as it seems that it doesn't yet work flawlessly for everyone.

[rmenessec]

@pp3345, seems to work flawlessly with the latest published KP2A beta on my Nexus 6 (LineageOS 15.1) via NFC, with ykDroid installed via the Play Store. No clear indication whether ykDroid was participating—I assume that's expected.

I used a tiny stub KDBXv4 AES256-Argon2 database created for the test, containing a single fake entry.

[pp3345]

@rmenessec Thank you! You may distinguish ykDroid from the integrated YubiChallenge port in the current KP2A build by checking whether it looks like the screenshots on Google Play. ;-)

[wbedard]

@rmenessec, et al. I just wanted to post a quick update after the run of troubleshooting I posted a couple of weeks ago.

First of all, I want to publicly thank whoever contacted Yubico on my behalf. After I suggested that they would not likely provide support to an issue involving a pre-release 3rd-party app, I was surprised when they contacted me to assist me with the issues described in this thread and to let me know about their recall campaign on my early "developers edition" YubiKey NEO. They basically arranged to send me a replacement device and the whole experience was a great example of the amazing support provided by Yubico.

As soon as I received the new device, I programmed it with the same Challenge-Response codes I was using for testing in KP2A. However, this new device still would not unlock my test database. At that point, I just set it aside and continued to follow this thread for future developments.

Most recently, I saw mention of the ykDroid app, which I was previously unaware of. My previous testing was performed with and without the YubiChallenge app. After reading up on what ykDroid does, I replaced YubiChallenge with ykDroid on my Nexus 6. In this configuration, I was finally able to open my test database, using both the old and new NEO devices. I repeated the same process on my Nexus 5 and it also works on that device. Suffice it to say that I am thrilled to finally have this working.

I hope this feedback helps @PhilippC as he continues to develop this app. I also hope it provides some much deserved praise both to Yubico for their amazing level of support to their customers and to @pp3345 for his useful "driver app" that finally made this whole process work for me. Thanks again for everyone's continued effort to make KP2A such an amazing app!

R/ wbedard

[PhilippC]

thanks for the feedback. I have just published an update to beta channel which requires ykDroid. I have removed the built-in NFC Challenge-Response handling to get rid of the NFC permission. Also ykDroid has a better implementation.

[wbedard]

@PhilippC, has anyone reported crashes in the new 1.06 release of KP2A? I looked here and in the Google+ Beta community but I didn't see any mention of it. When testing against the same workflows discussed in this thread, the new release crashes after reading the NEO (you can read the toasts about processing the master key...) and does so on both my Nexus devices. Rolling back to the previous beta release still works as previously reported. I'll post some logs over on Pastbin in a little bit but I wanted to give you a heads-up.

(Update: Link to logcat from my Nexus 6: https://pastebin.com/UDRn5Tf8)

[PhilippC]

@wbedard you are seeing https://github.com/PhilippC/keepass2android/issues/474

[PhilippC]

closing this as the implementation seems to be accepted

[aol-nnov]

@PhilippC sorry to bother you here, but I'm not sure if cross-project mentions work. Could you please follow the linked ykDroid PR and add some thoughts too? :)

[grenzor]

@PhilippC Will users be able to use PW+Keyfile+ChallengeResponse with the new implementation? If not, is it possible to support the option to do so?

[IPv777]

And what about TOTP support like in KeepassXC ?

-------- Message d'origine -------- On 20 août 2018 à 11:56, grenzor a écrit :

@PhilippC Will users be able to use PW+Keyfile+YubiChallenge with the new implementation? If not, is it possible to support the option to do so?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[phoerious]

TOTP ist not for unlocking the database. It is only a TOTP generator.

[PhilippC]

@grenzor please see https://github.com/PhilippC/keepass2android/issues/456 for this @IPv777 TOTP support is already there, KP2A is compatible to TrayTOP, KeeOTP and KeeWeb TOTP style.

[gamdow]

I've been trying to get my Password + Challenge-Response (HMAC-SHA1) KeePassXC database open in Keepass2Android 1.06f using NFC (why I'm here). It started working once I changed the Key Derivation Function from "AES-KDF (KBDX 3.1)" (default) to "AES-KDF (KBDX 4)". I'm guessing this is unrelated to the use of NFC, but I'm too lazy to verify that.

[rmenessec]

@gamdow, the requirement for KBDX 4.x is right there in the release notes for K2A 1.06. You were literally forced to see it when you launched the new release for the first time.

[PhilippC]

@gamdow see https://github.com/keepassxreboot/keepassxc/issues/1060 for the decision making process in KeepassX for this. Their old implementation was in general incompatible to most other Keepass implementation, they decided to keep the old way for backward compatibility and use the new way for KDBX4 databases.

[gamdow]

Thanks for responding to my comment. My main reason for posting was in case anyone had overlooked it as I had and was wasting time trying to fix the wrong problem.

@rmenessec, As previously stated, I'm quiet lazy, and reading release notes falls under that umbrella. I also upgraded to the 1.06 beta release in order to get NFC working, so the problems were conflated. Before inspiration struck, I wasn't even aware of KDF, so I wouldn't have recognized the incompatibility from reading release notes anyway.

That said, I assume the KDF version must be part of the DB meta-data in order to decrypt it? So could app not have warned me about the incompatibility when I tried to open it? Or does it rely on file extension?

[burkemw3]

Is there any guidance on expected time to unlock databases with password and yubikey challenge response? It's taking 30+ seconds on an Android phone for me, which is much longer than I expected and longer than the 1 second on a laptop.

Environment is Qualcomm SDM630 Snapdragon 630 Octa-core 2.2 GHz Cortex-A53. Test database encryption settings are AES-256, Argon2 KDF, 19 rounds, 64 MiB memory, 4 threads.

While opening, I see a dialog with the following text:

working

loading database... (Transforming master key...)

(Thanks for all your work on this app!)

[jonas-app]

@burkemw3 There are already multiple issues about this. One is assigned to the 1.08 milestone. https://github.com/PhilippC/keepass2android/issues/306 https://github.com/PhilippC/keepass2android/issues/283 https://github.com/PhilippC/keepass2android/issues/106

[JRussell]

This stopped working for me and I'm not sure why. I haven't changed anything. Using kp2a, ykdroid and a yubikey4 over USB. My USB keys work fine in Windows but on my phone I'm getting a toast that says "The challenge response is incorrect." then just sits at "Working..." indefinitely. I usually use Nextcloud but also tried copying the database straight to my phone and both give the same results. I figured this should be here but let me know if I should open a new issue.

[IPv777]

Maybe try to delete the data (and cache) of both apps (KP2A & ykDroid) ?

-------- Message d'origine -------- On 5 nov. 2018 à 19:45, JRussell a écrit :

This stopped working for me and I'm not sure why. I haven't changed anything. Using kp2a, ykdroid and a yubikey4 over USB. My USB keys work fine in Windows but on my phone I'm getting a toast that says "The challenge response is incorrect." then just sits at "Working..." indefinitely. I usually use Nextcloud but also tried copying the database straight to my phone and both give the same results. I figured this should be here but let me know if I should open a new issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[JRussell]

Maybe try to delete the data (and cache) of both apps (KP2A & ykDroid) ? … -------- Message d'origine -------- On 5 nov. 2018 à 19:45, JRussell a écrit : This stopped working for me and I'm not sure why. I haven't changed anything. Using kp2a, ykdroid and a yubikey4 over USB. My USB keys work fine in Windows but on my phone I'm getting a toast that says "The challenge response is incorrect." then just sits at "Working..." indefinitely. I usually use Nextcloud but also tried copying the database straight to my phone and both give the same results. I figured this should be here but let me know if I should open a new issue. — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](#4 (comment)), or mute the thread.

I tried uninstalling and reinstalling both apps. Same result. I should add that this is happening on both of my phones. Sony XZ1 Compact and Pixel 3. Running the latest kp2a beta from the play store.

[PhilippC]

@JRussell I suggest you open a new issue for this. Can you please

• try with the 1.06f release (https://github.com/PhilippC/keepass2android/releases/tag/1.06f)
• Enable debug logging and send me the log (here or to crocoapps@gmail.com)?

[JRussell]

new issue opened: https://github.com/PhilippC/keepass2android/issues/609

[meganleewebb]

@JRussell Might be unrelated, but I had the similar issue trying to share a db from KeepassXC. Found out that the version of the db was KDBX 3.1 . Changing it to version KDBX 4 and it all worked happily. I'm not using Argon2 yet, either if that makes any difference. Will change to that later when the decrypt gets faster.

[phoerious]

The decryption won't get faster. The speed depends on the number of transformation rounds you have configured. KDBX4 is generally slower, because it has a better derivation function. That is intended behaviour.

[lindhe]

I think the reason you experience that the db is very slow is mainly because of the Argon2 algorithm, rather than KDBX4 format per se. I might be misremembering, but I think Argon2 is much more memory intensive compared to AES. And since phones have much slower memory than a PC, it would be a pretty noticeable difference.

However, you can still use the KDBX4 format but with AES encryption. That would be much faster on a phone, but still support YubiKey on KeePass2Android.

[meganleewebb]

@lindhe is correct. I'm using AES until issue #306 is resolved.

[bungabunga]

are there any security drawbacks using AES-KDF vs. Argon2?

[lindhe]

are there any security drawbacks using AES-KDF vs. Argon2?

Kind of, but it mostly depends on your threat model. For most of us, the difference in security does not really matter.

Cracking processor intensive cryptos like AES can be sped up significantly (I'm guessing something like 1000x) by having dedicated hardware (ASIC) for the task instead of running the computations on general purpose hardware like a regular CPU/GPU. Memory intensive cryptos, on the other hand, is not very easy to speed up via dedicated hardware. I don't know if it's impossible, or just too hard to be worth the trouble.

But creating dedicated ASICs is hella' expensive, so unless you're up against state-sponsored actors, I'd say you're fine off with AES-KDF. A slight disadvantage of Argon2 is that it is not as old, so it has not been attacked for as long. So while we have no reason to believe it has any huge flaws, the risk is slightly higher compared to AES. Especially when considering the implementations, and not just the algorithms.

[phoerious]

ASICs can compute AES much faster than a general-purpose CPU, whereas Argon2 is a memory-hard KDF. That means you cannot arbitrarily trade memory for processing speed. Since memory access is as fast or slow on an ASIC as it is on a normal CPU and Argon2 guarantees a specific memory cost, an attacker cannot get these immense speed-ups anymore. It's also a lot slower in general with only few iterations compared to AES, which was never intended to be slow in the first place.