BLE安全機制從入門到放棄

原文作者： Jayden Huang
原文鏈接： https://jaydenh215.github.io/2019/05/14/BLE安全機制從入門到放棄/

網上介紹BLE安全機制的文章大多隻關注業務概念，如：配對加密是什麼，綁定過程是什麼；而忽略了其中涉及到的信息安全知識，如：使用了加密和認證有什麼用，不用又會怎麼樣。讓新人讀了有種雲裏霧裏，知其然而不知其所以然的感覺。這裏結合涉及到的信息安全知識，換一個角度來認識BLE安全機制。

前言

標題中的“放棄”有點調侃的意思，是指讀者在讀完之後，可以不依賴別人，靠自己讀藍牙核心規範加深認識，這樣收穫也會更多，也是這篇博文的目標。
爲了易於理解，會對藍牙核心規範的算法進行裁剪，但是原理是不變的，標準算法應參考藍牙核心規範。
最後，這是博主的一得之見，歡迎各位指正。

密碼技術初探

在介紹密碼技術之前，我們先給參與信息交互的對象賦予名稱，方便舉例和記憶。
下圖是重要角色一覽表：

Alice和Bob分別是兩家銀行，Bob銀行通過網絡向Alice銀行發送了一條500元的匯款請求：從賬戶B-6789向賬戶A-1234匯款500元。

當然，會有人在網絡中嘗試攻擊銀行間通信，妄想用非法手段牟利，其中就有這樣一個分工明確的組織，由以下成員組成：

Eve
- 竊聽不同銀行之間的消息，從中獲取重要信息，如獲知“從賬戶B-6789向賬戶A-1234匯款500元”。
Mallory：
- 篡改不同銀行之間的消息，如修改匯款請求爲“從賬戶B-6789向賬戶A-1234匯款5000000元”。
- 僞裝成Bob銀行，以Bob銀行名義發送一條新的匯款請求給Alice銀行。

從上述例子可知消息面臨的威脅有：竊聽、篡改和僞裝，對應的安全特性爲：機密性、一致性、是否已認證。

“威脅”和“安全特性”的關係可以這樣描述：

如果消息沒有加密，消息則不具有機密性，無法防止他人竊聽；
如果發送者發送的消息和接收者的消息是不同的，說明消息被篡改過，不具有一致性；
如果沒有對消息進行認證，無法保證消息來自正確發送者而不是僞裝者。

存在威脅，就會有對應的解決方法，下面會針對每個威脅介紹對應的密碼技術。

對稱密碼

算法一般指複雜步驟，加密算法指的是用明文生成密文的步驟，解密的步驟稱爲解密算法，兩者統稱爲密碼算法，密碼算法需要用到密鑰。

所謂對稱密碼（symmetric cryptography）技術，即加密和解密時用的是同一個密鑰，加密和解密的算法一般是公開的，如AES128。
對稱密碼應用圖：

對稱密碼解決的問題

如上圖所示

Bob創建一條匯款請求消息；
用密鑰key對它加密；
將加密後的消息發給Alice；
Alice收到密文；
Eve竊聽到了加密後的消息，由於沒有密鑰key，無法解讀內容；
Alice用密鑰key對消息解密；
Alice獲得一條匯款請求消息。

對稱密碼技術可以解決竊聽的威脅。

對稱密碼無法解決的問題

對稱密碼技術可以解決竊聽的威脅，但是有一個前提，就是在這之前發送者和接收者要有相同的密鑰key，所以一定要先給接收者配送密鑰，有以下幾種方式：

Bob通過網絡先將key發送給Alice，但容易被Eve截取到；
Bob乘坐交通工具將密鑰key親手交給Alice，或者其他網絡以外的方式配送密鑰，這種方式成本高維護麻煩，稱爲帶外（Out-Of-Band）配送；
用diffie-hellman密鑰交換算法解決；
用橢圓曲線diffie-hellman密鑰交換算法解決。

diffie-hellman密鑰交換算法

先不管DH密鑰交換算法是什麼，我們現在關注問題是：在Eve竊聽網絡的情況下，如何解決Bob配送key給Alice的問題？

密碼界的前輩們從數學角度上找到了答案：利用這個數學難題，Bob和Alice可以在Eve竊聽的情況下，協商出一個密鑰，而Eve不知道密鑰是什麼。

