嵌入式安全三要素：认证、完整性与保密性

关注

原创 2026-07-06 23:06:00 605 阅读 AI 写同款· GEO 优化 ›

【密码学系列-第二篇】HMAC 与 CMAC 通俗对比：嵌入式场景下的完整性防护指南 嵌入式通信场景下，单靠加密并不足以保证安全。：别人不能读出内容 → 用对称加密（如 AES）：别人不能悄悄改数据 → 用消息认证码（MAC）：别人不能复制旧数据 → 用随机数/序列号等机制于是我们设计了这样一套逻辑：加密：我不想别人看到内容 → 用 AES 等对称加密算法认证：我不想别人篡改数据 → 加入 HMAC 或 CMAC 等认证码防重放：我不想别人复制老包 → 加入 nonce 或 IV 做唯一标识。阅读详情

很多工程师把“安全”等同于“加密”，但在嵌入式系统中，安全的优先级通常是：

身份认证；
数据完整性；
数据保密性。

也就是说，设备首先要确认：

对方是否可信；
数据是否被改过；
数据内容是否需要隐藏。

只有前两个问题解决之后，保密性设计才有实际意义。

关键词	工程含义
认证 / 完整性 / 保密性	先确认对方可信和数据可信，再决定是否需要隐藏数据内容。

1. 为什么不能把安全简单理解为加密

在嵌入式系统中，很多人一提到安全，第一反应就是：

加 AES；
通信数据不要明文；
固件内容加密；
协议字段做混淆。

这些措施确实可以提高安全性，但它们并不等于完整的安全设计。

因为加密主要解决的是“别人能不能看懂数据”，而很多实际攻击并不是从“看懂数据”开始的，而是从下面这些问题开始的：

对方是不是合法设备？
这条命令是不是合法控制器发出的？
固件有没有被篡改？
配置参数有没有被偷偷修改？
这包数据是不是以前截获后重放的？
这个耗材、探头或电池是不是真的？

所以，在嵌入式安全中，通常应该先考虑身份认证和完整性，再考虑保密性。

2. 身份认证 Authentication

身份认证用于确认通信对象或设备确实是它声称的对象。

通俗地说，认证要解决的问题是：

你是谁？
你能不能证明你就是你？

在嵌入式产品中，认证常见于以下场景：

主机判断接入的传感器是否合法；
主机判断耗材、探头、电池是否为原厂或授权部件；
设备判断云端服务器是否可信；
设备判断升级包是否来自合法发布方；
网关判断接入的子设备是否可信；
产线系统判断设备是否为合法生产对象。

如果没有认证，攻击者可以伪造一个设备。

即使后续通信使用了加密，也可能只是和攻击者建立了一条**“加密但不可信”**的通道。

3. 没有认证时，加密也可能失效

一个常见误区是：

只要通信加密了，就安全了。

但如果设备没有先确认对方身份，加密通道本身也可能建立在错误对象之上。

例如：

主机通过某个接口连接传感器。如果攻击者伪造了一个传感器，并且主机没有认证机制，那么主机可能会直接和这个假传感器通信。

此时，即使通信过程中使用了 AES，结果也只是：

主机和假传感器之间建立了一条加密通道。

数据确实被加密了，但对方身份并不可信。

所以，认证是很多嵌入式安全设计中的第一步。

4. 完整性 Integrity

完整性用于判断数据是否被修改。

它要解决的问题是：

数据在传输、存储或升级过程中，有没有被改过？

在嵌入式系统中，需要完整性保护的数据很多，例如：

固件镜像；
Bootloader；
配置参数；
校准参数；
控制命令；
日志记录；
测量数据；
生产序列号；
设备证书；
升级包元数据。

如果没有完整性保护，攻击者可能修改固件、配置或通信命令，从而让设备执行错误逻辑。

5. Hash、MAC 和数字签名的区别

完整性保护常见手段包括 Hash、MAC 和数字签名。

它们的作用不同，工程上不能混用。

方法	主要作用	是否能证明来源	典型用途
Hash	判断数据有没有变化	不能	文件校验、固件摘要
MAC	判断数据有没有变化，并证明发送方知道共享密钥	可以，前提是共享密钥安全	通信报文认证、挑战响应
数字签名	判断数据有没有变化，并证明来自私钥持有者	可以	固件签名、证书链、安全升级

5.1 Hash

Hash 可以发现数据变化。

例如，对固件计算 SHA-256 摘要，只要固件内容发生任何变化，摘要结果就会不同。

但 Hash 本身不能证明数据来自合法发送方。

原因是攻击者如果能够修改固件，也可以重新计算一个新的 Hash。

所以，Hash 更适合用于普通校验、摘要计算，不能单独作为安全认证手段。

5.2 MAC

MAC，也就是消息认证码。

它不仅能判断数据有没有被修改，还能证明发送方知道某个共享密钥。

例如，主机和设备内部都保存同一个密钥。发送方对消息计算 MAC，接收方用同一个密钥验证 MAC。

