Apple AirDrop 的设计缺陷与改进方案

 

Apple 的离线文件共享服务 AirDrop 已集成到全球超过 15 亿的终端用户设备中。 本研究发现了底层协议中的两个设计缺陷，这些缺陷允许攻击者了解发送方和接收方设备的电话号码和电子邮件地址。 作为补救，本文研究了隐私保护集合交集(Private Set Intersection)对相互身份验证的适用性，这类似于即时消息程序中的联系人发现。 本文提出了一种新的基于 PSI 的优化协议称为 PrivateDrop，它解决了离线资源受限操作的具体挑战，并集成到当前的 AirDrop 协议栈中。 实验证PrivateDrop保留了AirDrop的用户体验，身份验证延迟远低于一秒。PrivateDrop目前已开源（https://github.com/seemoo-lab/privatedrop ）。

 

0x01 Introduction

Apple AirDrop 是一种文件共享服务，集成到全球超过 15 亿终端用户设备，包括 iPhone、iPad 和 Mac 系统，自 2011 年开始运行。AirDrop 完全离线运行，仅在两个设备之间使用直接 Wi-Fi 连接和低功耗蓝牙 (BLE)。本研究在底层身份验证协议中发现了两个严重的隐私漏洞。特别是，这些缺陷允许攻击者了解附近 AirDrop 发送者和接收者的联系人标识符（即电话号码和电子邮件地址）。这些缺陷源于在发现过程中交换此类联系人标识符的哈希值，可以使用暴力或字典攻击轻松破解。