最好解決配送問題的辦法就是不配送，通過協商獲得相同的密鑰，是不是很神奇，話不多說，我們看看是怎麼實現的。

離散對數問題

背景知識：mod符號表達的意思是求餘數，如表達式5 mod 7的計算思路爲：5除以7等於0，餘數爲5，所以5 mod 7 = 5。

現有離散對數問題如下，請問滿足公式的x是多少：

爲了求x，我們可以運用上面提到的背景知識來做計算，像下面這樣依次嘗試一遍，就可以得到x = 9。

例子的數字較小，所以很快就找到答案了，當數字很大時，計算x就會變得非常耗時，快速求出離散對數的算法到現在還沒被發現，所以可以得到這樣的一個簡單結論：

對於上圖公式，已知G、p、Y的時候，很難求出x。

接下來我們看看如何具體利用這個數學問題來協商出密鑰的。

diffie-hellman密鑰交換算法應用

在DH中，我們將Y稱爲公鑰（public key），將x稱爲私鑰（private key），則有以下結論：已知G、p、公鑰的時候，很難求出私鑰。

如上圖所示

Bob和Alice選擇一個公開的G和p，Eve當然也知道這個公開的G和p；
Bob和Alice分別隨機生成各自的私鑰sb和sa；
Bob和Alice根據G、p以及各自的私鑰，生成公鑰pb和pa；
Bob和Alice互發公鑰pb和pa，Eve竊聽到了pb和pa；
Bob和Alice計算出共享密鑰DHkey。

Eve能計算出DHkey嗎？

對比三個角色最後的“已知信息”可知，只要Eve知道任一私鑰（sb或sa），它就能容易算出DHkey，而這時候問題就變成了：Eve在已知G、p、公鑰情況下，是否能求出私鑰，這也就是我們上面提到的離散對數問題，這是很難做到的。

diffie-hellman密鑰交換算法解決的問題

因爲DH密鑰交換算法利用了“離散對數問題”的複雜度，所以就算Eve一直竊聽，Bob和Alice也能協商出一個共享密鑰，而Eve卻因爲複雜的數學問題而沒辦法算出共享密鑰，也就解決了對稱密碼中的配送問題。

橢圓曲線diffie-hellman密鑰交換算法

DH是利用了“離散對數問題”的複雜度來實現密鑰的安全交換的，如果將“離散對數問題”改爲“橢圓曲線上的離散對數問題”，這樣的算法就叫橢圓曲線diffie-hellman密鑰交換（ECDH）。

兩者密鑰交換總體流程相同，只是利用的數學問題不同而已，ECDH能夠用較短的密鑰長度實現較高的安全性。

橢圓曲線diffie-hellman密鑰交換算法應用

ECDH中的數學問題可以這樣簡單定義：

已知橢圓曲線上的點Y、基點G的時候，很難求出x。其中算術符號*表示的不是普通的乘法，而是一種在橢圓曲線上的特殊算法。

在ECDH中，我們稱Y爲公鑰（public key），x爲私鑰（private key）。

如上圖所示

Bob和Alice選擇一條密碼學家推薦的橢圓曲線，選擇曲線上的一個基點G；
Bob和Alice分別隨機生成各自的私鑰sb和sa；
Bob和Alice根據G以及各自的私鑰，生成公鑰pb和pa；
Bob和Alice互發公鑰pb和pa，Eve竊聽到了pb和pa；
Bob和Alice計算出共享密鑰DHkey。

橢圓曲線diffie-hellman密鑰交換算法無法解決的問題

DH和ECDH都能解決密鑰配送問題，結合對稱密碼技術，就能保證消息的機密性，防止被竊聽了，但是對於篡改和僞裝的攻擊，卻無能爲力。爲了解決剩下這兩個威脅，就要靠其他技術手段了。

如上圖所示，Mallory不需要知道密文是什麼意思，但是他可以修改密文，導致Alice解密出預期以外的內容。

如上圖所示，Mallory夾在Bob和Alice之間並僞裝他們。對於Mallory來說，DHkey是赤裸裸的，所以Bob和Alice互發的消息是沒有機密性的，這種攻擊也稱爲中間人攻擊（MITM）。

消息認證碼

