蓝牙安全漏洞BLUFFS的原理解析及影响范围

2023年11月28日，在安全顶会ACM CCS 2023^[1](The ACM Conference on Computer and Communications Security )上，来自法国EURECOM研究中心的安全研究员Daniele Antonioli发表了一篇名为《BLUFFS: Bluetooth Forward and Future Secrecy Attacks and Defenses》^[2]的论文，里面详细描述了一个蓝牙协议级漏洞BLUFFS，几乎能够影响使用蓝牙4.2到5.4协议的所有蓝牙设备。不久后，蓝牙SIG联盟在其官网^[3]上对这个漏洞做了一次特别的安全提醒，并赋予其CVE编号CVE-2023-24023。本篇文章的主要目的就是来分析这个漏洞的具体成因，影响范围以及危害级别的。

说明：蓝牙设备的类型目前分为了两种：经典蓝牙（BR/EDR）和低功耗蓝牙（BLE）。经典蓝牙主要用于数据量较大的传输，如蓝牙耳机/音箱等；低功耗蓝牙，顾名思义，主要用于数据量较小的传输，其功耗也会相对较少，如蓝牙手环/手表等。在本文中，由于BLUFFS漏洞针对的是经典蓝牙类型，因此，本文中的“蓝牙”若无特殊说明，指代的就是经典蓝牙。

在蓝牙的使用中，蓝牙官方联盟SIG发布的蓝牙协议规格说明书是所有蓝牙设备的一种指导性的规范或标准。在本文中，除了上面提到的论文外，也会主要参考蓝牙协议规格说明书5.3版本^[4]进行漏洞的分析。

整个蓝牙的安全体系包含有5个安全特性：配对、绑定、设备认证、加密以及消息完整性[4, p266]。它们的简要描述如下：

配对（Pairing）：创建一个或多个共享密钥的过程。

绑定（Bonding）：存储配对期间创建的密钥以供可信设备的后续连接使用。

设备认证（Device Authentication）：验证两个设备是否具有相同的密钥。

加密（Encryption）：保护消息的机密性。

消息完整性（Message Integrity）：防止消息篡改和伪造。

从上面描述中可以发现，蓝牙的配对过程主要是为了生成双方蓝牙设备所共享的秘钥，即链接秘钥LK（Link Key），论文中表示为PK（Pair Key），这个LK可能是暂时性秘钥（temporary）或半永久秘钥（semi-permanent）[4, p954]。暂时性秘钥表示每一次会话（session）该秘钥都会改变，主要用于一对多的场景中；半永久秘钥表示在当前会话终止时，该秘钥会保存在非易失性存储中（Non-Volatile Memory，NVM），以便下一次相同双方设备间的会话使用该秘钥，即会被用于下一次连接时的设备认证以及消息的加密过程。在本文中，由于不考虑一对多的场景，因此，LK默认为半永久秘钥。

绑定就是把已配对设备的秘钥等信息进行保存的过程，以便与对端蓝牙设备断开连接后，下一次连接时能够使用该秘钥等信息进行快速验证和加解密消息，提高效率。在Android中，绑定实质上就是保存已授权连接的蓝牙设备的信息（包括LK），并把该设备加入到自己的已配对列表中。

设备认证就是LK生成后验证设备双方的LK是否相同，从而判断对方是否为可信设备。

加密是利用LK来生成会话秘钥K_c（论文中表示为Session Key, SK），这个K_c就是这次会话所使用的加密秘钥，会话加密后能够防止传输的信息被窃取。

消息完整性用于判断传输的消息是否被篡改和伪造，协议规格说明书中提到了两种方法：CRC和基于AES-CCM的方法。

对于配对（LK秘钥的生成）、设备认证以及加密这三个过程所使用的安全算法和流程由于历史的原因主要分为了三类，即三个安全机制：Legacy、SSP（Secure Simple Pairing）以及SC（Secure Connections）[4, p950]如下表所示。现在许多的蓝牙设备由于兼容性考虑，同时具有这三个安全机制。

