蘋果無線生態系統安全性指南

Apple公司擁有著世界上最大的移動生態系統之一，在全球擁有15億臺有源設備，并提供十二種專有的無線連續性服務。以往工作揭示了所涉及協議中的一些安全性和隱私性問題，這些工作對AirDrop進行了廣泛的研究。為了簡化繁瑣的逆向工程過程，本研究提出了一個指南，指南介紹了如何使用macOS上的多個有利位置對所涉及協議進行結構化分析。此外還開發了一個工具包（https://github.com/seemoo-lab/apple-continuity-tools ），可以自動執行此手動過程的各個部分。基于此指南，本研究將分析涉及三個連續性服務的完整協議棧，特別是接力（HO，Handoff）， 通用剪貼板（UC，Universal Clipboard）和Wi-Fi密碼共享（PWS，Wi-Fi Password Sharing）。本研究發現了從藍牙低功耗（BLE，Bluetooth Low Energy）到Apple專有的加密協議等多個漏洞。這些缺陷可以通過HO的mDNS響應，對HO和UC的拒絕服務（DoS）攻擊，對PWS的DoS攻擊（可阻止Wi-Fi密碼輸入）以及中間設備（MitM）進行設備跟蹤。對將目標連接到攻擊者控制的Wi-Fi網絡的PWS進行攻擊。本研究的PoC實施表明，可以使用價格適中的現成硬件（20美元的micro：bit和Wi-Fi卡）進行攻擊。最后，建議采取切實可行的緩解措施，并與Apple分享我們的發現，Apple已開始通過iOS和macOS更新發布修復程序。

Introduction

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）實施。

Background

在本節中概述了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作為消息傳輸。

A hacker's Guide to Apple's Wireless Ecosystem

本節旨在提供結構化的方法，以進行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框架]，以便在特定進程訪問密鑰串時將代碼注入安全框架以記錄秘密。

Continuity Protocols

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），并完成了握手。

Security and Privacy Analysis

根據對多個連續性協議進行逆向工程的結果，對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，以演示下圖中攻擊的實際可行性。在視頻中，攻擊者在成功后向受害者提供了精心制作的門戶網站網頁。

（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應該能夠通過檢查是否為空或缺少字段來修復此漏洞，并且如果遇到意外的數據包，可以輕松地解決此漏洞。在提供修復程序之前，用戶可以在其設備上禁用藍牙以阻止攻擊。

Conclusion

盡管過去已發現嚴重的漏洞，但由于逆向工程的工程量巨大，因此難以分析的未記錄專有協議。本文對Apple Continuity無線生態系統進行結構化逆向工程的方法是實現獨立第三方安全審核的關鍵，實際上，這有助于保護全球15億臺設備的用戶。使用此方法，調查了接力（HO），通用剪貼板（UC）和Wi-Fi密碼共享（PWS）服務中涉及的協議，并發現了幾個導致拒絕服務（DoS）攻擊，設備跟蹤的漏洞以及中間設備（MitM）攻擊。實際上，所有攻擊都可以從附近的攻擊者那里發起，并且只需要低成本的硬件即可。為了將來進行類似的研究，調用制造商記錄其專有協議，就像Apple已經使用其Homekit附件協議（HAP）堆棧那樣。同時本文的詳細發現可以引導其他Continuity服務的分析，因為某些協議組件（例如，OPACK，Pair–Verify）似乎在服務之間共享，因此后續工作不必從頭再開始。