蓝牙Core Specification v4.0中引入的配对机制（称为LE Legacy Pairing)）在安全性方面与BR/EDR安全特性（如 Secure Simple Pairing）有所不同。从用户的角度来看，association models（关联模型）类似于BR/EDR Secure Simple Pairing，具有相同的名称，但提供的保护质量有所不同。
1、Association Models（关联模型）
蓝牙LE使用了4种 association models，称为Just Works、Numeric Comparison（数值比较）、Out of Band 和 Passkey Entry。LE legacy pairing 没有对应的Numeric Comparison（数值比较）。
在 LE legacy pairing 中，每个 association models 都类似于BR/EDR Secure Simple Pairing，但有以下例外：Just Works 和Passkey Entry 不提供任何被动窃听保护。这是因为 Secure Simple Pairing 使用的是椭圆曲线Diffie-Hellman，而 LE legacy pairing 则不是。
在LE Secure Connections pairing 中，这四个 association models 在功能上等价于 BR/EDR Secure Connections。
每个 association model 的使用都基于设备的 I/O 功能。
2、Key Generation（密钥生成）
Bluetooth LE 中的密钥生成是由每个LE设备上的 Host（主机）独立于任何其他LE设备执行的。通过在 Host（主机）上进行密钥生成，可以在不改变 Controller（控制器）的情况下对密钥生成算法进行升级。注：BR/EDR 中的密钥生成在 Controller（控制器）中执行。
蓝牙LE使用多个密钥，每个密钥有特定的用途，如下:
数据和设备身份验证的机密性
未加密数据的身份验证
Device Identity（设备标识）
在LE中，用于提供机密性和身份验证的密钥是通过在 pairing（配对）过程中组合来自每个设备的贡献来生成的。
3、加密
Bluetooth LE 加密采用 AES-CCM 加密。和BR/EDR一样，LE 加密也是在Controller（控制器）中执行的。
4、Signed Data（已签名的数据）
Bluetooth LE 支持在两个具有可信关系的设备之间通过未加密的 ATT bearer（ATT承载器）发送经过身份验证的数据。这是通过使用 Connection Signature Resolving Key（连接签名解析密钥(CSRK)）对数据进行签名来完成的。sending device 在 Data PDU 之后放置一个 signature（签名）。receiving device 验证签名，如果签名被验证，则假定数据PDU来自可信源。签名由签名算法生成的 Message Authentication Code（消息身份验证代码）和 counter（计数器）组成。 counter（计数器）用于防止replay attack（重播攻击），并在发送的每个 signed Data PDU（签名数据PDU）上递增。
5、Privacy Feature（隐私保护功能）
Bluetooth LE 支持一个特性，该特性通过频繁更改蓝牙设备地址来降低在一段时间内跟踪LE设备的能力。
为了让使用 privacy feature（隐私特性）的设备重新连接到已知设备，设备地址(称为私有地址)必须由其他设备进行解析。私有地址是使用设备在 bonding procedure 中交换的 resolving identity key (IRK) （解析身份密钥(IRK)）生成的。
privacy feature 有两种变体。在第一种变体中，私有地址由 Host（主机）解析和生成。在第二种变体中，在Host（主机）提供控制器设备标识信息之后，由控制器解析和生成私有地址，而不涉及主机。此外，当控制器中的解析列表无法存储绑定设备所需的所有 device identity resolving keys 时，第二种变体可能涉及主机。
privacy 有两种模式：device privacy mode（设备隐私模式）和 network privacy mode（网络隐私模式）。在设备隐私模式下的设备只关心设备的隐私，它将接受来自对等设备的广告包，这些 advertisement包 包含它们的身份地址和包含私有地址，即使对等设备之前就已经分发过它的 IRK。在网络隐私模式下，设备只接受来自包含私有地址的对等设备的广告数据包。默认情况下，当控制器解析和生成私有地址时，使用网络隐私模式。
Host（主机）通过添加和删除 device identities（设备标识）来维护一个解析列表。主机可以向控制器提供完整的解析列表或该解析列表的子集。设备标识由对等方的标识地址、local and peer’s IRK pair（本地和对等方的IRK对）组成。
当控制器执行地址解析时，主机需要引用解析列表中包含的对等设备，它使用对等设备的设备标识地址。同样，从控制器到主机的所有传入事件都将使用对等方的设备标识，前提是对等方的设备地址已经解析。如果控制器不能在 advertisement 中解析对等方的设备标识地址，它可以将事件传递给主机，以便在主机中进行解析。
当在控制器中执行地址解析时，Device filtering 就成为可能，因为在检查对等方的设备标识地址是否在 White List 中之前，可以先解析该地址。
图5.4显示了控制器解析列表和控制器 White List 之间关系的逻辑表示。遵循此模型不需要解析列表和 White List的实际实现。解析列表可以独立于 White List 。
注意：并不是 White List 中的所有设备都是设备标识地址。
当地址解析仅在主机中执行时，由于必须禁用 device filtering，设备可能会经历更大的功耗。