密码学基础（下）：公钥基础设施（PKI）概念、数字证书与CA机构、椭圆曲线密码学（ECC）简介
好，咱们接着聊。上一节我们把非对称加密、哈希、数字签名的原理过了一遍。这一节，我要把这些零散的知识点串起来，讲一个在OTA升级里真正落地的体系——公钥基础设施，也就是PKI。
说实话，我刚入行做嵌入式安全时，觉得PKI这东西是搞网络的人操心的。我一个小嵌入式工程师，把签名算法调通不就行了？后来在项目里吃了大亏——固件是签名了，但公钥怎么安全地放到设备里？设备怎么知道这个公钥是不是被换过了？这些问题，PKI就是标准答案。
1. 从“信任”说起：为什么需要PKI？
你想想看，非对称加密里，公钥是公开的。但“公开”不等于“可信”。
假设你的车机要下载一个OTA升级包。服务器发来固件和签名，车机用公钥验签。一切看起来没问题。但如果攻击者在中途把服务器的公钥换成了他自己的呢？车机用假公钥验假签名，照样能通过。这就是典型的中间人攻击。
所以，问题的核心不是“用什么算法签名”，而是“怎么安全地分发和验证公钥”。PKI就是解决这个信任问题的框架。
核心一句话：PKI不是某个算法，而是一套管理密钥和证书的规则、流程和软硬件体系。它解决了“你怎么知道这把公钥确实是它声称的那个实体拥有的”这个问题。
2. 数字证书：公钥的“身份证”
数字证书，说白了就是把公钥和它的主人绑定在一起的一个电子文件。这个绑定不是随便说说的，得有权威机构来担保。
一个标准的X.509数字证书包含哪些内容？我列个表，你对照着看：
| 字段 | 含义 | 我的备注 |
|---|---|---|
| 版本号 | 证书格式版本（V1/V2/V3） | 现在基本都用V3 |
| 序列号 | CA颁发的唯一编号 | 吊销证书时靠它定位 |
| 签名算法 | CA给证书签名用的算法 | 比如SHA256-RSA |
| 颁发者 | 签发该证书的CA名称 | 谁给你担保的 |
| 有效期 | 起始和结束时间 | 过期必须重新签发 |
| 主体 | 证书持有者的身份信息 | 设备ID或公司名 |
| 主体公钥 | 持有者的公钥 | 这就是我们要保护的核心 |
| 扩展字段 | 密钥用途、基本约束等 | OTA里常用Key Usage限制 |
| CA签名 | CA用私钥对整个证书的签名 | 防篡改的关键 |
你看，证书里最重要的就是主体公钥和CA签名。CA签名保证了证书内容没有被篡改过。你拿到一个证书，用CA的公钥验一下签名，就知道这个证书是不是真的。
我的经验：在嵌入式设备里，证书解析是个坑。X.509证书用ASN.1编码，解析库稍微没写好就容易出内存漏洞。我建议在OTA场景里，尽量用预解析好的二进制格式，或者用轻量级的TLS库自带的证书解析，别自己手写。
3. CA机构：信任的起点
CA，全称Certificate Authority，证书颁发机构。它是PKI体系里的“信任锚”。
CA的职责很简单：
- 验证身份：申请证书的人/设备，CA要先确认它确实是它声称的那个实体。
- 签发证书：验证通过后，CA用自己的私钥给申请者的公钥签名，生成数字证书。
- 管理证书生命周期：包括续期、吊销（CRL/OCSP）、归档。
CA自己也有一个证书，叫根证书。根证书是自签名的——也就是CA自己给自己签名。这个根证书就是信任链的起点。设备出厂时，会把根证书预置进去。之后所有由这个CA签发的证书，设备都能通过根证书来验证。
这就形成了一个信任链：
根证书（自签名，预置在设备中）
└── 中间CA证书（由根CA签发）
└── 设备证书（由中间CA签发）
└── 固件签名（由设备私钥签名）为什么要搞这么复杂？直接根证书签设备证书不行吗？
嗯，这里有个安全考量。如果根证书私钥泄露了，整个信任体系就崩了。所以根CA的私钥通常放在离线环境里，甚至用硬件加密机保护。日常签发工作由中间CA来做，即使中间CA出问题，吊销它一个就行，根证书还能继续用。
我曾经踩过的坑：有个项目，我们把根证书的公钥硬编码在Bootloader里。后来发现根证书过期了，但Bootloader没法更新。所有设备都验签失败，只能返厂。所以，OTA设备的根证书一定要有更新机制，哪怕只是通过安全通道推送一次。
4. 椭圆曲线密码学（ECC）简介
聊完PKI，咱们得说说ECC。为什么在OTA场景里，ECC越来越流行？
说白了，ECC用更短的密钥，提供和RSA同等级别的安全强度。你想想看，嵌入式设备的存储和算力都有限，ECC的256位密钥相当于RSA的3072位。省下来的空间和功耗，对电池供电的IoT设备来说太重要了。
ECC的核心是一个数学难题：椭圆曲线上的离散对数问题。给定椭圆曲线上的两个点G和Q，已知G，要找到整数k使得Q = kG，在计算上是不可行的。这就是ECC安全性的根基。
ECC的签名算法叫ECDSA（椭圆曲线数字签名算法）。它的流程和RSA签名类似，但数学运算不同。我简单画个对比：
| 特性 | RSA | ECC (ECDSA) |
|---|---|---|
| 安全强度 | 2048位 ≈ 112位对称 | 256位 ≈ 128位对称 |
| 密钥生成速度 | 慢 | 快 |
| 签名速度 | 慢 | 快 |
| 验签速度 | 快 | 较慢（但可接受） |
| 签名长度 | 256字节 | 64字节 |
| 推荐曲线 | N/A | P-256, secp256r1 |
在OTA固件签名场景里，我个人的习惯是：
- 服务端签名：用ECC，因为密钥生成和签名速度快，服务器压力小。
- 设备端验签：ECC验签虽然比RSA慢一点，但现代MCU带硬件加速器，基本无感。
- 密钥存储：ECC私钥更短，更容易塞进安全元件（SE）或TEE里。
注意：ECC的安全性高度依赖曲线的选择。不要自己发明曲线，用标准曲线（如NIST P-256、Curve25519）。我见过有人用了一个“优化”过的曲线，结果被侧信道攻击打得体无完肤。
5. 一张图看懂PKI与证书链
说了这么多，我画张SVG图，把PKI的核心流程串起来。你一看就明白了。
这张图把信任链的传递关系画清楚了。设备只需要安全地存储根CA的公钥，就能通过证书链逐级验证，最终确认固件签名的合法性。
6. 实践建议：在OTA中如何落地
最后，我结合项目经验，给你几条在OTA系统里落地PKI和ECC的实操建议：
- 证书不要太大：嵌入式设备的证书链尽量精简。根证书+中间证书+设备证书，三级就够了。别搞五六级，验签时间太长，用户等不了。
- 预置根证书：设备出厂时，把根证书的公钥烧死在一次性写入的存储区（如OTP）里。这样即使固件被破解，攻击者也改不了根证书。
- 支持证书吊销：OTA系统一定要有证书吊销列表（CRL）的更新机制。我见过一个项目，设备证书泄露了，但没法吊销，结果整个批次都得召回。
- ECC曲线选型：对于新项目，我建议直接用Curve25519（Ed25519签名）。它比P-256更安全，实现也更简单，不容易出侧信道漏洞。
- 验签性能测试：ECC验签在有些低端MCU上可能偏慢。量产前一定要做压力测试，确保在设备启动时间内能完成验签。
一个小技巧：如果设备性能实在有限，可以考虑“预验证”策略。在固件下载完成后，先验签再写入Flash。如果验签失败，直接丢弃，不污染Flash。这样即使下载过程中被篡改，也不会变砖。
好了，这一节的内容就到这儿。PKI和ECC是OTA安全的基石，理解透了，后面的签名方案设计才能游刃有余。