AES si 802.11i

AES si 802.11i

AES

Cea mai evidenta dezvoltare este introducerea unui nou proces de criptare, numit AES-CCM. Dupa cum sugereaza si numele , schema de criptare se bazeaza pe succesorul lui DES AES, in contrast cu WEP si TKIP, care se bazeaza ambii pe RC4. Din moment ce doar cea mai noua geneatie de cipuri WLAN contine hardware AES, 802.11i continua sa defineasca TKIP, dar cu prerogativele: orice hardware 802.11i compatibil trebuie sa suporte AES, in timp ce TKIP este optional- in WPA aceasta era exact invers. Datorita raspandirii largi a hardware-lor necompatibile AES , se asteapta ca fiecare card WLAN capabil de AES sa suporte inca WEP si TKIP. Echipamentele WLAN vor prezenta, probabil, optiuni privind configurarea TKIP- multe agentii in SUA considera TKIP insuficient de sigur, care in comparatie cu hashing-ul slab, Michael, este destul de justificata.

Sufixul CCM denota modul in care AES este utilizat in pachetele WLAN. Acest proces este destul de complicat, din acest motiv CCM este doar sensibil implementat in hardware - implementari bazate pe software sunt posibile, dar vor rezulta scaderi semnificative de viteza datorita procesorilor utilizati frecvent in puncte de access.

In contrast cu TKIP, AES doar necesita o cheie de 128 biti, cu care se atinge atat criptarea cat si protectia impotriva schimbarilor nedetectate ale pachetelor. In plus, CCM este perfect simetric, aceeasi cheie este utilizata in ambele directii de comunicatie.

Ocazional, se gasesc variante mai vechi ale AES in publicatii despre standardul 802.11i, numit AES-OCB sau WRAP. In aceste variante, AES a fost utilizat intr-o forma diferita, la care s-a renuntat in favoarea CCM in standardul final. WRAP este in zilele de astazi nesemnificativ.Similar cu TKIP, CCM utilizeaza un vector de initializare de 48 biti in fiecare pachet - o repetare a IV este imposibila in practica. Ca si la TKIP, receptorul noteaza ultimul IV utilizat si renunta la pachetele cu un IV egal sau mai mic decat valoarea comparata.

Pre-autentificare si PMK(Pair-wise master key) intermediar

Dupa cum s-a mai mentionat, intarzierea in publicarea standardelor este datorata detaliilor. In cazul 802.11i, au fost doua detalii care in mod particular ar fi trebuit sa ajute WLAN pentru conexiuni cu voce (VoIP) in retelele intreprinderilor. In special in conexiunile cu WLAN - telefonia bazata pe retele fara fir , roaming rapid (comutarea de la un AP la altul fara intreruperi) este de o semnficatie speciala. In conversatiile din telefonie, intreruperi de 100 milisecunde sunt iritante, dar intregul process de autentificare peste 802.11X, inclusiv negocierea cheii subsecvente cu AP, pot dura un timp semnificativ.Din acest motiv, asa numitul PMK intermediar a fost introdus ca o prima masura. PMK, bineinteles, serveste ca o cheie de baza pentru negocierea intr-o autentificare 802.1X atat pentru client cat si pentru AP. In mediile Voip este posibil ca un user sa se mute inainte si inapoi intre un numar relativ mic de AP. Se poate intampla ca un client sa comute inapoi la un punct de acces la care a mai fost inregistrat anterior. In acest caz ar fi fara sens sa se repete intreaga autentificare 802.1X. Din acest motiv, AP poate furniza PMK cu un cod , asa numitul PMKID, care se transmite la client. In cazul unei noi inregistrari, clientul utilizeaza PMKID pentru a interoga daca acest PMK mai este inca retinut. Daca da, faza cu 802.1X poate fi sarita si doar schimbul de pachete scurte este necesar inainte de restabilirea conexiunii. Acesta optimizare nu este necesara daca PMK-ul intr-un WLAN este calculat dintr-o expresie-de-permisiune intrucat aceasta se aplica oriunde si este cunoscut. O a doua masura permite unele accelerari chiar si in cazul unei prime inregistrari,dar necesita o mica atentie in ceea ce priveste partea clientului. Clientul trebuie deja sa detecteze o conexiune degradata la AP in timpul operatiei si selecteaza un nou AP in timp ce este inca in comunicatie cu vechiul AP. In acest caz are oportunitatea sa faca negocierea 802.1X cu noul AP peste vechiul AP, ceea ce reduce "timpul mort", necesitat de negocierea 802.1X.

"4-way handshake"

