Apple拥有15亿台活跃设备，处于控制硬件和软件的独特位置，因此可以将新服务快速推向其所有平台（iOS，iPadOS，macOS，tvOS和watchOS）。结果，Apple目前在“ Continuity”的统称下销售了十二种不同的无线服务，例如AirDrop和Handoff。尽管这些服务改善了用户体验，但无线协议的设计和实现为攻击提供了广阔的空间。这已经通过对标准协议（例如IPSec协议）的多次攻击得到了证明。例如蓝牙，WEP，WPA2，WPA3 ，GSM，UMT和LTE。最近，有几项研究发现了苹果专有的无线协议中的严重漏洞。尤其是展示了Apple设备的可追踪性，这些设备在Apple专有的Apple Wireless Direct Link（）上连续传输自定义蓝牙低功耗（BLE）广播，用户标识和拒绝服务（DoS）攻击。AWDL协议和对AirDrop的中间设备攻击。尽管这些工作已经发现了几个漏洞，但它们仅分析了潜在攻击面的一小部分（十二个服务中的一个）。这种分析中最昂贵的部分是对复杂软件体系结构进行逆向工程，该体系结构实现了提供Apple服务所涉及的各种专有协议。但是，先前的工作对实际过程缺乏详尽的讨论。
本文提供了第一个结构化的指南，以逆向工程这些专有协议，该指南结合了先前工作的见识和研究者自己的经验。为了使指南更易于访问和可持续发展，发布了一个工具包用于对苹果无线生态系统进行半自动逆向工程。遵循本指南，分析了HO，UC和PWS服务使用的三种以前未记录的协议。发现了四个新颖的安全性和隐私漏洞，从设计错误到实现问题，再次证明了安全性问题。这些攻击启用了新的设备跟踪，DoS和MitM攻击。仅使用标准硬件（例如常规Wi-Fi卡和用于BLE通信的低成本micro：bit）为所有攻击提供概念验证（PoC）实施。
在本节中概述了Apple当前的Continuity服务列表，它们依赖的链路层协议，最后讨论了该生态系统中以前的安全性和隐私分析。
A.连续性服务
Apple当前的Continuity产品组合在下表中列出的十二种不同服务组成。它们全部用于传输潜在敏感的用户数据，例如剪贴板内容，电话，照片和密码。尽管Apple为其中某些服务提供了一些高级安全性说明，但实际的协议设计和实现仍是封闭源代码。到目前为止，迄今为止的工作已经深入分析了一种服务，即。例如，AirDrop。其他工作也分析了针对其他几种服务的BLE广播。但是，所涉及的上层协议仍然是未知的。在这项工作中，演示了逆向工程方法论，并使用它来分析以前未仔细研究过的三种服务所涉及的协议。简要描述了这三种服务的目的：
HO：HO允许具有多个Apple设备的用户在设备之间切换，同时保持在相同的应用程序上下文中。例如Apple的Mail应用程序：用户可以开始在iPhone上键入电子邮件，切换到Mac，然后单击Mac中的图标以继续编写电子邮件。第三方开发人员可以通过公共API向其应用程序添加类似的功能。
UC：UC在一个所有者的附近设备之间共享剪贴板内容。例如，它允许在Mac上复制文本并在iPhone上粘贴内容。
PWS：PWS服务允许请求方设备在尝试连接到Wi-Fi网络时向Wi-Fi网络请求密码。知道密码的授予者设备可以决定是否要与请求者共享密码。作为一个用例，它时研究者可以与家庭住客共享一个家庭的Wi-Fi密码。
B.无线链路层协议
简要介绍Apple Continuity服务中涉及的两个关键链路层协议，特别是AWDL和BLE。通过监视在使用每种服务时变为活动的接口，在上表中编译了服务到链路层技术的映射。
Apple无线直接连接（AWDL）：AWDL是基于Wi-Fi的专有链路层协议，可以与常规Wi-Fi操作共存。它提供了相邻设备之间的高吞吐量直接连接，并且以前已经过逆向工程。Apple使用AWDL作为UC和HO等几种Continuity服务的消息传输。
蓝牙低功耗（BLE）：BLE在与Wi-Fi相同的2.4 GHz频带内运行。它设计用于小型电池供电的设备，例如智能手表和健身追踪器，因此不适合大型数据传输。BLE广播包是一种广播机制，可以包含任意数据。当设备建立连接或与附近的设备共享其当前活动时，将使用广播。苹果在很大程度上依赖于定制的BLE广播来宣布其连续性服务，并通过Wi-Fi或AWDL引导各种协议。通用属性配置文件（GATT）是BLE协议，用于发现服务和与对等设备进行通信。UUID标识单个服务，每个服务可以包含多个特征值。客户端连接到服务器设备并访问服务的特征。客户端可以向特征写入数据，从特征读取数据或从特征接收通知。Apple使用GATT作为消息传输。
本节旨在提供结构化的方法，以进行Apple无线协议的逆向工程，同时使用对连续性服务进行分析的实际示例。首先展示有用的优势。解释了二进制分析方法，并分享了对动态分析的见解。然后说明如何访问Apple服务的安全密钥材料，并讨论方法论对Apple生态系统中其他协议的适用性。最后介绍了为方便进行逆向工程而开发的几种工具和脚本。在本文中分析的所有服务都可以在macOS 10.15和iOS 13上使用。iOS和macOS共享了大部分代码，并且由于发现macOS比iOS更开放和可访问，因此使用macOS作为平台。
本节介绍的大多数方法也可以应用于iOS。对于其中一些（例如，完整密钥串访问），研究人员需要越狱的iPhone。自从发现一种名为checkm8的BootROM漏洞并引入了checkra1n以来，越狱已变得广泛可用，并支持所有iOS版本。
A.有利位置
从下图中描绘的不同角度进行协议分析。（1）静态二进制分析很难进行，因为每个协议都是跨多个组件（框架和守护程序）实现的。因此，在初始阶段，对整个系统进行监视（2）以确定可以随后进行彻底检查的核心组件是很有用的。同样，通过（3）网络接口传输的数据可以使用监视工具轻松访问，并且对于动态分析非常有用。发现检索和使用（4）持久数据（尤其是从系统的密钥串中获得）的能力对于构建原型并从而验证结果至关重要。最后，任何可用的（5）文档（图中未显示），例如专利或Apple的平台安全性白皮书，都有助于初步评估和理解服务的某些设计元素。拥有这些多个有利位置使我们能够收集更多信息，如果遇到困难（例如，遇到加密的流量时），则可以更改视角，并在以后的某个点（例如，在提取解密密钥之后）恢复分析。接下来，在下图中详细说明四个有利位置。
B.二进制分析
本研究分析了许多与Continuity服务相关的二进制文件，以找到最终实现该协议的那些部分。首先说明选择过程，然后讨论由两部分组成的Wi-Fi驱动程序，该驱动程序实现了大多数AWDL协议栈。将分析重点放在macOS上，并假设该架构在原则上与iOS相似，因为两个操作系统（OS）共享一个大型通用代码库。
（1）二进制概览
了解和浏览macOS的二进制格局对于查找和关联感兴趣的组件至关重要。
框架和守护程序：Apple在其OS中过度使用框架和守护程序。因此，众多的依赖关系导致了复杂的二进制选择过程。框架为其相应的单例守护程序提供API，并且可以由其他守护程序和进程使用。守护程序及其各自的框架通常具有相似的名称（例如，sharingd和Sharing）或共享派生的前缀（例如，searchpartyd，SPFinder和SPOwner）。在下面列出文件系统中的位置。/System/Library /Frameworks包含带有公共文档的框架，例如Security。/System/Library/PrivateFrameworks包含其他框架，如Sharing。/usr /libexec和/usr /sbin包含大多数守护程序，例如sharingd。但是，有些也以各自的框架提供。/usr/lib和/usr/lib/system包含低级库，例如CoreCrypto。
驱动程序：Wi-Fi驱动程序是内核扩展，因此位于/System/Library/Extensions中。该驱动程序分为一个通用组件（IO80211Family）和特定于芯片的插件（例如AirportBrcmNIC）。
（2）二进制选择
初始选择：过程的目的是识别可能包含相关代码的二进制文件，从而设置分析项目的范围。要开始此过程，可以使用系统的日志记录工具来识别在启动特定系统函数（例如AirDrop）时变为活动状态的过程。如果至少确定了一个守护进程，则可以通过运行otool -L来查找相关的框架和库，从而递归地浏览其依赖关系。在上图中显示了为HO找到的已发现依赖关系和交互的一部分。
（3）函数和代码段
由于分析的大多数二进制文件（例如sharedd守护程序）的大小，无法分析整个程序。相反，有意义的是识别感兴趣的函数，例如那些执行帧处理的程序。幸运的是，Apple不会从它们的（大多数）二进制文件中剥离符号名称，以使符号表提供有用的信息，例如。例如，在Rapport框架中列出了包括-[RPConnection_receivedObject：ctx：]在内的函数名称。解密后，此函数处理通过AWDL共享的接收消息。此外，调试日志语句可提示有关函数内部代码段的用途。因此，可以搜索调试字符串（使用字符串）及其交叉引用以查找其他详细信息。
C.系统日志
仅二进制分析很难理解完整的协议操作，用动态方法补充了静态分析。在本节中，讨论专用的macOS日志记录和调试工具，这些工具在分析过程中会有所帮助。特别是解释了控制台应用程序。但是，以前的工作也使用ioctl接口，Broadcom泄漏的wl实用程序和Apple未记录的CoreCapture框架来分析Wi-Fi驱动程序。控制台汇总自macOS 10.12起的所有系统和应用程序日志，并包括来自内核的调试消息。或者，可以使用log命令行工具访问相同的信息。
过滤感兴趣的输出：可以过滤日志输出，例如，通过过程或子系统。在日志的手册页上详细介绍了基于谓词的过滤。例如，要获取有关HO的信息，可以使用
工具使用此功能来识别记录有关特定系统服务（如AirDrop）信息的流程和框架。
增加日志级别：—level调试标志将增加使用os_log的进程的日志详细程度。另外，某些进程记录私有数据（例如密钥）。为此可以设置
从macOS 10.15开始，该命令不再可用，需要禁用SIP。
D.网络接口
监视Wi-Fi和Bluetooth网络接口是一种收集有关特定服务信息的快速方法。例如可以识别已知协议，是否使用加密，或者确定是否在处理未公开的协议。此外可以了解有效的无线通信通道，数据包传输的时间，并通常监视协议的动态。在下文中，讨论了发现对于此目的特别有用的那些工具。
（1）Wireshark
Wireshark 是一个开源网络协议分析器，支持许多标准化但专有的协议。虽然Wireshark从网络跟踪中识别已知协议，但也可以实现自定义分析器。发现与逆向工程流程并行编写这样的自定义分析器有多个目的：（1）迭代地记录和验证本文发现。（2）有助于推断各个字段的语义。例如，随机的随机数将在每次握手中发生变化，而静态密钥或证书将保持不变。（3）通过tshark导出时间序列数据，可用于评估实验。
（2）蓝牙资源管理器和数据包记录器
Apple在Xcode的附加工具包中附带了两个蓝牙调试工具，蓝牙资源管理器实时显示附近的BLE设备及其广播。苹果设备过度使用这些广播来宣布诸如AirDrop之类的服务的可用性。BTLEmap为这些广播中的大多数实现了分析器。另一方面，PacketLogger为Bluetooth HCI命令创建网络跟踪，因此提供了InternalBlue的某些功能。Wireshark支持PacketLogger记录的.pklg文件，可以方便地分析蓝牙轨迹。
E.密钥串(Keychain)
对特定服务或协议使用的私钥和其他安全数据的访问在做出关于可以采用哪种安全机制的有根据的假设时非常有用。同样，提取关键材料对于构建和测试证明或否定工作假设的原型至关重要，例如验证对经过身份验证的PWS连接的要求。
（1）macOS密钥串
在macOS 10.15中，有两种类型的密钥串分别称为login和iCloud密钥串。前者仅存储在本地计算机上。iCloud密钥串首次在iOS中引入，此后也已移植到macOS。该密钥串提供了更多功能，例如保护等级，设备之间的可选同步以及改进的访问控制。随着苹果将更多的密钥串项目从登录密钥串转移到iCloud密钥串，相信苹果将来会合并它们。密钥串访问应用程序是一个用于显示和使用任一密钥串的GUI。但是，发现并未显示所有的密钥串项目（例如，某些系统服务所使用的那些项目）。
（2）安全框架
幸运的是，Apple提供了一个文档化的API，用于通过Security框架访问密钥串，该框架另外是开源的。出于研究目的，SecItemCopyMatching函数尤其有趣，因为它允许从密钥串中检索诸如钥匙之类的物品。该函数需要一些查询参数来缩小应返回的项目的范围。为了获取目标程序的相关查询参数，可以通过搜索对SecItemCopyMatching的引用来静态分析二进制文件，也可以监视进程并在运行时使用调试器提取参数。对于PWS，查询由三个键组成：kSecClass，kSecReturnRef和kSecValuePersistentRef。后者的值是一个序列化对象，其中包含在钥匙串中定位特定项目所需的所有信息。
（3）访问Apple服务的密钥
作为安全措施，即使使用正确的查询参数，非Apple签名的程序也不会获得任何结果，因为Apple使用代码签名来实现对密钥串项目的访问控制。为了规避此措施，（1）需要在代码签名期间设置正确的keychain-access-group权利（在HO或简单的*通配符的情况下为com.apple.rapport），以及（2）禁用Apple Mobile File Integrity（AMFI） ，这样可以通过将以下内容设置为引导参数来阻止具有有限权利的程序启动：amfi_get_out_of_my_way = 1。
F.自动化逆向工具包
通用协议的自动化逆向工程是一个难题。但是发现了几种在Apple平台上自动化部分流程的可能性，以使本文工作更具可持续性。本研究发布了一个工具包，该工具包涵盖了本文发布时本节中提到的所有优势。特别是，该工具包允许（1）根据关键字发现有趣的守护程序/框架和函数，（2）提取由rapportd使用，由Continuity服务交换的纯文本消息，以及（3）打印系统中存储的所有机密信息特定守护程序使用的密钥串。接下来将详细介绍各个工具。
（1）识别二进制文件
工具包包含一个Python脚本，该脚本扫描系统日志消息中的指定关键字，并列出发出的守护程序，框架和子系统。然后，该工具可以递归搜索那些二进制文件及其依赖项（框架和库），以查找相同或其他的字符串和符号。最后，用户收到二进制文件和函数的初始候选列表以进行进一步分析。
（2）提取纯文本连续性消息
分析表明，许多连续性服务都使用rapportd提供的安全运输服务。与HTTP MitM代理类似，工具包允许在加密（发送）之前和解密（传入）之后提取交换的纯文本消息。在内部，该工具将lldb调试器附加到关系上，并在各自的发送和接收函数处使用断点来打印所有交换的消息。
（3）打印密钥串
连续性服务使用不同的安全机制来保护其通信，例如AirDrop中的TLS或自定义加密，所有这些都需要一个或多个秘密输入，例如私钥，证书或令牌。工具包提供了一种自动识别和提取这些输入的方法，以帮助构建自定义原型，从而使方法自动化。该工具基于FRIDA框架]，以便在特定进程访问密钥串时将代码注入安全框架以记录秘密。
A.接力和通用剪贴板
本文分析了HO和UC服务中涉及的协议。HO允许用户在其另一台Apple设备上的应用程序中继续其当前活动。UC允许用户在一个设备上复制剪贴板内容（例如，文本），并且（无缝地）将其粘贴到另一设备上。对于HO或UC，所有涉及的设备都必须登录到相同的iCloud帐户，并已打开蓝牙和Wi-Fi。发现HO和UC的协议是相同的。接下来，介绍不同阶段涉及的服务要求和协议：（1）使用BLE广播和mDNS-over-AWDL的发现阶段，（2 ）派生会话密钥的认证阶段，以及（3）传输应用程序数据的有效载荷传输阶段。
（1）要求
苹果公司将HO和UC设计为可在同一用户的设备之间工作。例如，登录到同一Apple帐户的设备。发现iCloud密钥串同步了长期设备特定的公共密钥PL，该公共密钥可以在名称RPIdentity-SameAccountDevice下找到。这些密钥用于经过身份验证的会话密钥交换。
（2）BLE发现
HO和UC都通过BLE广播在主机系统上宣布用户活动，例如剪贴板复制事件。接收设备使用嵌入的信息，例如，在系统扩展坞中显示启用了HO的应用程序的图标，如下图所示。单击该图标（HO）或粘贴事件（UC）会触发该图标。协议栈的其余部分。
BLE广播使用已经描述过的Apple的自定义框架结构，并利用制造商数据添加自定义字段。这些字段被编码为TLV8结构，这样一个帧就可以包含多个字段。Apple为其Continuity服务使用不同的字段类型。下图显示了类型为0x0c的HO和UC广播的有效负载。它包含一个明文状态标志，一个IV，一个身份验证标签，后跟一个加密的有效负载（以灰色显示）。苹果使用AES-GCM通过专用的BLE加密密钥K-BLE进行加密和身份验证。对于每个新广播，例如在新的HO或UC活动中，初始化向量（IV）会增加1。设备耗尽其IV空间（2^(16)）后，设备会通过伴随链接服务触发密钥更新协议以更新K-BLE。密钥更新协议使用长期密钥PL进行身份验证。
加密的有效负载主要包含活动类型和其他状态标志。活动类型指示已触发的应用程序或活动，并被编码为应用程序特定字符串（例如com）的截断的SHA-512哈希例如NoteApp的com . apple . notes . activity . edit – note，不支持的应用程序活动将被忽略。状态B标志类似于明文状态A。显然，Apple已弃用了状态A，而改为使用状态B。发现状态B可以编码更多信息，如下表所示。假设状态A是早期协议版本的一部分，并且苹果保留了它以便于向后兼容但开始加密包含更多敏感信息（活动类型）的新字段。
为了促进对广播的动态分析，实施了一个macOS应用程序，该应用程序解密和解析与用户的iCloud帐户关联的设备发送的所有广播。
（3）使用mDNS-over-AWDL进行发现
可以将广播BLE广播的设备描述为可以响应来自客户端设备的请求的服务器。参与活动后，接收到服务器BLE广播的客户端设备将使其AWDL通过mDNS和DNS服务发现（DNS-SD）（也称为Bonjour）启动服务发现。
查询的服务类型称为_companion-link._tcp.local。来自服务器设备的DNS响应包括指针（PTR）记录中的实例名称，服务（SRV）记录中的主机名，IPv6地址（AAAA）和文本（TXT）记录。值得注意的是，Apple为通过AWDL传输的SRV记录实现了主机名随机化（类似于介质访问控制（MAC）地址随机化）。TXT记录通常用于传输有关服务的其他信息。HO TXT记录包含以下示例中显示的信息：
发现值rpBA和rpAD用于标识两个设备是否都链接到相同的iCloud帐户，并过滤掉可能通过打开的AWDL接口响应的其他设备。特别是发现rpBA（编码为MAC地址字符串）是随机选择的，并且至少每17分钟更改一次。rpAD是由随机rpBA和设备的蓝牙身份解析密钥（IRK）（用于解析随机BLE地址）作为SipHash函数的参数生成的身份验证标签。由于IRK是通过iCloud密钥串同步的，因此登录到同一iCloud帐户的设备可以尝试密钥串中所有可用的IRK来查找其他设备。
（4）通过配对验证
用于HO和UC的伴随链接服务使用长期密钥PL进行相互认证，实现了经过身份验证的椭圆曲线Diffie-Hellman（ECDH）密钥交换。新的会话密钥用于加密后续消息。所谓的配对验证协议基于Apple的Homekit配件协议（HAP）协议，握手如下图所示。它主要执行ECDH，以与临时密钥对（Ps，Ss）和（Pc，Sc）交换会话密钥K。使用Ed25519签名对公用密钥Ps和Pc进行身份验证，该签名使用长期服务器密钥和客户端密钥对（PsL，SsL）和（PcL，ScL）进行生成和验证。验证密钥PsL和PcL使用iCloud密钥串同步。然后，两个设备都使用HKDF从新的会话密钥K导出服务器密钥Ks和客户端密钥Kc。这些密钥用于通过ChaCha20-Poly1305密码保护后续的有效载荷传输。
消息格式由TLV248编码组成，而TLV248编码又包含一个OPACK字典，该字典在键_pd下具有单个值。该值包含TLV8结构，这些结构对用于密钥交换的各个字段进行编码。OPACK是专有的未记录序列化格式，将其规范与示例实现一起发布在Python中。
（5）有效载荷转移
要传输实际的应用程序有效负载，例如剪贴板内容（UC）或用户活动（HO），随播链接服务使用身份验证协议中的Ks和Kc密钥实现另一个由ChaCha20-Poly1305保护的四向通信协议。协议首先交换设备的系统信息（上图P1和P2），其中包括设备型号。例如MacBook11,5，设备名称和几个标志。之后，客户端请求并接收特定于应用程序的有效负载（P3和P4）。HO开发人员API可以通过建立从服务器应用程序到客户端应用程序的直接套接字连接来传输附加数据。如果开发人员指定，则共享将打开TLS连接（长有效载荷传输）。并将打开的套接字传递给请求的应用程序。TLS连接通过使用与AirDrop和PWS相同的Apple ID证书和验证记录对双方进行身份验证。发现UC还使用相同的协议来传输大于10240字节的剪贴板内容。在这种情况下，UC使用P3和P4消息来引导TLS连接。
B.Wi-Fi密码共享
Apple还使用BLE来实现一项称为PWS的服务，该服务使用户可以与来宾和朋友共享已知的Wi-Fi密码。这项服务旨在解决通常手动输入密码的麻烦，如果密码太复杂或手边没有密码，有时这将是一个挑战。在下文中，将调用搜索Wi-Fi密码请求者的设备和共享密码授予者的设备。
在选择要连接的SSID后打开密码视图（上图a中）时，PWS自动启动。请求者的用户不需要进一步的用户交互。只要密码视图处于打开状态，周围的设备就会收到有关PWS的通知。如果授予者在范围内，则会弹出密码共享对话框（上图b中），要求用户共享密码。如果授予者接受，它将加密的密码发送给授予者。密码文本字段中已经输入的可能字符已被覆盖，插入了共享密码，并且设备自动尝试连接到Wi-Fi网络。
PWS协议包括在上图中描述的四个阶段：（1）使用BLE广播引导协议的发现阶段，（2）初始化阶段传输协议元数据，（3）认证阶段，其中请求者向授予者证明其身份并获得一个对称密钥，最后（4）转移预共享密钥（PSK）的共享阶段用于请求的Wi-Fi网络。在下文中，首先描述协议要求并讨论基本的BLE数据传输。然后，详细讨论四个主要协议阶段。
（1）请求
Apple旨在通过最少的用户交互来解决Wi-Fi密码共享的问题。他们的设计具有以下要求：（1）授权者需要将请求者的联系信息（电话号码或电子邮件地址）存储在其地址簿中。（2）授予者需要解锁。（3）请求者需要使用Apple ID登录。（4）两个设备都需要启用蓝牙。
（2）BLE数据传输和帧格式
使用GATT特性的value属性，所有发送和接收的消息都通过BLE传输。请求者充当授予者连接到的GATT服务器。授权者通过写入此GATT特性将消息发送给请求者。该特征还支持通知标志，请求者使用该标志进行响应。即使GATT字符istic的最大有效载荷长度设置为512字节，有效载荷也最多拆分为101个字节的数据包。为了能够在另一端重组完整的有效负载，有效负载的长度包含在第一个数据包的前2个字节中。
GATT特性支持多种服务。为了支持这一点，每个有效负载都被包裹在SF Session10帧中。该帧由服务类型和帧类型组成，后面是实际有效负载。对于特定服务，服务类型是恒定的。例如，PWS使用服务类型0x07。帧类型用于区分同一服务的不同帧。
（3）通过BLE广播发现
请求者发出BLE广播以通知周边设备。帧格式遵循与HO / UC相同的基本结构，但使用单独的类型。上图显示了TLV8类型为0x0f的PWS广播的帧格式。有效负载包括所有者的Apple ID，电子邮件地址，电话号码以及请求者为其请求密码的SSID的SHA-256哈希的前3个字节。
周围设备检查其任何联系人是否与哈希的联系人标识符之一匹配，以及它们是否具有用于提供的SSID哈希的密码。如果两项检查均成功，授予者将通过密码共享对话框提示其用户（前图b）。
（4）初始化和Wi-Fi密码共享
首先，授予者为新会话生成一个临时性的Curve25519密钥对，并发送包含公共密钥Pc的开始请求（M1）。接收到请求者后，生成另一个密钥对。如上图所示，开始响应（M2）包含请求者生成的公共密钥Ps，Apple ID证书Cs，Apple ID验证记录Vs和签名σs。除公钥外，所有字段都用ChaCha2的共享密钥和HKDF的密钥进行加密。加密的字段打包在另一个TLV8中。Apple ID证书和验证记录均由Apple签名，并且也用于AirDrop协议中。验证记录通过通用唯一标识符（UUID）与Apple ID证书绑定。特别是，UUID包含在验证记录和证书的通用名称中。验证记录还包含Apple验证的联系人标识符，并且授予者可以使用它来验证请求者的身份。Apple ID证书用于对两个公钥进行签名，即例如，σs= sign（Pc + Ps，ks），这向授予者证明，发送此数据的设备实际上拥有以Cs验证的私钥ks。该签名也包含在加密的TLV8中。在完成请求（M3）中，授予者加密一个空字符串，并将包含16字节Poly1305身份验证标签的密码发送给请求者。最后，完成响应（M4）包含一个固定状态字节（0x4），并完成了握手。
根据对多个连续性协议进行逆向工程的结果，对iOS和macOS平台进行了全面的安全性和隐私分析。特别是发现了针对HO和UC的协议级DoS攻击；一种利用多个设备标识符的异步随机间隔的设备跟踪攻击；对PWS的MitM攻击，导致受害者连接到由攻击者控制的Wi-Fi网络；以及针对PWS的DoS攻击，阻止用户连接到新的Wi-Fi网络。提供了一个缓解方法，可以缓解以前发现的设备跟踪漏洞，对下表中的漏洞进行了概述。在下文中，首先描述了常见的攻击者模型，然后详细讨论了各个漏洞，攻击实现方式，并针对发现的问题提出了可行的缓解措施。
A.攻击者模型
对于以下攻击，认为攻击者是：
•可以使用低功耗蓝牙无线，并且可以使用可以用作接入点的Wi-Fi无线，
•与目标设备在物理上接近（更准确地说，在无线通信范围内），
•是否处于非特权位置，特别是，它们（1）不需要有关其目标的任何联系信息，（2）不需要与目标进行现有的蓝牙配对，并且（3）不需要访问相同的Wi-Fi网络。
B.通过IV异步进行DoS
在HO和UC BLE广播中利用短的AES-GCM身份验证标签来强制客户端和服务器之间进行IV不同步，从而使HO和UC无法使用。Apple已部署的重播保护机制无法防御这种攻击，因此要求用户重新启动设备。
（1）漏洞：低熵身份验证标签和基于IV的重播保护
HO BLE广播使用带有一个字节的身份验证标签和两个字节的IV的AES-GCM进行加密。广播中使用的IV是一个线性增加的计数器，以避免使用相同的键重复使用IV。每当收到成功通过身份验证的广播时，接收方就会使用当前的广播更新最后一个有效的IV。从那里开始，IV小于或等于当前的任何经过身份验证的广播都将被丢弃。
除了重播保护，还观察到每当身份验证失败时，HO都会触发重密钥协议。在这种情况下，HO假定发送设备已更新其HO密钥K BLE，并向发送设备查询其当前密钥和IV。此密钥更新协议在AWDL上运行，并使用与HO和UC相同的过程来保护通信。但是观察到，如果返回的密钥-IV对与当前存储的密钥对匹配，则不会交换任何新密钥。
（2）攻击：触发连续密钥更新
在下文中，将C表示为存储链接服务器设备S的密钥-IV对的客户端设备。攻击的目标是在C处更改密钥-IV对的IV计数器，以便基于IV重放保护机制将丢弃S的将来有效广播，因此C不再能够从S接收新的UC剪贴板数据或HO活动。为实现此目标，攻击者应该：
1）生成有效的HO广播，
2）通过将S的BLE MAC地址设置为广播的源地址来进行欺骗，
3）将有效载荷中的IV设置为最大值，
4）发送256个广播副本以暴力强制所有身份验证标签值。
该攻击之所以有效，是因为Apple设备使用BLE广播中的共享密钥和IV来验证身份验证标签。在攻击中，发送了255个带有无效标签的广播，这些广播被全部丢弃，并触发了无效的重新加密事件。但是，一个广播将具有看似有效的身份验证标签。如果包含的IV大于当前存储的IV，则C更新IV，然后处理解密的有效载荷。至此，攻击者已经实现了他们的目标，并且他们无法伪造有效载荷也没关系。由于C处的IV已更新，因此C将丢弃S中的任何后续广播，因为所有后续广播都包含小于或等于0xffff的IV。
为了对附近所有设备配对发起攻击，用观察到的所有BLE MAC地址重复此攻击。由于只需要发送一个BLE广播，一个20美元的micro：bit就足以发起攻击。我们使用BLESSED开源BLE堆栈[16]构建了PoC。
（3）缓解措施：更长的身份验证标签
为了缓解攻击，建议增加身份验证标签的长度。美国国家标准技术研究院（NIST）建议使用128位，而BLE广播中的制造商数据只能携带24个字节。由于当前的HO广播已经使用了16个字节，Apple可以添加一个新的64位身份验证标签，并保留当前的标签以向后兼容。将搜索空间增加到2 64将有效地防止基于网络的暴破攻击。请注意，限制“每个密钥的验证尝试失败的次数” 是不适当的缓解措施，因为它会引发新的DoS攻击，攻击者可以在该DoS攻击中施加限制并阻止进行合法的验证尝试。
C.通过线性IV跟踪设备
即使苹果公司在BLE中采用MAC地址随机化，HO广播中线性增加的IV仍可用于长期设备跟踪。问题在于，当BLE地址更改时，IV保持稳定。在下文中提出了一种实用的缓解措施，用不可猜测的伪随机序列代替线性计数器。
（1）缓解措施：更改IV顺序
为了防止通过线性IV进行跟踪，建议使用具有以下属性的改组IV序列：
1）序列的长度为2^(16)，并且一次包含0到2^(16)-1的所有整数值;
2）发送者可以在恒定时间内选择序列中的下一个值;
3）接收器可以以恒定的时间告诉值x是否位于序列中的y之前或之后;
4）发送者和接收者只需要共享一个秘密;
5）给定序列中的任何值，对手将无法猜测序列的下一项或上一项。
下图显示了候选算法，用于在Knuth随机播放中生成随机序列。它使用伪随机数生成器（PRNG）以及从共享BLE加密密钥K-BLE派生的种子，并生成计数器到IV的映射。在内部，每个HO设备现在都保留一个内部递增计数器c，并将fMap（c）用作下一个广播的IV。请注意，每当MAC更改以同步标识符随机化时，发送设备上的c也应增加。该算法还生成反向IV到计数器映射，以在恒定时间内确定接收到的IV x是在当前计数器c之前还是之后，这可以通过将c与rMap（x）进行比较来完成。
虽然从开销的角度（恒定时间查找）来看，缓解措施是切实可行的，但它并不向后兼容，因为它会破坏Apple设备当前使用的重播保护机制。另外请注意，由于该序列基于HO键，因此每次发生重新键入键事件时，算法都需要重新运行。
D.通过异步标识符随机跟踪设备
当使用诸如HO或UC之类的连续性服务时，AWDL会明确发出多个设备标识符，例如MAC地址和主机名。尽管Apple为这些标识符实施了随机化方案，但发现间隔有时不同步，并允许连续的设备跟踪。AWDL使用Wi-Fi，并且本身不提供身份验证或加密。相反，Apple推迟了对上层协议的保护。因此，攻击者可以监视通过空中发送的所有数据包。
（1）漏洞：异步标识符随机化
苹果已经为AWDL实现了MAC地址随机化。在2019年，Apple在通过AWDL发送的Bonjour服务广播中还引入了主机名随机化。在本文中，发现Apple在DNS服务广播的TXT记录中引入了新的设备标识符rpBA。苹果设备会在一段时间后重新生成（或随机化）每个标识符。但是，这不会同步发生。
（2）攻击：合并标识符
标识符可能会重叠，从而使设备跟踪的时间长于随机化间隔的时间。要实际发动此类攻击，攻击者只需在其目标的Wi-Fi通信范围内。特别是，攻击者需要Wi-Fi卡并将其调谐到44或149频道（取决于国家/地区）并监视AWDL帧。使用一种简单的匹配算法，该算法可以存储当前标识符并在接收到新帧时对其进行更新，攻击者可以连续跟踪其目标。
本研究在办公室环境中进行了一项实验，以演示问题和攻击并在上图中显示跟踪iOS 13设备的示例性结果。该图描绘了该设备发出AWDL帧的时间（顶栏）。下面的条显示了第一次和最后一次记录特定的随机标识符的时间，因此清楚地指示了发生重叠的时间。例如在上图中，rpBA与其他标识符重叠35≤t≤38min。注意到IPv6和MAC地址的间隔是完全同步的，因为本地链路的IPv6地址是从当前MAC地址派生的。还值得注意的是，各个标识符的随机间隔差异很大，范围从少于一分钟（主机名）到超过35分钟（rpBA）。
（3）缓解措施：同步随机化
要了解为什么与rpBA重叠和出现长间隔，分析了CoreUtils框架中的-[CUSystemMonitorImp_rotatingIdentifierMonitorStart]函数。发现该函数将计时器设置为17分钟以随机化rpBA值，但是使用了低级API11，该API11允许系统推迟调用以节省电量。此计时器值既不会与其他计时器同步，也不会定期更新，这导致了分析的重叠。
为了减轻这个问题，建议标识符的随机化间隔应该被同步或者至少不重叠（例如，主机名和MAC地址）。另外，建议任何标识符的随机间隔不应超过15分钟。建议引入系统范围内的随机化API，以防止回归并容纳将来的标识符。
E.通过Wi-Fi密码自动填充的MitM
利用PWS协议中的单面身份验证为请求者自动填充Wi-Fi密码字段，从而使iOS或macOS目标连接到攻击者控制的Wi-Fi网络，并将攻击者提升到特权MitM位置。此位置允许进行辅助攻击，例如DNS欺骗或流量分析。此外，攻击者还可以通过触发Safari漏洞利用来破坏目标设备。
（1）漏洞：单方身份验证
MitM攻击利用了PWS各方需要提供的信息不对称性：按照Apple的设计，请求者必须提供经过认证的联系信息，而授予者则不能提供经过认证的联系信息。在案例中，攻击者充当授予者，因此不需要掌握有关其目标的任何信息。下面就这个问题进行详细阐述。
前文描述了请求者使用由Apple签名的验证记录和Apple ID证书向授予者证明其身份。因此，授予者可以验证请求者在其广播中拥有联系人标识符。相反，请求者不检查授予者的身份。即使授予者的哈希联系人标识符包含在PWS3数据包中，也不会在请求者上使用它们。另外，PWS3消息不包含授予者的验证记录和Apple ID证书。通过扫描周围的Wi-Fi网络并将散列的名称与BLE广播中的字段进行比较，可以轻松获得PWS3中的强制性SSID。使用授予者缺少的验证，结合以下事实：在请求者上不需要用户交互就可以对请求者进行攻击。
（2）攻击：SSID欺骗和Wi-Fi密码自动填充
当iOS和macOS设备连接到新的Wi-Fi网络时，此攻击以iOS和macOS设备为目标。目的是使目标设备以相同的SSID连接到受密码保护的Wi-Fi网络，但该网络由攻击者控制，进一步称为欺骗网络。在上图中显示了完整的协议流程和用户交互。然后，攻击者可以使用其MitM位置来分析受害者的流量或发起诸如DNS或NTP欺骗之类的二次攻击。此外，攻击者可以使用自动加载的强制门户网站网页来利用Safari Web浏览器中的漏洞，从而提取敏感的用户数据或访问用户的相机。
使用不同设置进行的实验表明，在打开密码对话框时，请求者将保存信号最强的BSSID，并且仅尝试连接到该BSSID。为了成功进行攻击，欺骗的网络必须是当时信号最强的网络。攻击者可以增加其接入点的发射功率，也可以使用定向天线来增加其机会。攻击者继续运行带有原始SSID和其欺骗网络的PSK的PWS客户端。受害者无需任何进一步的用户交互，一旦PWS完成，目标设备就连接到欺骗的网络。所提出攻击的一个问题是，仔细的用户可能会注意到他们无需输入任何密码即可自动连接到Wi-Fi网络。发现授予者可以在收到Pair-Verify M2数据包后使会话保持打开状态，等到受害者输入密码后再继续攻击，例如在受害者点击连接之前发送M3。如果在适当的时候继续，例如通过观察受害者，攻击很可能不会被察觉。本研究提供了一个视频PoC（https://youtu.be/a9OE2uZTWow ），以演示下图中攻击的实际可行性。在视频中，攻击者在成功后向受害者提供了精心制作的门户网站网页。
（3）缓解措施：相互认证和明确同意
SSID复制攻击之所以起作用，是因为请求者上的无交互用户界面以及授予者缺少身份验证。因此提出了两步缓解措施。首先，建议在“配对验证”握手中引入相互认证。鉴于AirDrop的身份验证协议是以这种方式设计的，目前尚不清楚苹果为什么不首先实现这一点。使用相互身份验证，由于攻击者必须位于受害者的联系人列表中，因此实施攻击将更加困难。其次建议更改UI，以便请求者的用户可以决定是否接受授予者的密码。苹果再次在AirDrop中实现了类似的机制，要求用户接受传入的文件。
F.使Setting App崩溃以防止Wi-Fi密码输入
研究发现PWS协议中存在一个解析漏洞，该漏洞可以防止附近设备的Wi-Fi密码输入。
（1）漏洞：解析PWS中的错误
在实现本研究自己的PWS客户端时，发现从下图所示的PWS3消息中发送的字典中删除必需的SSID或PSK键值对时，请求者无法解析数据包并使当前App崩溃。
（2）攻击：防止新Wi-Fi网络输入密码
在此攻击中，使iOS上的Setting App崩溃或关闭了当前正在输入Wi-Fi网络密码的蓝牙范围内的每台设备的macOS上的Wi-Fi密码窗口。用户进入Wi-Fi密码视图后，使用Apple ID登录并启用蓝牙的每台设备都会发送PWS广播，在PoC中证明了攻击的有效性。
（3）缓解措施：检查缺少字段
Apple应该能够通过检查是否为空或缺少字段来修复此漏洞，并且如果遇到意外的数据包，可以轻松地解决此漏洞。在提供修复程序之前，用户可以在其设备上禁用蓝牙以阻止攻击。
尽管过去已发现严重的漏洞，但由于逆向工程的工程量巨大，因此难以分析的未记录专有协议。本文对Apple Continuity无线生态系统进行结构化逆向工程的方法是实现独立第三方安全审核的关键，实际上，这有助于保护全球15亿台设备的用户。使用此方法，调查了接力（HO），通用剪贴板（UC）和Wi-Fi密码共享（PWS）服务中涉及的协议，并发现了几个导致拒绝服务（DoS）攻击，设备跟踪的漏洞以及中间设备（MitM）攻击。实际上，所有攻击都可以从附近的攻击者那里发起，并且只需要低成本的硬件即可。为了将来进行类似的研究，调用制造商记录其专有协议，就像Apple已经使用其Homekit附件协议（HAP）堆栈那样。同时本文的详细发现可以引导其他Continuity服务的分析，因为某些协议组件（例如，OPACK，Pair–Verify）似乎在服务之间共享，因此后续工作不必从头再开始。
- 结尾 - 精彩推荐 【技术分享】短期伪造舆论攻击：Twitter虚假趋势实例研究 【技术分享】CVE-2016-5195 脏牛漏洞浅析 【技术分享】Java安全-JVM类加载器 戳“阅读原文”查看更多内容 原文始发于微信公众号（安全客）：【技术分享】苹果无线生态系统安全性指南
