Thanks for the report, it is not your fault. Fidesmo pushed an update to their management API today, which apparently caused some disruption in the way how app access is handled for users.
We have isolated a probably cause, and are working with Fidesmo to resolve the issue on their side asap.
Ok Fidesmo has fixed the issue… though the first time you use the Fidesmo app since the fix, it may take a very long to sync up. It took around 2 minutes for all the icons and buttons to properly appear again for every app.
I don’t know how it was possible for the chip to become locked. I remember locking the NDEF applet - but that shouldn’t have locked the whole thing, right? Is there a password for unlocking it?
definitely don’t use GPP with an apex… you don’t have the master keys and attempting to use GPP will lock it in very short order. the GPP app even warns you of this when you run it.
can you scan with the Fidesmo mobile app? can you do a deployment of any other apps? can you use the apps already on the chip?
I can use the existing apps on there. NDEF and FIDO both work fine.
Fidesmo Android app scans the chip and reports the installed apps. But when trying to add or erase, it gets stuck at “Testing connection stability”. The progress bar doesn’t move. It eventually times out. “The source did not signal an event for 120 seconds and has been terminated.”
The NDEF applet can only be locked once, it cannot be unlocked. To have an unlocked NDEF applet again, you have to re-install the NDEF applet.
“Locking” in the context of the NDEF applet just activates the write-protection for the data stored in the NDEF container. It does not concern applet installation / removal.
I only used GPP once - which gave me that result. But the chip appeared unresponsive before then. It stopped responding after trying to use Fidesmo to remove an applet.
All that said, does that mean I can brick anyone’s implant just by sitting next to them?!
You cannot “brick” a smartcard, but you can break one. It’s much more useful than a brick.
The chips are designed for a world where they are programmed once, then used for many years.
Yes, you can permanently lock out the management interface. You can also lock a FIDO PIN, btw, but that takes eight attempts.
PIV has a PIN unlock PIN but the situation is similar. All these systems choose to be less vulnerable to letting someone steal your keys by brute force and thus more vulnerable to someone destroying them.
If they’re designed to be programmed once - why are they sold as having applets which can be installed, uninstalled, or updated?
I’m not super-upset. My chip still works as a FIDO2 token - although it’s annoying that it doesn’t work with GitHub and can’t be upgraded. Similarly, the message in the NDEF is fine, and the domain is registered for the next decade.
I’ve looked around the website and I don’t see any warnings about the risks that the chip can be so easily broken. It seems odd to me that a handful of malicious commands in an app or script could turn off critical functionality.
The whole NFC ecosystem seems incredibly fragile.
Anyway, thanks for the help. And thanks for the HID bridge - that works perfectly on my Linux laptop.
Because THAT is how they work.
I have installed and uninstalled applets a few times now over the life of my Flex, and I have had mine since the release.
As far as updates go, Im not sure if that functionality works like that yet, to do an update, I have had to uninstall then reinstall.
My opinion, for what its worth, I think although breaking the chip is possible, I wouldn’t say it was “easy”
You are probably correct about a putting warning somewhere though.
This would be really relevant to the “Advanced” user poking around, where they really shouldn’t.
The “advanced” user would also more likey go down the path of the FlexSecure.
Again, poking around where you probably shouldn’t
Just to be clear, I’m not shooting you down, just giving my view / opinion
What I meant was that if there’s a bug in the Fidesmo app or a popular client library, there’s a risk these chips become broken. Worse, if I sit next to you on a bus, I could permanently degrade your hardware.
On that note, if I wave my phone over your chip - can I uninstall one of your applets without authentication?
Oh, I see.
I can only speak to the QA I see come from VivoKey, Im personally happy with the process.
I can only ASS-U-ME that Fidesmo have good procedures in place and can only hope if they fuck something up, it can be unfucked.
I would put this in the realm of a targetted attack, Personally I feel safe from this, but maybe you have more enemies than me
I know with my phone, trying to read and write to my own Apex, I needed* to be very close, AND to install or destroy an applet, it takes far longer than a wave of my phone.
*I now have a @Hamspiced Resonant repeater in my phone, so reading and writing is much easier now, but still not faster, because it takes time to process the…process.
Anyway, just my opinion, and I feel I am speaking out of school here “defending” VK, I am just another customer like you.
Yeah it definately would take some extended time but i could see a malicous actor doing something like this.
They would need to be close contact with where your implant is, and maybe if they had their clothes lined with repeaters, and could be in close contact to where your implant is for extended time it is “possible” but i wouldnt say it was a probable attack.
Now… if you were to do something like the RFID thief, and could pass commands through it that changes things entirely. but it isnt capable of that.
For the Apex, Fidesmo communicates with your chip via the GlobalPlatform interface, but they hold the administrative keys and keep them secret. To expose functionality they provide their App which acts as a secure pipline between your chip and the Fidesmo servers. For the FlexSecure, you manage the chip locally yourself via direct GlobalPlatform, using e.g. the GlobalPlatformPro software.
The P71 chips in the FlexSecure and Apex products do only allow a certain amount of wrong GlobalPlatform authentication tries before they enter a locked state. In this state, the chip is functionally unusable, i.e. only a certain end-of-life applet can then be used. This is not what we are seeing in your case, since the chip is still communicationg with the Fidesmo App and also (as you reported) still allowing the normal usage of applets which are already installed. If the chip was terminated by the Security Manager on the chip due to too many failed authentications, it would have transitiond the card to the CARD_LOCKED state. refer to § 5 Life Cycle Models and § 9.6.3 Card Locking and Unlocking of https://globalplatform.org/wp-content/uploads/2018/05/GPC_CardSpecification_v2.3.1_PublicRelease_CC.pdf .
Due to this, I think the failure of the Fidesmo App to uninstall applets on your chip comes from a bug, potentially from the recent API changes. Please post which phone you are using, which apps you are trying to remove and a capture of the Fidesmo App trace (Settings → Enable logging).
To add to this, if you “soft-lock” any of the applets like the NDEF write protection, FIDO2 pin authentication, or even the OpenPGP pin entry, you can just reinstall the applets and re-deploy / register your secrets to recover.
That may be true from a design perspective (and certainly is for older chips), but there is nothing preventing us from using the modern generation of chips as a flexible in-field programmable platform. (EEPROM wear is a concern, but not for the amount of use we have).
Applet management is possible in all states except the end-of-life states for the card, iff you have the administrative keys.
That is a somewhat legitimate concern, but there are easier ways to brick an implant - a strong enough electromagnetic field will burn the chip, and a screwdriver though the skin will poke a hole in it. The discussion then degrades to threat modeling.
Fair. We already see these kind of skimming attacks happening with NFC enabled credit cards. That is the reason for PIN codes on many applets. I agree on not impossible but improbable, especially since the implant is concealed.
In my opinion, the more legimitimate concern are malfunctioning well-intended devices bricking chips. We saw this with some older NXP chips where an unstable connection would could brick the chip. The GP authentication issue still persists. Fidesmo has taken steps to ensure the app establishes a connection as careful as possible, and we are looking into the theory of chip recovery. Until then, users have to be a slight bit careful.
TLDR: I do no think your chip is bricked due to too many GlobalPlatform authentication failures. Otherwise you would not be able to use the existing applets. Please provide more data to diagnose the specific bug.
Edit: Whoops, just saw that you already tried fdsm. Will try to reproduce the bug. Maybe try to deliver the “install” recipe once again, and then the “destroy” one?
Just a minor correction: while you’re right that using an incorrect administrative key too many times transitions the card lifecycle, how that lifecycle transition is handled is up to the card OS itself. The cards I’ve used before (not the P71) have locked out admin access but not disabled selecting and using existing applets.
It sounds like you know more about how the P71 in particular works; if it just disables the card entirely, well, that’s a shame.
As you all seem to have concluded above, there’s no realistic risk of this happening “at random”. Someone would have to do it on purpose. A software bug could theoretically do it but it’s just not likely; it’s really in the domain of a malicious attacker or a user trying to manage a chip that’s actually managed by Fidesmo.
With the FlexSecure you control this key yourself instead of Fidesmo being the ultimate owner.
Well, thats at least what I assume about the chip coming from the docs … usually, in a locked state, only the FinalApplication applet may be selected. I dont have real-world testing on this for the P71 though.
Interesting point though, which cards did lock you out without disabling access?
somewhere though.