4. 链路管理层：链路管理协议（LMP）、配对与鉴权、加密与安全机制
好，咱们进入第四章节。链路管理层，这个名字听起来有点抽象，但说白了，它就是蓝牙设备之间「握手」和「上锁」的那个环节。
你想想看，两个蓝牙设备要通信，总不能上来就噼里啪啦传数据吧？总得先打个招呼，确认一下对方是谁，能不能信得过，然后商量好怎么加密，对吧？这些脏活累活，就是链路管理层干的。
我个人习惯把这一层看作是蓝牙协议栈的「外交官」和「保安队长」。它既要负责建立和维护连接（外交），又要负责安全认证和加密（安保）。今天咱们就把它拆开揉碎了讲清楚。
4.1 链路管理协议（LMP）—— 蓝牙的「外交语言」
LMP，全称 Link Manager Protocol。它不传你的音频数据，它只传控制信令。
我在做 Soundbar 项目时，经常需要抓空中的 HCI log 来分析问题。你会发现，在真正的音频流开始之前，主机和从机之间会有一大堆 LMP 报文在飞来飞去。这些报文就是设备在「谈判」。
LMP 主要干这几件事：
- 连接建立与释放：发起连接、接受连接、断开连接。就像你打电话，先拨号，对方接听，最后挂断。
- 角色切换：主从角色互换。比如你的手机是主设备，Soundbar 是从设备。在某些场景下，它们可以商量着互换一下角色。
- 时钟与定时器同步：蓝牙是时分复用的，大家得对表。LMP 负责同步双方的蓝牙时钟。
- 链路质量控制：比如调整发射功率、切换跳频序列。信号不好时，LMP 会尝试优化。
- 安全相关：配对、鉴权、加密的发起和协商，也是通过 LMP 完成的。
核心要点： LMP 报文是直接在 ACL 链路上传输的，优先级很高。它不经过 L2CAP，所以你看 L2CAP 的 log 是看不到 LMP 报文的。这一点很多新手会搞混。
举个例子，一个典型的 LMP 连接建立流程大致是这样的：
// 伪代码示意，不是真实代码
// 寻呼方（Paging）发起连接
LMP_host_connection_req (paging)
// 被寻呼方（Page Scan）响应
LMP_accepted (response)
// 交换一些基本信息
LMP_clk_off (clock offset)
LMP_setup_complete (setup done)
// 连接建立成功，进入连接状态
嗯，这里要注意，LMP 的报文格式非常紧凑，每个字节都有讲究。如果你在做底层驱动开发，一定要啃一下 Core Spec 的 Volume 2, Part C。
4.2 配对与鉴权 —— 确认过眼神，你是对的人
配对和鉴权，这两个词经常被混用，但它们是两码事。
- 配对（Pairing）：是建立共享密钥的过程。相当于两个人互相交换了暗号。
- 鉴权（Authentication）：是验证对方是否知道这个密钥的过程。相当于对暗号。
配对不成功，鉴权肯定失败。但配对成功了，每次连接时也可以选择不鉴权（虽然不安全）。
蓝牙的配对方式，经历了几个阶段。在 Soundbar 这种音频设备上，我们最常遇到的是 Legacy Pairing 和 Secure Simple Pairing (SSP)。
4.2.1 Legacy Pairing（传统配对）
这是蓝牙 2.0/2.1 时代的产物。它使用一个固定的 PIN 码（通常是 0000 或 1234）来生成初始密钥。
我曾经调试过一个老款 Soundbar，死活连不上新手机。查了半天，发现是 Soundbar 固件里写死了 Legacy Pairing，而手机默认只支持 SSP。这就是兼容性问题。
避坑指南： Legacy Pairing 的安全性极差。因为 PIN 码太短，很容易被暴力破解。现在的蓝牙规范已经不建议使用了。如果你的产品还在用 Legacy Pairing，赶紧升级吧。
4.2.2 Secure Simple Pairing (SSP) —— 安全简单配对
从蓝牙 2.1 + EDR 开始引入，现在是主流。SSP 有四种关联模型（Association Models），决定了配对时的用户交互方式：
| 模型 | 交互方式 | 典型场景 |
|---|---|---|
| Numeric Comparison | 两边显示一个6位数字，用户确认是否一致 | 手机连手机、手机连电脑 |
| Just Works | 无用户交互，自动配对 | Soundbar 连手机（最常见） |
| Passkey Entry | 一方显示数字，另一方输入 | 蓝牙键盘、蓝牙耳机 |
| Out of Band (OOB) | 通过 NFC 等外部方式交换信息 | NFC 触碰配对 |
对于 Soundbar 来说，绝大多数场景都是 Just Works。用户按下配对键，手机搜到设备，点一下就连上了。整个过程没有数字确认，也没有密码输入。
为什么会这样？因为 Soundbar 没有屏幕，没法显示数字。Just Works 虽然方便，但它的安全性其实是最低的。因为它无法防止中间人攻击（MITM）。
我的建议： 如果你的 Soundbar 有简单的 LED 或数码管，可以考虑用 Passkey Entry 或 Numeric Comparison。虽然用户体验稍微复杂一点，但安全性提升了一个档次。尤其是现在蓝牙支付、门锁等场景越来越多，安全无小事。
4.3 加密与安全机制 —— 给你的数据流加把锁
配对和鉴权搞定了，接下来就是加密。加密的目的是保证数据在空中传输时，即使被截获，也无法被解读。
蓝牙的加密机制，核心是 E0 流密码（传统）和 AES-CCM（蓝牙 4.0+ 的 LE 和 BR/EDR 安全连接）。
4.3.1 加密密钥的生成
加密不是直接用配对时生成的密钥。而是用那个密钥作为基础，再通过一系列算法，生成一个临时的加密密钥（Encryption Key）。
这个过程叫 加密密钥生成。它引入了随机数，确保每次连接时生成的加密密钥都不同。即使这次连接的密钥泄露了，下一次连接也是安全的。这叫「前向安全性」。
4.3.2 加密模式
蓝牙支持两种加密模式：
- 加密模式 1：只加密广播信道的数据包。这个很少用。
- 加密模式 2：加密所有面向连接的数据包（ACL 和 SCO/eSCO）。这是 Soundbar 最常用的模式。你的音频数据，在加密模式下，都是密文传输的。
4.3.3 安全连接（Secure Connections）
从蓝牙 4.2 开始，引入了 Secure Connections（SC）。它使用 ECDH（椭圆曲线迪菲-赫尔曼）密钥交换算法，取代了传统的 DH 算法。
SC 的好处是：
- 更强的密钥强度：使用 128 位 AES 加密，而不是传统的 64 位或 128 位 E0。
- 更强的抗破解能力：ECDH 的安全性远高于传统 DH。
- 简化了配对流程：在 SC 模式下，Just Works 也能提供一定程度的 MITM 保护（虽然还是不如 Numeric Comparison）。
重要提醒： 如果你的 Soundbar 芯片支持蓝牙 4.2 或更高版本，请务必开启 Secure Connections。这不仅是性能提升，更是安全底线。我在一个项目中遇到过客户要求必须支持 SC，否则不通过验收。所以，别偷懒。
4.4 实战中的坑与经验
最后，分享几个我在 Soundbar 项目中踩过的坑：
- 配对失败后重连慢：有些 Soundbar 在配对失败后，会进入一个很长的超时等待。用户体验极差。我当时的解决方案是：在固件中增加一个「快速重试」机制，如果第一次配对失败，立即重置链路层状态机，允许用户马上再次尝试。
- 加密导致音频卡顿：加密和解密需要计算资源。如果芯片的算力不够，或者加密算法实现得不好，会导致音频数据包处理延迟，从而产生卡顿或爆音。我曾经遇到过，开启加密后，A2DP 的 latency 从 100ms 飙升到 300ms。最后通过优化加密引擎的 DMA 传输才解决。
- Just Works 配对的安全隐患：虽然 Just Works 方便，但在某些场景下（比如会议室），恶意设备可以伪装成 Soundbar 进行中间人攻击。我建议在 Soundbar 的 App 中增加一个「安全配对模式」的开关，让用户可以选择使用 Numeric Comparison 或 Passkey Entry。
好了，链路管理层的内容就讲到这里。这一层虽然不直接处理音频数据，但它是整个蓝牙连接的基石。搞懂了 LMP、配对和加密，你才能理解为什么你的 Soundbar 有时候连不上、有时候卡顿、有时候不安全。
下一章，咱们聊聊 L2CAP 层，看看音频数据是怎么被封装和分段的。