Technical Info Request - Apex Platform

Heya. I tried emailing Apex but didn’t get a response, so I figured I’d shoot a message into the void here.

I’ve written a FIDO2/CTAP 2.1 applet: GitHub - BryanJacobs/FIDO2Applet: FIDO2 Javacard Applet . Now I’m interested in some details about this platform, since it looks like the Apex is one of a few open-ish Javacards out there. I’d love to see people using wearables (or implants, for those more daring than I) to authenticate everywhere.

Technical Questions:

  1. From reading, it appears the P71 is the core chip behind the Apex Flex / Ring. What is the amount of available flash, and more importantly how much TRANSIENT_RESET/TRANSIENT_DESELECT memory can applets expect to have available?
  2. Fidesmo lists acceptable crypto for applets, and ECC secp256r1 isn’t on it. But that crypto is core to FIDO standards! Does the Apex meet the technical requirements at ?
  3. What APDU buffer size is available for the chip? (free extra RAM!)

Nontechnical Questions:

  1. Can users directly install applets to the chips, or does Fidesmo attempt to hold the transit keys, and only let users install applets by calling cloud-intermediated APIs?
  2. Is the source of the Apex FIDO2 applet available anywhere? Is the applet itself? I see a bunch of dead repo links - it looks like it’s been closed off?
  3. What’s up with the Apex Ring? I was thinking of doing my own version of the OMNI - The most advanced, hackable NFC Ring® ever! – NFC Ring (which uses an Infineon processor limited to 271 bytes of transient memory…). I see the orders page says it’ll ship in Q2 2023 so obviously I’m not going to place a “pre” order for the past… when would the hardware ship? Is there some way to get a prototype?

Welcome @BryanJacobs
It’s great to see developers having interest in the platform.
The guy who can answer your questions best is the company owner himself @amal
Another person related with development is @StarGate01

  1. See

  2. Yes, the Apex can even do JC 3.0.5. secp256r1 is supported, you just have to specify the curve coefficients manually similar to e.g. .

  3. At least 133 bytes, possibly more, I am not quite sure.

  4. Correct, Fidesmo controls the ISD keys on the Apex. The flexSecure is the same chip but without Fidesmo, meant for developers and power users. You have to ask Fidesmo for a developer account if you want them to sign your applets to load them on Fidesmo-enabled devices.

  5. The Source of the Apex FIDO2 applet is currently private. The applet binary is available via Fidesmo for Apex customers.

  6. Thats a question for @amal

I think your applet presents an interesting opportunity for collaboration. It would be great to get you in contact with @amal .

1 Like

I may be wrong so take it with a grain of salt(and @amal can correct me of course) BUT I went to check what NXP have in their product sheet.
Matching P71 there are two controllers available P71D320 and P71D321

From the tech specs it seems Apex utilises P71D321

edit, I am not wrong, but I had to check @StarGate01 answer to point 1 before writing this…

@StarGate01 thanks so much for the answers!

It sounds like the FlexSecure is exactly the type of thing I’m looking for. If there’s actually 4K of RAM for the applet I wouldn’t need to play with APDU buffers at all - that’s more than enough for my applet to run without ever touching flash (except for durable storage of course).

Since it’s possible to run arbitrary applets on the FlexSecure, would it be possible to get the output of GitHub - crocs-muni/JCAlgTest: Automated testing tool for algorithms from JavaCard API supported by particular smart card. Performance testing of almost all available methods. The results for more than 100+ cards. from someone who has one? That will contain all the technical details I’d want and then some. If it supports some of the better crypto algs it would be possible to optimize the applet further - for example using a hardware HMAC instead of the software one I wrote myself.

Since things look good I’d love to buy one of the packages based on the chip. But I’m not super interested in getting a relatively fragile implant, so I’ll wait for @amal to see what availability is like of one in some kind of durable wearable.

I’m very open to “collaboration” with the applet, or of course it’s MIT-licensed so you can just take it even if I weren’t. From the way you’ve described your own one it sounds like mine is further along :slight_smile: .

Thanks again!

Heh, I just checked (from a potentially-different P71 D321) and it still doesn’t support ALG_HMAC_SHA_256 so I guess my software implementation in that department is there to stay. No problem though.

Correct, we do HMAC-SHA256 in software as well. The P71 does not have it, but you can derive it easily by using two rounds of the inbuilt SHA256.

Also, that Alg Test report came from one of the Vivokey devs :slight_smile:

