北京
你的设备还在用RSA签固件？NIST新标准已经落地，OpenSSL 3.5内置了ML-KEM和ML-DSA。对于要在野外跑10到20年的嵌入式产品，这不是"以后再说"的安全补丁，而是现在就要决定的架构选择。
后量子加密（PQC）正在从论文走进产线。欧洲路线图推动协调过渡，芯片厂商已经把PQC塞进MCU工作流。但嵌入式团队面临一个特殊困境：加密决策比想象中冻结得更早——引导加载程序验证逻辑、固件镜像格式、OTA包签名、设备证书、生产PKI、安全元件、TLS库、回滚策略，一旦部署，改动成本极高，有时甚至不可能。
真正的价值不是一夜之间替换RSA和ECC，而是在产品变得僵化之前引入加密敏捷性。
嵌入式团队需要熟悉的两个名字：ML-KEM和ML-DSA。ML-KEM是密钥封装机制，用于建立共享密钥，跟TLS关系最密切。ML-DSA是数字签名方案，涉及安全启动、固件签名、包签名、证书和设备身份。对Linux网关来说，ML-KEM通常是第一切入点，因为TLS栈比不可变的启动链更容易测试和升级。对固件和启动流程，ML-DSA更相关，但需要更谨慎的工程——签名大小、验证时间、镜像布局、清单格式，样样都要抠。
实际迁移路径建议分步走：先清点产品里所有加密依赖，把TLS、VPN、安全启动、OTA、包签名、证书和PKI都列出来；找出制造后无法更新的代码路径；用OpenSSL 3.5或Open Quantum Safe等工具在Linux网关上跑试点；在真实硬件上测量ML-KEM和ML-DSA的性能影响；检查镜像格式、清单、回滚和恢复路径；制定信任锚轮换和加密敏捷性策略；最后只把经过验证的部分推进生产。
一份自检清单供参考：预期 field 寿命是否确认？不可更新的签名验证器是否识别？TLS或VPN用途是否梳理？证书和PKI是否盘点？安全启动流程是否复核？OTA清单和签名格式是否检查？回滚和恢复路径是否验证？混合过渡需求是否评估？
后量子加密不是未来的事，是现在的架构决策。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
