Symptoms of EEPROM Damage

Question

Suppose there is an error in the Java Card applet: a temporary array of bytes is stored in the EEPROM instead of RAM. Moreover, suppose this byte array is overwritten by each APDU.

This error should damage the card sooner or later.

What symptoms can we expect? Wrong values ​​in an array without any explicit warnings or errors? Some exceptions that occur when accessing this array? Applet is not a choice? Does the whole card not fully respond?

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

In my experiment (J2E145), the first failure occurred after 5,000,000 APDUs, and the symptom was that the card did not send R-APDUs at all and just died. However, the next APDU was again in order, then about 1 APDU out of 10,000 with an error (with increasing frequency), and finally, after 5,100,000 APDUs, the card stopped communicating forever.

Is there any standard that says what should happen if an EEPROM is damaged? (I was looking for him, but I did not find him.)

I know that the question is wide and probably depends on the specific chip (I am particularly interested in NXP chips), but I think that your comments, answers and experience can help many Java card developers who found an error in their code after deployment.

Answer 1

I think the best snapshot of finding some information other than NDA'd is Common Criteria's security goals for specific platforms.

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

• From the OO review:

  The non-volatile EEPROM [...] contains highly reliable cells that guarantee data integrity. [...] Security features protect the contents of all memories.

• From the security function SF.OPC:

  An exception is forcibly carried out using a single fault detection circuit [...]. If the option “EEPROM Error Correction” [...] is additionally enabled, the probability of detecting injection errors is increased, and the error correction logic will throw an exception when an error is detected.

• From the SF.PHY security function:

  EEPROM can correct a 1-bit error in each byte. [...] EEPROM fixes errors automatically without user intervention [...]

Thus, this hardware platform is capable of detecting EEPROM cell errors and can even automatically correct 1-bit errors in each byte. An exception will be thrown for all other errors that can be handled by the software.

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

• From the SF.Audit security function:

  The following OO reactions are possible, based on an indication of a potential TSP violation:

  • Throw an exception
  • Shut down the map (life cycle state: TERMINATED)
  • Re-initialize the Java Card system (warm reset)
  • [...] EEPROM is able to correct a 1-bit error in each byte. [...] EEPROM fixes errors automatically without user interaction [...]
  • Lock card session (just stops processing, exit with reset session / card break)

  Based on these types of responses / reactions, the events listed above will have the following display:

  • EEPROM Crash Checked by Exceptions in Read / Write and Integrity / Integrity Checks: Card Lock Session
  • startup self-test mechanism: card blocking session
  • Corruption of objects with a check summation: Block a map session

• From the SF.SecureManagement security function:

  The TSF runs a self-test kit at the first start (each time it is turned on) to demonstrate the correct operation of the TSF, verify the integrity of the TSF data, and verify the integrity of the TSF executable code. This includes an EEPROM integrity check . If an error is detected, the TOE enters a safe state ( card lock session )

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

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

Answer 2

Here is the image from the native operating system: when writing a new value to non-volatile memory, the hardware procedure itself checks whether this value can be written correctly and returns a status error otherwise. This translates to SW1 / SW2 of 65 81. The infected file or object is marked as damaged, and future attempts to access it are cleared. If it is necessary for the application, it will no longer be able to work.

If I remember correctly, our equipment (non-NXP) even issues a preliminary warning, indicating that as long as the value can be written correctly this time, the memory cell will soon reach its limits.