第二章 背景知識(Background)
2.1. WEP (Wired Equivalent Privacy)
在無線網路的傳輸過程中，存在一個非常明顯的問題就是竊聽者 可以很容易地透過無線電波偷聽到傳輸的內容。無線網路的設計者知 道這個問題，希望透過某一種安全標準可以解決這個問題，IEEE 802.11 無線網路中 使用的安全 標準 就是 WEP (Wired Equivalent Privacy)。望文生義，WEP 的目的就是期望可以達到與有線網路相等 的安全等級。它是 MAC 層的加密協定，使用 RC4 的加密演算法，其 中所使用的秘密金鑰是由 AP 以及客戶端所共享。WEP 提供了資料的 加密性、完整性以及使用者認證性等等功能[14] 。
WEP 標準同時包含資料加密性、完整性與認證性。目前 WEP 使 用 2 種金鑰長度，分別是 64 與 128 位元，其中包含了 24 位元的初始 向量（IV，Initialization Vector）與實際的秘密金鑰值（40 與 104 位元）。 大家耳熟能詳的 40 位元編碼模式，其實相當於 64 位元編碼。該標準 並沒有考慮到金鑰的管理問題，所有的設備必須以手動的方式管理金 鑰；唯一的要求是，無線網卡與基地台必須使用同樣的加解密演算法。
無線網路的每一個使用者會擁有同樣的加密金鑰，但是會使用不同的 IV，以避免封包總是使用同一把金鑰，而隨機產生的 RC4 亂數值。
|| PRNGRC4
CRC-32
IV
Ciphertext Initialization
Vector (IV) Secret Key Plaintext
Message
Seed Key Sequence
Integrity Check Value (ICV)
||
圖 1 WEP 加密流程
整個 WEP 的加密過程會把資料訊框透過 CRC-32 演算法產生一 組 32-bit 的完整性檢查數值(Integrity Check Value，簡稱 ICV)，此 ICV 會串連在資料訊框的尾端，最後再使用 RC4 演算法所產生的亂數值與 上述的資料訊框與 ICV 做 XOR 運算產生密文，請參考下圖 1。RC4 演算法則是透過發送端的 IV 值與金鑰做運算而產生一組亂算值。這個 數值也會被 AP 端用來解密客戶端傳送過來的密文，因為 IV 是以明文 的方式包含在密文前傳送過來的，所以接收端在收到 IV 之後再與自己 的金鑰透過 RC4 演算法產生出同一組亂數值，再與密文做 XOR 的運 算，可得原始的資料訊框與 ICV，接收端再將資料訊框做一次 CRC-32 的運算，與 ICV 比較後假使相同，即可確定該資料訊框是正確的，並 沒有遭到竄改，請參考下圖 2。資料內容最後就可以交由上層的通訊 協定處理。
圖 2 WEP 解密流程
在認證性的部分，802.11 定義了兩種存取控制的認證模式：公開 系 統 認 證 (Open System Authentication) 以 及 分 享 金 鑰 認 證 (Shared-key Authentication)兩種模式。公開系統認證模式是一個簡單 的雙向式流程，使用者只需要提出正確的 SSID 值(SSID 是同一個無線 網路區段中，使用者及 AP 所使用的網路識別名稱)，無需使用 WEP 的加密方式，待 AP 回應成功訊息後即可進入網路；另外客戶端設備可 以使用「ANY」這個 SSID，無論這個 AP 原本使用的 SSID 為何，就 可以連上任何 AP。在分享金鑰認證模式下，是由 AP 先傳送一個 challenge 給客戶端，客戶端再使用自己的金鑰將 challenge 加密傳回 AP，AP 再使用自己的金鑰將 challenge 加密與客戶端傳回的密文做比 較。如果兩者相同，表示客戶端的確知道真正的金鑰為何，AP 則授權 該客戶端連上網路。大部分的無線網路設備都是使用公開認證的模式。
公開系統認證模式
如圖 3，在公開系統認證模式中無線設備認證的流程如下：
1. 客戶端發送一個認證要求給 AP。
2. AP 將認證客戶端為成功或失敗。
3. 若認證成功，客戶端則能無線上網。
圖 3 公開認證 VS 分享金鑰認證
分享金鑰認證模式
分享金鑰認證模式的流程如下，如圖 3：
1. 客戶端發送一個認證要求給 AP。
2. AP 傳回一個挑戰訊息給客戶端。
3. 客戶端使用 64 或是 128-bit 的預設金鑰將挑戰訊息加密後，
回傳至 AP 端。
4. AP 使用所設定的 WEP 金鑰對加密訊息解密。解密後與原本 的挑戰訊息比較，如果相同表示 AP 與客戶端均擁有相同的加 密金鑰，客戶端則認證成功。
如果解密後的訊息與原本的挑戰訊息不相同，表示 AP 與客戶端的 加密金鑰不相同。AP 則會拒紹客戶端的認證，客戶端便無法連上無線 網路。
2.1.1. WEP 的弱點
Borisov、Goldberg 以及 Wagner 的報告指出[15]，WEP 編碼的
弱點在於 IV 實作的基礎過於薄弱。例如說，如果駭客將兩個使用同樣
Fluhrer、Martin 及 Shamir[16]三人也發現，設計不良的 IV 有可能 會洩漏鍵值的內容（信心水準為 5%），所以說只要記錄 400〜600 萬 個封包（頂多 8.5 GB 的資料量），就有可能以 IV 來算出所有的 WEP 鍵值。更進一步探討，如果 WEP 鍵值的組合不是從 16 進位表，而是 從 ASCII 表而來，那麼因為可用的字元數變少，組合也會變少。那麼
駭客猜中的機率就會大增，只要一兩百萬個封包，就可以決定 WEP 的 值。
Arbaugh、Shankar 以及 Wan 的報告中也提到[17]，在分享金鑰 模式認證模式下，由於挑戰訊息的明文與密文都是以未經加密的方式 在空氣中傳輸，攻擊者可以用竊聽的方式取得明文、密文及 IV 值，所 以攻擊者可以在不知道金鑰的狀況下，將明文與密文做互斥或的運算 即可得到加密用的亂數值。接著自己要求一個分享金鑰認證的方式，
從 AP 端得到另一組明文，再以剛剛計算出的亂數值計算，即可得到正 確的挑戰訊息密文。