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.
Sorry, I should have been clearer. Is there a password for unlocking the entire chip?
At the moment, it won’t let me destroy any applets - so I can’t reinstall NDEF.
If the wrong transit key is sent with gpp three times, the chip is permanently done and can’t have applets installed or uninstalled again.
gpp silently defaults to the wrong key. This includes even just list commands.
If you did that, you did that.
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.
I think you may have misunderstood.
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
I think your comments are fair.
But, on this one:
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.
Now, concerning potential attacks.
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.
Fair. Although there is a warning for the https://dangerousthings.com/product/flexsecure/ in place, @amal might want to add one to the Apex page to warn users not to use GlobalPlatformPro etc.
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?
Oberthur cards from the days of yore before I learned not to do that.
I’ve tested several Cybernetic devices after the Fidesmo update and they are removing applets just fine. @edent if you’d like to hop on a call to sort this out I will DM you a calendar link you can book a time to chat?
Sounds good. I’m free all of Friday. I’ll post logs etc this evening.
From Fidesmo
It really looks like the device has been locked: when trying to authenticate, it rejects out attempts with the 69FF error (which usually means too many failed authentication attempts). Before that the same command was ending up with “Conditions of use not satisfied” (the 6985 error). The thing is, the device was locked somewhere outside of our platform, so I can’t say exactly why this happened. Roughly the last time it was working was on Jan 31, after that the next connection to our backend was on Feb 14 and the device had been already locked.
So, it appears that using GPP with the default master key one too many times has indeed locked the chip.
Interesting that the P71 still allows access to applets even though it was locked via the Security Manager. Thanks for the report.
I’ve asked fidesmo if they have some other lock mode for their rommask that is different from the factory p71.
Final update from Fidesmo…
This state indeed allows to perform some simple operations that do not involve connecting to the ISD, but 69FF error indicates that it’s not just a card lock, but a P71’s authentication retry counter threshold kicked in. And P71 documentation doesn’t provide any solutions for recovering from that state, unfortunately. So likely the ISD access on that device is locked forever.
So now the big question is… how many times did @edent try using GPP… was it 3 times… or closer to 8 times?