消息認證碼（MAC）技術是檢查信息一致性並進行認證的技術，發送者通過MAC算法可以輸出一個MIC值，接收者通過校驗MIC值不僅可以判斷消息一致性，還能判斷消息是否來自正確的發送者。

MAC技術有以下幾種重要性質：

正向快速：給定明文、MAC算法和密鑰key，在有限時間和有限資源內能計算出MIC。
逆向困難：給定MIC、MAC算法和明文，在有限時間內很難（基本不可能）逆推出密鑰。
輸入敏感：原始輸入信息修改一點信息，產生的MIC看起來應該都有很大不同。
衝突避免：很難找到兩段內容不同的明文，使得它們的MIC一致（發生衝突）。即對於任意兩個不同的數據塊，其MIC相同的可能性極小；對於一個給定的數據塊，找到和它MIC相同的數據塊極爲困難。

MAC技術與對稱加密技術有一個顯著差異：加密解密是雙向的，可以互相推導，而認證只能單向；加密是爲了解密，MAC設計是無法解。

消息認證碼解決的問題

消息經過CMAC算法之後，爲何Mallory無法篡改消息和僞裝呢？
消息一致性檢查和認證示意圖：

Mallory如果想篡改明文，那就同時也要篡改MIC，否則無法通過Alice的校驗，但是應該將MIC改成多少呢？因爲Malloyr沒有共享密鑰，所以他也不知道MIC應該是什麼。如果想篡改MIC，那就同時也要篡改明文才能通過Alice的校驗，由於MAC算法的逆向困難性質，Mallory不知道明文應該是什麼。
Bob用CMAC算法認證一條消息併發給Alice，並要求Alice也用CMAC算法認證並返回一條消息給Bob。若Mallory僞裝成Alice，由於沒有認證密鑰，無法返回通過Bob校驗的消息。

消息認證碼無法解決的問題

沒錯，要使用MAC技術，首先要有相同的認證密鑰，又回到了之前的密鑰配送問題，具體這裏採用哪種方式解決配送密鑰問題，視實際情況而定。

消息認證碼攻擊方式

對於MAC算法來說，應保證不能根據MIC和明文推測出通信雙方所使用的密鑰。但實際上用窮舉法是可以推測出來的，如果使用密碼學安全的、高強度的僞隨機數生成器生成密鑰，就會使得破解時間需要很長以至在現實中幾乎不可能破解。而如果密鑰是人爲選定的，就會大大增加被推測出來的風險。

認證加密CCM

其實上文一直在有意無意的強調一個事情，那就是加密和認證是獨立的兩個概念。加密能防止竊聽，認證能防止篡改和僞裝。前輩們用一種密碼技術將兩者融合起來——CCM（Counter with CBC-MAC）。

通過查閱資料，以我的戰五渣水平只能理解到這一程度：

發送方先對明文使用MAC技術，然後對稱加密成密文；
接收方先用對稱加密技術解密密文，然後用MAC技術校驗明文；
發送方和接收方需要至少一個共享隨機數和一個共享密鑰，隨機數可以公開，密鑰不可以公開。

上圖只是個人猜測的CCM應用示意圖，有可能是不對的，因爲不是術業專攻方向，沒有深入研究，秉着求真精神，覺得應該提醒大家，避免誤導。

放上圖的目的是：加密和認證可以做在一個算法中，而且BLE就是這麼用的。

信息安全小結

威脅、安全特性、密碼技術關係圖：

總結：

爲了解決竊聽問題，採用對稱密碼技術；
爲了解決對稱密碼技術的加密密鑰配送問題，採用配送密鑰技術；
爲了解決篡改問題，採用消息認證碼技術；
爲了解決僞裝問題，採用消息認證碼技術；
爲了解決消息認證碼技術的認證密鑰配送問題，採用配送密鑰技術。

Tips：無論消息認證碼技術還是對稱密碼技術，都需要用到配送密鑰技術，而不同的配送密鑰技術本身，也會涉及到認證強度的問題。比如希望用ECDH來解決消息認證碼的認證密鑰配送問題，但是ECDH本身認證強度爲零，所以它也需要消息認證碼技術來證明ECDH過程中沒有出現篡改或者僞裝攻擊，即又要使用消息認證碼技術，導致進入了死循環。所以需要選擇合適的密鑰配送技術，常見的有：郵箱驗證碼、手機短信驗證碼、NFC、目測法等。

