BLESA：針對藍牙低能耗重連接的欺騙攻擊

藍牙低功耗（BLE，Bluetooth Low Energy）協議在資源受限的設備之間實現高能效的無線通信。為了簡化其應用，BLE需要有限的交互或不需要用戶交互才能在兩個設備之間建立連接。不幸的是，這種簡單性是幾個安全問題的根本原因。在本文中，重點分析了兩個先前連接的設備重新連接的情況，從而分析了BLE鏈路層的安全性。在對BLE規范定義的重新連接過程進行形式化分析的基礎上，本文重點說明了該規范中的兩個關鍵安全漏洞。結果，即使是正確實現BLE協議的設備也可能容易受到欺騙攻擊。

為了證明這些設計缺陷，并進一步研究其安全隱患，本研究開發了BLE欺騙攻擊（BLESA，BLE Spoofifing Attacks）。這些攻擊使攻擊者可以模擬BLE設備并將欺騙性數據提供給另一個先前配對的設備。BLESA可以很容易地針對BLE協議的某些實現進行實施，例如Linux中使用的一種。此外，對于Android和iOS使用的BLE堆棧實現，發現了一個啟用BLESA的邏輯錯誤，將此安全問題報告給了受影響的各方（Google和Apple），他們也承認了本文的發現。

Introduction

低功耗藍牙（BLE）是使用最廣泛的低能耗通信協議，到2023年，支持BLE的設備數量有望達到50億。BLE協議支持無線短距離通信，該通信允許兩個設備連接和交換數據。非典型使用場景由智能手機和通過BLE進行通信的“小工具”設備（例如健身追蹤器）組成。每個BLE連接都涉及充當客戶端的設備（在此示例中為智能手機）和充當服務器的另一設備（在此示例為健身追蹤器）。第一次，兩個設備進行連接（允許它們交換數據），它們執行特定的配對過程，具體過程取決于所連接設備的類型及其用戶界面的功能。

促成啟用BLE的設備的快速增長的主要因素是其低成本和最終用戶所需的最少設置工作。先前的研究表明這些用戶友好的功能對該協議的安全性具有負面影響。由于BLE通信通常用于對安全敏感的設備中，例如物理安全設備（例如，鎖）或健康監控設備（例如，醫療植入物）[16]，因此這種擔憂尤其令人擔憂。

研究人員通過手動分析其規范指出并研究了BLE協議中的許多實現缺陷。此外，一些先前的工作還對BLE規范進行了自動的形式化分析。但是，這些形式化方法僅關注整個協議的有限方面，例如BLE配對機制。這種局限性是由于以下事實：完全規范化和自動分析BLE規范具有挑戰性。挑戰來自BLE協議的復雜性，建模其多層設計的困難，其多種變體和可選功能（這使該協議能夠支持功能明顯不同的各種設備）。

Threat Model

在本文中，研究了BLE協議一個尚未探索的機制。具體來說，專注于處理重新連接兩個先前連接的設備的機制。例如，當服務器設備（例如，健身跟蹤器）移出所連接的客戶端設備（例如，智能手機）的BLE無線通信范圍之外，然后稍后，這兩個設備足夠靠近時，該機制就起作用了重新建立連接。

為了開始對此場景的分析，首先使用ProVerif協議驗證程序對相關的BLE鏈路層規范進行了正式驗證。本文的形式化分析強調了BLE官方規范中的兩個弱點。這些漏洞（在某些BLE堆棧實現中）使攻擊者可以發起欺騙性攻擊，在這種攻擊中，攻擊者偽裝成先前配對的服務器設備，從而誘使客戶端設備接受欺騙性數據。

特別是發現BLE規范允許以多種方式實現此協議的多個方面，其中某些方面很容易受到攻擊。因此，即使在規范之后正確執行BLE協議棧，也很容易受到欺騙攻擊。例如，發現BLE協議棧（通過gatttool進行訪問）在Linux客戶端設備（例如，Linux筆記本電腦）中正確遵循BLE規范時，很容易受到所識別的欺騙攻擊的影響。

此外還發現，即使以理論上不易受到已識別攻擊的方式實現的BLE協議棧，由于特定的邏輯漏洞，在實踐中仍然容易受到攻擊。具體來說，在Android設備使用的BLE堆棧和iOS設備使用的BLE堆棧中發現了類似的實現問題。此問題使許多Android和iOS設備容易受到已識別的攻擊。已將發現的問題報告給Google和Apple，他們已確認了這些漏洞。截至2020年6月，Apple已為漏洞分配了CVE-2020-9770并對其進行了修復，但經過測試的設備（即運行Android10的Google Pixel XL）中的Android BLE實施仍然很容易受到攻擊。

