3. 公钥密码学基础：RSA、ECC 等算法在 PKI 中的应用

好，我们直接进入正题。PKI 的核心，说白了就是靠两把钥匙干活——一把公钥，一把私钥。这两把钥匙是怎么造出来的？背后就是 RSA、ECC 这些算法。

我个人习惯，在讲具体算法之前，先想清楚一个问题：为什么必须有公钥密码？对称加密用同一个密钥，速度快，但怎么把密钥安全地传给对方，这本身就是个死循环。公钥密码直接绕开了这个难题——我把公钥公开给你，你用公钥加密数据，只有我用私钥能解开。

但“公开”两个字，恰恰成了整个 PKI 安全基线的起点。你想想看，如果公钥是伪造的，那一切加密都白搭。

3.1 RSA：老当益壮，但得会用

RSA 这算法，我记得刚入行的时候就觉得它像个数学魔术。它基于一个事实：两个大质数相乘很容易，但要从乘积反推出是哪两个质数，难如登天。

RS的参数选择直接影响安全性。

关键参数：
  • n（模数）：两个大质数 p、q 的乘积。长度决定了安全强度。
  • e（公钥指数）：常用值有 3、65537。我个人不建议用 3，太容易出漏洞。
  • d（私钥指数）：核心秘密，一旦泄露，整个体系报废。
我的建议： 现在做 PKI 接口评估，RSA 密钥长度至少 2048 位，推荐 4096 位。1024 位的基本可以判死刑了。我在一次安全审计中遇到过一家甲方，证书还是 1024 位的，我当场就让他们下了整改函。

RSA 在 PKI 里主要干两件事：

  1. 数字签名：CA 用私钥给证书签名，客户端用 CA 的公钥验签。这是信任链的根基。
  2. 密钥传输：客户端用服务器的公钥加密一个对称密钥（比如会话密钥），服务器用私钥解开。SSL/TLS 握手就是这么干的。

这里有个坑，我曾经在项目中见过：有人直接把 RSA 加密当加密通道用，每次加密大块数据。RSA 加解密非常慢，而且有长度限制（最大为 (密钥长度字节数 – 11) 字节）。正确的做法是，RSA 只加密对称密钥，数据本身用 AES 这种对称算法加密。这叫“混合加密”。

3.2 ECC：小而美，潜力股

ECC（椭圆曲线密码学）近几年势头很猛。它的数学基础是椭圆曲线上的离散对数问题。同样的安全强度，ECC 的密钥长度比 RSA 短得多。

你看看这组对比数据就懂了：

安全强度（比特） RSA 密钥长度（位） ECC 密钥长度（位）
80 1024 160
128 3072 256
256 15360 512

说白了，ECC 用更小的密钥体积，提供了更高的安全级别。对移动设备、物联网终端这些资源受限的环境来说，ECC 几乎是必然的选择。我在评估一个车联网 PKI 项目时，如果强制用 RSA 4096，ECU 的计算和存储根本扛不住。后来全切成了 ECC P-256，问题才解决。

注意： ECC 曲线参数必须是标准化的。我见过有厂家自己拍脑袋抄了几条曲线，结果参数有后门，私钥能被算出来。在 PKI 里，只用 NIST 或 SM2 这些标准曲线，别自己发明。

ECC 在 PKI 里的应用场景和 RSA 类似，但优势明显：

  • ECDSA 签名：ECC 的数字签名算法，速度比 RSA 快，签名体积也小。
  • ECDH 密钥交换：用于在不安全的信道上安全地协商对称密钥。这是 TLS 1.3 的标配。

3.3 算法在 PKI 接口中的落地对比

现实中怎么选？我列个表给你参考：

评估维度 RSA ECC 日常基线检查重点
密钥生成 慢，尤其是大密钥 快，曲线固定后性能好 检查随机数源质量
签名速度 验签快，签名慢 签名快，验签相对慢 根据业务场景做压测
密钥体积 大，256字节（2048位） 小，32字节（256位） 评估证书存储和传输开销
算法成熟度 极高，已被研究透彻 高，但需警惕实现侧信道攻击 检查是否使用标准库（如 OpenSSL）
合规性 通用，支持最广 国密 SM2 属于 ECC，国内强推 看企业或监管所属领域

3.4 核心逻辑：公钥密码如何支撑 PKI

讲到这里，我们把 RSA 和 ECC 放入 PKI 大框架里看看。下面这张图，我特意做成了流程式的，它展示了公钥密码在 PKI 里最核心的用法：私钥签名，公钥验签。

公钥密码在PKI中的核心支撑流程 公钥密码在 PKI 中的核心支撑流程 CA (证书颁发机构) CA 私钥 CA 公钥（内置浏览器） 用私钥签名：生成数字证书 客户端验证签名：验签 验证通过 → 信任链建立

从图里你能看到，CA 用私钥签名，任何人都能用 CA 的公钥验签。这个模型里，公钥本身必须是可信的。所以 CA 的公钥通常被预装在操作系统或浏览器里，形成“根信任锚”。

一个现实问题： 你想想看，如果攻击者替换了你浏览器里的 CA 公钥，那信任链就断了。所以，PKI 接口的安全基线，第一条就是确保公钥的完整性。我每次做评估，第一件是事就是核对 CA 证书指纹。

3.5 避坑指南：实现层面的常见雷区

算法本身没问题，但实现上全是坑。我总结几个在 PKI 接口审计中反复出现的问题：

  • 随机数生成不安全。私钥生成依赖高质量随机数。用伪随机或固定种子生成密钥，等于没锁门。我曾经在一个嵌入式设备里发现，它的私钥竟然是通过系统时间戳 seed 出来的，三天之内就能被暴力算出来。
  • 私钥存储不当。私钥明文躺在磁盘里、数据库里、日志里。这是红线问题。必须用 HSM（硬件安全模块）或至少用加密存储。
  • 签名不做填充。RSA 加密/签名必须使用正确的填充（如 PKCS#1 v1.5、OAEP）。直接用裸 RSA 加密，有选择明文攻击的风险。
  • ECC 曲线点不是合法解。验证 ECC 公钥时，必须检查该点是否在曲线上。否则攻击者可以提供一个无效点，导致密钥协商失败或泄露信息。
注意： 这些坑在标准库（如 OpenSSL、Bouncy Castle）里处理得比较好。但如果你自定义了密码库，或者对标准库做了错误的配置，问题就来了。我的原则是：能用标准库就别自己造轮子，能用默认参数就别瞎改。

3.6 小结：评估时的核心关注点

做 PKI 接口安全基线评估时，关于公钥算法这块，我觉得你需要抓住这几条：

  1. 算法强度够不够？ RSA 低于 2048 位的，ECC 低于 256 位的，直接不通过。
  2. 实现是不是标准化的？ 用标准库，用标准曲线，用标准填充。
  3. 私钥保护到位了吗？ 有没有硬加密？有没有访问控制？有没有防导出机制？
  4. 公钥的真实性如何保证？ 证书链验证、指纹比对、CRL/OCSP 检查，一个都不能少。

嗯，这一章就到这。掌握这些，你就能对 PKI 接口里最基础的公钥密码部分，做到心里有数。

← 上一章 📖 返回目录 下一章 →