蓝牙协议栈·学习笔记

gy2023-12-252026-01-31

最近因为一些原因，我开始接触到蓝牙技术的实现细节。本文是我在学习过程中，结合自己的思考所做的笔记。

本文介绍的是低功耗蓝牙（LE），和传统蓝牙在协议栈等方面存在些许不同。现在出货的智能手机、笔记本电脑等设备同时支持低功耗蓝牙和经典蓝牙，而大多数市面上能买到的蓝牙耳机只采用低功耗蓝牙（LE）方案。

蓝牙协议栈的跨度极大，涉及通信、计网、信息安全等多个领域，而且每层都很复杂，凭本人极其有限的技术水平和有限的篇幅只能讲个大概，而且不可避免会有疏漏之处，建议你参考蓝牙官方文档、专业的技术书籍、技术论坛等，他们都比我写的更详细、更准确。祝你学习顺利！

蓝牙规范文档

1 蓝牙技术简述

蓝牙，是一种短距离低功耗无线数据交换技术，工作在2.4GHz ISM频段上。请再次注意，本文介绍的是低功耗蓝牙（BLE），和传统蓝牙在协议栈等方面存在些许不同。BLE在核心规范上是向后兼容的。

2 蓝牙协议栈概述

从协议栈的结构来看，BLE可从上到下分为Host和Controller，这种分层方式提升了蓝牙的可适配性。我从网上找到一张比较清晰的图片，展示蓝牙协议栈的结构：

比较著名的Host协议栈有Bluedroid（博通、谷歌），NimBLE（Apache），BlueZ（高通）。

如果学过OSI模型的话，理解起来可能会轻松一些。我们可以把蓝牙协议栈理解成一个逐级封装或拆解数据包的流水线，在学习蓝牙协议栈中的每一层时，不妨多去关注每一层是如何把输入数据转换为输出数据的。我会在接下来的文章中从底层到顶层选择性地介绍一些对于蓝牙监听至关重要的Layer。

2.1 物理层 (Physical Layer)

物理层（Physical Layer），包含无线电层和基带层，负责在最底层发送和接收数据，具有调制、解调和纠错等基础功能。低功耗蓝牙工作在2.4GHz ISM频段上，具有40个物理信道，其中0到36为数据信道和次要广播信道，37到39为主广播信道，每个信道宽2MHz。当链路层处于广播态时，每发送一个广播包，会在三个广播信道上发送三次。

和WiFi通信类似，蓝牙在设计时考虑到安全性、抗干扰性、共存性等因素，也采用跳频技术，以1600跳/s的速率按照协商好的跳频序列进行跳频，时隙长度为625μs。因为跳频技术的存在，即使数据链路上传输的是明文，也很难被窃听者截取到完整的、有价值的信息。仅凭这一点，就能劝退很多想要尝试进行窃听的人了。（如果能够计算出跳频序列，这个问题就能缓解许多）

物理层实在是过于底层，还有非常多的实现细节，在这里省略不提。

2.2 链路层（Link Layer）

2.2.1 链路层概述

链路层负责在物理层提供的比特流（Bit Stream）传输基础上建立和管理基于帧（Frame）的连接，职责包括传输Frame和管理网络拓扑结构（形成Piconet）等。

2.2.2 BLE Frame

BLE Frame的发送遵循小端模式，即先发低位，后发高位。一个BLE Frame的结构如下：

Preamble是frame的前导，主要用于自动增益控制（AGC）和帧检测（滤除干扰信号和不良信号），长度为8bits，通常是01010101或者10101010，由Access Address的最低有效位决定。

Access Address（访问地址）长度为32bits，用于链路层通信的识别与同步。广播包具有一个特定的Access address，也就是0x8E89BED6。数据包的Access address是随机的，以确保通信的安全性。

Note：访问地址并不等同于蓝牙设备地址。

从长度上来看，访问地址长32bits，而蓝牙设备地址长6*8=48bits。