為了展示確定的問題，設計了一種新穎的攻擊稱為BLESA（BLE欺騙攻擊）。在BLESA中，攻擊者假裝是先前配對的服務器設備，拒絕了來自客戶端設備的身份驗證請求，然后將欺騙性數據提供給它。然后，表明運行Ubuntu且其BLE堆棧的最新版本的Linux筆記本電腦容易受到BLESA的攻擊。另外，通過將它發布到Google Pixel XL手機上來展示BLESA的有效性，該手機記錄了來自稱為OuraRing的可穿戴活動跟蹤設備的信息。特別是，通過使用BLESA，攻擊者成功假冒了該手環，將欺騙數據注入到手機中，并且在手機上運行的環的配套應用程序接受并顯示了欺騙數據。

假設攻擊者具有與Dolev-Yao模型相同的功能，即，攻擊者可以竊聽，攔截和修改服務器與客戶端之間傳遞的合法消息。攻擊者還可以將任何消息注入通信渠道。但是，攻擊者不知道服務器和客戶端之間共享的密鑰，并且所使用的加密功能是完全安全的。而且，攻擊者無法替換服務器或客戶端的固件。由于BLE是一種短距離通信協議，因此假設攻擊者與客戶端之間的距離以及攻擊者與服務器之間的距離都在藍牙范圍內， 用欺騙性消息誤導客戶。

Formal Analysis of BLE Reconnection

當客戶端與先前連接的服務器重新連接時，將對BLE鏈路層身份驗證機制進行正式驗證。利用ProVerif進行此協議驗證。

A.ProVerif模型

當客戶端在新會話中與服務器重新連接時，將為身份驗證過程建立一個正式的模型。身份驗證過程被建模為兩個通信狀態機，一個用于客戶端，一個用于服務器。在BLE規范中，對與客戶端的屬性請求的傳輸相對應的狀態機和與服務器上的屬性請求的處理相對應的狀態機進行建模。該模型全面涵蓋了不同類型的消息，包括與屬性訪問請求，屬性訪問響應和錯誤響應相對應的消息。客戶端和服務器之間的通信被建模為自由（或開放）通道（free plain_channel：channel），在該通道中，攻擊者具有威脅模型中描述的功能。

還考慮了屬性的所有特征，以涵蓋服務器設備的不同使用場景。因此，將服務器上的屬性建模為可讀和可寫。此外對兩種類型的屬性進行建模：（1）無需配對即可訪問的基本屬性（即，在安全級別1），以及（2）敏感屬性配對后即可訪問（安全級別為2或更高）。最后，對客戶端進行建模以將訪問請求發送到服務器，以按不同的順序讀取/寫入這兩種類型的屬性。配對期間建立的共享密鑰用于在需要加密時對通信進行加密/解密。

安全目標：根據上面代碼中列出的傳統安全目標來分析上述模型。這些安全目標包括：（1）機密性，即，所傳達的消息不應將任何敏感數據泄露給攻擊者（第6-9行），（2）完整性，即所傳遞的消息不應被攻擊者篡改而不被檢測到（第6-9行），以及（3）真實性，即可以驗證所傳遞的消息是由真實發件者生成的（第11行）。此外，當啟動來自客戶端的請求并處理服務器上的請求時，還將檢查從規范中指定的規則中提取的一個BLE特定安全目標。僅當連接的安全級別與訪問該屬性的要求一致時，服務器才應授予對客戶端的讀/寫訪問權限（第13行）。

B.發現的設計缺陷

通過正式驗證，當先前連接的設備重新連接時，本研究發現了一些違反已檢查的安全目標的情況。這些違規導致以下兩個安全漏洞，攻擊者可能會利用這些漏洞來發起欺騙攻擊。

漏洞1：可選身份驗證

發現鏈路層加密/身份驗證是可選的：客戶端和服務器可以針對特定屬性選擇禁用它。因此，在基本屬性的情況下，可能會違反屬性訪問請求和響應的機密性，完整性和真實性目標，如ProVerif的以下結果所示。

反例：

注意到，服務器根據所請求屬性的訪問控制策略來確定其與客戶端的連接的安全級別。如計數器示例所示，當訪問控制策略允許連接的最低安全級別（即安全級別1）時，可以以純文本形式發送屬性訪問請求和響應。在這種情況下，將不會部署任何鏈路層身份驗證。因此，攻擊者可以對服務器和客戶端設備發起欺騙攻擊。