在身份验证期间，两个 AirDrop 设备运行一种联系人发现形式，它们确定它们是否是相互的联系人，即它们是否已将彼此的联系信息存储在其地址簿中。如果结果是肯定的，则连接仅被认为是真实的。保护隐私的联系人发现通常通过文献中的隐私保护集合交集( (PSI) 进行广播。 PSI 协议通常是加密图形协议，它允许两个交互方安全地计算其各自输入集的交集，而不会泄露任何额外的数据。在消费者对消费者 (C2C) 的背景下，PSI 已被提议用于防止在线游戏中的作弊，并且最近被提议用于根据 COVID-19 进行联系人追踪。通过本文工作，旨在促进 PSI 在 C2C 上下文中的部署，以进行相互身份验证。

然而，AirDrop 场景带来了一系列独特的挑战：解决方案需要： (a) 在没有任何第三方服务器支持的情况下完全脱机运行，(b) 考虑恶意方对其地址簿条目或自己的联系人 ID 标识，(c) 在能源和计算资源受限的移动设备上运行，以及 (d) 通过不增加明显的身份验证延迟来保持用户体验。

 

0x02 Background: Apple AirDrop

Apple 的文件共享服务 AirDrop 已集成到所有当前的 iOS 和 macOS 设备中。它使用称为 Apple Wireless Direct Link (AWDL) 的专有 Wi-Fi 链路层与低功耗蓝牙 (BLE) 相结合，完全离线运行。由于没有涉及协议栈的官方文档，本研究首先定义联系人标识符并讨论可用的可发现性设置。然后，描述了完整的技术协议流程并解释了身份验证过程。

A.联系人标识符和地址簿

每个 iOS 或 macOS 设备都有一个地址簿，可通过联系人应用程序访问。此地址簿包含多个联系人条目，这些条目又由多个对象组成，例如姓名或联系人信息。 AirDrop 杠杆将用户自己的联系人标识符及其地址簿条目用于身份验证。特别是，AirDrop 使用电话号码和电子邮件地址来识别联系人。这是可能的，因为每个 Apple 帐户（通常称为 Apple ID 或 iCloud 帐户）都至少分配了一个此类联系人标识符。 Apple 分别使用验证电子邮件和短信验证电子邮件地址或电话号码的所有权，从而确保标识符的正确性。

在本文中将只处理联系人标识符，即电话号码和电子邮件地址，而忽略可能包含多个标识符的“联系人”的概念。假设存在从设备本地到联系人列表条目的联系人标识符的明确映射。使用术语地址簿 (AB) 来指代设备联系人列表中所有联系人条目的联系人标识符集。请注意，AB 由用户控制，未经Apple验证。此外，用户自己的联系人标识符 (ID) 是分配给用户 Apple 帐户的 Apple 验证电话号码和电子邮件地址。使用符号 c 指代地址簿条目，使用 ID 指代 Apple 验证的联系人标识符。

B.设备可发现性

在 iOS 设备上打开共享窗格时，如果附近的设备可被发现，则会出现在用户界面中。特别是，接收器设备可以被每个人发现，也可以只被联系人发现，这是默认设置。在任何一种情况下，AirDrop 发送方都将尝试与响应接收方进行相互认证握手。请注意，文中解决的问题（即在身份验证过程中发送方和接收方的联系人标识符泄漏）会影响这两种设置。

C.完整协议工作流程

AirDrop 协议允许发送方将文件或链接传输到接收方。它由发现、身份验证和数据传输三个阶段组成，在上图中进行了描述：（a）当发送方打开共享窗格时，它开始发出 BLE 广播，其中包含每个联系人标识符的截断哈希。接收者将发送者的哈希联系人标识符与其地址簿中的条目进行比较。如果在仅联系人模式下找到至少一个联系人匹配或者每个人都可以发现，则接收器激活其 AWDL 接口。然后，发件人通过 AWDL 接口搜索具有 DNS 服务发现 (DNS-SD) 的 AirDrop 服务。 (b) 对于每个发现的服务，发送方通过HTTPS 发现请求启动身份验证程序。如果身份验证过程完全成功，接收者的身份将显示在发送者的用户界面中。 (c) 最后，发送方选择接收方并发送两个后续请求： Ask 请求包含有关文件的元数据，包括缩略图。接收者发送他们关于是否接收完整文件的决定。收到肯定响应后，发送方会继续在上传请求中传输完整文件，否则会中止交易。

D.相互认证

只能在具有 Apple ID 且存在于彼此地址簿中的用户之间建立经过身份验证的连接。为了进行身份验证，设备需要证明它已经注册了某个联系人标识符 IDi，例如与其 Apple ID 关联的电话号码或电子邮件地址，而验证设备会检查 IDi 是否是地址簿条目。身份验证涉及多个 Apple 签名的证书和一系列 Apple 运行的证书颁发机构 (CA)。特别是，AirDrop 使用设备特定的证书 σUUID 和验证记录 VRσ，它们都由 Apple 签名。一旦用户登录到他们的 iCloud 帐户，设备就会从 Apple 检索它们。然后它们可以在任何后续的 AirDrop 交易中离线使用。

证书 σUUID 包含帐户特定的通用唯一标识符 (UUID)。该证书在 TLS 连接中用作客户端或服务器证书（取决于角色）。由于证书中的 UUID 不链接任何联系人标识符，AirDrop 使用 Apple 签名的 Apple ID 验证记录 (VRσ)。验证记录包含来自 TLS 证书的 UUID 和所有联系人标识符 SHA-256(ID1),…,SHA-256(IDm)，这些标识符以哈希形式使用用户的 Apple ID 注册。此外，VRσ 包括签名和签名 CA σVR 的证书。 形式上定义 VRσ 如下：

其中 sign(σVR,VR) 是证书 σVR 的 VR 签名。在身份验证期间，AirDrop (a) 验证收到的验证记录上的签名，(b) 验证证书中的 UUID 是否与验证记录中的 UUID 匹配，以及 (c) 计算每个正常 ized3 地址的 SHA-256 哈希book entry 并将它们与验证记录中包含的哈希值进行比较。如果所有检查都通过，则身份验证成功。如果接收方的身份验证失败，则接收方中止连接。但是，如果发送方的身份验证失败，AirDrop 会继续交易，但会将连接视为未经身份验证，而对等方视为非联系。 AirDrop 在用户界面中显示带有地址簿中的姓名和图片的联系人。非联系人使用设备名称而不是图片显示。

 

0x03 Contact Identififier Leakage in AirDrop

在 AirDrop 协议中发现了两个设计缺陷，攻击者可以利用这些缺陷了解附近 Apple 设备的联系人标识符（电话号码和电子邮件地址）。这两个缺陷源于 AirDrop 的身份验证握手，其中哈希的联系人标识符作为 Apple 验证记录的一部分进行交换。首先，定义威胁模型并讨论当输入空间较小或可预测时，例如电话号码或电子邮件地址，加密哈希函数无法隐藏其输入（称为原像，preimage）。其次，解释了 AirDrop 设备在何处以及在多大程度上容易受到联系人标识符泄漏的影响。

A.威胁模型

在本文中，考虑了一个想要从附近的非接触式 AirDrop 设备中学习联系人标识符（电话号码和电子邮件地址）的攻击者。然后，他们可能会将这些标识符用于欺诈活动，例如（鱼叉式）网络钓鱼攻击或通过出售个人数据获利。具体来说，攻击者必须在物理上接近其目标，并且可以使用带有现成 Wi-Fi 卡的设备通过 AWDL进行通信。假设攻击者可以完全控制无线通道。攻击者可能会对其地址簿 (AB) 条目撒谎并任意偏离协议描述，但不能破坏 Apple 的联系人标识符所有权验证，即攻击者无法伪造任意联系人的有效证书标识符（ID）。假设 Apple 是值得信赖的，因为它充当认证机构并通过所有权验证过程从其所有用户那里学习联系人标识符，而不是地址簿条目。

B.恢复联系人标识哈希值

哈希不足以隐藏电话号码或电子邮件地址，因为输入空间很小/可预测。

电话号码：由于电话号码空间相对较小，因此可以使用暴力恢复哈希电话号码的原像。例如，美国电话号码包含一个区号，后跟 7 位数字。鉴于这个小的搜索空间 (10^7)，在几秒钟内检查 PC 上所有可能的电话号码是可行的。

更准确地说，最近的一项工作研究了三种不同的有效反转电话号码哈希的方法：在大规模键值存储中查找、暴力攻击和优化彩虹表结构。作者还模拟了一个全球有效手机号码前缀数据库，该数据库揭示了国家之间电话号码结构的巨大差异，因此，搜索空间的大小（例如，在奥地利，搜索空间按顺序排列） 10^10，而美国为 10^7）。每种研究的反转方法都能够反转 SHA-1 哈希，其分摊运行时间以毫秒为单位（例如，优化彩虹表构造为 52 毫秒）。这些结果直接适用于估计攻击者从 AirDrop 泄露的哈希值中恢复电话号码所需的工作量。

电子邮件地址：恢复哈希电子邮件地址的原像不是那么简单，但可以通过字典攻击检查常见的电子邮件格式，例如 first.lastname@{ gmail.com,yahoo.com,…}。或者，攻击者可以从数据泄露中生成电子邮件查找表或使用在线查找服务来查找哈希的电子邮件地址。

C.发件人联系人标识泄露

在 AirDrop 身份验证握手期间，发送者总是会公开他们自己的联系人标识符作为初始 HTTPS POST /Discover 消息的一部分（参见前图）。因此，恶意接收者可以了解发送者的所有（哈希）联系人标识符，而无需对其目标有任何先验知识。为了获得这些标识符，攻击者只需等待（例如，在公共热点），直到目标设备扫描 AirDrop 接收器，即用户打开 AirDrop 共享窗格。目标设备将自由地向在之前的 DNS-SD 服务查找期间找到的任何 AirDrop 接收器发送发现消息。因此，攻击者只需通过多播 DNS (mDNS) 宣布 AirDrop 服务，就可以在没有任何身份验证的情况下了解目标的验证记录。收集验证记录后，攻击者可以离线恢复哈希的联系人标识符。

D.接收者联系人标识泄露

如果 AirDrop 接收器知道验证记录中包含的任何发送者的联系人标识符（参见前图），则 AirDrop 接收器会在对发现消息的 HTTPS 200 OK 响应中显示其联系人标识符。因此，如果接收者知道发送者，恶意发送者可以学习所有联系人标识符，而无需接收者的任何先验知识。重要的是，恶意发送者不必知道接收者：特定上下文中的受欢迎的人（例如，公司的经理）可以利用此设计缺陷来了解其地址中包含受欢迎的人的其他人的所有联系人标识符书（例如，公司员工）。

 

0x04 PrivateDrop: PSI-based Mutual Authentication for AirDrop

在下文中描述了如何应用 PSI 来实现 PrivateDrop，这是用于 AirDrop 的私有相互身份验证协议，可防止前文中描述的两种攻击。一般来说，给定发送方 S 和接收方 R 具有经过验证的联系人标识符和大小受限的地址簿 (IDs^S, AB^S) 和 (IDs^R, AB^R ) 分别是，隐私保护的相互认证协议必须确保 S 和 R 最多获知对方地址簿中已有的联系人标识符，即 S 最多学习 AB^S ∩IDs^R，R 最多学习 AB^R ∩IDs^S。

私有集交集 (PSI) 协议是一种加密协议，可以安全地计算两方具有各自私有输入集 A 和 B 的交集 A∩B。 对于本文的其余部分，将获得交集结果的一方表示为 PSI 接收者和各自的另一方作为PSI 发送者。重要的是，使用PSI，交集之外的元素，即来自(A∪B) \ (A∩B) 的元素不会被泄露。

A.要求

主要目标是通过保护联系人标识符（Apple 验证的电话号码和分配给用户 Apple 帐户的电子邮件地址）和验证记录（Apple 签名的哈希联系人标识列表）来防止前文中描述的两种攻击。具体来说，在 AirDrop 认证的功能性和隐私性方面，希望同时实现以下属性：

(a) 仅当双方相互联系时才披露验证记录。如果双方是相互的联系人，他们已经知道各自另一方的至少一个联系人标识符。因此，包含在验证记录中的哈希值不会通过暴力破解或字典攻击泄露个人信息。

(b) 在验证记录中，仅披露对方已经知道的联系人标识符。即使相互联系人已经知道相应另一方的至少一个联系人标识符，验证记录包含所有注册标识符的哈希值。因此，对方不知道的联系人标识符的哈希值会通过暴力破解或字典攻击泄露额外的个人信息。

使用“A知道B”作为 “A的B联系人标识符(IDsB)的大小受到限制”简写，或者形式上：AB^A ∩IDs^B != 0。

在性能方面，希望最大限度地减少计算和通信开销。这对于实现电池驱动的移动设备的低能耗以及通过即时响应提供出色的用户体验非常重要。由于 AirDrop 主要用于移动设备，这些设备可能会不时脱机，因此解决方案必须是完全去中心化的，不能涉及外部服务器。此外，必须考虑到各方可能会采取恶意行为，即可能会尝试应用任意策略以提取个人信息。

B,设计选项和最终设计

考虑到前文中定义的要求，现在描述如何应用 PSI 来实现 AirDrop 的私有相互认证。主要任务是替换由于发送验证记录而在原始身份验证阶段发生的不安全的哈希值交换。

在上图中总结的想法是有两个连续的 PSI 执行。第一次执行确保 AirDrop 发送者知道接收者，第二次执行确保 AirDrop 接收者知道发送者。之后，由于每一方都确信它存储在各自另一方的地址簿中，因此他们可以安全地透露他们的联系标识符和验证记录。在下文中，将通过系统地分析所有可能的设计选项来详细说明如何配置 PSI 执行以实现所描述的结果。

表中列出的设计选项 (DO)的不同之处在于（a）AirDrop 发送方和接收方的 PSI 输入，即联系人标识符和地址簿，（b）各方在 PSI 中扮演的角色，以及（c）执行 DO 的顺序。

请注意，排除了双方输入其联系人标识符的组合，因为交集将始终为空。同样，不考虑双方都使用他们的地址簿作为输入，因为这个变体（在中正式化为两个用户之间的私人联系人发现）产生双方的共同联系人（即，找到“朋友的朋友” ) 但不能确定他们是否是相互联系的。

