Yubikey: Challenge-Response (KeePassXC mode)

[markchalloner]

iOS doesn't support Yubikey Challenge-Response for 2FA on Keepass files.

A workaround to be able to open Yubikey protected databases can be found in: keepassxreboot/keepassxc#1734 which shows how to create a pre-computed key file:

CHALLENGE_RESPONSE_KEY=
DATABASE_FILE=/tmp/passwords.kdbx
KEY_FILE=/tmp/passwords.key
xxd -p -c 33 -s 0xc5 -l 32 "$DATABASE_FILE" | xxd -r -p | openssl dgst -sha1 -hmac "$(echo -n "$CHALLENGE_RESPONSE_KEY" | xxd -r -p)" | cut -c 10- | xxd -r -p > "$KEY_FILE"

Unfortunately each time the database is changed this key file needs to be regenerated and imported into iOS.

It might be useful to add an Advanced Unlock option that takes the Challenge-Response secret and password and computes the key on the fly, avoiding the need for manual steps.

[CueHD]

There are different ways that KeePass implementations incorporate Yubikey Challenge-Response. The implementation used by KeepassXC and Keepass2Android for KDBX4 does not change the challenge nor response every time the database is saved.

See keepassxreboot/keepassxc#1060 for an explanation.

[mrclschstr]

It does change. See keepassxreboot/keepassxc#1734 (comment)

[mmcguill]

Hi, I'd like to add Yubikey support eventually, so thanks for opening the issue. I'm not super familiar with your use case here...

Could you describe in a little more detail the steps you follow with your device and KeePassXC to Unlock your database?

I will probably need to purchase a Yubikey to get started on this process. Any recommendations for use on iOS?

[markchalloner]

Hi Mark,

Thanks for coming back to me so quick.

Could you describe in a little more detail the steps you follow with your device and KeePassXC to Unlock your database?

The steps required to login to a Yubikey Challenge-Response protected Keepass file with KeepassXC are:

• provision a Yubikey slot with an HMAC-SHA1 Challenge-Response secret (backed up off key),
• connect Yubikey to a desktop PC via USB
• configure the KDBX4 database to use the HMAC-SHA1 secret on the Yubikey
• on opening the database in KeepassXC tick the Challenge Response field in the Enter master key screen.

The current steps required to login to a Yubikey Challenge-Response protected Keepass file with Strongbox are:

• generate a key file from the KDBX4 database master seed and HMAC-SHA1 Challenge-Response (see script above - this needs to be done each time the database changes)
• transfer the key to iOS,
• open database with Strongbox Advanced Unlock option Password & Key File... and select the imported key file.

The steps I envision would be:

• save the HMAC-SHA1 Challenge-Response secret in secure storage on iOS (simple: a local password protected only Strongbox database, complex: iOS local Keychain?)
• retrieve the secret (simple: manually input via Strongbox Advanced Unlock option Password & Challenge-Response secret, complex: automatically via pin mechanism?)
• Strongbox generates the master key from password and secret with the same algorithm implemented in KeepassXC
• open database

I will probably need to purchase a Yubikey to get started on this process. Any recommendations for use on iOS?

Unfortunately iOS support for Yubikey is currently limited to read-only modes: Yubikey's proprietary OTP, Static password and OATH-HOTP.

Because apps are unable to write via NFC/USB/Lightning the Challenge-Response wouldn't work. It looks Yubico are bringing out an iOS device supporting at least U2F which implies the ability to send data to the key. Unfortunately however Challenge-Response does not seem to be mentioned either in the press release, blog or the signup for the developer preview.

With the physical hardware out of the picture, the only other option is to use the actual secret for now (either off or on-device) as in the current steps documented above.

Cheers

[mmcguill]

Ok, thanks for the detailed response, very helpful.

[Mukrosz]

This feature would be amazing.
I see Lastpass is doing a similar/if not the same approach as mentioned above.

[mmcguill]

Hi @markchalloner how do you see inputting Yubikey secret? Should it be a hex byte space separated string like:

96 84 43 35 60 2b 5f 00 42 78 07 c6 26 f1 ae 25 af 10 f0 2a

Any examples would be great. I'll try to investigate this soon...

[markchalloner]

Hi @mmcguill,

Thanks! It looks like (when generating):

• the HMAC-SHA1 output by the older Yubikey Personalization Tool is space separated as in your example: 96 84 43 35 60 2b 5f 00 42 78 07 c6 26 f1 ae 25 af 10 f0 2a, but
• the HMAC-SHA1 output by the newer Yubikey Manager is non-separated: 96844335602b5f00427807c626f1ae25af10f02a,

