深入了解 WLAN 中的WPS

  第6章  深入了解Wi-Fi Simple Configuration

本章主要内容：

介紹Wi-Fi Simple Configuration相關知識；

介紹Android中WSC的相關代碼。

6.1  概述

在Wi-Fi相關技術體系中，除了802.11定義的标準規範外，Wi-Fi Alliance（Wi-Fi聯盟）也推出了兩項比較重要的技術規範，他們分别是Wi-Fi Simple Configuration和Wi-Fi P2P。其中：

Wi-Fi Simple Configuration（以後簡寫為WSC）：該項技術用于簡化SOHO環境中無線網絡的配置和使用。舉一個簡單的例子，配置無線網絡環境時，網管需要首先為AP設定SSID、安全屬性（如身份認證方法、加密方法等）。然後他還得把SSID、密碼告訴給該無線網絡的使用者。可是這些安全設定資訊對普通大衆而言還是有些複雜。而有了WSC之後，使用者隻需輸入PIN碼（Personal Identification Number，一串數字），或者摁一下專門的按鈕（WSC中，該按鈕被稱為Push Button）甚至使用者隻要拿着支援NFC的手機到目标AP（它必須也支援NFC）旁刷一下，這些安全設定就能被自動配置好。有了這些資訊，手機就能連接配接上目标無線網絡了。顯然，相比讓使用者記住SSID、密碼等資訊，WSC要簡單多了。

Wi-Fi Peer-to-Peer（以後簡寫為P2P）：P2P的商品名（brand name）為Wi-Fi Direct。它支援多個Wi-Fi裝置在沒有AP的情況下互相連接配接。筆者個人認為P2P是Wi-Fi中最具應用前景的一項技術。例如，在家庭中，使用者可直接把手機上的内容通過P2P技術傳輸到電視機上和家人分享。

注意，P2P和第3章無線網絡結構中提到的Independent BSS完全不同。IBSS中，各個STA屬于完全對等的關系，而P2P則不然。關于P2P的細節，我們留待下章再來分析。

在wpa_supplicant（以後簡稱WPAS）中，WSC的功能點分散在第4章介紹的幾條分析路線中，為了避免贅述，本章的分析拟采用如下方法：

首先将介紹WSC所涉及的基礎知識。它是本章的核心。

然後再分析WSC相關的代碼。這部分代碼包括Settings、WifiService相關子產品（主要是WifiStateMachine）以及WPAS。

下面，先來介紹WSC的理論知識。

6.2  WSC基礎知識介紹

WSC規範早期的名字叫Wi-Fi Protected Setup（簡寫為WPS）。WFA推出WPA後不久，WPS規範便被推出。随着WPA2的出現，WFA又制訂了WPS的更新版，即WSC。WSC的規範（以2.0.2版為例）全文隻有150來頁。

WSC的目的很簡單，就是為了簡化無線網絡配置（這也是其英文名為Simple Configuration的原因）。本節将以WSC的技術規範為主，向讀者介紹相關的理論知識。

提示：WSC規範中，安全設定資訊可以借助Wi-Fi作為傳輸手段，也可以借助其他傳輸方式，如NFC傳輸等。如果這些資訊使用Wi-Fi作為傳輸手段，則稱為In-Band交換，否則稱為Out-of-Band交換。

6.2.1  WSC應用場景介紹[1]

WSC定義兩個應用場景（usage model），分别是Primary UM和Secondary UM，其中：

Primay UM包括設定一個新的安全的WLAN，并為該WLAN添加無線裝置。該場景和前文介紹的WSC應用場景一樣。日常生活中，Primary UM對應的情況更為普遍。

Secondary UM包括從WLAN中移除某個無線裝置、通過添加新的AP或路由器來擴充WLAN的覆寫範圍、密鑰資訊更換（Re-keying credentials）等。

Primary UM常見的兩種案例包括PIN和PBC。其中，PIN對應的使用案例可用圖6-1來表示：

圖6-1  WSC PIN案例示意

圖6-1所示為WSC定義的PIN碼配置方法，其工作流程為：

1）打開AP和STA。使用者首先從STA相關的設定選項中擷取一個PIN碼。

2）然後使用者将STA的PIN碼通過AP的設定頁面傳遞給AP。

