3. 公钥基础设施入门
在设备身份工程中，设备要证明“我是谁”，不能只靠口令或序列号，而需要一套可验证、可撤销、可扩展的信任体系。公钥基础设施（PKI，Public Key Infrastructure）正是这套体系的骨架。它把密钥、证书、签发机构、注册审核和信任传递组织成一条可运营的生命周期链，使设备在出厂、入网、轮换、退役各阶段都能获得可验证的身份凭据。
一、核心角色与基本概念
PKI 由若干角色和对象组成。理解它们之间的职责边界，是后续证书生命周期管理的基础。
- 密钥对：由私钥和公钥组成。私钥必须保密，用于签名或解密；公钥可公开，用于验签或加密。设备身份场景中，私钥通常存放在安全芯片、TPM、TEE 或密钥库中，不可导出。
- 证书：由 CA 签发的结构化数据，包含主体标识、公钥、有效期、用途扩展、序列号、签发者及签名。证书是公钥的“身份证”。
- CA（证书颁发机构）：负责签发和吊销证书，是信任锚点。CA 用自己的私钥对证书签名，验证方用 CA 公钥验签。
- RA（注册机构）：负责身份审核、请求受理和注册，不直接签发证书。RA 把审核通过的请求转交 CA，实现“审核与签发分离”。
- CRL/OCSP：证书吊销列表和在线证书状态协议，用于查询证书是否已被吊销。
- 信任链：从终端实体证书逐级向上验证到根 CA，形成可追溯的信任路径。
二、数字签名与信任链原理
数字签名解决两个问题：完整性校验和身份不可否认。签名过程是：发送方对消息计算摘要，再用自己的私钥对摘要加密，生成签名；接收方用发送方公钥解密签名得到摘要，并对原文重新计算摘要，两者一致则说明消息未被篡改且确实由私钥持有者发出。
信任链则把这种验证关系逐级传递。设备证书由中间 CA 签发，中间 CA 由根 CA 签发，根 CA 自签名并预置在信任库中。验证时从设备证书开始，逐级用上级公钥验签，直到根 CA。只要路径完整、签名有效、有效期和用途合规、未被吊销，就认为设备身份可信。
三、证书签发与验证流程
一次典型的设备证书签发流程如下：设备生成密钥对并保护私钥；向 RA 提交证书签名请求（CSR），CSR 中包含公钥和主体信息；RA 审核设备身份（如产线凭证、序列号、注册令牌）；审核通过后转交 CA；CA 按模板签发证书并写入序列号、有效期和扩展项；证书下发到设备并部署到信任库。验证方在通信时执行信任链校验。
# 生成设备密钥对与 CSR（示例）
openssl genrsa -out device.key 2048
openssl req -new -key device.key -out device.csr \
-subj "/CN=DEV-0001/O=Factory-A/C=CN"
# CA 签发设备证书
openssl x509 -req -in device.csr -CA intermediate.crt \
-CAkey intermediate.key -CAcreateserial \
-days 365 -sha256 -out device.crt
# 验证信任链
openssl verify -CAfile root.crt -untrusted intermediate.crt device.crt四、典型场景与常见误区
在设备身份场景中，PKI 常用于设备入网认证、固件签名、TLS 双向认证和零信任接入。例如，产线为每台设备签发唯一证书，设备首次联网时用私钥签名挑战值，平台验证证书链和吊销状态后放行。证书到期前通过自动化流程轮换，避免大规模断连。
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 所有设备共用一张证书 | 单点泄露导致全量仿冒，无法精细吊销 | 一机一证，私钥不可导出 |
| 根 CA 直接签发设备证书 | 根密钥暴露风险高，吊销粒度粗 | 根 CA 离线，中间 CA 分层签发 |
| 只校验签名不校验吊销 | 已泄露证书仍可接入 | 启用 CRL/OCSP 并缓存策略 |
| 证书有效期过长 | 密钥泄露影响窗口大 | 短有效期 + 自动轮换 |
| 忽略用途扩展 | 签名证书被用于 TLS 认证 | 严格校验 KeyUsage/ExtendedKeyUsage |
理解 PKI 的角色分工、数字签名机制和信任链验证逻辑，是后续学习证书生命周期管理、设备身份注册、密钥轮换和吊销策略的前提。只有把“谁签发、谁审核、谁持有私钥、谁验证”这条链路理清，设备身份体系才具备可运营的安全基础。