在本文的Part1中，我介紹了啟動配置承載層(provisioning bearer layer)和藍牙mesh啟動配置流程的前三個階段：發(fā)送Beacon信號、邀請和交換公共密鑰。 啟動配置流程包括五個階段： 1、發(fā)送Beacon信號 2、邀請 3、交換公共密鑰 4、認證 5、啟動配置數(shù)據(jù)分發(fā) 1、發(fā)送Beacon信號：如果未經(jīng)啟動配置的設(shè)備支持PB-ADV承載層，則其作為未經(jīng)啟動配置設(shè)備Beacon進行廣播；如果使用的是PB-GATT承載層，則發(fā)送可連接的廣播數(shù)據(jù)包。這就向啟動配置設(shè)備（Provisioner）表明未經(jīng)啟動配置的設(shè)備已做好準備，可進入啟動配置流程。 2、邀請：啟動配置設(shè)備（Provisioner）邀請未經(jīng)啟動配置的設(shè)備發(fā)送自身啟動配置功能信息。 3、交換公共密鑰：在此階段，根據(jù)未經(jīng)啟動配置設(shè)備的功能，啟動配置設(shè)備(Provisioner)選擇合適的驗證方法，并通知未經(jīng)啟動配置設(shè)備將要采取的方式。之后，啟動配置設(shè)備和未經(jīng)啟動配置設(shè)備會創(chuàng)建一個橢圓曲線公私密鑰對并交換公鑰。然后，每臺設(shè)備使用自己的私鑰和對等設(shè)備的公鑰來計算對稱密鑰，即ECDHSecret。該密鑰用于驗證對端設(shè)備的身份。 本文將介紹啟動配置流程的后兩個階段：認證和啟動配置數(shù)據(jù)分發(fā)。 4、認證 在此步驟中，啟動配置設(shè)備使用所選的驗證方法，對未經(jīng)啟動配置設(shè)備進行驗證。有三種可用的驗證方法(OOB, Out-Of-Band)：輸出OOB（Output OOB）、輸入OOB（Input OOB）、以及靜態(tài)OOB（Static OOB）或無OOB（No OOB）。 輸出帶外（Output OOB） 若選擇的是輸出帶外（Output OOB）驗證方法，則未經(jīng)啟動配置設(shè)備會選擇一個隨機數(shù)，并通過與其功能兼容的方式輸出該數(shù)字。例如，如果未經(jīng)啟動配置設(shè)備是一個燈泡，則它能夠閃爍指定的次數(shù)。如果設(shè)備具有LCD屏幕，則可以將隨機數(shù)顯示為多位數(shù)值。啟動配置設(shè)備（Provisioner）的用戶需要輸入觀察到的數(shù)字，??驗證未經(jīng)啟動配置的設(shè)備。輸出帶外驗證方法的工作流程如圖1所示。 圖1 – 通過輸出OOB進行驗證 輸入隨機數(shù)后，啟動配置設(shè)備（Provisioner）生成并檢查確認值。無論采用哪種驗證方式，整個驗證步驟中的檢查確認值（check confirmation value）計算方式都是相同的，請繼續(xù)往下看。 輸入帶外（Input OOB） 輸入帶外（Input OOB）驗證方法與輸出帶外（Output OOB）方法類似，但設(shè)備的角色相反。啟動配置設(shè)備（Provisioner）生成并顯示隨機數(shù)，然后提示用戶采取適當?shù)牟僮鳎瑢㈦S機數(shù)輸入未經(jīng)啟動配置的設(shè)備。以照明開關(guān)為例，用戶可以在一定時間內(nèi)數(shù)次按下按鈕，以這種形式輸入隨機數(shù)。 與輸出帶外驗證（Output OOB）相比，輸入帶外（Input OOB）方法需要發(fā)送一個附加的啟動配置協(xié)議PDU。在完成認證操作之后，未經(jīng)啟動配置的設(shè)備向啟動配置設(shè)備發(fā)送一個啟動配置輸入完成PDU（Provisioning Input Complete PDU），通知其隨機數(shù)已輸入完成。隨后進入到執(zhí)行檢查確認值操作的步驟。 圖 2 – 通過輸入OOB進行驗證 靜態(tài)帶外(Static OOB) 或無帶外（No OOB） 在輸入帶外或輸出帶外都不可用的情況下，啟動配置設(shè)備（Provisioner）和未經(jīng)啟動配置的設(shè)備可采用靜態(tài)帶外（Static OOB）驗證或無帶外（No OOB）驗證：采用靜態(tài)OOB信息；或靜態(tài)OOB信息不可用，直接以數(shù)值0代替。在此情況下，啟動配置設(shè)備和未經(jīng)啟動配置的設(shè)備各自生成一個隨機數(shù)，然后進行檢查確認值操作。 檢查確認值(Check Confirmation Value) 無論采用何種驗證方法，都會進行確認值生成和檢查。根據(jù)藍牙m(xù)esh規(guī)格，啟動配置設(shè)備(Provisioner) 和未經(jīng)啟動配置設(shè)備應(yīng)分別計算確認值。這兩個值被稱為ConfirmationProvisioner和ConfirmationDevice。這兩個值的計算都使用一系列相同的函數(shù)，不同之處僅在于所使用的隨機數(shù)輸入。 藍牙m(xù)esh規(guī)格中有兩頁關(guān)于計算過程的內(nèi)容說明。確認值生成函數(shù)需要8個參數(shù)，參數(shù)值來自啟動配置（Provisioning）過程中的后續(xù)步驟。可參考規(guī)格的5.4.2.4認證和5.4.1啟動配置PDU部分，了解更多詳細信息。（詳見： ） 表1列出了用于確認值生成及其來源的參數(shù)。 表1 - 用于確認值計算的參數(shù) 讓我們來看看用于確認值生成的算法。圖3是一個流程圖，其中包括了幾輪AES-CMAC和SALT生成[1]。該流程圖對于ConfirmationProvisioner和ConfirmationDevice值均適用。 如果由啟動配置設(shè)備(Provisioner)執(zhí)行輸入，則從一個名為RandomProvisioner的值開始（下圖中以藍色表示），并生成ConfirmationProvisioner值。 如果由未經(jīng)啟動配置設(shè)備執(zhí)行輸入，則從一個名為RandomDevice的值開始（下圖中以綠色表示），并生成ConfirmationDevice值。 圖 3 – 確認值生成圖 確認值檢查(Confirmation Value Check) 當確認值生成之后，兩臺設(shè)備就會進行交換，并且都會檢查接收值的完整性。圖4表示確認值檢查的過程。 確認過程的開始就是啟動配置設(shè)備（Provisioner）將其隨機數(shù)RandomProvisioner發(fā)送到未經(jīng)啟動配置的設(shè)備。未經(jīng)啟動配置設(shè)備使用它來重新計算確認值，并與之前接收的確認值進行比較，進行驗證。 圖 4 –確認值檢查 如果由未經(jīng)啟動配置設(shè)備計算所得的確認值與接收到的ConfirmationProvisioner不匹配