ble安全機制初探

在介紹ble安全機制之前，我們先給參與信息交互的對象賦予名稱，方便舉例和記憶。
ble重要角色一覽表：

背景知識：簡單來說ble設備可分爲兩種角色，一種是主機角色（master），另一種是從機角色（slave），有以下幾種差異：

1. 建立連接前

主機能進入掃描狀態、發起連接狀態，不能進入廣播狀態；
從機能進入廣播狀態，不能進入掃描狀態和發起連接狀態；
一定是由主機發起連接，從機只能被連接。
2. 建立連接後
一定是由主機發起配對，但是從機能夠請求主機發起配對；
ble各個狀態示意圖：
廣播狀態：設備正在往空中發送廣播包，誰都可以收得到；
掃描狀態：設備正在接收空中的廣播包，看看誰在發，發什麼；
發起連接狀態：設備指定與另外一個設備發起連接；
明文數傳階段：兩個已連接設備之間，用明文傳送數據包；
配對階段：兩個已連接設備之間，運用密碼技術生成各種安全強度的密鑰；
加密過程：兩個已連接設備之間，使用配對階段輸出的密鑰，或者綁定階段提供的密鑰，衍生出最終用於加密底層數據包的密鑰；
密文數傳階段：兩個已連接設備之間，用密文傳送數據包；
綁定階段：用“綁定”這個詞特定描述配對階段中的第三階段，該階段交換綁定信息，有了綁定信息下次需要密文數傳可以跳過配對階段。

除了展示兩種角色的異同，我覺得有必要通過上圖澄清幾個概念，加深大家的理解：

複雜密碼技術是運用在已連接之後的配對階段，所以不存在配對失敗，導致ble無法正常建立連接，至多是配對失敗，導致連接斷開。
連接後，不一定要啓動配對，如果明文數傳已經滿足應用要求，就沒必要啓動配對了。

ble4.0安全機制

從用戶角度提出問題：我現在對密碼技術有初步瞭解了，也知道ble安全機制的一些背景知識，評估下來連接之後的明文數傳風險太大，我要用到密文數傳，ble提供什麼樣的解決方案呢？

上圖是ble4.0安全機制簡單示意圖，是上一節“建立連接後”的細節展開，觀察方式從上到下爲角色的時間軸，從左到右分別是不同的角色，空白地方的文本爲傳遞的數據，虛線爲可選項，雙斜槓爲不展開討論的內容。

對於密文數傳，ble提供解決方案分四種情況：

首次連接無綁定

首次連接，配對輸出臨時密鑰（STK），加密過程用STK衍生出會話密鑰（sessionKey）和隨機數（IV）用於CCM認證加密，後面都是密文數傳。
首次連接有綁定

首次連接，配對輸出臨時密鑰（STK），加密過程用STK衍生出會話密鑰（sessionKey）和隨機數（IV）用於CCM認證加密，後面都是密文數傳，進入綁定階段，從機將長期密鑰（LTK）發送給主機保存。
第二次連接且首次連接無綁定

第二次連接，配對輸出臨時密鑰（STK），加密過程用STK衍生出會話密鑰（sessionKey）和隨機數（IV）用於CCM認證加密，後面都是密文數傳。
第二次連接且首次連接有綁定

第二次連接，跳過配對階段，加密過程使用之前綁定的LTK衍生出會話密鑰（sessionKey）和隨機數（IV）用於CCM認證加密，後面都是密文數傳。

由下往上讀圖，回答用戶提出的問題：

ble4.0選擇CCM給明文數據認證加密，想要使用CCM，就需要一個密鑰和一個隨機數用於CCM認證加密，所以ble有一個“加密過程”負責輸出一個密鑰（sessionKey）和一個隨機數（IV），而加密過程又需要一個密鑰來產生sessionKey，所以ble有一個“配對階段”來輸出一個臨時密鑰（STK）給加密過程，或者在綁定階段輸出一個長期密鑰（LTK）給加密過程下一次連接時候使用。

TK配對碼的生成和配送

ble4.0的TK配對碼生成和配送方式有多種，常用的兩種TK配對碼的生成和配送方式是：JustWorks和Passkey，他們有以下差異：

