Apex Flex - applets no longer install

Support
#1

My Apex Flex can’t install applets anymore.

  • I received my Apex Flex and started testing applets prior to implantation.

  • I successfully installed Free Memory, NDEF (8KB), Tesla, OTP applets, then attempted the FIDO U2F. It took a long time trying to install (as expected) but failed, saying I may not have had enough space.

  • I removed the other applets one at a time and reattempted the U2F install, unsuccessfully each time, until I removed all applets - thinking the U2F applet must need all the Flex’s storage capacity (or almost all). Yet again with no success.

  • I attempted to reinstall the above apps that were working fine until being deleted and got the same time-out/maybe not enough capacity error and none worked.

  • I then attempted to install the Fidesmo link applet (f02a1083) to see if it was just an issue reinstalling applets that had been deleted - this didn’t appear to be successful either when I did it last night however I now see it as installed in the Fidesmo app but not in Apex Manager - plus the website does not appear to be accessible as an NDEF link as it should be.

  • I have used Fidesmo on both Android and iOS, it will scan the chip to know it has no services installed but doesn’t seem to connect properly to install either by tapping ‘Connect Service’ or the manual method. Apex Manager scans OK, and just said ‘no applets’ etc until the Fidesmo link applet showed up this morning somewhat randomly.

  • Attempting installations again (Free memory applet on Fidesmo Android), it will stay on ‘Hold on… Testing Connection Stability’ until it appears to lose connection with the chip, will eventually go to ‘Step 1/3 Delivering Service’, then after a while it says: ‘The source did not signal an event for 120 seconds and has been terminated.’

Can anyone suggest what I can try to resolve the issue?

I have got the logcat.txt from Apex Manager and screenshot of NFC Tools scan below, happy to provide any other info if it helps!

Is it possible there’s an issue at Fidesmo’s end? Did I perhaps hit a request rate limit?

My implantation is booked for about 30 hours’ time so hoping I can sort this out ASAP, otherwise I’ll have to postpone it.
(Edited to remove screenshots)

The anti🚫-derailment🚃 & thread🧵 hijacking🔫 thread🧵 ⁉
#2

I believe @hoker is involved in the Apex Manager’s development?

1 Like
#3

I sent this to the software team directly. Hopefully we can get back to you tomorrow. Thanks for the detailed breakdown of events. Please stop installing or removing applets for now.

Just as a side note I don’t think the Apex Manager app will show any installed applets unless the “Free Memory” applet has been successfully deployed. And I’m pretty sure it only shows VivoKey applets, not Fidesmo. So don’t take the Apex Manager being empty as a bad sign.

2 Likes
#4

Howdy. Just for clarification, AM will show your applets, whether or not the free memory applet is installed, however, @Satur9 is absolutely correct that I don’t show any applets that aren’t developed by VK.

I personally don’t know what’s going on with your chip, but we’ll dig into it and see.

3 Likes
#5

Thanks for the help. I’ll hold off touching anything more until I hear back.
Let me know if I can provide any more info - have set Fidesmo to keep local logs but not sure where these are stored.
Have postponed my implantation for a week so have plenty of time to work this out - glad this is happening while it’s still outside me!

1 Like
#6

Appreciate the help!

#7

I’m doing something now and also made contact with Fidesmo support regarding the error. I’ve never seen that particular one before with the timing issue.

1 Like
#8

Do you have access to a Linux PC with a USB PC/SC reader? For reference here is a pcsc_scan and gp -info (from GitHub - martinpaljak/GlobalPlatformPro: 🌐 🔐 Manage applets and keys on JavaCard-s like a pro (via command line or from your Java project)) output:

Thu May  4 02:19:25 2023
 Reader 2: ACS ACR1252 Dual Reader [ACR1252 Dual Reader PICC] 00 00
  Event number: 22
  Card state: Card inserted, 
  ATR: 3B 8A 80 01 00 31 C1 73 C8 40 00 00 90 00 90

ATR: 3B 8A 80 01 00 31 C1 73 C8 40 00 00 90 00 90
+ TS = 3B --> Direct Convention
+ T0 = 8A, Y(1): 1000, K: 10 (historical bytes)
  TD(1) = 80 --> Y(i+1) = 1000, Protocol T = 0 
-----
  TD(2) = 01 --> Y(i+1) = 0000, Protocol T = 1 