由于連接的安全級別由服務器指導，因此如果服務器僅允許安全級別為1的連接，則客戶端將無法強制執行更高安全級別的連接。這方面使得服務器和客戶端都容易受到欺騙攻擊。

漏洞2：規避身份驗證

當客戶端在配對后與服務器重新連接時，BLE規范提供了兩種可能的身份驗證過程。

（1）響應式認證：在此過程中，客戶端在建立連接后立即以純文本（即，安全級別1）發送屬性訪問請求。僅當服務器響應并顯示一條錯誤消息，表明連接的當前安全級別與訪問該屬性所需的安全級別不一致時，客戶端才會通過啟用加密/身份驗證做出反應。對于此過程，形式分析表明可以違反訪問響應的真實性，如下面的ProVerif輸出所示。

反例：

盡管存儲在服務器上的敏感屬性沒有泄漏給攻擊者，但攻擊者可以竊聽客戶端發送的請求，模擬服務器并用與敏感屬性相對應的欺騙響應來欺騙客戶端。Linux上的現有BLE堆棧實現（當通過gatttool訪問時）遵循此反應式身份驗證，從而使相應的客戶端容易受到欺騙攻擊。

（2）主動式身份驗證：在此過程中，客戶端設備會在向服務器發送任何請求之前主動啟用加密/身份驗證。特別是，客戶端使用先前建立的預共享密鑰啟用加密，然后繼續進行身份驗證。在這種情況下，如果服務器未能啟用加密（這也意味著它未能啟用身份驗證） ，客戶端將中止連接。形式化驗證表明，所有檢查的安全目標都在主動身份驗證期間成立，如以下結果所示。

不幸的是，Andriod和iOS使用的現有BLE堆棧實現無法正確遵循此過程，從而使相應的客戶端容易受到欺騙攻擊。

BLE Spoofing Attack(BLESA)

通過形式化驗證確定的設計漏洞來構造BLE欺騙攻擊（BLESA）。在這種攻擊中，攻擊者向偽裝成先前配對服務器設備的客戶端設備提供欺騙數據。

攻擊設置：本研究檢查了服務器和客戶端在上一個會話中安全配對的情況，當前它們已斷開連接，但它們打算開始新的會話。例如，當客戶端移出服務器的通信范圍然后又返回時，就會發生這種情況。

在這種情況下，攻擊者首先發現服務器并與其連接以獲得有關服務器屬性的信息（例如標識符）。由于BLE協議旨在允許任何設備與另一個BLE設備連接并獲取有關提供的屬性的信息，因此攻擊者可以輕松獲取此信息。此外，由于BLE廣播數據包始終以明文形式發送，因此攻擊者可以通過廣播相同的數據包并克隆其MAC地址來輕松地模擬良性服務器。然后，攻擊者開始廣播欺騙性的廣告包以確保無論何時客戶端嘗試啟動與先前配對的服務器進行新會話后，它可以發現欺騙性廣播包并與攻擊者建立連接。此時，攻擊者已準備好針對客戶端啟動BLESA。在以下各節中，將按照被動身份驗證過程以及遵循主動身份驗證過程針對客戶端介紹BLESA的工作流。

A.針對響應式身份驗證的BLESA

上圖a展示了客戶端和服務器重新連接以及反應式身份驗證過程在良性環境中進行的示意圖。客戶端首先向最低安全級別（即，安全級別1級的服務器發送屬性讀取請求），無需任何加密/身份驗證。如果屬性是敏感的并且可以在更高的安全級別（例如，具有加密和身份驗證的安全級別3）上是只讀的，則服務器會以錯誤消息（例如，加密不足）來響應客戶端。收到錯誤消息后，客戶端通過使用預共享的密鑰啟用加密和身份驗證來提高安全級別，然后再次發送請求。此時，服務器很容易接受讀取請求并返回屬性值。

現在，介紹BLESA的工作流程，如上圖b所示。在此，攻擊者攔截來自客戶端的屬性讀請求并以欺騙性的屬性值進行響應。由于客戶端沒有遇到任何錯誤消息，因此錯誤地假定可以在最低安全級別（即，以純文本格式）訪問該屬性。因此，客戶端不啟用加密/身份驗證，并且接受欺騙的屬性值。在BLESA的此實例中，使攻擊成為可能的根本原因是客戶端設備依賴于服務器的錯誤消息來進行攻擊。調整使用的安全級別。

