摘要

此份報告深入分析了經典「Blinkenlights」側通道攻擊(Side-channel attack)的現代應用，它被成功用於從使用 JieLi 系統單晶片（System-on-Chip, SoC）的低價穿戴式裝置中提取 firmware。分析聚焦於兩個主要的安全弱點：一個有缺陷的低功耗藍牙 (Bluetooth Low Energy, BLE) Over-The-Air (OTA) 認證機制，以及利用顯示器更新時序作為資料外洩的隱藏通道。此方法強調了資源受限的裝置對實體和邏輯側通道攻擊的漏洞，強調了除了簡單的混淆之外，對穩健安全協定至關重要的需求。研究結果強調，即使是微小的視覺或電磁洩漏，也可被利用來危害裝置的完整性，此原理最早在 2000 年代被證明，現在已針對物聯網（Internet of Things, IoT）時代進行了現代化 [1]。

IoT 安全的致命盲點：JieLi 晶片 BLE 認證缺陷與視覺側通道漏洞 | 資訊安全新聞

1. 簡介

低價、大眾市場 IoT 裝置的激增，帶來了一類新的安全挑戰。這些裝置通常圍繞著廉價、文件極少的 SoC（例如 JieLi AC6958C6）構建，經常將成本和功能置於安全之上。此處檢視的案例研究涉及一個穿戴式裝置，研究人員最初嘗試用傳統方法提取 firmware 受阻，因此轉向探索側通道技術。這次成功的入侵是透過結合對該裝置 BLE 通訊協定的分析，以及巧妙利用其螢幕更新機制所達成的。 [1]。此方法重現了 Blinkenlights 攻擊的概念，即裝置的視覺輸出被用來推斷內部狀態或資料，這是一種歷史上與從網路設備上閃爍的 LED 燈提取資料相關的技術 [2]。

2. 技術背景

2.1. 低功耗藍牙 (BLE) OTA 安全性

BLE 是穿戴式技術中短距離無線通訊的標準。Over-The-Air (OTA) 更新程序允許 firmware 無線更新，是一個關鍵的安全邊界。一個安全的 OTA 程序通常需要強大的認證、加密和 firmware 簽章，以防止未經授權的程式執行。然而，許多實作，特別是在平價硬體中，配備了薄弱或專有的認證方案。BLE 安全協定中的漏洞，例如被歸類為 SweynTooth 或 PerfektBlue 的那些，通常源於標準程序（如配對和金鑰交換）的實作有缺陷 [3]。在分析的裝置中，安全上的失敗始於一個專有的認證 Handshaking，而此 Handshaking 很容易被逆向工程。

2.2. Blinkenlights 側通道原理

Blinkenlights 攻擊是一種側通道分析的形式，它利用裝置實體表現中的非預期資訊洩漏。從歷史上看，這涉及監控網路硬體上的活動燈（blinkenlights）來推斷正在處理的資料 [2]。應用於穿戴式裝置的現代變體利用了顯示器的更新程序。當上傳一個客製化的手錶錶盤時，由於預設 BLE Maximum Transmission Unit (MTU) 較小（23 bytes），資料傳輸速率被觀察到很慢。至關重要的是，顯示器的更新本身被發現是寫入裝置記憶體的資料的直接體現，儘管這種體現在視覺上很細微 [1]。螢幕有效地成為了一個視覺側通道，在 firmware 資料被寫入時，byte-by-byte 地洩漏了它。

3. JieLi OTA 認證 Handshaking 分析

攻擊的初始階段涉及分析 JieLi OTA 應用程式實作的專有認證 Handshaking 。透過監控 BLE 流量（特別是 Android 應用程式的 logcat 輸出），研究人員能夠繪製出資料交換的序列。此 Handshaking 在任何 firmware 傳輸之前進行，被發現是一個可預測的多步驟程序，似乎不依賴強大的加密質詢-回應機制。觀察到的序列詳述如下 [1]：

sequenceDiagram     participant APP     participant Device          APP->>Device: Auth Data (17 bytes, starts with 0x00)     Note right of Device: Device processes data     Device->>APP: Response (17 bytes, starts with 0x01)          APP->>Device: "pass" Command (5 bytes, starts with 0x02)     Note right of Device: Device processes "pass"     Device->>APP: Response (17 bytes, starts with 0x00)          APP->>Device: Final Auth Data (17 bytes, starts with 0x01)     Note right of Device: Device confirms authentication     Device->>APP: "pass" Confirmation (5 bytes, starts with 0x02)          Note over APP,Device: Authentication Successful. OTA process can begin.

對 logcat 輸出的分析提供了確切的位元組序列，揭示了一個可以輕鬆複製的模式。例如，第三步驟涉及應用程式發送一個以 `0x02` 開頭的 5 byte 緩衝區，後面跟著 ASCII 字串 "pass" (`0x70617373`)。最後一步涉及裝置以相同的 "pass" 字串回應，確認認證成功。這種缺乏複雜性以及對固定、未加密字串的依賴，暗示了安全架構中的根本設計缺陷，使得欺騙認證程序並啟動資料傳輸變得微不足道。

以下顯示了揭示可預測序列的關鍵 logcat 資料片段： 

// Logcat snippet showing the "pass" command being sent
I ota:RcspAuth: -sendAuthDataToDevice- device : ..., authData : 0270617373 
// 0x02 is the command type, 0x70617373 is "pass" in ASCII.

// Logcat snippet showing the successful authentication response
D ota:OTAManager: ---onReceiveDeviceData-- >>> device : ..., recv data : 0270617373
// The device responds with the same "pass" string, confirming success.

4. 側通道提取方法論

4.1. 利用錶盤上傳機制

