密码学-数字证书及其他相关概念

已更新系列文章包括104、61850、modbus 、储能系统等，欢迎关注

之前聊过的对称加密（AES）、非对称加密（RSA/ECDSA）、哈希摘要和签名验签，密码学领域还有几个在嵌入式设备开发中极其重要的上层概念。它们是构建完整安全通信系统的"最后一公里"。

1. 数字证书与 PKI（公钥基础设施）------ "公钥的身份证"

你已知道的 ：公钥是公开的，但你怎么确定这个公钥确实是"云端总司令"的，而不是黑客伪造后发给你的？
新概念 ：数字证书（X.509） 就是公钥的"身份证"。由一个绝对权威的第三方机构（CA，证书颁发机构 ）用自己的私钥给"某人的公钥 + 身份信息"签名，生成的一份文件。CA根证书里包含的是CA的"公钥"。私钥永远只能留在CA自己的保险柜里，用于"签发"证书；而根证书（内含公钥）则公开发布，用于"验证"证书。
关系与作用 ：设备出厂时预置"CA根证书"。当云端发来它的公钥证书时，设备用CA的公钥去验签该证书。验签通过，才敢信任这个公钥是真的。这就解决了"公钥防伪"问题。

数字证书完整流程（颁发 + 验证）

第一阶段：CA的自我准备（信任的起点）

CA生成"根私钥"和"根公钥"：CA用自己的算法生成一对密钥。
- 根私钥：绝密，锁在CA保险柜，用于签字盖章。
- 根公钥：公开，放入"CA根证书"中。
CA制作"根证书" ：CA把"自己的名字（证书颁发机构） + 自己的根公钥 + 有效期"打包，并用自己的根私钥 给自己签个名（自签名）。这就生成了CA根证书。
设备出厂烧录 ：设备生产时，把这份CA根证书 （内含CA公钥）烧进设备的只读安全存储区。从此，你的设备无条件信任这个CA公钥。

第二阶段：云端向CA申请证书

云端生成自己的"实体的私钥和公钥"：云端服务器自己生成一对密钥。
- 云端私钥：自己藏好，绝不外传（用于后续签名）。
- 云端公钥：准备拿出来公开（但需要CA担保）。
云端提交"办证申请"（CSR，证书签名请求） ：小明把自己的云端公钥 、自己的域名（api.cloud.com）、公司名等身份信息，整理成一份申请书，发给CA。
CA审核身份 ：CA打电话、查营业执照，确认确实是 api.cloud.com 的合法主人。
CA签发"数字证书"：审核通过后，CA做两件事：
- 把云端公钥 + 云的身份信息（域名等） + 有效期，打包成一个文件。
- CA拿出自己的根私钥 ，对这个打包文件进行哈希+签名（就像在护照上盖了个防伪钢印）。
- 最终生成的文件，就是云端的数字证书（也叫公钥证书）。

第三阶段：设备验证云端证书

云端发送证书 ：当你的设备连接云端时，云端先把它的数字证书（包含云端公钥 + CA的签名）发给你。
设备开始验签（核心动作）：
- 解得开 => 证明这个证书确实是CA签发的，不是黑客伪造的。
- 解不开 => 直接拒绝连接。
- 第一步（拆封） ：设备用出厂时预置的CA根证书里的CA公钥，去解证书上的"CA防伪钢印（签名）"。解得开吗？
- 第二步（比对）：解开钢印后，设备得到了CA当时算出的"摘要A"。同时，设备自己把证书里的"云端公钥和身份信息"重新哈希一遍，算出"摘要B"。
- 第三步（判定）：如果摘要A == 摘要B，说明证书内容没被篡改。

10.设备提取并信任公钥 ：验签通过后，设备从证书里提取出明文的"云端公钥" 。因为设备信任CA，CA担保这个公钥属于 api.cloud.com，所以设备才敢把这个公钥存下来，用于后续加密通信或验签。

📌 关键角色和归属权总结

