npm audit 无法拯救你：我们为何转向 TEEs（Trusted Execution Environments）

Source: Dev.to

作为开发者，我们对代码质量极度执着。我们运行 linter，进行静态分析，并修补依赖。但在数字资产托管的世界里，即使是完美的代码在被攻破的硬件上运行仍然是一个漏洞。

标准 Linux 实例的问题

如果你的私钥管理服务运行在标准的 Linux 实例上，你就完全受制于操作系统内核。根套件、hypervisor 的零日漏洞，或拥有 sudo 权限的恶意管理员都可以转储内存并提取密钥。如果密钥必须在 RAM 中解密以签名交易，那么静态加密毫无意义。

向 Enclave（安全区）转变

这就是我们强制使用可信执行环境（TEE），例如 Intel SGX 或 AWS Nitro Enclaves 的原因。TEE 在 CPU 内部充当一个“黑盒”，将签名逻辑和密钥碎片与系统的其他部分隔离。即使是操作系统也无法窥视内部，甚至安全顾问也无法通过 SSH 进入并读取内存。

实现细节

隔离

签名服务运行在 enclave（安全区）内部。

证明（Attestation）

在 enclave 接收密钥碎片之前，它必须通过加密方式（远程证明）证明自己正在运行正确、未被篡改的二进制文件。

短暂执行

密钥通过多方计算（MPC）重建后签名交易，并在完成后消失——全部在 CPU 的加密内存空间中进行。

我们必须停止像构建社交网络那样构建金融应用。风险截然不同。如果你在构建托管解决方案，请将信任锚从管理员转移到硅芯片。

https://www.sqhwyd.net/