其中，Legacy在论文中表示为LSC（Legacy Secure Connections），SSP和SC在使用流程上几乎没有改变，只是改变了算法部分，因此在论文中统称为SC，在本文中，我们将使用论文中的缩写形式。下面分别对LSC和SC进行分析。且由于论文中BLUFFS漏洞主要针对的是LSC机制，因此，本文对LSC进行详细介绍，对SC解析了简要分析，重点分析SC和LSC的差异的地方。

使用LSC机制的蓝牙设备在真正传输信息之前会具有5个阶段：初始化秘钥（initialization key）的生成、链接秘钥（Link key/Pair Key, LK/PK）的生成、交换LK、设备认证以及加密秘钥（Session Key, SK）的生成。

其中，前两个阶段初始秘钥和链接秘钥的生成如下图所示，其为[5]中描述的LK生成过程：

从图中可以看到，初始化秘钥K_init是由PIN和一个共同的随机数通过E₂₂算法所生成的，E₂₂算法基于SAFER+，在协议规格说明书中有详细说明[4, 980]，这里不再对这些算法进一步介绍，只对其的输入和输出进行关注。其输入的PIN可以是设备提供的固定值，也可以是用户输入到这两个设备中。如果设备都是可输入设备，则规格说明书更建议使用后者[4, p955]。PIN的大小为1到16字节，若是其小于16字节，则需要加入发起连接设备的MAC地址（BD_ADDR）来共同生成初始化秘钥K_init。K_init然后会经过一系列的算法最终生成链接秘钥K_link。然后K_link会被用于通信设备的认证。

如下图所示，LSC的设备认证主要目的是验证设备双方所具有的链接秘钥Link key，即K_link是否一致，其包含有两个角色：申验者（Claimant）和验证者（Verifier），当然，一般来讲，它们也可以叫作外设（Peripheral）和中心（Central）。整个设备验证过程分为5个步骤^[5]：

1）验证者向申验者发送128位随机数（AU_RAND）。

2）申验者使用E₁算法并使用48位自己的蓝牙设备地址（BD_ADDR）、链接秘钥Link Key和AU_RAND作为输入来进行计算。验证者执行相同的计算。其计算获得的结果一共有128位数据，其中使用32位最高有效位（即SRES）用于认证，其余的96位称为ACO值，稍后加入到蓝牙会话加密密钥K_c的创建。

3）申验者将签名响应SRES返回给验证者。

4）验证者将申验者的SRES与其计算的值进行比较。

5）如果两个32位值相等，认证被认为是成功的。如果两个32位值不相等，认证失败。

设备成功验证后，就进入加密秘钥的生成以及消息的加密流程了，如下图所示^[5]：

首先，Master方（或者叫Central）会生成一个128位的随机数EN_RAND发送给Slave方（或者叫Peripheral），它们两者利用该EN_RAND以及链接秘钥Link Key、COF来通过算法E₃来计算获得加密秘钥K_c。这里的COF实质上就是前面的设备认证阶段生成的ACO，在协议规格说明书上COF的由来如下所示：

当然，这里的K_c为16字节，但是由于兼容性和功耗的考虑，蓝牙联盟最开始规定的加密秘钥长度可以是从1字节到16字节的，只要设备双方共同协商好。但由于之前的KNOB漏洞^[4]，其规定最低的加密秘钥长度改为了7，也就是说加密秘钥的长度，设备双方可以协商的最小长度为7。这个协商加密秘钥长度的过程就是图中的Constraining Mechanism，其根据协商的长度，从而去取K_c的前几字节的字段来获得最终的加密秘钥。最后使用该加密秘钥通过E₀算法来加解密明文数据包。

SC（Secure Connections）在Link key的生成、设备认证以及加密秘钥的生成这三个阶段的流程与SSP（Secure Simple Pairing）一致，只是使用的算法有差别。SSP的配对过程由于可以根据设备的IO能力选择不同的关联模型，因此十分灵活，其提供了四种方式：Numeric Comparison、Passkey Entry、Just Works以及Out of Band (OOB) 。这里关联方式的选择实质上对后面的流程是有一定影响的，如Just Works就不需要对Link Key进行验证，具体详情可以参考[4, 1573-1574]。这里我们还是按照需要验证Link Key的方式来进行讨论。