-----
+ Historical bytes: 00 31 C1 73 C8 40 00 00 90 00
  Category indicator byte: 00 (compact TLV data object)
    Tag: 3, len: 1 (card service data byte)
      Card service data byte: C1
        - Application selection: by full DF name
        - Application selection: by partial DF name
        - EF.DIR and EF.ATR access services: by GET RECORD(s) command
        - Card without MF
    Tag: 7, len: 3 (card capabilities)
      Selection methods: C8
        - DF selection by full DF name
        - DF selection by partial DF name
        - Implicit DF selection
      Data coding byte: 40
        - Behaviour of write functions: write OR
        - Value 'FF' for the first byte of BER-TLV tag fields: invalid
        - Data unit in quartets: 1
      Command chaining, length fields and logical channels: 00
        - Logical channel number assignment: No logical channel
        - Maximum number of logical channels: 1
    Mandatory status indicator (3 last bytes)
      LCS (life card cycle): 00 (No information given)
      SW: 9000 (Normal processing.)
+ TCK = 90 (correct checksum)

Possibly identified card (using /home/christoph/.cache/smartcard_list.txt):
3B 8A 80 01 00 31 C1 73 C8 40 00 00 90 00 90
        NXP PN65o's Internal Secure Element in card emulation mode. (Other)

GlobalPlatformPro 18.09.14-0-gb439b52
Running on Linux 6.1.24 amd64, Java 1.8.0_362 by Oracle Corporation
Reader: ACS ACR1252 Dual Reader [ACR1252 Dual Reader PICC] 00 00
ATR: 3B8A80010031C173C8400000900090
More information about your card:
    http://smartcard-atr.appspot.com/parse?ATR=3B8A80010031C173C8400000900090

[WARN] GPData - Invalid CPLC date: 4F31
CPLC: ICFabricator=4790
      ICType=D321
      OperatingSystemID=4700
      OperatingSystemReleaseDate=0000 (2010-01-01)
      OperatingSystemReleaseLevel=0000
      ICFabricationDate=0323 (2010-11-19)
      ICSerialNumber=41544420
      ICBatchIdentifier=0094
      ICModuleFabricator=0000
      ICModulePackagingDate=0000 (2010-01-01)
      ICCManufacturer=0000
      ICEmbeddingDate=0000 (2010-01-01)
      ICPrePersonalizer=1220
      ICPrePersonalizationEquipmentDate=4F31 (invalid date format)
      ICPrePersonalizationEquipmentID=35343434
      ICPersonalizer=0000
      ICPersonalizationDate=0000 (2010-01-01)
      ICPersonalizationEquipmentID=00000000

Card Data: 
Tag 6: 1.2.840.114283.1
-> Global Platform card
Tag 60: 1.2.840.114283.2.2.3
-> GP Version: 2.3
Tag 63: 1.2.840.114283.3
Tag 64: 1.2.840.114283.4.2.85
-> GP SCP02 i=55
Tag 65: 1.2.840.114283.5.7.2.0.0
Tag 66: 1.3.6.1.4.1.42.2.110.1.3
-> JavaCard v3
Card Capabilities: 
Supports: SCP01 i=05
Supports: SCP02 i=15 i=35 i=55 i=75
Supports: SCP03 i=00 i=10 i=20 i=60 i=70 with AES-128 AES-196 AES-256
Supported DOM privileges: SecurityDomain, DelegatedManagement, CardReset, MandatedDAPVerification, TrustedPath, TokenVerification, GlobalDelete, GlobalLock, GlobalRegistry, FinalApplication, ReceiptGeneration, CipheredLoadFileDataBlock
Supported APP privileges: CardLock, CardTerminate, CardReset, CVMManagement, FinalApplication, GlobalService
Supported LFDB hash: 02
Supported Token Verification ciphers: 7B
Supported Receipt Generation ciphers: 0C
Supported DAP Verification ciphers: 7B
Version:  48 (0x30) ID:   1 (0x01) type: AES  length:  16 (AES-128)
Version:  48 (0x30) ID:   2 (0x02) type: AES  length:  16 (AES-128)
Version:  48 (0x30) ID:   3 (0x03) type: AES  length:  16 (AES-128)

