VivoKey Apex update

well… perfection is the goal here … which can be “the enemy of the good” I know… but we ended up getting our chips punched out of their carrier ribbons professional done by a robot… now they are headed to be reeled on tape so they can then be picked up by robots and perfectly applied directly to our perfectly designed flex PCB antennas.

Because of the types of applications these devices will be running, where private keys which cannot be exported from the chip do their work inside the implant only, we want to eliminate any possibility of future failure, however remote… even 50+ years into the future. The best way to do that is to make robots extract and place components with precision.

14 Likes

6 Likes

Ok so that means there will be some time needed :wink:
But I like the way of thinking to have the perfect product.
:+1:

2 Likes

Any progress update or status change is like crack at this point.

11 Likes

Far be it from us to deny you your fix

2 Likes

Now that we are getting closer any updates on this :slight_smile:

Basically Apex is forced us to refactor the entire core of the VivoKey platform. Once that’s finished in Apex is properly linked then we move on to service deployment that will work for both Spark and Apex.

3 Likes

Ohh yeah I get that the services released will support both, that was always the promise of vivokey.
What I was curious about that comment that I replied to and some stuff you mentioned when I was asking you about if it was worth getting a spark, if you know you will be getting and apex. The details are a bit fuzzy because it was last year… but I remember you mentioning that it could act as a backup for your VivoKey account and that you also teased “other advantages” to getting a spark and an apex.
I was expecting that we would get to order them early or something similar, but seems like that is for the club so now I am curious about the advantages you where teasing lol.

Oh I see what you mean. Basically the Spark 2 can act as a backup for your account yes, but I honestly don’t remember what I meant by “other advantages” unless we were talking about the Spark 1… then there is a clear advantage to having an ISO 15693 transponder that is also a VivoKey

1 Like

Kewl yeah, I plan on my Spark 2 being a backup basically once I get the Apex, my Spark 2 is happy in place where it is and I’d rather just leave it there and add the Apex implant :wink:

1 Like

:thinking: Would I be correct in assuming the Spark 1 can also be used as a backup? Sorry if it feels like I’m splitting hairs.

image

1 Like

I just searched around and found a thread that said kinda sorta probably but now that we are a year later and may have a more solid answer of if this is possible and how it would work: Can the apex emulate a desfire chip while still doing everything else from like payment(if enabled)?
I would have access to enroll it and I don’t need to clone.

ok so…

The P71 used for Apex does not have desfire emulation loaded… it is possible and is part of the base OS, but because of memory constraints it has been loaded on the OS used for the Apex. That said, in theory, I believe the way AIDs are typically selected and worked with on a DESFire means that you could easily set up java card applet to do the job of a DESFire applet, emulating commands etc. for the given “file type”… the file type of course being defined by the DESFire spec.

What is not so easy or even possible are the other features of the DESFire, such as privacy mode where the UID is randomized per ISO14443A session or the secure messaging modes. Java card has its own secure messaging methods but I don’t think they are directly compatible with DESFire. Key management commands, memory configuration commands, and file management commands (how you define and deploy and manage file types) are also not likely supportable with java card, though it might still be possible… I just don’t know because I’ve not dug that deep on it yet.

The bottom line though is that if you wanted to emulate a DESFire file type AID on the Apex, you totally could… you would just need to actually emulate the entire command set used for by the application for that file type.

DESFire EV2 Spec; MIFARE DESFire EV2.pdf (311.6 KB)

File structure;

image

5 Likes

I’ve been following your work for a while and it looks like the Apex will be the implant for me. I’ve got a couple of questions

  1. Are you still targeting 2021 for mass release?
  2. What form factors are planned besides the flexible strip? For one, the OP mentions a glass tube version.
  3. This is fucking awesome, gonna get a dev kit alongside the implant.

Soon™. The first batch are in production afaik.

Flex (flexible strip), Max (glass tube), Ring, dev kit (card). I am not aware of any other options…

Of course I am just a bystander so none of this is the official position of Vivokey.

Everyone temper your expectations on the Apex Max (glass x-series). We do want them to exist as a product, but as Amal has said before we have no ETA for that form factor being publicly available. The challenge is that the smaller tags require bare silicon die, which are only available in a full wafer which is a very expensive up front cost. Also any Max that exist will have similar performance issues to the other x-series (poor coupling), and you really need good coupling for a complex power hungry chip like the Apex.

There is also a “Mega” form factor in the works, which is a 25mm disk with LEDs and an optional hole in the middle. This can use the MOB package so it’s expected sooner than the Max, but we currently have no ETA for that form factor either.

The Apex Flex and the Apex Ring are the only form factors that are certain to be released Soon™

1 Like

I saw the post about production to give to Flex one beta users. I’m assuming the dev cards on the store are Spark 2 cards? I’m mostly interested in the Fidesmo app development stuff so I might pick up one of their YubiKeys if I get impatient.

I figured as much.

So sorta like the FlexMN? Sweet.

1 Like

My understanding is that these are closer to the Apex Java cards. They weren’t announced until March of this year, so I would be surprised if they are just the spark 2.

However there is an intention, currently unimplemented, to have them reset every 30 days so that they truly are development cards and not access cards.

Sorry for the maybe stupid question but what does ETA means?