下图是[5]中描述的SSP的链接密钥Link Key的生成，值得注意的是这里使用的是ECDH公私钥对来进行生成的，而不是LSC那种使用PIN生成的对称密钥。图中的P-192和P-256为两种椭圆曲线算法，SC用的后者，SSP用的前者。其通过K_DH最终生成了链接密钥K_link。

设备验证阶段如下图所示，值得注意的是其与LSC不一样的地方在于，SC的设备双方都是申验者和验证者，即通信的设备既会验证对方的Link Key，也会被对方验证本方的Link Key，只要有一方验证失败，则这整个阶段都验证失败。而LSC只有一方（Central）是验证者。

接下来的加密密钥的生成以及加密算法如下图所示，可以看到其大致与LSC一致，不过采用的算法完全不一样，这里采用h3来生成加密密钥，使用AES-CCM来加密数据包。

BLUFFS攻击主要针对的是LSC机制的设备认证阶段和信息加密阶段。论文中主要强调的问题所在是加密密钥K_c（论文中为Session Key, SK），能够被用来解密之前的和以后的会话消息，也就是说，SK的生成算法存在漏洞，能够一直被使用，而不是每一个Session保证生成一个不同的SK，那么，一旦SK被破解，攻击者就可以利用该SK伪装设备，或者解密蓝牙通信的数据了。那么，下面我们就来分析该漏洞的所在以及论文里面的描述中是如何利用该漏洞的。

首先，我们需要知道：在链路层连接中，蓝牙连接的发起者被称作为Central，接受者称作为Peripheral，但是这两者角色可以通过协商进行变换，也就是说其中一方可以在连接后主动申请成为Central。这个是蓝牙协议的机制，也是BLUFFS漏洞利用的一个重要前提。另外，通信的蓝牙双方若是有一方不支持SC，那么他们就会使用LSC机制进行LK的生成、设备认证以及加解密消息等。

其次，我们在2.1.1节介绍了LSC的设备认证以及加密秘钥K_c的生成，论文中使用了一个实际案例进行了描述，其实质和2.1.1节所描述的一致，我们再来看论文[2]中的描述。如下图所示，Alice的蓝牙设备A与Bob的设备B进行通信，由于A只支持LSC，则它们之间的配对、认证和加密过程使用的就是LSC机制，A为Central，B为Peripheral，他们在之前已经生成了链路秘钥LK，即图中的PK（Pair Key）。那么，A与B就会进入设备验证阶段，A为验证者，B为申验者。整个流程为：

1）A向B发送AC_A，即2.1.1中的AU_RAND，一个由A生成的随机数。

2）B通过秘钥PK与接收到的随机数AC_A以及自己的MAC地址来BA_B计算获得CR_B，即SRES签名响应，发送给A，A进行检查，若一致则认证通过。

3）若上一步认证成功，则由A发起加密秘钥SK的生成阶段，这里的SE_A即是由A生成的随机数，在2.1.1中为EN_RAND，而这里的SD_A实际上是决定最终加密秘钥的长度的因子。

4）然后在A、B双方，都通过链路秘钥PK，B的MAC地址BA_B，以及A产生的随机值AC_A、SE_A以及设置秘钥长度的因子SD_A共同计算生成了加密秘钥SK，这里的计算方法统称为：KDF_LSC。

5）最后，A和B传输的数据使用SK进行加密。

以上的认证和加密流程有着一个可能的风险点就是整个流程是由Central，即A设备来主导的（包括参数的确定以及认证的检查校验），而这个Central是可以不需要任何权限和认证就能来协商确定的。这就是这个BLUFFS漏洞能够被利用的一个重要因素，下面我们参考论文来具体描述该漏洞。

