smartcard - Symptoms of EEPROM damage -

suppose there bug in java card applet: temporary byte array stored in eeprom instead of ram. moreover, suppose byte array overwritten each apdu.

this bug should damage card sooner or later.

what symptoms expect? incorrect values in array without explicit warnings or errors? exceptions thrown when accessing array? applet unselectable? whole card unresponsive?

should card damaged "once , forever", or these failures occur more , more often?

in experiment (j2e145) there first failure after 5 000 000 apdus , symptom card did not send r-apdu @ , died. however, next apdu ok again, approximately 1 apdu out of 10000 failed (with increasing frequency) , after 5 100 000 apdus card stopped communicating forever.

is there standard says should happen in case of eeprom damage? (i looking it, did not find any.)

i know question broad , depends on particular chip (i interested in nxp chips), think comments, answers , experience many java card developers, found bug in code after deployment.

i guess best shot @ finding non-nda'd information common criteria security targets specific platforms.

an example hardware platform nxp: nxp secure smart card controllers p5cx128v0a/p5cx145v0a, mso (bsi-dsz-cc-0645)

• from toe overview:

  the non-volatile eeprom [...] contains high reliability cells, guarantee data integrity. [...] security functionality protects contents of memories.

• from security feature sf.opc:

  an exception forced [...] single fault injection detection circuitry. in case minor configuration option "inverse eeprom error correction" enabled [...] probability detect fault injection errors increases , error correction logic raises exception when detecting error.

• from security feature sf.phy:

  the eeprom able correct 1-bit error within each byte. [...] eeprom corrects errors automatically without user interaction [...]

so this hardware platform capable of detecting eeprom cell failures , can automatically correct 1-bit errors within each byte. other detected errors raise exception can handled software.

that's hardware platform (without os / jcre). let's see security target of jcop tells us. chose nxp j3a128 , j3a095 secure smart card controller rev. 3 (bsi-dsz-cc-0731).

• from security feature sf.audit:

  the following reactions toe based on indication of potential violation of tsp possible:

  • throw exception
  • terminate card (life cycle state: terminated)
  • reinitialize java card system (warm reset)
  • [...] eeprom able correct 1-bit error within each byte. [...] eeprom corrects errors automatically without user interaction [...]
  • lock card session (simply stops processing; escape reset session/card tearing)

  based on these types of response/reaction events listed above have following mapping:

  • eeprom failure audited through exceptions in read/write operations , 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 suite of self-tests during initial start-up (at each power on) demonstrate correct operation of tsf, verify integrity of tsf data, , verify integrity of stored tsf executable code. includes checking eeprom integrity. if error detected, toe enters 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 error occurs, tsf maintain secure state (lock card session)

so this software platform (again) capable of detecting eeprom cell failures , can automatically correct 1-bit errors within each byte. other detected eeprom errors "lock card session", means stops processing , performs reset. seems match observation "the symptom card did not send r-apdu @ , died".