Persistent Memory (EEPROM) Leak during Credential Deletion and Authenticator Reset

[GN998]

Hi, Thank you for your project, but I have been testing this Applet and noticing a critical issue regarding persistent memory management.
It appears that the Applet does not release persistent memory (EEPROM) when credentials are deleted or when the authenticator is reset. Instead, the available memory monotonically decreases with every write operation, eventually leading to permanent storage exhaustion (bricking the card).

I have collected memory status data on firmware 2.0.5 and 2.0.11 using APDU commands . [82]

Section 1: 2.0.11 Test
Test Scenario [82] (Hex) [82] (Decimal/Bytes)
Initialized, no data written: 00020001eb24 125,732 00000b34
Attempt to fill memory: 00020001BFC4 114,628 00000584
After reset: 00020001bfa0 114,592 00000584
Attempt to write 10 items after reset: 00020001aee8 110,312 00000584
Reset after writing 10 items: 00020001AEC4 110,276 00000584
Reset after writing 10 items, then write 10 more: 000200019e0c 105,996 00000584

Section 2: 2.0.11 Re-initialization (Uninstall/Install Applet)
Test Scenario [82] (Hex) [82] (Decimal/Bytes)
Third initialization: 00020001e350 123,728 00000584
Write 10 items first: 00020001d298 119,448 00000584
No reset, directly write 20 more (or two rounds): 00020001b128 110,888 00000584

Section 3: Firmware 2.0.5 Test
Test Scenario [82] (Hex) [82] (Decimal/Bytes)
Initialized, no data written: 00020001e340 123,712 00000584
Attempt to fill memory: 00020001bca4 113,828 00000584
After reset once full: 00020001BC80 113,792 00000584
Attempt to write 10 items after reset: 00020001abc8 109,512 00000584
Reset after writing 10 items, then write 10 more: 00020001aba4 109,476 00000584

Section 4: Firmware 2.0.5 Continuous Writing Scenario
Test Scenario [82] (Hex) [82] (Decimal/Bytes)
2.0.5 Initialization: 00020001e340 123,712 00000584
Write 10 items first: 00020001d288 119,432 00000584
Repeat writing once more (20 total): 00020001c1d0 115,152 00000584
Repeat writing twice more (30 total): 00020001af6c 110,444 00000584

Section 5: Firmware 2.0.5 Test Data under "Write and Delete" Alternating Scenario
Test Scenario [82] (Hex) [82] (Decimal/Bytes)
2.0.5 Full initialization: 00020001e340 123,712 00000584
Write 10 items: 00020001d288 119,432 00000584
Delete 5 items: 00020001d288 119,432 00000584
Write 3 more items: 00020001cd84 118,148 00000584
Delete 3 items: 00020001cd84 118,148 00000584
Write 5 more items: 00020001c528 116,008 00000584

Card: NXP J3R180
OS: 22.04
NFC Reader: ACR122U-A9

[BryanJacobs]

You've neglected to mention which card you're using.

The applet calls the card garbage collector after freeing memory. Whether the card actually frees it is another matter.

Unfortunately, if you have one of the several cards that does not release memory when asked, nothing can be done about that.

[GN998]

You've neglected to mention which card you're using.

The applet calls the card garbage collector after freeing memory. Whether the card actually frees it is another matter.

Unfortunately, if you have one of the several cards that does not release memory when asked, nothing can be done about that.

Apologies—I'm currently editing the text and testing a separate issue, so I may not have provided the full information in my previous message.

Here are the environment details:
Card: NXP J3R180
OS: ubuntu22.04
NFC Reader: ACR122U-A9

Additional Details:

My test script uses a total of 10 accounts (a0–a9). The domain is rotated every 5 writes; for example, abc{0}.com is updated once every 5 accounts are written. This process is repeated for continuous writing.

Regarding repeated account inputs: Input 10 accounts, re-input the same 10, and then input them a third time.

[BryanJacobs]

I've triple checked, and there is a call to JCSystem.requestObjectDeletion() after each non-static memory allocation.

If the card OS (JCOP, for a J3R) supports cleaning up, it will clean up. There is nothing more that can be done in the applet so long as it uses dynamic memory at all.

If you want the applet to not dynamically allocate memory, feel free to compile it with NUM_RESIDENT_KEY_SLOTS_PER_BATCH set to 50 or similar. If you do that, and you don't use more than fifty resident keys at once, the applet won't allocate any new memory.

It is expected that deleting a single key will not free memory as the keys are allocated in chunks. It is NOT expected that resetting the authenticator will fail to free memory, but as said above, I'm confident that the OS (responsible for actually freeing the memory...) has been asked to release it.