前面我们通过一个案例Alice和Bob介绍了LSC机制的设备认证和加密秘钥的生成流程。BLUFFS漏洞的产生根源就是在LSC机制的这两个流程中的。根据论文的描述，若有两台蓝牙设备：Alice的设备A与Bob的设备B，它们之前正常配对连接过，即它们都在对方的已配对列表中，而此时如果有攻击者Charlie的设备C使用Alice的设备MAC地址来冒充Alice的设备A，并与Bob进行蓝牙连接，并且Charlie的设备C在连接过程中主动把自己的角色切换到Central，那么它就能够主导整个设备认证和SK的生成过程，包含SK的计算参数AC_A、SE_A以及SD_A，而这时它并不知道PK，这个PK是Alice和Bob在之前的配对连接时已经协商好了，并长期保存的。这里有三点需要注意：

1）由于Charlie不知道PK，那么在设备认证时，虽然它是验证者，但其无法通过PK来校验Bob传输过来的CR_B是否正确，那么Charlie会忽略此次校验，不进行校验，默认为直接校验通过。

2）SD_A实际上控制最终加密秘钥SK的长度Size的，前面我们描述过，在2019年KNOB漏洞出现之前，这个秘钥长度最小可以为1字节，KNOB之后改为7字节，攻击者Charlie能够利用SD_A控制Bob的设备生成的SK为最小长度，如7字节，这样做的目的是，通过其后续通信的加密过后的数据包来离线暴力破解加密秘钥SK，其长度越小，越容易被破解。这里的破解方式是不断随机7字节的数据作为秘钥来解密该加密数据包，而由于该加密的是蓝牙链路层的数据，因此其上层（如L2cap层）的一些头部Header数据是固定的，因此可以根据解密后的数据包的上层头部字段的值来判断解密是否成功。根据论文中的描述，破解7字节秘钥一般会需要几周的时间，如果采用分布式的高算力计算机群来破解可能只需要几天的时间，快的话可能只需1天。具体Charlie如何破解SK的将在3.1.1节进行描述。

3）攻击者Charlie破解了SK后有什么用呢？论文中给出了6个攻击场景，分别为A1-A6，如下图所示。实质上A1和A2，A4和A5在本质上是一样的。A1和A2指的是冒充只支持LSC的设备来欺骗其之前连接过的对端设备，这个对端设备的角色分别为Peripheral和Central，我们知道整个攻击成功的前提是攻击者设备为Central，这里无非就是当受害的对端设备为Central时，攻击者设备在冒充设备时主动发起协商请求把自己的角色变为Central。同理，A4和A5也是一样，只不过攻击者冒充的设备变为了能够支持SC机制。A3和A6分别说的场景是攻击者能够利用中间人攻击窃取/篡改正在正常通信的两个设备的通信数据，A3是这两个设备其中一个只支持LSC，表示他们之间的认证及加解密使用的LSC机制，A6是这两个设备都支持SC，采用的是SC的机制。实质上，这六个案例可以分为两类：冒充设备（A1、A2、A4和A5）和MitM中间人攻击（A3和A6）。我们在下一个章节来分析如何破解会话秘钥SK以及破解后的SK如何利用到这两类攻击场景中。

下图是论文[2]中描述Charlie冒充（伪装）为Alice与Bob进行设备认证和加密秘钥SK_C生成的过程，其中Alice和Bob之间在之前已经配对过，且生成了链接秘钥PK，由于PK是长期秘钥，其能够被用于在断开连接后的下一次连接会话时的认证和产生加密秘钥，对于Alice和Bob来讲，PK一直是被保存，因此一旦生成就是固定的（除非用户在已配对列表把对方设备删除）。

对于案例A1和A2，Alice是只支持LSC的设备，那么整个认证和秘钥生成流程就是LSC的流程，即使Bob支持SC。图中为Charlie使用Alice的MAC地址来连接Bob，可以看到，图里的加密秘钥SK_C已被Charlie破解。其实，若是最开始SK_C还没被破解，那么这里的整个流程可以同样的先做一次来用于SK_C的破解，这是因为，一旦Bob利用Charlie传输的参数AC_A、SE_A以及SD_A计算出SK_C，它就会使用SK_C来加密传输的数据包并发送给Charlie，Charlie获取到这些加密数据包后，就可以拿来离线暴力破解了（利用SD_A把SK_C的长度降为了最小长度7字节）。

