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/