has to be set in the chip at NXP (factory) during manufacturing of the silicon chip itself… and these will be… and the chip will be able to load and run EMV applications (for payment) and secure apps that use advanced crypto at the same time. The EMV applets are loaded by NXP during silicon manufacture, but the other applets you can deploy to the chip with your phone and the Fidesmo mobile app.
absolutely… each javacard application has a unique AID (application ID) which is “selected” by the reader and the code is run on chip. you can fit as many applications on as will fit in the memory.
I admit being too lazy to read through android docs (I developed an intense hatred over java, and Kotlin ain’t cute enough to balance it)…
But my money goes to how the libs are structured, mostly around the checks done to detect the presence of NDEF capabilities. What some libs do is to attempt and read a message, if you can’t, then there isn’t. If you can, then you already have it read.
(the whole “better ask for forgiveness” mindset)
In some libs, such as nfcpy, you have direct calls for that, which work well since that’s the paradigm you want. so you only check for the presence if you want to read it.
Now applying Android logic, whenever anything within Android finds something new, it must consume it to check if anything else was expecting you to find it (hope my layman’s version of “Intent” wasn’t too confusing), but then if your application has not told the system it wanted that piece of information yet, then it gets discarded, and the only thing that gets through is “yes, there is an NDEF message”, which then your code will open (and read again)
ps: as of the moment, this is but an educated guess I put together in the midst of assumptions and recollections. I really don’t want to go digging into Java source…
Yeah but proxmark3 hf 14a sniff shows it reads completely and then the app takes over and reads again… ugh. Though, you could be right if the app just wanted the ndef message and not actually issue read commands directly. Dunno.
it’s been a long while, but i recall there being a post somewhere on the vivokey forum about being able to secede from fidesmo’s ecosystem? is this still a thing with the apex, and if so, what sort of drawbacks would that have?
Yes this will be explored for Apex. We’ll need to construct a framework for essentially removing all applets from the chip and resetting it. This would also need to include the payment applets, and this may not actually end up being possible.
If that turns out to be the case, and we cannot properly extracate Apex from Fidesmo, then we might explore a truly open base line P71 model with no personalization at all. That would probably ultimately be a dangerous things product, not a VivoKey product. That would also mean no connection to the VivoKey platform either… and probably no official support beyond this forum.
