1. BLE廣播數(shù)據(jù)設(shè)備的第一張名片當(dāng)BLE設(shè)備處于未連接狀態(tài)時廣播Advertising是其與外界通信的唯一方式。這些周期性發(fā)送的廣播包就像設(shè)備的電子名片包含了大量可供掃描設(shè)備讀取的信息。一個典型的廣播報文由多個AD Structure組成每個AD Structure包含1字節(jié)長度、1字節(jié)AD Type和N字節(jié)AD Data。1.1 廣播包的核心構(gòu)成要素Flags0x01這個必選字段揭示了設(shè)備的基礎(chǔ)能力0x02 LE Limited Discoverable Mode 0x04 LE General Discoverable Mode 0x08 BR/EDR Not Supported 0x10 Simultaneous LE and BR/EDR ControllerComplete Local Name0x09設(shè)備名稱可能是最容易被濫用的信息。許多廠商使用包含型號、用途的命名規(guī)則如Fitbit-Charge5-AB12這直接暴露了設(shè)備類型和可能的用戶群體。Service UUIDs0x02/0x03/0x06/0x07廣播的服務(wù)UUID就像設(shè)備的功能菜單例如0x180DHeart Rate暴露這是健康設(shè)備0x180FBattery Service提示設(shè)備有電量監(jiān)控需求自定義UUID可能直接關(guān)聯(lián)到特定廠商的生態(tài)Manufacturer Specific Data0xFF這個廠商自定義字段通常包含# 典型結(jié)構(gòu)示例 company_id data[0:2] # 如0x004CApple custom_data data[2:] # 可能包含固件版本、狀態(tài)碼等TX Power Level0x0A這個1字節(jié)的發(fā)射功率值單位dBm可被用于距離估算。精明的攻擊者可以通過信號強度變化推斷設(shè)備移動軌跡。1.2 iOS系統(tǒng)的廣播限制策略蘋果在iOS系統(tǒng)中實施了嚴(yán)格的廣播過濾機制當(dāng)應(yīng)用處于后臺時只能讀取到設(shè)備UUID和信號強度即使在前臺部分AD Type如Device Address也會被屏蔽連續(xù)掃描會被系統(tǒng)限制每次掃描最多持續(xù)幾秒實測發(fā)現(xiàn)iOS 15設(shè)備在鎖屏狀態(tài)下廣播的Local Name字段會被自動替換為iPhone。這是蘋果針對跟蹤防護的重要改進。2. GAP層暴露的設(shè)備元信息Generic Access ProfileGAP定義了BLE設(shè)備如何被發(fā)現(xiàn)和連接。在連接建立前以下GAP參數(shù)已經(jīng)暴露2.1 設(shè)備地址BD_ADDR的隱私問題傳統(tǒng)BLE設(shè)備使用48位的公共地址類似MAC地址這帶來了永久性追蹤風(fēng)險?，F(xiàn)代設(shè)備采用可解析私有地址RPA機制graph LR A[Identity Resolution Key] -- B[隨機生成地址] B -- C[定期變更規(guī)則] C -- D[只有綁定設(shè)備能解析]但實際部署中存在三個常見漏洞部分廉價芯片在廣播中仍使用靜態(tài)地址地址隨機化間隔設(shè)置過長如30分鐘不變特定廣播事件如低電量警告會觸發(fā)固定地址模式2.2 連接參數(shù)預(yù)協(xié)商在Connection Request包中以下參數(shù)已經(jīng)暴露Connection Interval1.25ms單位Slave Latency允許跳過的連接事件數(shù)Supervision Timeout10ms單位這些參數(shù)實際上反映了設(shè)備類型智能手表短Interval15-30ms低Latency溫度傳感器長Interval100-200ms高Latency3. ATT/GATT層的預(yù)連接信息暴露雖然正式的數(shù)據(jù)交換發(fā)生在連接后但ATT/GATT協(xié)議在連接前已經(jīng)通過以下方式泄露信息3.1 Service Change Indication特性設(shè)備通過Service Changed特性0x2A05聲明其服務(wù)列表是否可變。這個看似無害的標(biāo)記實際上暴露了設(shè)備固件架構(gòu)值為0x0000-0xFFFF表示靜態(tài)服務(wù)列表啟用通知表示支持動態(tài)服務(wù)更新3.2 預(yù)期的MTU大小在連接參數(shù)請求中設(shè)備會聲明其支持的MTU大小默認(rèn)23字節(jié)。要求較大MTU如247字節(jié)的設(shè)備通常屬于需要傳輸大量數(shù)據(jù)的醫(yī)療設(shè)備支持OTA固件更新的IoT設(shè)備具有復(fù)雜控制界面的專業(yè)設(shè)備4. iOS系統(tǒng)級處理的特殊行為蘋果設(shè)備在BLE交互中表現(xiàn)出獨特的系統(tǒng)級特征4.1 定向廣播的隱私保護iOS設(shè)備在發(fā)起連接時使用特殊的Directed Advertising目標(biāo)設(shè)備地址被加密處理廣播持續(xù)時間嚴(yán)格限制在1.28秒內(nèi)未配對的設(shè)備無法解析真實地址4.2 后臺連接限制即使應(yīng)用獲得藍(lán)牙后臺權(quán)限iOS仍會施加以下限制連接事件間隔被強制延長不少于30秒每次數(shù)據(jù)傳輸后連接自動斷開GATT服務(wù)發(fā)現(xiàn)操作會被延遲執(zhí)行5. 安全防護的實踐建議基于上述分析建議設(shè)備開發(fā)者采取以下措施5.1 廣播數(shù)據(jù)的精簡策略# 安全的廣播包配置示例 adv_data { 0x01: [0x06], # 僅聲明BLE通用發(fā)現(xiàn)模式 0x09: Device, # 通用名稱 0x07: [0x1234] # 僅暴露必要服務(wù)UUID }5.2 連接參數(shù)的最佳實踐采用動態(tài)RPA地址變更間隔≤15分鐘為不同場景設(shè)置差異化連接參數(shù)數(shù)據(jù)傳輸Interval15-30ms待機狀態(tài)Interval≥200ms實現(xiàn)白名單過濾機制5.3 iOS適配的特殊處理在Info.plist中添加keyNSBluetoothAlwaysUsageDescription/key string用于設(shè)備連接和數(shù)據(jù)同步/string使用CBCentralManager的state restoration機制對敏感服務(wù)實現(xiàn)動態(tài)注冊機制在開發(fā)BLE產(chǎn)品時我強烈建議在原型階段就使用nRF Connect等工具進行廣播包分析確保不會無意中暴露過多信息。一個實用的技巧是在廣播數(shù)據(jù)中使用臨時隨機標(biāo)識符待連接建立后再通過安全通道交換真實信息。