ChatCoding的博客

即使攻击者破解了耗材 A，拿到 Key_A，也不能直接得到 Key_B、Key_C，更不能反推出 Root_Key。例如，主机发送一个随机 Challenge，设备使用内部密钥计算 MAC，主机使用相同密钥计算期望 MAC。对称密钥认证，是指主机和设备共享同一类密钥，通过相同算法计算认证结果，从而判断对方是否拥有正确密钥。使用一个父密钥 Root_Key，再结合设备唯一信息，派生出每台设备自己的密钥。因为设备端如果保存验证密钥，一旦设备被破解，攻击者可能伪造升级包。

如果 Challenge 固定、重复、可预测，或者主机允许验证旧 Challenge，那么攻击者截取到一组 Challenge + Response 后，就可以进行重放攻击。如果密钥直接明文放在 MCU 普通 Flash 中，一旦攻击者通过调试口、烧录口、固件读取或漏洞提取密钥，就可以伪造合法 MAC。因此，在 MCU 项目中，如果软件实现 MAC，应优先使用成熟密码库中的 HMAC-SHA256，而不是自行设计变体。MAC 有密钥参与，攻击者即使修改消息，也无法在不知道密钥的情况下生成正确 MAC。

因此，在安全设计中，应选择当前仍被认为安全的哈希算法，例如 SHA-256，而不是 MD5、SHA-1 这类已经不适合作为安全用途的算法。如果攻击者修改数据后，重新计算一个新的 Hash，并把新 Hash 一起发给设备，那么接收方仍然可能被骗。如果需要抵抗恶意修改，单独 CRC 不够，应至少考虑 Hash，并进一步结合 MAC 或数字签名。如果只有 Hash，没有签名，攻击者修改固件后也可以重新计算 Hash。但是，如果只校验 Hash，而不验证签名，仍然不能证明升级包来自官方。

例如，只检查 SN、设备 ID、型号或批次号，就认为设备可信，这在工程上是不安全的。真正可靠的做法，是结合挑战响应、MAC、数字签名、安全芯片、证书链和权限控制，建立从身份声明到身份证明，再到权限约束的完整闭环。因此，SN、设备 ID、型号、批次号、版本号，都只能作为身份声明或索引信息，不能单独作为安全认证依据。在工程实现中，SN、型号、批次号、设备 ID 只能用于识别和索引，不能单独作为可信认证依据。身份识别不是安全，身份认证才开始建立信任，授权则决定信任之后的权限边界。

如果攻击者伪造了一个传感器，并且主机没有认证机制，那么主机可能会直接和这个假传感器通信。例如，主机和设备内部都保存同一个密钥。即使后续通信使用了加密，也可能只是和攻击者建立了一条**“加密但不可信”**的通道。例如，对固件计算 SHA-256 摘要，只要固件内容发生任何变化，摘要结果就会不同。如果没有完整性保护，攻击者可能修改固件、配置或通信命令，从而让设备执行错误逻辑。所以，在嵌入式安全中，通常应该先考虑身份认证和完整性，再考虑保密性。这些数据内容本身可能并不敏感，即使被别人看到，风险也不大。

随着设备逐步接入网络、云平台、手机 App、产线系统和第三方配件，嵌入式系统已经从“单板软件”变成“设备生态系统”的一部分。攻击者不一定需要拆机。但是，当设备接入网络、云平台、手机 App、产线系统和第三方配件之后，风险边界发生了明显变化。如果系统只检查设备 ID，而没有真正的身份认证机制，那么设备 ID 一旦被复制，就可能被仿冒。在医疗、工业、打印、检测仪器等场景中，主机经常需要识别耗材、探头、模块或传感器是否合法。，工程团队通常通过看门狗、异常恢复、通信校验、滤波、冗余检测和可靠性测试来解决。