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.
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 .
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.
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.