从概念上来看，蓝牙设备地址（BD_ADDR）可分为公开地址和随机地址，随机地址又分为静态随机地址和私有随机地址。其中的公开地址由IEEE进行分配，一般需要设备制造商（或蓝牙SoC制造商）向IEEE申请购买，以确保唯一性（如果一个设备同时支持WIFI和蓝牙，则常常共用同一个mac地址）。蓝牙地址结构包括NAP、UAP和LAP三部分，三者分别用于跳频同步、作为一些算法的种子和设备唯一标识。NAP和UAP的组合（也就是地址的前24位）为制造商识别码（OUI）。为了记录和辨识方便，我们通常约定蓝牙地址表示为以冒号分隔的6个16进制单字节。参考下面这张图：

Coding Indicator（CI）由报文头部和长度数据（各8bits）组成，PDU Type指的是报文类型。

下面这张表格罗列出了一些常见的广播类型，在使用Sniffer抓取广播包时会遇到：

广播类型值	广播类型名称	物理信道
`0000b`	ADV_IND 通用广播指示	Primary Advertising
`0001b`	ADV_DIRECT_IND 定向连接指示	Primary Advertising
`0010b`	ADV_NONCONN_IND 不可连接指示	Primary Advertising
`0011b`	SCAN_REQ 主动扫描请求	Primary Advertising
`0100b`	SCAN_RSP 主动扫描响应	Primary Advertising
`0101b`	CONNECT_IND 连接请求	Primary Advertising
`0110b`	ADV_SCAN_IND 可扫描指示	Primary Advertising
`0111b`	ADV_EXT_IND	Primary Advertising
`1000b`	AUX_CONNECT_RSP	Secondary Advertising
其他值	保留备用	N/A

主广播信道上的广播包PDU最大为29字节。

PDU可能会在链路层被加密，CRC的生成在PDU被加密之后才进行。当PDU和CRC准备完毕时，为了避免在比特流中出现多位连续的0或1，链路层还会利用Huffman编码对PDU和CRC进行白化处理。

2.2.3 链路类型

BLE中定义了四种数据链路：

链路类型	描述
`ACL`（Asynchronous Connectionless Link，异步链路）	在LMP level上创建两种设备之间的异步连接（分组交换），数据传输不受时钟同步的约束。蓝牙的ACL链路是Connection-less的，无需事先建立连接，适用于临时性的数据传输场景。设备加入Piconet时会默认创建一个ACL链路。
`SCO`（Synchronous Connection Oriented，面向连接的同步链路）	通常用来传输对于延时比较敏感的信息，比如语音。SCO使用保留带宽进行同步通信（电路交换），即两台设备在LMP层利用保留时隙在物理信道上周期传送数据包，保证了音频数据传输的实时性。SCO包不含CRC，且不进行重传，数据的完整、正确性就无法保障，纠错只能在上层进行，所以HFP采用的音频编解码器需要具备一定的容错能力。需要注意的是，仅仅在ACL链接已经建立之后，才可以建立SCO链接，因为SCO链接是面向连接的，要求在通信之前必须先建立连接，然后才能进行数据传输，并且在通信结束时，需要释放连接。
`eSCO`（Extended Synchronous Connection-Oriented，扩展同步面向连接逻辑传输）	蓝牙1.2引入的特性，与SCO不同的是，eSCO支持重传，以对抗干扰；并且不使用保留时隙，主设备和任何一个从设备通过以单时隙为单位建立一个ACL链接，主设备和一个从设备之间只能存在一个ACL链接。单时隙技术不需要像保留时隙那样预留固定的时隙来进行数据传输，而是动态分配单个时隙，从而更加灵活地适应不同的通信需求。
`CPB`（Connectionless Peripheral Broadcast，无连接的外设广播逻辑传输）	可以用于蓝牙信标，但是对于蓝牙监听还暂时用不到，这里不写。

2.2.4 Piconet与Scatternet组网

