2. 校验核心概念：完整性、真实性、机密性、校验与加密的区别

做固件安全这么多年，我见过太多人把「校验」和「加密」混为一谈。说实话，这俩东西虽然经常一起出现，但干的完全是两码事。今天咱们就把这几个核心概念掰扯清楚。

2.1 三个核心属性：完整性、真实性、机密性

先问个问题：你拿到一个固件包，最关心什么？

我个人习惯，先看三件事：

• 文件有没有被人动过手脚？ —— 这是完整性
• 这个文件到底是不是官方发布的？ —— 这是真实性
• 文件内容会不会被别人偷看？ —— 这是机密性

嗯，这三个属性，缺一个都不行。咱们一个一个说。

完整性（Integrity）

完整性说白了就是「文件没被改过」。我在项目中遇到过好几次，固件在传输过程中被中间人篡改，插入了恶意代码。完整性校验就是用来发现这种问题的。

常用的手段是哈希校验。比如 SHA-256，把固件算出一个固定长度的摘要。只要原文改了一个 bit，摘要就完全不一样。

真实性（Authenticity）

这个就更有意思了。完整性只能发现篡改，但没法区分「官方发布的版本A」和「黑客伪造的版本A」。真实性校验，就是要确认这个固件确实来自你信任的源头。

怎么做？数字签名。用私钥签名，用公钥验证。我在做 IoT 设备固件升级时，就吃过没做真实性校验的亏——设备被刷上了第三方修改版固件，出了事还找不到原因。

机密性（Confidentiality）

机密性关注的是「别人能不能看到固件内容」。有些场景下，固件里包含敏感算法、密钥或者商业机密，这时候就需要加密传输或存储。

不过说实话，在固件校验领域，机密性往往不是最优先的。为什么？因为很多嵌入式设备是公开部署的，固件本身可以被读取（比如通过调试接口）。这时候你更应该关注完整性和真实性。

属性	解决的问题	常用技术	典型场景
完整性	文件是否被篡改	哈希（SHA-256、SHA-3）	固件下载后校验
真实性	文件是否来自可信源	数字签名（RSA、ECDSA）	固件升级认证
机密性	文件内容是否泄露	对称/非对称加密	固件包含敏感数据

2.2 校验与加密的区别

这个坑我踩过，所以必须重点讲。很多人觉得「加密了就等于安全了」，其实大错特错。

加密解决的是机密性问题，校验解决的是完整性和真实性问题。它们的目标完全不同。

举个例子。你给固件加了 AES 加密，传输过程中别人确实看不到内容。但如果攻击者把密文截获后，替换成另一段密文，你的设备解密后照样会执行——因为加密本身不提供完整性保护。

反过来，如果你只做了哈希校验，固件内容在传输过程中是明文的，任何人都可以读取。这在某些场景下也是不行的。

所以，正确的做法是：加密和校验配合使用。先签名再加密，或者先加密再签名，具体顺序取决于你的安全模型。我个人习惯是先签名后加密，这样验证方可以先解密再验签，流程更清晰。

2.3 知识体系总览

下面这张图，把这三个核心属性和它们之间的关系画清楚了。建议你多看几遍，理解每个属性的定位。

2.4 避坑指南

最后分享几个我踩过的坑，希望能帮你少走弯路。

• 别只用 CRC 做完整性校验。 CRC 只能检测随机错误，防不了恶意篡改。我在一个项目里看到有人用 CRC32 校验固件，结果攻击者轻松构造了碰撞。必须用密码学哈希。
• 签名和加密的密钥要分开。 我曾经见过一个方案，签名密钥和加密密钥是同一个。一旦泄露，全完蛋。密钥管理是另一门学问，后面会细讲。
• 不要迷信「加密固件就是安全的」。 加密只解决机密性，不解决完整性和真实性。攻击者可以重放旧的加密固件，或者篡改密文后让设备解密执行。一定要配合签名。