It's not inconceivable that the secret be backed up in either format (weirdly I have the non-separated format even though I generated it using the Personalization Tool).

When using:

• Keepass2Android's Challenge Response secret (recovery mode) can take the HMAC-SHA1 as both space separated and non-separated hex formats (though note this is for KeeChallenge's recovery rather than KeePassX's).
• openssl can only take the HMAC-SHA1 as a non-separated string: openssl dgst -sha1 -mac hmac -macopt hexkey:96844335602b5f00427807c626f1ae25af10f02a.

As an aside as I understand the CCHmac method takes an ascii encoded c string so I might be wary of treating the input as anything other than a string anyway to avoid accidentally converting it to the values represented in hex (though I'm not familiar with Objective C so wildly guessing here).

Hope that helps!

[mmcguill]

Alright yeah, I think it should be no issue supporting both formats... Cheers

[ssa3512]

It would be great to see support for this with Yubikey 5 NFC. I've been using Keepass2Android with "Password + Challenge-Response for Keepass XC" mode for some time. Considering moving to iOS but the lack of any applications that support Keepass + Yubikey NFC challenge-response is frustrating.

[mmcguill]

@ssa3512 Sure, understood. The issue is really do with hardware. There's no 2 ways comms capable Yubikey for iOS at the moment, which means challenge response is impossible right now. This issue itself is actually a way to workaround this by supplying the Yubikey secret to Strongbox and having it execute the challenge response (HMAC-SHA1) itself and use that generated response to open the database, which is no doubt a handy feature and something I hope to get done soon.

[SilverBut]

Unfortunately iOS support for Yubikey is currently limited to read-only modes: Yubikey's proprietary OTP, Static password and OATH-HOTP.

Update: iOS 13 would allow write to empty NFC tags. Wondering if this would be helpful if we want to add NFC capabilities for Strongbox.

[mmcguill]

Just an update. In theory Yubikey's new 5Ci should allow this Challenge/Response. I've been in touch and hopefully will get enrolled into their developer program. @SilverBut re the iOS 13 NFC, I don't know, but I'll ask Yubikey about this.

[mmcguill]

Update: Confirmed with Yubikey that iOS 13 NFC support should work too... Just a matter of allocating dev time to this, and a stable iOS 13 build.

[mmcguill]

This feature is now ready for you to test, it would be great to have some feedback. There are a couple of steps to get this working

1. You'll need your Yubikey master secret in Hex form as above (can be spaced couplets or just a long string)

2. You'll need version 1.36.0 from the app store (you might need to uninstall and re install from the app store to get this release)

3. You need to switch this feature on by going to Preferences > Advanced and turning on 'Show Yubikey Workaround' (Screenshot below)

4. You'll see a field where you can enter this secret when you tap on your database.

5. This should open your Yubiekey protected database, in read-only mode for the moment.

[markchalloner]

Hi Mark,

Great, thanks for the feature and the clear steps. The basic functionality works well!

I tested:

1. Opening a copy of my normal Keepass XC file from a remote with my Yubikey Challenge Response secret with and without the Read-only toggle enabled: PASS

• The file opened successfully, under Read-only mode in both cases
• Note: I was unable to easily retrieve the Challenge Response from another local Strongbox database as the clipboard is wiped on database close (with and without clipboard timeout enabled).

2. Setting and reopening the database with a convenience pin: FAIL

• The pin appeared to be set correctly.
• The database could not be opened with the message:

  Could not open database
  The Convenience Password or Key File were incorrect for this database.
  Convenience Unlock Disabled.
  

3. Setting and reopening the database with Touch ID: FAIL

• The database could not be opened with the message:

  Could not open database
  The Convenience Password or Key File were incorrect for this database.
  Convenience Unlock Disabled.
  

4. Opening the same database via Autofill: PASS

• The file opened successfully and the correct entries were shown.

5. Opening the same database via Autofill with convenience pin set: FAIL

• A convenience PIN was not requested even though it had been set, the login page was shown instead.
• The file opened successfully and the correct entries were shown.

6. Opening the same database via Autofill with Touch ID set: FAIL

• Touch ID was not requested even though it had been set, the login page was shown instead.
• The file opened successfully and the correct entries were shown.

Cheers

[mmcguill]

Thanks for the feedback @markchalloner... Yes, should have mentioned Convenience Unlock not supported either.

This is basically the most minimal release possible, I want to make sure the opening/unlocking works well. The next feature could/should be

1. Write Mode
2. Convenience Unlock

Convenience Unlock is probably straightforward enough. Write mode will take more work.

Any extra feedback from anyone else using this method welcome!

[markchalloner]

@mmcguill

If the Challenge Response field was type password could it be autocompleted from another database?

[mmcguill]

@markchalloner Yes, that would work, I'll see about adding that in the next release. I wonder if anyone else in this issue has tried this open method out yet?

[ssa3512]

I started testing this today and everything seems to be working well. Great job 👍 Looking forward to convenience unlock.

[mmcguill]

Thanks for the update @ssa3512 - Convenience Unlock coming soon...

[mmcguill]

Convenience Unlock should work for you with 1.37.0 - Let me know if it works ok!

[ssa3512]

Validated convenience unlock with 1.37.0.

PIN unlock works, Face ID works and the two together works.
Just to confirm, is the expected behavior when Face ID and a PIN are enabled is that BOTH are required? Based on the setting of "Allow Face ID" I was expecting it to be either/or but it is requiring both.

Additionally, when using Face ID, there doesn't seem to be any sort of fallback to using the master key/password to unlock whereas PIN unlock has the "Manual" button that allows you to use those. Is this by design?

[abalakov]

Hey @mmcguill, just wanted to thank you for your work on this!... it worked flawlessly

Same here! I can confirm it its working with Keyfile and Yubikey 5 NFC with 64bit fixed HMAC-SHA1 Challenge Response.

Thanks a lot!

[chrenderle]

Right now the Yubikey does not work with Autofill. Will this be implemented in the future or is this not possible due to the restrictions from Apple?

[mmcguill]

At the moment it's just not possible to access NFC in an Auto-Fill (technically App Extension) context by Apple explicitly don't allow it. I believe the same is true of MFI (e.g. Lightning 5Ci)...

The only solution I can think of, which may not be acceptable is to use the Workaround field, negating the use of the hardware token. :(

[Frederick888]

At the moment it's just not possible to access NFC in an Auto-Fill (technically App Extension) context by Apple explicitly don't allow it

Seems to be documented here: https://developer.apple.com/documentation/corenfc

This is unfortunate. I've been looking forward to migrating from Kypass to Strongbox for NFC challenge-response support and now this is tbh a huge bummer to me :(

[antnythr]

At the moment it's just not possible to access NFC in an Auto-Fill (technically App Extension) context by Apple explicitly don't allow it

Seems to be documented here: https://developer.apple.com/documentation/corenfc

This is unfortunate. I've been looking forward to migrating from Kypass to Strongbox for NFC challenge-response support and now this is tbh a huge bummer to me :(

Hopefully it’s something they’re planning to implement and that it’s available for iOS 14.

Time to submit some feedback I guess...
https://www.apple.com/feedback/

[Frederick888]

Time to submit some feedback I guess...

By the way since I'm using the memory-hard Argon2 function, the memory usage restriction on App Extensions causes random crashes in Auto-Fill and it seem that Strongbox is also affected by this issue (#99). Hence I'd appreciate it if you guys can include this problem in your feedback as well.

PS: Sorry this is a little off-topic.

[seonwoolee]

Ever since the latest update, I cannot open my KeePass database on my iPhone 6. I had previously been unlocking my database using the Yubikey secret.

I believe the problem may be related to the fact that because the iPhone 6 cannot be updated to iOS version 13 or later, apps including Strongbox can't use the NFC. When I try to choose one of the NFC slots, I get an error saying device does not support NFC Scanning...
When I don't specify a Yubikey NFC slot and put in the Yubikey secret, it says incorrect credentials.

Is there any chance you're accidentally ignoring the Yubikey secret field?

[mmcguill]

Hi, I don't think that it'll be ignoring the secret. Couple of questions

Does your database open with your Yubikey elsewhere?
Is your Yubikey programmed with Fixed Length or Variable input do you know?

[seonwoolee]

Yes, it opens with KeePassXC on Windows 10 and Linux, and Keepass2Android on Android.

I don't know how my Yubikey is programmed but I'm not sure why that matters; I'm trying to unlock my database using the Yubikey secret (the way I was unlocking it before the app was updated) and NOT my Yubikey.

[mmcguill]

Thanks @seonwoolee - That does sound strange. Can you mail support@strongboxsafe.com and I can try to investigate this further in the coming days...

[mmcguill]

@seonwoolee - I haven't heard from you but in case you're still available, there is a new parameter you can now specify in the workaround field. You can prefix the secret with a capital 'P' - this tells Strongbox to simulate a YubiKey programmed in 'variable' mode.

Note: It does matter how you programmed your yubikey even when you are using the workaround field. The YubiKey will calculate different responses for the same secret depending on this parameter. Long story but if you'd like to read more you can do so here:

Yubico/yubikey-personalization-gui#86

[mmcguill]

YubiKey 5Ci support is now available in 1.47.3. This means you can use your YubiKey over NFC and/or lightning.

I believe this issue is now complete and YubiKey Challenge Response is finally fully supported by Strongbox, closing this one out.

[timclassic]

@mmcguill Thanks for the Yubikey 5Ci support, and a generally nice program! This is great.

Unfortunately I just discovered the hard way that I can't use AutoFill (during a demo, heh). I then looked through the ExternalAccessory documentation and could not find a statement like the one in #95 (comment) about the lack of App Extension support. This makes me slightly hopeful.

I thought I'd bring it up here in case you think it's worth looking into a bit more. Either way, thanks again!

[mmcguill]

Hi @timclassic - Thanks for that and very sorry about the demo effect!

Yeah, so I just delved a bit deeper into the issue here, and it should technically be possible. The issue is that YubiKits iOS library was not built with App Extensions (which is what the Password Auto Fill component is) in mind and so because they bundle both NFC and Lightning into the one library, building it in an Auto Fill context causes the compiler to choke. NFC is not supported and this blocks the lightning functionality from compiling too.

I've raised the issue with Yubico now

Yubico/yubikit-ios#42

Hopefully they can support this scenario and it will be just a simple recompile from the Strongbox side to support this.

[timclassic]

Thanks for looking deeper! I’ll watch the Yubico issue in the meantime.

[yoojene]

@mmcguill thanks for a great app - I've just found Strongbox after being a long time Keepass and current MacPass user.

My question: is it possible to configure a single database with 2 YubiKeys (a 5 NFC and 5Ci for example?)

[ssa3512]

@yoojene you can use Yubikey Manager on a PC to manually set the challenge-response key. I have set the same key on each of my Yubikeys so they all work as the 2FA for the password manager. That way if I lose one, my backup key will still open my Keepass database.

[mmcguill]

Thanks @yoojene - yes, as @ssa3512 has pointed out, as long as you configure your keys with the same HMAC-SHA1 secret you'll be fine.

Also store that secret somewhere safe, even if you lose the 2 keys you can recover.

[yoojene]

Awesome thanks a lot @mmcguill and @ssa3512!

[strongbox-mark]

Hi all, just an update related to this issue.

As of 1.49.23 (available in the App Store now) you can use a "Virtual Hardware Key", which you can create in app to Unlock and Edit your hardware key protected database. This includes opening and editing in AutoFill mode.

For those of you who were using the "Emergency Secret Workaround Field" to unlock/edit your databases, Strongbox will automatically migrate this field and create a "Virtual Hardware Key" for you. It will then automatically associate this virtual key with your database, so you should not notice any changes.

The big difference is that you can now use your regular hardware key in the main App via NFC or Lightning, and whereas previously you couldn't access you database in AutoFill mode, you can use the new virtual key in AutoFill mode, leading to a kind of best of both worlds situation.

You can also set your virtual key to "AutoFill Only Mode" meaning it can only be used in AutoFill mode. This means much reduced access to your database with the virtual key and full access to your database requires the actual hardware key.

The secret workaround field will disappear from the UI in a release or two once everything looks ok with the new replacement virtual key paradigm.

To find this new feature, just look under "Hardware Key" in the Unlock screen, where you can view, add and remove virtual hardware key's.

NB: You'll need to fail out/cancel out of Convenience Unlock (Face ID/Pin Code) to see the manual Unlock screen, or just tap and hold your database > Manual Unlock.

Let me know if you have any questions...

[tristan-k]

What about iPad Pro (USB-C) users is there a way a Yubikey 5Ci can be used without Yubico Lightning SDK and with FIDO/CTAP/U2F and keyboard-emulation (OTP) modes?

[strongbox-mark]

Hi @tristan-k - I don't think there's a way to do this. We'd need support from Yubico for this. Could you raise this with them? Any pressure is helpful.

[j-s-c-a]

Quite some time ago since the last discussed on the completed feature, but I have a question about the implementation of this to understand some security implications when using it.
Where is the secret key stored for the Virtual Hardware Key? Is it some kind of "normal" storage of iOS or does it utilize a security features of the iOS device hardware that protects the key from being read out like the real Hardware Key does?

[strongbox-mark]

Hi @j-s-c-a - The secret is protected by the SE (Secure Enclave) in the same way as say the convenience master password or any other sensitive piece of data, so yes, utilising the security features of the device.