Sorry, that post slipped my attention.
The limitation on write-cycles is caused by the underlying memory technology. Up to version 4.0 the secure element chip (SmartMX2) was based on EEPROM cells, while the later secure element chips use Flash memory instead. In both EEPROM and Flash, you can write a single bit from 0 to 1, but you can erase only a complete row of bits. A row of bits is typically 16 bytes.
Now assume you have a PIN retry counter byte. This byte must be decreased before you compare the presented PIN with the stored PIN. If both values match, then you need to reset the retry counter to it initial value. That makes 2 writes to the cell.
NXP assures that each EEPROM memory cell survives at least 500.000 cycles. Then writing to it becomes unreliable. In our own tests, we did around 3.5 million writes to force failure of the cell.
The operating system running on the chip tries to counter the effects of cell wear-out, by switching memory areas. But that mechanism has it’s limitation in write transaction processing, which is required to mitigate tearing attacks (you remove the chipcard from the reader, while a cell write is in progress, leaving memory in fragile state).
Another effect is the design of the JavaCard VM, that executes the Java byte code in the operating system. The process model of the JavaCard is, that the heap is in EEPROM. When you allocate an object, then that is not in RAM like on a PC, but in persistent memory. During a power cycle, the object survives, so that the JavaCard application continues to run with the same object instances as before. Only very few objects are held in RAM (like the APDU buffer or transient arrays) and do not contribute to cell wear-out. RAM is compared to EEPROM a very rare resource in the chip.
When designing a JavaCard applet like the SmartCard-HSM, one obviously needs to carefully design the application with cell wear-out in mind. But some operations using the JavaCard API cause effects in memory that can not be circumvented. Those are specifically cryptographic primitives, which often have state flags in EEPROM.
The situation has improved a lot lately, mainly because SmartMX 3 is now using Flash memory and JCOP 4 uses JavaCard API 3.0.5. The JavaCard API now supports a OneShot API, that allows to call crypto primitives without a full instantiation of the API object.
A general recommendation is to switch to the 4.0 version, if you plan to use the device for a large number or crypto operations.
For versions before, the general recommendation is to do PIN verification only once per session and to do hashing outside the secure element.
Of course key management operations will always require EEPROM writes, as this creates objects in EEPROM memory. Unlike crypto operations, that just process some inbound data using key material read from EEPROM. But again for the 4.0 version cell wear-out should be no issue anymore (comparable to SSD disks).
