最近流行的壹項技術是“Wi-Fi”無線局域網。它運行在2.4GHz，是壹種基於無線電的方法:以可接受的連接帶寬將計算機連接到網絡。正如無線網絡愛好者約翰·薩克斯頓(John Saxton)提到的，“Wi-Fi是由IEEE P802成員設計和開發的，包括朗訊(現在的Agere)和哈裏斯(現在的InterSil)，他們花了幾年時間研究無線以太局域網。”他們是這個領域公認的專家，所以他們的工作(標準化IEEE 802.11b[縮寫為“802.11”])應該是值得效仿的。802.11是IEEE針對如何在相對較短的物理距離內將完全不同的計算元件聯網這壹問題的解決方案。在Palm PDA使用的IrDA紅外鏈接是針對同壹問題的另壹個明確的解決方案。IrDA允許PDA與配備IrDA硬件的主機進行短距離通信(以及相互通信)。802.11旨在提供相同的無縫功能，但在更大的物理範圍內。通過使用無線電波增加了從設備到接入點的距離，並且通過有線等效協議(WEP)對數據流進行了加密。WEP WEP是802.11系統安全的壹部分。其目的是提供機密性和數據完整性，並通過拒絕所有非WEP數據包來保護對網絡基礎設施的訪問。WEP使用通信者共享的密鑰。壹些版本使用最初用於制定標準的40位密鑰，而其他較新的版本使用128位(實際上是104位)密鑰。實際的加密/解密過程如下所示:對數據幀進行校驗和檢查(使用CRC-32算法)以獲得c(M)，其中M是消息。合並M和c(M)得到明文P=(M，c(M))。使用RC4算法加密p。這生成了作為初始化向量(IV)v和秘密密鑰k的函數的密鑰流；它以RC4 (v，k)為代表。密文是通過對明文和密鑰流應用異或函數生成的。然後，通過無線電發送密文和IV。從圖形上看，這個過程類似於:解密與加密正好相反。接收者重新生成密鑰流，並將其與密文進行XOR運算以恢復原始明文。然後，消息(p’)被分成兩部分:m’和c’。然後，計算c(M′)，並與接收到的校驗和c′進行比較。如果不是，消息體在傳輸過程中以某種方式被改變了。解密通過在數據包傳輸中使用IV和* * *共享密鑰來生成等效的加密密鑰流。最後，將結果與密文進行異或運算以顯示消息。在後壹頁的開頭，出現了WEPbuster。從上面可以看出，安全性在數學上取決於密鑰及其抵抗發現的能力。然而，尼基塔·博裏索夫、伊恩·戈德堡和戴維·瓦格納在今年1月的Mac-Crypto會議上提交的壹篇論文詳細描述了802.11的體系結構安全弱點(參見參考資料)。我主要依靠這篇論文來解釋所發生的事情。作者指出，如果兩條消息用相同的IV和密鑰加密，那麽流密碼(如RC4)就容易受到攻擊。如果密文壹起被異或，那麽密鑰流將彼此抵消，而兩個明文的異或將保留。在壹個典型的消息中，有壹個明文的重復，可以解決兩個明文的異或。有人可能會查找壹個已知的明文(例如“密碼:“”，當該明文與其自身進行異或時，就可以計算出兩個明文的異或中的文本。因此，如果密鑰流在消息之間被重用，如果攻擊者只知道部分明文，他將有另壹個危及加密的機會。作者意識到，盡管WEP標準建議在每個數據包之後改變IV(以及與密鑰結合的IV的RC4 ),但並不要求這樣做。事實上，他們發現在他們測試的壹些PCMCIA 802.11卡(比如朗訊的)中，初始化時IV被重置為零，然後每傳輸壹個包計數器就增加1。因為每次將卡插入便攜式計算機時都會進行初始化，這意味著低IV的密鑰流會頻繁出現，並且在密鑰的生命周期內都是如此。這樣，攻擊者在破壞時將擁有多個低IV密鑰流的實例化。重用是壹個眾所周知的密鑰流弱點，應該在802.11標準中解決，這樣卡制造商就不能使用這個方案，仍然試圖滿足標準。802.11還有其他結構問題。最隱蔽的問題之壹是IV數據空間只有24位寬。當有人認為5Mbps網絡接入點將在不到半天的時間內傳遞24位寬的數據包時，這個問題就變得很明顯了。這意味著即使低價值的IV沒有出現在數據流中，IV也會被習慣性地重復(而且或多或少是可以預見的)。從安全角度來看，這並不令人欣慰。如果攻擊者知道用相同IV加密的兩個包之壹的明文，他就可以解密這兩個包。因為大多數IP流量是以壹種眾所周知的方式組成的，所以攻擊者可以對消息做出壹些假設，並註意它們是否符合手頭的數據包。如果攻擊者已經獲得了完整的明文(比如攻擊者給妳發了壹封郵件，然後在802.11鏈接上等待妳閱讀)，那麽攻擊就變得無足輕重了。攻擊者需要壹個已知的明文來利用密鑰重用。為此，他可以建立壹個密鑰流對IV的“字典”。因為密鑰空間是2的24次方，也就是整個字典會占用1500字節(平均802.11密鑰流長度)乘以2的24次方，也就是24GB左右。這將適合許多現有的硬盤驅動器的多余空間。只是需要壹些時間和精力。這種攻擊不受密鑰長度的影響，只受IV的24位長度的影響。後頁頂部的密鑰管理問題802.11標準在密鑰管理中是沈默的。因此，大多數網絡對802.438+0438+0使用單個密鑰，即使在密鑰數組中指定索引的可選密鑰標識字段出現在消息中。這個領域在當前的實踐中似乎沒有被使用，但是壹旦架構弱點被更廣泛地傳播，這可能會改變。單個密鑰使得前面描述的所有攻擊更容易執行，尤其是當多個用戶共享密鑰時。而如果密鑰泄露，所有用戶都必須更換自己的系統驅動器，因為所有的系統驅動器都會被泄露。這將很難管理，並且需要時間來發揮作用，所有這些都對攻擊者有利。回到頁面頂部的WEP消息驗證，我提到了在WEP下對消息執行CRC-32校驗和。這是為了扮演消息完整性保證者的角色。但事實並非如此。CRC-32也不能幸免於惡意攻擊。讓我們先研究壹些校驗和屬性:校驗和是消息的線性函數。也就是說，它均勻分布在消息的整個XOR運算中。這意味著有壹些方法來控制校驗和，以便協議可以接受它，但它與消息內容無關。事實上，作者在他的論文中提供了壹個數學證明。另外，只要我們知道部分數據包內容，就可以執行這種攻擊。因此，校驗和可以被欺騙——它不是身份驗證的保證人。校驗和是壹個未加密的函數。也就是說，它不依賴於密鑰。如果攻擊者知道消息的明文，他可以在不知道密鑰的情況下得到CRC。它唯壹的解決方法是需要壹個加密的消息認證碼(比如SHA-1/HMAC)，而802.438+01標準並不要求這樣做。由於另壹個WEP特性(如下所述)，源自已知明文的攻擊只會成功。如果接收器不知道IV值，這些值可以重復使用。我們前面討論過這個問題；但在標準上仍有缺陷。使用接入點來破解WEP修改包是壹種啟用另壹種復雜攻擊的機制，這種攻擊使用物理接入點來解密編碼消息。其實IP重定向的使用比較簡單。首先，攻擊者從無線電信息流中發現壹個加密的數據包，然後修改它，使數據包立即發送到壹個受控的IP地址。它將被無阻礙地發送，因為接入點在它被發送到因特網之前解密它。從計算上來說，改變IP地址並不難。如果原IP地址的高16字和低16字是Dh和Dl，那麽我們需要把它們改成Dh '和Dl '。如果X是原始IP校驗和，那麽在補碼數學中，X' = X+Dh' +Dl'-Dh-Dl。如果攻擊者以某種方式知道X，他會根據上面的公式和[X (XOR) X']計算X '，得到我們要將數據包重定向到的IP的校驗和。這是最簡單的情況。也有人會憑經驗猜測IP地址，看看是否管用。這是壹種反應攻擊，因為攻擊是通過觀察偽造的反應來進行的。猜測正確的IP會被系統接受，而猜測錯誤的IP會使數據包落入位存儲區。這只對TCP數據包有效，因為攻擊者需要確認TCP校驗和正確時發送TCP(TCP ACK數據包是標準大小)。這充分證明了校驗和不是保證消息認證的好方法這壹命題的真實性。可以在系統不知情的情況下改變消息並插入偽造的新校驗和。像Mac這樣的加密功能可以防止這種攻擊。在《華爾街日報》的最新文章中，Greg Ennis(他是無線以太網兼容性聯盟的技術總監，也是IEEE的前成員)指出，標準流程“對任何人開放”。盡管他同意最近的弱點是壹個問題，但他提出了壹個有趣的觀察:WEP“從壹開始就不被視為頂級安全系統。”他還指出，IEEE正在研究不容易受到攻擊的未來版本。恩尼斯還表示，這種類型的攻擊“需要付出重大努力”才能完成。這是事實――這種情況不是不可克服的。如果有人-或政府機構-想吸收聖何塞機場美國航空公司貴賓休息室的所有筆記本電腦網絡流量，他們可以通過壹些特殊設備和壹些固件來實現。這就是問題所在。在《華爾街日報》的文章中，引用了壹位紐約計算機安全顧問的話說，當他坐在街對面的長椅上時，他可以訪問他的客戶——華爾街壹家主要金融服務公司——的計算機網絡。實現利用似乎沒那麽難。後頁解決方案PGP用PGPnet展示了它的方法。從鍵盤到最終用戶的超級加密為妳設置了壹個虛擬的專網，任何破壞802+05438+0傳輸的人都會嗅出無用的信息。WEP的問題似乎是，當它停止偶然的監聽時，它就失去了任何嚴重的攻擊。這可能是由於設計選擇使用更簡單的CRC來避免Mac的計算開銷。不管缺陷的原因是什麽，WEP本身似乎並不能保證安全。當用戶不得不使用移動網絡時，不要讓它危及妳的數據。作為參考，您可以參考developerWorks全球網站上這篇文章的英文原文。
由尼基塔·博裏索夫、伊恩·戈德堡和戴維·瓦格納合著的《攔截移動通信:802+0438+0的不安全性》深入研究了WEP的許多缺點。
IEEE 802.11手冊的其他資料請參考Bob O'Hara和Al Petrick合著的IEEE 802.11手冊:設計者指南。Informed Technology出版了這本書，並在其網站上更新了內容。
IEEE 802.11工作組在其網站上發布了當前主題列表。
關於作者拉裏·勒布(Larry Loeb)是上世紀《死亡機架》(Death Rack)多家電腦雜誌的編輯或作者。此外，他還出版了壹本關於SET的書，SET是Visa和MasterCard為安全電子交易開發的協議。妳可以通過larryloeb@prodigy.net聯系他，通常妳會得到答復。關閉關於舉報虐待的[x]幫助。舉報虐待。謝謝大家！此內容已被標記為引起管理員的註意。Close [x]關於舉報濫用的幫助舉報濫用舉報濫用失敗。請稍後再試。關閉[x]developerWorks:登錄IBM ID:需要壹個IBM ID？忘了IBM ID？密碼:忘記密碼了？更改您的密碼並保持登錄狀態。通過單擊submit，您同意developerWorks的條款和條件。使用條款當您第壹次登錄developerWorks時，會為您創建壹個概要文件。您選擇在developerWorks概要文件中公開的信息將向其他人公開顯示，但是您可以隨時修改這些信息的顯示狀態。您的姓名(除非您選擇隱藏)和昵稱將與您在developerWorks中發布的內容壹起顯示。所有提交的信息都是安全的。Close [x]請選擇您的昵稱:當您第壹次登錄developerWorks時，會為您創建壹個概要文件，您需要指定壹個昵稱。您的昵稱將與您在developerWorks上發布的內容壹起顯示。昵稱長度介於3到31個字符之間。出於隱私保護的原因，您的昵稱在developerWorks社區中必須是唯壹的，並且不能是您的電子郵件地址。昵稱:(長度在3到31個字符之間)單擊Submit表示您同意developerWorks的條款和條件。使用條款。所有提交的信息都是安全的。給這篇文章打分，評論回頂。