Shawn the R0ck 写道： 私钥一直是安全保护的核心目标。由于密钥槽的限制，大多数加密货币硬件钱包使用 MCU 芯片（如 STM32F205RE）进行实现，以便能使用secure element存储和支持更广泛的加密货币种类，然而，那些对保护私钥有更高安全要求的人通常会对 Java 卡感兴趣，因为Java Card基本上是具有加密算法硬件实现的智能卡。私钥或对称密钥无法从中提取。用户只能从 Java 卡获得加密操作的结果，另外一点是已经使用通信参数初始化但尚未加载应用程序（applet）的 Java 卡是可由用户编程的，而且有一些以 Java 卡 applet 形式实现的各种功能的自由开源软件项目。即使Java Card作为HSM（硬件安全模块）的安全性高于常见加密货币硬件钱包的实现，但依然有安全风险，HardenedVault介绍了两个典型的漏洞，这些漏洞位于更底层的JCRE（Java Card运行时环境），虽然不会导致私钥被泄露，但会导致应用程序陷入无法恢复的错误。一旦出现这种问题，卡中的私钥就可能会丢失。智能卡作为 HSM 的实现比基于 MCU 的解决方案（几乎所有硬件钱包都采用了这种方案）更加安全，但仍存在某些安全风险。甚至获得 EAL 5+ 认证的硬件钱包也有被攻击的记录。因此，在系统安全方面，我们仍需要坚持纵深防御的策略。另一方面，透明度很重要，开源是确保 HSM 的整个运行环境能够得到适当审计的唯一途径。对于 Java 卡，我们希望未来能够拥有一个自由开源且可更新的 JCRE。或者某种功能上类似于 Java 卡但可以用 C 语言编程的 HSM（对不起，我们不想使用 Rust，因为我们已经有了现代的缓解和检测器，Rust 对此来说有些生锈了，不是吗？），甚至可以直接使用通用计算（如可信计算、运行时保护、攻击面缩小等）实现。

https://hardenedvault.net/blog/2023-04-18-java-card-runtime-memory-corruption/