SM（Security Manager）安全管理层定义了BLE通信两端设备的配对方法和密钥分发的工作模式，提供了一系列加密算法，为BLE通信提供了加密、认证等安全保障。它与GAP层密切相关，关于安全需求的一些配置是在GAP层中完成的。

对数据进行加密，BLE使用AES加密算法，通过复杂的认证过程，保证该加密算法的密钥能够被安全的传递到通信链路两端的设备中。一旦有了密钥，就可以对通信过程中的数据进行加密和解密，使得第三方无法截获破译空中的数据。AES加密算法不是理解BLE协议栈的重点内容，并且协议栈都对AES加密提供了接口函数，所以本文不考虑底层的算法细节。经过配对后的两个设备，即可进入认证状态，进而可以对设置了Authenticated Required的特征值进行读写操作。

BLE通信面临的威胁

在BLE通信中，有三种情况威胁着用户数据的安全和私密：

窃听

考虑常规的BLE通信，一端是手机，一端是BLE设备。假如二者没有进行认证加密，那么在通信开始之前，在附近开启一个BLE Sniffer，就可以看到手机与BLE设备之间的连接后的通信数据明文。

显然许多应用无法接收这个事实，需要对数据和链路进行加密处理。

MITM攻击

MITM（Man in the Middle）中间人攻击是指第三方设备混入BLE通信链路之间，伪造通信数据迷惑双方。假如设备A和设备B在通信之始，设备M注意到二者要进行通信，设备M截取设备A发起的连接请求，伪装成设备B跟其建立连接进行通信，通信完毕后再伪装成设备A向设备B发起连接请求，建立连接后重复设备A在前面发送的数据。这样设备A就一直以为在跟设备B进行通信，设备B也同样，却不知二者中间还藏着一个第三者，如下图所示：

使用Authenticated MITM protection方式的安全保护，可以避免MITM攻击。

追踪

BLE广播包中包含了设备地址，使用Android手机，安装一个BLE扫描App，就可以获取周边正在广播设备的地址信息。设备地址是不会轻易改变的，所以跟踪设备的广播信息，就可以跟踪这个设备。更形象的描述，一个用户带着一个运动手环，攻击者可以检测附近的广播，一路追踪这个手环的移动。解决这个问题需要对设备地址进行特殊处理，即将设备地址包装成随机地址。iOS系统的BLE默认开启随机地址，过几十分钟就变换一次设备地址。

BLE的安全措施

BLE提供三种等级的安全措施：

No Security
Unauthenticated no MITM protection
Authenticated MITM protection

从名字中可以得知他们的含义：

无保护
不认证、不能抵御MITM（也不能抵御窃听）的保护
做认证、能够抵御MITM（也能够抵御窃听）的保护

在No Security情况下，数据以明文形式在空中传输，利用Sniffer可以查看到BLE通信中的活动数据。如果通信数据不在意安全，可以选择这种方式。无安全带来的好处是不用进行加解密计算，内部计算少对功耗有益，操作也会更加方便。由于没有生成任何密钥，所以这种方式不能使用加密和绑定等功能。

第二种保护方式，BLE主从设备之间不进行认证过程。但是它与第一种No Security不同，它是将认证密码设置0，两端设备无需交换这个密码，自动进行生成密钥的操作。由于密码是公开的，可以推算出设备端生成的密钥，因此Sniffer是可以看到通信过程中的数据明文的，即无法避免窃听和MITM的威胁。但是，这个方式仍然会产生密钥，可以进行后续的加密和绑定动作，假如Sniffer未在配对之始就跟踪通信链路，就无法破解通信链路，这也能提供一定程度的安全保护。这种方式的必要性是，它不需要输入密码，对于类似蓝牙耳机这种没有输入输出途径的设备，只能选择这种保护方式。假如一个设备需要绑定功能，不在意数据安全，也可以选择这个方式。

第三种为最强保护等级，既做认证又做加密。所谓认证，是指一方提供密码，在另一方输入并回传，如果密码匹配则为通过认证。通过认证的设备，就可以相互交换各自的密钥。二者之间的通信以密钥进行加解密，第三方设备没有密钥就无法获知数据明文。这种情况下的BLE通信，使用Sniffer看不到通信数据明文，仅能识别出部分帧格式。假如给Sniffer提供了认证密码，Sniffer就能够攻破加密链路，解密出数据明文。