此攻擊的核心技術創新在於將客製化手錶錶盤上傳視為一個通用資料傳輸機制。該程序很慢，一個小錶盤幾乎需要兩分鐘，這是資料正在循序傳輸和寫入的關鍵指標。研究人員假設，上傳期間的螢幕更新不僅僅是美觀，而是寫入快閃記憶體的資料的直接、即時視覺化 [1]。

4.2. 從螢幕更新中提取資料

此攻擊涉及在錶盤上傳程序期間捕獲螢幕更新。透過發送一個包含目標 firmware 的特製「錶盤」檔案，研究人員可以觀察螢幕的行為。螢幕被發現顯示與正在寫入的資料相對應的「閃爍」或像素變化模式。提取資料的程序可概念化如下：

  1. 準備: 創建一個客製化「錶盤」檔案，其中包含要提取的 firmware 資料。
  2. 注入: 透過被入侵的 BLE OTA 通道將客製化錶盤上傳到裝置。
  3. 觀察: 一台高速攝影機或專用光學感測器聚焦在裝置的螢幕上。
  4. 資料回復: 分析捕獲的影片 frames 以偵測像素變化和時序差異。螢幕模式的每次變化都對應於正在寫入的特定 chunk 資料。

關鍵步驟是分析錶盤的檔案格式。該格式被逆向工程，以了解資料是如何建構和顯示的。這使得研究人員能夠將螢幕上的視覺變化與 SoC 正在處理的基礎資料結構相關聯。錶盤檔案結構，經簡化以供分析，是資料區塊的序列，其中每個區塊的傳輸都會觸發一個可見的螢幕更新。資料結構可以由以下 pseudocode 結構表示： 

  1. // Pseudo-structure of the Watch Dial File Format
  2. struct WatchDialFile {
  3.     uint32_t magic_number;      // Identifier for the file type
  4.     uint32_t version;           // File format version
  5.     uint32_t total_size;        // Total size of the firmware/dial data
  6.     
  7.     // Data blocks that are written sequentially to flash memory
  8.     struct DataBlock {
  9.         uint32_t block_index;   // Index of the current block
  10.         uint32_t block_size;    // Size of the data in this block
  11.         uint8_t data[block_size]; // The actual data payload (e.g., firmware chunk)
  12.         uint32_t checksum;      // Integrity check for the block
  13.     } blocks[];
  14. };

透過精確地計時和分析與寫入每個 `DataBlock` 相關的視覺變化，研究人員可以有效地讀取正在傳輸的資料。此方法繞過了對快閃記憶體的實體存取或專有程式設計工具的需求，而是依賴於裝置正常操作的非預期副作用。

5. Firmware 重建與技術影響

5.1. 重建程序

一旦螢幕更新被捕獲並與資料區塊相關聯，firmware 重建就是將提取出的 chunk 拼接在一起的問題。此程序需要捕獲的影片 Frame 與錶盤檔案的已知結構之間進行仔細的同步。關鍵是能夠根據視覺「閃爍」模式準確識別每個資料區塊寫入操作的開始和結束。該技術的成功證實了螢幕的功耗或更新周期直接受到資料傳輸的調製，從而產生了一個可測量的側通道。

5.2. 對 IoT 安全性的技術影響

現代 Blinkenlights 攻擊對低價 IoT 和穿戴式裝置的安全性具有重大影響。此攻擊證明了：

  • 實體側通道持續存在: 即使在現代、高度整合的 SoC 中，實體側通道（視覺、電磁、聲學）仍然是一個可行的攻擊向量，特別是當裝置操作設計未考慮側通道抵抗性時。
  • 弱認證是通往目標的門戶: 容易被繞過的 JieLi OTA 認證充當了發起資料傳輸的必要門戶，然後再被側通道利用。強大、加密穩健的認證是第一道防線。
  • 低 MTU 對攻擊者來說是一個特性，而不是缺陷: 傳輸速率慢（小 BLE MTU 的後果）實際上透過使視覺變化更清晰、更容易逐 Frame 捕獲和分析，從而幫助了攻擊 [1]。

為了緩解此漏洞，製造商必須實作側通道對策。這包括：

graph TD     A[Device Security] --> B{Mitigation Strategies};     B --> C[Randomized Timing];     B --> D[Constant Power Consumption];     B --> E[Data Obfuscation on Display];     C --> C1[Jitter in Screen Update Cycles];     D --> D1[Hardware-level Power Smoothing];     E --> E1[Display Only Encrypted/Hashed Data];     B --> F[Strong Cryptographic OTA];     F --> F1[Signed and Encrypted Firmware];

最有效的軟體解決方案是確保視覺輸出與記憶體寫入操作隔離(Decouple)，或者顯示的資料被隨機化或加密，防止像素變化與基礎 firmware byte 之間存在直接關聯。硬體級解決方案，例如電源平滑，也將有助於掩蓋驅動視覺側通道的依賴資料的功率波動。

6. 結論

使用現代化的 Blinkenlights 側通道攻擊成功從基於 JieLi 的穿戴式裝置中提取 firmware，有力地證明了歷史漏洞如何被改編以危害當代技術。此攻擊利用了薄弱的專有 BLE 認證和裝置螢幕更新程序造成的非預期視覺側通道的組合。這項研究是一個重要的提醒，即 IoT 裝置中的安全性必須是全面的，不僅要解決網路協定，還要解決實體和側通道洩漏。對於低價硬體的製造商來說，投資於穩健、符合標準的安全措施並實作側通道抵抗性設計原則，對於防止類似的危害至關重要。

參考檔案

  1. A modern tale of blinkenlights
  2. BLINKENLIGHTS
  3. PerfektBlue—Bluetooth Vulnerabilities in Millions of Vehicles