JustWorks模式時，生成的TK是000000，因爲這是公開的，沒有配送的意義，配送目的是爲了防止通信雙方以外的第三方獲得密鑰，由於現在認證碼是公開的，就沒配送的意義了，而且由於認證碼泄露，這種模式不能提供篡改和僞裝保護。
Passkey模式時，TK的生成方式和配送方式如下：通信其中一方如Alice隨機生成TK爲142536，通過顯示屏/短信/NFC等藍牙以外的輸出數據的方式，將配對碼告知給Bob’s User，Bob’s User通過鍵盤往Bob設備輸入142536，使得Bob和Alice擁有一個共享認證密鑰，而針對藍牙基帶攻擊的第三方Mallory不知道，從而提供篡改和僞裝保護。

下面來看一下圖，Passkey模式是怎麼做到認證保護的。
認證保護示意圖：

通過正常認證過程，可以發現Bob和Alice只在空中交互了兩次，所以Mallory的攻擊時機有兩個，第一個是Bob和Alice交換MIC的時刻，另一個是在Bob和Alice交換明文的時刻。

分兩種攻擊行爲

篡改MIC或者明文其中一項，屬於篡改攻擊。

如果篡改MIC，那就是在未知明文和TK的情況下，憑空捏造一個EMIC，而且這個EMIC還要能夠通過後續校驗，這個幾乎不可能。MIC是果，明文和TK是因，因果倒置不可能吧。

如果篡改明文，那就是給定MIC，基於MAC算法且未知認證密鑰TK的情況下，推導出另一份明文，根據MAC算法性質，這個是很難做到的。

同時篡改MIC和明文，屬於僞裝攻擊，也叫MITM攻擊。

因爲僞造認證碼EMIC和僞造明文Erand是Mallory提供的，計算過程可能是EMIC = MAC(EK, Erand)，而真實配對碼TK和僞造配對碼EKEY只有百萬分之一的機率是相同的，所以看作是不相同的，也即EK != TK，根據MAC的輸入敏感性質，EMIC != MAC(TK, Erand)，最終認證失敗。

ble4.0真的足夠安全嗎？

我們先列出ble4.0安全機制各個密鑰的安全依賴關係：

CCM -> sessionKey -> STK(LTK) -> TK

可以看到，最終的源頭是TK認證碼，只有保證TK足夠安全，密文才能保證安全，也就是說不能讓非法分子獲得TK，否則他們就能夠將密文解密了。

一般我們依靠MAC算法本身的性質，可以保證認證密鑰不被推算出來，但是但是這些性質的前提是：認證密鑰是使用密碼學安全的、高強度的僞隨機數生成器生成的，而且這些密鑰位數很多，以至於無法窮舉。

而實際TK的取值是000000~999999，最多隻有100萬種可能性，先抓取配對階段（phase2.2）中用到的明文、MIC，再通過窮舉的方式，就可以推算出TK了。

我們分析一下，如果在整個安全機制過程中，一直存在竊聽者Eve，那麼我們會面臨什麼威脅。

Tips：在這裏也順帶分析靜態配對碼和動態配對碼的區別，靜態配對碼是指每次輸入都是固定的TK值，動態配對碼是指每次輸入都是動態產生的TK值，其實核心規範裏面沒有提過靜態配對碼，但是很多人會希望有如下功能：在一個設備預設一個配對碼爲123456，然後配對階段時另一個設備輸入配對碼123456則通過認證，否則不通過，其實對於ble來說，由於TK可以被破解，所以靜態配對碼沒有起到安全保護作用。

如果是靜態配對碼，Eve推算出首次連接TK，從而推算出STK，從而推算出sessionKey，從而破解CCM，從而竊取綁定過程中的LTK。

Bob和Alice首次連接，因TK和STK被破解，所有階段被破解，可任意竊聽和篡改；

Bob和Alice第二次連接，因LTK被竊取，所有階段被破解，可任意竊聽和篡改；

僞裝Bob或者Alice與對方首次連接，因爲TK是靜態配對碼，通過認證，僞裝成功。

如果是動態配對碼，Eve推算出首次連接TK，從而推算出STK，從而推算出sessionKey，從而破解CCM，從而竊取綁定過程中的LTK。

Bob和Alice首次連接，因TK和STK被破解，所有階段被破解，可任意竊聽和篡改；

Bob和Alice第二次連接，因LTK被竊取，所有階段被破解，可任意竊聽和篡改；

