EEPROM损坏的症状答案

【问题标题】：Symptoms of EEPROM damageEEPROM损坏的症状
【发布时间】：2015-08-18 15:08:01
【问题描述】：

假设 Java Card 小程序中存在错误：临时字节数组存储在 EEPROM 而不是 RAM 中。此外，假设这个字节数组被每个 APDU 覆盖。

这个错误迟早会损坏卡。

我们可以期待什么症状？没有任何明确警告或错误的数组中的值不正确？访问这个数组时抛出了一些异常？小程序无法选择？整张卡完全没有反应？

卡应该“一劳永逸”地损坏，还是这些故障会越来越频繁地发生？

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

是否有任何标准说明 EEPROM 损坏时应该如何处理？（我一直在寻找它，但我没有找到。）

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

【问题讨论】：

【解决方案1】：

我想找到一些非 NDA 信息的最佳方法是特定平台的通用标准安全目标。

来自 TOE 概述：

非易失性 EEPROM [...] 包含高可靠性单元，可确保数据完整性。 [...] 安全功能保护所有记忆的内容。
来自安全功能 SF.OPC：

[...] 单个故障注入检测电路强制执行异常。如果启用了次要配置选项“反向 EEPROM 纠错”[...]，检测到故障注入错误的可能性会增加，并且纠错逻辑会在检测到错误时引发异常。
来自安全功能 SF.PHY：

EEPROM 能够纠正每个字节内的 1 位错误。 [...] EEPROM 自动纠正错误，无需用户交互 [...]

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

这是针对硬件平台的（没有 OS / JCRE）。那么让我们看看 JCOP 的安全目标告诉我们什么。我选择了NXP J3A128 and J3A095 Secure Smart Card Controller Rev. 3 (BSI-DSZ-CC-0731)。

来自安全功能 SF.Audit：
TOE 可能会根据潜在违反 TSP 的指示做出以下反应：
- 抛出异常
- 终止卡（生命周期状态：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_KEYs 完整性错误。如果发生错误，TSF 保持安全状态（锁定卡会话）

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

【讨论】：

非常感谢您的研究，出色的工作！ TSF 在初始启动期间（每次开机时）运行一系列自检...如果检测到错误，TOE 进入安全状态（锁定卡会话） - 这意味着整张卡都坏了，所有的小程序和它们的数据都丢失了，对吧？
不客气。浏览这些文档以找到可公开引用的参考文献在我的待办事项列表上已经有很长一段时间了，而您的问题让我们有理由最终再次深入研究。
不幸的是，安全目标并没有就开机检查的确切条件给出明确的答案，所以我不能在不违反我们的 NDA 的情况下说明任何事情。如果您可以访问 JCOP UGM，您可能会在上面找到一些东西（尽管非常笼统）。
尽管如此，如果这些开机测试失败，由“锁定卡会话”触发的重置最终将在引导循环中锁定卡（或更有效的锁定）。

【解决方案2】：

这是来自原生操作系统的图片：当向非易失性存储器写入新值时，硬件例程会自行检查该值是否可以正确写入并返回错误否则状态。这被转换为 65 81 的 SW1/SW2。受影响的文件或对象被标记为损坏，并且将来访问它的尝试被完全拒绝。如果它对应用程序至关重要，这将不再起作用。

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

【讨论】：