Yeah the main annoyance is needing to set up the buffer in memory to do it, since HMAC-ing 64 bytes like FIDO needs for PIN verification requires a 96 byte contiguous array. In fact it’s the second-largest memory consumer in my whole application, after I/O buffers.

But even with the 1.8kB of RAM that jcalgtest output for a different P71 says, I wouldn’t be too worried about using 96 bytes of RAM…

Fair. I use the APDU buffer for that.

If you take a look at the implementation there, I wrote a manager class that uses the part of the APDU buffer above the request, the part behind the read cursor (when information has been read out and is no longer necessary), a transient_deselect buffer, or as a last resort spills to flash (for cards with truly tiny amounts of RAM).

clientChangePin takes a new PIN as input, and needs to HMAC that. It can get to the point where the portion of the old request still in use plus the amount of working memory are, together, larger than the APDU buffer. Admittedly it’s better in CTAP2.1 where PINs are capped at 63 bytes; in CTAP2.0 they could be arbitrary length.

@amal are you the person to ask about the Apex Ring? I have some P41 tape-on-reel samples here but I can’t be sure they’re masked the same way your implants/ring would be, and I’d like to make sure the FIDO2 Applet works fully in that environment.

I’ve been thinking about going through the FIDO certification process since I can pass the self-cert part and that would let me get a Metadata-Service-approved certificate, but in order to do that for the higher levels I need to bind the applet to a particular piece of hardware.

How are the wearables going, and what’s the best way to get development supplies?

Hi @BryanJacobs … kinda… @StarGate01 is doing the development of our FIDO2 applet for Apex devices (ring included), and we’ve come a long way with our solution… but yes certification is a major hurdle and requires a lot more admin overhead than initially anticipated. To put it bluntly, it’s a slog. All of our Apex devices (Apex Platform - VivoKey Technologies) currently use a special masked P71 which has a specific feature set required by Fidesmo. It’s a custom NC12 / SKU part number. At the moment we don’t have any Apex development hardware options because Fidesmo specifically shut down their open developer program, but as far as FIDO goes, the flexSecure is running on identical P71 hardware, just with a more standardized ROM mask.

The rings are great, we have inventory, everything works, but we are still waiting for partners to get in line… particularly our US based payment issuer.

I don’t particularly care about payments support. Would it be possible to purchase a flexsecure-setup ring? I don’t like the idea of having an implant sitting around just for me to do development on it, and the wearable would be more useful long-term.

I think it’s pretty likely my (MIT licensed) applet would run fine, from what you’ve said, so perhaps as an alternative you’d like to try it out on your own hardware and report back? I can’t access your applet to compare without a device of my own.

If things go well perhaps I’ll set it up to be Fidesmo-distributed so users can have something open source instead of closed. Better for everyone, right?

We don’t have any flexSecure type P71 rings… but I think you can get cards with the same P71 chips inside from here;

That site has had a banner saying they’re working on their shipping (with the cart inaccessible) for almost two years now.

I do have P41 chips around, and I made a circuit for connecting them to an antenna for wearables.

If I need to I guess I’ll go solder them up. They’re pretty tiny so it’s not the most fun thing to do at home.

Honestly the only reason we’re not opening it up is that the FIDO ecosystem is set up as a commercial battleground where creating hurdles to competition is almost considered sacred. the costs and complexity involved mean companies are investing to create a saleable solution… so it becomes very difficult to balance the apparent benefit of letting everyone see your source with the practical outcome being that nearly nobody will contribute, while competition gets a hand-out. This is the back and forth debate for all OSS as far as I can tell, but the effects of this exact situation are hitting our small startup team right where it counts. Still, I’d be happy to have a chat to talk if you want… I can DM a calendar invite.

Do you have bare die? The standard MOB package is pretty easy to work with with a standard soldering iron… do your chips look like this (without the metal ribbon garbage around it)?

hmm… i did arrange a purchase recently (last 8 months or so) through email…


However, I do believe I have a couple loose mob package P71s for flexSecure I could front you. Let’s schedule a chat?

Oh man, that would make my life so much easier if I had a package like that. Mine are just the center chip, 4mm wide - they come off a reel and I made a custom PCB that attaches the A/B antenna pins, but it would be so. much. easier. if I had something with a nice big pad like that.

I’ll message you to schedule a chat.

i’m so curious… these are the P41 chips you have? Can you post some images?

It’s a P41, yes. They’re really small which is nice for wearables, but… not so easy to work with.

The carrier PCB just connects the antenna pins to the breakout pads on the left/right.

ahhh yeah… that makes sense… interesting. definitely the mob package makes things way easier for contactless only stuff