假设 Java Card 小程序中存在错误：临时字节数组存储在 EEPROM 而不是 RAM 中。此外，假设这个字节数组被每个 APDU 覆盖。
这个错误迟早会损坏卡。
我们可以期待什么症状？没有任何明确警告或错误的数组中的值不正确？访问这个数组时抛出了一些异常？小程序无法选择？整张卡完全没有反应？
卡应该“一劳永逸”地损坏，还是这些故障会越来越频繁地发生？
在我的实验（J2E145）中，在 5 000 000 个 APDU 之后出现了第一次故障，症状是卡根本没有发送 R-APDU 并且就死了。然而，下一个 APDU 再次正常，然后大约 10000 个 APDU 失败（频率增加），最后在 5 100 000 个 APDU 之后，卡永远停止通信。
是否有任何标准说明在 EEPROM 损坏的情况下会发生什么？（我正在寻找它，但我没有找到任何东西。）
我知道这个问题很广泛，它可能取决于特定的芯片（我对 NXP 芯片特别感兴趣），但我认为您的评论、答案和经验可以帮助许多 Java Card 开发人员，他们在部署后发现他们的代码中存在错误。
这里是本地操作系统的图片：当向非易失性存储器写入新值时，硬件例程会自行检查该值是否可以正确写入，否则返回错误状态。这被转换为 65 81 的 SW1/SW2。受影响的文件或对象被标记为损坏，并且将来访问它的尝试被完全拒绝。如果它对应用程序至关重要，这将不再起作用。
如果我没记错的话，我们的硬件（非 NXP）甚至会发出预警，表明虽然这次可以正确写入值，但存储单元即将达到其极限。
我想找到一些非 NDA 信息的最佳方法是特定平台的通用标准安全目标。
恩智浦硬件平台示例：恩智浦安全智能卡控制器 P5Cx128V0A/P5Cx145V0A、MSO (BSI-DSZ-CC-0645)
从 TOE 概述：
非易失性 EEPROM [...] 包含高可靠性单元，可保证数据完整性。[...] 安全功能保护所有内存的内容。
从安全功能 SF.OPC：
[...] 单个故障注入检测电路强制执行异常。如果启用了次要配置选项“Inverse EEPROM Error Correction”[...]，检测到故障注入错误的可能性会增加，并且在检测到错误时，纠错逻辑会引发异常。
来自安全功能 SF.PHY：
EEPROM 能够纠正每个字节内的 1 位错误。[...] EEPROM 自动纠正错误，无需用户交互 [...]
因此，该硬件平台能够检测 EEPROM 单元故障，甚至可以自动纠正每个字节内的 1 位错误。对于所有其他检测到的错误，它将引发可由软件处理的异常。
那是针对硬件平台的（没有 OS / JCRE）。那么让我们看看 JCOP 的安全目标告诉我们什么。我选择了NXP J3A128 和 J3A095 安全智能卡控制器 Rev. 3 (BSI-DSZ-CC-0731)。
来自安全功能 SF.Audit：
基于潜在违反 TSP 的指示，TOE 可能会做出以下反应：
- 抛出异常
- 终止卡（生命周期状态：TERMINATED）
- 重新初始化 Java Card 系统（热复位）
- [...] EEPROM 能够纠正每个字节内的 1 位错误。[...] EEPROM 自动纠正错误，无需用户交互 [...]
- 锁定卡片会话（只需停止处理；通过重置会话/卡片撕裂逃脱）
基于这些类型的响应/反应，上面列出的事件将具有以下映射：
- 通过读/写操作和一致性/完整性检查中的异常审计 EEPROM 故障：锁定卡会话
- 开机自检机制：锁卡会话
- 校验和对象损坏：锁定卡会话
从安全功能 SF.SecureManagement：
TSF 在初始启动期间（每次上电）运行一套自检，以证明 TSF 的正确操作、验证 TSF 数据的完整性以及验证存储的 TSF 可执行代码的完整性。这包括检查 EEPROM 的完整性。如果检测到错误，则 TOE 进入安全状态（锁卡会话）
TSF 监控用户数据 D.APP_CODE、D.APP_I_DATA、D.PIN、D.APP_KEY的完整性错误。如果发生错误，TSF保持安全状态（锁定卡会话）
因此，该软件平台（再次）能够检测 EEPROM 单元故障，甚至可以自动纠正每个字节内的 1 位错误。对于所有其他检测到的 EEPROM 错误，它将“锁定卡会话”，这意味着它只是停止处理并执行重置。这似乎与您的观察相符“症状是该卡根本没有发送 R-APDU 而只是死了”。