Also, you can try to install GitHub - fidesmo/fdsm: Tiny Fidesmo command line client in Java on your PC and query the internal applet list from the chip using java -jar fdsm.jar --card-apps. Maybe Fidesmo messed up deleting applets and there are applets left over but not actually instantiated. Example output:

Using card in ACS ACR1252 Dual Reader [ACR1252 Dual Reader PICC] 00 00
#  appId - name and vendor
99848a60 - Free Memory (by VivoKey Technologies)
           Services: install, destroy
2f2e363b - HMAC-SHA1 Generator (by VivoKey Technologies)
           Services: install, destroy
61fc54d5 - OTP Authenticator (by VivoKey Technologies)
           Services: destroy, install
cc68e88c - FIDO Security (by VivoKey Technologies)
           Services: install_fido2, install_u2f, destroy

In the past, I also had my Android phone to subtly crash the NFC stack, requiring a reboot before anything regarding NFC worked again.

2 Likes
#9

Thanks @amal, much appreciated. I contacted Fidesmo directly too, prob going to get more movement from your end though so might cancel mine or at least get the tickets combined.

#10

This is exactly what I was hoping for @StarGate01 - you’re the O’Neill to my Thor!
Yep I have a spare Raspberry Pi and can access a Proxmark so will try the GPP method.
Will report back. Thanks heaps.

2 Likes
#11

Lmk how it goes. Just a heads up, I dont think(?) the Proxmark can act as a CCID PC/SC compliant smartcard reader, which is required by all the tools I mentioned. A compliant reader would be something like the ACR122U or the better ACR1252 (other companies offer readers as well). If you dont already have such a reader, its a worthwhile investment in order to properly use your Apex with your PC.

#12

Ok… we have some feedback from Fidesmo…

  • There were 68 attempts to perform interactions with the chip!
  • The initial error deploying the FIDO applet was caused by iOS. The problem is that iOS allows continued access to the chip for 20 seconds only, and loading the applet took more than that. Fidesmo attempts to split operations into small portions to fit into that limit, but as loading has to be done in a single SCP session there’s no way to do that in this case.
  • The message about not enough space is shown by FIDO deploy script for any failure, so it’s not related to anything. We are limited in what we can display when it come to errors because the error is not accessible via the deploy script processor.

This is where things get dicey…

  • After the initial failures, APDUs received response code [6985] Conditions of use not satisfied on establishing an SCP channel, which might mean that previous failed attempts forced chip to lock itself. I’m not aware if the chip has a fail mode for failed secure channel creation or not… I’m only aware of this issue with security domain authentication, not failure to establish a secure channel. More research is needed.

So, suggestions;

  1. Stop trying to do anything with the chip for now with iOS
  2. Attempt to get a PC/SC compliant reader and perform the checks suggested by @StarGate01
  3. Fidesmo suggests borrowing an Android phone with Fidesmo app and attempting to read / detect the chip (no app deployments, just read and report)
#13

Strange, 20 seconds should be plenty even for FIDO2 deployment. Maybe the coupling or transceiver was particulary bad, degrading datarate?

#14

I was thinking that as well… iphone’s nfc antennas are crap for flex unfortunately.

What is interesting is that after the initial failure it seemed to just be borked… like nothing worked after that… which is odd.

#15

Already after the very first initial failure? Usually a chip would not lock just because a GP upload aborts, only after many deliberate authentication failures …
If any of the Fidesmo tools to list the applets still work (either the Android app or fdsm), we at least know that the chip is not electrically damaged. Listing the applets does not require a secure GP session.

#16

It should also mean the chip is not locked, since fdsm needs to send APDUs to determine the CIN (fidesmo ID) of the chip, and that would not work if the chip was ISD borked

#17

Fidesmo is now performing some internal testing to figure out just how things happened. It’s not making sense to anyone at this point.

2 Likes
#18

As everyone who needs to know seems to have the log data they need, you might remove those screenshots in the first post. Of anything, I feel like your chip’s serial number might be info you don’t want archived on a public forum, just as a matter of infosec.

#19

Probably yes… the UID is not used in any capacity with the applets on board but could be used by independent access control systems… if enrolled.

#20

Hi, cheers for tip to remove screenshots - was aware some info might not be ideal to post but was panicking a bit. They’re gone now.
FYI, my ACR1252 is taking forever to arrive so haven’t had a chance to look into this further yet.
Will reply once I’ve got it, prob another 5-6 days…

1 Like