在低功耗蓝牙中，Piconet是指一个由一个主设备（master）和一个或多个从设备 [slave(s)] 组成的网络。主设备控制整个网络，向从设备收发数据；从设备依赖于主设备来进行同步和通信。在BLE中，与BR/EDR不同，从设备不与主设备共享相同的物理信道，每个从设备都在与主设备分开的物理信道上进行通信。

在一个Piconet中，每个从设备和主设备之间都有物理链路，但是从设备之间并不直接建立物理链路，从设备之间的通信需要依靠主设备进行中转。LE5.1不支持主从设备之间的角色交换。蓝牙核心规范要求一台LE设备某一时刻只能使用一个LE物理信道，但是时分复用技术让同一设备能够进行多个并发操作（比如，维持已连接设备的同时还能够持续发送广播）。

此外，BLE中还存在一种称为Scatternet的网络拓扑，其中一个设备可以同时担任多个Piconet的主设备和从设备的角色，从而形成更为复杂的连接结构（多对多拓扑）。Scatternet可以看做是由多个Piconet作为子集构成。

2.3 主机-控制器接口 (HCI)

2.3.1 HCI概述

HCI是一个位于主机与控制器之间的适配层（可选），向主机提供了较为统一的标准接口，便于主机的实现、控制器的切换等等，一般由Controller使用软件实现。我们在上层进行的操作，比如Characteristic的读写，这时数据就是从协议栈的上层通过HCI传递到控制器的。HCI采取COMMAND-EVENT设计模式，在AOSP平台上，HCI通过HCI_CMD和HCI_EVT进行数据流传递，其中主机通过HCI_CMD向控制器发出指令，控制器通过HCI_EVT响应主机命令。

2.3.2 HCI Command数据包

HCI Command数据包格式如下，其中Opcode是用来唯一标识不同类型命令的操作码，长度为2字节，由OpCode Group Field (OGF) 和 OpCode Command Field (OCF) 组成，其中OGF占用高6bit，OCF占用低10bit。根据OGF的值，可以将HCI commands进行分类，所以操作码的组织结构允许在不完全解码整个操作码的情况下推断出一些信息。

HCI Command数据包格式

下面是一些比较有用的HCI Command：

OCF	名称	描述
0x005	Create Connection	建立连接。附带数据包类型。
0x009	Accept Connection Request	接收连接请求。附带角色切换信息。
0x01d	Read Remote Version Information	读取LMP版本和制造商名称。
0x037	Write Link Supervision Timeout	以时隙为单位，设置ACL连接超时时长。若ACL链路超过指定的时间未响应，则断开连接。例如，对于蓝牙耳机，这个值一般设为8000 slots，也就是说，如果耳机距离手机太远，或者其他因素导致连接超时，5秒之后双方连接即断开。
0x01b	Read Remote Supported Features	根据ACL连接对应的Connection_Handle，获取远端设备的LMP所支持的特性。
0x01c	Read Remote Extended Features	与上面类似，也会返回LMP Features，但是里面有我真正关心的内容：是否支持安全简单配对、是否支持安全连接 …. …1 = Secure Simple Pairing Host: True …. ..0. = LE Supported Host: False …. .0.. = Simultaneous LE and BR/EDR to Same Device Capable Host: False …. 0… = Secure Connections Host: False 0000 …. = Reserved: 0x0 Reserved: 00000000000000
0x019	Remote Name Request	获取远端设备名称，返回ASCII字符串。
0x00f	Change Connection Packet Type	切换数据包类型。
0x00d	Write Link Policy Settings	…. …. …. …1 = Enable Role Switch: true (1) …. …. …. ..1. = Enable Hold Mode: true (1) …. …. …. .1.. = Enable Sniff Mode: true (1) …. …. …. 0… = Enable Park Mode: false (0)
0x00b	Link Key Request Reply	Host将自己持有的Link Key发送给Controller，用于链路层数据包的加解密。是一个非常重要的命令。

