安全是無線網絡技術中一個很重要的部分,它主要有三個保護點。
* ·數據的完整性(Integrity):用于檢查數據在傳輸過程中是否被修改。
- 數據的機密性(Confidentiality):用于確保數據不會被泄露。
- 身份驗證和訪問控制(Authentication and Access Control):用于檢查受訪者的身份。
* * * * *
**提示** 身份驗證和訪問控制的問題在無線網絡中尤為明顯。因為Wi-Fi以空氣作為傳播媒介,這意味著任何人通過類似AirPcap這樣的工具就能獲取其周圍的無線通信數據。而在以太網環境中,雖然網絡數據也是通過廣播方式發送,但用戶需要把網線插到網口中才能監聽數據。相信沒有哪個公司能隨隨便便允許一個外人把網線插到其公司內部的網口上。由于無線網絡天然就不存在有線網絡中這種類似的物理隔離,所以身份驗證和訪問控制是無線網絡中非常重要的一個問題。
* * * * *
無線網絡安全技術也是隨著技術發展而逐漸在演變,下面介紹其主要發展歷程。
* 802.11規則首先提出了WEP(Wired Equivalent Privacy,有線等效加密)。如其名所示,它是為了達到和有線網絡同樣的安全性而設計的一套保護措施。
* 經過大量研究,人們發現WEP很容易破解。在802.11規范提出新解決方案之前,WFA提出了一個中間解決方案,即WPA(Wi-Fi Protected Access)。這個方案后來成為802.11i草案的一部分。
* 802.11i專門用于解決無線網絡的安全問題。該規范提出的最終解決方案叫RSN(RobustSecurity Network,強健安全網絡),而WFA把RSN稱為WPA2。
本節先介紹WEP,然后介紹RSN中的數據加密,最后將介紹EAP、802.1X和RSNA密匙派生等內容。
* * * * *
**注意** 本書僅介紹數據加密及完整性校驗的大致工作流程,而算法本身的內容請讀者自行研究。另外,安全知識點中會經常見到Key(密鑰)和Password(密碼,也叫Passphrase)這兩個詞。它們本質意思都一樣,只不過Password代表可讀(human readable,如字符串、數字等)的Key,而Key一般指由算法生成的不可讀(如二進制、十六進制數據等)的內容。
* * * * *
**1.WEP介紹**
WEP是802.11規范的元老,在1999年規范剛誕生時就存在了。但隨著技術的發展,如今WEP已經無力應付復雜險惡網絡環境中的安全問題了。先來介紹WEP中的數據加密。
(1)WEP中的數據加密[16][25][26]
保護數據Confidentiality的一個主要方法就是對所傳輸的數據進行加密,而WEP采用了流密碼(Stream Cipher)對數據進行加密。這種加密方法的原理如圖3-30所示。
:-: 
圖3-30 流密碼工作原理
流密碼的工作原理如下。
* 源數據通過Key Stream(密鑰流)進行加密,加密方式就是異或(XOR),得到密文。
* 接收端得到密文后,再用相同的Key Stream進行異或操作,這樣就能得到目標數據。兩次異或操作,Key Stream又一樣,所以目標數據就是源數據。
* 整個過程中,只要Key Stream保證隨機性,那么不知道Key Stream的人理論上就無法破解密文。
根據上述內容可知,流密碼安全性完全依賴于Key Stream的隨機性,那么怎么生成它呢?一般的做法是:用戶輸入一個Secret Key(即密碼)到偽隨機數生成器(PseudoRandom NumberGenerator,PRNG)中,而PRNG會根據這個Secret Key生成密鑰流。
下面回到WEP,它的加密處理過程如圖3-31所示。
:-: 
圖3-31 WEP加密過程
WEP加密過程如下。
* 左上角PRNG的輸入(即隨機數種子),包括一個IV(Initialization Vector,初始向量,長24位)和WEP Key(Key長度有40、104和128位。位數越多,安全性越高)。IV的值由設備廠商負責生成。PRNG最終輸出Key Stream。
* XOR(即加密)操作的一方是Key Stream,另一方是數據和ICV(Integrity Check Value,完整性校驗值)。ICV長32位,其值由CRC-32方法對Data進行計算后得到。XOR操作后的數據即圖3-29所示的Encrypted部分。可知Data和ICV都經過了加密。
* 最終的MAC幀數據(frame payload)包括IV以及加密后的Data以及ICV。
再來看WEP的解密過程,如圖3-32所示。
:-: 
圖3-32 WEP解密過程
WEP解密過程如下。
* 幀數據中的IV和WEP Key共同作為PRNG的輸入以得到Key Stream。
* Key Stream和幀數據中的Cipher Text執行異或操作,得到明文(Plaintext)以及ICV。
* 接收端同時對自己解密得到的明文進行完整性校驗,得到ICV′。如果ICV和ICV′一樣,則數據正確。
* * * * *
**提醒** WEP弱點很多,其最主要的一個問題就是所有數據都使用同一個WEP Key進行加密。至于WEP存在的其他問題,讀者可閱讀參考資料[25]以獲得更詳細的信息。
* * * * *
(2)WEP中的身份驗證[27][28]
WEP其實并沒有考慮太多關于身份驗證方面的事情,根據IEEE 802.11-2012規范,本節真正的名字應該叫"Pre-RSNA Authentication",即RSNA出現之前的身份驗證。不過由于Pre-RSNA的認證方法和WEP有密切關系,所以一般就叫WEP身份驗證。
WEP身份驗證有以下兩種。
* 開放系統身份驗證(Open System Authentication):這種驗證其實等同于沒有驗證,因為無論誰來驗證都會被通過。那它有什么用呢?規范規定,如果想使用更先進的身份驗證(如RSNA),則STA在發起Authentication請求時,必須使用開放系統身份驗證。由于開放系統身份驗證總是返回成功,所以STA將接著通過Association請求進入圖3-29中的State 3然后開展RSNA驗證。
* 共享密鑰身份認證(Shared Key Authentication):Shared Key這個詞以后還會經常碰到,它表示共享的密碼。例如在小型辦公及家庭網絡(Small Office/Home Office,SOHO)環境中,AP的密碼一般很多人(即很多STA)都知道。
* * * * *
**提示** 初看上去,共享密鑰身份驗證的安全性比開放系統要強,但實際卻恰恰相反。因為使用了共享密鑰身份驗證就不能使用更為安全的RSNA機制。
* * * * *
由于筆者家庭網絡就使用了共享密鑰身份驗證,故這里也簡單向讀者介紹一下其工作原理,如圖3-33所示。
:-: 
圖3-33 共享密鑰身份驗證原理
由圖3-33可知Shared Key驗證的方法包括四次幀交互。
* STA(即圖中的Client)發送Authentication請求給AP。
* AP收到請求后,通過Authentication Response發送一個質詢明文(Challenge Text,長度為128字節)給STA。
* STA取出Challenge Text,通過圖3-31所示的WEP加密方法利用自己設置的密鑰對質詢文進行加密,然后再次發送Authentication Request給AP。
* AP收到第二次Authentication Request幀后,會利用AP的密鑰進行解密,同時還要驗證數據完整性。如果ICV正確,并且解密后的譯文等于之前發送的質詢文,則可知STA擁有正確的密碼,故STA身份驗證通過。
* AP返回驗證處理結果給STA。如果成功,STA后續將通過Association請求加入該無線網絡。
WEP的介紹就到此為止,下面來介紹RSNA中的數據加密。
**2.RSN數據加密及完整性校驗[29][30]**
RSN中數據加密及完整性校驗算法有兩種,分別是TKIP和CCMP。下面分別來介紹它們。
* * * * *
**規范閱讀提示**
規范中還有一種廣播/組播管理幀完整性校驗的方法,叫BIP(Broadcast/Multicast Integrity Protocol)。請讀者自行閱讀規范11.4.4節以了解相關內容。
* * * * *
介紹TKIP前,先介紹WPA。WPA是802.11i規范正式發布前用于替代WEP的一個中間產物。相比WEP,WPA做了如下改動。
* WPA采用了新的MIC(Message Integrity Check,消息完整性校驗)算法用于替代WEP中的CRC算法。新算法名為Michael。
* 采用TKIP(Temporal Key Integrity Protocol,臨時密鑰完整性協議)用于為每一個MAC幀生成不同的Key。這種為每幀都生成單獨密鑰的過程稱為密鑰混合(Key Mixing)。
(1)TKIP加密
下面簡單介紹TKIP的加密過程,如圖3-34所示。
:-: 
圖3-34 TKIP加密過程
* 左下角:用于數據完整性校驗的Michael算法的輸入包括兩部分,一部分是MIC Key(由廠商負責實現),另一部分是MAC幀頭中的DA、SA、Priority和MAC幀數據。Michael算法的輸出為Data和MIC。它們將作為后續加密算法的輸入(等同于圖3-31中加密前的Data+ICV)。
* 左上角:TKIP的密鑰計算分為兩部分。首先是第一階段的密鑰混合,其輸入有TA(Transmitter Address,32位)、TK(Temporal Key,128位)和TSC(TKIP Sequence Counter,序列號計數器。共48位,此處取其前32位)。此階段密鑰混合段的產物是TTAK(TKIP-mixed Transmit Address and Key,長80位)。注意,TK的來歷見后文關于密匙派生的知識。
* 中間部分:Phase 2 key mixing屬于密鑰計算的第二部分。本階段計算的輸入有TTAK和TSC(取其后16位),其產物可用作后續加密計算的WEP種子(包括一個128位的ARC4密鑰以及IV,可參考圖3-31)。
* 最后一步:利用WEP的加密方法進行數據加密,其過程即先利用WEP種子和PRNG生成密鑰流(由于每一個待加密的幀都會有不同的TSC,導致在進行PRNG前,每次輸入都有不同的WEP Key),然后使用XOR操作對Data和MIC進行異或。
由上述內容可知,TKIP將為每一幀數據都使用不同的密鑰進行加密,故其安全性比WEP要高。另外,由于生成密鑰和計算完整性校驗時會把MAC地址(如DA、SA、TA)等信息都考慮進去,所以它可以抵抗幾種不同類型的網絡攻擊[30]。不過,從加密本身來考慮,TKIP和WEP一樣都屬于流密碼加密。
(2)CCMP加密
CCMP出現在WPA2中,它比TKIP更安全,因為它采用了全新的加密方式CCMP(Counter Mode with CBC-MAC Protocol,計數器模塊及密碼塊鏈消息認證碼協議),這是一種基于AES(Advanced Encryption Standard,高級加密標準)的塊的安全協議。
CCMP加密過程如圖3-35所示。
:-: 
圖3-35 CCMP加密過程
* 左下角:PN(Packet Number,幀編號,48位)和KeyId(Key Identifier,密鑰標示符,每幀使用一個密鑰)共同構成一個8字節的CCMP頭(CCMP Header)。另外,每一幀的PN都會累加,所以圖中有一個"Increment PN"處理框(注意,重傳包的PN不累加)。
* 左上角:Plaintext MPDU(注意不是MSDU)意味著整個MAC幀(包括Head)都是輸入參數。MPDU被拆分成三個部分,其中A2(Address 2字段)、Priority和PN共同構成Nonce(即臨時的隨機數,用一次后就丟棄不再使用)。MPDU中的MAC頭信息將構成AAD(Additional Authentication Data,附加認證數據)。
* AAD、Nonce、MPDU中的MAC數據(Payload)以及TK(Temporary Key)共同作為加密算法的輸入,最終得到加密后的數據及消息校驗碼(Message Integrity Check,MIC)。
* CCMP Header、MAC Header、加密后的Data以及MIC共同構成了MPDU包。
關于RSN中的加密算法TKIP及CCMP就介紹到此。由于加解密工作上由硬件來完成,讀者僅需了解其中涉及的概念即可。
**3.EAP和802.1X介紹**
從本節開始,我們將重點關注安全主題中最后一個重要部分,即身份驗證。首先介紹EAP,然后介紹802.1X。
* * * * *
**提示** wpa_supplicant很大一部分內容就是在處理身份驗證,所以本節也將花費較多的筆墨來介紹相關內容。
* * * * *
(1)EAP[31][32][33]
目前身份驗證方面最基礎的安全協議就是EAP(Extensible Authentication Protocol),協議文檔定義在RFC3748中。EAP是一種協議,更是一種協議框架。基于這個框架,各種認證方法都可得到很好的支持。下面來認識EAP協議。首先介紹其中涉及的幾個基本概念。
* Authenticator(驗證者):簡單點說,Authenticator就是響應認證請求的實體(Entity)。對無線網絡來說,Authenticator往往是AP。
* Supplicant(驗證申請者①)發起驗證請求的實體。對于無線網絡來說,Supplicant就是智能手機。
* BAS(Backend Authentication Server,后端認證服務器):某些情況下(例如企業級應用)Authenticator并不真正處理身份驗證,它僅僅將驗證請求發給后臺認證服務器去處理。正是這種架構設計拓展了EAP的適用范圍。
* AAA(Authentication、Authorization and Accounting,認證、授權和計費):另外一種基于EAP的協議。實現它的實體屬于BAS的一種具體形式,AAA包括常用的RADIUS服務器等。在RFC3748中,AAA和BAS的概念可互相替代。
* EAP Server:表示真正處理身份驗證的實體。如果沒有BAS,則EAP Server功能就在Authenticator中,否則該功能由BAS實現。
EAP架構如圖3-36所示。
:-: 
圖3-36 EAP架構
由圖3-36所示,Supplicant通過EAPOL(EAP Over LAN,基于LAN的擴展EAP協議)發送身份驗證請求給Authenticator。圖中的身份驗證由后臺驗證服務器完成。如果驗證成功,Supplicant就可正常使用網絡了。
下面來認識EAP的協議棧,如圖3-37所示。
:-: 
圖3-37 EAP協議棧
由圖3-37可知,EAP沒有強制定義位于最底層(Lower Layer,LL)的傳輸層。目前支持EAP協議的網絡有PPP、有線網(EAPOL,也就是802.1X協議)、無線網絡(即802.11 WLAN)、TCP、UDP等。另外,LL本身的特性(例如以太網和無線網都支持數據重排及分片的特性)會影響其上一層EAP的具體實現。
* EAP Layer用于收發數據,同時處理數據重傳及重復(Duplicate)包。
* EAP Supplicant/Authenticator Layer根據收到EAP數據包中Type字段(見下文介紹)的不同,將其轉給不同的EAP Method處理。
* EAP Method屬于具體的身份驗證算法層。不同的身份驗證方法有不同的Method Type。
EAP協議的格式非常簡單,如圖3-38所示。
:-: 
圖3-38 EAP協議格式
* Code:EAP協議第一字節,目前僅有四種取值,分別為1(Request)、2(Response)、3(Success)、4(Failure)。
* Identifier:消息編號(ID),用于配對Request和Response。
* Length:2字節,用于表示EAP消息包長度(包括EAP頭和數據的長度)。
* Data:EAP中具體的數據(Payload)。當Code為Request或Response的時候,Data字段還可細分為Type以及Type Data。Type就是圖3-37中的EAP Method Type。
EAP Method Type取值如下。
* 1:代表Identity。用于Request消息中。其Type Data字段一般將攜帶申請者的一些信息。一般簡寫為EAP-Request/Identity或者Request/Identity。
* 2:代表Notification。Authenticator用它傳遞一些消息(例如密碼已過期、賬號被鎖等)給Supplicant。一般簡寫為Request/Notification。
* 3:代表Nak,僅用于Response幀,表示否定確認。例如Authenticator用了Supplicant不支持的驗證類型發起請求,Supplicant可利用Response/Nak消息以告知Authenticator其支持的驗證類型。
* 4:代表身份驗證方法中的MD5質詢法。Authenticator將發送一段隨機的明文給Supplicant。Supplicant收到該明文后,將其和密碼一起做MD5計算得到結果A,然后將結果A返回給Authenticator。Authenticator再根據正確密碼和MD5質詢文做MD5計算得到結果B。A和B一比較就知道Supplicant使用的密碼是否正確。
* 5:代表身份驗證方法為OTP(One Time Password,一次性密碼)。這是目前最安全的身份驗證機制。相信網購過的讀者都用過它,例如網銀付費時系統會通過短信發送一個密碼,這就是OTP。
* 6:代表身份驗證方法為GTC(Generic Token Card,通用令牌卡)。GTC和OTP類似,只不過GTC往往對應一個實際的設備,例如許多國內銀行都會給申請網銀的用戶一個動態口令牌。它就是GTC。
* 254:代表擴展驗證方法(Expanded Types)。
* 255:代表其他試驗性用途(Experimental Use)。
圖3-39所示為一個簡單的EAP交互。第三和第四步時,Authenticator要求使用MD5質詢法進行身份驗證,但Supplicant不支持,故其回復NAK消息,并通知Authenticator使用GTC方法進行身份驗證。第六步中,如果Supplicant回復了錯誤的GTC密碼時,Authenticator可能會重新發送Request消息以允許Supplicant重新嘗試身份驗證。一般認證失敗超過3次才會回復Failure消息。
:-: 
圖3-39 EAP交互
EAP的基本情況就介紹到此,讀者可通過RFC3748了解它的詳細情況。下面介紹802.1X。
* * * * *
**提示** 可閱讀參考資料[32]以了解EAP的其他幾種驗證方法。
* * * * *
(2)802.1X[34][35]
802.1X是802.1規范家族中的一員。簡單來說,802.1X詳細討論了EAP在Wired LAN上的實現,即EAPOL。先來認識802.1X中的兩個重要概念,如圖3-40所示。
由圖3-40可知,802.1X定義了:Controlled Port和UnControlled Port(受控和非受控端口)。
Port是802.1X的核心概念,其形象和我們常見的以太網中網口很類似。Port的定義和圖3-4中所述的定義一樣。802.1X定義了兩種Port,對于UnControlled Port來說,只允許少量類型的數據流通(例如用于認證的EAPOL幀)。Controlled Port在端口認證通過前(即Port處于Unauthorized狀態),不允許傳輸任何數據。
803.802.1X身份驗證通過后,Control Port轉入Port Authorized狀態。這時,雙方就可通過Controlled Port傳遞任何數據了。
* * * * *
**提示**
802.1X-2010文檔只有200來頁,但難度不小,引用的參考資料也非常多。建議讀者看完本節后再結合實際需求去閱讀它。另外802.1X中還定義了一個很重要對象叫PAE(PortAccess Entity)。Entity的概念在3.3.1節曾介紹過,它代表封裝了一組功能的模塊。在802.1X中,PAE負責和PACP(Port Access Control Protocol)協議相關的算法及處理工作。PAE分為
Supplicant PAE和Authenticator PAE兩種。
* * * * *
下面來看EAPOL的數據格式,如圖3-41所示。
:-: 
圖3-40 802.1X中的Port
:-: 
圖3-41 EAPOL格式
由圖3-41可知EAPOL消息格式如下。
* Protocol Version:占1字節,代表當前使用的802.1X版本號。值為0x03代表802.1X-2010,值為0x02則表示802.1X-2004,值為0x01表示802.1X-2001。
* Packet Type:EAPOL對EAP進行了擴展,該字段取值詳細內容見表3-14。
* Packet Body Length:指明Packet Body的長度。
EAPOL消息中最重要的是Packet Type,目前規范定義的幾種常見取值如表3-14所示。
:-: 
表3-14 EAPOL消息中Packet Type常見取值
EAPOL-Key用于交換身份驗證過程中使用的密鑰信息,其對應的Packet Body格式如圖3-42所示。Descriptor Type表示后面Descriptor Body的類型。802.1X中,Descriptor Type值為2時,Descriptor Body的內容由802.11定義。此處給讀者展示一個實際的例子,如圖3-43所示。
:-: 
圖3-42 EAPOL-Key幀對應的Body格式
:-: 
圖3-43 EAPOL-Key幀實例
圖3-43中:
* 0x888e代表EAPOL在802.11幀中的類型。
* Key Descriptor Type值為2,表示EAPOL RSN Key。
* Descriptor Body的內容就是大括號中所包含的信息。其細節請讀者閱讀802.11第11.6.2節。
最后,看看用MD5質詢算法作為身份驗證的EAPOL認證流程,如圖3-44所示。
:-: 
圖3-44 EAPOL認證流程
* Supplicant主動向Authenticator發送EAPOL-Start消息來觸發認證。注意,EAPOL-Start消息不是必需的。
* Authenticator收到EAPOL-Start消息后,將發出EAP-Request/Identity消息以要求Supplicant輸入用戶名。由于EAPOL-Start消息不是必需的,所以一個未經驗證的Supplicant發送了其他數據包也將觸發Authenticator發送EAP-Request/Identity消息。
* Supplicant將用戶名信息通過EAP-Response/Identity消息發送給Authenticator。Authenticator再將它經過封包處理后(轉換成RADIUS Access-Request消息)送給AS(Authenticator Server)進行處理。
* AS收到Authenticator轉發的用戶名信息后,將其與數據庫中的用戶名表對比,找到該用戶名對應的密碼信息。然后隨機生成的一個MD5質詢文并通過RADIUS Access-Challenge消息發送給Authenticator,最后再由Authenticator轉發給Supplicant。
* Supplicant收到EAP-Request/MD5 Challenge消息后,將結合自己的密碼對MD5質詢文進行處理,處理結果最終通過EAP-Response/MD5 Challenge消息經由Authenticator返回給AS。
* AS將收到RADIUS Access-Request消息和本地經過加密運算后的密碼信息進行對比,如果相同,則認為該Supplicant為合法用戶,然后反饋認證成功消息(RADIUS Access-Accept和EAP-Success)。
* Authenticator收到認證通過消息后將端口改為授權狀態,允許Supplicant訪問網絡。注意,有些Supplicant還會定期向Supplicant發送握手消息以檢測Supplicant的在線情況。如果Supplicant狀態異常,Authenticator將禁止其上線。
* Supplicant也可以發送EAPOL-Logoff消息給Authenticator以主動要求下線。
至此,我們對EAP和802.1X進行了簡單介紹,EAP和802.1X的目前是為了進行身份驗證,二者有自己的數據格式。如果沒有特殊需要,掌握上述知識就可以了。
* * * * *
**提示** 后續分析wpa_supplicant時還將對802.1X進行更為詳盡的介紹。
* * * * *
下面介紹安全部分最后一個內容,RSNA。
**4.RSNA介紹[36][37]**
RSNA(Robust Secure Network Association,強健安全網絡聯合)是802.11定義的一組保護無線網絡安全的過程,是一套安全組合拳。這套組合拳包含的過程如圖3-45所示。RSNA包括如下過程。
:-: 
圖3-45 RSNA過程
1)RSNA網絡發現階段。當STA掃描無線網絡時,需檢查Beacon幀或Probe Response幀中是否有RSNE信息元素。如果有,STA根據RSNE處理原則選擇合適的AP并完成802.11Authentication(設置認證類型為Open System Authentication)和Association。
2)上一步建立的安全保護機制非常弱,所以RSNA的第二步工作是開展802.1X認證。目的是利用802.1X認證機制實現有效安全的認證用戶身份,同時還需要分配該次會話所需要的一系列密鑰用于后續通信的保護。
3)RSNA通過4-Way Handshake和Group Key Handshake協議完成RSNA中的密鑰管理工作。密鑰管理工作主要任務是確認上一階段分配的密鑰是否存在,以及確認所選用的加密套件,并生成單播數據密鑰和組播密鑰用于保護數據傳輸。當上面三個步驟都完成后,RSNA網絡就建立成功。由上所述,我們發現RSNA包括兩個主要部分。
* 在數據加密和完整性校驗方面,RSNA使用了前面章節提到的TKIP和CCMP。TKIP和CCMP中使用的TK(Temporary Key)則來自于RSNA定義的密鑰派生方法。
* 密鑰派生和緩存。RSNA基于802.1X提出了4-Way Handshake(四次握手協議,用于派生對單播數據加密的密鑰)和Group Key Handshake(組密鑰握手協議,用于派生對組播數據加密的密鑰)兩個新協議用于密鑰派生。另外,為了加快認證的速度,RSNA還支持密鑰緩存。密鑰派生和緩存的詳情見下文。
RSNA中,我們僅介紹涉及的密鑰派生和緩存。
為什么要進行密鑰派生呢?它涉及密碼安全方面的問題,不過其目的并不難理解。在WEP中,所有STA都使用同一個WEP Key進行數據加密,其安全性較差。而RSNA中要求不同的STA和AP關聯后使用不同的Key進行數據加密,這也就是RSNA中Pairwise(成對)概念的來歷。
:-: 
圖3-46 Pairwise的概念
圖3-46展示了Pairwise Key的含義,不過該圖是否表明AP需要為不同的STA設置不同的密碼呢?這顯然和現實情況是違背的。因為現實生活中,我們關聯多個STA到同一個AP時使用的都是相同的密碼。
如何解決不同STA使用不同密碼的問題呢?原來,我們在STA中設置的密碼叫PMK(Pairwise Master Key,成對主密鑰),其來源有兩種。
* 在SOHO網絡環境中,PMK來源于預共享密鑰(Pre-Shared Key,PSK)。Shared Key概念在3.3.7節介紹WEP身份驗證時提到過,即在家用無線路由器里邊設置的密碼,無須專門的驗證服務器,對應的設置項為"WPA/WPA2-PSK"。由于適用家庭環境,所以有些無線路由器設置界面中也叫"WPA/WPA2-個人"(WFA認證名為"WPA/WPA2-Personal")。
* 在企業級環境中,PMK和Authenticator Server(如RADIUS服務器)有關,需要通過EAPOL消息和后臺AS經過多次交互來獲取。這種情況多見于企業級應用。讀者可在無線路由器設置界面中見到"WPA/WPA2-企業"(有時叫“WPA或WPA2”,WFA認證名為"WPA/WPA2-Enterprise")的安全類型選項,并且會要求設置RADIUS服務器地址。
Personal模式和Enterprise模式中PMK的來源如圖3-47所示。
:-: 
圖3-47 PMK來源
圖3-47中:
* Personal模式不需要RADIUS服務器參與。AP和STA雙方的Key屬于PSK,即事先就配置好了。
* Enterprise模式下,STA、AP和RAIDUS的PMK通過多次EAPOL消息來獲取。獲取的方法和具體的EAP Method有關。顯然,相比Personal模式,這種方式更加安全,但其耗費的時間也較長。
* STA和AP得到PMK后,將進行密匙派生以得到PTK。最后,PTK被設置到硬件中,用于數據的加解密。
* 由于AP和STA都需要使用PTK,所以二者需要利用EAPOL Key幀進行信息交換。這就是4-Way Handshake的作用。其詳情見下文。
有了PMK后,AP和STA將進行密鑰派生,正是在派生的過程中,AP和不同STA將生成獨特的密鑰。這些密鑰用于實際的數據加解密。由于STA每次關聯都需要重新派生這些Key,所以它們稱為PTK(Pairwise Transient Key,成對臨時Key),PTK如圖3-47所示。
* * * * *
**提示** WFA要求目前生產的無線設備必須通過WPA2認證。
* * * * *
RSNA中,針對組播數據和單播數據有不同的派生方法,即單播數據和組播數據使用不同的Key進行加密。本書僅介紹單播數據密鑰的派生方法,如圖3-48所示。輸入PMK長256位(如果用戶設置的密鑰過短,規范要求STA或AP將其擴展到256位),通過PRF(Pseudo RandomFunction,偽隨機數函數)并結合S/A(Supplicant/Authenticator)生成的Nonce(這兩個Nonce將通過4-Way Handshake協議進行交換)以及S/A MAC地址進行擴展,從而派生出TKIP和CCMP用的PTK。
:-: 
圖3-48 單播數據密鑰派生方法
圖3-48中分別描述了TKIP PTK和CCMP PTK的組成。
* EAPOL KCK(Key Confirmation Key)用于計算密鑰生成消息的完整性校驗值。
* EAPOL KEK(Key Encryption Key)用來加密密鑰生成消息。
這兩個EAPOL Key將用于后續EAPOL Key幀中某些信息的加密。TKIP TK和CCMP TK就是TKIP和CCMP算法中用到的密鑰。
明白密鑰派生的作用了嗎?簡單來說,WEP中,網絡中傳輸的是用同一個Key加密后的數據,其破解的可能性較大。而TKIP和CCMP則把PMK保存在AP和STA中,實際數據加密解密時只是使用PMK派生出來的Key,即PTK。
* * * * *
**提示** 關于TKIP PTK和CCMP PTK等其他信息,請讀者閱讀參考資料[30]。
* * * * *
由于密鑰派生時需要STA和AP雙方的Nonce等其他一些信息,所以二者還需通過4-WayHandshake以交換雙方的信息,其過程如圖3-49所示[24]。
:-: 
圖3-49 4-Way Handshake流程
* * * * *
**注意** 4-Way Handshake除了用于交換STA和AP信息外,還可用于AP和STA之間相互判斷對方是否有正確的PMK。
* * * * *
圖3-49所示的4-Way Handshake工作過程如下。
1. Authenticator生成一個Nonce(ANonce),然后利用EAPOL-Key消息將其發給Supplicant。
2. Supplicant根據ANonce、自己生成的一個Nonce(SNonce)、自己所設置的PMK和Authenticator的MAC地址等信息進行密鑰派生。Supplicant隨后將SNonce以及一些信息通過第二個EAPOL-Key發送給Authenticator。Message 2還包含一個MIC值,該值會被圖3-48中的KCK加密。接收端Authenticator取出Message 2中的SNonce后,也將進行和Supplicant中類似的計算來驗證Supplicant返回的消息是否正確。如果不正確,這將表明Supplicant的PMK錯誤,于是整個握手工作就此停止。
3. 如果Supplicant密鑰正確,則Authenticator也進行密鑰派生。此后,Authenticator將發送第三個EAPOL-Key給Supplicant,該消息攜帶組臨時密碼(Group Transient Key,GTK,用于后續更新組密鑰,該密鑰用圖3-48中的KEK加密)、MIC(用KCK加密)。Supplicant收到Message 3后也將做一些計算,以判斷AP的PMK是否正確。注意,圖中IGTK(Integrity GTK)用于加解密組播地址收發的管理幀,本書不討論。
4. Supplicant最后發送一次EAPOL-Key給Authenticator用于確認。
5. 此后,雙方將安裝(Install)Key。Install的意思是指使用它們來對數據進行加密。
Supplicant和Authenticator就此完成密鑰派生和組對,雙方可以正常進行通信了。
* * * * *
**提示** 由于篇幅原因,請讀者閱讀參考資料[38]以了解GTK的產生和作用。另外,4.5.5節“EAPOL-Key交換流程分析”將結合wpa_supplicant的代碼詳細介紹4-Way Handshake相關的內容。
* * * * *
另外,802.11還支持“混合加密”,即單播和組播使用不同的加密方法,例如單播數據使用CCMP而組播數據使用TKIP進行加密。注意,有些加密方法不能混合使用,例如組播數據使用CCMP加密,單播數據就不能使用TKIP。詳情見參考資料[39]。
* * * * *
**提示**
混合加密的主要目的是為了解決新舊設備的兼容性問題。它對應的應用場景如下。
1. AP支持TKIP和CCMP,屬于新一代的設備。
2. 一些老的STA只支持TKIP,而一些新的STA支持TKIP和CCMP。
對于單播數據來說,AP和STA的密鑰是成對的。所以對于老STA,AP和它們協商使用TKIP。對于新STA,AP和它們協商使用CCMP。而對于組播數據來說,所有STA、AP都使用同一個密鑰,加解密方法也只能是一樣的。在這種情況下,大家只能使用TKIP而不能使用CCMP對組播數據進行加解密了。
* * * * *
下面我們來介紹密鑰緩存。
根據前述內容可知,PMK是密鑰派生的源,如果認證前,STA沒有PMK,它將首先利用圖3-47右圖所示的802.1X協商步驟以獲取PMK(當然,對于SOHO環境中所使用的PSK而言,則不存在這種情況)。由于802.1X協商步驟涉及多次幀交換,故其所花費時間往往較長。在這種情況下,STA緩存這個得來不易的PMK信息就可消除以后再次進行802.1X協商步驟的必要,從而大大提升整個認證的速度。
根據802.11規范,PMK緩存信息的名稱叫PMKSA(PMK Security Association),它包括AP的MAC地址、PMK的生命周期(lifetime),以及PMKID(PMK IDentifier,用于標示這個PMKSA,其值由PMK、AP的MAC地址、STA的MAC地址等信息用Hash計算得來)。
當STA和AP進行關聯(或重關聯)時:
* STA首先根據AP的MAC地址判斷自己是否有緩存了的PMKSA,如果有則把PMKID放在RSNE中然后通過Association/Reassociation Request發送給AP。
* AP根據這個PMKID再判斷自己是否也保持了對應的PMKSA。如果是,雙方立即進入4-Way Handshake過程,從而避免802.1X協商步驟。
**5.無線網絡安全相關知識總結**
本節對無線網絡安全技術進行一個總體介紹,其中所涉及的概念、縮略詞較多,這里給讀者簡單總結一下其中的邏輯關系。
無線網絡安全要解決的是數據的Confidentiality和Integrity以及使用者的Authentication這三個問題。
* 規范最早定義的WEP本來目的是解決數據完整和機密性的問題,后來WEP中附帶完成了Authentication檢查。不過整體保護機制非常弱。
* 在802.11i正式出臺前,WFA提供了安全機制比WEP強的TKIP。注意,TKIP本身只能解決數據完整和機密性問題。而802.11i出臺后,又增加了一個更強健的加密算法CCMP(有時候也叫AES)。AES和TKIP都用于解決數據完整和機密性問題。
* 為了解決Authentication問題,規范借鑒802.1X,從而引出RSNA,它包括密鑰派生、緩存等內容。
* * * * *
**提示**
無線網絡安全的內容非常多,讀者不妨閱讀參考資料[37][38]以加深理解。區分
WPA/WPA2企業和個人用法的簡單公式如下。
:-: WPA-企業=802.1X+EAP+TKIP
WPA2-企業=802.1X+EAP+CCMP
WPA-個人=PSK+TKIP
WPA2-個人=PSK+CCMP
* * * * *
① RFC3748中也叫Peer,不過本文統一用Supplicant表示。
- 前言
- 第1章 準備工作
- 1.1 Android系統架構
- 1.2 工具使用
- 1.2.1 Source Insight的使用
- 1.2.2 Eclipse的使用
- 1.2.3 BusyBox的使用
- 1.3 本書資源下載說明
- 第2章 深入理解Netd
- 2.1 概述
- 2.2 Netd工作流程
- 2.2.1 main函數分析
- 2.2.2 NetlinkManager分析
- 2.2.3 CommandListener分析
- 2.2.4 DnsProxyListener分析
- 2.2.5 MDnsSdListener分析
- 2.3 CommandListener中的命令
- 2.3.1 iptables、tc和ip命令
- 2.3.2 CommandListener構造函數和測試工具ndc
- 2.3.3 InterfaceCmd命令
- 2.3.4 IpFwd和FirewallCmd命令
- 2.3.5 ListTtysCmd和PppdCmd命令
- 2.3.6 BandwidthControlCmd和IdletimerControlCmd命令
- 2.3.7 NatCmd命令
- 2.3.8 TetherCmd和SoftapCmd命令
- 2.3.9 ResolverCmd命令
- 2.4 NetworkManagementService介紹
- 2.4.1 create函數詳解
- 2.4.2 systemReady函數詳解
- 2.5 本章總結和參考資料說明
- 2.5.1 本章總結
- 2.5.2 參考資料說明
- 第3章 Wi-Fi基礎知識
- 3.1 概述
- 3.2 無線電頻譜和802.11協議的發展歷程
- 3.2.1 無線電頻譜知識
- 3.2.2 IEEE 802.11發展歷程
- 3.3 802.11無線網絡技術
- 3.3.1 OSI基本參考模型及相關基本概念
- 3.3.2 802.11知識點導讀
- 3.3.3 802.11組件
- 3.3.4 802.11 Service介紹
- 3.3.5 802.11 MAC服務和幀
- 3.3.6 802.11 MAC管理實體
- 3.3.7 無線網絡安全技術知識點
- 3.4 Linux Wi-Fi編程API介紹
- 3.4.1 Linux Wireless Extensions介紹
- 3.4.2 nl80211介紹
- 3.5 本章總結和參考資料說明
- 3.5.1 本章總結
- 3.5.2 參考資料說明
- 第4章 深入理解wpa_supplicant
- 4.1 概述
- 4.2 初識wpa_supplicant
- 4.2.1 wpa_supplicant架構
- 4.2.2 wpa_supplicant編譯配置
- 4.2.3 wpa_supplicant命令和控制API
- 4.2.4 git的使用
- 4.3 wpa_supplicant初始化流程
- 4.3.1 main函數分析
- 4.3.2 wpa_supplicant_init函數分析
- 4.3.3 wpa_supplicant_add_iface函數分析
- 4.3.4 wpa_supplicant_init_iface函數分析
- 4.4 EAP和EAPOL模塊
- 4.4.1 EAP模塊分析
- 4.4.2 EAPOL模塊分析
- 4.5 wpa_supplicant連接無線網絡分析
- 4.5.1 ADD_NETWORK命令處理
- 4.5.2 SET_NETWORK命令處理
- 4.5.3 ENABLE_NETWORK命令處理
- 4.6 本章總結和參考資料說明
- 4.6.1 本章總結
- 4.6.2 參考資料說明
- 第5章 深入理解WifiService
- 5.1 概述
- 5.2 WifiService的創建及初始化
- 5.2.1 HSM和AsyncChannel介紹
- 5.2.2 WifiService構造函數分析
- 5.2.3 WifiStateMachine介紹
- 5.3 加入無線網絡分析
- 5.3.1 Settings操作Wi-Fi分析
- 5.3.2 WifiService操作Wi-Fi分析
- 5.4 WifiWatchdogStateMachine介紹
- 5.5 Captive Portal Check介紹
- 5.6 本章總結和參考資料說明
- 5.6.1 本章總結
- 5.6.2 參考資料說明
- 第6章 深入理解Wi-Fi Simple Configuration
- 6.1 概述
- 6.2 WSC基礎知識
- 6.2.1 WSC應用場景
- 6.2.2 WSC核心組件及接口
- 6.3 Registration Protocol詳解
- 6.3.1 WSC IE和Attribute介紹
- 6.3.2 802.11管理幀WSC IE設置
- 6.3.3 EAP-WSC介紹
- 6.4 WSC代碼分析
- 6.4.1 Settings中的WSC處理
- 6.4.2 WifiStateMachine的處理
- 6.4.3 wpa_supplicant中的WSC處理
- 6.4.4 EAP-WSC處理流程分析
- 6.5 本章總結和參考資料說明
- 6.5.1 本章總結
- 6.5.2 參考資料說明
- 第7章 深入理解Wi-Fi P2P
- 7.1 概述
- 7.2 P2P基礎知識
- 7.2.1 P2P架構
- 7.2.2 P2P Discovery技術
- 7.2.3 P2P工作流程
- 7.3 WifiP2pSettings和WifiP2pService介紹
- 7.3.1 WifiP2pSettings工作流程
- 7.3.2 WifiP2pService工作流程
- 7.4 wpa_supplicant中的P2P
- 7.4.1 P2P模塊初始化
- 7.4.2 P2P Device Discovery流程分析
- 7.4.3 Provision Discovery流程分析
- 7.4.4 GO Negotiation流程分析
- 7.5 本章總結和參考資料說明
- 7.5.1 本章總結
- 7.5.2 參考資料說明
- 第8章 深入理解NFC
- 8.1 概述
- 8.2 NFC基礎知識
- 8.2.1 NFC概述
- 8.2.2 NFC R/W運行模式
- 8.2.3 NFC P2P運行模式
- 8.2.4 NFC CE運行模式
- 8.2.5 NCI原理
- 8.2.6 NFC相關規范
- 8.3 Android中的NFC
- 8.3.1 NFC應用示例
- 8.3.2 NFC系統模塊
- 8.4 NFC HAL層討論
- 8.5 本章總結和參考資料說明
- 8.5.1 本章總結
- 8.5.2 參考資料說明
- 第9章 深入理解GPS
- 9.1 概述
- 9.2 GPS基礎知識
- 9.2.1 衛星導航基本原理
- 9.2.2 GPS系統組成及原理
- 9.2.3 OMA-SUPL協議
- 9.3 Android中的位置管理
- 9.3.1 LocationManager架構
- 9.3.2 LocationManager應用示例
- 9.3.3 LocationManager系統模塊
- 9.4 本章總結和參考資料說明
- 9.4.1 本章總結
- 9.4.2 參考資料說明
- 附錄