B.針對主動式身份驗證的BLESA

上圖a顯示了客戶端設備與良性服務器重新連接時觸發的主動身份驗證過程的工作流程。連接后，客戶端立即請求使用預共享密鑰啟用加密（和身份驗證），服務器將遵守該請求。然后，客戶端安全地發送屬性讀取請求，并且服務器使用（加密和認證的）屬性值安全地進行響應。如果BLE堆棧正確地執行了主動身份驗證，遵循了規范，則BLESA將失敗。但是進一步分析表明，基于Android和iOS的客戶端設備都遭受邏輯錯誤，使BLESA可以針對這些設備。

上圖b展示了BLESA如何使用主動身份驗證過程成功勝過客戶端設備，但受到所解釋的實施漏洞的影響。具體地，在連接到攻擊者之后，如果客戶端嘗試啟用加密，則攻擊者向客戶端發送一條錯誤消息，指定長期密鑰不可用，從而使加密失敗。此時，客戶端未正確遵循BLE規范（在這種情況下，建議中止連接），但繼續與攻擊者建立連接，客戶端隨后繼續以明文形式發送對目標屬性的讀取請求。與服務器不同，攻擊者很容易授予對屬性的訪問權限，使其在最低安全級別（即安全級別1）下可用，并將偽造的屬性數據提供給客戶端。因此，客戶接受來自攻擊者的欺騙性數據。

漏洞利用：根據BLE規范，當客戶端與先前配對的服務器重新連接時，如果在主動身份驗證過程中加密啟用過程失敗，則客戶端應與服務器重新配對（如上圖所示）或中止連接。但是，某些客戶端（即基于Android和iOS的設備）中的BLE堆棧無法正確遵循規范。具體來說，發現即使啟用加密過程失敗，客戶端也可能不會中止連接并以明文形式繼續通信，而無需與服務器重新配對。攻擊者可以利用此缺陷來啟動BLESA。懷疑此實現漏洞可能是由官方文檔中解釋BLE協議這一部分的方式引起的。

為了訪問基本屬性，并且某些服務器設備不支持鏈路層加密（即設計漏洞1），BLE規范做出了一些規定，以維護與這些資源受限的服務器設備的兼容性并增強可用性。因此，當加密/身份驗證失敗時，仍然可以按照規范中的說明以純文本格式傳輸BLEdata和控制消息（上圖）。認為上圖中所示規范中的細節引起的矛盾可能使BLE堆棧開發人員感到困惑。這樣，他們犯了邏輯錯誤，即在加密過程失敗的情況下不中止連接，這對于訪問先前配對的服務器上的安全敏感屬性是必不可少的。

Implementation and Impact

A.設計漏洞-1的檢查

為了確定是否確實存在某些不使用鏈路層身份驗證的BLE服務器設備，采用兩種方法：（1）通過靜態分析來檢查一組BLE設備的配套應用程序的行為。（2）對一組實際的BLE設備進行采樣，并通過運行時分析檢查它們的通信數據包。

移動應用程序的靜態分析：典型的BLE設備（例如Fitbit健身追蹤器）依賴于其伴隨移動應用程序（例如Fitbit應用程序），該應用程序使最終用戶能夠訪問和管理記錄的屬性數據（例如步數）。由于配對過程（建立密鑰）是啟用鏈路層身份驗證的先決條件之一，因此，如果在其伴隨應用程序中未調用配對API，可以很容易地確認BLE設備不支持鏈路層身份驗證。為此，利用靜態分析框架FlowDroid來檢查Android BLE應用程序。更具體地說，對于每個伴隨應用程序，在FlowDroid中使用Class Hierarchical Analysis（CHA）選項來構建調用圖，并確定是否應用程序確實從其任何入口點（例如，活動）調用配對API。由于CHA是用于調用圖構造的相對保守的方法，因此可能會丟失部分方法調用。但是，與其他選項（例如，SPARK）相比，分析結果更加精確，誤報率極低。因此，它使用配對提供了一個較低范圍的BLE app。

靜態分析從33,785個受歡迎的應用程序開始，這些應用程序于2020年1月和2020年2月從AndroZoo網站自動爬取。基于這些應用程序的構造調用圖和相應的API，發現只有127個應用程序包含讀取的BLE數據讀/寫操作。然后，檢查在這些應用程序中是否調用了配對API（createBond( )）。不幸的是，發現在127個檢查的應用程序中，只有41個（32.3％）包含配對過程，這意味著大多數被調查的BLE伴侶應用程序（67.7％）沒有實現鏈路層身份驗證。