3）AP和STA将基于這個PIN碼完成安全設定協商。然後STA将完成掃描、關聯、四次握手等工作以加入目标AP。

PIN碼是一個長度為8個數字的字元串，圖6-2所示為筆者用Galaxy Note2測試WSC PIN方法時擷取到的PIN資訊。

圖6-2  Galaxy Note2 WSC PIN設定

圖6-2左圖所示的頁面位于Settings的無線網絡設定選項中，有條件的讀者不妨一試。

STA中的PIN碼需要輸入到AP中，圖6-3所示為筆者家中無線路由器WSC PIN設定頁面，注意右下角的黑框（裡邊填寫了來自手機的PIN碼，筆者測試時從Galaxy Note2中擷取的PIN碼是33871042）。

圖6-3  AP設定頁面

提示：圖6-2和圖6-3中所示的PIN碼并不一緻。此處為筆者有意為之，表示系統每次生成的PIN碼不是固定的。

相比PIN而言，PB配置方法（Push Button Configuration，簡稱PBC）的使用更加簡單。圖6-4所示為PBC案例示意圖。

圖6-4  PBC案例示意圖

由圖6-4可知，PBC的工作流程如下：

1）使用者打開AP和列印機（支援Wi-Fi）。列印機和AP上都有一個小按鈕（注意，規範要求該按鈕必須标記上WPS以表示它對WSC的支援）。

2）使用者隻要在AP和列印機上摁一下該按鈕，該操作将觸發列印機和AP完成安全設定協商。如此，列印機擷取AP的安全設定資訊後将順利加入目标AP。

圖6-5所示為筆者家中無線路由器上的WSC按鈕。

圖6-5  PBC實物

對于Android智能手機，它可通過軟體中的按鈕來模拟真實的Push Button（參考圖6-2中左圖的“WPS推送按鈕”項）。

6.2.2  WSC核心元件及接口介紹[2]

WSC規範定義了三個核心元件，如圖6-6所示：

圖6-6  WSC核心元件

圖6-6所示為WSC定義的三個核心元件，其中：

Enrollee的角色類似于supplicant，它向Registrar發起注冊請求。

Registrar用于檢查Enrollee的合法性。另外，Registrar還能對AP進行配置。

AP也需要注冊到Registar中。是以，從Registrar角度來看，AP也是Enrollee。

AP和Registrar以及Enrollee三者互動，Enrollee從Registrar那擷取AP的安全配置資訊，然後Enrollee利用該資訊加入AP提供的無線網絡。

注意，這三個元件隻是邏輯上的概念。在具體實作時，AP和Registrar可以由同一個實體實作，也可分别由不同實體來實作。

1）日常生活中，支援WSC的無線路由器兼具AP和Registrar的功能。這種AP在規範中被稱為Standalone AP。Android智能手機扮演Enrollee的角色。

2）如果AP和Registrar分别由不同實體來實作，這種Registrar也被稱為External Registrar。

除了三大元件之外，規範還定義了元件之間的互動接口。例如圖6-6中的E、M、A代表三個核心元件之間互動的接口，這些接口定義了互動雙方需要實作的一些功能。

規範中關于E、M、A的介紹非常複雜，筆者不拟照搬規範的内容，而是試圖通過一種普适的case來介紹E、M、A的功能。這個case就是AP和Registrar元件實作于一個無線路由器中，即Standalone AP，而Enrollee由STA實作。STA和Standalone AP通過Wi-Fi傳輸資料，即它們将采用In-Band互動手段。

在上述情況下，STA中的Interface E包括的功能有：

STA首先要尋找周圍支援WSC功能的Standalone AP。此步驟将通過發送攜帶WSC IE的Probe Request幀來實作。另外，STA必須能生成動态PIN碼。該PIN碼将用于檢驗後續安全配置資訊的正确性。

STA關聯到Standalone AP後（注意，僅僅是關聯成功。由于缺乏安全配置資訊，STA無法和AP開展RSNA流程，即四次握手等工作），雙方需要借助Registration Protocol協定（以後簡稱RP協定）來協商安全配置資訊。是以，STA必須實作RP協定的Enrollee的功能。

