一、 機制個別分析
1. 傳統藍牙底層 PIN 碼 (Legacy Bluetooth Link Layer PIN)
此機制屬於藍牙核心規範（通常指藍牙 2.0/2.1 之前的 Legacy Pairing，或在 BLE 中對應的 Passkey Entry 模式）中，由配對管理層（SM, Security Manager 或 LM, Link Manager）在**底層（鏈結層/傳輸層）**直接處理的硬體/系統級認證。
- 優點：
- 標準化協議支援
- 開發維護成本低
- 資源消耗低
- 缺點：
- 手法常見，易遭針對性攻擊
- 安全邊界侷限於藍牙鏈結
2. 內部自訂通訊密碼 (Application-Layer Custom Authentication)
此機制跳過或疊加於藍牙底層配對之上，由開發團隊在**應用層（Application Layer）**自訂的通訊協議中，設計專屬的身分驗證機制（例如：自訂的 Challenge-Response 挑戰應答、動態 Token、或特製的加密 Handshake 封包）。
- 優點：
- 私密性高與破譯難度大
- 架構靈活性與擴充性強
- 可實現端到端安全
- 缺點：
- 開發與維護成本高
- 容易引入自研邏輯漏洞
二、 核心差異對比表
| 對比維度 | 1. 傳統藍牙底層 PIN 碼 | 2. 內部自訂通訊密碼 |
|---|---|---|
| 運作層級 | 傳輸層 / 鏈結層 (Link/Controller Layer) | 應用層 (Application Layer) |
| 協議標準 | 遵循藍牙 SIG 核心規範 (標準化) | 企業內部私有協議 (自訂化) |
| 實現主體 | 藍牙晶片、系統藍牙堆疊 (OS Stack) | 應用軟體 (App) 與 設備韌體 (Firmware) |
| 破解難度 | 較低 (手法公開，易受離線暴破/竊聽) | 較高 (取決於自研演算法強度與逆向難度) |
| 開發難度 | 極低 (呼叫系統 API 即可) | 高 (需自行實作完整認證、加密與防禦邏輯) |
| 安全邊界 | 僅限藍牙點對點連線 (Point-to-Point) | 可實現端到端、多跳傳輸安全 (End-to-End) |
| 用戶體驗 | 跳出 OS 原生藍牙配對彈窗，體驗統一 | 需在 App 內部設計專屬的 UI 輸入或自動校驗 |
| 典型漏洞風險 | 協議層已知漏洞、中間人攻擊 (MITM) | 邏輯漏洞、明文傳輸、演算法強度不足 |
三、 總結與架構建議
-
單一機制的侷限性：
- 單純依賴 底層 PIN 碼 容易因為標準攻擊手法而門戶大開，特別是在工業控制、醫療、能源儲存（如 BMS/EMS）等高安全性場景。
- 單純依賴 應用層自訂密碼，若不小心處理，容易因開發疏漏（如未防範重放攻擊、弱加密）而導致安全性流於表面，且增加了設備端的運算與開發負擔。
-
縱深防禦（Defense in Depth）最佳實踐： 在實際的工業級或高安全性產品開發中，最推薦的作法是**「兩者結合」**：
- 底層： 啟用 BLE 的 Secure Connections (LE SC) 模式（取代傳統 Legacy PIN，改用 ECDH 密鑰協商與 Passkey/Just Works），確保無線傳輸通道本身不被輕易竊聽。
- 應用層： 在已加密的藍牙通道上，再跑一套內部自訂的認證協議（如基於 AES-128/CCM 的 Challenge-Response 認證）。如此一來，攻擊者即便突破了藍牙底層，也無法解讀或控制內部的核心業務數據。