配对（Pairing）

实现上述三种保护方式，需要涉及一系列相关工作和参数：配对绑定的需求、设备的输入输出能力、生成密钥的过程、交换密钥的过程、加密算法选择、密钥种类等等。BLE将这些过程，组织成一个专门的行为，即配对（Pairing）。从宏观上看，配对就是手机端输入一串密码，与BLE设备建立关联，从协议层面上看，配对就是规定了密钥的生成方法和分发流程，并顺带把链路给加个密。

配对的流程

配对分三个阶段：

交换配对特征
生成短期密钥STK（Short Term Key）
生成长期密钥LTK（Long Term Key）并分发

其中前两个阶段为必须阶段，第三个阶段非必须。经过第二个阶段，BLE的通信链路根据加密需求进行加密或者不加密。如果加密，则第三个阶段就可以生成一系列特殊作用的密钥，并分发出去（其实就是主从机将自己的密钥交给对方）。如果不加密，则无需进行第三个阶段。下图为配对的三个阶段执行框图：

图中，从上往下表示时序，首先建立链路层的连接，然后再发起配对请求。所以配对一定是在建立了连接之后才发生的。在第二阶段（Phase 2）和第三阶段（Phase 3）之间有一个横条，其内容暗示当前的链路已经进行了加密，即如果没有加密，就不应该有第三阶段。

IO Capability

配对特征包括：输入输出能力（IO Capability），OOB认证数据，密钥长度等。其中IO能力最常用也最关键，其他参数通常保持默认即可。IO Capability是指BLE设备具有何种输入输出能力，BLE对IO能力进行了枚举，抽象出3种输入能力和2种输出能力：

最终的IO Capability有以下几种：

No Input & No output
Display Only
Display & Yes/No
Keyboard Only
Keyboard & Display

这个参数影响了可以选择的安全保护方式，假如两个设备一个是Keyboard & Display，一个是No Input & No Output，它们就无法进行密码输入，也就无法选择Authenticated MITM protection这种保护方式。

配对方法

两端设备的IO能力不同，在第二阶段采用的生成密钥的方法也不同，BLE协议规定了三种生成密钥的方法，也称为“配对方法”：

Just Works
Passkey Entry
OOB（Out of Band）

Passkey Entry方法以一个6字节密码为初始密码，执行加密动作。由于初始密码为随机生成，因而能够保证后续加密行为的安全性。这种方法产生的链路是认证的（Authenticated）。在实际使用中，需要设备具有输出能力用以显示密码，在手机端输入密码，或者反过来设备端有一个输入键盘，手机端提供密码。

Just Works方法无需输入密码，两端设备仍然执行加密动作，但是初始密码设为0。这种方法产生的链路是未认证的（Unauthenticated）。在实际使用中，Just Works在配对时候手机屏幕会有弹窗，用户仅需要点一下确认即可。

OOB是指利用第三方途径，比如NFC或者WIFI，将Passkey传输给对方。只要这个第三方途径足够安全，就能够保证Passkey的安全，从而避免攻击设备截获Passkey。这个方案受限于第三方途径的匮乏以及操作的复杂性，到目前没有看见有人使用。

回头审视这三种方法，其实就是检查两端设备是否具有IO能力，如果能够输入输出，就选择Passkey来传密码，如果不能，就选择Just Works，特殊情况下选择OOB。BLE对IO能与配对方法也做了一个映射表，以确定在不同的IO能力情况下，协议栈如何选择配对方法,如上图的表格可知如果一个设备是No Input No Output，那么就只能使用Just Works这种配对方式。如果两端设备都没有输入能力仅有显示能力，则也要选择Just Works。注意，如果两端设备都是Keyboard，竟然是Passkey Entry！

配对请求（Pairing Request）

如果配对是由主机发起，则主机向从机发起配对请求。如果是由从机发起，则从机先向主机发出一个Security Request，请求发起安全管理流程，主机收到后再发起配对请求，如上图的Figure 2.1 LE Pairing Phases所示。
配对请求中包含以下内容：