Standalone AP中Interface E包括的功能有：

回複攜帶WSC IE的Probe Response幀以表明自己支援WSC功能。

實作RP協定定義的Registrar的功能。

另外，STA和AP可選擇實作某種Out-of-Band互動手段，規範中提到的兩種手段包括NFC和USB。

對于Interface A來說：

STA必須實作802.1X supplicant功能，并支援EAP-WSC算法。

Standalone AP需發送攜帶WSC IE的Beacon幀來表示自己支援WSC功能。同時，AP還必須支援802.1X authenticator功能，并實作EAP-WSC算法。

由于Standalone AP已經內建了三大元件中的AP和Registrar，是以Interface M的功能幾乎簡化為0。由于本書不讨論AP的實作，是以此處不拟介紹和它相關的内容。

規範閱讀提示：WSC規範關于E、M、A的介紹比較複雜，其中還涉及到UPnP的使用。筆者不拟讨論UPnP方面的内容。對它感興趣的讀者不妨參考筆者的一篇博文：http://blog.csdn.net/innost/article/details/7078539

由上文所述内容可知，WSC的核心知識集中在WSC IE以及RP協定中，下面将單獨用一節來介紹它們。

6.2.3  Registration Protocol介紹[3]

以前面提到的普适case為例，當STA和Standalone AP采用In-Band互動方法時，RP協定的完整互動流程如圖6-7所示：

圖6-7  完整RP協定互動示意圖

圖6-3中包括兩個部分，由“Enter passworkd of Enrollee”行隔開，其中：

上部分所對應的互動部分被稱之為Discovery Phase。在此階段中，STA借助Beacon幀或Probe Request幀搜尋周圍的AP。對開啟了WSC功能的STA來說，這些幀中都必須攜帶WSC IE。而沒有攜帶WSC IE的幀則表明發送者不支援或者未開啟WSC功能。Discovery Phase結束後，STA将确定一個目标AP。

此時使用者需要将STA顯示的PIN碼（如圖6-2所示）輸入到目标AP的設定頁面（如圖6-3所示）。

接着，STA将關聯到目标AP。和非WSC流程不一樣的是，STA和AP不會開展4次握手協定，而是先開展EAP-WSC流程。

EAP-WSC流程從EAPOL-Start開始，結束于EAP-Fail幀，一共涉及14次EAPOL/EAP幀交換。在這14次幀互動過程中，STA和AP雙方将協商安全配置資訊（例如采用何種身份驗證方法、何種加密方法，以及PSK等）。另外，這14次幀中，M1到M8屬于EAP-WSC算法的内容，它們用于STA和AP雙方确認身份以及傳輸安全配置資訊。

雖然EAP-WSC最終以EAP-Fail幀結束，但STA已經和AP借助M1到M8成功完成了安全資訊協商。是以，STA已經獲得了AP的安全配置情況。另外，由于STA收到的是EAP-Fail幀，是以它會斷開和AP的連接配接（AP會發送Deauthentication幀給STA）。

STA将利用協商好的安全配置資訊重新和AP進行關聯，後續流程和非WSC的無線網絡關聯一樣，即STA關聯到AP後，将開展RSNA工作（如4次握手協定、Group Handshake流程）。

關于圖6-7所涉及的流程，筆者特别強調幾點，請讀者認真體會：

如果不使用WSC，使用者需要為AP設定安全配置資訊，然後STA搜尋并關聯到目标AP。接着，STA和AP将利用4次握手協定和Group Handshake協定完成RSNA工作。RSNA工作屬于WPA和WPA2規範所指定的，STA和AP必須完成RSNA流程。

如果使用WSC，STA和AP共享的隻有PIN碼（或者使用者摁了雙方的按鈕），為了完成RSNA流程，STA需要從AP那擷取安全配置資訊。而這個安全配置資訊的傳遞則由圖6-7所示的EAPOL/EAP幀互動來完成。有了安全配置資訊後，STA後續流程和沒有使用WSC的情況一樣。

根據上面的描述，我們可知：

WSC的核心工作就是幫助STA和AP完成安全配置資訊協商。由于在這個流程中，使用者隻需輸入PIN碼或摁按鈕，是以使用者的工作量極小。WSC工作完成後，STA和AP的工作就和第4章介紹的一樣了（STA首先關聯到AP，然後完成4次握手協定和Group Handshake協定）。