组件	持有者	保密性	核心用途
CA 根私钥	CA （证书颁发机构）	绝密，永不公开	给所有下级证书签发（盖章）
CA 根证书（内含CA公钥）	设备（出厂预置）、浏览器等	完全公开	验证下级证书上的CA签名
云端实体私钥	云端服务器	绝密，自己藏好	用于证明自己是自己（TLS握手时签名）
云端数字证书（内含云端公钥）	云端服务器（发给设备）	完全公开	通过CA担保，把自己的公钥安全地交给设备

2. 混合加密（数字信封）------ "真实世界的加密方案"

已知的：RSA/ECDSA 加解密太慢，不适合加密大固件；AES 很快，但密钥没法安全地告诉对方。
新概念 ：混合加密完美结合两者。流程如下：
1. 发送方随机生成一个临时的 AES 对称密钥（会话密钥）。
2. 用 AES 快速加密那 100MB 的大固件（得到密文）。
3. 用接收方的 RSA/ECDSA 公钥 去加密那个小小的 AES 密钥（得到加密后的密钥）。
4. 把 密文 + 加密后的密钥 一起发给对方。
关系：接收方先用私钥解开 AES 密钥，再用 AES 密钥解密密文。这就是 TLS/SSL 握手的核心原理，兼顾了速度和密钥安全。

3. HMAC（哈希消息认证码）------ "带钥匙的哈希"

已知的：普通哈希（SHA-256）没有密钥，任何人都能算，只能防偶然错误，防不了人为篡改。
新概念 ：HMAC 是"哈希 + 对称密钥"的结合体。通信双方预先共享一个密钥，计算哈希时把密钥混入数据中。
关系与作用 ：它比非对称签名（RSA/ECDSA）快得多、功耗低得多 。在局域网内部设备间通信，用 HMAC 做校验和身份确认，效率远超签名验签。它保证：只有知道密钥的人，才能生成合法的校验码。

4. 密钥派生函数（KDF）与盐（Salt）------ "密码的保护伞"

已知的：用户输入的密码（如"123456"）太简单，直接哈希存下来，很容易被彩虹表暴力破解。
新概念 ：盐是一段随机数据，拼在密码后面一起哈希。KDF（如 PBKDF2、Scrypt） 是故意算得很"慢"的哈希算法。
关系与作用 ：设备本地存储登录密码时，流程是 最终密钥 = KDF(用户密码 + 随机盐)。加"盐"让同样的密码产生不同的哈希值，防预计算破解；算得"慢"让暴力破解的代价极高。这是设备本地身份认证的基石。

5. 真随机数生成器（TRNG）与熵------ "一切安全的种子"

已知的：所有算法（AES、RSA、ECDSA）都需要密钥，而密钥需要"随机"生成。
新概念 ：TRNG 是硬件从物理噪声（热噪声、量子效应）中提取的真随机数。熵是随机性的"纯度"指标。
关系与作用 ：如果设备没有足够的熵，生成的 RSA 私钥可能会被预测，导致整个安全体系崩塌。加密模块在初始化时，必须调用硬件 TRNG 驱动（如 ``/dev/hwrng）来收集熵，以确保 RAND_bytes 生成的密钥是安全的。

6. 防重放（Nonce / 时间戳）------ "旧指令的重放攻击"

已知的：验签通过只能证明签名是合法的，但证明不了这条指令是不是"现在"发的。
新概念 ：Nonce（一次随机数） 或 时间戳 是加到待签名数据里的一个"活体检测"字段。
关系：签名时，对 (指令内容 + 当前时间戳) 一起签名。验签时，设备不仅验签名，还检查时间戳是否在允许的误差范围内（如 ±5秒）。只要验签通过且时间戳新鲜，才能保证这不是黑客截获并重放的 3 天前的旧指令。

总结：

层级	核心概念	项目中的落地场景
底层基础	哈希、对称/非对称加密、TRNG	`crypto` 模块的工厂实现（OpenSSL底层调用）
中间协议	数字证书（X.509）、HMAC	`network` TLS 握手（验证服务器证书）、`ipc` 快速鉴权
上层业务	混合加密、KDF/盐、Nonce防重放	固件安全升级（大文件加密）、设备本地用户登录校验、云指令抗重放