4、BRSKI核心组件：Pledge、Registrar、MASA、Voucher
BRSKI协议说白了就是解决一个核心问题：一台全新的设备，怎么在没人现场配的情况下，自己找到组织、证明身份、拿到入网许可证？
我最早接触这个协议时，第一反应是——这不就是给网络设备搞了个“自助入职系统”吗？设备是新人，网络是HR部门，MASA是背调公司，Voucher就是offer letter。
嗯，这个比喻虽然糙了点，但核心逻辑确实差不多。咱们今天就把这四个组件拆开来看。
4.1 Pledge：那个啥也不懂的“新员工”
Pledge，就是刚出厂的设备。它只知道两件事：
- 自己有个出厂身份（通常是IEEE 802.1AR里的 IDevID 证书）
- 自己该去找谁报到（通过DNS或DHCP发现Registrar）
别的？一概不知。网络拓扑不知道，管理员是谁不知道，甚至连自己该干什么活都不清楚。
Pledge的核心特征
- 持有不可篡改的出厂身份（IDevID）
- 没有本地配置的信任锚
- 只能通过BRSKI协议完成“零接触”入网
- 入网后获得本地身份（LDevID）
我在项目中遇到过一种情况：某厂商的Pledge实现里，IDevID私钥存储用的是软证书，结果被攻击者通过JTAG接口读出来了。嗯，这里要提醒一句——IDevID的私钥保护必须是硬件级别的，TPM或安全元件是底线，别图省事。
4.2 Registrar：那个“HR部门”
Registrar是网络侧的核心组件。它负责：
- 接收Pledge的入网请求
- 验证Pledge的出厂身份
- 向MASA申请Voucher
- 把Voucher交给Pledge完成信任建立
说白了，Registrar就是Pledge和MASA之间的中间人。它自己不需要完全信任Pledge，但它需要有能力验证Pledge拿到的Voucher是不是真的。
| 角色 | 职责 | 关键能力 |
|---|---|---|
| Registrar | 入网审核 | 验证IDevID、申请Voucher、分发LDevID |
| Pledge | 入网请求 | 出示IDevID、安装Voucher、生成LDevID |
| MASA | 背书服务 | 签发Voucher、验证所有权 |
我个人习惯把Registrar部署在网络的边缘层，靠近接入交换机的位置。这样Pledge发起加入请求时，延迟最小。曾经有个项目把Registrar放在数据中心核心，结果Pledge跨三层网络发现Registrar时，DHCP选项和DNS解析各种超时——折腾了两天才定位到是网络延迟问题。
4.3 MASA：那个“背调公司”
MASA全称是Manufacturer Authorized Signing Authority。它是设备厂商运营的一个在线服务。
你想想看，Pledge说“我是某某厂商的设备”，Registrar怎么确认？它只能找厂商的MASA去核实。
MASA的核心能力：
- 持有厂商的根CA证书
- 能验证Pledge的IDevID是否由自己签发
- 根据Registrar的请求签发Voucher
- 记录Voucher的签发历史（防止重放攻击）
注意：MASA不是必须在线
BRSKI协议支持离线场景。Pledge可以预装一个“域名锚点”，Registrar可以缓存MASA的公钥。但说实话，我在实际部署中很少见到离线模式——你想想，设备都要联网了，MASA却连不上，这本身就有点矛盾。
我曾经帮一家客户排查过MASA证书过期的问题。他们的设备是两年前出厂的，MASA的签名证书只有一年有效期。设备上线时，Registrar拿着Voucher去验证，发现MASA证书链断了。嗯，这个坑其实很好避免——MASA的证书有效期必须覆盖设备的预期生命周期，或者至少要有自动续期机制。
4.4 Voucher：那张“offer letter”
Voucher是整个BRSKI协议里最巧妙的设计。它本质上是一个签名的JSON对象，里面包含：
- pinned-domain-cert：Registrar的域名证书指纹
- assertion：断言类型（通常是“verified”）
- serial-number：目标Pledge的序列号
- created-on：签发时间
- expires-on：过期时间
Voucher的作用是什么？
说白了，它就是MASA对Pledge说的一句话：“这个Registrar你可以信任，跟着它走没错。”
Pledge拿到Voucher后，会做三件事：
- 验证Voucher的签名（用MASA的公钥）
- 提取pinned-domain-cert
- 用这个证书去验证Registrar的身份
一旦验证通过，Pledge和Registrar之间就建立了一条信任链。之后就可以走EST协议完成证书申请了。
Voucher的格式
Voucher使用CBOR编码，结构定义在RFC 8366里。如果你用Python做原型验证，可以用cbor2库来解析。我习惯在调试时先转成JSON看结构，确认字段没问题再切回CBOR。
4.5 四个组件如何协作？
咱们用一张图把整个流程串起来：
你看，整个流程其实就四步：
- Pledge发起加入请求，出示IDevID
- Registrar拿着Pledge的身份去找MASA
- MASA验证通过后签发Voucher
- Registrar把Voucher交给Pledge，信任建立完成
之后的事情就简单了——Pledge和Registrar之间走EST协议，完成证书申请和安装，设备正式入网。
4.6 避坑指南
我做了几年BRSKI落地，踩过不少坑。挑几个典型的说说：
- IDevID证书链不完整：有些厂商只给设备装了叶子证书，没装中间CA。Registrar验证时证书链断裂。解决方案是要求厂商提供完整的证书链，或者在Registrar侧预置中间CA证书。
- Voucher过期时间太短：默认的Voucher有效期是24小时。如果Pledge和Registrar之间的网络不稳定，或者MASA响应慢，Voucher可能还没用就过期了。我建议把有效期设到72小时，同时加上重试机制。
- MASA域名解析失败：Pledge出厂时硬编码了MASA的域名，但有些网络环境DNS解析不到。解决办法是在Registrar侧配置MASA的IP地址映射，或者用代理方式访问。
重要提醒
BRSKI协议本身不加密Voucher的内容，只签名。所以Voucher在传输过程中可以被任何人读取，但无法篡改。如果你需要保护Voucher的机密性，必须在传输层使用TLS。我个人建议Registrar和MASA之间的通信强制使用mTLS，双向认证更安全。
嗯，四个组件讲完了。你可能会问：为什么BRSKI要搞这么复杂？直接让Pledge信任Registrar不行吗？
答案其实很简单——零信任。Pledge出厂时谁都不认识，Registrar也不认识Pledge。唯一的共同信任点是厂商的MASA。Voucher就是那个“信任传递”的载体。
这个设计思路，说实话，非常优雅。它把信任建立的过程从“预配置”变成了“按需验证”，这才是零接触入网该有的样子。