Whut? That’s news to me. They are “implementing important changes in the way developer accounts and applications are created and how API authentication is performed”.
I still have an account saved somewhere… I hope. I swear I had a feeling I should generate some more accounts just in case, damn. Seems like you can email them for an account, but still…
Interesting. I’m happy to fork this applet into our namespace and manage CI behind it (if you wanted to do PRs) - but I can’t give it much dev time personally right now.
Out of curiosity what are you using for CI?
A quick toolchain run down would be much appreciated.
I looked at the Vivokey namespace and found GitHub - VivoKey/Flex-OTP , but that project seems to be TOTP/HOTP and not HMAC-SHA1 challenge-response. so I think the YkOtpApplet provides different functionality from the applets you already have.
I don’t own the YkOtpApplet code, but it is licensed under the MPL2 so forking and distributing would be fair game afaik.
I don’t think much dev time would be needed, I already have a modified build file for the Fidesmo framework. A bit of cleanup, namespace changes etc. would still be required. I can push my fork once I have verified that the applet actually fully works as it should (with the desktop and mobile versions of KeepassXC / Keepass2Android+ykdroid)
The author (Alex Wilson / arekinath) provides a small tool (GitHub - arekinath/yktool) to program and test the HMAC-SHA1 functionality.
That would be good to know. Regardless, I assume you would want the repo structured similar to the e.g. Flex-OTP one. Atm I use openjdk-8, ant-javacard, oracle_javacard_sdks and fdsm.
Flex-OTP is pretty old, actually. A structure similar to vk-u2f is ideal.
I’m using Jenkins with ant-javacard and oracle_javacard_sdks. I don’t use FDSM as @StarGate01 does, because I don’t upload directly to a card (as it’s CI). I test with non-Fidesmo cards first, then move to Fidesmo once we’re ready for production.
One of the main things we’d need to do would be get Fidesmo to allow us to use the AID.
If it’s on GitHub, it’s usually fair game. arekinath is quite good and has written a few applets we work with.
Certainly - it does. It’s something we should get to the Fidesmo store.
Only big thing I can think of is getting a provisioning flow working, if yktool is needed to program the HMAC functionality. It’s on my to-do list to set up a Fidesmo-compatible provisioning server, as well.
Ah, so without their prefix? I see. In the meantime, I patched yktool to accept my Fidesmo AID as well, but while it works for testing that isn’t really a viable solution since many more apps like KeepassXC expect the correct Yubico AID. That AID is used or owned by Yubico though, if such a thing as ownership for AIDs even exists.
Interesting, any recommendations on cards? Preferably ISO 14443-A.
Good call. Expecting the user to compile and run a command line tool on the PC via a USB reader is kinda bad. So we would essentially have to build something like the (subset of) Yubikey Personalisation Tool but for Android (and maybe PC via PCSC)?
Well, we can go one further. Fidesmo has support for not only applets in their store, but complex flows to configure those applets. They run via a backend called by Fidesmo’s API to a (what would be VivoKey’s) server, which transcieves commands to the card via their API.
AID ownership is indeed a thing. DT’s AID is the A000000747 prefix, you register for them (and it costs money). I think VivoKey owns one specifically, too, but I’d have to check. Fidesmo will allow certain applets to use AID prefixes other than their own or one you have control over, such as for PIVApplet, as it’s a standard AID.
I was able to procure P71 test chips from China, but I can’t give any guarantees on getting more.
This sounds promising, but great care must be taken to guarantee that the HMAC secret never leaves the phone (unencrypted) or could be otherwise leaked from the API flow. Or it should be generated on the card itself, but programming a shared HMAC secret is an important feature to have.
I see. Are these P71 chips the same as the ones used in the Apex?
Hm. In the case of the Yubico AID that’s debateable, but ultimately up to Fidesmo if they want to allow third party implementations of a competitors product. (Assuming the interface of the Yubikey applet is non-standard). Also, the applet I linked only implements only a subset of the functionality provided by the Yubikey OTP applet - It does allow to configure two slots,but is missing the other functionality apart from HMAC-SHA1.
I found some sellers in Guangzhou and Shenzhen via Alibaba, but the minimum order quantity exceeds what I would be willing to spend for testing a hobby project. Maybe some would be willing to send samples, but I’ll just continue using the Fidesmo card. US and EU sellers offering ISO14443A javacards with other chipsets seem to have quite large minimum order quantities as well.
@fraggersparks As promised, here is my fork of YkOTPApplet which mirrors the vk-u2f structure and also contains an important patch which makes it compatible with KeepassXC: GitHub - StarGate01/vk-ykhmac: Javacard applet emulating the Yubikey challenge-response interface . Fork it into your namespace if you want or I could migrate it.
My only test device at the time is the Fidesmo card 2.0, so I cannot guarantee that it runs on an Apex or whatever. It targets jckit 2.2.2.
The fix mentioned is this: Fix padding handling for 64 byte challenges by StarGate01 · Pull Request #5 · arekinath/YkOtpApplet · GitHub .
The KeepassXC PCSC implementation is coming along well, some polish is still needed but I am able to unlock the database using either a Yubikey 5 via a USB NFC reader or the Fidesmo card running the applet. Both devices carry the same secret obviously. Yubikey via USB still works as before. I’ll make a PR for KeepassXC when the implementation is done, until then it is tracked in a feature branch in my fork: GitHub - StarGate01/keepassxc at feature/yubikey-pcsc .
The integration into KeePassXC is done and tested. The PR can be tracked here: Implement support for Yubikeys and potential other tokens via wireless NFC using smartcard readers by StarGate01 · Pull Request #6766 · keepassxreboot/keepassxc · GitHub . Is is very possible that there will be a lengthy discussion process until / if this PR is merged.
Great work! I went ahead and hearted it, hopefully if a few other people from the forum do as well, they’ll see that it’s a desired feature, even if the PR has to be modified.
There are a couple of build failures you need to take care of in their automated testing before the PR can be merged.
I know, see my comment at Implement support for Yubikeys and potential other tokens via wireless NFC using smartcard readers by StarGate01 · Pull Request #6766 · keepassxreboot/keepassxc · GitHub
Turns out, I don’t need physical cards at all. It is possible to emulate javacard applets in a way that is compatible with KeePassXC using a software stack consisting of jcardsim, vsmartcard and pcsc-lite.
If anyone in the future faces the same issues as me, I documented the emulation procedure here: GitHub - StarGate01/vk-ykhmac: Javacard applet emulating the Yubikey challenge-response interface .
Good news, after some more discussion and development, the PR has been merged and is on track to release with KeePassXC version 2.7.0 (the next one). You can test is by compiling the offical “develop” branch by yourself.
Seriously, fantastic work.
A few months later, the first public beta build of KeepassXC v2.7.0 is available for download, so everyone using a YubiKey / ykhmac javacard can test the new NFC PC/SC interface.
again, great job.
