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<

本文链接：https://www.leiyu.cn/news/content/1406.html 复制本文链接 链接已复制