2.3.3 HCI Event数据包

HCI Event数据包格式如下，是由Controller用于在事件发生时通知Host的数据包。Event Code来标识Controller到Host的事件类型。

HCI Event数据包格式

2.3.4 HCI ACL数据包

除了命令和事件数据包外，我们还会遇到HCI ACL数据包，在抓取到的HCI log里面，ACL数据包的数量占比是最大的：

HCI ACL数据包格式

在后续的监听过程中，我们会与HCI进行比较多的接触。在被监听者打开手机蓝牙之后，可以抓取到无协议的HCI数据流，主要用于蓝牙模块的一系列初始化、搜索设备、广播等工作。

2.4 逻辑链路控制与适配协议层 (L2CAP Layer)

2.4.1 L2CAP概述

L2CAP（Logical Link Control and Adaptation Protocol）负责适配上层协议，向上层协议提供面向连接和无连接（例如广播）的数据服务，并提供多路复用、分段和重组、服务质量监控三大功能，允许高层次的协议和应用能够以64KB的长度发送和接收数据包(L2CAP Serveice Data Unit, SDU)。其功能可以类比于OSI中的传输层。

辨析：SDU和PDU的区别？

SDU是指服务数据单元（Service Data Unit），它是指由L2CAP层接收到的上层协议传递给它的数据单元。这些数据单元可以来自于不同的高层协议，比如我们即将接触到的A2DP或者其他应用层协议。SDU的长度一般为64KB；

PDU是指协议数据单元（Protocol Data Unit），它是指L2CAP层将SDU封包后，向下传递给链路层的数据单元。具体一点来说，L2CAP层将上层协议传递给它的SDU进行分段、重组、加入控制信息等，然后将其封装成PDU进行传输。PDU的长度不固定，由报文长度以及双方设备MTU的最小值决定。

易混：注意区分不同语境下MTU的含义

举一个例子，Host ATT 层的最大数据传输单元和空中的单个物理数据包的最⼤⻓度（LE Packet Length）都可以称作MTU。不过前者是针对Host ATT层，⽽后者针对的是物理层 (PHY)。简单解释一下，即前者针对的是单 ATT Request 包能否完全装下要发送的数据，是否需要使⽤类似 Prepare Write Request 的包来分包发送；而 LE Packet Length 是底层的物理层 PHY 在发包的时候，决定这个包是否需要分成多个物理包来发送。例如，如果 (MTU+4 ) ⼤于 LE Packet Length，则 1 个 ATT 包可能需要分成多个物理包发送；反之，如果 (MTU+4) 小于 LE Packet Length，则所有的 ATT 包都能通过 1 个物理包发送出去。这⾥ MTU 之所以需要先加 4 再去比较，是因为实际发送的时候，需要给包加上 4 个字节的 L2CAP 头信息。（取自esp32_bluetooth_architecture）

2.4.2 逻辑信道

为了实现多路复用，L2CAP在链路层的物理信道基础上抽象出了众多逻辑信道，相当于TCP里面的Port，其分配情况如下：

信道标识符 channelID（CID）	用法
0x0000	Null identifier，不允许使用
0x0001	经典蓝牙信令信道，作为ACL-U逻辑链路发送信令的信道，如发送Conn_req、发送InformationRequest (0x0a)
0x0002	无连接信道，两个设备间未（？这里存疑）建立ACL链路时使用
0x0003	AMP管理协议
0x0004	Attribute Protocol（ATT）协议信道，用于交换属性数据
0x0005	BLE信令信道，适用于LE-U逻辑链路，一般传输的是控制数据，比如请求更新连接参数
0x0006	安全管理协议（Security Manager Protocol）信道
0x0007 ~ 0x003E	保留
0x003F	AMP测试协议
0x0040 ~ 0xFFFF	面向连接信道，是动态分配的，如在SDP服务发现时候就需要动态分配一个CID，和对端的CID连接后进行通信