僞裝Bob或者Alice與對方首次連接，因爲TK是動態配對碼，之前破解的TK用不上，無法通過認證，僞裝失敗。

總結出幾個觀點：

因爲“加密”都依賴於認證碼TK，而TK容易被窮舉破解，加密則形同虛設。
上面描述的威脅，首先是竊聽成功，才能篡改成功，問題是出在了竊聽上。正常情況下對於密文的處理，CCM需要先解密，後認證。如果Eve沒有竊聽成功，亂篡改Bob發出的CCM認證加密過的密文，那麼Alice解密出來的數據幾乎不可能通過後續認證的。正是因爲Eve竊聽成功，知道篡改哪部分內容，所以纔會造成威脅。解決竊聽問題，就能同時解決篡改問題了。
TK是不安全的，以至於如果使用靜態配對碼而不是動態配對碼，就無法解決僞裝問題，如果認證碼不像TK那樣範圍窄，靜態配對碼技術本身也沒什麼問題，但是最好還是定期更新。

上面總結的也是ble4.2安全機制裏面做的一部分改善，比如增加破解TK的難度，引入ECDH解決竊聽問題。

ble4.2安全機制

上一節，我們分析了ble4.0的安全“漏洞”，接下來簡單說一下ble4.2作出的應對措施。

無法改變的前提：
- 配對碼是6個字節。
可能的攻擊方式：
- Eve竊聽整個過程，從而破解TK，下一次可以僞裝Bob和Alice主動發起連接認證。
- Eve竊聽整個過程，從而破解TK，從而得到STK，然後竊取LTK。
- Mallory發起MITM攻擊，即使攻擊失敗，包含整個TK信息的MAC和MIC會被Mallory獲得。（雖然我不知道有什麼用）
提出對應解決的方案：
- 動態認證碼；
- ECDH保證機密性；
- 將TK拆成20bit，每次認證一個bit，攻擊失敗只會暴露1個bit，不會暴露整個TK。

BLE4.2與BLE4.0的安全機制區別主要體現在“配對階段”的phase2，在這個階段引入了ECDH，下面展開passkey模式的phase2（包括phase2.1~2.3）。

在“Authentication Stage1”過程，可以發現Bob和Alice只在空中交互了三次，所以Mallory的攻擊時機有三個：

交換公鑰的時刻
交換MIC的時刻
交換明文的時刻。

後兩個攻擊方式，在BLE4.0已經分析過了，至於第一個攻擊時機，因爲公鑰是也是MAC算法裏面的一個參數，所以它也不能被隨意篡改，如果改了後面的Ea和Eb校驗就不通過了，即給ECDH也提供了MITM保護。

Tips：這裏之所以可以提供MITM保護的實質是人的參與，通過觀察的方法獲得配對碼，繞開了藍牙空中傳輸來獲得配對碼，從而不會受到第三者攻擊。

對比BLE4.2和BLE4.0的主要區別：

BLE4.2沒有STK，在配對過程直接生成LTK，因爲LTK在配對階段就已經強制生成了，加密過程直接使用LTK，BLE4.2的綁定階段(phase3)不會發送LTK。
LTK是DHkey衍生出來的，DHkey是第三方無法竊聽也無法破解出來的，所以可以保證後面用CCM加密後數據的機密性。

BLE4.2完美解決了BLE4.0的安全漏洞。

總結

文章提到的只是BLE常見的一些概念，其他如：簽名（Signed）、授權（Authorization）之類都沒有提及，有興趣的讀者可以去核心規範探索一番。

參考資料裏面有許多優秀的書籍和文章，比如密碼技術相關知識我是從《圖解密碼技術》獲知的，關於具體的實戰抓包分析，吹爆“BLE配對過程詳解”這篇文章。

最後最後，感謝您閱讀到最後，這是對我最大的鼓勵，也希望這篇博文能讓您有一點點的收穫。

後記

一開始是想將MESH加進來的，但是考慮到還沒上過正式的項目去體驗過，怕寫出來理解的不夠透徹，所以還是算了，以後有機會再單獨開一篇吧，但是有興趣的朋友可以私底下一起交流。

參考資料

《圖解密碼技術》
BLE配對過程詳解
BLE核心規範
Hash算法總結
窮舉法破解BLE的TK值

【轉載】BLE安全機制從入門到放棄