关于 PSI 角色的分配和执行顺序，可以排除进一步的组合。由于必须确保 AirDrop 发送方和接收方相互联系，因此每个人都必须充当 PSI 接收方一次。在认证过程中，AirDrop 发送者应该是第一个泄露信息的人，否则恶意发送者很容易通过触发认证过程从大量无辜的接收者那里提取这些信息。因此，必须将选项链接起来，以便 AirDrop 接收器首先充当 PSI 接收器（DO1 或 DO2），然后充当发送器（DO3 或 DO4）。下面讨论剩下的两种可能性。

DO1 → DO4：在这里，PSI 发送者将他们的联系人标识符作为输入，而 PSI 接收者将他们的地址簿作为输入。因此，每一方都确信另一方是其联系人之一。这是原始（不安全）身份验证协议中的确切语义。但是，由于恶意 AirDrop 接收器在第一次 PSI 执行中收到空结果集后不一定会中止，因此 AirDrop 发送器在透露其联系人标识符之前无法证明接收器知道他们。由于严格希望避免这种信息泄漏，因此丢弃 DO1 → DO4。

DO2 → DO3：在这里，PSI 发送者将他们的地址簿作为输入，而 PSI 接收者将他们的联系人标识符作为输入。在认证过程结束时，每一方都可以确信它存储在各自的另一方地址簿中。因此，AirDrop 发送者可以安全地共享他们在 DO3 执行结果中出现的联系人标识符，因为对方已经存储了这些标识符。