对于LE-U逻辑链路，0x0001~0x0003全部保留备用，并且动态分配的CID范围仅仅在0x0040~0x007f，超出该范围的CID保留备用。

2.5 各类Profile

L2CAP为我们隐藏了底层链路的实现细节，使得开发人员可以更多地将自己的注意力面向产品的逻辑实现，各类Profile就是在这一基础上搭建起来的。对于初学者，Profile是一个比较抽象的概念，它常常译作中文名“协议”，你可以理解为一个多层对象，一个Profile还可以包含其他的Profile作为子集。在接下来的监听过程中，我们会接触到A2DP、HFP、AVDTP、AVRCP等协议。

蓝牙协议层次示意图

一个Profile可以包含一个或者多个Service，一个Service又可以包含一个或者多个Characteristic。

协议层再往上就是应用层了。

3 A2DP协议

3.1 A2DP协议简介

A2DP协议是Advanced Audio Distribution Profile（高级音频分发协议）的缩写，是一个用于实现在单声道、立体声或多声道模式下传输高质量音频内容的协议。与在蓝牙核心规范第2卷Section B第9节中定义的SCO链路上分发窄带语音的HFP不同，A2DP议的音频数据在ACL链路上传输，这与SCO上传输的语音数据是有本质区别的：

图片来自知乎专栏https://zhuanlan.zhihu.com/p/622758309

AVDTP（Audio/Video Distribution Transport Protocol，音频或视频分发传输协议）是A2DP的基础协议，定义了蓝牙设备之间数据流句柄（Stream Handle）的参数协商、建立和传输过程以及相互交换的信令格式。A2DP协议的音频数据包基于AVDTP协议进行传输，为了节省带宽，音频数据会被压缩。

AVRCP（Audio/Video Remote Control Profile）是用于远程控制蓝牙音频/视频设备的协议。它允许蓝牙设备之间进行播放控制、浏览和选择媒体内容等操作，最常见的使用案例就是我们的蓝牙耳机支持暂停和切歌等控制功能。因为A2DP不包括远程控制的功能，所以AVRCP协议通常与A2DP协议一起使用，以实现对音频/视频设备的远程控制。

这些协议之间相互配合，共同构成一套蓝牙音视频传输和控制的完整解决方案。

4 低功耗蓝牙连接过程

4.1 概述

低功耗蓝牙设备在进行配对时，涉及到物理层、链路层和L2CAP层的一系列步骤。以下是按照时间顺序对这三个层面进行详细分析：

易混辨析：蓝牙技术中，“连接两个设备”和“配对两个设备”是不同的概念。

连接是指建立设备之间的通信链接，进行数据交换。

配对是指在建立连接之前，设备之间需要进行一系列的安全验证步骤，以确保通信的安全性。最为关键的步骤就是生成link key，用于链路层加密。配对成功后，设备之间才能建立受信任的连接，开始数据交换。

一言蔽之，连接两个设备是建立通信链接的过程，而配对两个设备是在连接之前进行的安全验证步骤。连接是建立在配对的基础上的。一般来说，已经配对过的设备，在重新建立连接的时候不会再进行配对。

物理层：
- 广播和扫描（Advertising and Scanning）： BLE设备在广播中发送广播包，包含设备的唯一标识符（例如MAC地址）。其他设备在扫描中监听广播包，以便发现可用的BLE设备。
- 连接请求和响应（Connection Request and Response）： 当一个设备决定连接另一个设备时，它会发送连接请求，另一个设备回复连接响应。这两个设备之间建立了一个连接。
链路层：
- 连接建立（Connection Establishment）： 在连接请求和响应之后，设备之间建立了物理链路。连接建立包括连接参数的协商，如连接间隔、数据包大小等。
- 安全特征（Security Features）： BLE配对过程中，链路层会处理安全特征，如加密、身份验证等，确保通信的安全性。
L2CAP层：
- 配对请求和响应（Pairing Request and Response）： 一旦连接建立，设备之间可以开始BLE配对过程。L2CAP层协商配对参数和安全性要求。
- 密钥生成和分发（Key Generation and Distribution）： 配对成功后，L2CAP层负责生成和分发密钥，以确保通信的机密性和完整性。
- 服务发现和特征读取（Service Discovery and Characteristic Read）： 配对成功后，设备可以通过L2CAP层进行服务发现，并读取对应服务的特征。