下面我們将分别介紹WSC IE以及EAP-WSC相關知識。首先登場的是WSC IE。

1.  WSC IE和Attribute介紹[4]

WSC IE并不屬于802.11規範所定義的IE，而是屬于Vendor定義的IE。根據802.11規範，Vendor定義的IE有着如圖6-8所示的組成結構：

圖6-8  Vendor IE的結構

根據圖6-8所示的結構，WSC IE對應的設定如下：

Element ID取值為221。802.11規範中，該值意為“Vendor Specific”。

Length為OUI及Data的長度。

OUI取值為0x00-50-F2-04。其中00-50-F2代表Mircrosoft公司的OUI，04代表WPS。

WSC IE中，Data域的組織結構為一個或多個Attribute（屬性）。Attribute的格式為TLV，即Type（長度為2個位元組）、Length（長度為2個位元組，代表後面Value的長度），Value（最大長度為0xFFFF位元組）。

圖6-9所示為筆者截獲的WSC IE示意圖。

圖6-9  WSC IE執行個體

由上文可知，WSC IE的核心是其攜帶的Attribute。

WSC規範定義了多個Attribute，而了解這些Attribute的内容及作用是學習WSC的必經之路。下面将介紹WSC中一些重要的Attribute。

提示：Attribute不僅被WSC IE使用，還被後文介紹的EAP-WSC包使用

===================略略略略略略略==============================

5.  EAP-WSC處理流程分析

EAP-WSC流程涉及到EAPOL中的四個狀态機（SUPP_PAE、KEY_RX、SUPP_BE、Port Timers）以及EAP SM之間的關聯。當STA成功關聯到AP後，EAPOL及EAP狀态機情況如下（詳情請參考第4章4.5.3.4.3“eapol_sm_notify_portEnabled分析”一節）：

SUPP_PAE為DISCONNECTED狀态、KEY_RX為NO_KEY_RECEIVE狀态、SUPP_BE為IDLE狀态、EAP_SM為DISABLED狀态。

根據6.2.3“Registration Protocol介紹”一節中的圖6-7，EAP-WSC流程的開始于STA向AP發送的EAPOL-Start幀。是什麼原因導緻STA發送EAPOL-Start幀呢？來看下文。

（1）  發送EAPOL-Start

在STA關聯到AP流程的最後，eapol_sm_notify_portEnabled将設定portEnabled為1，根據代碼（eapol_supp_sm.c中SM_STEP(SUPP_PAE)）以及第4章圖4-28（Supplicant PAE SM狀态示意圖）可知，SUPP_PAE下一個要進入的狀态是CONNECTING，其EA（Entry Aciton）代碼為：

[-->eapol_supp_sm.c::SM_STATE(SUPP_PAE, CONNECTING)]

SM_STATE(SUPP_PAE, CONNECTING)

{

    //SUPP_PAE_state此時的值為SUPP_PAE_DISCONNECTED，故send_start為0

    //下面注意這個判斷很重要，我們待會還會回到此處

    int send_start = sm->SUPP_PAE_state == SUPP_PAE_CONNECTING;

    SM_ENTRY(SUPP_PAE, CONNECTING);

    if (send_start) {

        sm->startWhen = sm->startPeriod;

        sm->startCount++;

    } else {

 #ifdef CONFIG_WPS  //

        sm->startWhen = 1; //注意，如果WPAS支援WPS，則startWhen值為1

#else

        sm->startWhen = 3;

#endif

    }

    //啟動Port Timers SM，Port Timers SM将遞減startWhen，并調用eapol_sm_step以重新周遊狀态機

    eapol_enable_timer_tick(sm);

    sm->eapolEap = FALSE; ..

    //由于send_start為0，是以此時還不會發送EAPOL-Start包

    if (send_start)  eapol_sm_txStart(sm);

}

根據代碼中的注釋，當Port Timers SM運作時，它将遞減startWhen變量（結果是startWhen的值變為0），然後通過eapol_sm_step重新周遊狀态機。在該函數中，PAE的SM_STEP将被調用以檢查是否需要進行狀态切換，相關代碼如下所示：

