BRSKI 协议详解：架构、角色与核心流程

好，咱们进入正题。BRSKI 这个名字你可能听过，全称是 Bootstrapping Remote Secure Key Infrastructure。说白了，就是解决「设备第一次上电，怎么安全地拿到身份证书」这个问题。我最早接触它是在一个大型园区网项目里，几百台 AP 要批量上线，传统的手工配置方式简直要命。BRSKI 就是为这种场景设计的。

BRSKI 架构：谁跟谁说话

先看整体架构。BRSKI 不是一个单点协议，它定义了三个角色之间的交互。我习惯把这张图记在脑子里，排查问题时特别有用。

这张图我画了好几次才满意。三个角色之间的箭头方向，代表了信任关系的流向。你仔细看，Pledge 和 Registrar 之间是双向的，但 Registrar 和 MASA 之间也是双向的。嗯，这里要注意，MASA 是云端的，Registrar 通常是本地网络中的控制器。

三个角色，各司其职

Pledge：新来的「小白」设备

Pledge 就是那个刚出厂的、还没任何网络身份的设备。它只知道自己是谁——准确地说，它知道自己有一个由制造商颁发的 IDevID（初始设备标识证书）。这个证书是烧在硬件里的，不可篡改。

我在项目中遇到过一种情况：某厂商的设备 IDevID 证书过期了，导致 BRSKI 流程卡在第一步。排查了半天才发现是证书有效期问题。所以，采购设备时一定要确认 IDevID 的有效期，别等部署时才发现。

Registrar：网络中的「管家」

Registrar 是 Pledge 要投靠的对象。它通常运行在网络控制器或交换机上。它的职责是：

• 发现与响应：监听 Pledge 的加入请求
• 代理 Voucher 请求：替 Pledge 向 MASA 要授权凭证
• 代理证书注册：帮 Pledge 向 PKI 申请运营证书（LDevID）

说白了，Registrar 就是个中间人。但它不是简单的传话筒——它要验证 Pledge 的身份，还要决定是否允许这个设备加入网络。我个人的习惯是，在生产环境中把 Registrar 和 CA 分开部署，避免单点故障。

MASA：制造商那边的「公证人」

MASA 全称是 Manufacturer Authorized Signing Authority。它是设备制造商运营的一个云服务。它的核心能力只有两个：

1. 签发 Voucher：证明「这个 Pledge 确实是本厂生产的，并且允许它加入指定的网络」
2. 审计日志：记录谁、什么时候、为哪个设备签发了 Voucher

你想想看，如果没有 MASA，任何一台设备都可以声称自己是合法的。MASA 就是那个「验明正身」的环节。我曾经调试过一个跨厂商互通的问题——A 厂商的 Pledge 要连 B 厂商的 Registrar，结果 MASA 地址解析失败。后来发现是 Pledge 固件里硬编码的 MASA URL 写错了。

BRSKI 核心流程：Join → Voucher → Enroll

整个 BRSKI 流程可以拆成三个阶段。我习惯用「三步走」来记：先敲门（Join），再亮证（Voucher），最后办手续（Enroll）。

第一步：Join（加入）

Pledge 上电后，会通过 DHCP 或 DNS 发现本地的 Registrar。然后它发起一个 DTLS 连接——注意，不是 TLS，是 DTLS（基于 UDP 的 TLS）。为什么用 DTLS？因为有些设备资源受限，UDP 比 TCP 更轻量。

DTLS 握手时，Pledge 会把自己的 IDevID 证书发给 Registrar。Registrar 验证这个证书是否由可信的制造商 CA 签发。如果验证通过，Registrar 就知道：「嗯，这是一台正经设备。」

第二步：Voucher（凭证）

这是 BRSKI 最核心、也最容易出问题的环节。Registrar 拿到 Pledge 的 IDevID 后，需要向 MASA 请求一个 Voucher。Voucher 本质上是一个签名的 JSON 对象，里面包含：

Registrar 拿到 Voucher 后，会把它转发给 Pledge。Pledge 验证 Voucher 上的签名——它信任制造商的公钥。验证通过后，Pledge 就知道：「这个 Registrar 是 MASA 认可的，我可以信任它。」

第三步：Enroll（注册）

最后一步就相对简单了。Pledge 通过已经建立的 DTLS 安全通道，向 Registrar 发送一个 PKCS#10 证书签名请求（CSR）。Registrar 把这个 CSR 转发给企业 PKI（通常是 EST 服务器）。PKI 签发 LDevID 证书后，Registrar 再把它返回给 Pledge。

至此，Pledge 就拥有了合法的网络身份证书。它可以正常接入网络，参与 802.1X 认证、IPsec 等安全协议了。

我个人的习惯是，在 Enroll 完成后，让 Pledge 主动断开 DTLS 连接，重新用 LDevID 建立一条双向认证的安全通道。这样可以验证新证书是否工作正常。

一张表总结三个角色