Charlie破解了SK_C后，也同样利用这个过程，传递破解时的同样的值的参数AC_A、SE_A以及SD_A，那么Bob所生成的SK_C就和之前破解过的一致了。那么后面所有Bob传输的数据包都能够解密出来，Charlie就能够使用Alice的身份与Bob进行通信并使用Alice的各项服务能力了，如打蓝牙电话、听音乐、控制Bob设备等等。

当然，上面的案例的前提是使用的是LSC机制，即Alice和Bob其中之一只支持LSC，若是Alice和Bob都支持SC呢（即案例A4和A5）？那么，上述流程就不适用了，具体的探讨我们放在3.2章节漏洞影响中来介绍。

另外，这里实质上就做到了论文中所表达的威胁到前向和未来的数据加密，前向表示还未破解加密秘钥SK之前所传输的加密数据包能够在破解秘钥后解密数据，未来表示SK破解后可以一直利用该SK解密加密数据包了，即使重新开始会话，只要攻击者传输同样的值的参数AC_A、SE_A以及SD_A给受害者，就能够诱使受害者产生与破解时一样的加密秘钥SK。

这里的中间人攻击场景在论文中并没有进行一个具体描述，这里本文根据其冒充设备的攻击场景总结了两个利用场景：

1）使用KNOB的攻击方式，下图为KNOB的攻击流程图^[6]，可以看到Charlie篡改了Alice和Bob之间关于加密秘钥的长度设置的数据包（明文，因为加密秘钥还未产生），使得秘钥长度变为了1，因此，加密秘钥很容易被暴力破解。同理，目前加密秘钥规定的长度变为了7，破解难度变大，需要更多的时间（几天到几周不等）。但是，这种方式感觉不是论文所表达的，首先是因为这是KNOB所描述的问题，且已经被缓解了，其次是因为即使花很长时间破解加密秘钥SK，其实效性已经过了，它只能作用于本次session会话，即Alice和Bob要一直保持会话连接不断开，一旦断开，下一次连接时它们就会利用随机数AC_A、SE_A以及链接秘钥PK重新生成一个新的加密秘钥SK，导致之前Charlie所破解的秘钥不再适用。在实际使用中，蓝牙设备间很难保证一直保持会话连接不断开，因此，这个攻击场景很难实现，且与论文中所说的能够破解前向和未来的加密通信所背离（会话断开后，破解的加密秘钥不再适用）。

2）与3.1.1节所描述的那样，Charlie使用两个蓝牙设备分别冒充Alice与Bob通信以及冒充Bob与Alice通信，Charlie这两个蓝牙设备都切换到角色Central，然后分别诱使Alice和Bob产生7字节的加密秘钥_A和SK_B，它们并不是一样的值，这是因为SK的生成算法KDF_LSC其中一个参数为申验者的BA_B，即为Alice或Bob的MAC地址，由于它们的MAC地址并不相同，因此SK_A和SK_B不一样，Charlie分别离线暴力破解它们，然后再次利用3.1.1的方式使得Alice和Bob使用秘钥SK_A和SK_B。这个时候，由于攻击者Charlie成为了中间人，Alice所发出的数据包交给了Charlie，Charlie使用SK_A解密后，再使用SK_B加密，再传输给Bob，Bob会认为是Alice发出的包进行回应，反过来也是一样。这样一来，Charlie能够窃取和篡改Alice和Bob之间传输的所有数据。

这种方式，只要一次破解，就能够一直使用，即使当前会话session断开，下一次会话时还是可以诱使Alice和Bob生成其破解过的加密秘钥SK_A和SK_B，前提是只要SK的生成参数和之前一致。这里描述的攻击方式能够做到威胁到未来的会话通信，与论文中所表达一致。