5 低功耗蓝牙安全性

5.1 概述

蓝牙核心规范提供的很多安全措施其实并不是强制性的，由于高安全性和易用性二者往往是相互矛盾的，大部分蓝牙SoC出于降本增效的考虑，并不会搭载全部的安全措施，并且不同的连接状态所采取的安全措施数量与种类也可能是不同的。

这里用时间线的方式来概述两个BLE设备连接的过程：

设备发现与连接初始化：

广播者 (Broadcaster)通过发送广播 (Advertising) 让接收者发现自己（此时只能发⼴播，不能被连接）。观察者 (Observer)通过接收广播事件并发送扫描 (Scan) 请求，扫描周边的广播者，发现目标设备后，发送连接请求。当广播者接受了观察者发来的连接请求后就会成为从设备 (Slave)，观察者这时再建立物理链路，成为主设备 (Master)。
**配对(Pairing)**：

若决定进行安全通信，主设备会发起配对过程。配对是指两个设备同意建立一定级别的安全连接，双方通过交换信息确定安全参数，选择合适的配对方法（Just Works, Passkey Entry, or OOB）。配对方法的选择影响认证属性（MITM保护与否），比如使用Just Works方法则密钥具有未验证属性，而使用PIN或OOB则具有认证属性。
密钥生成与交换：

安全管理协议(SMP)在此阶段发挥作用，负责生成加密密钥和身份密钥。根据所选的配对方法，SMP执行相应的密钥交换协议，涉及短期密钥(STK)的生成。如使用Passkey Entry或OOB方法，配对过程中会生成具有认证属性的密钥。
**决定是否绑定(Bonding)**：

配对过程中，设备会检查对方是否支持Bonding，即：是否愿意在将来连接时复用此次配对产生的安全信息（如LTK、CSRK或IRK）。如果双方都支持且决定Bonding，则完成密钥分配，并在本地存储这些密钥，以便后续快速进行重连。
加密流程：

一旦Pairing和可能的Bonding完成，主设备或已经Bonding的设备会对链路进行加密。如果之前已Bonding，BLE协议栈就直接使用已经存储的密钥进行加密，否则，再生成密钥。具体的细节后面会涉及。
可以开始通信了：

上述加密操作成功完成后，链路进入加密状态，设备间的数据传输将受到保护。应用层可以通过注册的GAP回调获知加密状态，进而可以开始安全的数据交换。

5.2 密钥生成&加密

5.2.1 概述

BLE使用AES-CCM算法通过linkKey进行链路层级别的对称加密。在点对点通信中，这个linkKey长度为128bits，是双方第一次建立连接之后就通过配对确定下来的，需要持久化存储到flash中，下次连接时就可跳过繁琐的配对步骤，直接进行加密。如果删除配对，那么双方就需要重新配对并协商得到linkKey。我们通过sniffer抓包得到的数据包一般来说是经过加密的，需要知道这个linkKey，才能将数据解密。

再次强调，触发配对的前提是没有linkKey（即对方来配对，本地controller发送HCI_Link_Key_Request请求linkKey，但是本地没有linkKey，所以回复HCI_Link_Key_Request_Negative_Reply）。

BLE中的linkKey生成是由每个BLE设备上的Host独立进行的（作为对比，BR/EDR中的密钥生成是在Controller中执行的），不会受到其他BLE设备的影响。另外，通过在Host上执行密钥生成，可以在不更改Controller的情况下修改密钥生成算法。与密钥生成不同，BR/EDR和BLE的加密都是在Controller中的链路层执行的。

