3、配对阶段一：特征交换与IO能力
好，咱们进入配对流程的第一个阶段。说白了，这个阶段就是两个蓝牙设备在互相“摸底”——你支持什么？你能干什么？咱们得先搞清楚这些，才能决定后面怎么加密、怎么认证。
我个人习惯把这个阶段叫做“握手前的自我介绍”。两个设备刚建立连接，还不知道对方深浅，得先交换一下各自的能力信息。嗯，这里要注意，这个阶段是明文传输的，没有任何加密保护。所以别在这个阶段传什么敏感数据，它就是个信息交换。
3.1 特征交换到底交换了什么？
特征交换，英文叫 Feature Exchange。两个设备会互相发送一个叫“配对请求”和“配对响应”的包。里面主要包含三样东西：
- IO能力：设备有没有屏幕？有没有键盘？能不能显示数字？
- OOB数据标志：是否支持带外传输（比如用NFC交换密钥）
- 认证需求：要不要绑定？要不要防中间人攻击？
我刚开始做蓝牙开发时，以为这个阶段就是走个过场。后来有一次，两个设备明明都支持加密，但配对就是失败。查了半天，发现是IO能力配置错了，导致双方无法协商出合适的配对方式。从那以后，我再也不敢小看这个阶段了。
3.2 IO能力——决定配对方式的关键
IO能力，说白了就是你的设备怎么跟人交互。蓝牙规范里定义了这么几种：
| IO能力 | 显示能力 | 输入能力 | 典型设备 |
|---|---|---|---|
| DisplayOnly | 有 | 无 | 蓝牙音箱、显示器 |
| DisplayYesNo | 有 | 是/否 | 手机、平板 |
| KeyboardOnly | 无 | 有 | 键盘、遥控器 |
| NoInputNoOutput | 无 | 无 | 传感器、灯泡 |
| KeyboardDisplay | 有 | 有 | 电脑、高端门锁 |
你想想看，一个灯泡（NoInputNoOutput）和一个手机（DisplayYesNo）配对，它们能怎么认证？灯泡没法显示数字，也没法输入密码。所以只能走 Just Works 方式——说白了就是“信任式配对”，没有用户交互，安全性最低。
核心原则：IO能力决定了配对阶段二（认证阶段）能使用哪种配对方式。如果双方IO能力组合不支持某种配对方式，就会降级到 Just Works。
3.3 认证需求——你要多安全？
除了IO能力，特征交换里还有一个关键字段：认证需求。它是个位掩码，包含以下标志：
- bonding 标志：要不要绑定？绑定后下次连接不用重新配对。
- MITM 保护标志：要不要防中间人攻击？如果设为1，配对过程必须能抵抗MITM。
- Secure Connections 标志：是否强制使用LE Secure Connections？
- Keypress 通知标志：按键时是否通知对方？
- CT2 标志：是否支持CT2算法？
我记得有一次做智能门锁项目，客户要求必须防MITM。但门锁是NoInputNoOutput，手机是DisplayYesNo。按规范，这种组合只能走Just Works，根本防不了MITM。最后没办法，只能在门锁上加了个物理按键，把IO能力改成了DisplayYesNo，才满足了需求。
避坑指南：我曾经遇到一个坑——两个设备都支持MITM保护，但配对时还是走了Just Works。查了半天，发现是其中一方的IO能力配置成了NoInputNoOutput。记住：MITM保护需要双方都有一定的IO能力，否则无法实现。
3.4 OOB数据——另一种选择
OOB（Out Of Band）数据标志，表示设备是否支持通过其他通道交换配对信息。比如用NFC、二维码等方式。如果双方都支持OOB，就可以绕过IO能力的限制，实现更安全的配对。
我个人觉得OOB是个被低估的功能。很多开发者觉得麻烦，不愿意实现。但你想，如果两个设备都是NoInputNoOutput，又想防MITM，OOB几乎是唯一的选择。
3.5 特征交换的完整流程
好，咱们把整个流程串起来看看：
- 发起方发送 Pairing Request，包含自己的IO能力、OOB标志、认证需求。
- 接收方收到后，检查自己的能力和需求，决定是否接受配对。
- 接收方发送 Pairing Response，包含自己的IO能力、OOB标志、认证需求。
- 双方根据对方的IO能力和认证需求，协商出配对方式（Just Works、Passkey Entry、Numeric Comparison、OOB）。
- 如果协商失败（比如双方都不支持任何共同的配对方式），配对终止。
这里有个细节：配对请求和响应里还包含一个叫“最大加密密钥大小”的字段。我记得有一次，一个设备只支持7字节的密钥，另一个支持16字节。结果协商后用了7字节，安全性大打折扣。所以，如果你的设备对安全性有要求，记得检查这个字段。
3.6 实际项目中的经验
最后，分享几个我在项目中踩过的坑：
- IO能力别乱配：有些开发者图省事，把所有设备都配成NoInputNoOutput。结果所有配对都走了Just Works，安全性堪忧。
- MITM标志要谨慎：如果你设了MITM标志，但IO能力不支持，配对会失败。我见过不少这样的bug。
- OOB是个好选择：如果你的设备有NFC或二维码扫描功能，建议实现OOB。它能提供更高的安全性，而且用户体验也好。
- 测试要全面：不同IO能力的组合都要测一遍。我吃过亏，只测了手机对手机，结果手机对手环时出了问题。
小技巧：调试配对问题时，可以用蓝牙抓包工具（比如Ellisys或Frontline）看看Pairing Request和Response里的字段。很多时候，问题就出在IO能力或认证需求的配置上。
好了，特征交换阶段就讲到这里。下一章咱们进入配对阶段二——认证阶段，看看IO能力到底怎么影响配对方式的选择。到时候我会详细讲Just Works、Passkey Entry、Numeric Comparison这三种方式的具体实现。