作爲無線網絡，它在實現加密的時候，跟有線網絡有一些比較特殊的地方，無線網絡在鏈路層的可靠性比較差，容易造成一些數據差錯，甚至一些數據丟失，那麼因此呢，作爲web在設計的時候提出要實現自同步，所謂的自同步，事實上就是對於每一個分組，要能夠進行單獨的加密和解密，那麼也就是說，對於一個給定的已加密的分組，以及對應的密鑰，我們就可以對分組進行解密，那麼不管這個分組的前序分組是否出現丟失，我們都可以成功的對這個分組進行解密，換句話說呢，就是加密和解密過程中在分組之間，不能有依賴關係，不能像CBC一樣，說我這個分組加密的結果可能作爲一個輸入跟下一個加密分組再進行異或等等，這個不行
另外一個，作爲web從設計角度來說呢，是期望實現高效，這個高效主要是表現在整個方法上要相對來說不能太爲複雜，要實現硬件和軟件都可以實現，這是作爲web設計的一個目標
作爲流密碼，一定要有一個初始的密鑰，然後在產生密碼流的過程中，我們是針對每一個分組獨立產生一個密碼流，這個密碼流和分組和分組之間是沒有依賴關係的，那麼另外爲了保證每個分組使用的密碼流又不同，那麼因此我們又引入了一個IV初始向量，那麼原則上呢每一個分組使用的初始向量是不同的，那麼把初始向量再加上初始密鑰放在一起，那麼事實上是真正產生密碼流的初始密鑰，這樣呢，我基於這個初始密鑰再加上每一個分組對應的IV產生的密碼流，原則上每個分組用的密碼流就不同了
而這個密碼流是專門針對這個分組的，原則上只要每個分組的IV不同，那麼產生的密碼流也不同
作爲web事實上有多種標準，我們早期的基本的web是web40，它的初始密鑰，對稱密鑰是40個bit，我們現在很多一般不使用這個web40，一般會使用web104，這個時候每一端維護的共享密鑰是104位，我們後邊也是以這個104位爲例
作爲每一端都會有一個共享的104位的共享密鑰，作爲共享密鑰我們說呢還會用到一個IV，我們剛纔說了，針對每一個分組，我們要有一個針對這個分組的初始向量，我們稱之爲IV，這個IV是多少呢？IV是24bit，那麼在產生密碼流的時候，就是要把這個24個bit和104bit的共享密鑰放在一起實際上就得到一個128bit的這樣一個密鑰，用這個128bit的密鑰去爲每一個分組生成密鑰流
作爲web原則上來說呢，在兩端，或者說在每一端維護的共享密鑰可以不止一個，可以有多個，那麼這個時候呢，我們還需要有一個作爲密鑰ID，指定我們使用的是哪一個密鑰，那麼這個呢在我們最後構造成web的分組數據幀的時候，也要把這個keyID加進去，是一個8bit的字段
128bit密鑰=104bit初始共享密鑰+24bitIV 輸入到僞隨機數發生器以後，我們就可以得到一個密鑰流
RC4：流密碼加密算法 對數據以及ICV進行加密，也就是說這一部分內容在web中是進行加密的
最終構成802.11數據幀的時候，我們還要把我們前邊提到的IV還有keyID附加上去，就構成了802.11數據幀的載荷，也就是數據，我們把它稱之爲MAC，當然這個MAC大家注意，不是報文認證碼而是介質訪問控制，實際上我們所說的MAC子層這樣一個數據幀，它的載荷
將載荷插入到802.11數據幀之中就構成了一個802.11的一個幀，這個時候幀實際上已經通過web進行加密，進行安全性保護了
階段1：安全能力發現階段，作爲無線主機和AP之間通過彼此發現，並且呢，確認對方或者說彼此可以提供的安全能力，比如說呢，使用什麼加密方法呢，等等，在這個階段來進行確認，在這個基礎上
階段2：要完成認證，那麼這個認證過程中，事實上要在我們的STA客戶站點，和認證服務器之間完成相互認證，那麼這個相互認證最終還要確認一個主密鑰，生成一個主密鑰，在這個認證過程中，像我們圖中看到的示意圖，AP只進行一個數據的轉發，類似於一個數據中繼，相當於在我們這個移動主機和認證服務器之間提供了一個穿越式的通道，它不參與具體的認證，只完成認證信息的一個轉發，在階段2確定的主密鑰的基礎上
階段3：作爲我們的移動站點，或者說是無線站點，客戶端的站點，以及作爲我們的認證服務器都要基於這個主密鑰，最後導出一個叫成對主密鑰PMK，那麼作爲客戶站點要導出這樣一個PMK，作爲認證服務器也要導出相同的PMK，並且認證服務器還有一個責任，它需要把這個導出的PMK呢，發送給AP，這樣呢AP也就知道了，作爲我這個AP跟我這個移動的無線客戶端站點STA之間所確認的達成一致的成對的PMK到底是什麼，那麼，這是第3個階段
第4個階段：作爲我們客戶端的站點以及AP，要基於第3個階段確認的導出的PMK，再次導出用於報文加密和完整性認證的這樣一些臨時的密鑰TK，這個TK纔是我們無線主機和AP之間按照802.11i進行通信過程中，真正要使用的密鑰