[-->eapol_supp_sm.c::SM_STEP(SUPP_PAE)]

SM_STEP(SUPP_PAE)

{

    ......//略去不相關的内容

    else switch (sm->SUPP_PAE_state) { //SUPP_PAE_state還處于CONNECTING狀态

      ......

        case SUPP_PAE_CONNECTING:

        if (sm->startWhen == 0 && sm->startCount < sm->maxStart)

            SM_ENTER(SUPP_PAE, CONNECTING);//由于startWhen為0，PAE将重新進入CONNECTING狀态

         ......

        break;

    case SUPP_PAE_AUTHENTICATING:

    ......

   }

}

根據上面代碼可知，PAE将再次從CONNECTING狀态進入CONNECTING狀态。請讀者回顧SM_STATE(SUPP_PAE, CONNECTING)函數。這一次sendStart将取值1，是以eapol_sm_txStart會被調用。該函數的代碼如下所示：

[-->eapol_supp_sm.c::eapol_sm_txStart]

static void eapol_sm_txStart(struct eapol_sm *sm)

{

    //eapol_send函數指針指向wpa_supplicant_eapol_send，相關代碼在wpas_glue.c中。請讀者自行閱讀

    sm->ctx->eapol_send(sm->ctx->eapol_send_ctx,IEEE802_1X_TYPE_EAPOL_START, (u8 *) "", 0);

    sm->dot1xSuppEapolStartFramesTx++;

    sm->dot1xSuppEapolFramesTx++;

}

由上述代碼可知，eapol_send的執行個體wpa_supplicant_eapol_send将最終發送EAPOL-Start幀。

（2）  狀态機切換處理介紹

STA發出EAPOL-Start後，AP将發送EAP-Request/Identity包。STA處理EAP-Request/Identity後将回複EAP-Response/Identity包。上述流程将觸發EAPOL中的PAE、BE和EAP狀态機關聯。此關聯過程相當複雜。故本節将以EAP-Request/Identity為入口，分析WPAS中狀态機的切換處理。

注意：此處的狀态機關聯實際上反映的是WPAS中EAP包處理的通用流程。學習過程中，請讀者務必結合第4章4.4“EAP和EAPOL子產品介紹”一節介紹的理論知識。

先來看EAP-Request的處理。WPAS中，EAP包接收的函數是wpa_supplicant_rx_eapol（相關分析請參考第4章4.5.3.5“EAPOL-Key交換流程分析”一節對wpa_supplicant_rx_eapol的介紹）。在那裡，我們說過非PSK認證方法将由eapol_sm_rx_eapol處理。故直接來看eapol_sm_rx_eapol函數，代碼如下所示：

[-->eapol_supp_sm.c::eapol_sm_rx_eapol]

int eapol_sm_rx_eapol(struct eapol_sm *sm, const u8 *src, const u8 *buf, size_t len)

{

    const struct ieee802_1x_hdr *hdr;  const struct ieee802_1x_eapol_key *key;

    int data_len;  int res = 1; size_t plen;

    sm->dot1xSuppEapolFramesRx++;

    hdr = (const struct ieee802_1x_hdr *) buf;

    sm->dot1xSuppLastEapolFrameVersion = hdr->version;

    os_memcpy(sm->dot1xSuppLastEapolFrameSource, src, ETH_ALEN);

    plen = be_to_host16(hdr->length);

    ......

#ifdef CONFIG_WPS

    //workaround中文意思為“變通方案”。在WPAS中，它表示為了相容某些AP的錯誤行為（例如發送的EAP包

    //格式不符合要求），而采用繞過去的方法來處理

    if (sm->conf.workaround && plen < len - sizeof(*hdr) &&

        hdr->type == IEEE802_1X_TYPE_EAP_PACKET &&

        len - sizeof(*hdr) > sizeof(struct eap_hdr)) {

          ......

     }

#endif

    data_len = plen + sizeof(*hdr);

    switch (hdr->type) {

    case IEEE802_1X_TYPE_EAP_PACKET:  //本例中，我們收到的是EAP-Request包，滿足此case條件

        ......

        wpabuf_free(sm->eapReqData);

        sm->eapReqData = wpabuf_alloc_copy(hdr + 1, plen);

        if (sm->eapReqData) {

            sm->eapolEap = TRUE;  //設定條件變量

            eapol_sm_step(sm); //觸發狀态機運作

        }

        break;

        ......

    }

    return res;

}

