2. BRSKI核心概念
好，咱们正式开始啃 BRSKI 的硬骨头。这一章我会把六个核心概念掰开揉碎讲清楚。你想想看，一个设备要安全入网，总得有人介绍、有人担保、有人发证吧？这六个角色就是干这些活的。
我个人习惯把这六个实体分成三组来记：入网方（Pledge、Join Proxy）、管理方（Join Registrar、Domain CA）、担保方（MASA、Voucher）。这样逻辑就顺了。
一句话总结：Pledge 想入网 → 通过 Join Proxy 找到 Join Registrar → Registrar 找 MASA 要 Voucher → Voucher 证明 Pledge 身份 → Domain CA 给它发证书。搞定。
2.1 Pledge —— 那个想入网的新设备
Pledge 就是刚出厂、还没被任何网络管理过的设备。说白了，它就是个「网络黑户」。我刚开始接触 BRSKI 时，总觉得 Pledge 就是个普通的客户端，后来才发现它身上有两个关键东西：IEEE 802.1AR 证书（也叫 IDevID）和制造商植入的私钥。
嗯，这里要注意：Pledge 在入网前只知道两件事——自己的身份（IDevID）和怎么找到 Join Proxy。别的它一概不知。
- 身份凭证：出厂时烧录的 IDevID 证书，不可篡改
- 初始状态：没有网络配置，没有域证书
- 行为模式：主动发起 DTLS 连接，请求入网
我的经验：曾经有个项目，Pledge 的 IDevID 证书过期了，结果整个入网流程卡在证书校验阶段。后来我养成了习惯——拿到设备先检查证书有效期，别等部署了才发现。
2.2 Join Proxy —— 那个传话的中间人
Join Proxy 是个很有意思的角色。它自己不参与决策，就是个「传话筒」。但你别小看它，没有它，Pledge 和 Registrar 可能根本说不上话。
为什么会这样？因为 Pledge 刚上电，连 IP 地址可能都是 DHCP 临时给的，它根本不知道 Registrar 在哪。Join Proxy 的作用就是：在本地网络里广播自己的存在，然后帮 Pledge 把请求转发给 Registrar。
我记得有一次在客户现场调试，Join Proxy 和 Registrar 之间的网络不通，Pledge 的请求全丢了。查了半天才发现是防火墙把 443 端口拦了。从那以后，我每次部署都会先确认 Proxy→Registrar 的连通性。
| 角色 | 职责 | 关键行为 |
|---|---|---|
| Join Proxy | 转发 Pledge 的请求 | 监听本地网络，中继 DTLS 连接 |
| Pledge | 发起入网请求 | 携带 IDevID，请求 Voucher |
2.3 Join Registrar —— 那个管事的
Join Registrar 是网络管理方的代表。它负责验证 Pledge 的身份，决定要不要让它入网。你可以把它理解成「网络管理员」的自动化版本。
Registrar 手里有两张牌：一是它自己的证书（由 Domain CA 签发），二是它知道怎么联系 MASA。当 Pledge 通过 Proxy 找过来时，Registrar 会做三件事：
- 验证 Pledge 的 IDevID——检查证书链是否可信
- 向 MASA 请求 Voucher——确认 Pledge 没有被篡改
- 签发本地证书——如果一切正常，让 Domain CA 给 Pledge 发证
避坑指南：我曾经遇到过 Registrar 和 MASA 之间的时钟不同步，导致 Voucher 签名验证失败。BRSKI 对时间同步要求很严格，NTP 一定要配好，否则你会被各种证书过期错误折磨到崩溃。
2.4 MASA —— 那个制造商后台
MASA（Manufacturer Authorized Signing Authority）是制造商运营的云服务。它手里有所有出厂设备的记录。当 Registrar 来问「这个 Pledge 是不是你们家生产的？」时，MASA 就查数据库，然后签发一个 Voucher 作为担保。
说白了，MASA 就是设备的「出生证明」开具有。它不关心你网络怎么配，只负责证明设备身份的真实性。
- 核心数据：设备序列号、IDevID 公钥、生产批次
- 对外接口：HTTPS API，接收 Voucher Request，返回 Voucher
- 安全要求：必须用私钥签名 Voucher，防止伪造
2.5 Voucher —— 那个担保书
Voucher 是整个 BRSKI 流程里最关键的数据结构。它是一个签名的 JSON 对象，内容大致是：「我，MASA，证明设备 X 属于网络 Y，请 Registrar 给它发证书。」
嗯，这里要注意：Voucher 是有时效性的。我见过有人把 Voucher 当成永久凭证来用，结果设备重新入网时发现 Voucher 过期了。正确的做法是：每次入网都重新请求 Voucher。
// Voucher 的简化结构（RFC 8366）
{
"ietf-voucher:voucher": {
"created-on": "2024-01-15T08:00:00Z",
"expires-on": "2024-01-16T08:00:00Z",
"serial-number": "SN-12345678",
"assertion": "verified",
"pinned-domain-cert": "base64...",
"signature": "base64..."
}
}
我的习惯：调试时我会先用 openssl cms -verify 手动验证 Voucher 签名，确认 MASA 的证书链没问题，再集成到自动化流程里。这一步能省掉很多排查时间。
2.6 Domain CA —— 那个发证机关
Domain CA 是网络内部的证书颁发机构。它负责给所有通过验证的设备签发本地证书（LDevID）。有了这个证书，设备才能在网络里正常通信。
你想想看，Pledge 的 IDevID 是制造商给的，只能证明「你是谁家的设备」。而 Domain CA 签发的 LDevID 证明的是「你属于这个网络」。这是两个完全不同的信任域。
| 证书类型 | 签发者 | 用途 | 有效期 |
|---|---|---|---|
| IDevID | 制造商 | 证明设备身份 | 设备生命周期 |
| LDevID | Domain CA | 证明网络归属 | 按策略配置（通常 1-5 年） |
2.7 它们怎么配合？一张图看懂
下面这张图展示了六个实体之间的核心交互流程。我建议你多看几遍，把每个箭头对应的协议交互记清楚。
2.8 避坑总结
最后，我把自己踩过的坑整理一下，你记好了：
- 证书有效期：IDevID 虽然说是设备生命周期，但实际有 10-20 年限制。部署前检查一下，别等过期了才慌。
- 时钟同步：BRSKI 所有签名验证都依赖时间。NTP 必须配，而且建议用多个源。
- Voucher 缓存：不要缓存 Voucher 重复使用。每次入网都重新请求，MASA 那边会有防重放机制。
- Proxy 发现：Join Proxy 通常用 mDNS 或 DHCP 选项广播。如果设备找不到 Proxy，先查这两项配置。
血的教训：我曾经在生产环境里忘了配 Domain CA 的 CRL 分发点，结果设备证书吊销后，新设备还能用旧证书入网。从那以后，我每次部署都会用 openssl x509 -text -in cert.pem | grep CRL 检查一遍。
好了，这六个核心概念你搞清楚了，后面学协议细节就会轻松很多。记住这张交互图，它就是 BRSKI 的骨架。