無線網路安全機制剖析

 

HungLin Chou

hlchou@mail2000.com.tw

工研院電通所無線通訊技術組

 

一,前言

 

        無線網路傳輸是近年來相當流行的產業,從手機通訊上網到無線網路的發展,我們可以看到這樣的產業不斷的在成長與開疆辟土,使用者從對於無線網路全然陌生,到透過媒體與週遭環境的快速衍進,逐步的接受無線網路成為我們生活中的一部份.

 

        但是,無線通訊的技術不同於過去有線網路資料的傳輸,以往如果惡意的駭客想要入侵公司網路的話,最直接的方式就是把公司對外的攬線從中轉接到駭客的環境裡,透過過濾公司進出封包的資訊內容,來取得商業機密. 這種實體入侵的手法,對於駭客而言無形中增加了許多的困難點,可是無線網路的發展,卻讓公司內部網路對外如同開啟另一扇大門,由於無線網路訊號傳輸的無遠弗界,讓有心人即使不在企業內部,只要可以接收到無線網路的訊號,例如:在公司隔壁大樓,就可以竊取公司內部網路的資料.

 

接下來就讓我們開始這次文章的內容,這回的文章可能會稍微偏向通訊協定上的議題,不過舉出這樣文章的用意在於,隨著無線網路技術的演進,Linux 在這領域的角色也相形重要,對於Linux領域的愛好者而言,進一步的瞭解相關技術也就有其不可或缺的重要性.

 

 

二,無線網路

 

        目前大家最耳熟能詳的無線網路技術不外是802.11a(54Mbps/sec,11Channels)/b(11Mbps/sec,3Channels),這些無線網路傳輸標準的協定,不過除了定義傳輸標準的協定以外,802.11還定義了許多延伸與安全的協定,以便於在日後提供給無線網路使用者更為多元的使用環境,目前這些協定還包括

 

 

 

(1)802.11e:提供具備服務品質保證(QoS , Quality of Service)的無線網路環境,,以往無線網路主要定義了封包資料的傳輸,一般資料的傳輸允許在網路擁塞的情況下遺失資料,在透過重送的機制來把資料傳遞完成. 可是這樣的方式並不能充分滿足即時(Real-Time)多媒體影音服務傳輸,尤其當無線網路資源擁塞時,多媒體服務的延遲將會對用戶造成使用上的不便,所以802.11e定義了QoS的機制,可以提供影音資料較高的傳輸優先權,提供使用者更為流暢的無線網路影音服務.

 

(2)802.11f:提供了無線網路使用者漫遊(Roaming)時,透過不同無線接取點(Access Point)連線的資料交換機制,其中定義了IAPP(Inter Access Point Protocol) 機制,讓使用者在切換無線接取點時,可以讓新的AP與舊的AP交換使用者的連線資料,以便於維持原有的連線,而不會導致連線中斷,影響使用者無線網路傳輸.如下圖(一)所示

 

圖(一),802.11f下使用者在Access Point間移動的示意圖

 

(3)802.11g:定義了無線網路實體層的標準,可在2.4GHz與5Ghz的頻帶中提供3個無線通訊管道(Radio Channel),可以在每個Channel提供54Mbps的頻寬(802.11b為11Mbps),使用OFDM(Orthogonal Frequency-Division Multiplexing )的數位調變方式,為了相容於802.11b的環境,所以也同時支援CCK(Complementary Code Keying )調變方式.

 

(4)802.11i: 定義了在802.11a/b/g MAC(Media Access Control) Layer的安全機制,主要以EAP-802.1x做為認證的方式,AES與TKIP(Temporal Key Integrity Protocol)作為加密的方法,當然目前跟802.11f,一樣都沒有最後定案的版本,不過在可預見的未來裡,802.11i肯定會成為無線網路安全方面最為重要的通訊協定架構.

 

目前WLAN的安全是利用WEP加解密的方式來達到安全需求，不過這樣的方式由於WEP加密上的缺失,導致容易被惡意使用者入侵破解。例如駭客只要在辦公大樓外面，架設天線，並進行加解密的動作，就容易侵入公司內部網路.

 

        在無線網路安全沒有進一步的保障前,最好的方式就是可以透過WLAN加上VPN的安全機制,如下圖(二)所示

 

