EEPROM损坏的症状
Symptoms of EEPROM damage
假设 Java 卡小程序中存在错误：临时字节数组存储在 EEPROM 而不是 RAM 中。此外，假设这个字节数组被每个 APDU 覆盖。
这个错误迟早会损坏卡。
我们可能会出现什么症状？数组中的值不正确而没有任何明确的警告或错误？访问这个数组时抛出一些异常？小程序无法选择？整卡完全没反应？
卡应该损坏了"once and forever"，还是这些故障会越来越频繁？
在我的实验 (J2E145) 中，在 5 000 000 个 APDU 之后出现了第一次故障，其症状是卡根本没有发送 R-APDU 而只是挂掉了。然而，下一个 APDU 再次正常，然后大约 10000 个 APDU 中有 1 个失败（频率增加），最后在 5 100 000 个 APDU 之后，卡永远停止通信。
是否有任何标准规定在EEPROM损坏的情况下应该发生什么？ （我一直在找它，但我没有找到。）
我知道这个问题很广泛，可能取决于特定的芯片（我对 NXP 芯片特别感兴趣），但我认为您的评论、答案和经验可以帮助许多 Java 卡开发人员，他们部署后在他们的代码中发现了一个错误。
这里是native操作系统的图片：当向非易失性存储器写入新值时，硬件例程会自行检查是否可以写入该值正确并且 returns 否则为错误状态。这被转换为 SW1/SW2 of 65 81。受影响的文件或对象被标记为已损坏，并且以后访问它的尝试被完全拒绝。如果对应用来说是必不可少的，这个就不行了。
如果我没记错的话，我们的硬件（非NXP）甚至发出了预警，表明虽然这次可以正确写入值，但内存单元即将达到其限制。
我想找到一些非 NDA 信息的最佳方法是针对特定平台的通用标准安全目标。
NXP 硬件平台示例：NXP Secure Smart Card Controllers P5Cx128V0A/P5Cx145V0A, MSO (BSI-DSZ-CC-0645)
来自 TOE 概述：
The non-volatile EEPROM [...] contains high reliability cells, which guarantee data integrity. [...] Security functionality protects the contents of all memories.
来自安全功能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.
来自安全功能SF.PHY:
The EEPROM is able to correct a 1-bit error within each byte. [...] The EEPROM corrects errors automatically without user interaction [...]
所以这个硬件平台能够检测EEPROM单元故障，甚至可以自动纠正每个字节中的1位错误。对于所有其他检测到的错误，它将引发可由软件处理的异常。
那是针对硬件平台的（没有 OS / JCRE）。那么让我们看看 JCOP 的安全目标告诉我们什么。我选择了NXP J3A128 and J3A095 Secure Smart Card Controller Rev. 3 (BSI-DSZ-CC-0731).
来自安全功能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
来自安全功能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)
所以这个 软件平台（再次）能够检测 EEPROM 单元故障，甚至可以自动纠正每个字节中的 1 位错误。对于所有其他 检测到 EEPROM 错误，它将 "lock the card session"，这意味着它只是停止处理并执行重置。这似乎与您的观察相符“症状是卡根本没有发送 R-APDU 就死了”。
假设 Java 卡小程序中存在错误：临时字节数组存储在 EEPROM 而不是 RAM 中。此外，假设这个字节数组被每个 APDU 覆盖。
这个错误迟早会损坏卡。
我们可能会出现什么症状？数组中的值不正确而没有任何明确的警告或错误？访问这个数组时抛出一些异常？小程序无法选择？整卡完全没反应？
卡应该损坏了"once and forever"，还是这些故障会越来越频繁？
在我的实验 (J2E145) 中，在 5 000 000 个 APDU 之后出现了第一次故障，其症状是卡根本没有发送 R-APDU 而只是挂掉了。然而，下一个 APDU 再次正常，然后大约 10000 个 APDU 中有 1 个失败（频率增加），最后在 5 100 000 个 APDU 之后，卡永远停止通信。
是否有任何标准规定在EEPROM损坏的情况下应该发生什么？ （我一直在找它，但我没有找到。）
我知道这个问题很广泛，可能取决于特定的芯片（我对 NXP 芯片特别感兴趣），但我认为您的评论、答案和经验可以帮助许多 Java 卡开发人员，他们部署后在他们的代码中发现了一个错误。
这里是native操作系统的图片：当向非易失性存储器写入新值时，硬件例程会自行检查是否可以写入该值正确并且 returns 否则为错误状态。这被转换为 SW1/SW2 of 65 81。受影响的文件或对象被标记为已损坏，并且以后访问它的尝试被完全拒绝。如果对应用来说是必不可少的，这个就不行了。
如果我没记错的话，我们的硬件（非NXP）甚至发出了预警，表明虽然这次可以正确写入值，但内存单元即将达到其限制。
我想找到一些非 NDA 信息的最佳方法是针对特定平台的通用标准安全目标。
NXP 硬件平台示例：NXP Secure Smart Card Controllers P5Cx128V0A/P5Cx145V0A, MSO (BSI-DSZ-CC-0645)
来自 TOE 概述：
The non-volatile EEPROM [...] contains high reliability cells, which guarantee data integrity. [...] Security functionality protects the contents of all memories.
来自安全功能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.
来自安全功能SF.PHY:
The EEPROM is able to correct a 1-bit error within each byte. [...] The EEPROM corrects errors automatically without user interaction [...]
所以这个硬件平台能够检测EEPROM单元故障，甚至可以自动纠正每个字节中的1位错误。对于所有其他检测到的错误，它将引发可由软件处理的异常。
那是针对硬件平台的（没有 OS / JCRE）。那么让我们看看 JCOP 的安全目标告诉我们什么。我选择了NXP J3A128 and J3A095 Secure Smart Card Controller Rev. 3 (BSI-DSZ-CC-0731).
来自安全功能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
来自安全功能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)
所以这个 软件平台（再次）能够检测 EEPROM 单元故障，甚至可以自动纠正每个字节中的 1 位错误。对于所有其他 检测到 EEPROM 错误，它将 "lock the card session"，这意味着它只是停止处理并执行重置。这似乎与您的观察相符“症状是卡根本没有发送 R-APDU 就死了”。