傳輸數據包的運行分析：研究了12種BLE設備（如上表所示），這些設備被選擇代表了主流BLE設備制造商的各種應用。將每臺服務器設備與Google Pixel XL手機相連，并讀取其屬性。在這些實驗中，使用Ubertooth One無線電攔截運行時通信的數據包。通過分析截獲的數據包，發現在檢查的12個BLE設備中，有10個不支持任何鏈路層加密/身份驗證。為此得出的結論是，大多數現實世界中的BLE設備都不采用鏈路層身份驗證。

B.設計漏洞-2的檢查

為了檢驗第二個漏洞，測試了四個不同的客戶端設備，它們涵蓋了具有不同BLE堆棧實現的所有主要平臺。在下表中提供了有關這些設備的詳細信息。在每個平臺上進行實驗，以探討以下兩個問題的答案：（1）兩種身份驗證程序中的哪一個客戶端設備在與服務器設備重新連接時會利用嗎？（2）如果客戶端設備遵循主動身份驗證過程，則其BLE堆棧實現是否存在任何邏輯缺陷，使其容易受到欺騙攻擊？

為了回答這兩個問題，首先將每個經過測試的客戶端與一臺服務器（使用Linux筆記本電腦進行仿真，如下表所示）配對，然后斷開它們的連接。之后將經過測試的客戶端與同一服務器重新連接，并要求客戶端讀取服務器的屬性之一，同時使用Wireshark捕獲所有生成的BLE流量。

通過分析與用作客戶端的Linuxlaptop對應的流量數據，發現Linux BLE堆棧（即通過gatttool訪問的BlueZ）實現了響應式身份驗證過程。結果，Linux BLE遭受了漏洞2的困擾。相反，發現Android，iOS和WindowsBLE堆棧實現了主動身份驗證過程，其中Windows BLE堆棧嚴格遵循BLE規范。但是，即使加密/驗證失敗，Android和iOS設備也會繼續重新連接。

責任披露：已于2019年4月8日向Apple和Google報告了此漏洞。Apple已確認本文的發現，已將CVE-2020-9770分配給該漏洞，并進行了修復。盡管Google也確認了該漏洞，但被告知漏洞報告類似于比本研究早三天提交的另一份報告。注意到，測試設備（即具有Android 10的Google Pixel XL）中，較新的Android BLE實施（截至2020年5月）仍然很容易受到攻擊。

C.針對Linux客戶端的BLESA

為了攻擊Linux客戶端（前表第三行中列出），使用另一臺Linux筆記本電腦作為服務器設備。模擬的服務器運行python腳本以提供與敏感屬性相對應的服務，該屬性可以在安全級別3（即具有加密和身份驗證的連接）下讀取。為了模擬攻擊者，使用帶有CSR 4.0藍牙加密狗的Linux桌面（如下表所示）。攻擊者還運行一個Python腳本，該腳本處理從客戶端接收到的消息，并針對該客戶端啟動BLESA。此外，在客戶端設備上使用thegatttool發送屬性讀取請求并接收響應。

為了啟動BLESA，攻擊者執行以下步驟：?掃描（bluetoothctl）服務器發送的廣告包以記錄其MAC地址；?將攻擊者的藍牙MAC地址（BlueZ中的bdaddr工具）更改為服務器的MAC地址，以便客戶端可以與攻擊者重新建立連接；通過向加密狗發出主機控制器接口（HCI）命令，HCI_LE_Set_Advertising_Parameters，HCI_LE_Set_Advertising_Data和HCI_LE_Set_Advertising_Enable來廣播與服務器相同的（模擬的）廣播包；?在從客戶端接收到ATT_READ_REQ消息后，通過ATT_READ_RSP消息注入欺騙數據。

通過執行這些步驟，攻擊者成功繞過了Linuxclient的反應式身份驗證過程，并誘使客戶端接受欺騙數據。

D.針對Android / iOS客戶端的BLESA

由于BLESA通過將連接降級為純文本來繞過鏈路層身份驗證，因此與不使用任何應用程序層安全性機制（例如，加密或身份驗證）的BLE服務器設備通信的所有基于Android和iOS的客戶端設備都容易受到BLESA的攻擊。注意到根據先前的研究，從BLE服務器設備讀取數據時，有46％的Android應用程序（累計安裝量為23.79億）未利用應用程序層安全性。這意味著至少46％的Andriod應用程序容易受到BLESA的攻擊。Apple應用程序商店中的易受攻擊的應用程序所占的比例很可能相似。

