📚 课程目录第4章加密基础

加密基础：对称加密、非对称加密、哈希函数与数字签名

加密这东西，说白了就是给数据上锁。我在做设备隐私保护时，最常被问到的问题是：“到底该用哪种加密？” 嗯，这个问题没有标准答案，但有个基本原则——没有一种加密能包打天下。你得根据场景来选，甚至组合使用。

这一章，我把四种核心加密技术拆开来讲。对称加密、非对称加密、哈希函数、数字签名，每个我都会结合项目经验，告诉你什么时候用、怎么用、坑在哪。

核心观点：加密不是越复杂越好，而是越合适越好。设备端的算力有限，选错加密方案，轻则响应慢，重则设备死机。我见过有人给传感器芯片上 RSA-4096，结果每次握手要等 3 秒——这显然不合适。

对称加密：又快又简单，但密钥怎么传？

对称加密，就是加密和解密用同一个密钥。你想想看，就像你用一把钥匙锁门，也用同一把钥匙开门。优点是快，非常快。AES 在硬件加速下，每秒能处理 GB 级数据。

我个人习惯，在设备端做大量数据加密时，首选 AES-256-GCM。为什么？因为 GCM 模式自带认证标签，能同时检测数据是否被篡改。省掉你额外算哈希的步骤。

我的经验：在 IoT 设备上，AES-128 其实已经够用。别盲目上 AES-256，多出来的 128 位密钥长度，在设备端可能要多耗 30% 的算力。我曾经在一个智能门锁项目里，为了“更安全”用了 AES-256，结果电池续航从 6 个月掉到 4 个月——后来换回 AES-128，安全等级没降多少，续航回来了。

对称加密最大的痛点是什么？密钥分发。你想想，如果每个设备都用同一个密钥，那一个设备被破解，整个系统就完了。如果每个设备用不同密钥，那密钥怎么安全地送到设备上？

这就是非对称加密登场的地方。

非对称加密：密钥分发的救星

非对称加密，有一对密钥：公钥和私钥。公钥可以公开，私钥自己藏好。你用公钥加密，只有对应的私钥能解密。反过来，你用私钥签名，别人用公钥验证。

RSA 和 ECC 是两种主流方案。RSA 老牌、稳定，但密钥越长越慢。ECC 用更短的密钥达到同等安全强度——256 位的 ECC 密钥，安全性和 3072 位的 RSA 差不多。

特性	RSA	ECC
密钥长度（同等安全）	2048-4096 位	256-384 位
加密速度	慢（密钥越长越慢）	快（尤其签名）
硬件资源消耗	高	低
典型应用	传统 PKI、HTTPS	移动设备、IoT、区块链

我在项目中怎么选？如果设备是资源受限的 MCU（比如 Cortex-M0），我建议用 ECC。如果设备有独立的安全芯片或硬件加速，RSA 也可以。但说实话，现在新项目我基本都推 ECC 了。

避坑指南：我曾经在一个项目中，直接用 RSA 加密整个固件包。结果每次 OTA 升级，设备要花 40 秒解密——用户都以为设备死机了。后来改成“用 RSA 加密 AES 密钥，再用 AES 加密固件”，解密时间降到 2 秒。记住：非对称加密只用来加密小数据，比如密钥、哈希值。

哈希函数：不可逆的指纹

哈希函数，输入任意长度数据，输出固定长度的摘要。关键特性：不可逆、抗碰撞。你没法从哈希值反推出原始数据，也很难找到两个不同数据有相同哈希值。

SHA-256 是目前最常用的。输出 256 位（32 字节），足够安全。MD5 和 SHA-1 已经被破解，别用了。

哈希函数在设备隐私保护里，主要有三个用途：

数据完整性校验：下载固件后算一下哈希，和官方发布的对比，一致就没被篡改。
密码存储：存密码的哈希值，而不是明文。即使用户数据库泄露，攻击者也拿不到原始密码。
消息认证：结合密钥做 HMAC，验证消息是否来自合法发送方。

重要提醒：哈希不是加密。哈希不可逆，加密可逆。很多人把这两个概念搞混。哈希是“单向函数”，加密是“双向函数”。你存密码用哈希，传数据用加密——别搞反了。

数字签名：证明你是谁，东西没被改

数字签名 = 哈希 + 非对称加密。流程是这样的：

发送方对数据算哈希
用私钥加密这个哈希，得到签名
把数据和签名一起发出去
接收方用公钥解密签名，得到哈希值
接收方自己算数据的哈希，对比两个哈希

如果一致，说明数据没被改，而且确实是私钥持有者签的。这就是完整性 + 身份认证。

我在设备固件签名里经常用 ECDSA（基于 ECC 的数字签名算法）。签名短、验证快，适合资源受限的设备。

// 伪代码：固件签名与验证流程
// 签名（在安全构建服务器上执行）
hash = SHA256(firmware_binary)
signature = ECDSA_sign(private_key, hash)
// 输出：firmware_binary + signature

// 验证（在设备端执行）
hash = SHA256(received_firmware)
is_valid = ECDSA_verify(public_key, hash, received_signature)
if (is_valid) {
    // 固件未被篡改，开始升级
} else {
    // 拒绝升级，记录告警
}

我的习惯：在设备出厂时，就把公钥烧录到设备的不可篡改存储区（比如 eFuse 或安全元件）。这样即使固件被替换，攻击者也改不了公钥。我曾经见过一个项目，公钥存在普通 Flash 里，结果攻击者直接替换公钥，用自己的私钥签名恶意固件——整个安全体系瞬间崩塌。

四种技术如何协同工作？

实际项目中，这四种技术很少单独使用。我给你画个典型流程：

设备身份认证：设备用 ECC 私钥签名一个随机挑战，服务器用公钥验证。证明“我是合法设备”。
会话密钥协商：用 ECDH（基于 ECC 的密钥交换协议）协商出一个临时 AES 密钥。
数据加密传输：用 AES-256-GCM 加密业务数据，同时用 GCM 的认证标签保证完整性。
固件升级：服务器用 ECDSA 签名固件，设备验证签名后，用 AES 解密固件内容。

你看，四种技术各司其职，组合起来才是一个完整的安全体系。

又一个坑：我曾经遇到一个团队，自己实现了加密算法——千万别干这种事。加密算法是数学家和密码学家几十年研究的成果，你自己写的“加密算法”大概率几天就被破解。用标准库，用经过验证的实现。OpenSSL、mbedTLS、WolfSSL 都是靠谱的选择。