IO Capability：输入输出能力
OOB Data Flag：是否采用OOB（如果置位，则覆盖AuthReq Flag）
AuthReq Flag：是否需要绑定、MITM保护
Encryption Key Size：密钥长度
Initiator Key Distribution：发起者要求哪些密钥需要分发
Responder Key Distribution：响应者要求哪些密钥需要分发

主从两端经过配对请求和响应以后，就能够获知对方的IO能力和是否需要认证，从而选择一个合适的配对方法。
至此配对的第一阶段结束，下面进入第二阶段：生成STK，加密链路。

生成STK（Short Term Key）

先介绍一下临时密钥TK（temporary Key），顾名思义，就是一个临时用的密钥。对于Passkey Entry方法，假如6字节的密码为123456，注意这个密码是十进制，将其转成十六进制为0x01E240，那么对应生成的TK=0x00…001E240，TK长度为128bit（16字节），前面补足0。对于Just Works方法，TK=0x00…0，长度也是128bit。有了TK，可以使用BLE协议栈的随机算法生成几个随机序列：Mconfirm，Mrand，Sconfirm，Srand。其中前缀M表示Master，S表示Slave，后缀confirm表示确认命令，rand表示随机命令。这四个随机序列长度均为128bit。

配对第二阶段，主机端（Master）先生成Mconfirm和Mrand，从机端（Slave）生成Sconfirm和Srand，然后主机将自己的Mconfirm发给从机，从机将自己的Sconfirm发给主机。而后主从分别将自己的rand发给对方，并根据rand和TK值计算出confirm序列，这个序列如果跟刚刚交换的对方的confirm序列相等，则通过校验，否则报错。如果双方都通过校验，则根据TK、Srand和Mrand三个序列生成出一个新的序列，称为STK。

有了STK，就可以加密链路。加密链路并非神秘，它就是向控制器发送一个加密链路的HCI命令（Set_Connection_Encryption，0x0013），具体实施由控制器底层去处理。加密之后的链路，通信数据都要经过密钥进行加密解密。至此，配对的第二阶段结束。

密钥分发（Distribution）

在安全管理的规划里，有多种密钥承担着不同的工作，除了STK，还包括如下密钥：

身份解析密钥IRK（Identity Resolving Key）：用于解析随机地址
连接前面密钥CSRK（Connection Signature Resolving Key）：用于签名和验证签名
长期密钥LTK（Long Term Key）：用于记录加密后的链接
辅助密钥EDIV（Encrypted Diversifier）：用于识别LTK，每次刷新LTK都会重新生成
随机数Rand（Random Number）：用于识别LTK，每次刷新LTK都会重新生成

设备地址经过IRK加密可以变成随机地址（私有地址），这样能够解决“追踪”的威胁。另一端设备利用IRK可以将随机地址还原成原始地址。

CSRK用于签名类的问题。

LTK存在于绑定信息中，而绑定信息会存于Flash，所以LTK能够长期保持。假如两个设备已经绑定，断开后重新连接，就会去校验LTK信息。LTK如此重要，甚至提供了EDIV和Rand来增加它的安全性。
这些密钥大多需要STK作为种子来生成，主从两端生成这些密钥并相互交换，就完成了配对的第三阶段。

绑定（Bonding）

经过了配对过程，主从两端都获得了几个密钥，将这些密钥以及一些必要的额外信息（比如对方设备地址）打包存到Flash中，这个过程就叫绑定。简单的讲，配对是生成密钥，绑定是保存密钥。这两个行为在时序上前后关联，绑定前肯定需要经过配对，配对结束后可以选择不绑定。

重连

主从两端绑定以后，各自保存了绑定信息，那么下次重连，无需再次输入Passkey，即进入认证状态。如果从机端采用了HID Profile，甚至可以实现设备自动重连，只有手机发现从机在附近广播，就自动重连它。假如一端设备中的绑定信息受损，比如手机端的绑定信息被意外清除，那么在下次连接时候就需要重新进行配对、绑定流程。

加密（Encryption）

经过了配对，BLE通信链路就被加密，但是这种加密是基于Passkey一路加密而来，假如Sniffer获得了Passkey，就能够翻译出加密链路上通行的数据

原作者：CY大象，原链接已失效，插图大量丢失，小编已重新整理