1. 从“能连上”到“敢连上”：BLE安全为什么是产品设计的生死线

几年前，我参与过一个智能门锁的项目，用的就是蓝牙BLE。当时团队的重心全在“功能实现”上：手机App能发现门锁、能连接、能发送开锁指令，大家就觉得大功告成了。直到有一次内部安全测试，一个实习生用网上开源的抓包工具，在十米开外轻松截获了开锁指令，并且原封不动地重放了一次，门锁“咔哒”一声就开了。那一刻，会议室里鸦雀无声。这个惨痛的教训让我深刻意识到，对于BLE，尤其是涉及控制、支付、隐私数据的应用，“连接”只是万里长征第一步，“安全连接”才是抵达终点的保障。

蓝牙低功耗（BLE）技术因其低功耗、低成本、易集成的特点，已经渗透到我们生活的方方面面：从智能手环、电子价签，到医疗设备、汽车钥匙。但随之而来的安全挑战也日益严峻。很多人，包括一些开发者，对BLE安全的认知还停留在“配对码”或者“绑定”这个层面，认为设置了PIN码就安全了。这其实是一个巨大的误区。BLE的安全是一个体系，从物理层的数据收发，到应用层的数据加密与访问控制，环环相扣。理解并实施好这套安全体系，是让产品从“玩具”升级为“工具”，从“能用”变为“敢用”的关键。

本文不会堆砌枯燥的协议栈章节，而是从一个实践者的角度，拆解BLE安全的核心机制、常见攻击手段，以及在实际开发中，从芯片选型、协议栈配置到应用层设计，你必须关注的那些“安全阀门”。无论你是嵌入式软件工程师、移动端开发者，还是物联网产品经理，这些内容都将帮助你构建更可靠、更值得用户信任的BLE产品。

2. BLE安全机制的三层铠甲：配对、绑定与加密

BLE的安全并非铁板一块，而是由浅入深的三层防护。很多开发中的混乱，都源于对这三者关系的混淆。

2.1 第一层：配对（Pairing）—— 建立信任的“握手仪式”

配对是安全关系的起点。它的核心目的，是让两个从未谋面的设备（比如你的手机和新的智能手表）安全地交换用于后续加密通信的密钥。你可以把它想象成两个人第一次见面，需要一种安全的方式互换电话号码和约定一个只有彼此知道的暗号。

BLE的配对过程主要围绕一个核心问题展开：如何在不安全的无线电波中，安全地交换一个秘密？协议提供了几种“配对方法”，其安全强度依次递增：

1. Just Works（只管用）：这是最简单，也是最不安全的方式。设备双方直接生成并交换密钥，过程中没有任何用户验证。攻击者可以实施“中间人攻击”，轻松窃听或篡改这个密钥交换过程。它只适用于没有任何安全要求或显示/输入能力的设备（比如一个简单的温度传感器）。
2. Passkey Entry（密码输入）：一个设备（通常是有屏幕的，如手机）生成一个6位数字密码，用户需要在另一个设备（如键盘输入的智能锁）上输入这个密码来完成验证。这提供了“主动参与”的验证，能有效防止被动窃听，但无法抵御中间人攻击（如果攻击者从一开始就介入，可以伪造两端）。
3. Numeric Comparison（数值比较）：两个设备都显示一个6位数字，用户需要确认两边的数字是否一致。这主要用于两个都有显示能力的设备（如手机和智能手表）。它同样无法抵御中间人，但通过用户确认，保证了连接对象的正确性。
4. Out of Band（OOB，带外通信）：这是最安全的方式。密钥或认证信息通过另一个安全的通道交换，比如NFC触碰、二维码扫描。因为攻击者很难同时入侵两个不同的物理通道，所以安全性最高。

注意：选择哪种配对方式，不是由开发者随意决定的，而是由设备双方的“输入/输出能力”协商出来的。在协议栈初始化时，你需要正确设置本设备的IO能力（如无输入无输出、有显示无输入、有键盘等），这直接决定了最终能使用的最高安全等级的配对方式。

