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大象，原链接已失效，插图大量丢失，小编已重新整理
