Hi, I purchased two Vivokey demo cards (The Spark dev kit). However the Vivokey app is not able to read the cards, instead it displays “NFC error”. On the same phone (S7 running Lineage 16) the Fidesmo card 2.0 works without problems using the Fidesmo App, and various YubiKeys work as well via NFC. The NXP tag info app reads the Viviokey demo cards as ICODE DNA (SL2S6002) and the NFC Tools pro app is able to read it as well (ISO15693). A USB PC/SC reader (SCL011) is not able to read the Vivokey demo cards, but does read the Fidesmo card 2.0 and also various YubiKeys.
Am I missing something? How can I use the Vivokey demo cards with my phone or PC? I want to emulate a Spark (and eventually an Apex) implant for development and testing purposes.
I gathered that both the Spark and the Apex use the Fidesmo ecosystem. Are these any big differences from a developers perspective?
Keep trying to read. The full scan report you attached is incomplete. The reason for this is that Android totally borked iso15693 reading in their NFC stack with the release of android 9. My S7 worked fine reading NFC type 5 tags until that release, then would constantly fail… working about one in ten tries. Many other customers had this same problem all of a sudden. This is the primary reason we released the Spark 2 which is iso14443a. It’s super annoying, and we even sent demo cards to Google’s actual NFC developer in Singapore… they kept insisting it was fixed but clearly it’s not.
(1) Do you know if this issue has been fixed in Android 10 and beyond? I could update my phones OS if really needed.
(2) Since my PC USB-based PC/SC reader (SCL011) does not recognize the demo cards as well (the manufacturer specifies support for ISO 14443, but not ISO 15693), would the Spark 2 be supported better on this reader as well? I would really like to use this or a similar USB reader, because I plan to integrate it into my laptop and since I already have it. I don’t think a Proxmark would fit, and it would also require a bit of software shenanigans to get working like I would want it to.
(3) Since both the spark 1 and the demo cards seem to use ISO 15693, is the Fidesmo card 2.0 a better development platform for the spark 2 considering that it uses ISO 14443-A as well (Taginfo reports ISO 7816-4, 14443-4A, 14443-3A and 14443-2A)? Sadly, the Vivokey app reports “NFC error” for the Fidesmo card as well. Could it be reflashed to present as a Vivokey? Could I use any ISO 14443-A javacard and flash it as a Vivokey?
(4) Also, regarding PC/SC and CCID in general: The Fidesmo card reads great as a CCID device, which enables me to develop and test applets comfortably using the USB reader. Is this possible for the Spark 2 / the Apex as well?
(5) Regarding the upcoming Apex line: Does the Apex use ISO 14443a as well? Is CCID / PCSC supported? I plan to replace my Yubikeys.
Sorry for the amount of questions, and thank you in advance for any answers.
P.S. Since Fidesmo does not offer a HMAC-SHA1 applet I managed to compile and deploy an open source implementation of the one used in the Yubikey. I’d like to do the same or use an existing compatible applet on the Vivokey platform.
no, the java card capabilities of the VivoKey Apex and fidesmo card are totally different and separate from the spark 2… the spark chips are about proving identity using symmetric crypto features of the chips with the VivoKey platform (and app)… the Fidesmo platform is all about deploying java card applets to smart cards. The Apex chip will have a vivokey java card applet on board that will allow it to work with the vivokey platform and app, and also you can deploy other java card applets to it from the fidesmo platform… but you cannot use a fidesmo card with the vivokey platform or app because the vivokey ID applet that enables this will only be available on the vivokey apex.
well that depends what you mean by “test applets”… you could dev software that runs on the host and utilizes the spark and / or applets on the apex yes… and you could develop applets for apex to be deployed through fidesmo, but spark does not run applets.
To be clear, “applet” typically describes a java card app because they are extremely small and purpose built for one thing, where as mobile phone or desktops applications are typically called “apps”.
Thank you for the comprehensive answer, that clears up about everything I wanted to know.
I was indeed referring to javacard embedded applets, ultimately I want to do at least TOTP and HMAC-SHA1 challenge-response using the implant. This seems to be possible using the applets provided either by Fidesmo Inc, Vivokey (afaik you are developing some applets to distributed via Fidesmo which aim to achieve Yubikey feature-partity) or by me. Any cabable host “App” like pcsc-lite, Winscard or the yubikey authentificator should be able to communicate with whatever platform carries the applet.
I gotta admit, having my arm count towards the famous “3 Billion Devices that Run Java” is a strange thought, but I cant (unknowingly) lose or forget my arm at home. I guess crypto-anarchist trans-humanism it is then.
In conclusion, I’ll patiently wait for the Apex and keep developing for the Fidesmo card 2. I wish you much success developing and deploying the Apex, I am excited for the launch.
indeed. to be clear the applets must be deployed by Fidesmo to the Apex. we are working on a way to opt-out of Fidesmo but at the moment that’s not possible, so you will need a developer account to do so.
getting a developer account with Fidesmo is free and you can easily deploy your applets and even publish them to Fidesmo’s platform. that said, i think it would be cool to start some open source projects we can publish as official VivoKey applets… but of course not necessary. We do have plans in these areas, so coordinating may help speed things and reduce overlap… but again, totally up to you.
@fraggersparks is our java card applet dev btw… so we can coordinate in the open here on the forum or via other methods if you’re interested.
I am already using my Fidesmo developer account that I created many months ago when their registration was still open. I am using their handy fdsm tool to sideload applets onto the card directly from my PC using the USB PCSC reader, instead of pushing it to some API cloud and then downloading it via the Fidesmo Android app. These applets are signed using my Fidesmo keys and the framework accepts them without issue.
I’d love to collaborate on open-source stuff, however I cannot promise when and how much time I can spare. Currently I am looking into KeepassXC, I am planning to extend the hardware token interfacing from Yubicos USB HID to PCSC with whichever device implements the correct applet (could be an Apex in the future). The Yubikeys themselfs actually present via PCSC as well. My current motivation is to use the Yubikeys wirelessly on any device, the Android app is already able to handle it.
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.
I looked at the Vivokey namespace and found GitHub - VivoKey/apex-totp , 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 .