如果验证成功，说明：

数据没有被修改；
发送方大概率持有正确密钥。

因此，MAC 常用于设备认证、挑战响应和通信报文完整性保护。

5.3 数字签名

数字签名基于非对称密钥体系。

发布方使用私钥对固件或数据摘要进行签名，设备端使用公钥验证签名。

数字签名适合用于：

固件安全启动；
OTA 升级包校验；
证书链验证；
生产授权文件验证。

它的优势是：设备端只需要保存公钥，不需要保存发布方私钥。

即使设备被攻击者拿到，也不应该能伪造合法签名。

6. 保密性 Confidentiality

保密性用于防止数据被窃听者读取。

它要解决的问题是：

这条数据被别人看到，会不会造成风险？

保密性适用于敏感数据，例如：

医疗数据；
用户身份信息；
密钥材料；
商业机密；
算法参数；
生产授权信息；
设备内部诊断数据；
某些专有协议内容。

常见保密性手段包括：

对称加密，例如 AES；
非对称加密；
会话密钥；
TLS / DTLS；
安全存储；
加密 Flash；
加密升级包。

7. 不是所有数据都必须加密

不是所有命令都必须加密。

例如：

打开灯；
查询版本号；
读取普通状态；
设置非敏感工作模式。

这些数据内容本身可能并不敏感，即使被别人看到，风险也不大。

但是，这并不代表它们不需要安全保护。

对于控制命令来说，更重要的问题通常是：

命令是不是合法控制器发出的？
命令有没有被篡改？
命令是不是历史数据重放？
命令是否在允许的权限范围内？

也就是说，有些数据不一定需要保密性，但一定需要认证、完整性和防重放保护。

8. 工程判断方法

判断一条消息是否需要加密时，不要先问：

能不能加 AES？

而应该先问三个问题：

8.1 这条消息需要证明来源吗？

如果需要证明来源，就要考虑：

设备认证；
消息认证；
挑战响应；
MAC；
数字签名；
证书机制。

8.2 这条消息被篡改会不会有风险？

如果被篡改会造成风险，就要考虑：

完整性校验；
MAC；
数字签名；
安全计数器；
防回滚；
防重放机制。

8.3 这条消息内容被别人看到是否有价值？

如果内容被看到会造成风险，就要考虑：

数据加密；
会话密钥；
密钥协商；
安全存储；
TLS / DTLS；
加密升级包。

前两个问题通常决定认证和完整性，第三个问题才决定保密性。

9. 工程示例

示例 1：固件升级包

固件升级包通常至少需要：

完整性保护；
发布方身份认证；
防回滚机制。

如果固件内容涉及算法、协议或商业机密，还需要考虑加密。

也就是说，固件升级包并不是“只加密”就安全，关键是要验证：

这个固件是不是官方发布的？
这个固件有没有被篡改？
这个固件是不是允许安装的版本？

示例 2：耗材认证

耗材认证的核心通常不是“数据是否保密”，而是：

这个耗材是不是真的？
它是不是被复制出来的？
它有没有被重复使用或非法复位？

因此，耗材认证通常需要：

唯一身份；
挑战响应；
共享密钥或非对称认证；
安全计数器；
防重放机制。

示例 3：普通控制命令

例如“打开灯”这样的命令，内容本身并不敏感。

但是，如果攻击者可以伪造这条命令，系统仍然存在风险。

所以它可以不加密，但应该保证：

命令来自合法控制器；
命令没有被篡改；
命令不是历史数据重放；
命令在当前状态下允许执行。

10. 工程总结

加密只是安全的一部分。

真正可靠的嵌入式安全系统，必须先解决两个更基础的问题：

身份可信；
数据可信。

然后再根据数据价值决定是否需要隐藏内容。

简单来说：

认证解决“你是谁”；
完整性解决“数据有没有被改”；
保密性解决“别人能不能看懂”。

在嵌入式产品中，安全设计的优先级通常不是：

先加密，再考虑其他。

而应该是：

先认证身份；
再保护完整性；
最后根据需要保护保密性。

收录于

嵌入式加密技术系列文档

标签

#网络 #服务器 #tcp/ip

嵌入式设备安全合规：从“裸奔”到系统级防护，先御OS的实战解析在物联网与工业控制领域，嵌入式设备的安全问题日益严峻。传统设备缺乏可信根，启动链、固件升级、通信链路及运行期防护均存在天然缺陷，难以满足等保2.0、IEC 62443等合规要求。系统级安全平台成为解决之道，其原理是从上电启动到业务运行构建完整信任链，通过安全启动、签名验签、双向认证、日志审计等机制实现纵深防御。这种方案不仅适用于工业网关、边缘AI盒子，也能覆盖智慧城市、医疗电子等场景，让设备具备“自证清白”的可信能力。以先御OS为例，它在不依赖专用安全芯片的前提下，将安全组件作为操作系统内生能力，以极低性能阅读详情