蓝牙学习系列（六）：BLE 配对与绑定详解
目录
配对与绑定，就是这对伙伴决定：“我们要发明一套只有我俩懂的暗语，并且把暗语本锁进各自的保险箱，以后每次见面直接拿出来用。”
这不仅仅是“加密”那么简单。这是一场精心设计的密钥诞生仪式，最终产出一套完整的“信任凭证”，让设备间的关系从“临时通话”升级为“可信密友”。
今天，我们抛开繁琐的协议细节，直击核心：在最新的LE Secure Connections（安全连接）模式下，那些关键的密钥（TK, STK, LTK, IRK, CSRK）是如何一步步诞生、使用和存档的？
（在现实生活中，我们可能会把“配对”和“绑定”混淆使用，当然几乎也没有只配对而不绑定的情况，所以可以将两者视为一个整体概念：一旦配对成功，就默认会绑定，即双方会保存彼此的长期密钥，后续重连时自动恢复加密链路。这种约定俗成的用法对普通用户来说更易理解，但在技术文档或代码实现中，我们仍需明确区分这两个阶段——配对是密钥协商过程，绑定是密钥存储行为。）
一、 核心密钥家族：
在深入流程前，我们先认识一下即将登场的“密钥家族”成员。它们各有使命，生命周期也不同。
|
密钥名称 |
全称 |
核心使命 |
生命周期 |
比喻 |
|---|---|---|---|---|
|
TK |
Temporary Key |
在传统配对中，作为生成STK的“种子”。在安全连接中已不再需要。 |
仅用于一次配对过程 |
一次性口令 |
|
STK |
Short Term Key |
在传统配对中，用于立即加密本次连接，并保护LTK的传输。 |
加密单次连接 |
本次聊天的临时密码 |
|
LTK |
Long Term Key |
加密之王。用于对未来所有的连接进行加密和解密。是绑定的核心。 |
永久（除非被删除） |
长期通行证/保险箱钥匙 |
|
IRK |
Identity Resolving Key |
隐私守护者。用于解析对方不断变化的私有地址，从而在茫茫设备中认出“老朋友”。 |
永久 |
接头暗号/身份识别码 |
|
CSRK |
Connection Signature |
防伪印章。用于对无连接的数据（如广播数据）进行签名，确保数据来源可信且未被篡改。 |
永久 |
个人私章/数字签名 |
关键进化：在蓝牙4.2引入的 LE Secure Connections（LESC） 模式中，流程被大幅简化并强化。TK和STK已经退出历史舞台，LTK的生成方式变得无比安全。下文我们将完全聚焦于这种现代、安全的配对方式。
二、 配对仪式全景
下图完整描绘了LE Secure Connections模式下，配对与绑定的核心三幕剧。请跟随图2-1，看LTK、IRK、CSRK等密钥是如何一步步诞生的：
图2-1给出的是蓝牙4.2以后的LE Secure Connections ，对于以前的Legacy Pairing，主要存在如图2-2所示区别（上图2-1的第二阶段有所差异）：
Legacy Pairing会根据模式just work、passkey entry、out of band三种关联模型来确认TK（临时密钥）。然后确认STK、LTK等。
- Legacy模式：关联模型 → TK → STK → 加密 → LTK传输
- LESC模式：ECDH交换 → DHKey → 关联模型认证 → LTK生成（不传输）
2.1：规则协商
为安全定下基调。双方设备交换“安全能力清单”，关键声明两点：
- 我们都支持最新的LE Secure Connections（LESC）。
- 我们有什么交互能力？（有屏幕可显示数字吗？有键盘可输入吗？）这决定了使用“数字比较”还是“密码输入”进行用户认证等。
协商结果：确定使用数字比较（双方都有屏幕）或密码输入（一方有屏，一方有键盘）模型。这两种模型都具备防御“中间人攻击”的能力。如下图3-1、3-2所示。
2.2：核心密钥LTK的诞生
2.2.1 LE Secure Connections
LESC 模式下 LTK 的生成是一场精妙的密码学仪式，其核心是 “不传输秘密而共享秘密”。
- 起点是数学难题：流程始于椭圆曲线迪菲-赫尔曼 密钥交换。双方交换可公开的公钥，利用各自绝密的私钥，在本地计算出相同的 DHKey。DHKey 的安全性基于离散对数问题的数学难题，即使全程窃听也无法破解。
- LTK 是“衍生品”：认证通过后，LTK 由双方设备在本地，利用 DHKey、各自的蓝牙地址和随机数等参数独立派生而来。由于 DHKey 相同，双方计算出的 LTK 也必然相同。
- 最大的安全优势：LTK 及其种子 DHKey 自始至终都只存在于设备的内存中，从未以任何形式在无线链路中出现或传输过。这从根本上杜绝了被动窃听获取 LTK 的可能性，实现了“前向安全”。
简单比喻：两个人利用公开的数学规则（ECDH），各自在脑中算出了一把相同的数字钥匙（LTK）。他们从未通过任何可能被窃听的渠道（包括加密的信使）传递过这把钥匙或制造它的核心原料。
2.2.2 Legacy Pairing
Legacy 模式生成 LTK 的过程更像一个多层的、依赖临时秘密的“接力”过程，其安全性链条的强度取决于最弱一环。
- 起点是用户交互：流程始于关联模型的协商。双方根据 IO 能力确定使用
Just Works、Passkey Entry或OOB中的一种。 - 生成临时密钥：根据选定的模型，确定一个 临时密钥 的值：
Just Works: TK = 0Passkey Entry: TK = 用户输入的6位数字OOB: TK = 从带外通道获取的数据
- 生成短期密钥：双方交换随机数，并利用 TK 生成一个短期密钥。STK 的强度直接受 TK 的强度和随机性影响（
Just Works模式下 TK=0，安全性最弱）。 - 加密并传输LTK：使用 STK 对当前连接进行首次加密。然后，从设备生成 LTK 以及与之绑定的
EDIV和Rand，通过这条已被 STK 加密的链路，将 LTK 发送给主设备。主设备存储(LTK, EDIV, Rand)。 - 关键的安全短板：LTK 的保密性完全依赖于 STK 加密链路的安全性，而 STK 又源于可能很弱（如
Just Works）或较短（6位数字）的 TK。此外，LTK 本身需要在空中传输，存在理论上的风险。
简单比喻：两人先公开约定一个简单的临时暗号（TK），用这个暗号加密一个稍复杂的密码本（STK）互相确认，然后用这个密码本加密真正的保险箱钥匙（LTK），再把钥匙寄给对方。如果临时暗号被猜出或破解，整个安全链条就会崩塌。
2.3：信任加深与存档——从配对到绑定
加密通道建立后，双方可以安全地交换更多“信任凭证”，并完成绑定的最后一步。
- 分发IRK与CSRK：在加密的保护下，双方可以选择性地将自己的IRK和CSRK发送给对方。
- IRK：相当于“我的身份伪装规则”。你有了它，下次我即使用变化的私有地址广播，你也能认出我。
- CSRK：相当于“我的签名私章”。你有了它，我后续发送的签名广播数据，你可以验证其真伪。（少见使用CSRK）
- 永久存档——绑定：双方将本次配对产生的所有长期密钥（LTK、IRK、CSRK）以及对方的身份地址，一起安全地存储到设备的Flash等非易失性存储器中。
- 仪式完成：至此，绑定状态达成。两个设备之间建立了持久的信任关系。
三、安全通信的实战
理论上的“规则协商”在空中化作了两个实实在在的数据包：Pairing Request 与 Pairing Response。它们的结构完全相同，包含了一份决定后续所有流程的“安全能力清单”。我们通过实战抓包来解读这份清单。如下图3-1、3-2所示。
3.1 Pairing Request
图3-1展示了BLE配对流程中 “第一幕：规则协商” 的实例。主设备（通常是手机或电脑）通过这个 Pairing Request数据包，向外围设备发出了一份详尽的 “安全合作意向书”。以下是蓝牙安全管理协议中 Pairing Request 数据包的完整字段解读表格。该数据包定义了后续配对流程的全部安全规则。
|
字段层级 |
字段名称 |
原始值 |
二进制/具体值 |
含义与影响 |
|---|---|---|---|---|
|
顶层协议 |
Protocol |
- |
Bluetooth Security Manager Protocol (SMP) |
此数据包属于安全管理协议，用于处理配对与加密。 |
|
指令码 |
Opcode |
0x01 |
Pairing Request |
此为配对流程的起始指令，由发起方（主设备）发出。 |
|
设备能力 |
IO Capability |
0x04 |
Keyboard, Display |
发起设备同时具备键盘（可输入）和显示器（可显示）。这是协商认证方式（如密码输入、数字比较）的关键依据。 |
|
带外认证 |
OOB Data Flags |
0x00 |
OOB Auth. Data Not Present |
不使用蓝牙以外的通道（如NFC）交换认证信息。所有流程将在蓝牙链路上完成。 |
|
认证要求 |
AuthReq (整体) |
0x05 |
|
安全需求的位图总览，详细分解见下方。 |
|
^^ |
^^ - Reserved |
- |
|
保留位，必须为0。 |
|
^^ |
^^ - CT2 Flag |
- |
|
不支持蓝牙5.2的“面向连接的通道映射更新”特性。连接稳定性可能使用传统机制。 |
|
^^ |
^^ - Keypress Flag |
- |
|
在“密码输入”认证过程中，不需要在用户每次按键时提供实时反馈。 |
|
^^ |
^^ - Secure Connection (SC) Flag |
- |
|
核心安全模式： |
|
^^ |
^^ - MITM Flag |
- |
|
必须防御中间人攻击。这将强制要求后续使用需要用户交互的认证方式（如输入密码），而不能自动完成（ |
|
^^ |
^^ - Bonding Flags |
- |
|
请求建立长期绑定。配对成功后，双方将存储密钥，以便未来快速安全重连。 |
|
加密强度 |
Max Encryption Key Size |
16 |
16字节 (128位) |
支持的标准AES-CCM加密密钥最大长度，提供了当前通用的强加密强度。 |
|
密钥分发 (发起方) |
Initiator Key Distribution (整体) |
0x07 |
|
发起方希望分发和接收的密钥类型。 |
|
^^ |
^^ - Reserved |
- |
|
保留位。 |
|
^^ |
^^ - Link Key |
- |
|
不交换经典蓝牙(BR/EDR)的链接密钥。这是纯BLE设备的典型设置。 |
|
^^ |
^^ - Signature Key (CSRK) |
- |
|
希望交换连接签名密钥。用于后续对数据进行签名验证。 |
|
^^ |
^^ - Id Key (IRK) |
- |
|
希望交换身份解析密钥。这是实现隐私保护（可解析私有地址）的关键。 |
|
^^ |
^^ - Encryption Key (LTK) |
- |
|
希望交换长期加密密钥。这是绑定的核心，用于加密所有未来的连接。 |
|
密钥分发 (响应方) |
Responder Key Distribution (整体) |
0x07 |
|
发起方希望响应方分发和接收的密钥类型。此处与 |
|
^^ |
^^ - Reserved |
- |
|
保留位。 |
|
^^ |
^^ - Link Key |
- |
|
不交换经典蓝牙链接密钥。 |
|
^^ |
^^ - Signature Key (CSRK) |
- |
|
希望响应方交换CSRK。 |
|
^^ |
^^ - Id Key (IRK) |
- |
|
希望响应方交换IRK。 |
|
^^ |
^^ - Encryption Key (LTK) |
- |
|
希望响应方交换LTK。 |
3.2 Pairing Response
同表格3-1字段，后续会取交集对这两份清单进行“取交集”运算，并遵循“就高不就低”的安全原则，生成一套双方都同意的最终配对参数。在此不赘述，后续章节会讲解。
四、绑定的价值：秒连的奥秘
绑定的魔力，在设备第二次及以后的重逢中展现得淋漓尽致。它让用户从繁琐的确认中解放，真正实现“开盖即连、拿起就用”的无感体验。在实际工程中，实现“秒连”主要有两种技术路径，它们的核心都是利用绑定阶段存储的长期密钥（LTK） 和对方身份信息，区别在于重连时如何建立连接。
4.1 两种重连方式对比
| 对比项 | 定向广播方式 | IRK + RPA 方式 |
|---|---|---|
| 从设备广播类型 | 定向广播（ADV_DIRECT_IND），广播包中明确指定主设备身份地址 | 普通可连接广播（ADV_IND），使用由本地 IRK 生成的 RPA 地址 |
| 主设备识别方式 | 扫描到定向广播，发现目标地址为自己，立即响应 | 扫描到广播地址，用存储的从设备 IRK 解析，确认身份 |
| 是否需要 IRK | 从设备无需 IRK 参与，只需存储主设备身份地址 | 双方必须交换 IRK，用于解析对方的 RPA |
| 隐私保护能力 | 主设备地址固定（或静态），可能被追踪 | 从设备使用 RPA，地址周期性变化，保护隐私 |
| 典型应用场景 | 遥控器、耳机（主设备为电视/手机，地址相对固定） | 高端耳机、手环（注重隐私，主设备为手机） |
| 代码实现复杂度 | 低，只需保存对方地址，启动定向广播 | 较高，需实现 IRK 存储、地址解析功能 |
4.2 场景一：定向广播式秒连（无 IRK 参与）
适用场景：主设备（如电视、音箱）使用公共地址或静态随机地址，地址长期不变。
流程：
- 首次配对时，遥控器（从设备）保存了电视（主设备）的身份地址和 LTK。
- 电视关机再开机后，遥控器发起重连：
- 遥控器读取存储的电视地址，发送定向广播（ADV_DIRECT_IND），广播包中明确写着：“我是遥控器，我要找电视 ××”。
- 电视扫描到该定向广播，发现目标地址正是自己，立即响应连接请求。
- 连接建立后，电视使用之前存储的 LTK 直接发起加密（发送 LL_ENC_REQ，携带 EDIV/Rand）。
- 遥控器收到后，根据 EDIV/Rand 找到对应的 LTK 并回复，链路瞬间加密。
用户体验：电视开机后，遥控器按下按键，几乎无延迟响应。无弹窗、无配对提示。
4.3 场景二：IRK + RPA 式秒连（隐私保护）
适用场景：从设备（如耳机、手环）需要保护隐私，主设备（手机）也支持 RPA 解析。
流程：
- 首次配对时，双方交换 IRK。Airports（从设备）存储了手机的 IRK 和身份地址，手机存储了耳机的 IRK。
- Airports耳机开机重连：
- 耳机使用自己的 IRK 生成一个可解析私有地址（RPA），并以普通可连接广播（ADV_IND）形式发出。
- 手机扫描到该广播地址，用存储的耳机 IRK 进行解析。解析成功，确认“这是老朋友耳机”。
- 手机发起连接请求，连接建立后，同样使用 LTK 加密恢复。
用户体验：打开耳机盒，手机弹窗显示“已连接”，无额外操作。由于 RPA 会定时变化，耳机地址无法被持续追踪，隐私得到保护。
4.4 绑定的核心价值
无论采用哪种方式（主流的回连就是表格4-1所示），绑定的本质都是将一次性的繁琐认证（配对）转化为每次使用的无感秒连。用户不需要反复点击确认、输入 PIN 码，设备在后台自动完成身份识别和加密恢复。
总结：
- 如果你的产品主设备地址固定（如电视、音箱），定向广播方案最简单可靠，无需 IRK 参与。
- 如果你的产品注重隐私（如耳机、手环），IRK + RPA 方案是规范推荐的方式，但需要实现地址解析功能。
- 无论哪种方案，LTK 的存储与匹配是加密恢复的核心，是绑定价值的根本体现。
通过绑定，技术真正隐于无形，为用户带来“开盖即连、拿起就用”的极致体验。
五、 给开发者的密钥备忘录
理解这些密钥，是诊断安全相关问题和优化用户体验的关键。
|
遇到的现象或问题 |
可能相关的密钥 |
排查思路 |
|---|---|---|
|
每次重连都需要重新配对确认 |
LTK未成功绑定 |
检查设备端是否成功将LTK存储到永久存储器，以及存储后是否被正确检索使用。 |
|
手机找不到已配对的设备（设备在广播） |
IRK |
设备可能使用了私有地址广播，但手机的IRK丢失或无法解析。检查绑定信息是否被意外删除。 |
|
连接被意外加密，但并非期望的配对设备 |
LTK混淆 |
多个设备间LTK存储混乱，或使用了默认密钥。确保密钥与设备身份严格绑定。 |
|
希望实现“快速配对”或“一键连接” |
绑定状态 |
确保完整走完配对流程并存储所有密钥（LTK, IRK）。这是实现快速重连的基础。 |
六、总结
从公钥交换的数学魔法，到LTK的安全本地生成，再到IRK、CSRK的加密分发，现代BLE配对绑定过程是一套优雅而坚固的安全体系。它不再依赖脆弱的临时口令传递，而是基于“即便公开所有通信，也无法推导出密钥”的密码学原理。
对于开发者而言，掌握这套“密钥诞生记”意味着：
- 能精准定位：当出现连接、配对或加密问题时，能快速判断是哪个环节、哪种密钥出了问题。
- 能正确设计：为产品选择恰当的安全模型（如数字比较），并确保绑定逻辑可靠。
- 能优化体验：充分利用绑定机制，为用户实现“开盒即连”的无感安全体验。
配对与绑定，是BLE设备从“认识”走向“信任”的桥梁。架好这座桥，你的产品才能赢得用户长久的信赖。
由于个人水平有限，文中若有任何疏漏或表述不清之处，欢迎在评论区指正与交流。
后续更新预告：我将持续更新ble系列的技术科普，下一篇计划《BLE GATT 数据模型详解》。如果本文对你有帮助，欢迎点赞、收藏、关注，这是对我最大的鼓励！
📚 蓝牙学习系列专栏
本系列是系统性的蓝牙低功耗(BLE)技术教程，从协议栈原理到实战开发，适合嵌入式开发者、物联网工程师和所有对蓝牙技术感兴趣的读者。
🎯 **系列导航**：本文是《蓝牙学习系列》第6篇
🔗 **完整专栏**： 蓝牙学习系列专栏
智能硬件社区聚焦AI智能硬件技术生态，汇聚嵌入式AI、物联网硬件开发者，打造交流分享平台，同步全国赛事资讯、开展 OPC 核心人才招募，助力技术落地与开发者成长。
更多推荐
29
0- 0
已为社区贡献7条内容
所有评论(0)