总之，通过按特定顺序执行 DO2 → DO3，可以满足定义的功能和隐私要求，并防止前文描述的攻击。

C.PSI 协议的选择

现在确定了两个 PSI 协议必须以哪个顺序运行，需要找到实例。在已有工作中，提出了许多可以应用的两方 PSI 协议。特别是，PSI 协议的一个子类别专门研究不平衡集大小，其中一方的输入集比另一方大得多。在环境中，双方都不受商业激励或严重法律后果的约束，可以半诚实地行事。因此，必须选择一种对恶意发送方和接收方具有安全性的协议。此外，AirDrop 是一种与随机通信伙伴临时执行的协议，因此不可能预先分发加密数据库。最后，目标是提供行业级的实现，以集成到 Apple 的生态系统中。因此需要一个简单的协议，不需要复杂的库来进行不经意的传输或乱码电路。

考虑到所有要求，采用了 Jarecki 和 Liu提出的基于公钥的 PSI 协议。这个 Diffie-Hellman 风格的协议通过零知识证明添加恶意安全性。所需的公钥操作可以使用椭圆曲线密码术有效地实例化，为此存在行业级库，如 MIRACL 和内置操作系统功能ties（iOS 和 macOS 中的 Apple CryptoKit）。
在下图中，总结了PSI 协议应用于本文的用例。具体来说，展示了对 DO2 的应用。 DO3 的应用程序与相同类型的输入（PSI 发送者的地址簿 AB，PSI 接收者的标识符 ID）类似地工作，但 AirDrop 发送者/接收者到 PSI 发送者/接收者的分配被交换。

为简单起见，描述中的 H 表示一个哈希函数，它将一个或多个位串或组元素映射到一个固定长度的短位串或质数阶 q 的乘法组中的一个元素。从上下文中可以清楚地看出各自的输入和输出域。在实现中使用 SHA-2家族实例化 H。

非形式化地，该协议的工作原理如下：（a）PSI 接收器使用抗冲突哈希函数 H 哈希其输入元素 IDi 以对元素进行分组，使用随机密钥 αi 加密哈希值 hi，并发送结果值yi 给 PSI 发件人； (b) PSI 发送方使用随机密钥 k 额外加密接收到的元素，并将结果 zi 发送给接收方； (c) PSI 接收方“删除”自己的密钥 αi，这样它就可以在发送方的密钥 k 下无意中获得其输入的加密；最后 (d) PSI 发送方以随机顺序将其自己的输入元素 cj 的哈希加密 uj 发送给接收方，然后接收方可以比较这些值以确定交集。值 uj 的位长 l 可以减少到 λ + 2log2(n)，其中 λ 是统计安全参数（在实现中设置为 λ = 40） ，而 n 是每一方拥有的地址簿条目数量的上限。这产生可忽略不计的故障概率 2^(-λ)。

为了实现恶意安全性，该协议利用知识的零知识证明来确保 PSI 发送者知道并使用相同的密钥 k 来计算所有值 zi。这需要对单个指数进行所谓的 AND 证明。为了高效且直接的实例化，选择 Schnorr 的 DLOG 证明并应用 Fiat Shamir 启发式将其转换为非交互式版本（在随机预言机模型中），这不需要额外的通信轮次（参见上中的蓝色部分）。

上图中的协议通过输入的数量泄漏了一些信息。例如，可以从地址簿条目的数量中了解 AirDrop 发件人是否受欢迎。为了防止这种泄漏，用虚拟元素填充输入集到一个全局固定的上限。例如，将地址簿条目的数量限制为 n = 10k，将联系人标识符的数量限制为 m = 10 是合理的。

