Method Confusion Attack on Bluetooth Pairing | IEEE Conference Publication | IEEE Xplore
引言
本文讲述一种蓝牙配对机制的设计缺陷。此漏洞允许两个设备使用不同的方法执行配对。在成功相互交互时，被攻击的设备并不知道方法混淆。此攻击即使在蓝牙的最高安全模式下也适用（MITM保护下）。通过方法混淆攻击，攻击者可以渗透受害者之间的安全连接并拦截/监控所有流量。
蓝牙会根据应用程序请求提供加密、身份验证和完整性保护。为了支持这些功能，必须在参与设备之间建立可信连接。此过程（配对过程）在首次使用时建立信任。首先，用户必须启用蓝牙广播，使该设备对其他蓝牙设备可见。接下来，在其他设备上启动配对过程。在配对结束时，两个设备都相互进行身份验证并共享一个密钥，以实现加密安全的数据传输。
对于配对过程来说，有多种配对方法（关联模型）。理论上，设备之间需要在配对方法上达成一致（可能需要用户参与），但实际上可以利用某种缺陷（所提的设计缺陷），从而使用不同的方法进行配对（方法混淆）。此外，蓝牙配对无法验证两个设备是否实际执行相同的配对方法。因此，执行完全不同配对方法的两个单独配对过程可能相互作用。即使用户参与了配对过程，也没有向用户提供足够的信息来识别这种方法混淆。
攻击者主要拦截并劫持两个设备（尚未建立信任连接）之间的配对尝试。随后，攻击者对两个受害者执行两种不同的配对方法（方法混淆）。此时，受害者假设正在与他们想要的同伴配对。攻击者现在获得了秘密信息，这些信息反过来又可以用来影响配对过程，使方法混淆以成功的配对结束。虽然受害者假设已经建立了可信的连接，但他们也与攻击者进行了配对，此时攻击者现在处于稳定的中间人（MitM）位置。
BLE在4.2 版本后开始支持低能安全连接（LESC，本文的攻击的主要目标）。其在曲线P-256上使用基于椭圆曲线的迪菲-赫尔曼ECDH密钥交换，此种方法对手无法通过被动窃听获取密钥。
配对过程
注：配对过程中，启动配对的是启动器I，应答设备的是响应器R。
在实际配对过程之前，两个设备会交换有关各自安全要求和输入输出功能（IOCap）的信息。
两个设备交换ECDH公钥信息并计算共享的DH密钥。—— 此时双方未验证彼此PK（PK1和PK2），通过这些PK建立起的共享密钥（DHK）不能受信任。
在此阶段，之前交换的PK才会进行验证。使用哪种验证方法（关联模型）取决于此前配对特征交换中收集的信息（IOCap）。两个设备会独立的选择验证方法。
关联模型主要有以下几种（NC和PE是攻击的核心）：
实际上并没有任何阶段验证双方是否使用了相同的关联模型（验证方法），正是因为这一点，才使得方法混淆攻击成为可能。（此阶段后，假定PK的完整行和真实性已经得到验证）
在此阶段，受信任的PK用于双方之间建立的安全通道。
LTK和MacKey来源于经过身份验证的PK（MacKey 对攻击的重要性不高）；f5是蓝牙规范中描述的加密密钥生成功能；NI和NR是在身份验证阶段交换的随机数；DHK是通过PK建立的共享密钥。
随后计算确认值Ea和Eb，它们会通过新的安全通道进行交换，并等待对方验证。（此步骤验证之前所有交换的值的完整性和真实性）
关联模型
NC通过创建待验证的PK的哈希和来验证PK。这个哈希和在两个设备上都以6位数字的形式显示给用户。如果用户确认这些数字在两台设备上相等，则验证密钥。
这个哈希包含随机数N和NR（为避免重放攻击——指攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性）。这些随机数按照特定顺序进行交换，在交换前有一条确认消息。确认信息确保在他们确定自己的随机数选择之前，不会知道对方的随机数。否则，攻击者将能够轻松找到并选择导致确认值 Va 发生冲突的随机数，这会增加错误批准不合法密钥的可能性。
PE要求其中一个设备选择并显示随机的6位密钥。此密钥必须由用户输入到其他设备中（具体由哪个设备显示数字，是根据IOCap选择）。
然后进行身份验证，对输入的密钥（20 bits）逐位进行验证（确保双方都拥有正确的密钥），如果该过程顺利完成，则将PK视作已通过身份验证。
每个设备都有单独的功能和安全要求，为了支持各种各样的设备，会根据配对设备的功能和安全要求，动态选择关联模型（验证方法）。在BLE中，使用配对特征（IOCap）交换来商定配对方法。对于关联模型，有三个特征值需要关注：
如果每台设备都有OOB数据，那么设置OOB-bit，两者使用OOB认证方法进行配对。本文攻击不适用于OOB模式，不做讨论。
如果没有设备设置MitM-bit，可以视作双方使用JW进行配对。由于JW没有提供MITM保护，因此本文也不做讨论。
如果MitM-bit被设置，则通过IOCaps来决定使用NC还是PE配对。
BLE 设备的广播会从三个通道（37、38、39）中的一个定期传输广播包。广播消息以设备地址开头，设备地址类型有：
如果启用了LE隐私，还有下面几种类型：
方法混淆攻击
方法混淆攻击针对BLE设备的配对尝试阶段（配对开始前的广播阶段），目标是实现MITM位置。攻击者会与双方设备进行R->MI和I->MR两个配对过程，一个通过NC方法配对，另一个通过PE方法配对（根据受攻击设备提供的 IOCap也分为了PoN和NoP两种攻击）。
攻击可能成功的原因如下：
首先需要I和MR进行配对，假定用户想要配对设备R和I。
R 开始广播自己，I 开始搜索广播消息。同时MR也进行广播（与R同名），此时用户可以观察到MR在I的配对菜单中，且MR与R无法区分（同名）。为了避免R出现在I的配对菜单里，需要屏蔽R的广播信号。
当配对请求到了MR后，MI会发起与R 的连接。此时I和R的通信都由M（MI和MR）处理，而MI和MR彼此共享信息，且可以访问彼此的变量和状态。
此种攻击下，I与MR执行PE配对，MI与R执行NC配对。下图显示了I和R的具体交互过程。
首先I和MR会进行配对，进行特征信息交换：
接着，触发MI和R的配对，MI开始与R进行特征信息交换：
然后，I 和 MR 以及 MI 和 R 同时分别的交换 PK。
首先，MR会暂停与I的配对过程（等待MI和R）。同时，MI与R进行身份验证（NC）：
接着，是I和MR的身份验证（PE）：
MR设置密钥rb = Va，用户在I上输入的密钥，也就是在R上显示的Va，所以在I上，ra = Va，也就可以得到ra = rb。
这个过程在用户看来，就是一个合法的PE配对模式，I要求用户输入6位数字，而R上显示了6位数字等待确认。
因为I和MR之前交换过PK，所以他们会计算相同的DHK(I, MR)，MI和R也是如此，计算出DHK(MI, R)。
首先I传输其确认值EI。MR收到I发来的EI后，MR会触发MI计算EMI，然后发送给R。
当用户确认设备R上的NC对话后，设备完成认证阶段，等待确认消息。当R现在接收到EMI时，它成功地验证了值，并向MI回复ER。因此，R和MI之间的配对成功完成。
MI收到ER后，丢弃该消息，触发MR计算EMR， 然后将这个值传输给 I。
I验证了收到的EMR之后，也完成了I和MR之间的配对。
自此，M 能够通过解密接收到的消息，并重新加密后转发它们来中继 I 和 R 之间的所有通信，但是I和R却不能察觉攻击者的存在。
仅当两个受害者都成功完成了身份验证阶段时，M 才会完成LTK计算和验证阶段。如果一个受害者没有完成身份验证阶段，配对过程最终会因超时而终止。通过这种方式，攻击者可以防止所谓的单侧配对。
NoP与PoN类似，唯一不同就是I和MR执行NC配对，MI和R执行PE配对。其攻击过程与PoN类似。
实现
本文设计了一个端到端的攻击框架，该框架共有三个组件：1)方法混淆攻击工具，2)选择干扰器，3)地址嗅探器（启用LE Privacy时使用），整个过程在蓝牙MITM平台BThack上实现。
BThack是一个完善的BLE协议栈，它允许应用程序以各种方式修改通信。作者将BThack与USB Cambridge Sililcon Radio, Bluetooth Dongles (CSR的蓝牙适配器，USB接口) 结合。
BThack应用程序允许自定义回调，以便在某些点中断状态机的控制流（I与MR等待MI与R）。
凭借BTstack的单线程设计，堆栈随后暂停执行并允许内存修改，然后再最终恢复（这可以简化MitM发起方和响应方的同步）。
BThack MitM应用程序由两个与内存无关的进程组成，分别包含独立的BLE堆栈。每个进程都与其单独的USB-BLE设备进行通信，并使用进程间通信IPC相互通信（通过IPC，它们能够同步虚拟设备的状态机和中继消息）。其中一个充当R的角色，而另一个充当I。
PoN攻击的实现方式如下：I连接到MitM响应程序（MR)。这会触发MI连接R。在MR的密钥生成过程中存在一个回调。触发时，回调等待MI和R完成NC，并将 Va 设置为密钥。配对完成后， I 和 R 之间的通信通过IPC转发。
为了确保I连接到MR，而不是R，需要阻止R的广播抵达I，同时不能干到其他设备（例如MR）的广播，所以需要对广播选择性干扰。也就是说需要识别广播中的广播数据包并有选择的进行干扰，且需要低延迟的实现（需要在数据包完成传输之前，就得发送干扰消息）。
本文采用Cayre等人的方法，使用nrf51 BLE芯片上的定制固件（需要使用三个，因为广播通道有三个）的地址匹配功能。
地址匹配功能能够配置4字节模式，如果发现该模式，则会触发数据包接收过程。此功能的用途是过滤传入数据包的报头地址，以提供选择性接收。如果接收到指定的数据包的报头地址，会停止接收数据包，并切换到传输模式，传输虚拟数据包。两次同时访问介质时造成的干扰会导致广播数据包的校验和不匹配;这会导致数据包在接收时被丢弃。
所有这些操作都是在硬件中执行的，没有CPU的参与，从而保证较低的延迟。
如果未启用LE Privacy，则广播地址是固定的，匹配广播地址的前四个字节；如果开启LE Privacy，广播地址随机，作者认为可以通过匹配本地名称来实现。虽然数据包布局可变，但是在相同型号/实现设备之间是一致的。
如果LE Privacy被启用，则会使用R的本地名称进行干扰。在这种情况下，框架还初始化一个可以禁用CRC检查（检测数据传输过程中是否出现错误）的嗅探器，以跟踪受害者响应器的地址。当它上线并发布广播时，它会不断扫描R。与此同时，BThack MitM应用程序在R的本地名称下开始广播。一旦BThack MitM应用程序报告连接尝试(从I到MR)，干扰器就会停止。然后，将R的当前地址从嗅探器传递到MitM应用程序，MitM应用程序随后在MI和R之间发起连接。攻击随后完成。
评估
作者通过四个步骤评估。首先，进行预测试，检验实际方法混淆攻击的干扰功能。然后，进行完整的端到端实验室测试，证明方法混淆攻击能够获得MitM位置。随后，实现在现成的设备。最后，进行了性能评估，以测量吞吐量和延迟。
通过一系列重复实验验证干扰功能（启用LE Privacy和禁止LE Privacy）。将R设置为可发现模式，并在启动干扰系统时尝试与R的配对。结果表明在所有测试中，均没有来自R的广播抵达I。
方法混淆攻击存在两种攻击变体，所以也有两种测试场景：
场景1：R的IOCap是DisplayYesNo；I的IOCap是DisplayKeyborad；攻击方案是PoN。
场景2：R的IOCap是KeyboardOnly；I的IOCap是DisplayKeyborad；攻击方案是NoP。
实验过程如下：将R置于广播模式，然后扫描可用设备。在扫描结果中检测到R的名称时，尝试连接到该设备。建立连接时，请求配对。当其中一个设备显示 6 位值，而另一个设备提示密钥字段时，传输并确认了该值。一旦配对导致加密连接，信息就会通过该通道进行交换。
两种情景都成功实现MitM攻击，攻击者能够窃听受害者之间交换的信息。通过将窃听的数据与受害者合法解密的明文进行比较，可以验证这一点。
作者同样测试了NoP和PoN两种攻击变体。
I是一加7 Pro（Android 9.0）、iPhone 11（iOS 13.4.1）和Thinkpad W540（Windows 10），这些设备的IOCap都是DisplayKeyborad。
R是：
其他与实验过程相同，攻击者均能够完成与受害设备的配对，并达到MitM位置。
作者测量了吞吐量和往返时间（RTT），总体而言，所实现的连接质量可以满足大多数应用的需求（最大为300ms）。
作者选择了40为受过高等教育并有技术研究经验的参与者进行测试，有37位的参与者完成了配对过程，并且攻击者实现了MITM；其余3位参与者没有完成配对，但40名参与者均未察觉出攻击。
（结论）用户不太可能发现两台设备执行了两个不同的配对模式：
修复策略
作者希望，可以通过协议本身（而不是修改协议）来防止方法混淆攻击。具体而言，就是建议PE使用的密钥必须与NC中显示的值明显可区分，例如，PE密钥的最低有效位设置为1，NC密钥的最低有效位设置为0。当期待PE密钥的程序收到NC密钥时，能够检测到并中止配对。
换句话说，就是在20位中的一位设置有效位，这样虽然会减少一半的值空间（攻击者可能更有机会暴力破解密钥），但是考虑硬件功能，值空间依旧足够大。如果不遵循这些更新的准则的设备可能会有50%的可能连接失败。但是作者认为这个方案的优点大于缺点，
此解决方案的优点是很容易修改到现有协议。首先，尝试支持此功能的设备不需要实现新的输入方法。其次，协议不需要改变。