圖(二),WLAN透過VPN接取Internet的資源

 

        VPN的加密機制可以補足WLAN所缺乏的安全問題,例如可以在公司內部架設一個VPN Server,提供PPTP或是IPSec的機制,讓使用者在無線網路傳輸時,可以先透過PPTP簽入內部主機後再連結上網路資源,如此一來在無線部分傳輸的資料就可以透過加密的方式來傳輸了.

 

        不過,用VPN 來解決無線網路安全問題並不是一個最佳的方案,不過在目前更佳的無線網路安全標準尚未建立以前,有些廠商則採用這樣的架構作為暫時的系統解決方案.

 

 

 

三,透過WEP(Wired Equivalent Privacy)加密的問題

 

        在802.11標準定案時,在Link Layer也同時定義了WEP(Wired Equivalent Privacy)作為防止資料遭到竊取與攻擊的加密機制. WEP定案之後,陸續就有人開始針對這方面的安全問題加以探討,進而找出了WEP加密的弱點. 因此在本文的這個段落中,筆者將針對WEP加密所導致的問題加以介紹,當然在討論WEP被攻擊的弱點之前,我會先把WEP加密的機制解說一次,之後才帶入衍生的問題點.

 

        無線網路的環境,透過WEP加密傳送封包時只有MAC Address與IV欄位是明碼,其餘部分都會經由RC4編碼加密來傳送.

 

        RC4為一種對稱式的金鑰加密方法,也就是在加密的兩端之間(WLAN Client與Access Point)都要維持一個相同的Key,共同用這把Key來加解密.

 

        加密的方式主要可以分為兩類Block Cipher與Stream Cipher,所謂的Block Cipher指的就是針對一個一個區塊的加密方式,這樣的方式實做起來比較複雜,而且會需要多餘的記憶體來儲存暫存的資料. 另一種方式就是Stream Cipher,把所要加密的資料一個byte一個byte的加密,好處就是實做簡單,可以快速的產生加密後的資料.

 

        如下所是就是透過RC4 Stream Cipher加密的流程示意圖,

 

圖(三),Stream Cipher 示意圖

 

 

        資料傳輸時,WEP Key是不變的,唯一會改變的就是24 bits長度的IV值,根據不同廠商實做的方式,IV值可以隨著每個封包的傳送而改變,也可以維持一定的週期不重複,不過由於IV值是由24bits的長度所組成,所以最大的IV週期將不會超過2^24(16777216)個封包,也就是說,如果惡意攻擊者在WEP Key不更新的情況下,只要連續監聽不超過2^24封包就可以偵測到重複的IV值了. 尤其如果每次IV值都是由小到大重複計算送出,那樣當系統重置時(重新開機或是重新插拔PCMCIA網卡),就有可能會導致IV值重複出現的機率大幅增加.

 

        由此我們可以知道在WEP的保護下,基本上外人是無法得知實際上傳輸的資料內容,除非惡意的使用者知道了我們使用的WEP Key,

 

 

        如下所示,為一個封包透過RC4加密的流程,首先系統會產生一組24 bits動態產生的IV值,這個IV值與系統所使用者WEP Key一起經由RC4運算後,經由Stream Cipher的方式透過XOR加密使用者所要傳送的封包,在使用者加密後的封包要送出時,剛剛產生的IV直就會附在封包之前,接收者只要根據這個IV直與兩邊共同擁有的WEP Key,就可以把加密過的封包資料解回來了.

 

圖(四),WEP-IV Encryption

 

 

        如下圖所示,在接收端收到封包後,就可以把IV值與接收端的WEP Key經過RC4運算後,再與原本加密過的封包做一次XOR運算,就可以把封包給解回來了.

 

圖(五),WEP-IV Decryption

 

 

        在我們清楚了WEP加密的機制之後,我們再針對WEP所可能發生的安全問題加以介紹,首先就是由於這樣的加密流程,WEP Key本身是不變的,改變的是長度為24bits的IV值(IV值在WEP2時已經加長到128bits),所以說一旦被入侵者收到同樣的IV值且內容不同的封包,那樣就可以建立起一個統計IV直的資料庫,而對封包加以破解,如以下例子

 

 

