Segurança em Redes sem Fio Padrão IEEE802.11i
-
Upload
alexandropastore -
Category
Documents
-
view
1.224 -
download
7
description
Transcript of Segurança em Redes sem Fio Padrão IEEE802.11i
UNIVERSIDADE DE CAXIAS DO SUL PRÓ-REITORIA DE PÓS-GRADUAÇÃO E PESQUISA
CURSO DE ESPECIALIZAÇÃO EM GERENCIAMENTO E SEGURANÇA DE REDES DE COMPUTADORES
Segurança em Redes sem Fio Padrão IEEE802.11i
por Alexandro Pastore http://br.linkedin.com/in/alexandropastore
Caxias do Sul, 11 de Fevereiro de 2008
SEGURANÇA EM REDES SEM FIO PADRÃO IEEE802.11i
Alexandro Pastore
ESTE TRABALHO DE CONCLUSÃO DO CURSO DE ESPECIALIZAÇÃO EM GERENCIAMENTO E SEGURANÇA DE REDES DE COMPUTADORES FOI
APROVADO
_________________________________________ Profa. Dra. Maria de Fátima Webber do Prado Lima
Coordenadora do Curso de Especialização em Gerenciamento e Segurança de Redes de Computadores
CONCEITO FINAL:
COMISSÃO EXAMINADORA:
___________________________________________ Prof. João César Netto, Doutor em Ciências Aplicadas
Orientador do Trabalho de Conclusão
___________________________________________
Professora Maria de Fatima Webber do Prado Lima
___________________________________________
Professor Cristian Koliver
Resumo
Esta dissertação realizou um estudo explanatório sobre os protocolos e técnicas
empregadas na segurança de redes locais sem fio padrão IEEE 802.11 (WLAN – Wireless
Local Area Network). Inicia-se abordando como tema o primeiro protocolo de segurança que
surgiu para WLAN’s, o WEP (Wired Equivalent Privacy). Após dá-se continuidade ao estudo
com ênfase na norma IEEE 802.11i, composta por diversas técnicas e protocolos utilizados
para prover um maior nível de segurança em redes 802.11 e que substitui com propriedade o
obsoleto protocolo WEP. Ao longo do trabalho, os principais problemas relativos a
vulnerabilidades que cada técnica ou protocolo têm são analisados.
Lista de Figuras
Figura 1 – O Vetor de Inicialização ......................................................................................... 14
Figura 2 – As Três Camadas..................................................................................................... 22
Figura 3 – Ilustração do Modelo de Autenticação TLS............................................................ 23
Figura 4 – Formato de Mensagem EAP ................................................................................... 25
Figura 5 – Fluxo de Mensagens da Autenticação ..................................................................... 26
Figura 6 – Formato Básico de uma Mensagem Radius ............................................................ 27
Figura 7 – EAP s/ Radius ......................................................................................................... 27
Figura 8 – As camadas TLS ..................................................................................................... 29
Figura 9 - Handshake ............................................................................................................... 29
Figura 10 - TTLS ...................................................................................................................... 30
Figura 11 – Geração de Chaves Temporais .............................................................................. 31
Figura 12 – Geração das chaves temporais .............................................................................. 34
Figura 13 - Detalhes de um frame RSN-IE .............................................................................. 36
Figura 14 - RC4 usando IV de 48bits ....................................................................................... 38
Figura 15 - Counter Mode ........................................................................................................ 41
Figura 16 – CCMP .................................................................................................................... 42
Figura 17 – Passos no processamento do MPDU ..................................................................... 43
Figura 18 – Cabeçalho CCMP .................................................................................................. 44
Figura 19 – Cifragem e Decifragem CCMP ............................................................................. 44
Figura 20 – Cifragem de bloco CCMP ..................................................................................... 45
Figura 21 – MPDU CCMP ....................................................................................................... 50
Figura 22 – Cifragem CCMP ................................................................................................... 51
Figura 23 – Decifragem CCMP ................................................................................................ 51
Figura 24 – Reconstrução do valor de nonce ........................................................................... 51
Figura 25 – Formatação dos Blocos de Contagem ................................................................... 52
Figura 26 – Reconstrução do Initial Counter ........................................................................... 53
Lista de Diagramas
Diagrama 1 – TKIP Pairwise Key ............................................................................................ 33
Daigrama 2 – TKIP Group Key ................................................................................................ 33
Diagrama 3 – AES Pairwise Key ............................................................................................. 34
Diagrama 4 – AES Group Key ................................................................................................. 34
Diagrama 5 – 4Way Handshake ............................................................................................... 46
Diagrama 6 – Handshake Simplificado .................................................................................... 48
Diagrama 7 – Ataque DoS Handshake ..................................................................................... 48
Lista De Siglas
AES Advanced Encryption Standard
AP Access Point
CBC Cipher Block Chaining
CCMP Counter Mode with Cipher Block Chaining Message Authentication
Code Protocol
DoS Denial Of Service
EAP Extensible Authentication Protocol
EAPOL Extensible Authentication Protocol Over Lans
GMK Group Master Key
GTK Group Transient Key
ICV Integrity Check Value
IEEE Institute of Electrical and Electronics Engineer
IV Initialization Vector
MAC Medium Access Control
MIC Message Integrity Code
MPDU MAC Protocol Data Unit
MSDU MAC Service Data Unit
NIST National Institute for Science and Technology
PAN Personal Area Networks
PMK Pairwise Master Key
PRNG Pseudo Randomic Number Generator
PTK Pair Transient Key
RSN Robust Secure Network
STA Station
SNMP Simple Network Management Protocol
TCS Tkip Sequence Counter
TKIP Temporal Key Integrity Protocol
TMTO Time-Memory Trade Off
TPTK Temporal Pair Transient Key
TSC Tkip Sequence Counter
TTAK Tkip-Mixed Transmit Address And Key
WEP Wired Equivalent Privacy
WLAN Wireless Local Area Network
WMAN Metropolitan Area Networks
WPA WiFi Protected Access
Sumário
Resumo ..................................................................................................................................... 11
Lista de Figuras ........................................................................................................................ 12
Lista de Diagramas ................................................................................................................... 13
Lista De Siglas .......................................................................................................................... 14
Sumário ..................................................................................................................................... 16
Introdução ................................................................................................................................. 10
1. Wired Equivalent Privacy (WEP)......................................................................................... 12
1.1 Autenticação ................................................................................................................... 12 1.2 Privacidade ..................................................................................................................... 13 1.3 O Algoritmo RC4 ........................................................................................................... 13 1.4 O Vetor de Inicialização ................................................................................................. 14 1.5 Chaves WEP ................................................................................................................... 15 1.6 A Cifragem RC4 ............................................................................................................. 15 1.7 Porque o WEP não é Seguro ........................................................................................... 16
2. Uma Conexão Segura ........................................................................................................... 17
2.1 Autenticação ................................................................................................................... 17 2.2 Controle de Acesso ......................................................................................................... 18 2.3 Prevenção de Replay ...................................................................................................... 18 2.4 Detecção de Modificação de Mensagens........................................................................ 18 2.5 Privacidade de Mensagens.............................................................................................. 19
3. O que é IEEE 802.11i ........................................................................................................... 20
3.1 WPA ............................................................................................................................... 20 3.2 Chaves ............................................................................................................................ 21 3.3 Camadas de Segurança ................................................................................................... 21
4. Controle de Acesso – IEEE 802.1x, EAP e Radius .............................................................. 24
4.1 EAP ................................................................................................................................. 25 4.2 EAPOL ........................................................................................................................... 25 4.3 Radius ............................................................................................................................. 26
5. Uso de Chaves no Processo de Autenticação ....................................................................... 28
5.1 Transport Layer Security – TLS ..................................................................................... 28 5.2 TLS Handshake sobre EAP ............................................................................................ 29
6. Hierarquia de Chaves............................................................................................................ 31
6.1 The Four-Way Exchange ................................................................................................ 32
6.2 Chaves Broadcast e Multicast......................................................................................... 32 6.3 Como são Geradas as Chaves Temporais ....................................................................... 34 6.4 Robust Secure Network (RSN) ....................................................................................... 35
7. TKIP ..................................................................................................................................... 37
7.1 Integridade de Mensagens .............................................................................................. 37 7.2 Seleção e Uso do IV ....................................................................................................... 38 7.3 TSC (Tkip Sequence Counter) ....................................................................................... 39
8. AES-CCMP .......................................................................................................................... 40
8.1 Modo de Operação .......................................................................................................... 41 8.2 Counter Mode + CBC MAC : CCM ............................................................................... 42 8.3 O Cabeçalho CCMP ....................................................................................................... 43 8.4 A implementação ............................................................................................................ 44
9. Vulnerabilidades do 802.11i ................................................................................................. 46
9.1 Vulnerabilidade 4-Way Handshake ................................................................................ 46 9.1.1 Análise dos Campos Utilizados no Handshake ....................................................... 47 9.1.2 O Ataque DoS .......................................................................................................... 48
9.2 Vulnerabilidade do Protocolo CCMP ............................................................................. 50
9.2.1 Reconstrução do Valor Nonce ................................................................................. 51 9.2.2 Reconstrução do Initial Counter .............................................................................. 52
9.3 O Ataque Time-Memory Trade Off (TMTO) ................................................................ 53
Conclusão ................................................................................................................................. 55
Referência Bibliográfica ........................................................................................................... 57
10
Introdução
A mobilidade é um tema que está cada vem mais em voga. As pessoas querem cada
vez mais ter acesso às informações em qualquer lugar e a qualquer momento. O número
crescente de dispositivos móveis e a popularização destes traduzem o crescente anseio pela
mobilidade.
A tecnologia para transmissão de informações por meios sem fio tem evoluído muito
nos últimos anos, proporcionando maiores velocidades de transmissão e maiores alcances,
com menos erros. Com tudo isso, aplicações que até pouco tempo atrás eram inviáveis para
transmissões sem fio, pois demandavam maior largura de banda para sua transmissão, a
exemplo de aplicações Multimídia, cresceram e muito.
Estas tecnologias para transmissão de dados sem fio se classificam principalmente
pela abrangência ou área de cobertura. No caso de transmissões para pequenas áreas de
cobertura ou PANs (Personal Area Networks), como exemplo podemos citar a tecnologia
regida pela norma IEEE 802.15 e popularmente conhecida por Bluetooth. Já em áreas de
abrangência metropolitana ou WMANs (Wireless Metropolitan Area Networks), a tecnologia
é a que segue o padrão IEEE 802.16 e é popularmente conhecida pelo nome dado pelo
consórcio de empresas fabricantes de equipamentos deste tipo, o Wi-MAX. Este trabalho
analisa pontos fortes e fracos relativos a segurança em redes de cobertura local, as WLANs
(Wireless Local Area Network). A transmissão deste tipo de cobertura é padronizada pela
norma IEEE 802.11 e o nome popular para redes deste tipo também foi criado pelo consórcio
de empresas fabricantes de produtos para esta tecnologia, conhecido por WiFi.
Um dos maiores empecilhos para o contínuo crescimento e popularização das redes
sem fio é a questão de segurança. Numa rede convencional “cabeada”, para ter-se acesso às
informações, obrigatoriamente há a necessidade de se estar conectado fisicamente à rede
física. Mas quando se trata de redes sem fio, onde a informação trafega pelo “ar”, ela se torna
disponível a qualquer um que esteja dentro do seu alcance.
Inicialmente a norma IEEE 802.11 trabalhou a questão de segurança de redes
WLAN com o protocolo WEP (Wireless Equivalency Protocol) com chave de 64 bits , o qual
usa o algoritmo de criptografia RC4. Porém o protocolo se mostrou altamente vulnerável a
ataques de força bruta, pois a chave usada pelo protocolo usa um algoritmo relativamente
fraco e parte da chave usada é constante. Numa tentativa de diminuir as vulnerabilidades, os
11
fabricantes acabaram criando soluções paliativas, como os usos de WEP com chaves maiores
e o uso de outro protocolo, o WPA. Isso até que o IEEE criasse um outro protocolo padrão e
definitivo que guiasse todos os fabricantes para a mesma direção.
Em julho de 2004 o IEEE finalmente homologou o padrão que tornaria uma rede
WLAN muito mais segura, o IEEE 802.11i. Esta norma baseia-se em um conjunto de
protocolos integrados para prover segurança em vários níveis, como o controle de acesso ao
meio e a garantia de confidencialidade e integridade das informações trocadas entre as
entidades envolvidas numa conexão.
12
1. Wired Equivalent Privacy (WEP)
WEP (Wired Equivalent Privacy/Privacidade Equivatente à Redes Cabeadas) foi o
protocolo criado originalmente na norma IEEE 802.11 de WLAN’s (Wireless Local Área
Network / Redes Locais sem Fio) para prover segurança, e seu foco era prover segurança
tanto ao nível de autenticação, ou seja, ter um controle de quem pode ou não acessar a rede,
quanto aos aspéctos de privacidade, tornando os dados trafegados inelegíveis para os demais,
exceto aos que compartilham a mesma chave de sessão, das quatro que podem estar
disponíveis.
Infelizmente com o tempo o protocolo acabou mostrando suas franquezas, como
veremos mais adiante, e muitos softwares de quebra de senha WEP foram surgindo,
mostrando assim que realmente o protocolo se mostrava ineficaz para cumprir com o seu
objetivo. Claro que, é melhor usar o WEP do que não usar nenhum mecanismo de segurança.
Porém, como o protocolo se mostrou altamente vulnerável, a popularização de WLANs em
ambientes mais sérios, como empresas, acabou sendo retardada.
1.1 Autenticação
Existem duas partes da segurança WEP descritos na norma. A primeira refere-se a
fase de autenticação e a segunda refere-se a fase de cifragem. Basicamente a idéia é, quando
um dispositivo deseja acessar um AP (Access Point/Ponto de Acesso), uma espécie de
gateway/roteador responsável por interligar os dispositivos móveis ou liga-los à outras redes,
primeiramente ele deverá provar a sua identidade. Aqui está a primeira falha do WEP.
Apenas o dispositivo móvel precisa provar sua identidade, o AP não, quando na verdade,
ambos deveriam obrigatoriamente fazer tal prova.
A norma 802.11 define basicamente três tipos de mensagens para troca de
informações entre STA (Stations/Estações Clientes) e os AP’s. São elas, mensagens de
controle, de gerenciamento e de dados. A fase de autenticação usa basicamente mensagens do
tipo gerenciamento e ocorrem quatro trocas de mensagens deste tipo, a saber:
13
1. STA requisita autenticação;
2. AP solicita resposta a um desafio p/ que STA prove estar autorizado;
3. STA responde ao desafio do AP;
4. AP autoriza ou não STA a ingressar em sua rede;
O desafio aqui é provar ao AP que o requisitante de ingresso conhece a chave
secreta. Como isto é feito:
O AP envia à STA um número randômico chamado “challenge text”, que é um
número arbitrário de 128-bits. A STA então cifra este número com a sua chave secreta e o
enviar de volta ao AP. Se a resposta vier corretamente cifrada com a chave, o ingresso à rede
será permitido. Aqui está mais uma vulnerabilidade do WEP, pois um atacante pode
introduzir-se no meio desta negociação, copiar a mensagem de resposta e fazer-se passar pela
STA requisitante. Ou também, um atacante pode fazer-se passar por um AP sem saber a chave
secreta, pode enviar o desafio em plain text à STA e aguardar a resposta cifrada com a chave.
1.2 Privacidade
Eis aqui o que muitos consideram a questão mais importante e o principal quesito de
segurança numa rede sem fio. O objetivo é, tornar inelegível aos outros, a sua troca de dados
com o AP, mantendo assim o sigilo das informações.
1.3 O Algoritmo RC4
Bem, como visto anteriormente, o protocolo WEP usa uma chave secreta do tipo
síncrona, ou seja, a mesma chave é usada tanto para cifrar quanto para decifrar uma
informação. Ou seja, tanto o dispositivo móvel quanto os AP’s devem conhecer e usar a
mesma chave.
Sistemas de segurança baseam-se normalmente em dois tipos métodos de cifragem,
cifragem de bloco (block ciphers) ou cigragem de fluxo (stream ciphers). Na cifragem de
fluxo, os dados vão sendo cifrados continuamente, um após o outro. Já no processo de
cifragem por bloco, o sistema aguarda os dados até formarem o tamanho definido do bloco,
14
então o sistema cifra o bloco e começa novamente até formar um novo bloco. O WEP usa o
sistema de fluxo, usando o algoritmo de criptografia RC4. Ou seja, um byte entra e outro byte
saí cifrado, codificado. A escolha do RC4 foi feita por ser um algoritmo simples de ser
implementado e que consome pouco recurso de processamento, pois não utiliza operações
mais complexas como a multiplicação. No RC4 existem duas fases, a primeira é a de
inicialização, onde algumas tabelas internas são populadas de acordo com a chave utilizada. E
a segunda fase é onde os dados são realmente transformados, a medida que passam pelas
tabelas inicializadas e terminam então criptografados. No caso do WEP, cada pacote
‘inputado’ sofre a execução das duas fases, inicialização e cifragem, tornando assim cada
pacote independente da cifragrem dos anteriores.
1.4 O Vetor de Inicialização
Originalmente, a norma 802.11 previu uma chave com tamanho de 40 bits. Bem,
porque 40 e não 64 bits? Bom, a diferença de 64 para 40 é justamente o tamanho do vetor de
inicialização (IV – Initialization Vector) usado no protocolo, ou seja, 24 bits. Para que a chave
usada não fosse constante, o que facilitaria a coleta de dados para utilização de força bruta
para descoberta da chave, usou-se o artifício do vetor de inicialização. A idéia é relativamente
simples, para se criptografar um dado, usa-se a concatenação do IV mais a chave para
produzir o dado cifrado. Como o IV sempre altera de byte para byte, um mesmo dado cifrado
irá gerar diferentes resultados, dificultando um pouco o trabalho de um atacante. O porém é
que o IV passa de forma aberta de uma entidade à outra, aumentando a vulnerabilidade do
processo. Como o vetor tem apenas 24 bits de tamanho, é impossível que seu valor não se
repita em algumas horas de conversação com um AP.
Figura 1 – O Vetor de Inicialização
15
1.5 Chaves WEP
A chave Wep tem as seguintes características:
1. Tamanho fixo: normalmente entre 40 e 104 bits;
2. Estática: a chave não se altera, exceto no caso de reconfiguração;
3. Compartilhada: tanto os access points quanto os dispositivos que a eles se
conectam usam a mesma chave;
4. Simétrica: a mesma chave usada para cifrar, é usada para decifrar;
Por ser estática, uma alteração de chave pode acarretar um grande trabalho,
dependendo do número de estações a serem configuradas, tornando inviável a constante
alteração da mesma em grandes ambientes que possuam centenas de estações móveis.
A norma possibilita a definição de até quatro (4) chaves Wep nos AP’s. Isto abre a
possibilidade de utilizar-se a distribuição das chaves de duas formas: ou todos todas STA
usam a mesma chave, ou pode-se distribuir diferentes chaves para cada conjunto de STA’s,
até quatro grupos distintos.
1.6 A Cifragem RC4
O RC4 é um algoritmo de cifragem proprietário do tipo stream que foi desenvolvido
em 1987. Porém o algoritmo sofreu engenharia reversa em 1994 e acabou tornando-se público
anonimamente desde então.
A idéia básica do algoritmo é gerar uma seqüência pseudo-randômica de bytes
chamada ‘key stream’ que é combinada com os dados usando-se a operação lógica de XOR.
Uma importante característica do XOR é que quando se aplica o mesmo valor duas vezes, o
valor original é obtido.
Existem duas fases no RC4: a fase de key setup, onde uma cadeia de 256 bytes é
criada com a permutação de números de 0-255; isto é, todos os números estão presentes na
cadeia, porém de forma desordenada e aleatória. Depois disso, a fase seguinte é a da geração
do pseudorandômico. Essa fase envolve mais troca de bytes na cadeia gerada pela fase
16
anterior para gerar então um byte de interação (R). Assim, a cada byte a ser cifrado, é
aplicado o XOR com (R).
1.7 Porque o WEP não é Seguro
O protocolo WEP foi incluído no IEEE 802.11 padrão em 1997, mas só a partir de
1999 ele foi amplamente implementado nos equipamentos de rede, e muitos fabricantes já
estavam ampliando o suporte aumentando o tamanho de chave para 104 bits. Muitos usuários
já começavam a formar opiniões restritivas ao WEP, principalmente ao modo inseguro de
autenticação do protocolo. Em 2001 foi publicado um ataque, mostrando que independente do
tamanho da chave, numa rede com tráfego pesado, em algumas horas era possível descobrir a
chave.
17
2. Uma Conexão Segura
Abaixo, destaco quais são os principais mecanismos de segurança a se considerar
para uma rede ser considerada segura:
• Autenticação;
• Controle de Acesso;
• Prevenção de replay;
• Detecção de modificação de mensagens;
• Privacidade de mensagens;
• Proteção à chave;
2.1 Autenticação
O processo de autenticação se resume em cada parte provar à contra parte
(autenticação mútua) ser quem realmente ele se diz ser. O processo de autenticação não é um
processo que deva ocorrer uma única vez, no início da conversação. O ideal é que a prova
aconteça sempre que houver troca de mensagens. Como a autenticação é um processo em
geral oneroso, no princípio, este processo ocorre em modo completo (full), mas a partir daí,
bastará às partes envolvidas manterem em suas próximas mensagens, a identificação que lhes
concedeu acesso à rede, evitanto desta forma ataques como os denominados spoofing (método
usado para forjar identidade).
Finalmente, uma outra premissa para que uma autenticação seja considerada
fortemente segura, é que a chave usada no processo de autenticação seja diferente da chave a
ser usada posteriormente para criptografia dos dados (privacidade).
Portanto, podemos resumir um processo de autenticação como fortemente seguro se:
1. O método de prova de identidade for imune a técnicas de spoofing;
2. A identidade for preservada e mantida ao longo de toda a comunicação até
que a mesma seja finalizada;
18
3. For um processo de identificação mútuo;
4. As chaves usadas no processo de identificação forem sempre diferentes das
usadas para criptografia dos dados;
2.2 Controle de Acesso
O controle de acesso é o processo que permite ou nega a comunicação de um
dispositivo à rede. Em geral o controle de acesso é feito através da verificação de uma lista de
dispositivos que possuem acesso permitido à rede. A identificação de um dispositivo só pode
ser feita através de seu endereço MAC. Como esse endereço é passível de ser forjado, esse
tipo de controle é considerado dispensável e geralmente a identificação cumpre muito melhor
este papel.
2.3 Prevenção de Replay
A prevenção de replay usa técnicas que evitem que, se alguém capturar todo tráfego
previamente usado numa comunicação entre (A) e (B), possa ser reutilizado posteriormente
por qualquer outra entidade, seja ela (A), (B) ou um terceiro (C). Infelizmente o protocolo
WEP não implementa qualquer tipo de técnica para prevenção de replay.
2.4 Detecção de Modificação de Mensagens
A utilização de técnicas para modificar mensagens, ou seja, trocar o seu conteúdo
original sem que o receptor ou o remetente percebam tal alteração, são realmente difíceis de
serem implementadas. Se você não for capaz de decifrar uma mensagem, obviamente será
totalmente incapaz de alterá-la de forma a mantê-la ainda íntegra e legível. Normalmente a
integridade de dados é verificada através de mecanismos de checksum, cujo qual, também é
cifrado juntamente com os demais dados. Portanto, sem o conhecimento da chave de
criptografia, a alteração da mensagem torna-se muito difícil, certo? Difícil sim, mas não
impossível. Como os métodos de check são geralmente lineares, pode-se deduzir que bits de
19
check serão alterados se um bit da mensagem for alterado. Infelizmente como o WEP usa
técnicas de XOR no seu algoritmo de criptografia, a troca de um bit na área de dados não
cifrados também alterará o mesmo bit de dados cifrados, e vice-versa.
2.5 Privacidade de Mensagens
Este é considerado o mais importante quesito de segurança, se todos os itens
anteriores forem quebrados, mas este item não, o atacante estará bastante limitado. Porém se
este item for quebrado, podemos dizer que o atacante está dentro ‘de casa’. Existem
basicamente dois objetivos básicos em ataques de criptografia, decodificar mensagens e
descobrir a chave secreta. De posse da chave, o atacante estará livre para explorar outras
vulnerabilidades, porém, isso não significa acesso total e irrestrito a todas as informações,
pois poderá haver outros níveis de segurança, como os provido por sistemas operacionais etc.
A descoberta da chave também abrirá a possibilidade de ataques de modificação e replay de
mensagens.
20
3. O que é IEEE 802.11i
IEEE 802.11i define um novo padrão de segurança para redes locais sem fio
(WLANs) chamado Robust Security Network (RSN). Para se conectar a uma rede RSN, um
dispositivo necessitará ter uma série de novas capacidades, como veremos mais adiante.
Como essa nova norma exige uma série de implementações, não suportadas pelo legado de
equipamentos WEP, uma solução paliativa foi criada para servir de ponte entre o WEP e os
novos equipamentos que estão surgindo com suporte ao RSN, o WPA.
3.1 WPA
O WPA (Wi-Fi Protected Access) foi criado pela aliança de fabricantes de
equipamentos para redes sem fio chamada Wi-Fi como uma solução temporária à falta de
segurança do WEP, até que o 802.11i fosse finalizado e implementado em larga escala pelos
fabricantes em seus equipamentos para redes sem fio. Foi uma solução que não exigia troca
de hardware e sim apenas upgrade de software, pois o algoritmo usado ainda é o RC4, mas
com um novo enfoque, através do protocolo Temporal Key Integrity Protocol (TKIP).
O WPA tem suporte a dois métodos de autenticação e gerenciamento de chaves. O
primeiro é o suporte à autenticação EAP com protocolo 802.1x standard, método que faz uso
de um servidor em separado, denominado RADIUS server, para autenticar de forma segura
um dispositivo requerente de acesso à rede (suplicante). O outro método é o de pré-
compartilhamento de chaves, como no usado pelo WEP. Mas para não ter os mesmos
problemas de falta de segurança que o WEP tem no uso de chaves compartilhadas, o WPA
usa um método que cria uma chave única de sessão para cada dispositivo conectado à rede.
Isso é feito usando-se uma pré-chave chamada GMK (Group Master Key) que carrega um par
de chaves transientes chamada PTK (Pair Transient Key). Este segundo método foi criado
com o intuito de oferecer suporte a pequenas redes, onde dificilmente há todos os requisitos
que o protocolo 802.1x exige.
21
Por padrão, o WPA assume como técnica de cifragem o TKIP, mas também provê
suporte ao uso do AES (Advanced Encryption Standard).
3.2 Chaves
Segurança baseia-se fortemente em chaves secretas. O contexto de segurança de
uma rede RSN se define pela posse de chaves com tempo de vida finito. Há toda uma
hierarquia de chaves, onde muitas das chaves só são conhecidas depois que o processo de
autenticação tenha sido completado. Como são chaves criadas em tempo de execução, são
conhecidas por “chaves temporais”. Estas chaves sofrem atualizações de tempos em tempos e
são completamente destruídas quando a comunicação é encerrada.
Uma chave é basicamente uma informação compartilhada entre duas ou mais partes,
e sua funcionalidade só se mantém enquanto ela for secreta para apenas estas partes.
Chaves são usadas de duas formas, serve para provar uma identidade, e também para
se ter acesso a alguns serviços, como exemplo, a chave de um carro.
A autenticação é baseada em informações secretas compartilhadas que não podem
ser criadas automaticamente. Uma chave de autenticação tem que ser previamente criada por
alguma entidade de confiança e guardada de forma severamente segura. A entidade a ser
autenticada deverá então possuir um informação especial, a denominada “master key”. Esta
chave deverá ter mecanismos muito eficientes para proteger o seu conteúdo. Portanto, uma
“master key” deve ter seu uso minimizado ao máximo. Ela será usada para criar outras chaves
temporais.
3.3 Camadas de Segurança
Em redes sem fio, três níveis estão claramente definidos:
1. Wireless Lan Layer
2. Access Control Layer
3. Authentication Layer
22
A função da camada Wireless lan Layer é negociar compatibilidades e aceitar que
aplicações se conectem à rede. Também é esta camada a responsável por cifrar e decifrar
dados. Ou seja, é a camada que faz o trabalho pesado.
O Access Control Layer é a camada que gerencia o meio. Seu papel é gerenciar o
contexto de segurança, e deverá barrar qualquer dado de quem não tenha autorização para
trafegar. Esta camada também participa na criação das chaves temporais.
O nível de camada mais importante e robusto é a de Authentication Layer. A ele
cabem tomadas de decisões quanto a identidades serem aceitas ou rejeitadas pelo sistema.
Figura 2 – As Três Camadas
Como camada de controle de acesso numa rede RSN, foi eleito, o já muito bem
aceito protocolo definido pelo IEEE, 802.1x.
Quanto a camada de autenticação, o IEEE deixou a opção em aberto, pois há muitos
protocolos bons para tal finalidade, e o Instituto optou então por deixar esta negociação livre.
23
Figura 3 – Ilustração do Modelo de Autenticação TLS
24
4. Controle de Acesso – IEEE 802.1x, EAP e Radius
O controle de acesso é um dos mais importantes elementos de segurança,
principalmente em se tratando de uma rede sem fio. O 802.1x é o mecanismo que permitirá
apenas o tráfego de mensagens de autenticação pela rede, enquanto a autenticação não for
completa.
Há três elementos básicos a saber, quando falamos de controle de acesso:
1. Suplicante: é a entidade que solicita acesso ao meio;
2. Autenticador: é a entidade que controla a porta de acesso, permitindo ou não ao
suplicante o acesso a rede, dependendo do que o ‘autorizador’ decidir;
3. ‘Autorizador ’: é a entidade que decide se o suplicante terá ou não acesso;
O processo ocorre da seguinte forma:
1. O autenticador é alertado pelo suplicante que requisita acesso;
2. O suplicante se identifica;
3. O autenticador requisita autorização ao ‘autorizador’;
4. O ‘autorizador’ indica SIM ou NÃO;
5. O autenticador libera ou não o acesso do suplicante;
A norma IEEE 802.1x foi originalmente concebida para redes ‘cabeadas’, pois seu
controle de acesso ocorre nas portas dos switches. Posteriormente a tecnologia teve seu uso
ampliado também para redes sem fio.
Para que a confidencialidade da autenticação ocorra de forma segura, antes de
qualquer troca de informação sobre a autenticação entre o suplicante e o autenticador, deverá
haver uma negociação de chaves, transformando assim o conteúdo da troca de mensagens
secreto, apenas conhecido pelas duas entidades.
25
4.1 EAP
O EAP é o protocolo responsável por tornar possível a conversação entre o
suplicante e o autenticador. Ele faz o intercâmbio entre as duas entidades, permitindo a
escolha na negociação de que técnica será utilizada na comunicação. Por ser muito versátil
nesta negociação, já que muitos protocolos de autenticação rodam sobre EAP, é que ele foi
escolhido! Por sua simplicidade, quatro tipos básicos (códigos) de mensagens podem ser
enviadas através dele:
• Request usado p/ enviar mensagens do autenticador ao suplicante;
• Response usado para enviar mensagens do suplicante ao autenticador;
• Success enviado pelo autenticador p/ indicar que o acesso foi concedido;
• Failure enviado pelo autenticador p/ indicar que o acesso foi recusado;
Figura 4 – Formato de Mensagem EAP
O identificador é um valor de 0-255, e pode ser incrementado para cada mensagem
enviada. Quando voltar uma resposta, ela voltará com o mesmo número de identificador que
foi gerado pela requisição. O campo length informa o tamanho total da mensagem.
4.2 EAPOL
Como o EAP foi concebido para ser usado em redes dial-up, o IEEE criou o EAPOL
(EAP over LAN), que é a adaptação do EAP para redes 802. O comitê 802.1x aperfeiçoou-o,
adicionando mais alguns tipos de mensagens com finalidades administrativas. Os cinco tipos
de mensagens são:
• EAPOL start: o replicante envia via multicast p/ localizar algum autenticador disponível;
• EAPOL key: usado para a troca de chaves a serem usadas na criptografia do processo de
autenticação;
• EAPOL packet: usado para transportar as mensagens EAP;
26
• EAPOL logoff: usado pelo suplicante p/ requisitar desconexão;
• EAPOL encapsulated ASF Alert: usado para tráfego de traps SNMP (Simple Network
Management Protocol);
Pelo gráfico abaixo, podemos ter uma idéia clara de como ocorrem as seqüências de
mensagens EAP entre as três partes envolvidas, replicante, autenticador e autorizador.
Figura 5 – Fluxo de Mensagens da Autenticação
4.3 Radius
Apesar do Radius (RFC 2865) não fazer parte do IEEE 802.11i, ele é um protocolo
de comunicação para autenticação sobre redes TCP/IP largamente utilizada em redes 802.1x.
Existe uma RFC específica para EAP sobre Radius, a RFC 3579.
Há quatro tipos de mensagens relevantes:
• Access Request (NAS > AS)
• Access Challenge (NAS < AS)
• Access Accept (NAS < AS)
• Access Reject (NAS < AS)
NAS = Access Point
AS = Servidor de Autenticação
27
Figura 6 – Formato Básico de uma Mensagem Radius
Para estender o uso do Radius com EAP, fez-se necessário a utilização do campo de
atributos do Radius. As mensagens EAP são enviadas usando o atributo de valor 79.
Figura 7 – EAP s/ Radius
28
5. Uso de Chaves no Processo de Autenticação
A autenticação faz parte do processo de criar um contexto de segurança na
comunicação, e por ser um processo relativamente oneroso, é comum a autenticação principal
ocorrer apenas na negociação inicial da comunicação e após isto, tokens são criados para que
haja provas de autenticação nas transações posteriores, evitando assim que todo o processo
completo tenha que ocorrer inúmeras vezes.
Chaves podem ser simétricas ou assimétricas. Como já citado anteriormente, chaves
simétricas são aquelas que, a mesma chave serve para cifrar e decifrar mensagens, são
conhecidas como “chaves secretas”. Chaves assimétricas, conhecidas por “chaves públicas”,
consistem num par de chaves afins, e o que a chave A cifra, só pode ser decifrada pelo seu par
A’ e vice-versa. Conceitua-se uma de chave pública e a outra a chave privada. Suponhamos
que X contem a chave pública de Y, X poderá então enviar mensagens à Y e somente Y
poderá decifrá-la. De outra forma, Y poderá enviar mensagens cifradas para X com sua chave
privada, e se X conseguir decifrá-las com a chave pública de Y, terá certeza que a mensagem
vem realmente de Y. O único problema é ter certeza de que a chave pública de Y, é realmente
dele. Aqui entra um terceiro elemento, uma autoridade de certificado, que deve ser 100%
confiável e que terá o papel de guardar e fornecer a quem solicitar, a chave pública de Y.
Em geral, uso de chaves simétricas e assimétricas têm seu uso combinado,
principalmente porque, as chaves assimétricas são bem mais onerosas em termo de
processamento que as chaves simétricas. Pode-se usar chaves públicas para criar-se um
contexto de comunicação seguro e depois então fazer-se a troca das chaves secretas para
utilizá-las posteriormente nas cifragens das mensagens subseqüentes.
5.1 Transport Layer Security – TLS
A especificação completa do TLS fornece uma enorme gama de funcionalidades,
como autenticação, criptografia e compressão. Porém em redes sem fio RSN, apenas a parte
de autenticação é usada. O TLS é dividido em duas camadas: record protocol e handshake
29
protocol. O record protocol é responsável por codificar os dados de acordo com os
parâmetros que foram negociados pelo handshake protocol.
Figura 8 – As camadas TLS
5.2 TLS Handshake sobre EAP
A conexão entre duas partes via TLS é estabelecida no processo de handshake. Em
redes 802.11i, as funções de criptografia utilizadas (TKIP ou AES-CCMP) ocorrem somente
entre o access point e o dispositivo móvel. Já o processo de handshake TLS ocorre entre o
servidor de autenticação e o dispositivo móvel. A principal função do TLS em redes RSN é
prover a autenticação através de um canal de comunicação seguro, formado pela troca de
chaves públicas das duas partes envolvidas no processo, o cliente que é o dispositivo móvel e
o servidor de autenticação.
O processo envolve uma séria de troca de mensagens entre as duas partes, conforme
podemos ver na figura a seguir.
Figura 9 - Handshake
30
1. (request) Servidor de autenticação solicita a identificação do cliente;
2. (response) Aqui o cliente informa quem está com seu certificado ou se identifica como
anônimo;
3. (request) Servidor inicia processo TLS;
4. (response) O Cliente envia um HELLO contento um conjunto de informações como a lista
de algoritmos de cifragem suportadas por ele;
5. (request) O servidor envia o seu HELLO, e opcionalmente a resposta do pedido de
certificado para o cliente;
6. (response) Aqui várias informações são passadas, como o certificado do cliente (se
solicitada), uma chave secreta pré-master e o algoritmo escolhido;
7. (request) O servidor envia o resto das mensagens em um único request;
8. (response) O cliente apenas responde ao servidor sem dados, uma espécie de ACK;
9. Aqui finalmente o servidor envia uma mensagem informando se a autenticação obteve ou
não sucesso;
O inconveniente do TLS é que ambas as entidades, cliente e servidor precisam
possuir um certificado digital, o que torna mais onerosa a solução. Como solução, surgiu o
TTLS (Tunnel Transport Layer Security), que não exige certificado do cliente, apenas do
servidor de autenticação. Neste caso, o servidor constrói um túnel seguro com o cliente
usando a sua estrutura de chave assimétrica e depois então permite que o cliente passe
informações de identificação dentro deste túnel usando outros métodos de autenticação como
CHAP, PAP, etc... Na figura a seguir podemos ver a seqüência de mensagens trocadas num
modelo TTLS.
Figura 10 - TTLS
31
6. Hierarquia de Chaves
A chave mestre PMK (Pairwise Master Key) é gerada na fase de autenticação,
dentro do canal seguro. O método de autenticação que gera tal chave é chamado de “key-
generating” e esta chave é única para cada cliente que forma o par de comunicação com o
servidor de autenticação. Esta chave é usada em fase posterior para derivar as demais chaves.
A norma 802.11i exige que a PMK tenha o tamanho de 256 bits. O número de chaves a gerar
serão quatro, pois serão usadas para proteger o EAPOL handshake e os dados dos usuários,
tanto a nível de cifragem quanto a nível de integridade de dados. São elas:
• Data Encryption key (128 bits)
• Data Integrity key (128 bits)
• EAPOL-Key Encryption key (128 bits)
• EAPOL-Key Integrity key (128 bits)
Estas chaves são conhecidas como temporal keys, pois são re-geradas a cada nova
associação dos dispositivos móveis aos AP’s e por isso, evitam ataques tipo replay. A estas
chaves denomina-se “ ” (PTK).
Figura 11 – Geração de Chaves Temporais
Existe um valor arbitrário gerado para usar no cálculo das chaves, conhecido por
“nonce”, e este valor nunca se repete para a mesma chave.
A geração das chaves temporais é um processo que ocorre em quatro passos, e é
conhecido por “four-way exchange” ou “four-way handshake”. Este processo ocorre entre o
dispositivo móvel e o AP.
32
6.1 The Four-Way Exchange
Por convenção, usaremos a sigla A de autenticador para o access point e S de
suplicante para o dispositivo móvel.
O primeiro passo consiste em o A e S gerarem seus valores de nonce,
respectivamente Anonce e Snonce. Em seguida ocorre a troca de quatro mensagens.
1. A>S: Mensagens EAPOL de A para S informando o valor de Anonce. Uma vez
que S sabe os valores de Nonce(S), MAC(S), Nonce(A), MAC(A) e PMK, ele já
tem todos os dados necessários para gerar as quatro temporal keys;
2. S>A: S informa à A o valor de Snonce; Metade do processo está completo, e
como resultado, as quatro chaves temporais estão geradas em ambos os lados;
3. A>S: A informa à S que está pronto para trocar mensagens cifradas com as
chaves geradas;
4. S>A: S informa à A que recebeu sua mensagem (3) e a partir de então também
criptografará suas mensagens com as chaves geradas;
Resumindo dos passos:
1) Os valores de Anonce e Snonce são trocados;
2) Chaves temporais são calculadas;
3) Suplicante prova ter conhecimento de PMK;
4) Autenticador prova ter conhecimento de PMK;
5) Ambos (A e S) sincronizam-se e cifram pacotes unicast entre eles;
6.2 Chaves Broadcast e Multicast
Em redes 802.11, mensagens broadcast (mensagens direcionadas à todos os
dispositivos da rede) e multicast (mensagens direcionadas à um grupo específico de
dispositivos da rede) também são permitidas, porém os dispositivos móveis não podem enviar
este tipo de mensagens diretamente aos outros dispositivos móveis. Para tal, a mensagem
deverá ser direcionada ao access point e esse por sua vez irá replicar aos demais. Como cada
par formado por dispositivo móvel e access point possui chaves diferentes, não é possível
33
usar estas chaves para mensagens em multicast e broadcast. Para este caso, existe uma outra
estrutura de chaves especiais para esta finalidade, as chaves de grupo ou group keys. As group
keys são chaves compartilhadas por todos os dispositivos conectados ao access point, o que
permite a decifragem de mensagens recebidas por broadcast e multicast por todos
dispositivos conectados àquele access point. As chaves de grupo somente são enviadas depois
que as chaves que as chaves pairwise já tiverem sido contextualizadas, o que facilita o
processo. A distribuição de chaves de grupo são distribuídas pelo access point através dos
seguintes passos:
1. Uma chave de 256 bits GMK (Group Master Key) é criada;
2. É calculado o valor da chave GTK (Group Transiente Key), cuja qual derivará o grupo de
chaves temporais;
3. A chave GTK é enviada para o dispositivo móvel;
A seguir os diagramas resumo da hierarquia de chaves usadas:
Diagrama 1 – TKIP Pairwise Key
Daigrama 2 – TKIP Group Key
34
Diagrama 3 – AES Pairwise Key
Diagrama 4 – AES Group Key
6.3 Como são Geradas as Chaves Temporais
Como citado anteriormente, as chaves temporais são derivadas das chaves mestres.
Como as master keys têm 256 bits, o processo deverá expandi-la para 512 bits e então derivar
as quatro chaves temporais de 128 bits cada. Neste processo usa-se o chamado “gerador de
números pseudo-randômico” ou PRNG. Umas das informações utilizadas na semente de
inicialização do processo é justamente a master key, como podemos verificar na figura 12.
Figura 12 – Geração das chaves temporais
A função PRNG é utilizada em várias etapas, inclusive para gerar os valores nonce e
o GTK. Para tal, foi criado uma série de funções chamadas PRF’s. Cada qual tem o intuito de
35
gerar um número X de bits resultantes. PRF-128 por exemplo, gerará um resultado de 128
bits. Cada função precisa receber três parâmetros.
Seguem alguns exemplos de uso:
Nonce = PRF-256(Random Number, "Init Counter", MAC || Time)
Pairwise Temporal Keys = PRF-512(PMK, "Pairwise key expansion", MAC1||MAC2||Nonce1||Nonce2)
Group Pairwise Temporal keys = PRF-256(GMK, "Group key expansion", MAC||GNonce)
O algoritmo de hash usado na implementação destas funções é o HMAC-SHA-1.
Como todo algoritmo de hash, a entrada de uma cadeia de dados produz como saída outra
cadeia de tamanho fixo (20 bytes no caso deste algoritmo) e não há função de retorno que
aplicada sobre o resultado, retorne o valor original. Se um bit de dados for alterado na cadeia
de entrada, a cadeia de dados resultante será completamente diferente. Como 20 bytes ou 160
bits podem não ser suficientes dependendo da finalidade do número a ser gerado, será
necessário mais interações para que se chegue ao número de bits desejados, descartando assim
o que exceder o necessário.
6.4 Robust Secure Network (RSN)
RSN foi criado como parte da norma 802.11i e especifica a autenticação pelo IEEE
802.1x e a criptografia dos dados através do TKIP (Temporal Key Integrity Protocol) ou pelo
CCMP (Counter Mode with CBC-MAC Protocol). RSN usa TKIP ou AES como métodos de
criptografia para proteger a confidencialidade dos dados. TKIP foi incluído para manter
compatibilidade com o legado de hardware já existente, já o AES é a opção para longo prazo
e é também a opção padrão do 802.11i. Como já citado anteriormente, RSN usa mensagens
EAPOL-Key para gerenciamento de chaves. A negociação de qual método de criptografia
será usada na conversação que se inicia entre um dispositivo móvel e um access point se dá
através do que chamamos de Robust Secure Network Association (RNSA). Nesta associação,
informações são trocadas para escolher qual o método é o mais indicado e suportado para ser
usado entre as partes. Estas informações ficam contidas num frame que denominado RSN IE
ou RSN information element.
36
Figura 13 - Detalhes de um frame RSN-IE
37
7. TKIP
O Temporal key Integrity Protocol (TKIP) foi criado para solucionar o problema de
reuso de chave que ocorre no WEP. Em resumo, vejamos quais são os principais problemas
do WEP:
• O vetor de inicialização (IV) é muito pequeno e não protege de ataques de replay;
• A forma como as chaves são criadas a partir do IV o tornam vulneráveis ataques simples;
• Não há um efetivo sistema de detecção a ataques de alteração de mensagens (integridade);
• Usa-se diretamente a shared-key para criptografia de dados e não há nenhum sistema
nativo que faça troca de chaves periodicamente;
• Não existe proteção à ataques de replay de mensagens;
Agora vejamos como o TKIP se propôs a melhorar as deficiências do WEP
7.1 Integridade de Mensagens
Foi criado o Integrity Check Value (ICV), cuja finalidade é detectar se a mensagem
não sofreu nenhuma adulteração durante o percurso até o destino final. Isto foi feito
adicionando-se um valor de checksum às mensagens. O termo usado para a validação de
integridade para mensagens é MAC (Message Authentication Code), porém para não haver
confusão com o mesmo termo usado em redes, que vem de Media Access Control, resolveu-se
chamar então de MIC. O valor de MIC é calculado usando-se um processo especial e
irreversível, combinado com a chave de criptografia. Assim, sem a chave, não há como o
atacante regerar o valor de MIC sem conhecer a chave de criptografia. O algoritmo escolhido
para calcular o MIC não deve contemplar operações que consumam muito processamento,
pois isto criaria facilmente um overhead de processamento nos equipamentos, diminuindo
assim a capacidade de throughput da rede, haja visto que a cada mensagem trafegada, um
cálculo complexo teria que ser feito. Foi escolhido então o algoritmo chamado Michael, cuja
simplicidade (apenas operações de soma e deslocamento) não impacta em quase nada o
38
processamento dos dispositivos. Porém é claro, tudo tem seu preço, seus prós e contras. Se
por um lado o algoritmo proporciona pouco overhead de processamento devido a sua
simplicidade, por outro lado ele é mais vulnerável a ataques de força bruta. O cálculo do MIC
ocorre no MSDU, ou seja, o cálculo é feito pelo driver do cartão de rede sem fio, e o mesmo
já sai calculado quando a mensagem é transferida do driver para o hardware.
MSDUs(MAC Service Data Unit) e MPDUs(MAC Protocol Data Unit): Para
compreendermos o funcionamento dos algoritmos de criptografia usados em redes RSN,
precisamos primeiramente conhecer os termos MSDU e MPDU. Ambos referem-se à pacotes
de dados, com os respectivos endereços de origem e destino. MSDU refere-se à pacotes de
dados trafegando entre o driver do dispositivo de rede sem fio e dispositivo físico
propriamente dito. Já o MPDU refere-se ao pacote de dados sendo trafegado entre o
dispositivo físico de rede e a antena. Um MSDU pode ser fragmentado em várias partes e
gerar vários MPDUs.
7.2 Seleção e Uso do IV
Em TKIP, o tamanho do IV aumentou dos 24 bits para 48 bits, o que tornou quase
impossível ocorrer a reutilização de um IV em pouco tempo, já que o número de
possibilidades aumentou de aproximadamente 16 milhões para mais de 281 trilhões de
combinações possíveis. Para não criar problemas para o hardware legado, que usa um IV de
24 bits, a forma de cálculo foi alterada, e possui agora duas fazes. Abaixo, o gráfico mostra
como é feita a composição de valores para o cálculo criptográfico usando o algoritmo RC4.
Perceba que, para fazer uso do IV de 48 bits, o mesmo é quebrado e usado em duas fases.
Figura 14 - RC4 usando IV de 48bits
39
A primeira fase gera uma chave de sessão originária de uma chave temporal e do
endereço MAC do originador. Denomina-se esta fase de TCS (TKIP Sequence Counter). A
chave temporal é originada de um valor de 128 bits similar ao valor da chave WEP. O TCS é
formado por uma combinação de valores, originários do endereço de origem(AS), endereço
de destino(DA), prioridade e dados. Assim que completada a fase, o TTAK (TKIP-Mixed
Transmit Address And Key) estará definino.
Na fase seguinte, o TTAK e o vetor de inicialização (IV) são usados em conjunto
para criar a chave de criptografia da sessão.
7.3 TSC (Tkip Sequence Counter)
Este mecanismo foi criado para evitar ataques de replay. Na verdade tanto o TSC
quanto o IV atuam em objetivo comum. O TSC é um contador, que é incrementado a cada
mensagem enviada. Se a seqüência recebida não for a esperada, ou seja, maior ou igual (caso
de retransmissão) da última recebida, a conversação será interrompida.
40
8. AES-CCMP
Em RSN, AES (Advanced Encryption Standard) é o padrão de criptografia default,
pois ele é considerado mais seguro e “forte” que o TKIP. Por o TKIP ter compromisso com o
legado, novas técnicas, mais eficientes e seguras, não puderam ser utilizadas nele, já o AES
nasceu sem estas limitações. AES não é um protocolo, é um método de cifragem de bloco. O
protocolo é o CCMP (Counter Mode–CBC MAC Protocol). O CCMP define um conjunto de
regras que utiliza o AES para cifragem de dados. AES está para o CCMP, assim como o RC4
está para o TKIP.
O AES foi escolhido em 2002 pelo U.S. National Institute for Science and
Technology (NIST) nos Estados Unidos, como sendo um algoritmo suficientemente robusto
para ser usado como padrão em aplicações do governo americano que necessitavam de alta
confidencialidade. O algoritmo escolhido para tornar-se o AES foi o Rijndael algorithm.
Então, o IEEE decidiu adotar o próprio AES como algoritmo de criptografia do 802.11i,
aproveitando todo trabalho que o NIST já havia feito para encontrar um algoritmo
suficientemente seguro, robusto e eficiente para o governo.
Como dito anteriormente, o AES é um algoritmo de criptografia de bloco. Usando
operações matemáticas e lógicas, o método combina a chave e um bloco de dados não
cifrados de 128 bits para produzir um outro bloco cifrado. O AES é reversível, ou seja, é
possível voltar aos dados originais. Outra importante característica é que o bloco cifrado e o
não cifrado têm exatamente o mesmo tamanho. O que o AES faz é simplesmente converter
um bloco de 128 bits, de forma eficiente e extremamente segura. Mais uma coisa importante a
salientar sobre o AES, é que além de implementar um mecanismo para prover
confidencialidade, através do uso de criptografia, o AES também já implementa o controle de
autenticidade, garantindo assim a integridade das informações.
41
8.1 Modo de Operação
Como o AES trabalha com blocos de tamanho fixo e as mensagens possuem
tamanhos variáveis, tipicamente entre 512 e 12000 bits, algum método deve ser utilizado para
converter tamanhos arbitrários de mensagens em uma seqüência de blocos de tamanho fixo
para proceder com a criptografia. De forma análoga, o inverso também é verdadeiro. A esse
método chama-se mode of operation. O CCMP usa o método chamado de CCM, que é
baseado no uso de contadores, chamado Counter Mode.
Neste sistema, não se usa diretamente o bloco AES para cifrar uma mensagem, pois
dois blocos idênticos iriam gerar a mesma saída, o que criaria uma vulnerabilidade. Ao invés
disto, o CCM cifra um valor arbitrário, o contador, e depois faz uma operação de XOR com o
bloco de dados da mensagem, e como resultado teremos os dados criptografados. O contador,
como o próprio nome sugere, é geralmente incrementado de um a cada bloco processado, e o
seu valor inicial sempre deverá ser um valor randômico, e nunca iniciar com o valor pré-
fixado. O importante é que a contraparte saiba qual o valor inicial do contador foi utilizado.
A figura abaixo ilustra bem o processo.
Figura 15 - Counter Mode
Este modo de operação tem várias propriedades interessantes. Primeiramente, a
decifragem funciona exatamente como o método de cifragem, pois fazendo XOR num mesmo
valor duas vezes, obteremos novamente o resultado original, ou seja, tudo que precisamos é
do bloco de criptografia. Outra característica importante, é que como sabemos quais os
próximos números que serão usados no contador, o processo pode executar em paralelo, pois
não há dependência de valores. E por último, neste método, não há importância em o tamanho
da mensagem não ser múltiplo do tamanho do bloco, pois o que sobrar da mensagem no final
dela, será operado com o XOR do contador e terá seu resultado computado normalmente.
42
O counter mode porém garante apenas a confidencialidade, e como foi citado
anteriormente, o AES é usado para garantir também a autenticidade. Por isso, o IEEE fez mais
uma alteração no modo de uso do AES.
8.2 Counter Mode + CBC MAC : CCM
CCM usa o counter mode em conjunto com um método de autenticação chamado
“Cipher Block Chaining” (CBC), que é usado para gerar o “message integrity code” (MIC).
O MIC é chamado pela comunidade de especialistas de “Message Authentication Code”, daí
o nome CBC-MAC. A idéia básica é:
1. Tome o primeiro bloco da mensagem e cifre-o usando AES;
2. Faça um XOR entre o resultado do passo 1 e o segundo bloco da mensagem e
cifre este também;
3. Novamente faça um XOR do resultado do passo 2 com o terceiro bloco e cifre o
resultado ... e assim por diante;
O resultado será um único bloco de dados que combinou o resultado de toda a
mensagem. Qualquer bit que tenha sido alterado resultará num bloco completamente
diferente. O detalhe é que o processo é simples, porém não pode ser paralelizado.
Vejamos agora como o CCMP é usado em redes RSN.
Figura 16 – CCMP
43
O dado chega como um MSDU e é então quebrado em fragmentos de MPDUs. Um
cabeçalho contendo endereço de origem e destino é adicionado com mais algumas outras
informações. Neste ponto, cada MPDU é processado pelo CCMP para gerar MPDUs
cifrados. Apenas os dados são cifrados, o cabeçalho não.
Figura 17 – Passos no processamento do MPDU
1. MPDU ainda sem criptografia, apenas com o cabeçalho MAC;
2. O cabeçalho MAC é separado do MPDU, informações do cabeçalho são extraídas
e usadas para formar o valor do MIC. Também constroi-se a partir deste momento
o cabeçalho do CCMP;
3. Com o MIC já calculado e protegido pelo cabeçalho CCMP, ocorre a cifragem dos
dados juntamente com o MIC;
4. A composição dos dados e o valor de MIC são cifrados;
5. Finalmente o cabeçalho MAC é adicionado na frente do MPDU e este está pronto
para ser transmitido;
8.3 O Cabeçalho CCMP
O cabeçalho CCMP tem dois objetivos, o primeiro é prover um Packet Number (PN)
de 48 bits, que dá segurança contra ataques de replay e permite ao receptor derivar um valor
proveniente de um nonce que foi usado na fase de criptografia. Outro objetivo é, no caso de
multicasts, informar ao receptor qual o group key foi usado.
44
Figura 18 – Cabeçalho CCMP
8.4 A implementação
A implementação do bloco CCMP pode ser vista como um simples processo de
entradas e saídas. Como demonstra a figura abaixo.
Figura 19 – Cifragem e Decifragem CCMP
Perceba que a fase de decifragem possui as mesmas entradas que a fase de cifragem.
Isto porque o cabeçalho CCMP é transmitido sem criptografia e pode então ser extraído pelo
receptor antes de proceder com a decifragem. O processo mantém o contador de seqüência
PN, que é incrementado a cada novo bloco processado, evitando deste modo a reutilização de
um pacote que tenha sido previamente utilizado. O PN tem 48 bits de tamanho, e é grande o
suficiente para que ele nunca “estoure”.
45
Figura 20 – Cifragem de bloco CCMP
Percebe-se como o processo ocorre em duas fases, primeiramente o MIC é calculado
e adicionado ao MPDU, e depois todo MPDU, inclusive o MIC é cifrado.
O MPDU cifrado contém dois campos a mais que um MPDU sem cifragem, o
cabeçalho MPDU e o valor de MIC que possui 8 bytes de tamanho. Perceba que ó o MIC tem
apenas a metade do tamanho de um bloco AES, mas já é grande o suficiente para evitar uma
falsificação de mensagem.
46
9. Vulnerabilidades do 802.11i
O conjunto de protocolos e métodos utilizados pela norma IEEE 802.11i, sem
dúvida, tornou o acesso à redes WLAN significativamente mais seguras do que o antigo e
obsoleto protocolo WEP, porém ainda assim, é possível encontrar alguns artigos mostrando
algumas deficiências do 802.11i, que podem torná-lo vulnerável a alguns ataques.
9.1 Vulnerabilidade 4-Way Handshake
Como visto anteriormente, uma vez estabelecida a PMK pela fase de autenticação
802.1x entre o autenticador e suplicante, dá-se início o processo conhecido por “4 Way
Handshake” cujo objetivo será gerar o conjunto de chaves temporais (PTK’s) necessárias p/
assegurar integridade e confidencialidade das mensagens a serem trocadas nas fases
posteriores. A fim de revisarmos o processo, vejamos o diagrama a seguir que ilustra os
quatro tipos de mensagens que ocorre entre o suplicante e o autenticador.
Diagrama 5 – 4Way Handshake
Uma vez que o processo tenha ocorrido normalmente, suplicante e autenticador
terão gerado a PTK com base nos parâmetros trocados entre eles. O autenticador poderá
atualizar a PTK por periodicidade ou por solicitação do suplicante requerendo um novo
handshake p/ a mesma PMK.
47
Autenticador ou suplicante irão silenciosamente descartar qualquer mensagem
recebida que estiver fora de seqüência ou que tiverem o MIC inválido. Caso o suplicante não
recebe a mensagem 1 em algum tempo após o término com sucesso da fase de autenticação
802.1x, ele irá se dissociar e requisitar uma nova fase de autenticação novamente. De outra
forma, se o autenticador não obtiver nenhuma resposta da sua mensagem 1 ao suplicante, ele
irá retransmiti-la um número finito de vezes e por fim, se não obtiver sucesso, forçará a
dissociação do suplicante que não respondeu.
Repare que enquanto o autenticador pode iniciar apenas uma instância de handshake
e aceitar apenas a resposta esperada, o suplicante pode aceitar todas as mensagens para iniciar
os processo de handshake. Neste momento, um atacante pode iniciar um processo malicioso,
adulterando várias mensagens tipo 1.
Autenticador e suplicante estão programados para seguir o protocolo, cada par (A/S)
compartilham a PMK e tentam seguir o protocolo de sessões de handshake sequencialmente.
O atacante pode disfarçar-se como outro participante forjando o seu MAC, e enviar
mensagens tipo 1 usando os parâmetros (MIC,nonce) que “escutou” previamente das
mensagens trocadas entre outros participantes. Obviamente não será fácil ao atacante
interceptar e bloquear uma mensagem transmitida por um link sem fio, mas considerando-se
que mensagens podem ser facilmente perdidas neste tipo de cenário, o ataque é plausível de
ocorrer. Ou seja, um ataque de “Negação de Serviço” (DoS) pode ser conseguido usando
mensagens 1.
9.1.1 Análise dos Campos Utilizados no Handshake
Os pesquisadores Changhua He e John C. Mitchell utilizaram uma ferramenta de
modelagem chamada Murφ para verificar a real necessidade de utilizar cada campo usado no
handshake e chegaram a conclusão que é possível simplificar muito as mensagens, sem
comprometimento do nível de segurança do protocolo. Dentre as conclusões, eles informaram
que o número de seqüência não é realmente necessário para satisfazer o seu objetivo de
prevenir ataques de replay, pois os próprios campos de nonce e PTKs já previnem este tipo de
ataque. Outra conclusão a que chegaram é que o endereço MAC também poderia ser banido
do processo, pois uma vez que o estabelecimento do PMK foi feito com sucesso, o uso dele
48
não traria nenhum acréscimo de segurança ao processo. Vejamos no diagrama a seguir, a
proposta destes pesquisadores ao processo de handshake.
Diagrama 6 – Handshake Simplificado
9.1.2 O Ataque DoS
O atacante é capaz de fazer-se passar pelo autenticador enviando mensagens 1 aos
suplicantes, uma simples mensagem deste tipo causará inconsistência na PTK. O atacante
envia uma mensagem tipo 1 após o suplicante ter enviado uma mensagem 2. O suplicante irá
calcular um novo PTK usando o nonce enviado pela mensagem forjada. Isto causará um
bloqueio no processo, pois o PTK não será consistente com o PTK originalmente usado pelo
verdadeiro autenticador. O atacante poderá determinar o momento exato para mandar a
mensagem forjada monitorando o tráfego de rede ou enviando um seqüência de mensagens 1
numa certa constância (flooding).
Diagrama 7 – Ataque DoS Handshake
49
Aparentemente os engenheiros do 802.11i já previram um problema deste tipo e
propuseram o seguinte: O suplicante deve guardar duas PTK’s, uma temporária (TPTK) e
outra PTK. Apenas a TPTK é atualizada quando a mensagem 1 é recebida. A PTK só é
atualizada quando recebida a mensagem 3, que não pode ser forjada. Porém, esta solução só
funcionará quando diferentes instâncias (uma entre o suplicante e o autenticador e outra entre
o mesmo suplicante e o atacante) de handshake executarem sequencialmente. Obviamente não
funcionará para o ataque mostrado no diagrama acima, pois o suplicante sequer conseguirá
verificar o conteúdo do campo MIC da mensagem 3 corretamente.
Podemos alterar um pouco esta abordagem para gravar as duas possíveis chaves
TPTK e PTK e tentar verificar o MIC da mensagem 3 com ambas as chaves. Isto soluciona o
problema mostrado no diagrama acima, porém o atacante continuará criando problemas ao
suplicante enviando uma série de mensagens 1 com diferentes conteúdos de nonce em cada
uma delas. Ou seja, o suplicante terá que ter memória suficiente para guardar o conteúdo de
cada uma dessas mensagens forjadas até que ele consiga terminar o processo de handshake
satisfatoriamente, obtendo o verdadeiro PTK. Como o processo de cálculo do PTK não é
oneroso, o ataque não terá sucesso neste aspecto, porém, no aspecto de memória, isto sim
poderá ser um sério problema ao suplicante.
Algumas soluções podem ser implementadas p/ diminuir a vulnerabilidade da fase
de handshake à ataques de DoS. Como autenticador e suplicante possuem o conhecimento do
valor da PMK antes da fase “4-Way Handshake”, poder-se-ia derivar uma PTK trivial da
PMK e usá-la para calcular um MIC na mensagem 1. Desta forma, o atacante teria
dificuldades para gerar uma mensagem 1 forjada, já que a mesma estaria autenticada pelo
MIC.
Uma outra forma que também poderia ser usada é eliminar a fase intermediária do
suplicante, o suplicante não responderia a mensagem 1 com o seu valor de nonce, ele apenas
faria isto depois da confirmação de legitimidade da mensagem 3. Nesta abordagem, o
suplicante precisará apenas guardar o valor de snonce, o que eliminaria o ataque DoS tipo
memória. Ele apenas derivará PTK usando o valor de snonce e o valor de anonce, depois
calcularia o MIC da PTK e enviaria a correspondente mensagem 2. Recebendo a mensagem 3
o suplicante iria novamente derivar a PTK usando o valor guardado de snonce e do valor
recebido de anonce e calcularia então o MIC usando o valor de PTK. Uma vez o MIC estando
certo, enviaria a mensagem 4. O maior problema desta solução é que ela causa um maior
overhead de cpu do lado do suplicante, haja visto que ele precisará calcular PTK duas vezes.
50
9.2 Vulnerabilidade do Protocolo CCMP
Uma outra vulnerabilidade encontrada na norma 802.11i foi a que se refere a uma
fragilidade encontrada no protocolo baseado no modo de contadores, counter mode. A
fragilidade apontada se baseia na possibilidade de um atacante descobrir o valor inicial usado
no contador. Uma falha do contador certamente resultará no colapso de todo o mecanismo de
segurança do 802.11.
Figura 21 – MPDU CCMP
O Counter Mode opera cifrando o contador inicial e o resultado é ‘XOReado’ com o
texto para produzir então o texto cifrado. O contador inicial é gerado dos campos de flag, do
tamanho do payload e de um nonce. O nonce por sua vez é gerado do Packet Number (PN),
do endereço MAC da camada de enlace e do campo de prioridade MAC. Como o valor de
nonce pode ser pré-calculado, a única coisa necessária para se calcular o contador inicial é o
tamanho do payload. O tamanho do payload pode ser obtido com informações prévias,
exemplificando: em 802.11 o tamanho máximo do payload é de 2296 bytes (2312 de payload
- 8 bytes de MIC e - 8 bytes do cabeçalho CCMP). Se a quantidade de dados for maior que o
tamanho máximo de payload, o MSDU será fragmentado em MPDUs, ou seja, o primeiro
MPDU terá 2296 bytes. Uma vez que se possa prognosticar o valor inicial do contador,
ataques do tipo Time Memory Trade Off (TMTO) podem diminuir o nível de segurança
esperado do AES-128-CM.
As figuras a seguir mostram como o CCMP cifra e decifra mensagens.
51
Figura 22 – Cifragem CCMP
Figura 23 – Decifragem CCMP
9.2.1 Reconstrução do Valor Nonce
O bloco de nonce é constituído de três campos. Um é o endereço MAC, outro é o
campo de prioridade, que por default é zero e por último o valor de PN, que é o único campo
realmente dinâmico. Como os cabeçalhos MAC e CCMP são transmitidos em texto claro, e
seus campos ficam em posições fixas, no MPDU, não fica difícil de descobrir o valor de PN e
assim, descobrir o valor de nonce, como ilustra a figura a seguir.
Figura 24 – Reconstrução do valor de nonce
52
9.2.2 Reconstrução do Initial Counter
No 802.11i o payload a o MIC são cifrados usando o método counter mode. O
processo ocorre em blocos conforme abaixo:
Si = ℮k (Ctri)
onde,
Ctri = (Ctr1 + i – 1) mod 2n (1 ≤ i ≤ b)
Ctri = valor do bloco de contagem que sofreu i interações
℮k = cifragem AES usando chave k
n = número de bits no bloco
b = número de blocos de chaves que sofrerá XOR com o texto em claro
O Texto C é cifrado C = P (+) (S1 || ... || Sb)
E decifrado P = C (+) (S1 || ... || Sb)
O bloco de contagem (Ctr) consiste de três valores:
• Flags
• Nonce
• Tamanho de payload
O bloco de contagem Ctri de interação i é formatado conforme figura abaixo:
Figura 25 – Formatação dos Blocos de Contagem
O campo de flags é um octeto e consiste de 2 bits reservados, para uso futuro, 3 bits
com valores zero e os últimos 3 bits expressam o tamanho do payload (q) em binário, [q-1]3.
O valor de nonce já foi extraído conforme sessão anterior, o bit de tamanho de cada
string nonce (N) e payload (P) são múltiplos de 8 bits. O tamanho destas strings são
denotados como n e p respectivamente, portanto n e p são números inteiros. Ao octeto que
53
representa o tamanho P denotamos como Q. Ao octeto que representa o tamanho de Q
denotamos como q, que é o parâmetro de formatação da função. Portanto, Q é equivalente a
[p]8q, ou seja, a representação binária de p em q octetos.
Como observamos, o valor do flag é uma constante fixa. Também já vimos como
reconstruir o valor do nonce. Agora para calcularmos o valor do bloco de contagem
precisamos do tamanho do payload. Já vimos que as MPDUs têm tamanho máximo de 2312
bytes, e que as MSDUs que têm tamanho maior que 2296 bytes são fragmentadas em
MPDUs. Como o payload das MPDUs também contém o cabeçalho TCP, IP e SNAP,
praticamente toda MSDU é fragmentada e o primeiro pacote terá sempre o tamanho máximo,
e portanto, o tamanho de payload pode ser estimado. Isto tornará possível então estimar o
valor inicial e os valores subseqüentes do contador.
p = 2296 octetos
se q = 2, então
Q = [p]8q = [2296]8x2
Q = 00001000 11111000
Onde
p = octeto que representa o tamanho do payload
q = octeto que representa o tamanho do octeto que tem o tamanho do payload
Q = representação em cadeia de bits do tamanho de P
Figura 26 – Reconstrução do Initial Counter
9.3 O Ataque Time-Memory Trade Off (TMTO)
De posse do valor do Initial Counter, uma ataque TMTO pode então ser deflagrado.
Na verdade, TMTO é uma técnica usada para diminuir ao máximo o número de interações ou
operações para se chegar a um resultado, e com isto ganhar muito em desempenho. Porém,
em contra partida e de forma inversa, a necessidade de uso da memória aumenta
54
exponencialmente. Neste tipo de técnica, o atacante gera uma enorme base de dados antes de
efetivamente atacar a chave. Uma importante propriedade deste ataque é que o atacante não
precisa nenhum conhecimento prévio do texto em claro durante a fase de geração da base de
dados, pois técnicas de erro-correção ou backtracking são utilizadas.
O sucesso de um ataque deste tipo depende essencialmente da quantidade de dados
disponíveis, portanto uma estratégia bem formulada para a geração de dados são essenciais
para o sucesso deste ataque.
No caso do CCMP focaremos nos 2296 bytes do payload, onde observamos que o
contador é incrementado de forma padronizada, durante uma mesma sessão. Esta
característica torna o contador previsível e por conseqüência vulnerável à ataques de TMTO.
Outra característica importante é que não há limites de MPDUs por sessão, o que torna
possível a coleta de uma grande quantidade de dados para formar um banco de dados.
O TMTO reduz a efetividade de tamanho de chaves em 2n/3, onde n é a chave usada
na cifragem. Como o AES Counter Mode tem chave de 128 bits no 802.11i, após um ataque
TMTO a chave efetiva será: (2 x 128) / 3 = 85 bits, o que diminui consideravelmente a força
da chave! Aplicando-se a lei de Moore (Moores’Law), padrões atuais de chaves simétricas
deveriam ter no mínimo 97 bits.
Algumas sugestões para diminuir a vulnerabilidade à ataques de TMTO são:
• Aumentar o tamanho do contador para 64 bits;
• Usar um contador estimável, mas que porém fosse usado um componente
uniformemente distribuído no initial counter;
• Usar chaves AES maiores que 128 bits;
55
Conclusão
O padrão IEEE 802.11i veio a contribuir e muito para a melhoria de segurança ante
a enorme vulnerabilidade que as redes 802.11 tinham com o originalmente criado protocolo
para este propósito, o WEP. Redes operando em conformidade RSN são realmente bastante
seguras, tomando-se como referência o padrão de poder computacional disponível atualmente.
A maior dificuldade que o padrão 802.11i impôs é que, devido a sua complexidade
relativamente alta, acabou dificultando a interoperabilidade entre sistemas de diferentes
fabricantes, o que pode tornar-se um empecilho. Outro ônus do padrão foi a necessidade de
torná-lo compatível com o hardware legado do WEP. Conclui-se que o IEEE deveria ter
amadurecido mais a normatização da segurança de redes WLAN's, e assim teria evitado
precipitadamente a homologação do WEP como protocolo de segurança e consequentemente
o seu descrédito pelo mercado.
O padrão 802.11i implementou várias técnicas que melhoraram o controle de acesso,
a integridade e a confidencialidade nas comunicações de redes sem fio. A utilização da norma
802.1X, que tem por objetivo primordial o controle de acesso ao meio, foi muito bem vinda
ao padrão, principalmente por tratar-se de um tipo de rede onde a informação trafega "pelo ar"
por meio de ondas eletromagnéticas, e cujo acesso é facilitado justamente pela sua natureza de
operação. No handshake do 802.1x, ocorre uma fase de suma importância para o sucesso da
norma 802.11i, onde são criadas uma hierarquia de chaves, que serão usadas nesta e em outras
fases posteriores. Faz-se o uso de chaves temporais derivadas de chaves mestres, muito bem
guardadas e com seu uso minimizado ao máximo. Com isso evita-se vários tipos de ataques,
dentre eles os ataques do tipo replay, pois a cada nova seção, um novo conjunto de chaves é
gerado.
Ataques de força bruta também foram minimizados com o uso de chaves maiores ou
por uso de algoritmos de criptografia mais "fortes" como o AES. No caso do TKIP por
exemplo, como o algoritmo RC4 precisou ser mantido para manter compatibilidade com o
hardware legado, optou-se pela utilização de um "Vetor de Inicialização" maior, com 48 bits
(238 trilhões de combinações possíveis), tornando assim mais difícil a recorrência do uso de
um mesmo valor de vetor.
56
O uso do método de criptografia AES-CCMP, onde se utiliza o AES para cifrar um
contador variável, antes de operar (pelo operador XOR) os dados propriamente ditos, gera
uma codificação muito segura, pois o contador inicial de uma seção é sempre diferente e
dificulta ataques à confidencialidade das informações. A adição do CBC (Cipher Block
Chaining) ao protocolo tornou ainda mais difíceis ataques "de meio" com modificação das
informações, pois este método torna a criptografia dos blocos de informações dependentes, já
que o resultado da cifragem de um bloco é usado na cifragem do bloco seguinte e assim por
diante. Ou seja, qualquer alteração em um bloco intermediário afetará todos os resultados
subseqüentes, o que resultará em descartes pelo receptor.
Em suma, o padrão 802.11i utiliza um misto de técnicas que fazem o uso de chaves
síncronas, assíncronas e temporais, contadores, hash's, algoritmos criptográficos etc. a fim de
fornecer conexões em redes sem fio mais robustas, confiáveis e menos suscetíveis a ataques à
confidencialidade e integridade das informações.
57
Referência Bibliográfica
EARLE, Aaron E., Wireless Security Handbook , New York - EUA, Auerbach Publications, 2006.
EDNEY Jon, ARBAUGH William A., Real 802.11 Security: Wi-Fi Protected Access and 802.11i, Boston – EUA , Addison Wesley US, 2004.
IEEE-SA Computer Society - Std 802.11i, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specificatio n, New York – EUA, 2004.
Artigos:
DULANEY Ken, AHLAWAT Rachna, PESCATORE John, GIRARD John, New Standard Will Advance Wireless Networking , GARTNER - ID Number FT-23-3273, 07/2004.
CAM Nancy, HOUSLEY Russ, WAGNER David, WALKER Jesse, Security Flaws in 802.11 Data Link Protocols , Communications of the ACM, 05/2003.
CHEN Jyh-Cheng, JIANG Ming-Chia, LIU Yi-Wen, Wireless LAN Security and IEEE 802.11i, IEEE, 2004.
MOUSTAFA Hassnaa, BOURDON Gilles, GOURHANT Yvon, Authentication, Authorization and Accounting (AAA) in Hibrid Ad Hoc Hotspot’s Environments , ACM, 2006.
ARBAUGH William A., Wireless Security Is Different , IEEE, 08/2003.
BHAGYAVATI, SUMMERS Wayne C., DEJOIE Anthony, Wireless Security Techniques: An Overview , ACM, 2004.
HE Changhua, MITCHELL John C., Analysis of the 802.11i 4-Way Handshake , ACM, 2004.
PARK Joon S, DICOI Derrick, WLAN Security: Current and Future , IEEE, 10/2003.
POTTER Bruce, Wireless Security’s Future , IEEE, 2003.
SITHIRASENAN Elankayer, ZAFAR Saad, MUTHUKKUMARASAMY Vallipuram, Formal Verification of the IRRR 802.11i WLAN Security Prot ocol , IEEE, 2006.
FURQAN Zeeshan, MUHAMMAD Shahabuddin, GUHA Ratan K., Formal Verification of 802.11i using Strand Space Formalism , IEEE, 2006.
STAMP Mark, Once Upon a Time-Memory Tradeoff , 2003.
JUNAID M., MUFTI Muid, ILYAS Umar M., Vulnerabilities of IEEE 802.11i Wireless LAN CCMP Protocol , PWASET Vol 11 - Waset.org, 2006.