在這里展示了攻擊者（如前表所示）如何通過模擬Oura環將BLESA投放到Google Pixel手機上。攻擊者執行前三個步驟，即?掃描環的廣播數據包；?克隆廣播包和環的MAC地址。此后，攻擊者執行以下操作：?發送HCI命令HCI_LE_Long_Term_Key_Request_Negative_Reply，指示在收到HCI事件HCI_LE_Long_Term_Key_Request時，密鑰無法繞過加密和身份驗證；?在之后從ATT_READ_RSQ消息中通過ATT_READ_RSP消息注入欺騙數據。注意到，攻擊者可以按照相同的步驟針對iOS客戶端設備啟動BLESA。

通過執行這些步驟，攻擊者成功地將欺騙的數據注入到智能手機中，并且在智能手機上運行的環的配套應用程序將欺騙的數據顯示給用戶。上圖a顯示，在實驗中，Oura Ring設備的實際電池電量為43％。通過BLESA，成功地向應用程序注入了偽造的電池電量（0％），如圖b所示;同時，還注入了另一條欺騙性消息，該消息觸發了應用程序中的通知，提示充電已完成，如圖c所示。

注意到，盡管第一個欺騙消息使應用程序認為電池電量為0％，但有趣的是，該應用程序接受了另一個欺騙消息（對應于充電完成）并向用戶顯示錯誤通知。可以在https://pursec.cs.purdue.edu/projects/blesa.html 上訪問此攻擊的演示。

Mitigation of BLESA

為了防止BLESA，需要確保客戶端與其之前配對的服務器設備之間的重新連接過程安全。可以通過改進BLE堆棧實現和/或更新BLE規范來實現這一目標。

更新實施：就Linux BLEstack（通過gatttool訪問的BlueZ）而言，可以將客戶端設備更新為僅采用主動身份驗證。根據BlueZ開發人員，他們已將gatttoolas標記為不推薦使用，它將從BlueZ中完全刪除gatttool及其源代碼，并且僅保留bluetoothctl。此外，可以通過正確遵循BLE規范來緩解已發現的Android和iOS客戶端使用的主動身份驗證的實現漏洞。更新的實現必須確保當與先前配對的服務器的身份驗證失敗時，客戶端將中止連接并重新啟動配對過程。

一個更根本的問題是，即使對于主動身份驗證，BLESA也會在實現中存在其他潛在錯誤的情況下繞過鏈路層身份驗證。這是安全研究人員建議在多層上進行身份驗證的典型方案。實際上，如果在應用程序層進行身份驗證/加密，則鏈路層問題就不會成為可利用的問題。不幸的是，這種改進可能會不能廣泛部署，因為很大一部分資源受限的設備無法遠程更新。

修訂規范：雖然修復錯誤以使BLE設備快速抵御BLESA是很重要的，但制定出規范以防止更高級的欺騙攻擊也同樣重要。為此，應防止客戶端首先發送屬性訪問請求然后根據服務器返回的錯誤消息調整連接的安全級別。換句話說，在發送訪問請求之前，客戶端應首先獲取有關存儲在服務器上的屬性的訪問要求的真實信息，然后調整連接的安全級別以滿足這些要求。但是，此方法要求客戶端在配對過程中記錄服務器上每個屬性的安全要求。因此，需要更新規范中的配對過程，以便服務器可以將其每個屬性的安全性要求發送給客戶端。

Conclusion

在本文中對BLE規范中定義的重新連接過程進行了形式驗證，并發現了BLE鏈路層身份驗證機制中的兩個設計缺陷。通過利用這些設計缺陷，本研究提出了BLESA，這是一種新穎的BLE欺騙攻擊，攻擊者可以通過它模擬BLE服務器設備并將欺騙數據提供給先前配對的BLE客戶端設備。BLESA可以輕松地針對運行Linux的BLE設備啟動（通過gatttool訪問）。

此外，對已發現的現實BLE實現中的漏洞的進一步檢查，揭示了Android和iOS BLE堆棧中的一個相關實現漏洞。由于存在此漏洞，這兩個堆棧都容易受到BLESA的攻擊。為了展示BLESA，詳細介紹了如何使用此攻擊來將來自健身追蹤器的數據欺騙到Android智能手機。此外，估計了可能受到此攻擊影響的現有Android應用程序的數量。最后討論了重新連接過程中可能的改進，以從根本上減輕BLESA等欺騙攻擊的威脅。