2.2 第二层：绑定（Bonding）—— 记住彼此的“安全档案”

配对成功，生成了密钥，但会话结束，连接断开后，密钥就丢弃吗？如果是这样，每次重连都要重新走一遍繁琐的配对流程，用户体验极差。绑定的作用，就是将配对过程中生成的长期密钥（Long Term Key, LTK）安全地存储在两个设备上。

绑定完成后，两个设备就成为了“老朋友”。下次再见面（重连）时，它们可以直接使用存储的LTK来快速恢复加密链路，无需再次配对。这个过程称为“重连”或“加密恢复”，速度极快，用户无感。

这里有一个关键点：绑定信息（尤其是LTK）的存储安全，是应用开发者的责任。协议栈只负责生成和调用它。你必须确保将其存储在设备的可信区域（如安全元件SE、TrustZone、或经过加密的本地存储中），防止被恶意应用或物理攻击提取。如果绑定信息泄露，攻击者就可以伪装成合法设备进行连接。

2.3 第三层：加密（Encryption）与数据签名—— 通信内容的“保险箱”

配对和绑定解决了“和谁通信”以及“如何快速恢复信任”的问题。而加密则是解决“通信内容不被窥探和篡改”的问题。

• 加密：使用LTK衍生的会话密钥，对空中传输的数据载荷进行加密。没有密钥的攻击者即使截获数据包，看到的也只是乱码。BLE使用AES-CCM加密算法，这是一种兼顾加密和完整性校验的强算法。
• 数据签名（使用LE安全连接时）：对于某些不需要加密但需要防篡改的数据（比如广播的传感器数据），可以使用一个签名来确保数据的真实性。接收方可以验证数据是否来自可信的设备且未被修改。

这三层铠甲是递进关系：没有成功的配对，就没有用于加密的LTK；没有绑定，每次加密都要重新配对；没有加密，即使绑定了，通信内容也如同明信片一样公开。一个安全的BLE产品，必须根据其面临的风险，正确配置并启用这三层防护。

3. 隐藏在协议栈配置中的安全陷阱

很多开发者调用一个GAP_Bond或sm_set_pairing_param之类的函数就觉得安全搞定了，其实远非如此。协议栈的配置就像房子的地基，配置错了，上面的应用层代码再坚固也白搭。

3.1 安全模式与等级：定义通信的“最低安保标准”

BLE规范定义了安全模式和等级，用来规定一次连接需要满足的最低安全要求。

• 安全模式1：这是最常用的模式，专注于数据加密和认证。

  • 等级1：无安全要求（无加密和认证）。
  • 等级2：未认证的加密。数据加密了，但设备身份未经过强认证（例如，用了Just Works配对）。适用于需要隐私但无需严格身份的场景。
  • 等级3：已认证的加密。数据加密，且设备身份通过MITM（中间人）保护机制认证（即使用了Passkey Entry或OOB配对）。这是对安全性有要求的设备必须达到的等级。
  • 等级4：使用LE安全连接的已认证加密。这是基于椭圆曲线密码（ECC）的更强配对方式，能提供更好的未来安全性。

• 安全模式2：专注于数据签名（用于广播数据等）。

实操陷阱：很多芯片原厂的SDK示例代码，为了演示方便，默认将安全模式设置为模式1等级1（无安全）。如果你基于这样的代码开发产品，而没有修改这些配置，那么你的设备将接受任何连接请求，且通信完全不加密。第一步，永远是在协议栈初始化函数中，找到并设置正确的安全模式和等级。例如，对于智能门锁，至少应设置为模式1等级3。

3.2 配对参数协商：一场“安全能力”的博弈

当两个设备连接并开始配对时，它们会交换各自的“安全需求”（IO能力、是否要求MITM保护等），并协商出一套双方都能接受的配对方法。这个过程如果处理不当，可能导致“安全降级攻击”。

例如，你的智能设备明明支持Passkey Entry（高安全），但为了兼容性，在参数中错误地声明自己也可以接受Just Works（低安全）。一个恶意的中心设备（攻击者）可能会在协商时故意选择Just Works，从而绕过更安全的用户验证流程。