D.优化 PrivateDrop 的 PSI

在将上图的 PSI 协议集成到 AirDrop 中时，应用了多项性能改进。

预计算：首先，PSI 发送方可以生成密钥 k 并提前计算值 ui。这可以完成，例如，当设备充电时的夜里。只需在地址簿条目更改时更新预先计算的值。由于 AB 是更大的输入集，这消除了协议执行中最大的计算瓶颈。同样，PSI 接收器可以预先计算很少变化的值 yi 。

再利用：此外，可以跨会话重用预先计算的值。在之前的工作中，将大规模数据库视为输入集，预先计算的值通过编码和分布在概率数据结构（如 Bloom 或 Cuckoo 过滤器）中来重用，OPRF 评估针对这些结构进行检查。

从独立的角度来看，这允许用户跟踪，但在 AirDrop 中，用户已经可以通过用于建立协议通信通道的 TLS 证书中的 UUID 进行跟踪。在整个 AirDrop 执行过程中避免用户跟踪是未来工作的一个重要领域。然而，在更长的时间内重复使用地址簿条目的预计算加密允许跟踪联系人组成的变化，即自上次协议执行以来添加或删除了多少联系人。即使没有发生变化，这也会泄露一些信息，例如，没有遇到新的人或没有人被“取消好友”。如果应该避免这种泄漏，应该预先计算新的加密并且永远不要重复使用。

轮次复杂度：就轮次复杂度而言，可以将 PSI 发送方的最后两条消息捆绑到接收方，而无需更改接收方的视图。因此，PSI 协议仅包含一轮，并且在零知识证明验证失败的情况下，PSI 接收器可以忽略接收到的值 ui。

此外，优化了 DO2 和 DO3 的顺序但独立执行。为此将 DO2 的第二条消息与 DO3 的第一条消息捆绑在一起。总的来说，两个协议执行都需要发送三个消息，即两轮。重要的是，在最后一个 DO2 消息中直接包含第一个 DO3 消息不会对 AirDrop 发送方产生负面影响，以防与恶意接收方接触。这是因为在顺序执行中，AirDrop 发送方在 DO2 结束时没有得到响应。此外，恶意 AirDrop 接收器无法从接收哈希联系人标识符的加密中获悉任何额外的私人信息。此外，由于 AirDrop 接收器在 DO3 结束时没有得到响应，并且可以验证发送者的输入，利用在线阶段顺序执行的恶意行为只会影响正确性，而不会影响输入隐私。

请注意，代替提出的三个消息协议，可以通过完全对称的 DO2 和 DO3 执行来进一步并行化计算。这将需要发送四条消息，但仍然可以在两轮中完成。然而，为了防止恶意发送者对无辜接收者造成不必要的工作（拒绝服务攻击），要求发送者在开始计算之前首先处理接收者的输入并显示其加密的地址簿条目。此外，通过额外的并行化在整体效率方面的潜在收益可以忽略不计，因为一轮通信引起的恒定开销（≈ 100 毫秒）大于整个在线计算（即使对于 m = 10 ID也小于 50 毫秒） 。

E.对抗隐私攻击

前图中 PSI 协议的安全特性可以防止恶意方在任意偏离协议定义时学习私人信息。然而，恶意方可能会篡改协议输入，这是协议本身无法阻止的，因为这是对集合交集的理想特征的攻击。现在讨论此类攻击的影响以及如何利用 Apple 现有的认证基础设施来应对它们。

恶意发件人：恶意 AirDrop 发件人可能会尝试通过在其地址簿中包含 VIP 的公开电子邮件地址来获取敏感的联系信息，例如 VIP。 PSI 协议然后产生匹配，并且在 AirDrop 协议的后续步骤中发送 VIP 的所有联系人标识符的易受攻击的哈希值（包括例如哈希的电话号码）。

为了防止这种攻击，修改了 AirDrop 协议流程，以仅发布在 PSI 协议中找到匹配项的哈希联系人标识符（在验证记录中）。这需要更改当前的 AirDrop 验证记录，其中包含所有联系人标识符，参见方程 (1) 和 (2) 。特别地，为每个用户的 m 个联系人标识符 IDi 创建单独的验证记录，如下所示：

这产生了一种可扩展的解决方案，因为创建和分发验证记录是一次性成本，并且每个用户的 ID 数量 m 预计很小（例如，m = 10）。

恶意接收者：知道发件人的恶意 AirDrop 接收器可能会试图通过使用存储在发件人地址簿中的联系人标识符（例如，紧急电话号码）来欺骗发件人相信他们是相互的联系人。此外，使用相同的方法，恶意 AirDrop 接收器可以测试发送者是否认识特定的人。为防止此类攻击，建议由 Apple 签署加密的联系人标识符。

类似于等式(4)中的单个验证记录，引入了包含 UUID 和用户联系人标识符的预计算值 yi 的 Apple 签名证书：

PrivateDrop 验证等式(5)中的 UUID 等于 TLS 证书中的一个，以防止被另一方重复使用，从而减轻重放和中间机攻击。与方程(4)一样。 这是一个轻量级的添加，不需要对现有基础设施进行重大更改。仍然可以在客户端设备上选择密钥 αi。只有一个简单的零知识协议必须与 Apple 一起运行，以确保 yi 实际上是一个合法哈希的联系人标识符的加密，并且客户端设备拥有密钥 αi。这可以再次使用 Schnorr 的协议和 Fiat-Shamir 启发式有效地实例化。或者，Apple 可以选择密钥 αi 并将它们与签名值 Yσ,i 一起交给客户端设备。