5.2.2 配对方式

蓝牙版本	最高支持的配对方式
BR/EDR v2.1之前	BR/EDR legacy：普通配对。引入了Passkey Entry模式，需要用户手动输入一个六位数的PIN码（Passkey）到另一个设备上，现在市面上一些蓝牙键盘就是使用这种方法进行配对。具备MITM保护，因为只有知道正确Passkey的设备才能完成配对，可以大大增加中间人攻击的难度。
BR/EDR v2.1	BR/EDR Secure Simple Pairing：安全简单配对。引入了Just Works模式（无用户交互，适用于蓝牙耳机等无法显示和无法输入密码的设备）。这个模式下，临时密钥（TK）固定为0，即配对过程中的密钥协商不包含任何动态的或用户提供的信息，没有机制确保设备之间的通信未被第三方窃取，无法提供MITM保护。
BR/EDR v4.2	BR/EDR Secure Connections：安全连接。采用符合联邦信息处理标准（FIPS）的椭圆曲线Diffie-Hellman（ECDH）算法来生成密钥，引入了Numeric Comparison（数字比较）模式，是一种相对较新的配对模式。这个模式下，两个蓝牙设备会各自显示一个相同的6位数字，用户通过比较并确认这两个数字是否一致来完成配对认证，而不是像传统的Passkey Entry那样需要用户手动输入密码。这种方法可以提供MITM保护，显示的数字并不直接用于计算linkKey。
BLE v4.0	LE legacy (Secure Simple Pairing)，实际上指的是在蓝牙4.0及以前版本中使用的安全简单配对（Secure Simple Pairing，SSP）方法的一个子集。
BLE v4.2	LE Secure Connections，同上，依然是BR/EDR Secure Connections的一个衍生物。

注：蓝牙4.0版本开始支持BLE，BLE的Secure Simple Pairing并非新技术，在BR/EDR中早就已经提出。

5.2.3 普通配对

从用户的角度来看，普通配对需要在进行配对的两台设备之间手动输入相同的PIN码。普通配对的流程如下：

发起设备controller请求从host获取pincode（HCI_PIN_Code_Request）
用户输入pincode以后，host会将pincode发送到controller（HCI_PIN_Code_Request_Reply）
发起设备controller发送LMP_in_rand给响应设备
响应设备也会请求host输入pincode（HCI_PIN_Code_Request）
响应设备的用户输入pincode后，同样会把pincode发送到自己的controller （HCI_PIN_Code_Request_Reply）
响应设备回复LMP_accepted给发起设备
之后发起设备发送LMP_comb_key，响应设备回复LMP_comb_key，两端产生linkKey
进入认证环节，认证完成后将linkKey通知host（HCI_Link_Key_Notification）

5.3 数据签名

BLE支持在两个已经具有信任关系的设备之间，通过未加密的连接发送经过身份验证的数据，这是借助连接签名解析密钥（CSRK）对数据进行签名来实现的。签名由签名算法生成的消息认证码和一个counter组成（counter用来防止重放攻击，在发送每个已签名的PDU时递增）。发送端在PDU后面放置签名，接收端验证这个签名，如果验证通过，则认为PDU来自受信任的发送端。

5.4 地址私有化

首先，BLE支持频繁改变蓝牙设备地址（BD_ADDR），来避免设备被追踪。

BLE通过生成私有地址和使用身份解析密钥（IRK）来维持连接的隐私性（私有地址是在绑定过程中交换的IRK生成的），使得设备在重新连接已知设备时，可以使用私有地址来进行通信，而不会暴露真实的设备地址。如果一个设备使用私有地址，它就会拥有一个身份地址(Identity Address，IA)，由接收到的私有地址和IRK去计算得来。

私有地址又分为可解析地址和不可解析地址，这里的“解析”一词指的是接收端使用收到的私有地址和IRK去计算IA的过程。