为什么嵌入式工程师都该懂一点安全？¶

说一个很多人都经历过的场景¶

项目快交付了。

功能测试通过，压力测试也跑完了，客户那边催得很紧。

这时候有人提了一句："安全这块怎么样？"

会议室安静了两秒。

然后项目经理说："安全下个版本再做，先出货。"

所有人点头，继续往下走。

这个场景，我相信很多做嵌入式的工程师都不陌生。

问题是——下个版本，往往没有机会再补。

嵌入式工程师为什么觉得安全"跟我没关系"¶

做嵌入式这行，大多数人的日常是：调驱动、啃数据手册、跟硬件工程师对接、解奇奇怪怪的 bug。

安全，听起来是另一个部门的事。是做后台的人、做渗透测试的人才需要操心的事。

但现实是：

嵌入式设备才是整个系统里最容易被忽视、也最容易被攻击的环节。

它直接跟硬件打交道，跑的是你自己编译的固件，网络通信自己处理，升级流程自己控制。没有操作系统帮你兜底，没有云平台帮你挡攻击。

出了问题，是你的代码，是你的设计。

嵌入式安全，保护的是什么？¶

在讲具体技术之前，先想清楚一件事：

我们在保护什么？防的是谁？

威胁大概分三类：

物理攻击 — 攻击者拿到设备，拆开，把存储芯片焊下来读取固件，提取密钥、源码、敏感数据。车载设备、工控机、医疗设备都是高价值目标。

网络攻击 — 设备联网，攻击者拦截通信、篡改数据包、伪装成服务器发送恶意指令。

固件攻击 — 攻击者想办法把一个假固件刷进去，设备从此听他的话，而不是你的。

针对这三类威胁，嵌入式安全有四道防线：

Secure Boot → 存储加密 → 加密通信 → OTA 签名验证

第一道防线：Secure Boot，从开机第一秒建立信任¶

没有它会怎样？¶

设备上电，Bootloader 加载内核，系统启动。

整个过程没有任何人检查这些代码是否合法。攻击者只需要把修改过的固件刷进去，设备正常启动，但里面跑的已经是他的代码了。

信任链是核心¶

Secure Boot 的本质是信任链（Chain of Trust）：

芯片内部 ROM（出厂固化，不可修改）
        ↓ 验证签名
    Bootloader（厂商签名）
        ↓ 验证签名
    Linux Kernel（厂商签名）
        ↓ 验证签名
    Root Filesystem（厂商签名）

每一层启动前都验证下一层的数字签名。签名私钥只有你有，公钥烧进芯片 eFuse，烧了改不了。任何环节被篡改，验证失败，拒绝启动。

实际落地要注意¶

私钥保管是命根子 — 私钥泄漏，整套机制形同虚设。建议用 HSM 硬件安全模块管理
做回滚保护 — 防止攻击者把固件降级到有漏洞的旧版本
开发阶段别烧死 eFuse — eFuse 一旦烧录不可逆，测试阶段先用可撤销方式验证

第二道防线：存储加密，拆机也读不出东西¶

物理攻击有多简单？¶

有经验的攻击者，拿到一块板子，十分钟可以把存储芯片焊下来，用编程器读出全部内容。固件、密钥、配置、用户数据，一览无余。

存储加密的目标就是：就算芯片被拆走，读出来的也是一堆密文。

怎么实现？¶

主流方案是在芯片内部安全区域生成随机密钥，数据写入存储时自动加密，读出时自动解密。密钥从不离开芯片。

攻击者拿走存储芯片，没有对应的芯片配合，解不开。

坑在哪里¶

调试变复杂 — 加密开启后 JTAG 调试和日志输出可能受限，建议功能验证完成后量产前再开启

密钥不可导出是特性不是 bug — 这意味着你必须留好原始固件，生产流程要设计好，否则维修和返厂会很麻烦

第三道防线：加密通信，网络上的对话不被偷听¶

明文通信有多危险？¶

如果设备用 HTTP 跟服务器通信，同一网络里任何人开个抓包工具，就能看到全部内容。

更危险的是中间人攻击 — 攻击者伪装成服务器，把假的指令发给你的设备，设备照单全收。工控设备、医疗设备如果遭遇这种攻击，后果不堪设想。

TLS 做了两件事¶

加密 — 通信内容加密，第三方看不懂

身份验证 — 设备验证服务器证书，确认对方是真实服务器

嵌入式常用 Mbed TLS（轻量，适合资源受限场景）或 OpenSSL（功能完整）。

更高要求：双向认证¶

普通 TLS 只有设备验证服务器。双向认证（mTLS） 让服务器也验证设备身份，确认只有合法设备才能接入。工业控制、车载、医疗这类场景基本都要求双向认证。

最常见的错误¶

// 开发图方便关掉验证，量产忘了开回来
// 这等于 TLS 完全没用
mbedtls_ssl_conf_authmode(&conf, MBEDTLS_SSL_VERIFY_NONE);

这一行代码，毁掉整套加密通信。我见过不止一个项目这样出货。

第四道防线：OTA 签名验证，升级不变成攻击入口¶

OTA 是最危险的入口¶

远程升级是现代嵌入式产品的标配。

但它同时也是最高危的攻击面 — 如果攻击者能推一个假固件进来，整个设备就是他的了。

完整的安全 OTA 流程¶

开发者用私钥对固件签名
        ↓
固件包（含签名）上传服务器
        ↓
设备通过加密通道下载
        ↓
用内置公钥验证签名
        ↓
验证通过 → 写入存储 → 重启
验证失败 → 丢弃，保持原固件不变

私钥只在你手上，攻击者伪造的固件签名验证必然失败。

A/B 分区防变砖¶

升级最怕中途断电，设备变砖。

A/B 分区方案让升级有退路：

正在运行：A 分区
         ↓
下载新固件 → 写入 B 分区
         ↓
验证签名通过 → 重启从 B 启动
         ↓
启动成功 → B 成为当前分区
启动失败 → 自动回滚 A 分区

设备永远有一个可以回滚的备份，升级失败也能自救。

四道防线，是一个整体¶

威胁类型              对应防线
──────────────────────────────────
刷入恶意固件    →    Secure Boot
拆机读取数据    →    存储加密
窃听篡改通信    →    TLS 加密通信
伪造 OTA 包     →    签名验证

这四道防线不是独立的，而是环环相扣：

Secure Boot 保护 OTA 客户端本身不被替换
存储加密保护设备内的私钥不被提取
TLS 保护 OTA 固件下载的通道不被劫持

任何一环缺失，整条链都可能从最薄弱的地方断掉。

为什么是嵌入式工程师的责任？¶

因为这些事，没有人能替你做。

上层应用有框架保护，云端有安全团队，但嵌入式这一层，启动流程是你写的，通信代码是你写的，OTA 逻辑是你写的。

安全不是加密算法，不是密码学理论。

它是你设计系统时，每一个环节都多问自己一句：这里如果被攻击，会怎样？

养成这个习惯，比学任何工具都重要。

你现在负责的项目里，这四道防线做了几道？欢迎评论区说说，我们交流一下 👇