Smartcard EEPROM损坏的症状

假设Java卡小程序中有一个bug：临时字节数组存储在EEPROM中，而不是RAM中。此外，假设该字节数组被每个APDU覆盖

此错误迟早会损坏卡

我们能预料到什么症状？数组中的值不正确，没有任何明确的警告或错误？访问此阵列时引发了一些异常？小程序不可选择？整个卡完全没有反应

卡是否应该“一次性”损坏，或者这些故障是否会越来越频繁

在我的实验（J2E145）中，5000 000次APDU后出现了第一次故障，症状是卡根本没有发送R-APDU，只是死掉了。但是，下一个APDU再次正常，然后10000个APDU中约有1个出现故障（频率增加），最后在5个100000个APDU之后，卡永远停止通信

是否有任何标准规定了EEPROM损坏时应采取的措施？（我在找，但没有找到。）

---

我知道这个问题很广泛，可能取决于特定的芯片（我对NXP芯片特别感兴趣），但我认为你的评论、答案和经验可以帮助很多Java卡开发人员，谁在部署后发现了代码中的错误。

这里是来自本机操作系统的图片：当向非易失性内存写入新值时，硬件例程自行检查该值是否可以正确写入，否则返回错误状态。这将转换为65 81的SW1/SW2。受影响的文件或对象被标记为已损坏，以后访问该文件或对象的尝试将被彻底拒绝。如果它对于应用程序是必需的，那么它将不再能够工作

---

如果我没记错的话，我们的硬件（非NXP）甚至会发出一个预警，表明虽然这次可以正确写入值，但内存单元即将达到极限。

我想找到一些非保密信息的最佳途径是特定平台的通用标准安全目标

NXP的硬件平台示例：

• 从脚趾概述：
  非易失性EEPROM[…]包含高可靠性单元，保证数据完整性。[…]安全功能保护所有存储器的内容

• 从安全功能SF.OPC：
  异常由[…]单一故障注入检测电路强制执行。如果启用了次要配置选项“反向EEPROM错误校正”[…]，则检测故障注入错误的概率增加，并且在检测错误时，错误校正逻辑会引发异常

• 从安全功能SF.PHY：
  EEPROM能够纠正每个字节内的1位错误。[…]EEPROM自动纠正错误，无需用户交互[…]

因此，该硬件平台能够检测EEPROM单元故障，甚至可以自动纠正每个字节内的1位错误。对于所有其他检测到的错误，它将引发可由软件处理的异常

这是针对硬件平台的（没有OS/JCRE）。让我们看看JCOP的安全目标告诉我们什么。我选择了

• 从安全功能SF.Audit：
  根据可能违反TSP的指示，脚趾可能会做出以下反应：
  • 抛出异常
  • 终止卡（生命周期状态：已终止）
  • 重新初始化Java卡系统（热复位）
  • […]EEPROM能够纠正每个字节内的1位错误。[…]EEPROM自动纠正错误，无需用户交互[…]
  • 锁定卡会话（只需停止处理；通过重置会话/撕卡退出）
  根据这些类型的响应/反应，上述事件将具有以下映射：
  • 通过读/写操作和一致性/完整性检查中的异常审计EEPROM故障：锁定卡会话
  • 启动时的自检机制：锁定卡会话
  • 检查汇总对象损坏：锁定卡会话
• 从安全功能SF.SecureManagement：
  TSF在初始启动期间（每次通电时）运行一套自检，以演示TSF的正确操作，验证TSF数据的完整性，以及验证存储的TSF可执行代码的完整性。这包括检查EEPROM的完整性。如果检测到错误，前束进入安全状态（锁定卡会话）
  TSF监控用户数据D.APP_代码、D.APP_I_数据、D.PIN、D.APP_键的完整性错误。如果发生错误，TSF将保持安全状态（锁定卡会话）

---

因此，该软件平台（再次）能够检测EEPROM单元故障，甚至可以自动纠正每个字节内的1位错误。对于所有其他检测到的EEPROM错误，它将“锁定卡会话”，这意味着它只是停止处理并执行重置。这似乎与您的观察结果相符“症状是卡根本没有发送R-APDU，只是死了。”

非常感谢您的研究，出色的工作！TSF在初始启动期间（每次通电时）运行一套自检。。。如果检测到错误，TOE将进入安全状态（锁定卡会话）-这意味着整个卡已损坏，其所有小程序及其数据都将丢失，对吗？不客气。在我的待办事项清单上，查阅那些文件以找到一个可公开引用的参考资料已经有很长一段时间了，你的问题让我有理由再次深入研究。不幸的是，安全目标没有给出明确的答案