Symptoms of EEPROM damage

Question

Suppose there is a bug in a Java Card applet: a temporary byte array is stored in EEPROM instead of RAM. Moreover, suppose this byte array is overwritten with each APDU.

This bug should damage the card sooner or later.

What symptoms could we expect? Incorrect values in the array without any explicit warnings or errors? Some exceptions thrown when accessing this array? The applet unselectable? The whole card completely unresponsive?

Should the card be damaged "once and forever", or will these failures occur more and more often?

In my experiment (J2E145) there was the first failure after 5 000 000 APDUs and the symptom was that the card did not send R-APDU at all and just died. However, the next APDU was OK again, then approximately 1 APDU out of 10000 failed (with increasing frequency) and finally after 5 100 000 APDUs the card stopped communicating forever.

Is there any standard which says what should happen in case of the EEPROM damage? (I was looking for it, but I did not find any.)

I know the question is broad and it probably depends on the particular chip (I am interested especially in NXP chips), but I think your comments, answers and experience could help many Java Card developers, who found a bug in their code after deployment.

Andryc

Answer 1

I guess the best shot at finding some non-NDA'd information is the Common Criteria security targets for the specific platforms.

An example for a hardware platform from NXP: NXP Secure Smart Card Controllers P5Cx128V0A/P5Cx145V0A, MSO (BSI-DSZ-CC-0645)

• From the TOE overview:

  The non-volatile EEPROM [...] contains high reliability cells, which guarantee data integrity. [...] Security functionality protects the contents of all memories.

• From security feature SF.OPC:

  An exception is forced by the [...] single fault injection detection circuitry. In case minor configuration option "Inverse EEPROM Error Correction" is enabled [...] the probability to detect fault injection errors increases and the error correction logic raises an exception when detecting an error.

• From security feature SF.PHY:

  The EEPROM is able to correct a 1-bit error within each byte. [...] The EEPROM corrects errors automatically without user interaction [...]

So this hardware platform is capable of detecting EEPROM cell failures and can even automatically correct 1-bit errors within each byte. For all other detected errors it will raise an exception that can be handled by software.

That's for the hardware platform (without OS / JCRE). So let's see what a security target of JCOP tells us. I chose NXP J3A128 and J3A095 Secure Smart Card Controller Rev. 3 (BSI-DSZ-CC-0731).

• From security feature SF.Audit:

  The following reactions by the TOE based on indication of a potential violation of the TSP are possible:

  • Throw an exception
  • Terminate the card (Life cycle state: TERMINATED)
  • Reinitialize the Java Card System (warm reset)
  • [...] The EEPROM is able to correct a 1-bit error within each byte. [...] The EEPROM corrects errors automatically without user interaction [...]
  • Lock the card session (simply stops processing; escape with reset the session/Card tearing)

  Based on these types of response/reaction the events listed above will have the following mapping:

  • EEPROM failure audited through exceptions in the read/write operations and consistency/integrity check: Lock card session
  • self test mechanism on start-up: Lock card session
  • Corruption of check-summed objects: Lock card session

• From security feature SF.SecureManagement:

  The TSF run a suite of self-tests during initial start-up (at each power on) to demonstrate the correct operation of the TSF, to verify the integrity of TSF data, and to verify the integrity of stored TSF executable code. This includes checking the EEPROM integrity. If an error is detected, the TOE enters into a secure state (lock card session)

  The TSF monitors user data D.APP_CODE, D.APP_I_DATA, D.PIN, D.APP_KEYs for integrity errors. If an error occurs, the TSF maintain a secure state (lock card session)

So this software platform is (again) capable of detecting EEPROM cell failures and can even automatically correct 1-bit errors within each byte. For all other detected EEPROM errors it will "lock the card session", which means that it simply stops processing and performs a reset. This seems to match your observation "the symptom was that the card did not send R-APDU at all and just died".

Orlop

Thanks a lot for your research, excellent work! The TSF run a suite of self-tests during initial start-up (at each power on) ... If an error is detected, the TOE enters into a secure state (lock card session) - this means the whole card is broken and all its applets and their data are lost, right? – Andryc

You're welcome. Going through those docs to find a publicly citable reference was on my todo list for quite some time and your question gave a reason to finally dig into that again. – Orlop

Unfortunately, the security targets did not give a clear answer on the exact conditions for the power-on checks, so there is nothing I could state without violating our NDA. If you have access to the JCOP UGM, you might find something on that (though kept very generalized). – Orlop

Nevertheless, if those power-on tests fail, the reset triggered by "lock card session" will eventually lockdown the card in a boot-loop (or some more efficient lock-down). – Orlop

Answer 2

Here the picture from a native operating system: When writing a new value to non-volatile memory, the hardware routine does a check by itself, whether the value could be written correctly and returns an error status otherwise. This is translated to a SW1/SW2 of 65 81. The affected file or object is marked as corrupted, and future attempts to access it are cleanly rejected. If it is essential for the application, this will no longer be able to work.

If I remember correctly, our hardware (non-NXP) even issues a pre-warning, indicating, that while the value could be written correctly this time, the memory cell is about to reach its limits.

Bronchia