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.

Documents

Segurança em Redes sem Fio Padrão IEEE802.11i