# BLURtooth: Exploiting Cross-Transport Key Derivation in Bluetooth Classic and Bluetooth Low Energy ###### tags: `Bluetooth Security` ## 1. Introduction * 藍芽標準為BT與BLC使用獨立的安全架構(`seperate security architecture`)以及威脅模型(`threat models`),雖然這些security architecture針對不同的threat models,但他們使用的相似的安全機制: `pairing`以及`secure session establishment` 1. `Pairing`: 建立長期的shared key 2. `Secure Session establishment`: 使得paired devices藉由從長期的pairing key得出的session key來建立安全的通訊管道 * 支援BT與BLE的devices需要配對兩次才能安全地使用兩種傳輸,因配對相同裝置兩次被視為"user-unfriendly",所以Bluetooth v4.2 引入了`Cross-Transport Key Derivation (CTKD)`的方法 * 舉例來說,兩個devices可以用BT來配對,產生了BT long term key,並透過CTKD來得到BLE long term key (無須透過BLE配對) * CTKD的安全性仍有待探索。舉例來說,藍芽標準在BT與BLE的thread models中並不包含CTKD ## 2. Background ### 2.1 BT v.s BLE * BT與BLE之間並不相容(incompatible,即使都用2.4 GHz band但他們的link layers不一樣)也不能互相操作(interoperate),代表BT裝置不能與BLE裝置直接溝通,只能透過支援BT以及BLE protocol的`dual-mode bluetooth module`(例如:手機、電腦、平板)才能在這兩個protocol間進行資料傳輸。然而像是一些low end devices(例如:鍵盤、滑鼠、穿戴裝置)則不是提供BT就是BLE 1. `BT (Bluetoth Classic)`適合用在**throughput高**的使用情境,例如:streaming audio (音訊經過壓縮透過封包傳遞資料,即時傳輸以供聆聽)以及voice calls(語音通話) 2. `BLC (Bluetooth Low Energy)`適合用在**低功耗**使用情境,例如:fitness tracker、localizing(定位)以及monitoring(監控) * BT與BLE使用不同的security architecture與threat models,兩種傳輸提供一種配對(pairing)機制`Secure Simple Pairing(SSP)`,來讓兩個裝置產生一個long term key, ### 2.2 CTKD (Cross-Transport Key Derivation) * Improving Dual-Mode Pairing * Showing both BT and BLE connections may confuse users * Solution: CTKD * Pairing once over BT or BLE and get the key of the other transport securely use both link key and LTK * Speedup the pairing process by using BLE advertising, instead of BT inquiry/paging ![](https://i.imgur.com/03VAE0q.png =500x200) * CTKD enables two devices to pair once, either over BT or BLE, and then securely use both: * Steps: 1. Pairing through BLE 1. Service Pairing Request 1. BLE LTK derivation 1. BLE connected and paired 1. BT Link Key derivation by LTK 1. BT connection request 1. BT connected and paired ![](https://i.imgur.com/shEUvZe.png =400x250) * If Secure Connections pairing occurs first on LE * Derivation of BR/EDR Link Key from LE LTK 1. LTK = f5(DHKey, N1, N2, BD_ADDRm, BD_ADDRs) * DHKey: Diffie-Hellman Key(ECDH) * N1, N2: rand_num generaterd and sent by Master and Slave, respectively * BD_ADDRm, BD_ADDRs: Bluetooth address of Master and Slave, respectively * f5(): Low Energy Secure Connections key generation function 2. ILK = h6(LTK, “tmp1”) * ILK: Intermediate Link Key * “tmp1”: keyID * h6(): Link Key Conversion function (AES-CMAC-128) 3. BR/EDR link key = h6(ILK, “lebr”) ![](https://i.imgur.com/qWtzTD2.png =250x300) ![](https://i.imgur.com/BnCSl0u.png =500x100) * If Secure Connections pairing occurs first on BR/EDR * Derivation of LE LTK from BR/EDR Link Key 1. Link Key透過f2拿到 1. ILTK = h6(Link Key, “tmp2”) 2. LTK = h6(ILKT, “brle”) ![](https://i.imgur.com/9sVcpEt.png =150x300) ### 2.3 CTKD life cycles * Phase 1: Discovery * 當Alice與Bob(slave)發現對方並交換資訊 (e.g. Alice進行scan, Bob則advertise自己的存在) * Phase 2: Pairing * 用ECDH(Diffie-Hellman)得出pairing key (e.g. BLE key或BT key) * 為了防止中間人攻擊,會進行SSP的assiciation phase (例如:比對兩方數字) * 最後透過第一個pairing key得到第二個pairing key (e.g. BLE key from BT key) * Phase 3: Communication * Alice與Bob透過shared pairing key來建立secure sessions * 每個session透過pairing key來得到session key * 用session key來進行加密(AES-CCM) ![](https://i.imgur.com/RmcnPR1.jpg =450x165) ### 2.4 Cross-Transport Issues with CTKD * CTKD的漏洞(vulnerability)就在其橫跨兩種連接方式 * CTKD life cycles上的5個issues,Cross-Transport Issues (CPI) * CTI 1: Roles (Discovery) * BT不像BLE一樣master與slave的角色是固定的,並且Alice可以透過BT來配對 * 攻擊者可以透過role個數不一致的弱點來冒充一個slave device,並透過BT傳送pairing request給Alice * CTI 2: Secure Connections (Discovery) * 在作者實驗中發現,CTKD的secure connection僅支援要配對的transport,而非兩種transport都支援 * CTI 3: Association (Pairing) * BT與BLE配對都需要一個association phase * 攻擊者可以用某個transport用像Just Works這樣的weak association來配對,而另外一個transport用像Numeric Comparison的strong association,那這樣就有機會發生impersonation attack因為user很難發現attacker用Just Works來偽裝成可信賴的裝置 * CTI 4: Key Overwrite (Pairing) * 假如Alice與Bob用BT進行secure session,攻擊者可以用BLE與Bob配對來冒充Alice(impersonation attack)並overwrite Alice與Bob的BT key * CTI 5: States (Communication) * 在作者的實驗中發現Alice與Bob之間用BT/BLE已建立secure sessions時,Alice與Bob依然是pairable,Bob在BLE還是discoverable * 攻擊者可以用Alice與Bob沒有在用的transport來進行配對,在某些CTKD的使用情景下,其中一個transport只是拿來進行配對並且得出另一個transport的key,因此這個transport會一直都是pairable但pairing後就不會再使用這個transport,這使攻擊者可以藉由pair沒用到的那個transport並強迫CTKD來建立一個意圖不明或惡意的sessions ## 3. STRIDE model >威脅建模(STRIDE):透過站在「攻擊者或是竊取者一樣的思路」以結構化的方法以及系統的識別,來評估產品、資訊系統或內部竊取的風險和威脅[6] * STRIDE: 1. Spoofing (欺騙) * 欺騙者假裝成某個人或另一個系統 ![](https://i.imgur.com/IVWfYHb.png =425x200) * 避免方式: (1) Single key (2) Access token (3) Signature 3. Tampering (竄改) * 未經授權竄改數據或硬體設定 * 避免方式: (1) 防火牆或分割硬碟確保原始數據不被覆蓋 (2) Log files來檢測受竄改的資料 5. Repudiation (否認性) * 安全系統應該建立在**不可否認**的機制下 (e.g. 傳送方或接收方,都不能否認曾進行資料傳輸或接收),並且保證可追蹤到不當行為 7. Information disclosure (資訊揭露) * 將資料洩漏給不該具有存取權的人手中 9. Denial of service (服務阻斷) * 侵占有限資源,使服務無法正常使用 11. Elevation of privilege (特權提升) * 透過擴展權限來影響系統 ## 4. BLUR Attacks on CTKD ### 4.1 BLUR Impersonation Attacks ### 4.2 BLUR Man-in-the-Middle Attack ### 4.3 BLUR Unintended Sessions Attack * Stride model of Unintended Sessions Attack [7] 如下圖所示,Alice與Bob(slave)要進行溝通,Charlie則為攻擊者。有些裝置不一定需要BT跟BLE都連接,若只有BT連接,則BLE空出來。當在進行unintended sessions attack攻擊時,因CTKD的機制,Charlie就可以送出BLE的配對請求給Bob。當CTKD完成後,Charlie就可以與Bob建立一個安全但意圖不明的BT與BLE sessions,同時不會打斷Bob現有的連線與session ![](https://i.imgur.com/TQndqfS.jpg =375x150) 1. **Spoofing**: Charlie 在 BT 連線後,會偽裝成其他的 BLE 裝置 2. **Tampering**: 連線成功後,Charlie 可能以 unknown device 的名義竄改資料 3. **Repudiation**: 在 BT 連線成功的前提下,Charlie 能以 unknown device 身分連線,後續追蹤unknown device可能會出問題 4. **Information disclosure**: 連線成功後,Charlie 可能取得並外洩資料 5. **Denial of service**: 無 6. **Elevation of privilege**: 連線成功後,Charlie 可能取得更高的權限 * Adaptive Strategy of Unintended Session Attack * **CTI2**: Secure Connections (Discovery) * 無法分辨 secure connections 是提供給單一 transport 還是雙方 transports 的 * Solution: 在CTKD執行前,將 BLE 與 BT 皆設為 secure * **CTI5**: States (Communication) * 提供更多選項來讓攻擊者攻擊,例: 在僅需一個 transport 的情境下佔用另一個、在配對專用的 transport 上建立惡意對話 * Solution: 在確定不需使用時,disable 閒置的 transport