暴破：最后，任何一方都可以通过添加大量“假”地址簿条目（所谓的枚举攻击）来尝试猜测对方的联系人标识符。然而，与离线暴力破解相比，每秒可以检查多达数百万次的猜测，成功概率要低得多，因为严格限制输入集的大小到一个合理的上限（例如，m = 10 且 n = 10k）。

F.PrivateDrop 协议

在上图中，展示了完整的基于 PSI 的 AirDrop 相互认证协议。下表中总结了其计算和通信开销。 对于计算开销，计算所需的幂运算和哈希运算。假设验证每个签名需要一个这样的幂运算和一个哈希运算。忽略值 yi 上的签名，因为确切的开销取决于所选的实现。如果 Apple 提供密钥 αi 以及值 Yi 和签名 sign(σVR,Yi)，则预计算阶段的额外通信开销仅为 O(m)。否则，如果在客户端设备上选择了密钥，则非交互式零知识 Schnorr 证明需要使用 O(m) 幂运算和哈希运算进行额外计算。

开销：总体而言，在预计算阶段，双方都有 O(m + n) 的计算开销，这是一次性成本。在在线阶段，计算开销是 O(m)，其中 m<<n，而通信开销是 O(m+n)。由于 n 在实践中仍然相当有限（例如，n = 10k）以及低延迟和高带宽 Wi-Fi 连接的可用性，这种通信开销非常易于管理。

 

0x05 Implementation and Integration

本研究为 iOS 和 macOS 实现了原始的 AirDrop 协议和 PrivateDrop 扩展，以实证研究 PSI 引起的开销。不使用 Apple 的闭源 AirDrop 实现来提供非 PSI 和 PSI 之间的比较。下面将讨论实现（包括 mDNS 和 HTTPS 通信）以及将 PrivateDrop 集成到原始 AirDrop 协议栈中。

A.基础协议实现

Apple 没有公开或记录允许研究者集成 PrivateDrop 扩展并进行细粒度性能评估的低级 AirDrop API。使用现有的 AirDrop开源实现也不是一种选择，因为它是用 Python 编写的，iOS 不支持它，也没有针对性能进行优化。因此在 Swift 中重新实现了完整的 AirDrop 协议栈，Swift 是 Apple 的现代编程语言，可编译为汇编代码。特别是，使用 Apple 的公共 NetService API通过 mDNS 和通过 AWDL 接口的引导通信来宣布服务。此外，使用 SwiftNIO来实现高性能的异步网络操作并实现 HTTPS 通信。下图展示了本研究的 AirDrop 实现与 Apple 的非常相似。

AirDrop 的验证记录是使用加密消息语法 (CMS) 实现的。为了提供与 Apple 现有认证基础设施的最佳集成，还在等式(6)中实现了签名 Yσ,i。在内容管理系统中。为了验证，使用 OpenSSL 库，因为 Apple 的安全框架仅在 macOS 上提供 CMS 支持，而在 iOS上不提供。

B.PSI 操作实施

实现PSI 协议需要访问低级椭圆曲线 (EC) 操作，为此希望利用内置的操作系统功能。不幸的是，Apple 的基于 Swift 的 CryptoKit没有公开所需的点运算，例如加法和标量乘法。作为替代方案使用已建立的开源库 Relic 。与 MIRACL或 libecc等其他第三方候选程序相比，Relic 专注于效率和可移植性，支持所有相关架构，即 arm64（iOS 和 macOS）和 x86_64（macOS） 。此外，Relic 是用 C 编写的，它与基于 Swift 的协议实现很好地集成在一起。本研究实例化所有原语以提供 128 位的安全级别，基于 Diffie-Hellman 的 PSI 实施使用标准化椭圆曲线 P-256。

C.与HTTPS握手集成

为了将 PrivateDrop 集成到 AirDrop 的 HTTPS 协议中，在下图中描绘的身份验证阶段引入了两个新的 HTTPS 消息。特别是引入了 StartPSI 和 FinishPSI，其中包括三个消息 M1、M2 和M3 来自优化的 PSI 协议作为有效载荷。该协议在 mDNS 发现完成后立即执行，并取代原来的 HTTPS 发现交换。由于 AirDrop 发送方在协议中充当 HTTPS 客户端，因此最初的 HTTPS 请求不包含有效负载，只是向接收方发出信号以启动 PSI 协议。

选择个人验证记录：PSI 协议的输出决定了后续请求中包含哪些单独的验证记录 VRσ,i。如果 PSI 协议未产生匹配项，则不包括验证记录。如果 PSI 协议产生一个或多个匹配项，则请求中将包含与其中一项匹配项对应的随机选择的单独验证记录。请注意，原则上可以包含所有匹配项的验证记录。然而，这不会产生任何好处，因为一个联系人标识符足以根据用户的地址簿唯一标识另一方。相反，传输多个验证记录会增加通信开销并要求接收方验证多个签名。

