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
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
_________
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
7.1 Integridade de Mensagens .............................................................................................. 37 7.2 Seleção e Uso do IV ....................................................................................................... 38 7.3 TSC (Tkip Sequence Counter) ....................................................................................... 39
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
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.