圖(六),透過IV值的重複取得明碼

 

        透過這樣的方式,如果我們又可以推出其中一個PlainText1內容的話,就可以把另一個文字內容給解開了.

 

        如果我們知道那個IV值配上那個RC4(WEP Key,IV)值,那我就可以組合出一樣的CheckSum值,送出我自己想要送出的資料封包(例如:ICMP),進而來拆解出我們所要的WEP Key

 

 

四,802.1x Port-Based Network Access Control

 

        在正式介紹到EAP(Extensible Authentication Protocol)認證的機制以前,在無線網路安全架構下(802.11i)將會引入802.1x Port-Based Network Access Control的機制,透過這樣的機制,Access Point可以用來過濾沒有經過後端認證伺服器(Radius Server)許可的使用者封包.

 

        當Access Point與Radius Server 進行Radius Protocol的協議流程時,如果收到Access-Reject的封包,就表示該使用者認證失敗,被Radius Server拒絕登入. 如果Access Point收到Access-Accept,就表示該使用者認證成功,Radius Server同意其登入網域,之後只要是由該使用者經過認證的主機所送出的封包,經過Access Point時就會放行通過.

 

如下圖(七)所示為無線網路使用者透過進行認證的示意圖,我們可以看到在Access Point(Authenticator)與使用者(Supplicant)端使用EAPOL作為EAP認證的底層協定,支援802.1x認證的Access Point會記錄目前認證過的MAC Address,並且會禁止未經認證的MAC Address通過Access Point,如果該MAC Address認證過了,就會記錄在Access Point,之後由該MAC Address所發出的封包就可以自由進出Access Point.

 

        當然囉,在一開始沒有任何使用者通過認證時,只有Ethernet Type為0x888E的封包可以通過,0x888E的封包指的就是EAPOL(EAP Over Lan)的封包,緊接在12bytes的Destination and Source MAC address之後,當Access Point收到 EAPOL的封包後,就會把其後的EAP封包內容加入要送給Radius Server的Radius Protocol封包EAP-Message Attribute中,再送給Radius Server進行認證.

 

       

圖(七),EAPOL通過 802.1x Access Point的示意圖

 

 

五,EAP(Extensible Authentication Protocol) 認證機制與RADIUS (Remote Access Dial In User Service)Protocol

 

整個無線網路認證的機制會包括EAP,EAPOL與Radius Protocol.

 