通信轮次：请注意，在处理 M2 之后，接收方已经选择了适当的个人验证记录，并且可以将其与 M3 一起发送回发送方。发起文件传输时，发件人将在 Ask 请求中包含其个人验证记录。通过将接收者的验证记录搭载到 M3，避免了在 PSI 协议完成后交换 VRσ,i 所必需的一轮额外通信。总的来说，与原始身份验证相比，基于 PSI 的协议只需要额外的一轮通信。

D.与BLE广播集成

AirDrop 的 BLE 广播包含发件人哈希联系人标识符的前两个字节，这也是验证记录的一部分。接收者使用这些哈希来检查发送者是否是潜在的联系人匹配，以及他们是否应该打开他们的 AWDL 接口来进行完整的身份验证握手。这种机制没有提供额外的安全性，因为它可以很容易地被暴力破解。因此，短哈希似乎是一种优化，以防止唤醒接收器的 Wi-Fi 无线电，从而不必要地耗尽设备的电池。

由于本研究工作的目的是防止个人信息泄露，建议不包含任何（甚至缩短的）联系人标识符，只需将字段设置为固定值，例如 0x0000。然后，每当 AirDrop 接收器听到这样的广播时，他们就会无条件地激活其 AWDL 接口。巧合的是，每个人都可以发现的 AirDrop 接收器已经实现了这种行为，因此预计这种变化不会带来任何实际障碍。

E.替代AirDrop

已经实现了一个功能齐全的 PrivateDrop 原型。 Apple 必须进行以下更改才能将 PrivateDrop 变成 AirDrop 的直接替代品，AirDrop 可以随 iOS 和 macOS 更新一起部署，并且不需要硬件修改：(a) 确保与原始版本的有限向后兼容性AirDrop 协议，启用 PrivateDrop 的设备应支持 AirDrop 的发现请求，但绝不包括 AirDrop 的验证记录，以保护自己免受标识符泄漏。 PrivateDrop 设备将始终显示为与 AirDrop 设备的非联系人。请注意降级攻击（downgrade attack），即强制两个 PrivateDrop 设备使用旧版 AirDrop 协议，因此只会导致未经身份验证的连接，因为 PrivateDrop 设备永远不会与 AirDrop 设备交换其验证记录。 (b) Apple 的 CA 基础设施必须扩展以发布 VRσ,i 和 Yσ,i 值。 (c) PrivateDrop 应使用系统的 Contact API 为联系人发现提供输入。出于评估目的，使用随机生成的联系人。 (d) 目前没有集成 BLE 发现，因为 iOS 在扫描响应中隐藏了 Apple 特定的广播，并禁止向第三方应用程序发出它们。 (e) 最后，PrivateDrop 目前没有实现单独的验证记录，而是使用 AirDrop 验证记录 VRσ 来匹配 Apple 签署的 TLS 证书。

 

0x06 Experimental Evaluation

根据对 AirDrop 的实现来评估 PrivateDrop 的性能。为此，使用不同的 Apple 设备和设备的 AWDL 接口上的可变输入大小进行了广泛的实验评估。在任何实际环境中，发现延迟的中位数都远低于 1 秒。在下文中，解释了评估指标和实验设置。然后介绍并讨论评估结果。

A.评价指标

根据运行时间或延迟评估协议的性能。特别是，在几个参考点对协议流进行计时以测量: (a) 计算开销，即计算加密操作所花费的时间，(b) 网络开销，即通过数据通道传输数据所花费的时间，以及(c) 整体运行时间，即执行完整发现过程所花费的时间。

B.实验设置

使用PrivateDrop 和 AirDrop 进行所有实验，并在表中总结了所有其他实验参数，例如集大小、硬件和网络环境。

设置大小：复杂性分析表明，在线 PSI 开销取决于标识符 m 和地址簿条目 n 的数量。之前的一项在线研究发现，Apple 用户平均拥有 n = 136 个联系人。因此，按这个数量级选择 n 的值，但也包括高达 n = 15000 的值以评估潜在的可扩展性限制。同样，选择 m 来覆盖中等和极端的限制（1 到 20）。为简单起见，在所有的实验中，发送方和接收方的输入大小相同，即 m = mS = mR 和 n = nS = nR。

硬件和网络连接：使用最新的 Apple 设备进行评估，特别是 iPhone 12 mini 和 MacBook Pro（2019）。除了 AWDL 之外，iOS 和 macOS 设备的组合允许通过有线网络连接 (USB) 进行实验，从而测量网络引起的延迟的影响。在所有实验中，MacBook 充当发送者，iPhone 充当接收者，以确保可比较的结果。

环境：在家庭办公环境中进行所有实验，在那里无法控制干扰蓝牙和 Wi-Fi 传输。这种干扰可能导致AWDL 实验的高方差，这在之前实验中没有观察到。

测试套件：基于 PrivateDrop为 iOS 和 macOS 实现了一个基准应用程序，它允许定义一个场景。场景由一组固定的实验参数组成，例如设置大小以及发送器和接收器设备的选择（参见下表）。对于每个场景，运行 100 个实验 (Monte Carlo)，每个实验都包含一个完整的协议执行。为了避免时间干扰引入的系统错误，以循环方式为每个场景安排单独的运行。条形图表示所有运行的中值延迟，误差条表示 0.05 和 0.95 分位数。除非另有说明，否则会测量发送方的延迟。每个实验都包含一个完整的协议运行以及一个准备和清理阶段： (a) 准备：随机生成地址簿，预先计算值 ui ，然后等待发送方和接收方都准备就绪。 (b) 执行：运行完整的协议执行，从 DNS-SD 发现到文件上传。 (c) 清理：关闭 HTTPS 和 DNS-SD 服务器以关闭所有连接。