首先，我们来探讨3.1节中描述的6个攻击场景，前面的描述的冒充设备和中间人攻击都是针对的LSC安全机制，即场景A1、A2、A3。而若Alice和Bob都支持SC的话，攻击者Charlie就没办法使用上述描述的攻击方式来冒充设备和中间人攻击了，这是因为，如2.1.2所描述的，SC在设备认证阶段是双向的，不像LSC那样由Central来主导，若攻击者Charlie冒充Alice来与Bob进行通信，在设备验证阶段，由于Charlie不知道PK的值，Bob对Charlie的验证会失败，会立刻断开与它的连接。

论文[2]中的实验结果也验证了这一点，如下图所示，这里的Chip和Device表示的是受害者的芯片和设备，即Bob的角色，其分为LSC和SC两类。对于LSC，所有案例（A1-A6）几乎都能成功，因为无论攻击者所冒充的Alice支持的LSC和SC，由于受害者Bob只支持LSC，因此它们之间使用的肯定就是LSC机制（向下兼容），因此就能够使用3.1.1和3.1.2所描述的攻击场景了。而若Bob支持SC，那么就要看Alice所支持的安全机制了，A1-A3案例是攻击者冒充的Alice只支持LSC，那么显然，攻击者可以攻击成功。而若Alice能够支持SC，那么其与Bob之间就会采用SC安全机制，导致攻击失败，即A4-A6案例会失败。这里有两个例外，Infineon CYW20819和Cypress CYW40707，我们猜测的原因可能有：1）它们的SC安全机制在实现时存在问题，少了一些关键校验；2）由于这两种芯片虽然支持SC，且之前也是使用SC与对端设备来进行设备验证，但它们能够支持在配对或连接阶段时对端设备从SC降级到只支持LSC，从而使得攻击者冒充的对端虽然支持SC，但攻击者使用的设备只支持LSC，使用对端设备的MAC地址与这两种芯片连接时，导致它们之间也使用了LSC来进行了认证。

因此，可以看到，该漏洞影响在于蓝牙通信双方存在一方只支持LSC安全机制，若是这双方都支持SC安全机制，那么该漏洞大概率无法被利用，攻击者无法攻击成功。

论文中总结了整个设备认证和加密秘钥生成的过程中可能存在的问题，其总结了4点，我们逐一进行分析：

1）LSC安全机制在加密秘钥SK的生成中，所使用的参数是单向决定的。前面我们已一直在提到，整个LSC的设备认证和加密秘钥生成阶段都是由Central所主导的，加密秘钥SK所需要的可变参数AC_A、SE_A以及SD_A都是由Central传输给Peripheral。这就导致了，一旦攻击者切换为Central就能够控制整个设备认证和加密秘钥生成阶段。

2）LSC安全机制在加密秘钥SK的生成时所使用的算法并没有使用真正的随机变量（nonce）。虽然参数AC_A、SE_A也是随机数，但它们能够被重复利用，导致每一次会话都能够生成相同的SK，使得该SK能够解密之前和之后的Session会话。

3）LSC 所生成SK的参数不受完整性保护。在SK的计算过程中交换的参数是在没有完整性保护的情况下发送。因此，欺骗设备或在会话上执行 MitM 的攻击者可以在不被发现的情况下操纵参数AC_A、SE_A以及SD_A。

4）把SC安全机制降级到LSC机制不需要安全认证，即SC或LSC的协商不受完整性保护。因此，受害者设备无论是否支持SC，攻击者设备始终可以把它们之间使用的安全机制降级为LSC。

参考文档：

[1]https://www.sigsac.org/ccs/CCS2023/program.html

[2]Antonioli D. BLUFFS: Bluetooth Forward and Future Secrecy Attacks and Defenses[C]//Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security. 2023: 636-650.

[3]https://www.bluetooth.com/learn-about-bluetooth/key-attributes/bluetooth-security/bluffs-vulnerability/

[4]Bluetooth SIG. 2021. Bluetooth Core Specification v5.3.

https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=521059.

[5]https://blog.51cto.com/u_11134889/2108064

[6]Daniele Antonioli, Nils Ole Tippenhauer, and Kasper B Rasmussen. 2019. The KNOB is Broken: Exploiting Low Entropy in the Encryption Key Negotiation Of Bluetooth BR/EDR. In 28th USENIX Security Symposium (USENIX Security 19). 1047-1061.