沈超的个人博客

硬件工程师的实验笔记——原理图、PCB、FPGA、模拟前端、嵌入式固件

这里记录从原理图到量产的全过程。 成功的经验要记,翻车的教训更要记。 每篇都有原理图或波形佐证——不写空话。

最新文章 ↓ 关于本站

内容系列

主控

XCZU3EG:A53 应用域 + R5F 实时域 + PL 数据面

背板

CPCI-S 10 仪器槽,CAN-FD 控制面 + LVDS 数据面

仪器卡

示波器 / DMM / 桥路 / 信号源 / 功率计 + 扩展谱系

方法论

结论必须板上验证,翻车也照实写

最新文章

阅读 137
嵌入式固件

起因:一个假密钥活了三周

2026 年 7 月中旬,Keel 框架的 bootloader 加密功能刚做完。我跑通了 ECDSA-P256 签名验证、AES-128-CTR 加密封装、HMAC-SHA256 完整性校验——三条链路全部自测绿灯。

然后我做了一件"以后再做的事":用了一个默认密钥

具体来说,签名验证的公钥就是 secp256r1 曲线的生成点 G。对应的私钥是 1。对,就是数字 1。

这不是偷懒。bootloader 的 OTP(One-Time Programmable)烧录流程还没打通,产品板也没到手。我需要一个"能跑通全链路但明显不安全"的占位符,等硬件就绪再换。

问题是:这个占位符活了三周

三周里,我写了文档、跑了测试、做了评审。所有人都看到了代码里的 #warning "using default dev key",但没人觉得这是紧急事项。毕竟——"反正没人会攻击我们的开发板"。

直到有一天,我在写 OTA 升级文档时突然意识到:如果有人拿到固件包,用私钥=1 签一个恶意镜像,bootloader 会欣然接受并烧进去。签名验证从"安全门"变成了"摆设"。

那天晚上,我加了五层防御。

阅读剩余部分