C.认证延迟

首先凭经验测量 PrivateDrop 在线阶段对于可变集大小 n 和 m 的性能。为此，在 MacBook Pro 2019（发送器）和 iPhone 12（接收器）之间运行了一组实验。为了最大限度地减少无线信道引入的噪声，通过发送器和接收器之间的USB线连接进行此实验。

总延迟：在上图中，显示了 PrivateDrop 和 AirDrop 的完整身份验证阶段的延迟。 AirDrop 身份验证取决于 m 和 n，因此，将中值延迟作为基准。相比之下，PrivateDrop 运行时间按预期随着 m 和 n 增加。对 PrivateDrop 的结果表明，对于中等设置（m = 10，n = 1000），与 AirDrop 相比，中位身份验证延迟增加了 2 倍。即使在极端情况下（m = 20，n = 15000），总体延迟也保持在 500 毫秒以下。这满足了用户体验要求，因为人类将任何低于 1000 毫秒的延迟视为“立即响应”。

PSI 延迟：仔细研究了 PSI 对线路相位的影响对整体认证延迟的影响。上图显示了 iPhone 12 上单个操作的计算时间。实际上，仅计算实际交集取决于地址簿条目的数量 n（参见上图中的紫色部分），最多为 5% n = 15000 的总时间。所有其他算术运算随 m 线性增加，这验证了复杂性分析。从绝对值来看，m = 1 时的中值计算开销小于 12 ms，而 m = 20 时保持低于 50 ms。请注意，完整的协议执行需要双方进行相同的操作。为了获得总 PSI 开销，如果假设发送方和接收方的硬件相同，可以将这些数字加倍。尽管如此，仅 PSI 操作就占不到总认证延迟的一半。另一个主要组成部分是网络延迟，接下来将对其进行探讨。

D.联网延迟

AirDrop 最初使用发送方和接收方之间的无线连接。本节给出网络工作延迟的影响，并提供 AWDL 和线连接之间的比较。为此在 AWDL 上重复了之前的实验，并测量了 HTTPS 请求和回复的传输延迟。特别地，为每个请求-响应对记录时间戳 T1..4，即，

将延迟计算为 t = T4-T1-（T 3-T2）以排除接收端处理延迟。 上图显示了无线和有线连接的 StartPSI 和 FinishPSI 交换引起的中值传输延迟 t。添加了 AirDrop 的 Discover 请求的中值传输延迟以供参考。定性地，可以观察到地址簿条目的数量 n 对 AWDL 的传输延迟的影响比线连接的影响更大，并且传输延迟构成了整个认证延迟的一半左右。有趣的是，两个 PSI 请求在线上的传输延迟相似，而第一个请求在 AWDL 上占用的时间要长得多。原因是第一个请求包括建立连接所需的时间，这通常比 AWDL 花费的时间更长，并且具有更高的差异，将在下面讨论。

AWDL 传输延迟的高方差：与线连接相比，没有发现 AWDL 上的传输延迟差异很大（参见上图）。这种影响可以用 AWDL 的信道分配机制来解释。 AWDL 最初为传输分配很少的时隙，即几乎没有可用带宽，然后如果 Wi-Fi 接口上有负载，则动态分配更多时隙。因此，初始 Wi-Fi 传输被推迟到下一个可用时隙，导致无法控制的延迟在一秒的数量级，这是一个 AWDL 周期的长度。随着时间的推移，可用带宽的增加也解释了为什么第一条消息的中间传输延迟 (StartPSI) 明显大于第二条消息 (FinishPSI)。

E.预计算

虽然在线性能对用户体验至关重要，但加密地址簿条目 uj 的预计算也必须可在移动设备上进行管理。因此，在预计算阶段评估计算值 uj 的运行时间。由于运行时间线性取决于 n，对 iPhone 12 的结果进行线性回归，以将运行时间近似为 n×0.331 毫秒。原始结果如下图。看到，即使对于大型地址簿（n = 10k），单线程预计算也只需要 3.31 秒。为了节省电池电量，移动设备可以将预计算推迟到充电时，例如整夜。

 

0x07 Conclusion

在本文中，基于相互联系的概念解决了离线对等点之间的隐私保护认证问题。通过全面的实验性能评估证明了本文方法的实用性，这证明在实际条件下开销可以忽略不计。AirDrop 中的两个明显设计缺陷启发了本文工作，这些缺陷允许攻击者破解发送方和接收方设备的电话号码和电子邮件地址。谷歌最近为 Android推出了一个名为“Nearby”的类似平台，在该平台中，设备可见性可以限制为用户的联系人，因此可以从本研究的隐私保护身份验证协议中受益。

本文提出的解决方案 PrivateDrop 可防止用户向非联系人披露个人信息。尽管如此，用户仍然可以通过 TLS 证书中特定于帐户的 UUID 进行跟踪，这为未来的工作留出了空间。尽管如此，结果表明即使在资源受限的移动设备之间的离线场景中，具有恶意安全性的 PSI 也已准备好进行实际部署。