WPAS每收到一個EAP包都會觸發上述代碼中流程。回顧一下eapol_sm_step中和狀态機運轉相關的代碼：

[-->eapol_supp_sm.c::eapol_sm_step]

void eapol_sm_step(struct eapol_sm *sm)

{

    int i;

    for (i = 0; i < 100; i++) {

        sm->changed = FALSE;

        SM_STEP_RUN(SUPP_PAE);//先執行SUPP_PAE狀态機

        SM_STEP_RUN(KEY_RX); //再運轉KEY_RX狀态機

        SM_STEP_RUN(SUPP_BE); //最後運轉SUPP_BE狀态機

        if (eap_peer_sm_step(sm->eap)) //執行EAP_SM狀态機

            sm->changed = TRUE;

        if (!sm->changed)

            break;

    }

  ......

}

其中，eap_peer_sm_step的代碼如下所示：

[-->eap.c::eap_peer_sm_step]

int eap_peer_sm_step(struct eap_sm *sm)

{

    int res = 0;

    do {  //無限循環，直到EAP SM穩定後才退出

        sm->changed = FALSE;

        SM_STEP_RUN(EAP);

        if (sm->changed)

            res = 1;

    } while (sm->changed);

    return res;

}

通過上述代碼可知，EAPOL和EAP的狀态機關聯過程如下：

1）EAPOL先按順序周遊PAE、KEY_RX、BE狀态機。

2）然後執行EAP狀态機。隻有EAP SM穩定後（即eap_peer_sm_step函數中的sm->changed為FALSE時）才退出eap_peer_sm_step。

3）如果上述四個狀态機有任何一個狀态機的狀态不穩定（即sm->changed為TRUE），則繼續周遊所有狀态機。

特别需要指出的是，狀态機A運作時可能會修改一些條件變量進而導緻狀态機B發生狀态切換。雖然第4章對每個狀态機的狀态切換圖都有詳細介紹，但讀者很難理清楚狀态機之間是如何互相影響的。在此，筆者整理了WPAS從發送EAPOL-Start包到接收EAP-Request/Identity以及回複EAP-Reponse/Identity這一過程中四個狀态機的切換過程，如圖6-34所示：

圖6-34  EAP-Request/Response Identity流程中的狀态機關聯示意

圖6-34中：

最上面一行顯示了PAE、KEY_RX、BE和EAP_SM的初始狀态。由于EAP-WSC不會收發EAPOL-Key幀，是以KEY_RX将不參與關聯過程。

圖中的方框上部所示為狀态機以及目前的狀态，格式為狀态機名_狀态名，如PAE_CONNECTING等。方框下部所示為該狀态機對應狀态的EA處理（由于篇幅原因，圖中EA僅列出了一些重要的處理邏輯）。

當狀态機A從一個狀态切換到另一個狀态時，切換過程用實箭頭表示（例如第二行中，PAE_CONNECTING切換到PAE_RESTART，切換條件為“eapolEap為TRUE”。當WPAS收到一個EAP幀時，該變量将在上文介紹的eapol_sm_rx_eapol函數中被設定為TRUE）。

當狀态機A在其EA進行中修改了某些條件變量（或者外界設定了某個條件變量）導緻狀态機B發生狀态切換時，其切換過程用虛箭頭表示。例如第二行中的PAE_RESTART狀态，其EA将設定eapRestart為TRUE，而該條件和portEnabled将共同促使EAP_SM進入INITILIAZE狀态。

第二行表示eapol_sm_step第一次循環過程中的狀态機切換以處理接收到的EAP-Request/Identity包。但這一輪還不會真正處理EAP包。

第三行表示eapol_sm_step的第二次循環。在這次循環過程中，EAP狀态機将處理EAP-Request/Identity包。在解析該包時，發現它包含了Identity資訊，是以EAP SM将進入IDENTITY狀态去處理它。處理完畢後，EAP SM将構造一個EAP-Response/Identity包，并設定eapResp變量為TRUE。