圖(八),EAP認證機制架構圖

 

        EAP(Extensible Authentication Protocol)è是一個 PPP(Point-to-Point Protocol) 的延伸,主要用來在PPP中提供額外的認證機制,以提供遠端登入的認證機制,基於不同的安全需求與使用考量,EAP提供了不同的認證方式(例如: MD5-Challenge, TLS(Transport Level Security,可透過Smart Card認證).

 

        EAPOL(EAP Over Lan)è是屬於無線網路協定裡IP Layer以下的通訊協定,主要定義在IEEE 802.1x的7.6節中, 可以讓使用者在未經過EAP認證登入以前的封包,透過EAPOL的傳送,經由Access Point與後端AAA (Authentication, Authorization, and Accounting) Server進行認證.

 

        Radius Protcolè主要用來提供Authentication機制,用來辨認使用者的身份與密碼,確認通過之後,經由Authorization授權使用者登入網域使用相關資源,並可提供Accounting機制,保存使用者在網路上的活動記錄,以提供系統服務業者完整認證收費機制的一個基礎.

 

        如下圖()所示,為一個EAP封包被EAPOL封包封裝時的封包格式

 

圖(九),EAPOL&EAP封包格式

 

由於在系統尚未認證前只有EAPOL的封包可以通過Access Point,所以在Access Point會去檢查PAE Ethernet Type的欄位,如果為 0x888E ,表示此為EAPOL的封包,就會放行通過(例如:IP封包欄位值為0x0800,ARP封包為0x0806,PPPOE的封包為0x8864), 不然就會過濾掉.

 

        EAPOL的檔頭中最重要的就是Packet Type,他可以讓我們確認這個EAPOL封包是夾帶EAP封包的,或是用來進行一般EAPOL的程序.

 

EAPOL的Paeket Type可以分為五類,如下

 

(1)   EAP-Packet(0x00)è表示這個Frame是用來夾帶EAP資料的,所以如圖()的Packet Body Length就會包含後便Packet Body資料長度. 而Packet Body代表的就是所夾帶的EAP封包內容.

其他四類的Packet Type都是專屬於EAPOL使用,並不會用來夾帶EAP的資料,所以它們的Packet Length都是為0.

如下為筆者所攔下的封包

 

00 02 2d 1d fa c0 00 06 25 ac 24 3c 88 8e 01 00

00 04 01 00 00 04 01 00 00 00 a0 62 fc b9 a1 2c

8c 57 88 9e 0d b3 e7 1e a3 13 00 00 00 00 00 00

00 00 01 d4 60 d5 82 b4 ce 35 59 5a

 

每個欄位所代表的意義

 

00 02 2d 1d fa c0èDestination MAC Address

00 06 25 ac 24 3cèSource MAC Address

88 8eèPAE Ethernet Type

01èProtocol Version

00 èPacket Type

00 04èPacket Body Length

01èEAP-Packet Code

00èEAP-Identifier

00 04 èEAP-Length

01 èEAP-EAP Type

00 00 00 a0 62 fc b9 a1 2c 8c 57 88 9e 0d b3 e7

1e a3 13 00 00 00 00 00 00 00 00 01 d4 60 d5 82

b4 ce 35 59 5aèEAP-Type Data

 

(2)   EAPOL-Start(0x01)è

 

如下為筆者所攔截EAPOL-Start的封包,前12個bytes為目的和來源端的MAC Address,再來就是代表EAPOL封包的0x888E Ethernet Type

 

00 06 25 ac 24 3c 00 02 2d 1d fa c0 88 8e 01 01

00 00 00

 

每個欄位所代表的意義

 

00 06 25 ac 24 3cèDestination MAC Address

00 02 2d 1d fa c0èSource MAC Address

88 8eèPAE Ethernet Type

01èProtocol Version

01èPacket Type(0x01代表為EAP-Start)

00 00èPacket Body Length

 

其它例如EAPOL-LogOff(0x02)作為登出EAPOL環境的封包, EAPOL-Key(0x03)用來交換Key使用的封包 與EAPOL-Encapsulated-ASF-Alert(0x04.

 

 

EAP的檔頭主要包含以下幾項(RFC 2284)

 

Packet Code(1 byte)è

1為EAP Request

2為EAP Response

3為EAP Success

4為EAP Failure.

 

Identifier(1 byte)è用來辨認Request與Response,所以回覆該Request的Response封包它的Identifier必須與Request送出的一致. 不同Request會有不同的Identifier.

 

Length(2 bytes)è表示EAP封包的長度.

 

EAP Type(1 byte)è一個EAP封包只會包含一個EAP Type,共可分為以下七類

(1)   Identityè0x01

(2)   Notificationè0x02

(3)   Nak(Response Only) è0x03

(4)   MD5-Challengeè0x04

(5)   One-Time Password(OTP) è0x05

(6)   Generic Token Cardè0x06

(7)TLSè0x0d

 

 

如下圖所示,為RADIUS Protocol的封包格式,可以根據目前通訊上的需求,加入不同的Attribute

圖(十),EAP Over RADIUS 封包格式

 

        例如,在EAP-TLS認證的需求下,微軟也定義了一些新的Radius Attribute,例如:RFC 2548, Microsoft Vendor-specific RADIUS Attributes.

 

        RADIUS封包的第一個欄位為Code,可以用來辨別這個RADIUS封包主要的功能,可以分為以下幾類(可參考RFC 2138)

1      èAccess-Request

2      èAccess-Accept

3      èAccess-Reject

4      èAccounting-Request

5      èAccounting-Respons