配置要点：

1. 正确声明IO能力：你的设备有按键吗？有显示屏吗？根据实际情况设置，这决定了可用的配对方法上限。
2. 设置MITM保护需求：对于需要身份认证的设备，务必在参数中要求MITM保护。这样，如果对方设备无法提供（比如只支持Just Works），配对会失败，而不是降级。
3. 使用安全连接（LE Secure Connections）：如果芯片支持，务必启用。它用ECC替代了旧有的传统配对，能有效抵御被动窃听和某些中间人攻击，是当前的主流选择。

3.3 绑定信息管理：钥匙不能丢在门口

如前所述，绑定后的LTK存储至关重要。除了存储安全，管理策略也同样关键：

• 绑定列表溢出：低端设备的绑定存储空间可能只有几个或几十个槽位。当槽位满后，新的绑定请求会导致旧绑定被覆盖。你需要设计策略，例如使用LRU（最近最少使用）算法来淘汰，或者提示用户管理已绑定设备。
• 解除绑定：产品必须提供让用户解除绑定的途径（如在App中删除设备）。这不仅关乎体验，更是安全要求——当设备丢失或转让时，必须能撤销旧设备的访问权限。在协议栈层面，解除绑定意味着删除存储的LTK和身份解析密钥（IRK）。

4. 应用层安全：协议栈之上的最后防线

即使协议栈层面的安全配置完美无缺，应用层设计的疏忽也会让所有努力付诸东流。这一层是开发者控制力最强，也最容易出问题的地方。

4.1 属性协议（ATT）与GATT：细粒度访问控制

BLE设备的功能通过GATT（通用属性配置文件）暴露给客户端。GATT由服务（Service）、特征（Characteristic）和描述符（Descriptor）组成。每个特征都有其属性（读、写、通知等）。

安全漏洞重灾区：对特征的访问权限配置不当。

• 场景一：过度授权。一个只应由授权用户写入的“控制指令”特征，被配置为“可写且无需认证”。任何连上的设备都能随意控制。
• 场景二：权限混淆。一个用于读取设备序列号的特征，本应“可读无需加密”（方便配网），却被错误地设置为“只读且需加密”。导致配网App在未加密的连接阶段无法读取序列号，流程卡死。

正确做法：在设计GATT表时，为每一个特征和描述符仔细定义其安全权限。权限通常包括：

• 访问权限：可读、可写、可通知/指示。
• 安全权限：无要求、需加密但无需认证、需加密且需认证。

例如：

4.2 数据有效性验证与速率限制

协议栈保证了传输通道的加密，但无法理解你传输的数据含义。应用层必须对收到的数据进行有效性验证。

• 边界检查：收到一个“设置温度”的指令，值范围是16-30度。如果收到一个0或100，应该直接拒绝并返回错误，而不是去处理。
• 状态机检查：设备处于“已开锁”状态时，再次收到“开锁”指令应忽略或返回错误，避免重复执行。
• 速率限制：对于关键指令（如开锁），必须实施速率限制。例如，每秒最多接受一次该指令。这能有效抵御“暴力穷举”攻击（虽然数据加密了，但攻击者可以不断尝试发送各种加密后的指令）和“资源耗尽”攻击（发送海量指令让设备死机）。

4.3 固件更新（OTA）的安全设计

OTA是BLE设备生命周期管理的必备功能，但也引入了巨大的攻击面。一个不安全的OTA流程，等于为攻击者打开了安装恶意固件的大门。

安全OTA的核心原则：

1. 身份认证：设备必须验证固件包的来源是否合法（通常是厂商）。这通过数字签名实现。设备端预置厂商的公钥，收到固件包后，用公钥验证其签名。签名无效，立即终止更新。
2. 完整性校验：确保固件在传输过程中未被篡改。通常使用哈希值（如SHA-256）校验。
3. 加密传输：固件包本身应该加密，防止被反向工程。即使OTA使用了加密连接，对固件包自身再进行一次加密也是良好的纵深防御实践。
4. 安全启动：设备上电时，Bootloader必须能够验证即将加载的应用固件的签名。只有验证通过，才跳转执行。这是防止设备运行被篡改固件的最后一道防线。
5. 回滚保护：防止攻击者利用旧版本固件的已知漏洞进行降级攻击。设备应能记录当前固件版本，并拒绝安装版本号更低的合法固件。