第三行中，eapResp變量将使得BE進入RESPONSE狀态，該狀态的EA将調用txsuppResp發送這個EAP-Response/Identity包。

當圖6-34執行完畢後，EAPOL和EAP狀态機将進入穩定狀态，這樣，eapol_sm_step得以傳回。根據EAP-WSC的流程，WPAS下一步将繼續接收并處理EAP包。在這以後的過程中（從M1到M8）：

PAE保持Authenticating狀态不變。

當EAPOL收到一個EAP包後，BE将從RECEIVE狀态切換至REQUEST狀态。EAP将根據EAP包的資訊從IDLE狀态轉移到其他狀态（首先是RECEIVED狀态，在該狀态中将解析EAP包的内容，根據内容以進入GET_METHOD或METHOD狀态以處理EAP包）。

EAP狀态機處理完EAP包，BE将進入RESPONSE狀态并發送EAP回複包。整個流程将反複執行，直到EAP-WSC流程終結。

是以，對EAP-WSC流程來說，EAPOL狀态機的執行過程比較固定。而對EAP SM來說，它将根據EAP包内容的不同而轉移到不同的狀态。下面我們将直接進入EAP對應的狀态以分析不同EAP包的處理過程。

注意，根據圖4-21關于EAP SM的描述，當portEnabled值為TRUE時，應該從DISABLED狀态切換至INITIALIZE狀态。不過，我們在4.5.3.3.3“wpa_supplicant_associate分析之三”一節中曾提到說由于force_disabled變量為TRUE，EAP_SM是無法轉入INITIALIZED狀态的。為什麼此處它卻可以呢？原來。由于本例使用的key_mgmt是WPA_KEY_MGMT_WPS，是以force_disabled變量将被設定為FALSE，這樣EAP SM就可以轉換至INITIALIZE狀态了。其間的細節内容請讀者參考wpa_supplicant_initiate_eapol及内部所調用的eapol_sm_notify_config函數。

=============================略略略===========

6.4  本章總結和參考資料說明

6.4.1  本章總結

本章對Wi-Fi Simple Configuration和其中的PIN方法進行了深入介紹。主要内容包括：

WSC的理論知識，它是本章的核心。WSC中最重要的是RP協定以及WSC IE及各種Attribute的作用。希望讀者能結合本章給的執行個體圖來認真學習它們。

掌握理論知識後，本章介紹了Android平台中WSC的代碼實作。它包括Settings、WifiService相關子產品以及wpa_supplicant相關子產品。僅就EAP-WSC算法本身而言，其難度并不大。

由于WSC使用了EAP-WSC算法，是以本章還介紹了EAPOL和EAP狀态機之間的關聯過程。這部分代碼的難度比較大，需要結合第4章4.4“EAP和EAPOL子產品介紹”一節中的狀态機切換圖來學習。

注意：WSC規範中還定義了另外一種比較常用的PBC方法。PBC和PIN類似，它也會用到一個PIN碼，隻不過這個PIN碼為“00000000”。讀者可閱讀參考資料[7]來了解PBC。

6.4.2  參考資料說明

本章參考資料其實隻有一個，即WSC規範2.0.2版。讀者可在百度文庫上搜尋到該文檔，其位址為http://wenku.baidu.com/view/aa2e8a20cfc789eb172dc83d.html

WSC應用場景介紹

[1]  WSC-2.0.2第1節“Introduction”

WSC核心元件及接口介紹

[2]  WSC-2.0.2第4節“Core Architecture”

Registration Protocol介紹

[3]  WSC-2.0.2第6.1節“In-band Setup Using a Standalone AP/Registrar”

[4]  WSC-2.0.2第8節“Message Encoding”

[5]  WSC-2.0.2第7節“Registration Protocol Definition”

[6]  http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange

維基百科關于D-H算法的描述，讀者可通過它了解D-H的相關知識。

Push Button Configuration

[7]  WSC-2.0.2第11節“Push Button Configuration”。

規範中，PBC的介紹隻有7頁。建議讀者學完本章後再來看它。

————————————————

版權聲明：本文為CSDN部落客「阿拉神農」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。

原文連結：https://blog.csdn.net/innost/article/details/21555225