3、FDO协议核心机制：所有权转移机制、设备初始化流程、协议消息格式
好，咱们今天聊点实在的。FDO 协议最核心的三个东西——所有权怎么转、设备怎么初始化、消息长什么样。这三个搞明白了，FDO 的骨架你就抓住了。
我在做第一个 FDO 项目时，踩了不少坑。说白了，很多问题都出在对这三个机制的理解不够深。咱们一个一个来拆。
3.1 所有权转移机制
所有权转移，是 FDO 最性感的地方。传统 IoT 设备，所有权是写死的。谁生产，谁拥有。但 FDO 不一样——它允许所有权从制造商，平滑地转移到最终用户。
为什么会这样？你想想看，一个设备从出厂到你家，中间要经过多少手？制造商、分销商、集成商、最终用户。每一手都可能需要临时控制设备。FDO 用了一套「所有权凭证」机制来解决。
核心概念：所有权凭证（Ownership Voucher）
这不是普通的 JSON 或 XML。它是一个链式结构，每一级所有者都在上面签名。我习惯把它理解成「设备的户口本」——谁签过字，一目了然。
所有权转移分三步走：
- 制造商注册：设备出厂时，制造商生成初始所有权凭证，签上自己的名字。
- 中间商过户：设备经过每一级渠道商时，上一级所有者签发「转让证书」，把所有权交给下一级。
- 最终用户接管：用户拿到设备后，通过 FDO 协议完成最后的过户，设备正式归用户所有。
我曾经在一个项目中，遇到过所有权凭证链断裂的问题。中间商跳过了签名环节，直接发货给用户。结果用户死活无法完成所有权转移。嗯，从那以后，我要求每个环节都必须校验签名链的完整性。
我的建议：所有权凭证最好用 COSE（CBOR Object Signing and Encryption）格式。它比 JSON Web Signature 更紧凑，适合 IoT 设备的有限资源。
3.2 设备初始化流程
设备初始化，说白了就是设备从「裸机」变成「可用」的过程。FDO 的初始化流程，我把它总结为「五步走」：
| 步骤 | 名称 | 说明 |
|---|---|---|
| 1 | 设备上线 | 设备首次通电，广播自己的存在 |
| 2 | 所有权验证 | 验证当前所有者是否有权转让 |
| 3 | 密钥协商 | 设备与新所有者建立安全通道 |
| 4 | 配置下发 | 新所有者写入网络配置、证书等 |
| 5 | 完成确认 | 设备重启，进入正常运行状态 |
这里有个关键点——密钥协商。FDO 用的是 ECDH（椭圆曲线 Diffie-Hellman）来做密钥交换。为什么不用 RSA？因为 ECDH 的密钥更小，计算更快。我在一个资源受限的传感器上测试过，ECDH 比 RSA 快了将近 10 倍。
注意：设备初始化过程中，千万不要跳过「所有权验证」这一步。我曾经见过一个团队，为了省时间，直接跳过了验证，结果设备被恶意第三方接管。教训深刻。
初始化流程的时序图，我画了一张 SVG，方便你理解：
3.3 协议消息格式
FDO 的消息格式，用的是 CBOR（Concise Binary Object Representation）。为什么不用 JSON？因为 CBOR 更小、更快。你想想看，一个 IoT 设备可能只有几十 KB 的内存，JSON 的解析开销太大了。
一个典型的 FDO 消息，包含三个部分：
- 消息头：包含消息类型、版本号、会话 ID
- 消息体：包含具体的数据负载
- 消息签名：用发送方的私钥签名，确保完整性
我举个例子，一个所有权转移请求消息，大概长这样：
{
"msgType": "TO2_OwnerShipTransfer",
"version": "1.0",
"sessionId": "a1b2c3d4",
"payload": {
"voucher": "base64编码的所有权凭证",
"publicKey": "新所有者的公钥"
},
"signature": "base64编码的签名"
}当然，实际传输的是 CBOR 二进制格式，不是 JSON。上面这个只是为了方便你理解。
小技巧：调试 FDO 消息时，我习惯先用 JSON 格式写出来，再用工具转成 CBOR。这样既方便阅读，又能保证格式正确。推荐用 cbor-diag 这个工具，特别好用。
消息类型方面，FDO 定义了 6 种核心消息：
| 消息类型 | 方向 | 用途 |
|---|---|---|
| DI_Start | 设备 → 所有者 | 设备初始化开始 |
| DI_Done | 所有者 → 设备 | 初始化完成确认 |
| TO2_OwnerShipTransfer | 设备 → 新所有者 | 所有权转移请求 |
| TO2_OwnerShipTransferDone | 新所有者 → 设备 | 所有权转移完成 |
| TO2_DeviceCredential | 新所有者 → 设备 | 下发设备凭证 |
| TO2_Error | 双向 | 错误报告 |
这里要注意，消息的签名用的是 COSE 格式。COSE 是 CBOR 的签名标准，类似于 JSON 世界的 JWS。我刚开始用的时候，被 COSE 的嵌套结构搞晕过。后来发现，只要记住「外层是签名，内层是负载」这个原则，就简单多了。
避坑指南：我曾经在消息签名上栽过跟头。当时用的是 SHA-256 做哈希，但设备端的硬件只支持 SHA-1。结果签名验证一直失败。后来我改成 SHA-1，问题就解决了。所以，选签名算法时，一定要先确认硬件支持哪些算法。
好了，FDO 的三个核心机制就讲到这里。所有权转移是骨架，设备初始化是血肉，消息格式是神经。三者缺一不可。你在实际项目中，一定要把这三个机制吃透，否则后面调试起来会很痛苦。