5. 实战攻防演练：常见BLE攻击手段与防御之道

了解攻击手段，才能更好地进行防御。下面列举几种针对BLE的常见攻击，并给出相应的防护建议。

5.1 窃听与重放攻击

• 攻击描述：攻击者使用软件定义无线电（SDR）或廉价蓝牙嗅探器（如Nordic的nRF Sniffer），在设备通信范围内被动窃听空中传输的数据包。如果通信未加密，所有信息一览无余。即使加密，攻击者也可以录制加密的数据包，并在之后原样“重放”出去。
• 经典案例：本文开头提到的智能门锁漏洞，就是典型的重放攻击。攻击者录下了合法的“开锁”指令数据包，重放后门锁执行了开锁动作。
• 防御措施：
  • 强制使用加密连接（安全模式1等级2以上）。
  • 启用加密绑定，确保每次会话使用不同的临时密钥衍生会话密钥，增加破解难度。
  • 应用层防御重放：在关键指令中加入一次性的随机数（Nonce）、时间戳或序列号。服务器端（或作为外围设备的固件端）记录最近接收到的随机数/序列号，拒绝重复的指令。

5.2 中间人攻击

• 攻击描述：攻击者同时与通信的双方建立连接，并转发（可能篡改）双方的消息，让双方都以为在与合法的对方通信。这对于Just Works配对方式是有效的。
• 防御措施：
  • 使用带用户验证的配对方式：Passkey Entry或Numeric Comparison。用户参与验证的过程（输入密码或比较数字）使得MITM攻击难以在用户无察觉的情况下完成。
  • 使用OOB配对：通过NFC等带外通道交换信息，从根本上杜绝了在BLE通道上进行MITM的可能。
  • 在App端进行二次确认：例如，在完成BLE配对后，App可以显示连接设备的唯一标识（如证书哈希），并要求用户确认。

5.3 拒绝服务攻击

• 攻击描述：攻击者通过发送大量连接请求、恶意格式的数据包或利用协议漏洞，使目标设备资源耗尽（内存、电量）或进入错误状态，从而导致正常服务中断。
• 防御措施：
  • 连接请求过滤：在广播阶段，可以设置白名单，只响应已知设备的连接请求。
  • 协议栈及时更新：关注芯片厂商发布的安全通告和协议栈更新，修复已知的协议层漏洞。
  • 应用层健壮性：做好异常处理，对异常数据包或高频请求进行丢弃和复位，避免死机。

5.4 身份跟踪

• 攻击描述：BLE设备在广播时，通常会携带一个固定的设备地址（Public Address）或周期性变化的随机地址（Random Private Address）。如果随机地址的生成或更换策略有缺陷，攻击者可以通过分析广播包中的其他固定信息（如特定服务UUID、设备名称片段）或信号强度模式，长期跟踪一个设备，侵犯用户隐私。
• 防御措施：
  • 正确使用可解析私有地址：确保设备使用RPA（Resolvable Private Address），并且只有绑定过的设备才能通过IRK解析出它的真实身份。对于未绑定的观察者，RPA看起来是不断变化的随机地址。
  • 减少广播信息：在广播数据中，只包含必要的信息。避免广播唯一的设备名称、序列号等。
  • 调整广播间隔和功率：非必要时，降低广播频率和发射功率，减少被远距离侦测到的机会。

安全是一个持续的过程，而不是一个可以一劳永逸勾选的特性。对于BLE产品，从芯片选型支持的安全特性，到协议栈的配置，再到应用层的每一行代码，都需要带着安全的思维去审视。在项目初期就引入安全设计和威胁建模，远比在漏洞出现后亡羊补牢要经济、有效得多。毕竟，用户信任的建立极其艰难，而崩塌往往只在一瞬间。