过去很多 MCU 产品是单机设备,攻击面有限,工程团队更关注功能、实时性、成本和可靠性。随着设备逐步接入网络、云平台、手机 App、产线系统和第三方配件,嵌入式系统已经从“单板软件”变成“设备生态系统”的一部分。安全问题也从可选项,变成了架构设计的基本要求。
|
关键词 |
工程含义 |
|---|---|
|
威胁模型 / 全生命周期 |
安全应从产品立项阶段进入架构设计,是出问题后再补丁式修复。 |
1. 安全风险的变化
传统嵌入式设备常见风险主要包括:
- 死机;
- 误动作;
- 通信异常;
- 电磁干扰;
- 现场环境导致的偶发故障。
这些问题更多属于可靠性问题,工程团队通常通过看门狗、异常恢复、通信校验、滤波、冗余检测和可靠性测试来解决。
但是,当设备接入网络、云平台、手机 App、产线系统和第三方配件之后,风险边界发生了明显变化。
此时,设备面对的不再只是自然环境和偶发异常,还包括人为攻击。风险也从单纯的可靠性问题,扩展为安全问题,例如:
- 远程攻击;
- 身份伪造;
- 固件篡改;
- 密钥泄露;
- 克隆生产;
- 供应链攻击。
攻击者不一定需要拆机。只要能够通过通信接口、调试接口、升级包、外部总线或网络入口影响设备,就可能造成系统级后果。
2. 典型攻击场景
在实际产品中,常见攻击场景包括:
2.1 仿冒合法设备接入系统
攻击者伪造一个“看起来合法”的设备,接入主机、云平台或产线系统。
如果系统只检查设备 ID,而没有真正的身份认证机制,那么设备 ID 一旦被复制,就可能被仿冒。
2.2 复制固件生产克隆机
如果 MCU Flash 中的固件没有读保护,或者固件与硬件之间没有绑定关系,攻击者可能直接读取固件并复制到其他硬件上。
这会导致山寨设备、克隆设备和非法生产问题。
2.3 篡改升级包植入恶意代码
如果 OTA 或本地升级包没有签名校验,攻击者可以修改升级包内容,植入恶意代码。
设备一旦执行被篡改的固件,就可能出现异常控制、数据泄露或被远程接管等问题。
2.4 重放历史通信数据骗过主机
攻击者截获一次合法通信数据后,后续重复发送同样的数据包。
如果协议中没有随机数、计数器、时间戳或挑战响应机制,主机可能误认为这是一次新的合法操作。
2.5 提取 MCU Flash 中的密钥
如果密钥直接明文存储在 MCU Flash、EEPROM 或外部 Flash 中,一旦调试口、烧录口或存储器被读取,密钥就可能泄露。
密钥泄露之后,通信加密、设备认证、耗材认证等机制都会失效。
2.6 破解耗材认证机制
在医疗、工业、打印、检测仪器等场景中,主机经常需要识别耗材、探头、模块或传感器是否合法。
如果认证方式只是固定 ID、简单校验码或明文参数,很容易被复制和仿冒。
2.7 伪造传感器数据或控制命令
攻击者可以伪造传感器数据,让系统误判现场状态;也可以伪造控制命令,让设备执行错误动作。
对于医疗、工业、能源和物联网设备,这类风险可能直接影响人身安全、合规性和品牌信誉。
3. 工程上的安全目标
嵌入式安全的目标不是单纯“把数据加密”。
真正的目标是建立三条可信链路:
- 可信身份:设备必须证明自己是谁;
- 可信代码:固件必须证明没有被篡改;
- 可信数据链路:通信数据必须证明来自合法对象,并且没有被修改。
只有这些基础建立起来,加密通信才有实际意义。
4. 从工程角度理解安全设计
很多工程团队一开始容易把安全理解为:
加一个 AES 加密;
加一个 CRC 校验;
通信数据不要明文传输。
这些措施有一定作用,但它们并不等同于完整的安全架构。
例如:
- CRC 只能发现随机错误,不能防止恶意篡改;
- AES 只能保护数据内容,但不能自动证明对方身份;
- 固件加密只能防止直接查看内容,但不能替代签名校验;
- 设备 ID 只能用于标识设备,不能证明设备一定是真的;
- 密钥如果存储不安全,加密算法再强也没有意义。
因此,嵌入式安全设计必须从系统架构层面考虑,而不是只在通信协议里加几个加密字段。
5. 落地建议
项目初期应先做威胁建模,明确产品到底要防什么。
常见问题包括:
- 要防远程攻击吗?
- 要防山寨克隆吗?
- 要防产线超产吗?
- 要防非法固件运行吗?
- 要防耗材伪造吗?
- 要防调试口读取密钥吗?
- 要防升级包被篡改吗?
- 要防旧版本固件回滚吗?
不同威胁模型会决定不同的安全方案。
例如:
|
安全目标 |
可能需要的设计 |
|---|---|
|
防止非法固件运行 |
安全启动、固件签名、启动链校验 |
|
防止固件被篡改 |
数字签名、哈希校验、安全升级 |
|
防止设备被仿冒 |
设备证书、唯一密钥、挑战响应 |
|
防止通信被窃听 |
会话密钥、加密通信 |
|
防止通信被篡改 |
MAC、签名、消息完整性校验 |
|
防止重放攻击 |
随机数、计数器、时间戳 |
|
防止密钥泄露 |
加密芯片、安全存储、关闭调试口 |
|
防止旧固件回滚 |
版本计数器、防回滚机制 |
|
防止产线超产 |
证书烧录、授权计数、安全计数器 |
|
防止耗材伪造 |
加密认证芯片、挑战响应、绑定机制 |
安全设计介入越晚,后期补救成本越高。
如果硬件阶段没有预留安全芯片、调试口保护、安全存储和安全启动能力,后期单靠软件补丁很难彻底解决问题。
6. 工程总结
嵌入式安全不是后期补丁,而是贯穿产品全生命周期的系统设计。
它涉及:
- 硬件选型;
- MCU 安全能力;
- 加密芯片选型;
- 固件架构;
- 安全启动;
- 密钥管理;
- 通信协议;
- 产线烧录;
- 固件升级;
- 现场维护;
- 报废回收。
对于现代嵌入式设备来说,安全已经不再是“锦上添花”的功能,而是产品架构的一部分。
一个真正可靠的嵌入式系统,不仅要能稳定运行,还要能证明:
我是谁;
我运行的代码可信;
我收发的数据可信;
我的密钥不会轻易泄露;
我的生命周期可被安全管理。
178

被折叠的 条评论
为什么被折叠?