RSNA (Robust Security Network Association) defineste "4-way handshake" pentru a efectua cateva functii precum confirmarea persistarii comunicatiei statiilor, adunand informatii privind sesiunile cheilor de autentificare, instaland cheile criptografice si confirmand instalarea lor. Metoda "4-way handshake" este realizata utilizand IEEE 802.1X. Mesajele schimbate in "4-way handshake" sunt in format EAPOL-Key. EAPOL-Key (EAP peste LAN - incapsuleaza mesajele EAP dintre solicitant si autentificator) este definit in IEEE 802.1X pentru a putea fi folosit in schimbul de informatii despre criptarea cheilor. Figura urmatoare descrie cum circula mesajul in "4-way-handshake

Figura 3.4. Exemplu de circulare a mesajelor in stabilirea RSNA

In "4-way hanshake" mai intai autentificatorul trimite un mesaj catre solicitant. Primul mesaj contine informatia cheii si un "Anonce", denumit de asemenea ca materialul cheii, garantat de autentificator ; in "4-way hanshake" acesta nu va fi reutilizat niciodata. In consecinta, RSN pot raspunde atacurilor. Dupa ce s-a primit primul mesaj solicitantul valideaza mesajul prin verificarea campului RC (Replay Counter) din mesaj. RC este o secventa de numere, care va fi incrementata de fiecare mesaj EAPOL-Key. Daca RC este mai mic sau egal cu valoarea retinuta de solicitant, atunci solicitantul reunuta la mesaj. In caz contrar, solicitantul genereaza un "Snonce". Prin utilizarea algoritmului functiei preudo-aleatoare PRF (Pseudo-Random Function) cu "Anonce", "Snonce", PMK (Pairwise Master Key) si alte informatii ca intrari, solicitantul genereaza un PTK (Pairwise Transient Key). Solicitantul trimite inapoi al doilea mesaj continand informatia cheii, "Snonce", RSN IE -ul solicitantului (RSN Information Element) si MIC (Message Integrity Code).

Pana cand se primeste al doilea mesaj, autentificatorul valideaza mesajele verificand RC-ul. Procesul este similar cu cel al solicitantului. Deoarece autentificatorul utilizeaza acelasi algoritm si aceleasi intrari, PTK derivat din autentificator va fi acelasi cu cel din solicitant. Autentificatorul verifica deasemenea MIC. Se renunta la pachet daca MIC nu este validat. In plus, autentificatorul compara RSN IE primit cu cel continut in cererea de asociere/reasociere (Association/reassociation Request) primite anterior de la solicitant. Altffel , autentificatorul trimite un al treilea mesaj catre solicitant.Al treilea mesaj include informatia cheii, "Anonce", MIC si RSN IE-ul autentificatorului. La receptia celui de-al treilea mesaj, solicitantul verifica mai intai mesajul prin campurile RC si "Anonce". Compara apoi RSN IE cu cel receptionat anterior in cadrele "Beacon" si "Probe Response". Solicitantul va disasocia de la AP daca RSN IE-urile sunt diferite. Daca RSN IE este corect, solicitantul verifica in continuare MIC. Solicitantul trimite inapoi al patrulea mesaj catre autentificator daca MIC este valid. Al patrulea mesaj contine informatia cheii si MIC.

Odata ce al patrulea mesaj este receptionat de autentificator, acesta verifica RC-ul ca si anterior ; verifica apoi MIC, daca RC este valid. "4-way handshake" este complet daca MIC este valid. Al patrulea mesaj este utilizat pentru a face cunoscut autentificatorului ca solicitantul a instalat cheia temporara, PTK. PTK este cunoscuta doar de solicitant, autentificator , si serverul de autentificare. Este folosit ca cheie de criptare a datelor.

"Handshake"-ul cu cheie de grup

RSNA defineste deasemenea o cheie de grup pentru comunicare , pentru ca autentificatorul sa trimita catre solicitant GTK (Group Transient Key) astfel incat acesta sa poata primi mesaje de broadcast. Ca si "4-way handshake", mesajele schimbate in comunicarea cu cheie de grup utilizeaza formatul EAPOL-Key (vezi figura 3.4

Dupa cum se indica si in Figura 3.4, "handshake"-ul cu cheie de grup se face dupa "4-way handshake". Autentificatorul trimite mai intai un mesaj care include informatia cheii, MIC, si GTK catre solicitant. GTK este criptat cu ajutorul unei chei de criptare KEK (EAPOL-Key Encryption Key), si MIC este calculat in mesajul EAPOL-Key utilizand confirmarea KCK (EAPOL-Key Confirmation Key). Atat KEK si KCK sunt parte a PTK. Pana cand se primeste mesajul, solicitantul verifica RC. Utilizeaza apoi KCK pentru a verifica MIC. Solicitantul va decripta GTK cu KEK daca RC si MIC sunt valide. Solicitantul configureaza apoi GTK in MAC-ul IEEE 802.11. In plus, raspunde mesajului care include si informatia cheii si MIC, inapoi catre autentificator. In mod similar, autentificatorul valideaza RC si MIC.