Baixar para ler offline
![484 Redes de computadores
alfabeto e assim por diante. O texto simples é escrito hori-
zontalmente, em linhas. O texto cifrado é lido em colunas,
a partir da coluna cuja letra da chave seja a mais baixa.
Para quebrar uma cifra de transposição, o criptoanalis-
ta deve primeiro estar ciente de lidar com tal cifra. Ao exa-
minar a frequência de E, T, A, O, I, N etc., fica fácil consta-
tar se essas letras se encaixam no padrão normal para texto
simples. Se houver correspondência, isso significa que se
trata sem dúvida de uma cifra de transposição, pois nesse
tipo de cifra cada letra é representada por ela mesma, man-
tendo intacta a distribuição de frequências.
A próxima etapa é fazer uma estimativa do número de
colunas. Em muitos casos, uma palavra ou frase provável
pode ser deduzida a partir do contexto da mensagem. Por
exemplo, suponha que nosso criptoanalista tenha suspei-
tado de que a frase em texto simples milliondollars ocorre
em algum lugar na mensagem. Observe que os digramas
MO, IL, LL, LA, IR e OS ocorrem no texto cifrado como
um resultado do desdobramento dessa frase. No texto ci-
frado, a letra O vem depois da letra M (ou seja, elas são
verticalmente adjacentes na coluna 4), pois estão separadas
na provável frase por uma distância igual ao tamanho da
chave. Se tivesse sido usada uma chave de tamanho sete,
teriam surgido os digramas MD, IO, LL, LL, IA, OR e NS.
Na verdade, para cada tamanho de chave, é produzido um
conjunto de digramas diferente no texto cifrado. Ao tentar
encontrar diferentes possibilidades, muitas vezes o criptoa
nalista é capaz de determinar com facilidade o tamanho da
chave.
A última etapa é ordenar as colunas. Quando o núme-
ro de colunas k é pequeno, cada um dos k(k - 1) pares de
colunas pode ser examinado para que se constate se suas
frequências de digramas correspondem às do texto simples
em inglês. O par que tiver a melhor correspondência será
considerado na posição correta. Em seguida, cada uma das
colunas restantes é experimentada como sucessora desse
par. A coluna cujas frequências de digramas e trigramas
proporcionem a melhor correspondência será a título ex-
perimental considerada correta. A próxima coluna é en-
contrada da mesma maneira. O processo inteiro continua
até ser encontrada uma ordenação potencial. O mais pro-
vável é que o texto simples seja reconhecido nesse ponto
(por exemplo, se ocorrer milloin, ficará claro qual é o erro).
Algumas cifras de transposição aceitam um bloco de
tamanho fixo como entrada e produzem um bloco de ta-
manho fixo como saída. Essas cifras podem ser comple-
tamente descritas fornecendo-se uma lista que informe a
ordem na qual os caracteres devem sair. Por exemplo, a
cifra da Figura 8.2 pode ser vista como uma cifra de blocos
de 64 caracteres. Sua saída é 4, 12, 20, 28, 36, 44, 52, 60,
5, 13,..., 62. Em outras palavras, o quarto caractere de en-
trada, a, é o primeiro a sair, seguido pelo décimo segundo,
f, e assim por diante.
8.1.4 Chave única
Na verdade, é fácil criar uma cifra inviolável; a técnica
é conhecida há décadas. Primeiro, escolha como chave uma
sequência de bits aleatórios. Em seguida, converta o texto
simples em uma sequência de bits, utilizando por exemplo
sua representação ASCII. Por fim, calcule o OU exclusivo
(XOR) dessas duas sequências. O texto cifrado resultante
não pode ser violado porque, em uma amostra grande o
suficiente de texto cifrado, cada letra ocorrerá com a mes-
ma frequência, bem como o digrama, o trigrama e assim
por diante. Esse método, conhecido como chave única, é
imune a todos os ataques presentes e futuros, não importa
quanta capacidade computacional tenha o intruso. A razão
deriva da teoria da informação: simplesmente não existe ne-
nhuma informação na mensagem, todos os textos simples
possíveis com o tamanho dado são igualmente prováveis.
Um exemplo de como as chaves únicas são usadas é dado
na Figura 8.3. Primeiro, a mensagem 1, ‘I love you’, é con-
vertida em ASCII de 7 bits. Em seguida, uma chave única,
chamada chave 1, é escolhida e sujeita à operação XOR com
a mensagem para obter o texto cifrado. Um criptoanalista po-
deria experimentar todas as chaves únicas possíveis para ver
que texto resultou para cada uma. Por exemplo, a chave úni-
ca listada como chave 2 na figura poderia ser experimentada,
resultando no texto simples 2, ‘Elvis lives’ [Elvis não morreu],
que pode ser ou não plausível (um assunto que está além do
escopo deste livro). De fato, para cada texto simples ASCII
de 11 caracteres, existe uma chave única que o gera. É isso
que queremos dizer quando mencionamos que não existe ne-
nhuma informação no texto cifrado: é possível obter qualquer
mensagem com o tamanho correto a partir dele.
As chaves únicas são ótimas na teoria, mas têm várias
desvantagens na prática. Para começar, não pode ser me-
morizada; então, tanto o remetente quanto o destinatário
devem levar uma cópia escrita com eles. Se qualquer um dos
dois estiver sujeito à possibilidade de captura, as chaves es-
critas sem dúvida serão inconvenientes. Além disso, a quan-
tidade total de dados que podem ser transmitidos é limitada
pelo tamanho da chave disponível. Se o espião tiver muita
sorte e descobrir uma grande quantidade de dados, talvez
M E G A B U C K
7 4 5 1 2 8 3 6
p l e a s e t r Texto simples
pleasetransferonemilliondollarsto
myswissbankaccountsixtwotwo
Texto cifrado
AFLLSKSOSELAWAIATOOSSCTCLNMOMANT
ESILYNTWRNNTSOWDPAEDOBUOERIRICXB
a n s f e r o n
e m i l l i o n
d o l l a r s t
o m y s w i s s
b a n k a c c o
u n t s i x t w
o t w o a b c d
Figura 8.2 Uma cifra de transposição.
08_tanen0809_cap08 BR.indd 484 4/25/11 3:07 PM](https://image.slidesharecdn.com/capitulo8-230509122826-f3e8d8cc/85/capitulo8-pdf-6-320.jpg)
![492 Redes de computadores
Foram realizadas outras conferências e mais tentativas de
encontrar falhas nos algoritmos.
Em outubro de 2000, o NIST anunciou que tinha se-
lecionado o Rijndael, de Joan Daemen e Vincent Rijmen.
O nome é derivado do sobrenome dos autores: Rijmen +
Daemen. Em novembro de 2001, o Rijndael se tornou o
padrão AES do governo dos Estados Unidos, publicado
como FIPS (Federal Information Processing Standard) 197.
Por causa da extraordinária abertura da competição, das
propriedades técnicas do Rijndael e do fato de a equipe
premiada consistir em dois jovens criptógrafos belgas (com
pouca probabilidade de ter criado uma porta dos fundos só
para agradar a NSA), o Rijndael se tornou o padrão cripto-
gráfico dominante no mundo. A criptografia e a descripto-
grafia AES fazem parte do conjunto de instruções de alguns
microprocessadores (por exemplo, Intel).
O Rijndael admite tamanhos de chaves e tamanhos de
blocos desde 128 bits até 256 bits em intervalos de 32 bits.
O comprimento da chave e o do bloco podem ser esco-
lhidos independentemente. Porém, o AES especifica que
o tamanho do bloco deve ser 128 bits e o comprimento da
chave deve ser 128, 192 ou 256 bits. É pouco provável que
alguém utilize chaves de 192 bits; assim, de fato, o AES tem
duas variantes: um bloco de 128 bits com uma chave de
128 bits e um bloco de 128 bits com uma chave de 256 bits.
Em nosso tratamento do algoritmo, examinaremos ape-
nas o caso de 128/128, porque é provável que esse se torne a
norma comercial. Uma chave de 128 bits oferece um espaço
de chaves de 2128
≈ 3 × 1038
chaves. Ainda que a NSA consiga
construir uma máquina com 1 bilhão de processadores para-
lelos, cada um capaz de avaliar uma chave por picossegundo,
tal máquina levaria cerca de 1010
anos para pesquisar o espaço
de chaves. Nessa época, o Sol já terá explodido e as pessoas
que sobreviverem terão de ler os resultados à luz de velas.
Rijndael
Sob uma perspectiva matemática, o Rijndael se baseia
na teoria de campo de Galois, o que proporciona ao algo-
ritmo algumas propriedades de segurança demonstráveis.
Porém, ele também pode ser visto como código em C, sem
a necessidade de entrarmos nos detalhes matemáticos.
Como o DES, o Rijndael utiliza substituição e permuta-
ções, e também emprega várias rodadas. O número de roda-
das depende do tamanho da chave e do tamanho do bloco,
sendo 10 para chaves de 128 bits com blocos de 128 bits,
passando para 14 no caso da maior chave ou do maior blo-
co. No entanto, diferentemente do DES, todas as operações
envolvem bytes inteiros, a fim de permitir implementações
eficientes, tanto em hardware quanto em software. Um es-
boço do código é apresentado no Quadro 8.1. Observe que
esse código é para fins de ilustração. Boas implementações
do código de segurança seguirão práticas adicionais, como
zerar a memória confidencial depois que ela tiver sido usa-
da. Veja, por exemplo, Ferguson et al. (2010).
#define LENGTH 16 /* número de bytes no bloco de dados ou chave */
#define NROWS 4 /* número de linhas no estado */
#define NCOLS 4 /* número de colunas no estado */
#define ROUNDS 10 /* número de iterações */
typedef unsigned char byte; /* inteiro de 8 bits sem sinal */
rijndael(byte plaintext[LENGTH], byte ciphertext[LENGTH], byte key[LENGTH])
{
int r; /* índice do loop */
byte state[NROWS][NCOLS]; /* estado atual */
struct {byte k[NROWS][NCOLS];} rk[ROUNDS + 1]; /* chaves da rodada */
expand_key(key, rk); /* constrói as chaves da rodada */
copy_plaintext_to_state(state, plaintext); /* inicia estado atual */
xor_roundkey_into_state(state, rk[0]); /* XOR da chave no estado */
for (r = 1; r <= ROUNDS; r++) {
substitute(state); /* aplica caixa S a cada byte */
rotate_rows(state); /* gira linha i por i bytes */
if (r < ROUNDS) mix_columns(state); /* função embaralha */
xor_roundkey_into_state(state, rk[r]); /* XOR da chave no estado */
}
copy_state_to_ciphertext(ciphertext, state); /* retorna resultado */
}
Quadro 8.1 Um esboço do Rijndael em C.
08_tanen0809_cap08 BR.indd 492 4/25/11 3:08 PM](https://image.slidesharecdn.com/capitulo8-230509122826-f3e8d8cc/85/capitulo8-pdf-14-320.jpg)
![Capítulo 8 Segurança de redes 493
A função rijndael tem três parâmetros: plaintext, um ar-
ray de 16 bytes contendo os dados de entrada, ciphertext,
um array de 16 bytes no qual será retornada a saída cifrada,
e key, a chave de 16 bytes. Durante o cálculo, o estado atual
dos dados é mantido no array de bytes state, cujo tamanho
é NROWS × NCOLS. No caso de blocos de 128 bits, esse ar-
ray tem 4 × 4 bytes. Em 16 bytes, é possível armazenar
todo o bloco de dados de 128 bits.
O array state é iniciado com o texto simples e modifi-
cado em cada etapa da computação. Em algumas etapas, é
executada a substituição byte a byte. Em outras etapas, os
bytes são permutados dentro do array. Outras transforma-
ções também são usadas. No final, o conteúdo do array state
é retornado como texto cifrado.
O código começa expandindo a chave em 11 arrays do
mesmo tamanho do estado. Eles são armazenados em rk,
um array de structs, cada um contendo um array de estado.
Um desses arrays será utilizado no início do cálculo, e os
outros 10 serão usados durante as 10 rodadas, um por ro-
dada. O cálculo das chaves de rodadas a partir da chave de
criptografia é muito complicado para ser examinado aqui.
Basta saber que as chaves de rodadas são produzidas pela
rotação e pela operação XOR repetida em vários grupos de
bits da chave. Para ver todos os detalhes, consulte (Daemen
e Rijmen, 2002).
A próxima etapa é copiar o texto simples no array state
de forma que ele possa ser processado durante as rodadas.
O texto é copiado em ordem de colunas, com os quatro
primeiros bytes na coluna 0, os quatro bytes seguintes na
coluna 1 e assim por diante. Tanto as colunas quanto as
linhas são numeradas a partir de 0, embora as rodadas se
iniciem em 1. Essa configuração inicial dos 12 arrays de
bytes com tamanho 4 × 4 é ilustrada na Figura 8.8.
Há mais uma etapa antes do início da principal com-
putação: rk[0] é submetido a uma operação XOR em state,
byte por byte. Em outras palavras, cada um dos 16 bytes
em state é substituído pelo XOR do próprio valor com o byte
correspondente em rk[0].
Agora chegou a hora da atração principal. O loop exe-
cuta dez iterações, uma por rodada, transformando state
em cada repetição. O conteúdo de cada rodada consiste em
quatro etapas. A etapa 1 efetua uma substituição byte a
byte em state. Por sua vez, cada byte é usado como um índi-
ce para uma caixa S, a fim de substituir seu valor pelo con-
teúdo dessa entrada da caixa S. Essa etapa é uma cifra de
substituição monoalfabética. Diferentemente do DES, que
tem diversas caixas S, o Rijndael tem apenas uma caixa S.
A etapa 2 gira cada uma das quatro linhas para a es-
querda. A linha 0 é girada 0 bytes (isto é, não se altera), a
linha 1 é girada 1 byte, a linha 2 é girada 2 bytes e a linha 3
é girada 3 bytes. Essa etapa difunde o conteúdo dos dados
atuais em torno do bloco, de modo semelhante às permu-
tações da Figura 8.5.
A etapa 3 embaralha cada coluna independentemente
das outras. O embaralhamento é realizado com o uso da
multiplicação de matrizes, na qual a nova coluna é o pro-
duto da coluna antiga por uma matriz constante, sendo a
multiplicação feita com o campo finito de Galois, GF(28
).
Embora isso possa parecer complicado, existe um algorit-
mo que permite calcular cada elemento da nova coluna
usando duas pesquisas em tabelas e três operações XOR
(Daemen e Rijmen, 2002, Apêndice E).
Por fim, a etapa 4 efetua o XOR da chave correspon-
dente a essa rodada no array state.
Tendo em vista que cada etapa é reversível, a deco-
dificação pode ser feita simplesmente executando-se o
algoritmo no sentido inverso. Porém, também existe um
artifício pelo qual a decodificação pode ser realizada exe-
cutando-se o algoritmo de criptografia com a utilização de
tabelas diferentes.
O algoritmo foi projetado não só por segurança, mas
também para aumentar a velocidade. Uma boa implemen-
tação de software em uma máquina de 2 GHz deve ser
capaz de alcançar uma taxa de criptografia de 700 Mbps,
que é rápida o suficiente para codificar mais de cem vídeos
MPEG-2 em tempo real. As implementações de hardware
são ainda mais rápidas.
8.2.3 Modos de cifra
Apesar de toda essa complexidade, o AES (ou o DES,
ou ainda qualquer cifra de bloco) é basicamente uma cifra
state rk[0] rk[1] rk[2] rk[3] rk[4] rk[5] rk[6] rk[7] rk[8] rk[9] rk[10]
Texto simples de 128 bits Chave de codificação de 128 bits
chaves de rodadas
Figura 8.8 Criação dos arrays state e rk.
08_tanen0809_cap08 BR.indd 493 4/25/11 3:08 PM](https://image.slidesharecdn.com/capitulo8-230509122826-f3e8d8cc/85/capitulo8-pdf-15-320.jpg)
![498 Redes de computadores
criptográfico consistir em um loop no qual os bits da chave
são processados em ordem, um atacante que substituir o
clock principal de n GHz por um clock lento (por exem-
plo, 100 Hz) e prender pinças dentadas (pinças jacaré) nos
pinos de energia da CPU e de terra poderá monitorar com
precisão a energia consumida por cada instrução de máqui-
na. A partir desses dados, será surpreendentemente fácil
deduzir a chave. Esse tipo de criptoanálise só pode ser anu-
lado por codificação cuidadosa do algoritmo em linguagem
assembly para ter certeza de que o consumo de energia será
independente da chave e também independente de todas
as chaves de rodadas individuais.
O quarto desenvolvimento é a análise de sincronismo.
Os algoritmos criptográficos estão repletos de instruções if que
testam bits nas chaves de rodadas. Se as partes then e else de-
morarem períodos de tempo diferentes, tornando mais lento
o clock e verificando quanto tempo demoram diversas etapas,
talvez seja possível deduzir as chaves de rodadas. Uma vez
que todas as chaves de rodadas sejam conhecidas, em geral
será possível calcular a chave original. A análise da energia
e da sincronização também pode ser empregada simultanea-
mente para facilitar o trabalho. Embora a análise da energia e
da sincronização possa parecer exótica, na realidade são técni-
cas eficientes que podem romper qualquer cifra não projetada
de forma específica para resistir a elas.
8.3 Algoritmos de chave pública
O problema da distribuição de chaves sempre foi o
elo mais fraco da maioria dos sistemas de criptografia. In-
dependentemente de quanto um sistema de criptografia
fosse sólido, se um intruso conseguisse roubar a chave, o
sistema acabava sendo inútil. Como todos os criptólogos
sempre presumem que a chave de criptografia e a cha-
ve de descriptografia são iguais (ou facilmente derivadas
uma da outra) e que a chave é distribuída a todos os usuários
do sistema, tinha-se a impressão de que havia um proble-
ma inerente ao sistema. As chaves tinham de ser prote-
gidas contra roubo, mas também tinham de ser distribuí-
das; portanto, não podiam ser simplesmente trancadas na
caixa-forte de um banco.
Em 1976, dois pesquisadores da Universidade de Stan-
ford, Diffie e Hellman (1976), propuseram um sistema
de criptografia radicalmente novo, no qual as chaves de
criptografia e de descriptografia eram diferentes, e a cha-
ve de descriptografia não podia ser derivada da chave de
criptografia. Em sua proposta, o algoritmo de criptografia
(chaveado) E e o algoritmo de descriptografia (chaveado)
D tinham de atender a três requisitos, que podem ser decla-
rados da seguinte forma:
1. D(E(P)) = P.
2. É extremamente difícil deduzir D a partir de E.
3. E não pode ser decifrado por um ataque de texto
simples escolhido.
O primeiro requisito diz que, se aplicarmos D a uma men-
sagem criptografada, E(P), obteremos outra vez a mensagem
de texto simples original P. Sem essa propriedade, o destinatá-
rio legítimo não poderia decodificar o texto cifrado. O segun-
do é autoexplicativo. O terceiro é necessário porque, como
veremos em um minuto, os intrusos podem experimentar o
algoritmo até se cansarem. Sob essas condições, não há razão
para a chave criptográfica não se tornar pública.
O método funciona da seguinte forma: uma pessoa,
digamos Alice, desejando receber mensagens secretas, pri-
meiro cria dois algoritmos que atendem aos requisitos an-
teriores. O algoritmo de criptografia e a chave de Alice se
tornam públicos, daí o nome criptografia de chave pú-
blica. Por exemplo, Alice poderia colocar sua chave pú-
blica em sua home page da Web. Usaremos a notação EA
para indicar o algoritmo de criptografia parametrizado pela
chave pública de Alice. De modo semelhante, o algoritmo
de descriptografia (secreto) parametrizado pela chave pri-
vada de Alice é DA
. Bob faz o mesmo, publicando EB
, mas
mantendo secreta a chave DB
.
Agora, vamos ver se podemos resolver o problema de
estabelecer um canal seguro entre Alice e Bob, que nunca
haviam tido um contato anterior. Tanto a chave de cripto-
grafia de Alice, EA
, quanto a chave de criptografia de Bob,
EB
, estão em arquivos de leitura pública. Agora, Alice pega
sua primeira mensagem P, calcula EB
(P) e a envia para Bob.
Em seguida, Bob a descriptografa aplicando sua chave se-
creta DB
[ou seja, ele calcula DB
(EB
(P)) = P]. Ninguém mais
pode ler a mensagem criptografada EB
(P), porque o siste-
ma de criptografia é considerado sólido e porque é muito
difícil derivar DB
da chave EB
publicamente conhecida. Para
enviar uma resposta R, Bob transmite EA
(R). Agora, Alice
e Bob podem se comunicar com segurança.
Talvez seja interessante fazer uma observação sobre
a terminologia. A criptografia de chave pública exige que
cada usuário tenha duas chaves: uma chave pública, usa-
da pelo mundo inteiro para criptografar as mensagens a
ser enviadas para esse usuário, e uma chave privada, que
o usuário utiliza para descriptografar mensagens. Faremos
referência a essas chaves como chave pública e chave pri-
vada, respectivamente, e vamos distingui-las das chaves
secretas (também chamadas chaves simétricas) usadas na
criptografia de chave simétrica convencional.
8.3.1 RSA
O único problema é que temos de encontrar algorit-
mos que realmente satisfaçam todos os três requisitos. De-
vido às vantagens potenciais da criptografia de chave públi-
ca, muitos pesquisadores estão se dedicando integralmente
a seu estudo, e alguns algoritmos já foram publicados. Um
método muito interessante foi descoberto por um grupo
de pesquisadores do MIT (Rivest et al., 1978) e é conheci-
do pelas iniciais dos três estudiosos que o criaram (Rivest,
Shamir, Adleman): RSA. Ele sobreviveu a todas as tenta-
08_tanen0809_cap08 BR.indd 498 4/25/11 3:08 PM](https://image.slidesharecdn.com/capitulo8-230509122826-f3e8d8cc/85/capitulo8-pdf-20-320.jpg)
![Capítulo 8 Segurança de redes 505
De modo mais geral, se houver algum mapeamento
entre as entradas e as saídas, com n entradas (pessoas,
mensagens etc.) e k saídas possíveis (aniversários, sumá-
rios de mensagens etc.), haverá n(n - 1)/2 pares de entra-
da. Se n(n - 1)/2 k, a chance de haver pelo menos uma
correspondência será muito boa. Portanto, fazendo uma
aproximação, é provável que haja uma correspondência
para n k . Esse resultado significa que provavelmente
um sumário da mensagem de 64 bits possa ser quebrado
gerando-se 232
mensagens e procurando-se duas mensa-
gens com o mesmo sumário.
Agora, vejamos um exemplo prático. O departamento de
ciência da computação da State University nos Estados Uni-
dos tem uma única vaga estável para dois professores, Tom e
Dick. Tom foi admitido dois anos antes de Dick e, portanto, é
convocado para os testes primeiro. Se ele for aprovado, Dick
será descartado. Tom sabe que a chefe de seu departamento,
Marilyn, gosta muito do trabalho dele; sendo assim, ele pede
a Marilyn que escreva uma carta de recomendação ao reitor,
que tomará a decisão a respeito do cargo. Depois de enviadas,
todas as cartas passam a ser confidenciais.
Marilyn pede a sua secretária, Ellen, que escreva a car-
ta para o reitor, fazendo um esboço do que deseja. Quan-
do a carta está pronta, Marilyn a revisa, calcula e assina o
sumário de 64 bits e o envia ao reitor. Ellen pode enviar a
carta mais tarde pelo correio eletrônico.
Infelizmente para Tom, Ellen está envolvida emocional-
mente com Dick e gostaria que Tom fosse descartado; assim,
escreve a carta a seguir com as 32 opções entre colchetes.
Caro Sr. Reitor,
Esta [carta | mensagem] tem como objetivo expressar mi-
nha [honesta | franca] opinião a respeito do professor Tom Wil-
son, que [é | está] [candidato | prestes] [para | a] obter uma vaga
permanente nesta universidade [imediatamente | este ano]. Eu
[conheço | trabalho com] o professor Wilson há seis anos. Ele é
um [destacado | excelente] pesquisador de grande [ talento | capa-
cidade ] [mundialmente | internacionalmente ] conhecido por suas
[brilhantes | criativas] ideias a respeito de [muitos | uma grande
variedade de] problemas [difíceis | complicados].
Ele também é um [professor | educador] [bastante | mui-
to] [respeitado | admirado]. Seus alunos fazem críticas [ma-
ravilhosas | espetaculares] de [suas aulas | seus cursos]. Ele é
o [professor | orientador] [mais querido | mais conhecido] [da
universidade | do departamento].
[Além disso | Além do mais], o professor Wilson é um
[grande | fantástico] administrador. [Seus contratos | Suas con-
cessões ] trouxeram uma [grande | substancial] quantia em
dinheiro para [o | nosso] departamento. [Esse dinheiro | Esses
fundos] [permitiu | permitiram] que [criássemos | realizássemos]
muitos programas [especiais | importantes], [tais como | por
exemplo] o programa Universidade 2000. Sem esses fundos,
[seríamos incapazes | não seríamos capazes] de dar continuidade
a esse programa, que é tão [importante | essencial] para nós.
Afirmo ao senhor que ele é o profissional mais adequado
para essa posição.
Infelizmente para Tom, assim que acaba de redigir e
digitar essa carta, Ellen também digita a seguinte carta:
Caro Sr. Reitor,
Esta [carta | mensagem] tem como objetivo expressar
minha [honesta | franca] opinião a respeito do professor Tom
Wilson, que [é | está] [candidato | prestes] [para | a] assumir
uma vaga permanente nesta universidade [imediatamente |
este ano]. Eu [conheço | trabalho com] Tom há seis anos. Ele
é um [incompetente | mau] pesquisador, não é bem visto em
sua [especialidade | área]. Sua pesquisa [raramente | esporadi-
camente] mostra [bom-senso | conhecimento] dos [principais |
mais importantes] problemas atuais.
Ele não é um [professor | educador] [bastante | muito] [res-
peitado | admirado]. Seus alunos fazem [duras | pesadas] críti-
cas de [ suas aulas | seus cursos]. Ele é o [professor | orientador]
mais impopular [da universidade | do departamento] devido
à sua [tendência | propensão] a [ridicularizar | embaraçar] os
alunos que fazem perguntas em suas aulas.
[Além disso | Além do mais], Tom é um administrador [ter-
rível | fraco]. [Seus contratos | Suas concessões ] trouxeram ape-
nas uma [insignificante | pequena] quantia em dinheiro para [o
| nosso] departamento. A menos que mais [verbas | fundos] se-
jam [alocadas | alocados], teremos de cancelar alguns progra-
mas essenciais, tais como seu programa Universidade 2000.
Infelizmente, sob essas [condições | circunstâncias], não posso
recomendá-lo em sã consciência para essa posição.
Ellen passa o programa em seu computador para calcu-
lar os 232
sumários de mensagens de cada carta. Há chances
de que um sumário da primeira carta corresponda a um su-
mário da segunda carta. Caso isso não aconteça, ela poderá
incluir algumas outras opções e tentar de novo durante o
fim de semana. Suponha que ela encontre uma correspon-
dência. Vamos chamar a carta ‘boa’ de A e a ‘ruim’ de B.
Em seguida, pelo correio eletrônico, Ellen envia a carta
A a Marilyn para que seja aprovada. Ela mantém a carta B
completamente secreta, sem mostrá-la a ninguém. É claro
que Marilyn aprova a carta, calcula seu sumário da men-
sagem de 64 bits, assina o sumário e envia-o assinado ao
reitor Smith utilizando o correio eletrônico. Por outro lado,
Ellen envia a carta B ao reitor (não a carta A, como deveria
fazer).
Depois de obter a carta e o sumário da mensagem as-
sinado, o reitor executa o algoritmo de sumário da mensa-
gem na carta B, observa que ela corresponde ao sumário
que Marilyn enviou e despede Tom. O reitor não perce-
be que Ellen gerou duas cartas com o mesmo sumário da
mensagem e enviou a ele uma mensagem diferente da que
Marylin viu e aprovou. (Final opcional: Ellen conta a Dick
o que fez. Dick não gosta do que ouve e termina o namoro
com ela. Ellen fica furiosa e confessa tudo a Marilyn. Mari-
lyn telefona para o reitor. Tom acaba ficando com o cargo.)
Com o SHA-1, o ataque do aniversário se torna impraticá-
vel, pois, mesmo com um trilhão de sumários por segundo,
seriam necessários 32 mil anos para calcular todos os 280
08_tanen0809_cap08 BR.indd 505 4/25/11 3:08 PM](https://image.slidesharecdn.com/capitulo8-230509122826-f3e8d8cc/85/capitulo8-pdf-27-320.jpg)
capitulo8.pdf
- 1. Capítulo Segurança de redes8 Durante as primeiras décadas de sua existência, as re- des de computadores foram usadas principalmente por pes- quisadores universitários, para enviar mensagens de correio eletrônico, e também por funcionários de empresas, para compartilhar impressoras. Nessas condições, a segurança nunca precisou de maiores cuidados. Porém, como milhões de cidadãos comuns atualmente usam as redes para execu- tar operações bancárias, fazer compras e arquivar sua devo- lução de impostos, surge um ponto fraco atrás de outro, e a segurança tornou-se um problema de grandes proporções. Neste capítulo, estudaremos a segurança das redes sob vá- rios ângulos, destacaremos muitas falhas e discutiremos di- versos algoritmos e protocolos que as tornam mais seguras. A segurança é um assunto abrangente e inclui inúme- ros tipos de problemas. Em sua forma mais simples, preocu- pa-se em impedir que pessoas mal-intencionadas leiam ou, pior ainda, modifiquem secretamente mensagens enviadas a outros destinatários. Outra preocupação da segurança são as pessoas que tentam ter acesso a serviços remotos que não estão autorizadas a usar. Ela também lida com meios para saber se uma mensagem supostamente verdadeira é um trote. A segurança trata de situações em que mensa- gens legítimas são capturadas e reproduzidas, além de lidar com pessoas que tentam negar o fato de ter enviado certas mensagens. A maior parte dos problemas de segurança é causada propositalmente por pessoas mal-intencionadas, que ten- tam obter algum benefício, chamar atenção ou prejudicar alguém. Alguns dos invasores mais comuns estão listados na Tabela 8.1. Fica claro por essa lista que tornar uma rede segura envolve muito mais que apenas mantê-la livre de erros de programação. Para tornar uma rede segura, com frequência é necessário lidar com adversários inteligentes, dedicados e, às vezes, muito bem subsidiados. Você tam- bém deverá ter em mente que as medidas utilizadas para interromper a atividade de adversários eventuais terão pouco impacto sobre os adversários ‘mais espertos’. Os re- gistros policiais mostram que a maioria dos ataques não é perpetrada por estranhos que grampeiam uma linha telefô- nica, mas por pessoas ressentidas com a organização a que pertencem. Os sistemas de segurança devem ser projetados tendo em vista esse fato. Os problemas de segurança das redes podem ser divi- didos nas seguintes áreas interligadas: sigilo, autenticação, não repúdio e controle de integridade. O sigilo — também chamado confidencialidade — está relacionado ao fato de manter as informações longe de usuários não autorizados. É isso que costuma nos vir à mente quando pensamos em segurança de redes. Em geral, a autenticação cuida do pro- cesso de determinar com quem você está se comunicando antes de revelar informações sigilosas ou entrar em uma transação comercial. O não repúdio trata de assinaturas: como provar que seu cliente realmente fez um pedido ele- trônico de dez milhões de unidades de um produto com preço unitário de 89 centavos quando mais tarde ele afir- mar que o preço era 69 centavos? Ou talvez ele afirme que nunca efetuou nenhum pedido. Por fim, como você pode se certificar de que uma mensagem recebida é de fato legí- tima e não algo que um oponente mal-intencionado modi- ficou a caminho ou inventou? Todas essas questões (sigilo, autenticação, não repúdio e controle de integridade) também ocorrem em sistemas Adversário Objetivo Estudante Divertir-se bisbilhotando as mensagens de correio eletrônico de outras pessoas Cracker Testar o sistema de segurança de alguém; roubar dados Representante de vendas Tentar representar toda a Europa e não apenas Andorra Executivo Descobrir a estratégia de marketing do concorrente Ex-funcionário Vingar-se por ter sido demitido Contador Desviar dinheiro de uma empresa Corretor de valores Negar uma promessa feita a um cliente por meio de uma mensagem de correio eletrônico Vigarista Roubar números de cartão de crédito e vendê-los Espião Descobrir segredos militares ou industriais de um inimigo Terrorista Roubar segredos de armas bacteriológicas Tabela 8.1 Algumas pessoas que podem causar problemas de segurança e os motivos para fazê-lo. 08_tanen0809_cap08 BR.indd 479 4/25/11 3:07 PM
- 2. 480 Redes decomputadores tradicionais, mas com algumas diferenças significativas. O sigilo e a integridade são obtidos graças à utilização de correspondência registrada e de bloqueio de documentos. Hoje é mais difícil roubar o trem postal do que nos tempos de Jesse James. Além disso, é comum as pessoas conseguirem distin- guir um documento original de uma fotocópia, e isso quase sempre faz diferença para elas. Como teste, tire uma fo- tocópia de um cheque válido. Tente descontar o cheque original na segunda-feira. Agora tente descontar a fotocó- pia do cheque na terça-feira. Observe a diferença no com- portamento do caixa. Já com os cheques eletrônicos, não há como distinguir entre o original e a cópia. Talvez leve algum tempo até que os bancos aprendam a lidar com isso. As pessoas autenticam outras pessoas por vários meios, incluindo reconhecimento de rosto, voz e caligrafia. As com- provações de assinatura são feitas por meio de papel timbra- do, de símbolos em alto-relevo etc. Em geral, as falsificações podem ser detectadas por especialistas em caligrafia, papel e tinta. Nenhuma dessas opções está disponível eletronica- mente. É claro que são necessárias outras soluções. Antes de entrarmos nas soluções propriamente ditas, vale a pena dedicar alguns momentos considerando a que parte da pilha de protocolos pertence a segurança de re- des. É provável que não exista uma parte específica. To- das as camadas contribuem de alguma forma. Na camada física, os ‘grampos’ podem ser anulados mantendo-se as linhas de transmissão (ou seja, as fibras ópticas) em tubos lacrados contendo gás inerte em alta pressão. Qualquer tentativa de perfurar um tubo liberará o gás, reduzindo a pressão e disparando um alarme. Alguns sistemas milita- res utilizam essa técnica. Na camada de enlace de dados, os pacotes de uma li- nha ponto a ponto podem ser codificados à medida que saem de uma máquina, e decodificados quando entram em outro sistema. Todos os detalhes podem ser tratados na camada de enlace de dados, com as camadas mais altas alheias ao que está acontecendo. No entanto, essa solução se mostra ineficiente quando os pacotes têm de atravessar vários roteadores, pois é necessário descriptografar os paco- tes em cada roteador, o que os torna vulneráveis a ataques dentro do roteador. Além disso, essa estratégia permite que algumas sessões sejam protegidas (por exemplo, aquelas que envolvem compras on-line por cartão de crédito) e ou- tras não. Todavia, a criptografia no nível do enlace de dados, como esse método é chamado, pode ser facilmente incluída em qualquer rede e com frequência é muito útil. Na camada de rede, podem ser instalados firewalls para manter ou descartar pacotes. A segurança do IP tam- bém funciona nessa camada. Na camada de transporte, é possível criptografar co- nexões inteiras ponto a ponto, ou seja, processo a proces- so. Para obter segurança máxima, é necessário que ela seja ponto a ponto. Por fim, questões como autenticação do usuário e não repúdio só podem ser tratadas na camada de aplicação. Tendo em vista que a segurança não se ajusta nitida- mente a nenhuma camada, ela também não se enquadra em nenhum capítulo deste livro. Por essa razão, merece seu próprio capítulo. Embora este capítulo seja longo, técnico e essencial, isso é quase irrelevante no momento. Por exemplo, está bem documentado o fato de que a maioria das falhas de se- gurança em bancos se deve a funcionários incompetentes, procedimentos de segurança negligentes, diversos bugs de implementação que permitem a invasão remota por usuá- rios não autorizados e os chamados ataques de engenharia social, nos quais os clientes são enganados para revelar os detalhes de sua conta. Todos esses problemas de segurança acontecem com mais frequência do que a ação de crimi- nosos inteligentes grampeando linhas telefônicas e depois decodificando mensagens criptografadas. Se uma pessoa puder entrar em uma agência bancária qualquer com uma tira de extrato de caixa eletrônico que encontrou na rua, afirmando que esqueceu sua senha e receber uma nova senha na mesma hora (em nome das boas relações com os clientes), nem toda criptografia do mundo evitará o abuso. Sobre esse aspecto, o livro de Ross Anderson (2008a) é um excelente alerta, pois documenta centenas de exemplos de falhas de segurança em numerosos setores, quase todas causadas por aquilo que se poderia chamar educadamente de práticas comerciais relaxadas ou desatenção com a segu- rança. Apesar disso, a base técnica sobre a qual o comércio eletrônico é montado, quando todos esses outros fatores são bem elaborados, é a criptografia. Com exceção da segurança na camada física, quase toda segurança se baseia em princípios criptográficos. Por essa razão, começaremos nosso estudo da seguran- ça examinando em detalhes a criptografia. Na Seção 8.1, veremos alguns princípios básicos. Da Seção 8.2 até a Se- ção 8.5, examinaremos alguns algoritmos e estruturas de dados fundamentais usados na criptografia. Em seguida, examinaremos em detalhes como esses conceitos podem ser usados para alcançar a segurança em redes. Conclui- remos com alguns conceitos breves sobre tecnologia e sociedade. Antes de começarmos, devemos chamar atenção para o que não será abordado neste capítulo. Procuramos nos concentrar em questões de redes, e não naquelas relacio- nadas ao sistema operacional e às aplicações, embora seja difícil traçar uma linha clara separando esses assuntos. Por exemplo, não há nada aqui sobre autenticação do usuário com a utilização da biometria, segurança de senhas, ata- ques por overflow de buffers, cavalos de Troia ou trojans, spoofing de login, inserção de código em scripts de sites, vírus, worms e temas semelhantes. Todos esses tópicos são abordados detalhadamente no Capítulo 9 do livro Modern Operating Systems (Tanenbaum, 2007). O leitor interessado 08_tanen0809_cap08 BR.indd 480 4/25/11 3:07 PM
- 3. Capítulo 8 Segurança deredes 481 deve consultar esse livro para conhecer os aspectos de se- gurança relacionados aos sistemas. Agora, vamos iniciar nossa jornada. 8.1 Criptografia A palavra criptografia vem de palavras gregas que sig- nificam ‘escrita secreta’. A criptografia tem uma longa e in- teressante história de milhares de anos. Nesta seção, vamos esquematizar alguns destaques, que serão usados como in- formações básicas para o que vem a seguir. Se desejar um histórico completo da criptografia, recomendamos a leitura do livro de Khan (1995). Para ver um tratamento completo do estado da arte em segurança e algoritmos criptográfi- cos, protocolos, aplicações e material relacionado, consulte Kaufman et al. (2002). Para uma abordagem mais mate- mática, consulte Stinson (2002). Se preferir uma aborda- gem menos matemática, consulte Burnett e Paine (2001). Os profissionais fazem distinção entre cifras e códigos. Uma cifra é uma transformação de caractere por caractere ou de bit por bit, sem levar em conta a estrutura linguística da mensagem. Em contrapartida, um código substitui uma palavra por outra palavra ou símbolo. Os códigos não são mais utilizados, embora tenham uma história gloriosa. O código mais bem-sucedido já inventado foi usado pelas for- ças armadas dos Estados Unidos durante a Segunda Guer- ra Mundial no Pacífico. Elas simplesmente tinham índios navajos que se comunicavam uns com os outros usando palavras em Navajo específicas para termos militares, como chay-dagahi-nail-tsaidi (literalmente, matador de cágado) para indicar uma arma antitanque. A linguagem navajo é altamente tonal, extremamente complexa, e não tem ne- nhuma forma escrita. Além disso, nem uma única pessoa no Japão conhecia alguma coisa sobre ela. Em setembro de 1945, o San Diego Union descreveu o código da seguinte forma: “Por três anos, onde quer que os marines aterrissassem, os japoneses recebiam uma en- xurrada de estranhos ruídos gorgolejantes entremeados com outros sons que lembravam o clamor de um mon- ge tibetano e o som de uma bolsa de água quente sendo esvaziada”. Os japoneses nunca conseguiram quebrar o código e muitos índios navajos receberam altas honras militares por serviço e bravura extraordinários. O fato de os Estados Unidos terem conseguido quebrar o código ja- ponês e os japoneses nunca terem conseguido quebrar o código navajo desempenhou um papel crucial nas vitórias norte-americanas no Pacífico. 8.1.1 Introdução à criptografia Historicamente, quatro grupos de pessoas utilizaram e contribuíram para a arte da criptografia: os militares, os diplomatas, as pessoas que gostam de guardar memórias e os amantes. Entre eles, os militares tiveram o papel mais importante e definiram as bases para a tecnologia. Nas organizações militares, as mensagens a ser criptografadas eram entregues habitualmente a auxiliares mal remunera- dos, que se encarregavam de criptografá-las e transmiti-las. O grande volume de mensagens impedia que esse trabalho fosse feito por alguns poucos especialistas. Até o advento dos computadores, uma das principais restrições impostas à criptografia era a habilidade do au- xiliar de criptografia para fazer as transformações neces- sárias, em geral com poucos equipamentos e no campo de batalha. Outra restrição era a dificuldade de alternar os métodos criptográficos rapidamente, pois isso exigia a re- petição do treinamento de um grande número de pessoas. No entanto, o perigo de um auxiliar de criptografia ser cap- turado pelo inimigo tornou indispensável a necessidade de alterar o método criptográfico instantaneamente, se preci- so. Essas necessidades conflitantes fizeram surgir o modelo da Figura 8.1. As mensagens a ser criptografadas, conhecidas como texto simples (ou plaintext), são transformadas por meio de uma função parametrizada por uma chave. Em seguida, Método de criptografia, E Intruso passivo: só escuta Intruso ativo: pode alterar mensagens Texto simples, P Texto simples, P Método de descriptografia, D Chave criptográfica, K Chave descriptográfica, K Texto cifrado, C = EK(P) Intruso Figura 8.1 O modelo de criptografia (para uma cifra de chave simétrica). 08_tanen0809_cap08 BR.indd 481 4/25/11 3:07 PM
- 4. 482 Redes decomputadores a saída do processo de criptografia, conhecida como texto cifrado (ou ciphertext), é transmitida, quase sempre por um mensageiro ou por rádio. Presumimos que o inimigo, ou intruso, ouça e copie cuidadosamente o texto cifrado completo. No entanto, ao contrário do destinatário preten- dido, ele não conhece a chave para descriptografar o texto e, portanto, não pode fazê-lo com muita facilidade. Às ve- zes, o intruso pode não só escutar o que se passa no canal de comunicação (intruso passivo) como também gravar mensagens e reproduzi-las mais tarde, injetar suas próprias ou modificar mensagens legítimas antes que elas cheguem ao receptor (intruso ativo). A arte de solucionar mensagens cifradas, conhecida como criptoanálise, e a arte de criar mensagens cifradas (criptografia) é chamada coletivamente criptologia. Com frequência, será útil e prático ter uma notação para estabelecer uma relação entre o texto simples, o texto cifrado e as chaves. Usaremos C = EK (P) para indicar que a criptografia do texto simples P usando a chave K gera o texto cifrado C. Da mesma forma, P = DK (C) representa a descriptografia de C para obter o texto simples outra vez. Então, temos: DK (EK (P)) = P Essa notação sugere que E e D são simplesmente fun- ções matemáticas, o que é verdade. A única parte compli- cada é que ambas são funções de dois parâmetros, e escre- vemos um desses parâmetros (a chave) como um caractere subscrito, em vez de representá-lo como um argumento, para distingui-lo da mensagem. Uma regra fundamental da criptografia é que se deve supor que o criptoanalista conhece os métodos genéricos de criptografia e descriptografia que são utilizados. Em ou- tras palavras, o criptoanalista conhece os detalhes de como funcionam o método de criptografia, E, e o método de des- criptografia D da Figura 8.1. O esforço necessário para criar, testar e instalar um novo algoritmo toda vez que o antigo método é (supostamente) comprometido sempre tornou impraticável manter o algoritmo criptográfico em segredo. Imaginar que esse algoritmo é secreto, quando não é, re- sulta mais em prejuízo do que em benefícios. É nesse ponto que entra a chave. A chave consiste em uma string (relativamente) curta que seleciona uma das muitas formas possíveis de criptografia. Ao contrário do método genérico, que só pode ser modificado a cada perío- do de alguns anos, a chave pode ser alterada sempre que necessário. Portanto, nosso modelo básico é um método genérico publicamente conhecido, parametrizado por uma chave secreta que pode ser alterada com facilidade. A ideia de que o criptoanalista conhece os algoritmos e que o se- gredo reside exclusivamente nas chaves é chamada princí- pio de Kerckhoff, em homenagem ao criptógrafo militar flamengo Auguste Kerckhoff que primeiro o enunciou em 1883 (Kerckhoff, 1883). Desse modo, temos: Princípio de Kerckhoff: Todos os algoritmos devem ser públi- cos; apenas as chaves são secretas Devemos enfatizar o caráter não sigiloso do algoritmo. Tentar manter o algoritmo secreto, uma estratégia conhe- cida no ramo como segurança pela obscuridade, nunca funciona. Além disso, ao tornar o algoritmo público, o es- pecialista em criptografia libera a consulta para inúmeros criptólogos ansiosos por decodificar o sistema e assim pu- blicar artigos demonstrando suas habilidades. Caso muitos especialistas tenham tentado decodificá-lo durante cinco anos após sua publicação e nenhum tenha conseguido, isso significa que o algoritmo é provavelmente sólido. Na verdade, o sigilo está na chave, e seu tamanho é uma questão muito importante do projeto. Considere uma fechadura de combinação simples. Segundo o princípio geral, você insere dígitos em sequência. Todo mundo sabe disso, mas a chave é secreta. Uma chave com um tamanho de dois dígitos significa que existem cem possibilidades. Uma de três dígitos significa mil possibilidades e uma de seis dígitos significa um milhão de possibilidades. Quanto maior for a chave, mais alto será o fator de trabalho com que o criptoanalista terá de lidar. O fator de trabalho para decodificar o sistema por meio de uma exaustiva pesquisa no espaço da chave é exponencial em relação a seu tama- nho. O sigilo é decorrente da presença de um algoritmo forte (mas público) e de uma chave longa. Para impedir que seu irmãozinho leia suas mensagens de correio eletrô- nico, serão necessárias chaves de 64 bits. Para uso comer- cial de rotina, devem ser usados pelo menos 128 bits. Para manter o governo de outros países à distância, são necessá- rias chaves de pelo menos 256 bits, de preferência maiores. Do ponto de vista do criptoanalista, o problema da criptoanálise apresenta três variações principais. Quando tem determinado volume de texto cifrado mas nenhum texto simples, o analista é confrontado com o problema do texto cifrado disponível. Os criptogramas da seção de palavras cruzadas do jornal são um exemplo desse tipo de problema. Quando há uma correspondência entre o texto cifrado e o texto simples, o problema passa a ser chamado de texto simples conhecido. Por fim, quando o cripto- analista tem a possibilidade de codificar trechos do texto simples escolhidos por ele mesmo, temos o problema do texto simples escolhido. Os criptogramas dos jornais po- deriam ser decodificados de forma trivial se o criptoanalista tivesse a permissão de fazer perguntas tais como: qual é a criptografia de ABCDEFGHIJKL? Com frequência, os novatos na área de criptografia pressupõem que, se uma cifra puder resistir a um ataque do texto cifrado disponível, isso significa que ela é segura. Essa suposição é muito ingênua. Em muitos casos, o crip- toanalista pode fazer uma estimativa com base em trechos do texto simples. Por exemplo, a primeira mensagem que muitos sistemas de tempo compartilhado emitem quando você os chama é ‘login:’. Equipado com alguns pares de 08_tanen0809_cap08 BR.indd 482 4/25/11 3:07 PM
- 5. Capítulo 8 Segurança deredes 483 texto simples/texto cifrado, o trabalho do criptoanalista se torna muito mais fácil. Para ter segurança, o autor da crip- tografia deve ser conservador e se certificar de que o siste- ma seja inviolável, mesmo que seu oponente seja capaz de criptografar o texto simples escolhido. Historicamente, os métodos de criptografia têm sido divididos em duas categorias: as cifras de substituição e as cifras de transposição. Em seguida, trataremos de cada uma dessas técnicas como informações básicas para a criptogra- fia moderna. 8.1.2 Cifras de substituição Em uma cifra de substituição, cada letra ou grupo de letras é substituído por outra letra ou grupo de letras, de modo a criar um ‘disfarce’. Uma das cifras mais antigas é a cifra de César, atribuída a Julio César. Nesse método, a se torna D, b se torna E, c se torna F,... e z se torna C. Por exemplo, ataque passaria a ser DWDTXH. Em nossos exemplos, o texto simples é apresentado em minúsculas e o texto cifrado em maiúsculas. Uma ligeira generalização da cifra de César permite que o alfabeto do texto cifrado seja deslocado k letras, em vez de três. Nesse caso, k passa a ser uma chave para o mé- todo genérico dos alfabetos deslocados em forma circular. A cifra de César pode ter enganado Pompeu, mas nunca mais enganou ninguém. O próximo aprimoramento é fazer com que cada um dos símbolos do texto simples, digamos, as 26 letras, seja mapeado para alguma outra letra. Por exemplo texto simples: a b c d e f g h i j k l m n o p q r s t u v w x y z texto cifrado: Q W E R T Y U I O P A S D F G H J K L Z X C V B N M Esse sistema geral é chamado cifra de substituição monoalfabética, sendo a chave a string de 26 letras cor- respondente ao alfabeto completo. Para a chave anterior, o texto simples ataque seria transformado no texto cifrado QZQJXT. À primeira vista, talvez esse sistema pareça seguro, pois, apesar de conhecer o sistema genérico (substituição de letra por letra), o criptoanalista não sabe qual das 26! ≈ 4 × 1026 chaves possíveis está em uso. Ao contrário do que acontece com a cifra de César, experimentar todas elas não é uma es- tratégia muito promissora. Mesmo a 1 ns por solução, um milhão de chips de computador em paralelo demandariam 10 mil anos para que todas as chaves fossem experimentadas. Todavia, com um volume de texto cifrado surpreen- dentemente pequeno, a cifra pode ser descoberta com fa- cilidade. A estratégia básica se beneficia das propriedades estatísticas dos idiomas. Por exemplo, em inglês e é a letra mais comum, seguida de t, o, a, n, i etc. As combinações de duas letras, ou digramas, mais comuns são th, in, er, re e an. As combinações de três letras, ou trigramas, mais comuns são the, ing, and e ion. Um criptoanalista que tente decodificar uma cifra mo- noalfabética começaria contando as frequências relativas de todas as letras do texto cifrado. Depois disso, por tenta- tivas, ele atribuiria e à letra mais comum e t à próxima letra mais comum. Em seguida, verificaria os trigramas para en- contrar um no formato tXe, o que poderia sugerir que X é h. Da mesma forma, se o padrão thYt ocorrer com frequên- cia, provavelmente isso significará que Y representa a. Com essas informações, o criptoanalista poderá procurar por um trigrama com o formato aZW que ocorra com frequência (muito provavelmente and). Fazendo estimativas em rela- ção a digramas, trigramas e letras mais comuns, e conhe- cendo os prováveis padrões de vogais e consoantes, o crip- toanalista criaria um texto simples através de tentativas, letra por letra. Outra estratégia é adivinhar uma palavra ou frase pro- vável. Por exemplo, considere o seguinte texto cifrado de uma empresa de contabilidade (montado em grupos de cinco caracteres): CTBMN BYCTC BTJDS QXBNS GSTJC BTSWX CTQTZ CQVUJ QJSGS TJQZZ MNQJS VLNSX VSZJU JDSTS JQUUS JUBXJ DSKSU JSNTK BGAQJ ZBGYQ TLCTZ BNYBN QJSW Nos Estados Unidos, uma palavra muito provável em uma mensagem de uma empresa de contabilidade é finan- cial. Com base em nosso conhecimento de que financial tem um caractere repetido (i), com quatro outras letras entre suas ocorrências, procuramos letras repetidas no texto ci- frado com esse espaço entre elas. Encontramos 12 casos como esse nas posições 6, 15, 27, 31, 42, 48, 56, 66, 70, 71, 76 e 82. No entanto, apenas dois deles, 31 e 42, têm a letra seguinte (que corresponde a n no texto simples) repetida na localização adequada. Dessas duas, apenas 31 também tem a letra a corretamente posicionada; portanto, sabemos que financial começa na posição 30. Desse ponto em diante, fica fácil deduzir a chave utilizando a estatística de frequência para o texto em inglês e procurando palavras quase com- pletas para terminar. 8.1.3 Cifras de transposição As cifras de substituição preservam a ordem dos sím- bolos no texto simples, mas os disfarçam. Por outro lado, as cifras de transposição reordenam as letras, mas não as disfarçam. A Figura 8.2 mostra uma cifra de transposi- ção muito comum, a de colunas. A cifra se baseia em uma chave que é uma palavra ou frase que não contém letras repetidas. Nesse exemplo, a chave é MEGABUCK. O obje- tivo da chave é numerar as colunas de modo que a coluna 1 fique abaixo da letra da chave mais próxima do início do 08_tanen0809_cap08 BR.indd 483 4/25/11 3:07 PM
- 6. 484 Redes decomputadores alfabeto e assim por diante. O texto simples é escrito hori- zontalmente, em linhas. O texto cifrado é lido em colunas, a partir da coluna cuja letra da chave seja a mais baixa. Para quebrar uma cifra de transposição, o criptoanalis- ta deve primeiro estar ciente de lidar com tal cifra. Ao exa- minar a frequência de E, T, A, O, I, N etc., fica fácil consta- tar se essas letras se encaixam no padrão normal para texto simples. Se houver correspondência, isso significa que se trata sem dúvida de uma cifra de transposição, pois nesse tipo de cifra cada letra é representada por ela mesma, man- tendo intacta a distribuição de frequências. A próxima etapa é fazer uma estimativa do número de colunas. Em muitos casos, uma palavra ou frase provável pode ser deduzida a partir do contexto da mensagem. Por exemplo, suponha que nosso criptoanalista tenha suspei- tado de que a frase em texto simples milliondollars ocorre em algum lugar na mensagem. Observe que os digramas MO, IL, LL, LA, IR e OS ocorrem no texto cifrado como um resultado do desdobramento dessa frase. No texto ci- frado, a letra O vem depois da letra M (ou seja, elas são verticalmente adjacentes na coluna 4), pois estão separadas na provável frase por uma distância igual ao tamanho da chave. Se tivesse sido usada uma chave de tamanho sete, teriam surgido os digramas MD, IO, LL, LL, IA, OR e NS. Na verdade, para cada tamanho de chave, é produzido um conjunto de digramas diferente no texto cifrado. Ao tentar encontrar diferentes possibilidades, muitas vezes o criptoa nalista é capaz de determinar com facilidade o tamanho da chave. A última etapa é ordenar as colunas. Quando o núme- ro de colunas k é pequeno, cada um dos k(k - 1) pares de colunas pode ser examinado para que se constate se suas frequências de digramas correspondem às do texto simples em inglês. O par que tiver a melhor correspondência será considerado na posição correta. Em seguida, cada uma das colunas restantes é experimentada como sucessora desse par. A coluna cujas frequências de digramas e trigramas proporcionem a melhor correspondência será a título ex- perimental considerada correta. A próxima coluna é en- contrada da mesma maneira. O processo inteiro continua até ser encontrada uma ordenação potencial. O mais pro- vável é que o texto simples seja reconhecido nesse ponto (por exemplo, se ocorrer milloin, ficará claro qual é o erro). Algumas cifras de transposição aceitam um bloco de tamanho fixo como entrada e produzem um bloco de ta- manho fixo como saída. Essas cifras podem ser comple- tamente descritas fornecendo-se uma lista que informe a ordem na qual os caracteres devem sair. Por exemplo, a cifra da Figura 8.2 pode ser vista como uma cifra de blocos de 64 caracteres. Sua saída é 4, 12, 20, 28, 36, 44, 52, 60, 5, 13,..., 62. Em outras palavras, o quarto caractere de en- trada, a, é o primeiro a sair, seguido pelo décimo segundo, f, e assim por diante. 8.1.4 Chave única Na verdade, é fácil criar uma cifra inviolável; a técnica é conhecida há décadas. Primeiro, escolha como chave uma sequência de bits aleatórios. Em seguida, converta o texto simples em uma sequência de bits, utilizando por exemplo sua representação ASCII. Por fim, calcule o OU exclusivo (XOR) dessas duas sequências. O texto cifrado resultante não pode ser violado porque, em uma amostra grande o suficiente de texto cifrado, cada letra ocorrerá com a mes- ma frequência, bem como o digrama, o trigrama e assim por diante. Esse método, conhecido como chave única, é imune a todos os ataques presentes e futuros, não importa quanta capacidade computacional tenha o intruso. A razão deriva da teoria da informação: simplesmente não existe ne- nhuma informação na mensagem, todos os textos simples possíveis com o tamanho dado são igualmente prováveis. Um exemplo de como as chaves únicas são usadas é dado na Figura 8.3. Primeiro, a mensagem 1, ‘I love you’, é con- vertida em ASCII de 7 bits. Em seguida, uma chave única, chamada chave 1, é escolhida e sujeita à operação XOR com a mensagem para obter o texto cifrado. Um criptoanalista po- deria experimentar todas as chaves únicas possíveis para ver que texto resultou para cada uma. Por exemplo, a chave úni- ca listada como chave 2 na figura poderia ser experimentada, resultando no texto simples 2, ‘Elvis lives’ [Elvis não morreu], que pode ser ou não plausível (um assunto que está além do escopo deste livro). De fato, para cada texto simples ASCII de 11 caracteres, existe uma chave única que o gera. É isso que queremos dizer quando mencionamos que não existe ne- nhuma informação no texto cifrado: é possível obter qualquer mensagem com o tamanho correto a partir dele. As chaves únicas são ótimas na teoria, mas têm várias desvantagens na prática. Para começar, não pode ser me- morizada; então, tanto o remetente quanto o destinatário devem levar uma cópia escrita com eles. Se qualquer um dos dois estiver sujeito à possibilidade de captura, as chaves es- critas sem dúvida serão inconvenientes. Além disso, a quan- tidade total de dados que podem ser transmitidos é limitada pelo tamanho da chave disponível. Se o espião tiver muita sorte e descobrir uma grande quantidade de dados, talvez M E G A B U C K 7 4 5 1 2 8 3 6 p l e a s e t r Texto simples pleasetransferonemilliondollarsto myswissbankaccountsixtwotwo Texto cifrado AFLLSKSOSELAWAIATOOSSCTCLNMOMANT ESILYNTWRNNTSOWDPAEDOBUOERIRICXB a n s f e r o n e m i l l i o n d o l l a r s t o m y s w i s s b a n k a c c o u n t s i x t w o t w o a b c d Figura 8.2 Uma cifra de transposição. 08_tanen0809_cap08 BR.indd 484 4/25/11 3:07 PM
- 7. Capítulo 8 Segurança deredes 485 seja incapaz de transmiti-los de volta para a matriz, porque a chave terá sido consumida. Outro problema é a sensibili- dade do método para caracteres perdidos ou inseridos. Se o transmissor e o receptor ficarem fora de sincronismo, todos os dados a partir desse momento se parecerão com lixo. Com o advento dos computadores, a chave única se tornou potencialmente prática para algumas aplicações. A origem da chave poderia ser um DVD especial contendo vários gigabytes de informações que, se fossem transpor- tadas em uma caixa de filmes em DVD e tivessem no iní- cio alguns minutos de vídeo, nem sequer seriam suspeitas. É claro que, nas redes de gigabits, ter de inserir um novo DVD a cada 30 segundos seria algo entediante. Além disso, os DVDs devem ser transportados em mãos, do transmissor para o receptor, antes de ser possível enviar qualquer men- sagem, o que reduz bastante sua utilidade prática. Criptografia quântica É interessante, mas talvez haja uma solução para o problema de como transmitir a chave única pela rede, e ela vem de uma fonte muito improvável: a mecânica quântica. Essa área ainda é experimental, mas os testes iniciais são promissores. Se eles puderem ser aperfeiçoados e se tor- narem eficientes, quase toda a criptografia será realizada por fim com a utilização de chaves únicas, pois é provável que elas sejam seguras. A seguir, explicaremos em linhas gerais como funciona esse método, denominado cripto- grafia quântica. Em particular, descreveremos um proto- colo chamado BB84 para indicar seus autores e o ano da publicação (Bennet e Brassard, 1984). Uma usuária chamada Alice quer estabelecer uma cha- ve única com um segundo usuário, Bob. Alice e Bob são chamados protagonistas, os personagens principais de nossa história. Por exemplo, Bob é um gerente de banco com quem Alice gostaria de realizar negócios. Os nomes ‘Alice’ e ‘Bob’ foram usados como protagonistas em prati- camente todos os ensaios e livros sobre criptografia desde que Ron Rivest os apresentou há muitos anos (Rivest et al., 1978). Os criptógrafos amam a tradição. Se fôssemos usar ‘Andy’ e ‘Barbara’ como protagonistas, ninguém acredita- ria em nada do que fosse explicado neste capítulo. Então, que seja! Se Alice e Bob pudessem estabelecer uma chave úni- ca, eles teriam a possibilidade de empregá-la para se co- municar com segurança. A pergunta é: como eles podem estabelecê-la sem antes trocar DVDs? Podemos supor que Alice e Bob estejam em extremidades opostas de um cabo de fibra óptica pelo qual possam enviar e receber pulsos de luz. Porém, uma intrusa atrevida chamada Trudy pode cortar a fibra e criar um grampo ativo. Trudy pode ler todos os bits em ambos os sentidos. Ela também pode enviar fal- sas mensagens nos dois sentidos. A situação pode parecer desesperadora para Alice e Bob, mas a criptografia quântica pode trazer uma nova luz sobre o assunto. A criptografia quântica se baseia no fato de que a luz se propaga em pequenos pacotes chamados fótons, que apresentam algumas propriedades peculiares. Além disso, a luz pode ser polarizada ao passar por um filtro de pola- rização, um fato bem conhecido pelos usuários de óculos de sol e pelos fotógrafos. Se um feixe de luz (isto é, um fluxo de fótons) passar por um filtro de polarização, todos os fótons que emergirem dele serão polarizados na direção do eixo do filtro (por exemplo, vertical). Se o feixe passar agora por um segundo filtro de polarização, a intensidade da luz que emergirá do segundo filtro será proporcional ao quadrado do cosseno do ângulo entre os eixos. Se os dois eixos forem perpendiculares, nenhum fóton passará pelo filtro. A orientação absoluta dos dois filtros não importa; só interessa o ângulo entre seus eixos. Para gerar uma chave única, Alice precisa de dois conjuntos de filtros de polarização. O primeiro conjunto consiste em um filtro vertical e um filtro horizontal. Essa escolha é chamada base retilínea. Uma base é apenas um sistema de coordenadas. O segundo conjunto de filtros é idêntico, exceto por estar deslocado 45 graus, de forma que um filtro abrange desde o canto inferior esquerdo até o canto superior direito, e o outro abrange desde o canto superior esquerdo até o canto inferior direito. Essa escolha é chamada base diagonal. Desse modo, Alice tem duas ba- ses, que ela pode inserir rapidamente em seu feixe, à von- tade. Na realidade, ela não tem quatro filtros separados, mas um cristal, cuja polarização pode ser trocada eletrica- mente para qualquer das quatro direções permitidas, em alta velocidade. Bob tem o mesmo equipamento de Alice. Mensagem 1: 1001001 0100000 1101100 1101111 1110110 1100101 0100000 1111001 1101111 1110101 0101110 Chave 1: 1010010 1001011 1110010 1010101 1010010 1100011 0001011 0101010 1010111 1100110 0101011 Texto cifrado: 0011011 1101011 0011110 0111010 0100100 0000110 0101011 1010011 0111000 0010011 0000101 Chave 2: 1011110 0000111 1101000 1010011 1010111 0100110 1000111 0111010 1001110 1110110 1110110 Texto simples 2: 1000101 1101100 1110110 1101001 1110011 0100000 1101100 1101001 1110110 1100101 1110011 Figura 8.3 O uso de uma chave única para criptografia e a possibilidade de conseguir qualquer texto simples que seja possível a partir do texto cifrado pela utilização de alguma outra chave. 08_tanen0809_cap08 BR.indd 485 4/25/11 3:07 PM
- 8. 486 Redes decomputadores O fato de Alice e Bob terem cada um duas bases disponíveis é essencial para a criptografia quântica. Para cada base, Alice atribui agora uma direção como 0 e a outra como 1. No exemplo apresentado a seguir, vamos supor que ela escolha a direção vertical como 0 e a hori- zontal como 1. Independentemente, ela também escolhe do canto inferior esquerdo até o canto superior direito como 0, e do canto superior esquerdo até o canto inferior direito como 1. Alice envia essas escolhas a Bob como texto simples. Agora, Alice escolhe uma chave única, baseada, por exemplo, em um gerador de números aleatórios (um as- sunto por si só bastante complexo). Ela o transfere bit por bit para Bob, escolhendo uma de suas bases ao acaso para cada bit. Para enviar um bit, sua pistola de fótons emite um fóton polarizado de maneira apropriada, conforme a base que ela está usando para esse bit. Por exemplo, ela poderia escolher as bases diagonal, retilínea, retilínea, dia- gonal, retilínea etc. Para enviar sua chave única igual a 1001110010100110 com essas bases, ela enviaria os fótons mostrados na Figura 8.4(a). Dadas a chave única e a sequ- ência de bases, a polarização a ser usada para cada bit é determinada de forma exclusiva. Bits enviados um fóton por vez são chamados qubits (bits quânticos). Bob não sabe que base usar, e assim escolhe uma ao acaso para cada fóton que chega e simplesmente a utiliza, como mostra a Figura 8.4(b). Se escolher a base correta, ele receberá o bit correto. Se escolher a base incorreta, receberá um bit aleatório porque, se um fóton acessar um filtro pola- rizado a 45 graus em relação a sua própria polarização, ele saltará ao acaso para a polarização do filtro ou para uma po- larização perpendicular à do filtro, com igual probabilidade. Essa propriedade dos fótons é fundamental para a mecânica quântica. Desse modo, alguns bits estão corretos e alguns são aleatórios, mas Bob não consegue distingui-los. Os re- sultados de Bob estão representados na Figura 8.4(c). De que maneira Bob pode descobrir quais são as bases corretas e quais são as erradas entre as que recebeu? Ele apenas diz a Alice que base usou para cada bit em texto simples, e ela lhe diz quais são as bases corretas e quais são as erradas em texto simples, como mostra a Figura 8.4(d). A partir dessas informações, ambos podem construir uma sequência de bits com os palpites corretos, como mostra a Figura 8.4(e). Em média, essa sequência de bits terá metade do comprimento da sequência de bits original, mas, como ambas as partes o conhecem, elas poderão usá-lo como uma chave única. Tudo o que Alice tem a fazer é transmitir uma sequência de bits um pouco maior que o dobro do ta- manho desejado, para que ela e Bob tenham uma chave única com o comprimento apropriado. Problema resolvido. Mas espere um minuto. Esquecemos de Trudy. Vamos supor que ela esteja curiosa para saber o que Alice tem a dizer e corte o cabo de fibra, inserindo seus próprios detector e transmissor. Infelizmente para Trudy, ela também não sabe que base usar para cada fóton. O melhor que ela pode fazer é escolher uma base ao acaso para cada um dos fótons, como fez Bob. Um exemplo de suas escolhas é mostrado na Figura 8.4(f). Quando mais tarde Bob informar (em texto simples) que bases usou e Alice disser a ele (em texto simples) quais delas estão corretas, Trudy saberá quando acertou e quando errou. Segundo a Figura 8.4, ela acertou nos bits 0, 1, 2, 3, Chave de Trudy (g) x 0 x 1 x x x ? 1 x ? ? 0 x ? 0 1 0 1 1 0 0 1 x Não Sim Não Sim Não Não Não Sim Sim Não Sim Sim Sim Não Sim Não Número do bit Dados Bases de Trudy (f) Chave única (e) Base correta? (d) O que Bob recebe (c) Bases de Bob (b) O que Alice envia (a) 1 0 0 1 1 1 0 0 1 0 1 0 0 1 1 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Figura 8.4 Um exemplo de criptografia quântica. 08_tanen0809_cap08 BR.indd 486 4/25/11 3:07 PM
- 9. Capítulo 8 Segurança deredes 487 4, 6, 8, 12 e 13. No entanto, ela sabe pela resposta de Alice na Figura 8.4(d) que só os bits 1, 3, 7, 8, 10, 11, 12 e 14 fazem parte da chave única. Em quatro desses bits (1, 3, 8 e 12), ela acertou seu palpite e capturou o bit correto. Nos outros quatro (7, 10, 11 e 14), ela errou e não sabe qual bit foi transmitido. Desse modo, Bob sabe que a chave única começa com 01011001, a partir da Figura 8.4(e), mas tudo que Trudy tem é 01?1??0?, a partir da Figura 8.4(g). É claro que Alice e Bob estão cientes de que Trudy talvez tenha captado parte de sua chave única, e assim gostariam de reduzir as informações que ela tem. Eles podem fazer isso executando uma transformação na chave. Por exem- plo, poderiam dividir a chave única em blocos de 1.024 bits e elevar ao quadrado cada uma para formar um número de 2.048 bits, usando a concatenação desses números de 2.048 bits como a chave única. Com seu conhecimento parcial da sequência de bits transmitida, Trudy não tem como gerar seu quadrado e, portanto, não tem nada. A transformação da chave única original em uma chave diferente que redu- za o conhecimento de Trudy é chamada amplificação de privacidade. Na prática, são usadas transformações com- plexas em que todo bit de entrada depende de cada bit de saída em vez do quadrado do bit de entrada. Pobre Trudy. Ela não apenas não tem nenhuma ideia de qual é a chave única, como também sua presença não é mais secreta. Afinal, ela tem de retransmitir cada bit recebido para Bob, a fim de levá-lo a pensar que está se comunicando com Alice. Porém, o melhor que pode fazer é transmitir o qubit que recebeu usando a mesma polarização que empregou para recebê-lo, e durante cerca de metade do tempo ela esta- rá errada, provocando muitos erros na chave única de Bob. Quando finalmente começar a transmitir dados, Alice os codificará usando um pesado código de correção ante- cipada de erros. Do ponto de vista de Bob, um erro de 1 bit na chave única é o mesmo que um erro de transmissão de 1 bit. De qualquer modo, ele receberá o bit errado. Se houver correção antecipada de erros suficiente, ele poderá recuperar a mensagem original apesar de todos os erros, mas poderá contar com facilidade quantos erros foram cor- rigidos. Se esse número for muito maior que a taxa de erros esperada do equipamento, ele saberá que Trudy grampeou a linha e poderá tomar providências (por exemplo, infor- mando Alice de que ela deve mudar para um canal de rá- dio, chamar a polícia etc.). Se Trudy tivesse um meio de clonar fótons, de forma que tivesse um para inspecionar e um idêntico para enviar a Bob, poderia evitar a detecção, mas no momento não se conhece nenhum modo perfeito de clonar um fóton. No entanto, mesmo que Trudy pudes- se fazê-lo, o valor da criptografia quântica para estabelecer chaves únicas não seria reduzido. Embora a criptografia quântica opere sobre distâncias de até 60 km de fibra, o equipamento é complexo e dispen- dioso. Ainda assim, a ideia é promissora. Para obter mais informações sobre a criptografia quântica, consulte Mullins (2002). 8.1.5 Dois princípios fundamentais da criptografia Ainda estudaremos muitos sistemas criptográficos nas próximas páginas, mas é importante entender dois princí- pios básicos subjacentes a todos eles. Preste atenção. Você correrá risco ao violá-los. Redundância O primeiro princípio é que todas as mensagens crip- tografadas devem conter alguma redundância, ou seja, in- formações que não são necessárias para a compreensão da mensagem. Talvez um exemplo esclareça por que isso é ne- cessário. Considere uma empresa de encomendas postais, a Expresso Jabuti (EJ), com 60 mil produtos. Pensando ser muito eficientes, os programadores da EJ decidiram que as mensagens de encomendas devem consistir no nome do cliente com 16 bytes, seguido por um campo de dados de 3 bytes (um para a quantidade e dois para o número do produto). Os 3 últimos bytes devem ser criptografados por meio de uma chave muito longa conhecida apenas pelo cliente e pela EJ. A princípio, essa estratégia pode parecer segura, e até certo ponto isso acontece, porque os intrusos passivos não podem descriptografar as mensagens. Infelizmente, há uma falha fatal que a torna inútil. Suponha que uma funcioná- ria recém-demitida queira punir a EJ por tê-la despedido. Antes de sair da empresa, ela leva consigo parte da lista de clientes e passa a noite acordada criando um programa para gerar encomendas fictícias utilizando nomes de clien- tes verdadeiros. Como não tem a lista das chaves, ela sim- plesmente inclui números aleatórios nos três últimos bytes e envia centenas de encomendas para a EJ. Quando as mensagens chegam, o computador da EJ utiliza o nome do cliente para localizar a chave e descripto- grafar a mensagem. Infelizmente para a EJ, quase todas as mensagens de 3 bytes são válidas; portanto, o computador começa a imprimir as instruções de entrega. Apesar de pa- recer estranho um cliente encomendar 837 conjuntos de balanços para crianças, ou 540 caixas de areia, para o com- putador, o cliente pode estar planejando abrir uma cadeia de parques de diversões por franquia. Portanto, um intru- so ativo (a ex-funcionária) pode causar muitos problemas, mesmo que não seja capaz de entender as mensagens que seu computador está gerando. Esse problema pode ser resolvido por meio da inclu- são de informações redundantes em todas as mensagens. Por exemplo, se as mensagens de pedidos forem amplia- das para 12 bytes, os 9 primeiros deverão ser iguais a zero; assim, essa estratégia de ataque deixa de ser interessante, porque a ex-funcionária não é mais capaz de gerar um lon- go fluxo de mensagens válidas. A moral da história é que todas as mensagens devem conter informações redundan- tes suficientes para que os intrusos ativos sejam impedidos de transmitir dados inválidos que possam ser interpretados como uma mensagem válida. 08_tanen0809_cap08 BR.indd 487 4/25/11 3:07 PM
- 10. 488 Redes decomputadores No entanto, a inclusão de informações redundantes também facilita a quebra de mensagens por parte dos criptoanalistas. Suponha que o negócio de encomenda postal seja muito competitivo e que a principal concorren- te da Expresso Jabuti, a Tartaruga Entregas, adoraria saber quantas caixas de areia a EJ está vendendo. Para isso, re- solve grampear a linha telefônica da EJ. No esquema ori- ginal com mensagens de 3 bytes, a criptoanálise era prati- camente impossível porque, após descobrir uma chave, o criptoanalista não era capaz de dizer se a mensagem esta- va correta. Afinal de contas, quase todas as mensagens são tecnicamente válidas. Com o novo esquema de 12 bytes, fica mais fácil para o criptoanalista distinguir uma mensa- gem válida de uma inválida. Desse modo, temos: Princípio criptográfico 1: as mensagens devem conter alguma redundância Em outras palavras, ao decifrar uma mensagem, o destinatário deve ser capaz de saber se ela é válida, sim- plesmente inspecionando-a e talvez executando uma com- putação simples. Essa redundância é necessária para impe- dir que intrusos ativos enviem lixo e enganem o receptor, fazendo-o descriptografar o lixo e agir sobre o ‘texto sim- ples’. No entanto, essa mesma redundância permite que os intrusos passivos entrem no sistema com maior facilidade; portanto, há uma zona de tensão nessa situação. Além dis- so, a redundância nunca deverá ser criada sob a forma de n zeros no início ou no fim de uma mensagem, pois o envio dessas mensagens a determinados algoritmos criptográfi- cos proporciona resultados mais previsíveis, facilitando o trabalho do criptoanalista. Um polinômio de CRC é muito melhor que uma sequência de valores zero, pois o receptor pode verificá-lo facilmente, mas gerará mais trabalho para o criptoanalista. Seria muito melhor usar um hash cripto- gráfico, conceito que exploraremos mais adiante. Por en- quanto, pense nele como um CRC melhor. Voltando à criptografia quântica por um momento, também podemos ver como a redundância desempenha um papel importante. Devido à interceptação dos fótons por Trudy, alguns bits na chave única de Bob estarão er- rados. Bob precisa de alguma redundância nas mensagens de entrada para descobrir os erros presentes. Uma forma muito rudimentar de redundância é repetir a mensagem duas vezes. Se as duas cópias não forem idênticas, Bob saberá que a fibra tem muito ruído, ou que alguém está interferindo na transmissão. É claro que enviar tudo duas vezes é um exagero; um código de Hamming ou de Reed- -Solomon é um modo mais eficiente de realizar a detecção e correção de erros. Porém, deve ficar claro que alguma redundância é necessária para distinguir uma mensagem válida de uma mensagem inválida, em especial diante de um intruso ativo. Atualidade O segundo princípio criptográfico é tomar algumas medidas para assegurar que cada mensagem recebida pos- sa ser confirmada como uma mensagem atual, isto é, en- viada muito recentemente. Essa medida é necessária para impedir que intrusos ativos reutilizem mensagens antigas. Se tais medidas não fossem tomadas, nossa ex-funcionária poderia interceptar a linha telefônica da EJ e ficar simples- mente repetindo mensagens válidas já enviadas. Assim: Princípio criptográfico 2: algum método é necessário para anular ataques de repetição Uma medida desse tipo seria incluir em cada mensa- gem um registro de tempo válido apenas por, digamos, 10 segundos. Em seguida, o receptor poderia manter as men- sagens durante 10 segundos, a fim de comparar as mensa- gens recém-chegadas com as anteriores e filtrar duplicatas. As mensagens transmitidas há mais de 10 segundos pode- riam ser descartadas, pois as repetições enviadas mais de 10 segundos depois da mensagem original serão rejeitadas por ser muito antigas. Outras medidas além dos registros de tempo serão discutidas mais adiante. 8.2 Algoritmos de chave simétrica Embora a criptografia moderna utilize as mesmas ideias básicas da criptografia tradicional (transposição e substituição), sua ênfase é diferente. Tradicionalmente, os criptógrafos têm utilizado algoritmos simples. Hoje em dia, acontece o inverso: o objetivo é tornar o algoritmo de crip- tografia tão complexo e emaranhado que, mesmo que o criptoanalista adquira enormes volumes de texto cifrado a sua própria escolha, sem a chave ele não seja capaz de en- tender nada do que conseguir. A primeira classe de algoritmos de criptografia que es- tudaremos neste capítulo é a dos algoritmos de chave si- métrica, porque utilizam a mesma chave para codificação e decodificação. A Figura 8.1 ilustra o uso de um algoritmo de chave simétrica. Em particular, vamos nos concentrar nos blocos de cifras, que obtêm um bloco de n bits de tex- to simples como entrada e o transformam usando a chave em um bloco de n bits de texto cifrado. Os algoritmos criptográficos podem ser implementados em hardware (para obter velocidade) ou em software (para obter flexibilidade). Embora a maior parte de nosso trata- mento esteja relacionado aos algoritmos e protocolos, que são independentes da implementação real, algumas pala- vras sobre a construção de hardware criptográfico podem ser interessantes. As transposições e substituições podem ser implementadas com circuitos elétricos simples. A Fi- gura 8.5(a) mostra um dispositivo, conhecido como caixa P (onde P significa permutação), usado para efetuar uma transposição em uma entrada de 8 bits. Se os 8 bits forem 08_tanen0809_cap08 BR.indd 488 4/25/11 3:07 PM
- 11. Capítulo 8 Segurança deredes 489 designados de cima para baixo como 01234567, a saída des- sa caixa P específica será 36071245. Com uma conexão in- terna adequada, pode-se criar uma caixa P para executar qualquer transposição praticamente na velocidade da luz, pois nenhuma computação é envolvida, apenas a propaga- ção de sinais. Esse projeto segue o princípio de Kerckhoff: o atacante sabe que o método geral é permutar os bits. O que ele não sabe é qual bit fica em cada posição. As substituições são realizadas por caixas S, como mos- tra a Figura 8.5(b). Nesse exemplo, é introduzido um texto simples de 3 bits, e a saída é um texto cifrado de 3 bits. A entrada de 3 bits seleciona uma das oito linhas de saída do primeiro estágio e a define como 1; todas as outras são iguais a 0. O segundo estágio é uma caixa P. O terceiro estágio codi- fica a linha selecionada novamente em binário. Com a cone- xão interna mostrada, se os oito números octais 01234567 fossem introduzidos um após o outro, a sequência de saída seria 24506713. Em outras palavras, 0 foi substituído por 2, 1 foi substituído por 4 etc. Mais uma vez, com a conexão apropriada da caixa P dentro da caixa S, qualquer substitui- ção pode ser realizada. Além disso, tal dispositivo pode ser construído em hardware e consegue alcançar grande veloci- dade, pois os codificadores e os decodificadores têm apenas um ou dois atrasos nas interfaces de entrada e saída (abaixo de um nanossegundo) e o tempo de propagação pela caixa P pode ser menor que 1 picossegundo. A capacidade real desses elementos básicos se torna aparente quando dispomos uma série inteira de caixas em cascata para formar uma cifra-produto, como mostra a Figura 8.5(c). Nesse exemplo, 12 linhas de entrada são transpostas (isto é, permutadas) pelo primeiro estágio (P1 ). No segundo estágio, a entrada é dividida em quatro grupos de 3 bits, sendo que cada um deles é substituído de forma independente dos outros (S1 a S4 ). Esse arranjo mostra um método de aproximar uma caixa S maior a partir de várias caixas S menores. Ele é útil porque caixas S menores são práticas para a implementação pelo hardware (por exem- plo, uma caixa S de 8 bits pode ser observada como uma tabela de pesquisa de 256 entradas), mas caixas S grandes se tornam difíceis de criar (por exemplo, uma caixa S de 12 bits, no mínimo, precisaria de 212 = 4.096 fios cruzados em seu estágio intermediário). Apesar de ser menos gené- rico, esse método ainda é poderoso. Através da inclusão de um número de estágios suficientemente grande na cifra- -produto, a saída pode ser transformada em uma função excessivamente complicada da entrada. As cifras-produto que operam sobre entradas de k bits para produzir saídas de k bits são muito comuns. Em geral, o valor de k varia de 64 a 256. Uma implementação de hardware normalmente tem pelo menos 18 estágios físicos, em vez de apenas sete, como na Figura 8.5(c). Uma imple- mentação de software é programada como um loop com pelo menos 8 iterações, cada uma executando substituições semelhantes às de caixas S em sub-blocos do bloco de da- dos de 64 bits a 256 bits, seguidas por uma permutação que mistura as saídas das caixas S. Com frequência, existe uma permutação especial no início e também uma no fim. Na literatura, as repetições são chamadas rodadas. 8.2.1 DES — Data Encryption Standard Em janeiro de 1977, o governo dos Estados Unidos adotou uma cifra-produto desenvolvida pela IBM como seu padrão oficial para informações não confidenciais. A cifra, o padrão de criptografia de dados, ou DES (Data En- cryption Standard), foi amplamente adotada pelo setor de informática para uso em produtos de segurança. Em sua forma original, ela já não é mais segura; no entanto, em uma forma modificada ela ainda é útil. Agora, vamos ex- plicar como o DES funciona. Na Figura 8.6(a), mostramos um esboço do DES. O texto simples é criptografado em blocos de 64 bits, produ- zindo 64 bits de texto cifrado. O algoritmo, parametrizado por uma chave de 56 bits, tem 19 estágios distintos. O pri- meiro deles é uma transposição independente da chave no texto simples de 64 bits. O último estágio é exatamente o inverso dessa transposição. O penúltimo estágio troca os 32 bits mais à esquerda pelos 32 bits mais à direita. Os 16 estágios restantes são funcionalmente idênticos, mas são parametrizados por diferentes funções da chave. O algo- ritmo foi projetado para permitir que a decodificação fosse feita com a mesma chave da codificação, uma propriedade necessária em qualquer algoritmo de chave simétrica. As etapas são executadas na ordem inversa. A operação desses estágios intermediários é ilustrada na Figura 8.6(b). Cada estágio utiliza duas entradas de 32 bits e S1 S2 P1 P4 P3 P2 S3 S4 S5 S6 S7 S8 Cifra-produto (c) Caixa S Decodificador: 3 para 8 Codificador: 8 para 3 (b) Caixa P (a) S9 S10 S11 S12 Figura 8.5 Elementos básicos das cifras-produto. (a) Caixa P. (b) Caixa S. (c) Produto. 08_tanen0809_cap08 BR.indd 489 4/25/11 3:07 PM
- 12. 490 Redes decomputadores produz duas saídas de 32 bits. A saída da esquerda é apenas uma cópia da saída da direita. A saída da direita é formada pelo resultado do OU exclusivo bit a bit aplicado à entrada da esquerda e a uma função de entrada da direita com a chave desse estágio, Ki . Toda a complexidade reside nessa função. A função consiste em quatro etapas, executadas em se- quência. Primeiro, um número de 48 bits, E, é construído através da expansão do Ri -1 de 32 bits, de acordo com uma regra fixa de transposição e duplicação. Em segundo lugar, E e Ki são submetidos a uma operação XOR. Em seguida, essa saída é dividida em oito grupos de 6 bits, sendo cada um deles entregue a uma caixa S diferente. Cada uma das 64 en- tradas possíveis para uma caixa S é mapeada em uma saída de 4 bits. Por fim, esses 8 × 4 bits passam por uma caixa P. Em cada uma das 16 iterações, é utilizada uma chave diferente. Antes de se iniciar o algoritmo, é aplicada à cha- ve uma transposição de 56 bits. Antes de cada iteração, a chave é particionada em duas unidades de 28 bits, sendo cada uma delas girada à esquerda um número de bits que depende do número da iteração. Ki é derivada dessa chave girada, pela aplicação de mais uma transposição de 56 bits sobre ela. Em cada rodada, um novo subconjunto de 48 bits dos 56 bits é extraído e permutado. Uma técnica às vezes utilizada para tornar o DES mais forte é chamada clareamento. Ela consiste em operação XOR entre uma chave aleatória de 64 bits e cada bloco de texto simples, antes de sua entrega ao DES, e depois em uma operação XOR entre uma segunda chave de 64 bits e o texto cifrado resultante, antes de sua transmissão. O clarea- mento pode ser removido com facilidade pela execução das operações inversas (se o receptor tiver as duas chaves de clareamento). Como essa técnica acrescenta efetivamente mais bits ao tamanho da chave, ela torna uma pesquisa exaustiva do espaço de chaves muito mais demorada. Ob- serve que a mesma chave de clareamento é utilizada para cada bloco (isto é, só existe uma chave de clareamento). O DES esteve envolvido em controvérsias desde seu lançamento. Ele se baseia em uma cifra desenvolvida e pa- tenteada pela IBM, cujo nome é Lucifer. A diferença é que a cifra da IBM utilizava uma chave de 128 bits, em vez de uma chave de 56 bits. Quando quis padronizar o uso de uma cifra para informações não confidenciais, o governo dos Estados Unidos ‘convidou’ a IBM para ‘discutir’ o pro- blema com a NSA, o órgão do governo especializado em decifrar códigos, que é o maior empregador de matemá- ticos e criptólogos do mundo. A NSA é tão secreta que no setor existe a seguinte brincadeira com seu nome: P: O que significa NSA? R: No Such Agency (em português: não existe tal agência). Na verdade, NSA significa National Security Agency (Agên- cia de Segurança Nacional). Após essas discussões, a IBM reduziu a chave de 128 para 56 bits e decidiu manter em segredo o processo se- (b) (a) Transposição inicial Iteração 16 Li-1 f(Ri-1, Ki) Ri-1 Li-1 Texto simples em 64 bits Texto cifrado de 64 bits 32 bits Li 32 bits Ri Iteração 2 Iteração 1 Chave de 56 bits Troca de 32 bits Transposição inversa Figura 8.6 O Data Encryption Standard. (a) Esboço geral. (b) Detalhe de uma iteração. O sinal de adição dentro do círculo significa OU exclusivo (XOR). 08_tanen0809_cap08 BR.indd 490 4/25/11 3:08 PM
- 13. Capítulo 8 Segurança deredes 491 gundo o qual o DES foi projetado. Muita gente suspeitou de que o tamanho da chave tinha sido reduzido para ga- rantir que a NSA pudesse decifrar o DES, mas nenhu- ma organização com um orçamento menor foi capaz de fazê-lo. Supostamente, o motivo para manter o projeto em segredo foi ocultar uma porta dos fundos que pu- desse facilitar ainda mais a decifração do DES por parte da NSA. Quando um funcionário da NSA disse discreta- mente para o IEEE (Institute of Electrical and Electronic Engineers) cancelar uma conferência sobre criptografia, as pessoas ficaram ainda mais embaraçadas com a situa- ção. A NSA negou tudo. Em 1977, dois pesquisadores de criptografia de Stan- ford, Diffie e Hellman (1977), projetaram uma máquina para decifrar o DES e estimaram que ela poderia ser mon- tada por um custo de 20 milhões de dólares. Com base em um pequeno trecho de texto simples e no texto cifrado correspondente, tal máquina poderia descobrir a chave através de uma pesquisa exaustiva do espaço de chaves de 256 entradas em menos de um dia. Atualmente, já se pode brincar. A máquina existe, está à venda e custa menos de US$ 10.000 para ser fabricada (Kumar et al., 2006). DES triplo No início de 1979, a IBM percebeu que o tamanho da chave do DES era muito pequeno e criou uma forma de au- mentá-lo usando a criptografia tripla (Tuchman, 1979). O método escolhido, que desde então foi incorporado ao pa- drão internacional 8732, está ilustrado na Figura 8.7. Nesse caso, são usados três estágios e duas chaves. No primeiro estágio, o texto simples é criptografado com K1 da maneira usual do DES. No segundo estágio, o DES é executado no modo de descriptografia, com o uso de K2 como chave. Por fim, outra criptografia DES é feita com K1 . Esse projeto levanta duas questões. Primeiro, por que são utilizadas apenas duas chaves em vez de três? Segundo, por que foi usado EDE (Encrypt Decrypt Encrypt) em vez de EEE (Encrypt Encrypt Encrypt)? São utilizadas duas chaves porque até mesmo os criptógrafos mais paranoi- cos concordam que 112 bits serão suficientes para aplicações comerciais durante um bom tempo. (E, entre os criptógra- fos, a paranoia é considerada um recurso, não um bug.) O uso de 168 bits só criaria overhead desnecessário para geren- ciar e transportar outra chave, com pouco ganho real. O motivo para criptografar, descriptografar e criptogra- far mais uma vez é a compatibilidade com os sistemas DES de chave única existentes. Tanto as funções de criptografia quanto as de descriptografia são mapeamentos entre conjun- tos de números de 64 bits. Do ponto de vista da criptogra- fia, os dois mapeamentos são igualmente fortes. No entanto, ao usar EDE em vez de EEE, um computador que utiliza a criptografia tripla pode se comunicar com outro que utiliza a criptografia simples apenas definindo K1 = K2 . Essa proprie- dade permite que a criptografia tripla seja implantada gra- dualmente, o que não interessa aos criptógrafos acadêmicos, mas é de grande importância para a IBM e seus clientes. 8.2.2 AES — Advanced Encryption Standard À medida que a vida útil do DES começou a se aproxi- mar do fim, mesmo com o DES triplo, o NIST (National Institute of Standards and Technology), o órgão do departamento de comércio dos Estados Unidos encarrega- do de aprovar padrões, decidiu que o governo precisava de um novo padrão criptográfico para uso não confiden- cial. O NIST estava ciente de toda a controvérsia que cer- cava o DES e sabia muito bem que, se anunciasse um novo padrão, todas as pessoas com algum conhecimento sobre criptografia logo concluiriam que a NSA havia criado uma porta dos fundos no DES, e assim poderia ler tudo que fosse criptografado com ele. Em tais condições, talvez ninguém utilizasse o padrão e seria mais provável que ele desapare- cesse. Dessa forma, o NIST adotou uma estratégia diferente e surpreendente para um órgão do governo: patrocinou uma competição de criptografia. Em janeiro de 1997, pesquisado- res do mundo inteiro foram convidados a submeter propos- tas para um novo padrão, a ser chamado AES (Advanced Encryption Standard). As regras dessa competição eram: 1. o algoritmo teria de ser uma cifra de bloco simétrica; 2. todo o projeto teria de ser público; 3. deveriam ser admitidos tamanhos de chaves iguais a 128, 192 e 256 bits; 4. teriam de ser possíveis implementações de software e de hardware; 5. o algoritmo teria de ser público ou licenciado em termos não discriminatórios. Foram feitas quinze propostas sérias e organizadas conferências públicas nas quais essas propostas eram apre- sentadas, e os participantes encorajados ativamente a en- contrar falhas em todas elas. Em agosto de 1998, o NIST se- lecionou cinco finalistas, baseado principalmente em seus requisitos de segurança, eficiência, simplicidade, flexibili- dade e memória (importantes para sistemas embarcados). K1 E K2 D K1 E P C K1 D K2 E (a) (b) K1 D C P Figura 8.7 Criptografia tripla usando o DES. (b) Descriptografia. 08_tanen0809_cap08 BR.indd 491 4/25/11 3:08 PM
- 14. 492 Redes decomputadores Foram realizadas outras conferências e mais tentativas de encontrar falhas nos algoritmos. Em outubro de 2000, o NIST anunciou que tinha se- lecionado o Rijndael, de Joan Daemen e Vincent Rijmen. O nome é derivado do sobrenome dos autores: Rijmen + Daemen. Em novembro de 2001, o Rijndael se tornou o padrão AES do governo dos Estados Unidos, publicado como FIPS (Federal Information Processing Standard) 197. Por causa da extraordinária abertura da competição, das propriedades técnicas do Rijndael e do fato de a equipe premiada consistir em dois jovens criptógrafos belgas (com pouca probabilidade de ter criado uma porta dos fundos só para agradar a NSA), o Rijndael se tornou o padrão cripto- gráfico dominante no mundo. A criptografia e a descripto- grafia AES fazem parte do conjunto de instruções de alguns microprocessadores (por exemplo, Intel). O Rijndael admite tamanhos de chaves e tamanhos de blocos desde 128 bits até 256 bits em intervalos de 32 bits. O comprimento da chave e o do bloco podem ser esco- lhidos independentemente. Porém, o AES especifica que o tamanho do bloco deve ser 128 bits e o comprimento da chave deve ser 128, 192 ou 256 bits. É pouco provável que alguém utilize chaves de 192 bits; assim, de fato, o AES tem duas variantes: um bloco de 128 bits com uma chave de 128 bits e um bloco de 128 bits com uma chave de 256 bits. Em nosso tratamento do algoritmo, examinaremos ape- nas o caso de 128/128, porque é provável que esse se torne a norma comercial. Uma chave de 128 bits oferece um espaço de chaves de 2128 ≈ 3 × 1038 chaves. Ainda que a NSA consiga construir uma máquina com 1 bilhão de processadores para- lelos, cada um capaz de avaliar uma chave por picossegundo, tal máquina levaria cerca de 1010 anos para pesquisar o espaço de chaves. Nessa época, o Sol já terá explodido e as pessoas que sobreviverem terão de ler os resultados à luz de velas. Rijndael Sob uma perspectiva matemática, o Rijndael se baseia na teoria de campo de Galois, o que proporciona ao algo- ritmo algumas propriedades de segurança demonstráveis. Porém, ele também pode ser visto como código em C, sem a necessidade de entrarmos nos detalhes matemáticos. Como o DES, o Rijndael utiliza substituição e permuta- ções, e também emprega várias rodadas. O número de roda- das depende do tamanho da chave e do tamanho do bloco, sendo 10 para chaves de 128 bits com blocos de 128 bits, passando para 14 no caso da maior chave ou do maior blo- co. No entanto, diferentemente do DES, todas as operações envolvem bytes inteiros, a fim de permitir implementações eficientes, tanto em hardware quanto em software. Um es- boço do código é apresentado no Quadro 8.1. Observe que esse código é para fins de ilustração. Boas implementações do código de segurança seguirão práticas adicionais, como zerar a memória confidencial depois que ela tiver sido usa- da. Veja, por exemplo, Ferguson et al. (2010). #define LENGTH 16 /* número de bytes no bloco de dados ou chave */ #define NROWS 4 /* número de linhas no estado */ #define NCOLS 4 /* número de colunas no estado */ #define ROUNDS 10 /* número de iterações */ typedef unsigned char byte; /* inteiro de 8 bits sem sinal */ rijndael(byte plaintext[LENGTH], byte ciphertext[LENGTH], byte key[LENGTH]) { int r; /* índice do loop */ byte state[NROWS][NCOLS]; /* estado atual */ struct {byte k[NROWS][NCOLS];} rk[ROUNDS + 1]; /* chaves da rodada */ expand_key(key, rk); /* constrói as chaves da rodada */ copy_plaintext_to_state(state, plaintext); /* inicia estado atual */ xor_roundkey_into_state(state, rk[0]); /* XOR da chave no estado */ for (r = 1; r <= ROUNDS; r++) { substitute(state); /* aplica caixa S a cada byte */ rotate_rows(state); /* gira linha i por i bytes */ if (r < ROUNDS) mix_columns(state); /* função embaralha */ xor_roundkey_into_state(state, rk[r]); /* XOR da chave no estado */ } copy_state_to_ciphertext(ciphertext, state); /* retorna resultado */ } Quadro 8.1 Um esboço do Rijndael em C. 08_tanen0809_cap08 BR.indd 492 4/25/11 3:08 PM
- 15. Capítulo 8 Segurança deredes 493 A função rijndael tem três parâmetros: plaintext, um ar- ray de 16 bytes contendo os dados de entrada, ciphertext, um array de 16 bytes no qual será retornada a saída cifrada, e key, a chave de 16 bytes. Durante o cálculo, o estado atual dos dados é mantido no array de bytes state, cujo tamanho é NROWS × NCOLS. No caso de blocos de 128 bits, esse ar- ray tem 4 × 4 bytes. Em 16 bytes, é possível armazenar todo o bloco de dados de 128 bits. O array state é iniciado com o texto simples e modifi- cado em cada etapa da computação. Em algumas etapas, é executada a substituição byte a byte. Em outras etapas, os bytes são permutados dentro do array. Outras transforma- ções também são usadas. No final, o conteúdo do array state é retornado como texto cifrado. O código começa expandindo a chave em 11 arrays do mesmo tamanho do estado. Eles são armazenados em rk, um array de structs, cada um contendo um array de estado. Um desses arrays será utilizado no início do cálculo, e os outros 10 serão usados durante as 10 rodadas, um por ro- dada. O cálculo das chaves de rodadas a partir da chave de criptografia é muito complicado para ser examinado aqui. Basta saber que as chaves de rodadas são produzidas pela rotação e pela operação XOR repetida em vários grupos de bits da chave. Para ver todos os detalhes, consulte (Daemen e Rijmen, 2002). A próxima etapa é copiar o texto simples no array state de forma que ele possa ser processado durante as rodadas. O texto é copiado em ordem de colunas, com os quatro primeiros bytes na coluna 0, os quatro bytes seguintes na coluna 1 e assim por diante. Tanto as colunas quanto as linhas são numeradas a partir de 0, embora as rodadas se iniciem em 1. Essa configuração inicial dos 12 arrays de bytes com tamanho 4 × 4 é ilustrada na Figura 8.8. Há mais uma etapa antes do início da principal com- putação: rk[0] é submetido a uma operação XOR em state, byte por byte. Em outras palavras, cada um dos 16 bytes em state é substituído pelo XOR do próprio valor com o byte correspondente em rk[0]. Agora chegou a hora da atração principal. O loop exe- cuta dez iterações, uma por rodada, transformando state em cada repetição. O conteúdo de cada rodada consiste em quatro etapas. A etapa 1 efetua uma substituição byte a byte em state. Por sua vez, cada byte é usado como um índi- ce para uma caixa S, a fim de substituir seu valor pelo con- teúdo dessa entrada da caixa S. Essa etapa é uma cifra de substituição monoalfabética. Diferentemente do DES, que tem diversas caixas S, o Rijndael tem apenas uma caixa S. A etapa 2 gira cada uma das quatro linhas para a es- querda. A linha 0 é girada 0 bytes (isto é, não se altera), a linha 1 é girada 1 byte, a linha 2 é girada 2 bytes e a linha 3 é girada 3 bytes. Essa etapa difunde o conteúdo dos dados atuais em torno do bloco, de modo semelhante às permu- tações da Figura 8.5. A etapa 3 embaralha cada coluna independentemente das outras. O embaralhamento é realizado com o uso da multiplicação de matrizes, na qual a nova coluna é o pro- duto da coluna antiga por uma matriz constante, sendo a multiplicação feita com o campo finito de Galois, GF(28 ). Embora isso possa parecer complicado, existe um algorit- mo que permite calcular cada elemento da nova coluna usando duas pesquisas em tabelas e três operações XOR (Daemen e Rijmen, 2002, Apêndice E). Por fim, a etapa 4 efetua o XOR da chave correspon- dente a essa rodada no array state. Tendo em vista que cada etapa é reversível, a deco- dificação pode ser feita simplesmente executando-se o algoritmo no sentido inverso. Porém, também existe um artifício pelo qual a decodificação pode ser realizada exe- cutando-se o algoritmo de criptografia com a utilização de tabelas diferentes. O algoritmo foi projetado não só por segurança, mas também para aumentar a velocidade. Uma boa implemen- tação de software em uma máquina de 2 GHz deve ser capaz de alcançar uma taxa de criptografia de 700 Mbps, que é rápida o suficiente para codificar mais de cem vídeos MPEG-2 em tempo real. As implementações de hardware são ainda mais rápidas. 8.2.3 Modos de cifra Apesar de toda essa complexidade, o AES (ou o DES, ou ainda qualquer cifra de bloco) é basicamente uma cifra state rk[0] rk[1] rk[2] rk[3] rk[4] rk[5] rk[6] rk[7] rk[8] rk[9] rk[10] Texto simples de 128 bits Chave de codificação de 128 bits chaves de rodadas Figura 8.8 Criação dos arrays state e rk. 08_tanen0809_cap08 BR.indd 493 4/25/11 3:08 PM
- 16. 494 Redes decomputadores de substituição monoalfabética que utiliza caracteres gran- des (caracteres de 128 bits para AES, e caracteres de 64 bits para DES). Sempre que o mesmo bloco de texto simples chega ao front end, o mesmo bloco de texto cifrado sai pelo back-end. Se você codificar o texto simples abcdefgh 100 ve- zes com a mesma chave DES, obterá o mesmo texto cifra- do cem vezes. Um intruso pode explorar essa propriedade para ajudar a subverter a cifra. O modo Electronic Code Book Para ver como essa propriedade das cifras de substi- tuição monoalfabética pode ser usada para anular parcial- mente a cifra, usaremos o DES (triplo), por ser mais fácil representar blocos de 64 que de 128 bits, mas o AES tem exatamente o mesmo problema. A maneira direta de usar o DES para codificar um longo fragmento de texto simples é dividi-lo em blocos consecutivos de 8 bytes (64 bits) e codificá-los uns após outros com a mesma chave. O últi- mo fragmento de texto simples é completado até 64 bits, se necessário. Essa técnica é conhecida como modo ECB (Electronic Code Book), em analogia aos antigos livros de código em que cada palavra de texto simples era listada, seguida por seu texto cifrado (em geral, um número deci- mal de cinco dígitos). Na Figura 8.9, temos o início de um arquivo de compu- tador com a lista das gratificações anuais que uma empresa decidiu oferecer a seus funcionários. Esse arquivo consiste em registros de 32 bytes consecutivos, um por funcionário, no formato mostrado: 16 bytes para o nome, 8 bytes para o cargo e 8 bytes para a gratificação. Cada um dos dezesseis blocos de 8 bytes (numerados de 0 até 15) é codificado pelo DES (triplo). Leslie acabou de brigar com o chefe e sabe que não deve esperar uma grande gratificação. Ao contrário, Kim é a favorita do chefe e todo mundo sabe disso. Leslie pode acessar o arquivo após a codificação, mas antes de ser en- viado ao banco. Ela pode retificar essa situação injusta, ten- do apenas o arquivo criptografado? Não há problema. Leslie só precisa fazer uma cópia do 12o bloco do texto cifrado (que contém a gratificação de Kim) e usá-lo para substituir o quarto bloco do texto cifra- do (que contém a própria gratificação). Mesmo sem saber o que contém o 12o bloco, Leslie pode esperar ter um Natal muito mais feliz naquele ano. (Copiar o oitavo bloco tam- bém é uma possibilidade, mas o risco de ser descoberto é maior; além disso, Leslie não é uma pessoa gananciosa.) Modo de encadeamento de blocos de cifras Para contrariar esse tipo de ataque, todos os blocos de cifras podem ser encadeados de várias maneiras, a fim de que a substituição de um bloco como a que Leslie fez transforme o texto simples decodificado em lixo, a par- tir do bloco substituído. Uma forma de encadeamento é o encadeamento de blocos de cifras. Nesse método, mostrado na Figura 8.10, cada bloco de texto simples é submetido a uma operação XOR com o bloco de texto ci- frado anterior, antes de ser codificado. Como consequên- cia, o mesmo bloco de texto simples não é mais mapeado Nome Cargo Gratificação 16 8 8 Bytes D a v i s , B o b b i e L i m p e z a $ 5 C o l l i n s , K i m D i r e t o r $ 1 0 0 , 0 0 0 B l a c k , R o b i n C h e f e $ 5 0 0 , 0 0 0 A d a m s , L e s l i e C a i x a $ 1 0 Figura 8.9 O texto simples de um arquivo codificado como 16 blocos DES. (a) (b) + E IV Chave Chave IV P0 C0 + E P1 C1 E P2 C2 E P3 C3 D C0 P0 D C1 P1 D C2 P2 D Caixa de decodificação Caixa de codificação OU exclusivo C3 P3 + + + + + + Figura 8.10 Encadeamento de blocos de cifras. (a) Codificação. (b) Decodificação. 08_tanen0809_cap08 BR.indd 494 4/25/11 3:08 PM
- 17. Capítulo 8 Segurança deredes 495 para o mesmo bloco de texto cifrado, e a criptografia não é mais uma grande cifra de substituição monoalfabética. O primeiro bloco é submetido a uma operação XOR com um vetor de referência, ou IV (Initialization Vector), escolhido ao acaso, que é transmitido (em texto simples) juntamente com o texto cifrado. Podemos ver como funciona o modo de encadeamento de blocos de cifras examinando o exemplo da Figura 8.10. Começamos com o cálculo C0 = E(P0 XOR IV). Em seguida, calculamos C1 = E(P1 XOR C0 ) e assim por diante. A decodi- ficação também utiliza XOR para inverter o processo, com P0 = IV XOR D(C0 ) e assim por diante. Observe que a cripto- grafia do bloco i é uma função de todo o texto simples conti- do nos blocos 0 a i - 1, e assim o mesmo texto simples gera um texto cifrado diferente, dependendo de onde ele ocorre. Uma transformação do tipo que Leslie fez resultará em texto sem sentido para dois blocos a partir do campo de gratifica- ção de Leslie. Para um funcionário de segurança astuto, essa peculiaridade pode sugerir onde iniciar a investigação legal. O encadeamento de blocos de cifras também tem uma vantagem: o mesmo bloco de texto simples não resultará no mesmo bloco de texto cifrado. Assim, a criptoanálise será difícil. De fato, essa é a principal razão de seu uso. Modo de feedback de cifra No entanto, o encadeamento de blocos de cifras tem a desvantagem de exigir a chegada de um bloco de 64 bits in- teiro para poder iniciar a decodificação. No caso da codifi- cação byte a byte, é usado o modo de feedback de cifra, empregando o DES (triplo), como mostra a Figura 8.11. Para o AES, a ideia é exatamente a mesma, sendo usado um registrador de deslocamento de 128 bits. Na figura, o estado da máquina de criptografia é mostrado após os bytes 0 a 9 terem sido codificados e enviados. Ao chegar o byte 10 do texto simples, conforme ilustra a Figura 8.11(a), o algoritmo DES opera sobre o registrador de deslocamento de 64 bits para gerar um texto cifrado de 64 bits. O byte mais à esquerda desse texto cifrado é extraído e submetido a uma operação XOR com P10 . Depois, esse byte é encami- nhado à linha de transmissão. Além disso, o registrador de deslocamento (shift register) é deslocado 8 bits à esquerda, fazendo C2 ficar fora da extremidade esquerda, e C10 é in- serido na posição que acabou de ficar vaga na extremidade direita, logo depois de C9 . Observe que o conteúdo do registrador de deslocamen- to depende do histórico anterior do texto simples; assim, um padrão que se repetir várias vezes no texto simples será crip- tografado de maneira diferente do texto cifrado a cada vez. Como ocorre no encadeamento de blocos de cifras, é neces- sário um vetor de referência para iniciar o processo. A decodificação com o modo de feedback de cifra fun- ciona exatamente como a codificação. Em particular, o conteúdo do registrador de deslocamento é codificado, e não decodificado, e assim o byte selecionado que é submetido à operação XOR com C10 para obter P10 é o mesmo que sofreu a operação XOR com P10 para gerar C10 na primeira vez. Desde que os dois registradores de deslocamento permane- çam idênticos, a decodificação funciona corretamente. Ela é ilustrada na Figura 8.11(b). Um problema apresentado pelo modo de feedback de cifra é que, se um bit do texto cifrado for invertido aciden- talmente durante a transmissão, os 8 bytes decodificados enquanto o byte defeituoso estiver no registrador de des- locamento serão danificados. Depois que o byte defeituoso for empurrado para fora do registrador de deslocamento, o texto simples correto será gerado mais uma vez. Desse modo, os efeitos de um único bit invertido são em parte localizados e não danificam o restante da mensagem, mas danificam uma quantidade de bits igual à largura do regis- trador de deslocamento. Modo fluxo de cifras Apesar disso, existem aplicações em que um erro de transmissão de 1 bit alterando 64 bits de texto simples pro- (a) C10 (b) Chave C10 P10 E Registrador de deslocamento de 64 bits C2 C3 C4 C5 C6 C7 C8 C9 + Caixa de codificação Seleciona byte mais à esquerda Chave P10 C10 C10 E Registrador de deslocamento de 64 bits C2 C3 C4 C5 C6 C7 C8 C9 Caixa de codificação Seleciona byte mais à esquerda OU exclusivo + Figura 8.11 Modo de feedback de cifra. (a) Codificação. (b) Decodificação. 08_tanen0809_cap08 BR.indd 495 4/25/11 3:08 PM
- 18. 496 Redes decomputadores voca um impacto grande demais. Para essas aplicações, há uma quarta opção, o modo fluxo de cifras. Ele funciona pela codificação de um vetor de referência com uma chave para obter um bloco de saída. O bloco de saída é então co- dificado, usando-se a chave para obter um segundo bloco de saída. Em seguida, esse bloco é codificado para obter um terceiro bloco e assim por diante. A sequência (arbi- trariamente grande) de blocos de saída, chamada fluxo de chaves, é tratada como uma chave única e submetida a uma operação XOR com o texto simples para obter o tex- to cifrado, como mostra a Figura 8.12(a). Observe que o vetor de referência só e usado na primeira etapa. Depois disso, a saída é codificada. Observe também que o fluxo de chaves é independente dos dados, portanto pode ser calcu- lado com antecedência, se necessário, e é completamente insensível a erros de transmissão. A decodificação aparece na Figura 8.12(b). A decodificação ocorre quando se gera o mesmo fluxo de chaves no lado receptor. Como o fluxo de chaves só de- pende do vetor de referência e da chave, ele não é afetado por erros de transmissão no texto cifrado. Desse modo, um erro de 1 bit no texto cifrado transmitido gera apenas um erro de 1 bit no texto simples decodificado. É essencial nunca utilizar o mesmo par (chave, vetor de referência) duas vezes em fluxo de cifras, porque isso vai gerar o mesmo fluxo de chaves o tempo todo. O uso de um mesmo fluxo de chaves duas vezes expõe o texto cifrado a um ataque de reutilização de fluxo de cha- ves. Imagine que o bloco de texto simples P0 seja codificado com o fluxo de chaves para obter P0 XOR K0 . Mais tarde, um segundo bloco de texto simples Q0 é codificado com o mesmo fluxo de chaves para obter Q0 XOR K0 . Um intruso que capturar ambos os blocos do texto cifrado poderá sim- plesmente efetuar uma operação XOR dos dois juntos para obter P0 XOR Q0 , o que eliminará a chave. Agora, o intruso tem o XOR dos dois blocos de texto simples. Se um deles for conhecido ou puder ser encontrado, o outro também poderá ser encontrado. Em todo caso, o XOR de dois fluxos de texto simples poderá ser atacado com a utilização de propriedades estatísticas da mensagem. Por exemplo, no caso de texto em inglês, o caractere mais comum no fluxo provavelmente será o XOR de dois espaços, seguido pelo XOR de espaço e da letra ‘e’ etc. Em resumo, equipado com o XOR de dois textos simples, o criptoanalista tem uma ex- celente chance de deduzi-los. Modo contador Um problema apresentado por todos os modos, com exceção do modo do livro de código eletrônico, é a impos- sibilidade de conseguir acesso aleatório a dados codificados. Por exemplo, suponha que um arquivo seja transmitido por uma rede e depois armazenado em disco em forma co- dificada. Isso poderia ser um meio razoável de operação, se o computador receptor fosse um notebook que pudesse ser roubado. Armazenar todos os arquivos críticos em forma codificada reduz muito os danos causados pelo vazamento de informações secretas na eventualidade de o computador cair em mãos erradas. Porém, com frequência, os arquivos de disco são aces- sados em ordem não sequencial, especialmente arquivos de bancos de dados. No caso de um arquivo codificado pela utilização do encadeamento de blocos de cifras, o acesso a um bloco aleatório exige primeiro a decodificação de todos os blocos situados à frente dele, uma proposta dispendiosa. Por essa razão, foi criado mais um modo, o modo conta- dor, como ilustra a Figura 8.13. Aqui, o texto simples não é codificado diretamente. Em vez disso, o vetor de referência somado a uma constante é codificado, e o texto cifrado re- sultante é submetido a um XOR com o texto simples. Au- mentar o vetor de referência em uma unidade a cada novo bloco facilita a decodificação de um bloco em qualquer lu- gar no arquivo sem que primeiro seja preciso decodificar todos os seus predecessores. Embora seja útil, o modo do contador tem um pon- to fraco que vale a pena assinalar. Suponha que a mesma chave K seja usada novamente no futuro (com um texto simples diferente, mas com o mesmo vetor de referência) e um atacante adquira todo o texto cifrado em ambas as execuções. O fluxo de chaves é o mesmo nos dois casos, expondo a cifra a um ataque de reutilização do fluxo de chaves do tipo que vimos no caso de fluxo de cifras. O crip- toanalista tem de efetuar a operação XOR dos dois textos cifrados juntos, a fim de eliminar toda a proteção criptográ- fica e simplesmente obter o XOR dos textos simples. Essa E (a) Chave Texto simples Texto cifrado Fluxo de chaves Caixa de codificação IV + E (b) Chave Texto simples Texto cifrado Fluxo de chaves Caixa de codificação IV + Figura 8.12 Um fluxo de cifras. (a) Codificação. (b) Decodificação. 08_tanen0809_cap08 BR.indd 496 4/25/11 3:08 PM
- 19. Capítulo 8 Segurança deredes 497 fragilidade não significa que o modo do contador seja uma má ideia. Ela simplesmente quer dizer que tanto as chaves quanto os vetores de referência devem ser escolhidos de forma independente e ao acaso. Ainda que a mesma chave seja utilizada duas vezes por acidente, se o IV for diferente em cada utilização, o texto simples estará seguro. 8.2.4 Outras cifras AES (Rijndael) e DES são os algoritmos criptográficos de chave simétrica mais conhecidos e as escolhas-padrão da indústria, mesmo apenas por motivos de responsabilidade. (Ninguém o culpará se você usar AES em seu produto e o AES for quebrado, mas certamente alguém o fará se você usar uma cifra fora do padrão e ela mais tarde for que- brada.) Porém, vale a pena mencionar que foram criadas várias outras cifras de chave simétrica. Algumas delas es- tão incorporadas a vários produtos. A Tabela 8.2 mostra algumas entre as cifras de chave simétrica mais comuns. É possível usar combinações dessas cifras, por exemplo, AES sobre Twofish, de modo que ambas precisem ser quebradas para recuperar os dados. 8.2.5 Criptoanálise Antes de deixar o assunto de criptografia de chave simé- trica, vale a pena mencionar pelo menos quatro desenvol- vimentos em criptoanálise. O primeiro desenvolvimento é a criptoanálise diferencial (Biham e Shamir, 1997). Essa técnica pode ser usada para atacar qualquer cifra de bloco. Ela funciona a partir de um par de blocos e texto simples que diferem apenas por um pequeno número de bits e pela ob- servação cuidadosa do que acontece em cada iteração inter- na à medida que a codificação prossegue. Em muitos casos, alguns padrões de bits são muito mais comuns que outros, e essa observação pode levar a ataques probabilísticos. O segundo desenvolvimento que vale a pena notar é a criptoanálise linear (Matsui, 1994). Ela pode quebrar o DES com apenas 243 textos simples conhecidos. Essa técnica funciona efetuando o XOR de certos bits no texto simples e no texto cifrado, e examinando o resultado. Quando isso é feito repetidamente, metade dos bits deve ter o valor 0 e metade deve ter o valor 1. Porém, com frequência, as cifras introduzem uma inclinação em um sentido ou no outro, e essa inclinação, embora pequena, pode ser explorada para reduzir o fator de trabalho. Para ver os detalhes, consulte o ensaio de Matsui. O terceiro desenvolvimento é o uso da análise do consumo de energia elétrica para encontrar chaves se- cretas. Em geral, os computadores utilizam 3 volts para representar um bit 1 e 0 volts para representar um bit 0. Desse modo, o processamento de um bit 1 exige mais ener- gia elétrica que o processamento de um 0. Se um algoritmo Caixa de codificação + E IV Chave P0 C0 + E IV+1 Chave P1 C1 + E IV+2 Chave P2 C2 + E IV+3 Chave P3 C3 Figura 8.13 Codificação com a utilização do modo contador. Cifra Autor Comprimento da chave Comentários DES IBM 56 bits Muito fraco para usar agora RC4 Ronald Rivest 1 a 2.048 bits Atenção: algumas chaves são fracas RC5 Ronald Rivest 128 a 256 bits Bom, mas patenteado AES (Rijndael) Daemen e Rijmen 128 a 256 bits Melhor escolha Serpent Anderson, Biham, Knudsen 128 a 256 bits Muito forte DES triplo IBM 168 bits Bom, mas está ficando ultrapassado Twofish Bruce Schneier 128 a 256 bits Muito forte; amplamente utilizado Tabela 8.2 Alguns algoritmos criptográficos de chave simétrica comuns. 08_tanen0809_cap08 BR.indd 497 4/25/11 3:08 PM
- 20. 498 Redes decomputadores criptográfico consistir em um loop no qual os bits da chave são processados em ordem, um atacante que substituir o clock principal de n GHz por um clock lento (por exem- plo, 100 Hz) e prender pinças dentadas (pinças jacaré) nos pinos de energia da CPU e de terra poderá monitorar com precisão a energia consumida por cada instrução de máqui- na. A partir desses dados, será surpreendentemente fácil deduzir a chave. Esse tipo de criptoanálise só pode ser anu- lado por codificação cuidadosa do algoritmo em linguagem assembly para ter certeza de que o consumo de energia será independente da chave e também independente de todas as chaves de rodadas individuais. O quarto desenvolvimento é a análise de sincronismo. Os algoritmos criptográficos estão repletos de instruções if que testam bits nas chaves de rodadas. Se as partes then e else de- morarem períodos de tempo diferentes, tornando mais lento o clock e verificando quanto tempo demoram diversas etapas, talvez seja possível deduzir as chaves de rodadas. Uma vez que todas as chaves de rodadas sejam conhecidas, em geral será possível calcular a chave original. A análise da energia e da sincronização também pode ser empregada simultanea- mente para facilitar o trabalho. Embora a análise da energia e da sincronização possa parecer exótica, na realidade são técni- cas eficientes que podem romper qualquer cifra não projetada de forma específica para resistir a elas. 8.3 Algoritmos de chave pública O problema da distribuição de chaves sempre foi o elo mais fraco da maioria dos sistemas de criptografia. In- dependentemente de quanto um sistema de criptografia fosse sólido, se um intruso conseguisse roubar a chave, o sistema acabava sendo inútil. Como todos os criptólogos sempre presumem que a chave de criptografia e a cha- ve de descriptografia são iguais (ou facilmente derivadas uma da outra) e que a chave é distribuída a todos os usuários do sistema, tinha-se a impressão de que havia um proble- ma inerente ao sistema. As chaves tinham de ser prote- gidas contra roubo, mas também tinham de ser distribuí- das; portanto, não podiam ser simplesmente trancadas na caixa-forte de um banco. Em 1976, dois pesquisadores da Universidade de Stan- ford, Diffie e Hellman (1976), propuseram um sistema de criptografia radicalmente novo, no qual as chaves de criptografia e de descriptografia eram diferentes, e a cha- ve de descriptografia não podia ser derivada da chave de criptografia. Em sua proposta, o algoritmo de criptografia (chaveado) E e o algoritmo de descriptografia (chaveado) D tinham de atender a três requisitos, que podem ser decla- rados da seguinte forma: 1. D(E(P)) = P. 2. É extremamente difícil deduzir D a partir de E. 3. E não pode ser decifrado por um ataque de texto simples escolhido. O primeiro requisito diz que, se aplicarmos D a uma men- sagem criptografada, E(P), obteremos outra vez a mensagem de texto simples original P. Sem essa propriedade, o destinatá- rio legítimo não poderia decodificar o texto cifrado. O segun- do é autoexplicativo. O terceiro é necessário porque, como veremos em um minuto, os intrusos podem experimentar o algoritmo até se cansarem. Sob essas condições, não há razão para a chave criptográfica não se tornar pública. O método funciona da seguinte forma: uma pessoa, digamos Alice, desejando receber mensagens secretas, pri- meiro cria dois algoritmos que atendem aos requisitos an- teriores. O algoritmo de criptografia e a chave de Alice se tornam públicos, daí o nome criptografia de chave pú- blica. Por exemplo, Alice poderia colocar sua chave pú- blica em sua home page da Web. Usaremos a notação EA para indicar o algoritmo de criptografia parametrizado pela chave pública de Alice. De modo semelhante, o algoritmo de descriptografia (secreto) parametrizado pela chave pri- vada de Alice é DA . Bob faz o mesmo, publicando EB , mas mantendo secreta a chave DB . Agora, vamos ver se podemos resolver o problema de estabelecer um canal seguro entre Alice e Bob, que nunca haviam tido um contato anterior. Tanto a chave de cripto- grafia de Alice, EA , quanto a chave de criptografia de Bob, EB , estão em arquivos de leitura pública. Agora, Alice pega sua primeira mensagem P, calcula EB (P) e a envia para Bob. Em seguida, Bob a descriptografa aplicando sua chave se- creta DB [ou seja, ele calcula DB (EB (P)) = P]. Ninguém mais pode ler a mensagem criptografada EB (P), porque o siste- ma de criptografia é considerado sólido e porque é muito difícil derivar DB da chave EB publicamente conhecida. Para enviar uma resposta R, Bob transmite EA (R). Agora, Alice e Bob podem se comunicar com segurança. Talvez seja interessante fazer uma observação sobre a terminologia. A criptografia de chave pública exige que cada usuário tenha duas chaves: uma chave pública, usa- da pelo mundo inteiro para criptografar as mensagens a ser enviadas para esse usuário, e uma chave privada, que o usuário utiliza para descriptografar mensagens. Faremos referência a essas chaves como chave pública e chave pri- vada, respectivamente, e vamos distingui-las das chaves secretas (também chamadas chaves simétricas) usadas na criptografia de chave simétrica convencional. 8.3.1 RSA O único problema é que temos de encontrar algorit- mos que realmente satisfaçam todos os três requisitos. De- vido às vantagens potenciais da criptografia de chave públi- ca, muitos pesquisadores estão se dedicando integralmente a seu estudo, e alguns algoritmos já foram publicados. Um método muito interessante foi descoberto por um grupo de pesquisadores do MIT (Rivest et al., 1978) e é conheci- do pelas iniciais dos três estudiosos que o criaram (Rivest, Shamir, Adleman): RSA. Ele sobreviveu a todas as tenta- 08_tanen0809_cap08 BR.indd 498 4/25/11 3:08 PM
- 21. Capítulo 8 Segurança deredes 499 tivas de rompimento por mais de um quarto de século e é considerado um algoritmo muito forte. Grande parte da segurança prática se baseia nele. Por isso, Rivest, Shamir e Adleman receberam o ACM Turing Award de 2002. Sua principal desvantagem é exigir chaves de pelo menos 1.024 bits para manter um bom nível de segurança (em compa- ração com 128 bits para os algoritmos de chave simétrica), e isso o torna bastante lento. O método RSA se baseia em alguns princípios da teo- ria dos números. Agora vamos mostrar de forma resumida como usá-lo; para obter mais detalhes, consulte o docu- mento original. 1. Escolha dois números primos grandes, p e q (geral- mente, de 1.024 bits). 2. Calcule n = p × q e z = (p − 1) × (q − 1). 3. Escolha um número d tal que z e d sejam primos entre si. 4. Encontre e de forma que e × d = 1 mod z. Com esses parâmetros calculados com antecedência, estamos prontos para começar a criptografia. Divida o tex- to simples (considerado uma sequência de bits) em blocos, de modo que cada mensagem de texto simples P fique no intervalo 0 ≤ P < n. Isso pode ser feito agrupando-se o texto simples em blocos de k bits, onde k é o maior inteiro para o qual a desigualdade 2k < n é verdadeira. Para criptografar a mensagem P, calcule C = Pe (mod n). Para descriptografar C, calcule P = Cd (mod n). É possível provar que, para todo P na faixa especificada, as funções de criptografia e descriptografia são inversas entre si. Para reali- zar a criptografia, você precisa de e e n, enquanto para a des- criptografia são necessários d e n. Portanto, a chave pública consiste no par (e, n) e a chave privada consiste em (d, n). A segurança do método se baseia na dificuldade de fatorar números extensos. Se pudesse fatorar o valor n (publicamente conhecido), o criptoanalista poderia então encontrar p e q e, a partir deles, encontrar z. Com o co- nhecimento de z e e, é possível encontrar d utilizando-se o algoritmo de Euclides. Felizmente, os matemáticos têm tentado fatorar números extensos por pelo menos 300 anos, e o conhecimento acumulado sugere que o problema é extremamente difícil. De acordo com Rivest e seus colegas, a fatoração de um número de 500 dígitos requer 1025 anos, usando-se a for- ça bruta. Nesse caso, eles pressupõem o melhor algoritmo conhecido e um computador com um tempo por instrução de 1 ms. Mesmo que os computadores continuem a se tor- nar cada vez mais rápidos na proporção de uma ordem de grandeza por década, ainda se passarão séculos até que a fatoração de um número de 500 dígitos se torne viável e, nesse tempo, nossos descendentes poderão simplesmente escolher p e q ainda maiores. Um exemplo didático muito comum do algoritmo RSA é mostrado na Figura 8.14. Para esse exemplo, escolhemos p = 3 e q = 11, o que gera n = 33 e z = 20. Um valor adequa- do para d é d = 7, visto que 7 e 20 não têm fatores comuns. Com essas opções, e pode ser encontrado resolvendo-se a equação 7e = 1 (mod 20), que produz e = 3. O texto cifrado C para uma mensagem de texto simples P é dado por C = P3 (mod 33). O texto cifrado é decodificado pelo receptor usan- do a regra P = C7 (mod 33). A figura mostra a codificação do texto simples ‘SUZANNE’ como exemplo. Como os números primos escolhidos para esse exem- plo são muito pequenos, P tem de ser menor que 33; portanto, cada bloco do texto simples só pode conter um caractere isolado. O resultado é uma cifra de substituição monoalfabética, que não impressiona muito. Se em vez disso tivéssemos escolhido p e q ≈ 2512 , teríamos n ≈ 21024 e assim cada bloco poderia ter até 1.024 bits ou 128 caracte- res de 8 bits, em comparação com 8 caracteres para o DES e 16 caracteres para o AES. Devemos destacar que o uso do RSA da forma como descrevemos é semelhante ao uso de um algoritmo simé- trico no modo ECB — o mesmo bloco de entrada gera o mesmo bloco de saída. Portanto, é necessário algum tipo de encadeamento para a criptografia de dados. No entanto, na prática, a maior parte dos sistemas baseados no RSA utiliza a criptografia de chave pública, em especial para distribuir chaves únicas de sessão, que, por sua vez, são emprega- das com algum algoritmo de chave simétrica, como AES Simbólico S U Z A N N E Simbólico S U Z A N N E Numérico Texto simples (P) Texto cifrado (C) Após a decodificação Cálculo do receptor Cálculo do transmissor 19 21 26 01 14 14 05 19 21 26 01 14 14 05 P3 6859 9261 17576 1 2744 2744 125 P3 (mod 33) C7 (mod 33) 28 21 20 1 5 5 26 C7 13492928512 1801088541 1280000000 1 78125 78125 8031810176 Figura 8.14 Um exemplo do algoritmo RSA. 08_tanen0809_cap08 BR.indd 499 4/25/11 3:08 PM
- 22. 500 Redes decomputadores ou DES triplo. O RSA é lento demais para codificar grandes volumes de dados, mas é amplamente utilizado para a dis- tribuição de chaves. 8.3.2 Outros algoritmos de chave pública Apesar de ser utilizado em larga escala, o RSA não é de forma alguma o único algoritmo de chave pública conheci- do. O primeiro foi o algoritmo da mochila (Merkle e Hell- man, 1978). A ideia aqui é que alguém possui um grande número de objetos, cada objeto com um peso diferente. O dono dos objetos codifica a mensagem selecionando se- cretamente um subconjunto dos objetos e colocando-os na mochila. O peso total dos objetos na mochila torna-se pú- blico, e o mesmo acontece com a lista de todos os objetos possíveis. A lista de objetos da mochila é mantida em se- gredo. Com outras restrições, o problema de descobrir uma lista de objetos possíveis com o peso fornecido foi consi- derado computacionalmente inviável e formou a base do algoritmo de chave pública. O inventor do algoritmo, Ralph Merkle, estava bastan- te seguro de que esse algoritmo não poderia ser decifrado; portanto, ofereceu um prêmio de 100 dólares a quem con- seguisse fazê-lo. Adi Shamir (o ‘S’ do RSA) se prontificou a decifrar o algoritmo e ganhou o prêmio. Indignado, Merkle reforçou o algoritmo e ofereceu um premio de 1.000 dóla- res a quem pudesse decifrá-lo. Ronald Rivest (o ‘R’ do RSA) também conseguiu decifrar o novo algoritmo e ganhou o prêmio. Merkle não ousou oferecer 10.000 dólares pela nova versão revisada; portanto, ‘A’ (Leonard Adleman) não teve sorte. Apesar de ter sido refeito, o algoritmo da mochila não é mais considerado seguro e não é usado na prática. Outros esquemas de chave pública se baseiam na difi- culdade de calcular logaritmos discretos. Os algoritmos que utilizam esse princípio foram criados por El Gamal (1985) e Schnorr (1991). Existem alguns outros esquemas, como os que se ba- seiam em curvas elípticas (Menezes e Vanstone, 1993), mas as duas principais categorias são aquelas que se baseiam na dificuldade de fatorar números extensos e no cálculo de logaritmos discretos cuja base é um número primo ex- tenso. Esses problemas são considerados de fato difíceis de resolver — os matemáticos estão estudando os algoritmos há anos sem grandes resultados. 8.4 Assinaturas digitais A autenticidade de muitos documentos legais, finan- ceiros e outros tipos é determinada pela presença de uma assinatura manual autorizada. Isso não vale para as foto- cópias. Para que os sistemas de mensagens computadori- zadas possam substituir o transporte físico de documentos em papel e tinta, deve-se encontrar um método que per- mita assinar os documentos de um modo que não possa ser forjado. O problema de criar um substituto para as assinaturas escritas à mão é muito difícil. Basicamente, necessita-se de um sistema pelo qual uma parte possa enviar uma mensa- gem assinada para outra parte de forma que: 1. o receptor possa verificar a identidade alegada pelo transmissor;. 2. mais tarde, o transmissor não possa repudiar o con- teúdo da mensagem; 3. o receptor não tenha a possibilidade de inventar ele mesmo a mensagem. Por exemplo, o primeiro requisito diz respeito a sistemas financeiros. Quando o computador de um cliente pede ao de um banco que compre uma tonelada de ouro, o computador do banco precisa se certificar de que o computador que emitiu o pedido pertence de fato à empresa de cuja conta um valor deve ser debitado. Em outras palavras, os bancos precisam au- tenticar o cliente (e o cliente precisa autenticar o banco). O segundo requisito é necessário para proteger o ban- co contra fraudes. Suponha que o banco compre uma to- nelada de ouro e que logo depois disso o preço do ouro caia bruscamente. Um cliente desonesto poderia processar o banco, afirmando nunca ter feito nenhum pedido para a compra de ouro. Quando o banco mostra a mensagem no tribunal, o cliente nega tê-la enviado. A propriedade segundo a qual nenhuma parte de um contrato pode ne- gar mais tarde tê-lo assinado é chamada não repúdio. Os esquemas de assinatura digital que estudaremos agora aju- dam a garantir o não repúdio. O terceiro requisito é necessário para proteger o cliente caso o preço do ouro dispare e o banco tente montar uma mensagem assinada na qual o cliente pedia uma barra de ouro em vez de uma tonelada. Nesse cenário de fraude, o banco simplesmente guarda para si próprio o restante do ouro. 8.4.1 Assinaturas de chave simétrica Uma estratégia para as assinaturas digitais é ter uma autoridade central que saiba de tudo e na qual todos con- fiem, digamos, Big Brother (BB). Em seguida, cada usuário escolhe uma chave secreta e a leva para o escritório do BB. Assim, somente Alice e BB conhecem a chave secreta de Alice, KA , e assim por diante. Quando deseja enviar uma mensagem em texto sim- ples assinada, P, ao gerente de sua conta, que é Bob, Alice gera KA (B, RA , t, P), onde B é a identidade de Bob, RA é um número aleatório escolhido por Alice, t é um registro de tempo para assegurar a atualidade e KA (B, RA , t, P) é a mensagem criptografada com sua chave, KA . Em seguida, ela envia a mensagem, da maneira descrita na Figura 8.15. BB vê que essa mensagem veio de Alice, descriptografa a mensagem e a envia a Bob, exatamente como mostramos. A mensagem para Bob contém o texto simples da mensa- gem de Alice e também a mensagem assinada KBB (A, t, P). Agora Bob executa a solicitação de Alice. 08_tanen0809_cap08 BR.indd 500 4/25/11 3:08 PM
- 23. Capítulo 8 Segurança deredes 501 O que acontecerá se mais tarde Alice negar ter envia- do a mensagem? Na etapa 1, todo mundo processa todo mundo (pelo menos nos Estados Unidos). Por fim, quando o caso parar nos tribunais e Alice continuar negando ter enviado a mensagem a Bob, o juiz perguntará a Bob como ele pode ter certeza de que a mensagem veio de Alice e não de Trudy. Primeiro, Bob destaca que BB só aceitará uma mensagem de Alice se ela tiver sido criptografada com KA . Portanto, não há possibilidade de Trudy ter enviado a BB uma mensagem falsa no lugar de Alice, sem que BB detec- tasse esse fato de imediato. Em seguida, drasticamente, Bob apresenta a Prova A: KBB (A, t, P). Bob afirma tratar-se de uma mensagem as- sinada por BB que prova o fato de Alice ter enviado P a Bob. Em seguida, o juiz solicita que BB (em quem todos confiam) descriptografe a Prova A. Quando BB testemunha que Bob está dizendo a verdade, o juiz decide a favor de Bob. Caso encerrado. Um problema em potencial com o protocolo de assi- natura da Figura 8.15 é Trudy repetir uma das mensagens. Para minimizar esse risco, são utilizados registros de tempo em todas as mensagens. Além disso, Bob pode verificar to- das as mensagens mais recentes para ver se RA foi usada em alguma delas. Caso isso tenha acontecido, a mensagem será descartada por ser uma repetição. Observe que Bob rejeita- rá as mensagens muito antigas ao verificar seus registros de tempo. Para se proteger contra ataques de repetição repen- tinos, Bob verifica RA em cada uma das mensagens recebi- das para ver se a mensagem foi enviada por Alice durante a última hora. Caso contrário, Bob pode pressupor com toda segurança que essa solicitação é nova. 8.4.2 Assinaturas de chave pública Um problema estrutural com o uso da criptografia de chave simétrica para assinaturas digitais é que todos têm de confiar no Big Brother. Além disso, Big Brother tem de ler todas as mensagens assinadas. Os candidatos mais lógicos à execução do servidor Big Brother são o governo, os bancos, os contadores e os advogados. In- felizmente, nenhuma dessas organizações inspira total confiança a todos os cidadãos. Daí, seria interessante se o ato de assinatura de documentos não exigisse a presença de uma autoridade confiável. Felizmente, a criptografia de chave pública pode tra- zer uma importante contribuição nessa área. Vamos supor que os algoritmos de criptografia e descriptografia de chave pública tenham a propriedade de que E(D(P)) = P além, é claro, da propriedade habitual de que D(E(P)) = P. (O RSA tem essa propriedade; portanto, a suposição não é ir- racional.) Supondo-se que seja esse o caso, Alice pode en- viar uma mensagem de texto simples assinada, P, para Bob transmitindo EB (DA (P)). Observe atentamente que Alice conhece sua própria chave de descriptografia (privada), DA , assim como a chave pública de Bob, EB ; portanto, a criação dessa mensagem é algo que Alice pode fazer. Quando recebe a mensagem, Bob a transforma usando sua chave privada e produz DA (P), como mostra a Figura 8.16. Ele guarda esse texto em um lugar seguro e depois aplica EA para obter o texto simples original. Para ver como a propriedade de assinatura funciona, suponha que depois Alice negue ter enviado a mensagem P para Bob. Quando o caso chegar aos tribunais, Bob po- A, KA (B, RA, t, P) Bob Alice BB KB (A, RA, t, P, KBB (A, t, P)) 1 2 Figura 8.15 Assinaturas digitais com Big Brother. Chave pública de Bob, EB Chave privada de Alice, DA Chave privada de Bob, DB DA(P) DA(P) EB (DA(P)) Linha de transmissão Computador de Alice Computador de Bob P P Chave pública de Alice, EA Figura 8.16 Assinaturas digitais com o uso da criptografia de chave pública. 08_tanen0809_cap08 BR.indd 501 4/25/11 3:08 PM
- 24. 502 Redes decomputadores derá produzir tanto P quanto DA (P). O juiz pode confirmar com facilidade que Bob certamente tem uma mensagem válida criptografada por DA , simplesmente aplicando EA à mensagem. Como Bob não sabe qual é a chave privada de Alice, a única forma de Bob ter adquirido uma mensagem criptografada por essa chave seria se Alice de fato a tivesse enviado. Enquanto estiver presa por perjúrio e fraude, Ali- ce terá bastante tempo para inventar novos algoritmos de chave pública muito interessantes. Apesar de a utilização da criptografia de chave públi- ca para assinaturas digitais ser um esquema elegante, há problemas relacionados ao ambiente onde elas operam e não ao algoritmo básico. De um lado, Bob só poderá pro- var que uma mensagem foi enviada por Alice enquanto DA permanecer secreta. Se Alice revelar sua chave secreta, o argumento deixará de existir, pois qualquer um poderia ter enviado a mensagem, inclusive o próprio Bob. Por exemplo, pode ocorrer um problema se Bob for o corretor de ações de Alice. Alice solicita a Bob que ele com- pre ações ou títulos de determinada empresa. Logo depois disso, o preço cai bruscamente. Para repudiar a mensagem que enviou a Bob, Alice vai à polícia afirmando que sua casa foi assaltada, e o PC que continha sua chave foi rouba- do. Dependendo das leis do estado ou do país onde mora, ela poderá ou não ser legalmente processada, em especial se afirmar que só descobriu o roubo quando chegou em casa após o trabalho, muitas horas depois do ocorrido. Outro problema com o esquema de assinatura é o que acontecerá se Alice decidir alterar sua chave. Isso é legal, e provavelmente é uma boa ideia fazê-lo de vez em quando. Se mais tarde surgir um caso jurídico, como descrevemos antes, o juiz aplicará a EA atual a DA (P) e descobrirá que ela não produz P. Nesse momento, a situação de Bob ficará complicada. Em princípio, qualquer algoritmo de chave pública pode ser usado para assinaturas digitais. O padrão de fato do setor é o algoritmo RSA. Muitos produtos de segurança o utilizam. No entanto, em 1991, o NIST propôs a utiliza- ção de uma variante do algoritmo de chave pública de El Gamal em seu novo padrão, o DSS (Digital Signature Standard). O El Gamal obtém sua segurança a partir da dificuldade de calcular logaritmos discretos, e não da difi- culdade de fatorar números muito extensos. Como sempre acontece quando o governo tenta ditar padrões criptográficos, houve um tumulto. O DSS foi cri- ticado por ser: 1. secreto demais (a NSA projetou o protocolo para utilizar o El Gamal). 2. lento demais (10 a 40 vezes mais lento do que o RSA para verificar assinaturas). 3. novo demais (o El Gamal ainda não foi analisado por completo). 4. inseguro demais (chave fixa de 512 bits). Em uma versão posterior, o quarto ponto rendeu muita discussão quando foram permitidas chaves com até 1.024 bits. Apesar disso, os dois primeiros pontos perma- necem válidos. 8.4.3 Sumário de mensagens Uma crítica aos métodos de assinatura é que eles fre- quentemente reúnem duas funções distintas: autenticação e sigilo. Em geral, a autenticação é necessária, mas o sigilo não. Além disso, obter uma licença para exportação nor- malmente é mais fácil se o sistema em questão oferecer apenas autenticação, mas não sigilo. A seguir, descrevere- mos um esquema de autenticação que não exige a cripto- grafia da mensagem inteira. Esse esquema se baseia na ideia de uma função de hash unidirecional que extrai um trecho qualquer do tex- to simples e, a partir dele, calcula uma sequência de bits de tamanho fixo. Essa função de hash, representada por MD (Message Digest), geralmente é chamada sumário da mensagem e tem quatro propriedades importantes: 1. se P for fornecido, o cálculo de MD(P) será muito fácil. 2. se MD(P) for fornecido, será efetivamente impossível encontrar P. 3. dado P, ninguém pode encontrar P’ tal que MD(P’) = MD(P). 4. uma mudança na entrada de até mesmo 1 bit produz uma saída muito diferente. Para atender ao critério 3, a função de hash deve ter pelo menos 128 bits, de preferência mais. Para atender ao critério 4, o hash deve desfigurar completamente os bits, o que não é diferente dos algoritmos de criptografia de chave simétrica que vimos. Calcular um sumário da mensagem a partir de um tre- cho de texto simples é muito mais rápido que criptogra- far esse texto simples com um algoritmo de chave públi- ca; portanto, os sumários de mensagens podem ser usados para agilizar algoritmos de assinatura digital. Para ver como isso funciona, considere mais uma vez o protocolo de as- sinatura da Figura 8.15. Em vez de assinar P com KBB (A, t, P), agora BB calcula o sumário da mensagem aplicando MD a P, produzindo MD(P). Em seguida, BB inclui KBB (A, t, MD(P)) como o quinto item da lista criptografada com KB que é enviada a Bob, em vez de KBB (A, t, P). Se houver uma contestação, Bob poderá produzir tan- to P quanto KBB (A, t, MD(P)). Depois que Big Brother tiver descriptografado o item para o juiz, Bob terá MD(P) que, certamente, é genuíno, além do P alegado. No entanto, como é impossível para Bob encontrar outra mensagem que produza esse hash, o juiz será facilmente convencido de que Bob está falando a verdade. A utilização de sumá- rios de mensagens dessa forma poupa tempo de criptogra- fia e reduz os custos com o transporte de mensagens. 08_tanen0809_cap08 BR.indd 502 4/25/11 3:08 PM
- 25. Capítulo 8 Segurança deredes 503 Sumários de mensagens também funcionam em siste- mas de criptografia de chave pública, como mostra a Figura 8.17. Aqui, primeiro Alice calcula o sumário da mensagem de seu texto simples. Em seguida, ela assina a mensagem e envia tanto a compilação assinada quando o texto simples a Bob. Se Trudy substituir P durante a operação, Bob per- ceberá a troca quando calcular MD(P). SHA-1 e SHA-2 Diversas funções para o sumário da mensagem foram propostas. Uma das funções mais utilizadas é SHA-1 (Se- cure Hash Algorithm 1) (NIST, 1993). Como em todos os sumários de mensagens, ele opera tratando os bits de uma maneira suficientemente complicada, de modo que cada bit da saída seja afetado por cada bit da entrada. SHA-1 foi de- senvolvimento pela NSA e ratificado pelo NIST no FIPS 180- 1. Ele processa os dados de entrada em blocos de 512 bits e gera um sumário da mensagem de 160 bits. Um modo típico de Alice enviar uma mensagem não secreta mas assinada para Bob é ilustrado na Figura 8.18. Nessa figura, sua men- sagem de texto simples é colocada no algoritmo SHA-1 para obter um hash de 160 bits do SHA-1. Em seguida, Alice assi- na o hash com sua chave privada RSA e envia a mensagem de texto simples e o hash assinado para Bob. Depois de receber a mensagem, Bob calcula o hash SHA-1 e também aplica a chave pública de Alice ao hash assinado para obter o original, H. Se os dois corresponde- rem, a mensagem será considerada válida. Tendo em vista que não há nenhum meio para Trudy modificar a mensa- gem (de texto simples) enquanto ela estiver em trânsito e produzir uma nova mensagem com hash H, Bob pode detectar com facilidade quaisquer mudanças que Trudy te- nha feito na mensagem. Para mensagens cuja integridade seja importante, mas cujo conteúdo não seja secreto, o es- quema da Figura 8.18 é bastante utilizado. Por um custo relativamente pequeno em computação, ele garante que as modificações feitas na mensagem de texto simples em trân- sito poderão ser detectadas com probabilidade muito alta. Agora, vamos ver rapidamente como o SHA-1 funcio- na. Ele começa preenchendo a mensagem com a adição de um bit 1 ao final, seguido pelo número de bits 0 necessários para tornar o tamanho um múltiplo de 512 bits. Em segui- da, um número de 64 bits contendo o tamanho da mensa- gem antes do preenchimento é submetido a uma operação OR nos 64 bits de baixa ordem. Na Figura 8.19, a mensa- gem é mostrada com o preenchimento à direita, porque o texto em inglês e as figuras se estendem da esquerda para a P, DA (MD (P)) Bob Alice Figura 8.17 Assinaturas digitais utilizando sumários de mensagens. Algoritmo SHA-1 H Hash SHA-1 de 160 bits de M DA(H) Hash sinalizado Algoritmo RSA Chave privada de Alice, DA Enviado a Bob Mensagem M de texto simples de Alice (qualquer tamanho) Figura 8.18 Utilização do SHA-1 e do RSA para assinar mensagens não secretas. M0 H0 W0 M1 H1 W1 M2 H2 W2 H3 Mn-1 (a) Início da mensagem Bloco de 512 bits Palavra de 32 bits Preenchimento (b) (c) H4 W79 Figura 8.19 z (a) Uma mensagem preenchida até um multiplo de 512 bits. (b) As variáveis de saída. (c) O array de palavras. 08_tanen0809_cap08 BR.indd 503 4/25/11 3:08 PM
- 26. 504 Redes decomputadores direita (isto é, o canto inferior direito em geral é percebido como o fim da figura). Com os computadores, essa orien- tação corresponde a máquinas big-endian, como SPARC e IBM 360, e seus sucessores, mas o SHA-1 sempre preenche o fim da mensagem, não importando que máquina endian seja usado. Durante o cálculo, o SHA-1 mantém cinco variáveis de 32 bits, de H0 até H4 , onde o hash se acumula. Estas são mostradas na Figura 8.19(b). Elas são inicializadas como constantes especificadas no padrão. Cada um dos blocos de M0 até Mn -1 agora é processado um por vez. Para o bloco atual, as 16 palavras são primeiro copiadas para o início de um array auxiliar de 80 palavras, W, como mostra a Figura 8.19(c). Depois, as outras 64 pa- lavras em W são preenchidas usando a fórmula Wi = S1 (Wi -3 XOR Wi -8 XOR Wi -14 XOR Wi -16 ) (16 ≤ i ≤ 79) onde Sb (W) representa a rotação circular à esquerda da palavra de 32 bits, W, por b bits. Agora, cinco variáveis auxiliares, de A até E, são iniciadas de H0 até H4 , respecti- vamente. O cálculo real pode ser expresso em pseudo-C como: for (i = 0; i 80; i++) { temp = S5 (A) + fi (B, C, D) + E + Wi + Ki ; E = D; D = C; C = S30 (B); B = A; A = temp; } onde as constantes Ki são definidas no padrão. As fun- ções fi são definidas como: fi (B,C,D) = (B AND C) OR (NOT B AND D) (0 ≤ i ≤ 19) fi (B,C,D) = B XOR C XOR D (20 ≤ i ≤ 39) fi (B,C,D) = (B AND C) OR (B AND D) OR (C AND D) (40 ≤ i ≤ 59) fi (B,C,D) = B XOR C XOR D (60 ≤ i ≤ 79) Quando todas as 80 iterações do loop são completadas, as variáveis de A até E são somadas a H0 até H4 , respectivamente. Agora que o primeiro bloco de 512 bits foi processado, o próximo é iniciado. O array W é reiniciado a partir do novo bloco, mas H fica como estava. Quando esse bloco é concluído, o próximo é iniciado, e assim por diante, até to- dos os blocos da mensagem de 512 bits serem processados. Quando o último bloco é concluído, as cinco palavras de 32 bits no array H são transmitidas como saída, formando o hash criptográfico de 160 bits. O código C completo para SHA-1 é dado na RFC 3174. Novas versões de SHA-1 foram desenvolvidas para produzir hashes de 224, 256, 384 e 512 bits. Coletivamen- te, essas versões são chamadas SHA-2. Não apenas esses são hashes maiores do que hashes SHA-1, mas a função de sumário foi mudada para combater alguns pontos fracos em potencial do SHA-1. O SHA-2 ainda não é muito usado, mas provavelmente o será no futuro. MD5 Para completar, vamos mencionar outro sumário que é muito popular. MD5 (Rivest, 1992) é o quinto de uma sé- rie de sumários de mensagens projetados por Ronald Rivest. Resumindo, a mensagem é preenchida para um tamanho de 448 bits (módulo 512). Depois, o comprimento original da mensagem é acrescentado como um inteiro de 64 bits para gerar uma entrada total cujo comprimento é um múltiplo de 512 bits. Em cada rodada, um bloco de entrada de 512 bits é extraído e colocado no buffer de 128 bits. Para que os cálcu- los sejam feitos com maior precisão, também é incluída uma tabela criada a partir da função seno. O objetivo da utilização de uma função conhecida é evitar qualquer suspeita de que o projetista tenha criado uma armadilha secreta para seu próprio uso. Esse processo continua até que todos os blocos de entrada tenham sido consumidos. O conteúdo do buffer de 128 bits forma o sumário de mensagens. Após mais de uma década de uso sólido e estudo, os pontos fracos no MD5 têm levado à capacidade de encon- trar colisões, ou então diferentes mensagens com o mes- mo hash (Sotirov et al., 2008). Esse é o prenúncio do fim de uma função de sumário, pois significa que o sumário não pode ser usado com segurança para representar uma mensagem. Assim, a comunidade de segurança classifica o MD5 como quebrado; ele deve ser substituído sempre que possível, e nenhum sistema novo deverá usá-lo como parte de seu projeto. Apesar disso, você ainda poderá encontrar o MD5 nos sistemas existentes. 8.4.4 O ataque do aniversário No mundo da criptografia, nada é o que parece. Talvez você esteja pensando que são necessárias aproximadamen- te 2m operações para subverter um sumário da mensagem de m bits. Na verdade, normalmente 2m/2 operações serão suficientes, utilizando-se o ataque do aniversário, um método publicado por Yuval (1979) no clássico artigo ‘How to Swindle Rabin’ (Como enganar Rabin). A ideia para esse ataque vem de uma técnica que fre- quentemente os professores de matemática utilizam em seus cursos de probabilidade. A pergunta é a seguinte: quantos alunos você deverá ter em uma sala de aula para que a probabilidade de haver duas pessoas que aniversa- riem no mesmo dia exceda 1/2? A maioria dos alunos espe- ra que a resposta seja superior a 100. Na verdade, a teoria da probabilidade afirma que esse número é apenas 23. In- tuitivamente, sem fazer uma análise rigorosa, com 23 pes- soas podemos formar (23 × 22)/2 = 253 pares diferentes, cada um dos quais tem uma probabilidade igual a 1/365 de ser um acerto. Sob esse aspecto, essa probabilidade deixa de ser tão surpreendente. 08_tanen0809_cap08 BR.indd 504 4/25/11 3:08 PM
- 27. Capítulo 8 Segurança deredes 505 De modo mais geral, se houver algum mapeamento entre as entradas e as saídas, com n entradas (pessoas, mensagens etc.) e k saídas possíveis (aniversários, sumá- rios de mensagens etc.), haverá n(n - 1)/2 pares de entra- da. Se n(n - 1)/2 k, a chance de haver pelo menos uma correspondência será muito boa. Portanto, fazendo uma aproximação, é provável que haja uma correspondência para n k . Esse resultado significa que provavelmente um sumário da mensagem de 64 bits possa ser quebrado gerando-se 232 mensagens e procurando-se duas mensa- gens com o mesmo sumário. Agora, vejamos um exemplo prático. O departamento de ciência da computação da State University nos Estados Uni- dos tem uma única vaga estável para dois professores, Tom e Dick. Tom foi admitido dois anos antes de Dick e, portanto, é convocado para os testes primeiro. Se ele for aprovado, Dick será descartado. Tom sabe que a chefe de seu departamento, Marilyn, gosta muito do trabalho dele; sendo assim, ele pede a Marilyn que escreva uma carta de recomendação ao reitor, que tomará a decisão a respeito do cargo. Depois de enviadas, todas as cartas passam a ser confidenciais. Marilyn pede a sua secretária, Ellen, que escreva a car- ta para o reitor, fazendo um esboço do que deseja. Quan- do a carta está pronta, Marilyn a revisa, calcula e assina o sumário de 64 bits e o envia ao reitor. Ellen pode enviar a carta mais tarde pelo correio eletrônico. Infelizmente para Tom, Ellen está envolvida emocional- mente com Dick e gostaria que Tom fosse descartado; assim, escreve a carta a seguir com as 32 opções entre colchetes. Caro Sr. Reitor, Esta [carta | mensagem] tem como objetivo expressar mi- nha [honesta | franca] opinião a respeito do professor Tom Wil- son, que [é | está] [candidato | prestes] [para | a] obter uma vaga permanente nesta universidade [imediatamente | este ano]. Eu [conheço | trabalho com] o professor Wilson há seis anos. Ele é um [destacado | excelente] pesquisador de grande [ talento | capa- cidade ] [mundialmente | internacionalmente ] conhecido por suas [brilhantes | criativas] ideias a respeito de [muitos | uma grande variedade de] problemas [difíceis | complicados]. Ele também é um [professor | educador] [bastante | mui- to] [respeitado | admirado]. Seus alunos fazem críticas [ma- ravilhosas | espetaculares] de [suas aulas | seus cursos]. Ele é o [professor | orientador] [mais querido | mais conhecido] [da universidade | do departamento]. [Além disso | Além do mais], o professor Wilson é um [grande | fantástico] administrador. [Seus contratos | Suas con- cessões ] trouxeram uma [grande | substancial] quantia em dinheiro para [o | nosso] departamento. [Esse dinheiro | Esses fundos] [permitiu | permitiram] que [criássemos | realizássemos] muitos programas [especiais | importantes], [tais como | por exemplo] o programa Universidade 2000. Sem esses fundos, [seríamos incapazes | não seríamos capazes] de dar continuidade a esse programa, que é tão [importante | essencial] para nós. Afirmo ao senhor que ele é o profissional mais adequado para essa posição. Infelizmente para Tom, assim que acaba de redigir e digitar essa carta, Ellen também digita a seguinte carta: Caro Sr. Reitor, Esta [carta | mensagem] tem como objetivo expressar minha [honesta | franca] opinião a respeito do professor Tom Wilson, que [é | está] [candidato | prestes] [para | a] assumir uma vaga permanente nesta universidade [imediatamente | este ano]. Eu [conheço | trabalho com] Tom há seis anos. Ele é um [incompetente | mau] pesquisador, não é bem visto em sua [especialidade | área]. Sua pesquisa [raramente | esporadi- camente] mostra [bom-senso | conhecimento] dos [principais | mais importantes] problemas atuais. Ele não é um [professor | educador] [bastante | muito] [res- peitado | admirado]. Seus alunos fazem [duras | pesadas] críti- cas de [ suas aulas | seus cursos]. Ele é o [professor | orientador] mais impopular [da universidade | do departamento] devido à sua [tendência | propensão] a [ridicularizar | embaraçar] os alunos que fazem perguntas em suas aulas. [Além disso | Além do mais], Tom é um administrador [ter- rível | fraco]. [Seus contratos | Suas concessões ] trouxeram ape- nas uma [insignificante | pequena] quantia em dinheiro para [o | nosso] departamento. A menos que mais [verbas | fundos] se- jam [alocadas | alocados], teremos de cancelar alguns progra- mas essenciais, tais como seu programa Universidade 2000. Infelizmente, sob essas [condições | circunstâncias], não posso recomendá-lo em sã consciência para essa posição. Ellen passa o programa em seu computador para calcu- lar os 232 sumários de mensagens de cada carta. Há chances de que um sumário da primeira carta corresponda a um su- mário da segunda carta. Caso isso não aconteça, ela poderá incluir algumas outras opções e tentar de novo durante o fim de semana. Suponha que ela encontre uma correspon- dência. Vamos chamar a carta ‘boa’ de A e a ‘ruim’ de B. Em seguida, pelo correio eletrônico, Ellen envia a carta A a Marilyn para que seja aprovada. Ela mantém a carta B completamente secreta, sem mostrá-la a ninguém. É claro que Marilyn aprova a carta, calcula seu sumário da men- sagem de 64 bits, assina o sumário e envia-o assinado ao reitor Smith utilizando o correio eletrônico. Por outro lado, Ellen envia a carta B ao reitor (não a carta A, como deveria fazer). Depois de obter a carta e o sumário da mensagem as- sinado, o reitor executa o algoritmo de sumário da mensa- gem na carta B, observa que ela corresponde ao sumário que Marilyn enviou e despede Tom. O reitor não perce- be que Ellen gerou duas cartas com o mesmo sumário da mensagem e enviou a ele uma mensagem diferente da que Marylin viu e aprovou. (Final opcional: Ellen conta a Dick o que fez. Dick não gosta do que ouve e termina o namoro com ela. Ellen fica furiosa e confessa tudo a Marilyn. Mari- lyn telefona para o reitor. Tom acaba ficando com o cargo.) Com o SHA-1, o ataque do aniversário se torna impraticá- vel, pois, mesmo com um trilhão de sumários por segundo, seriam necessários 32 mil anos para calcular todos os 280 08_tanen0809_cap08 BR.indd 505 4/25/11 3:08 PM
- 28. 506 Redes decomputadores sumários de duas cartas com 80 variantes cada uma e, de qualquer forma, não poderíamos ter certeza de que haveria uma correspondência. É claro que, com uma nuvem de 1 milhão de chips trabalhando em paralelo, 32 mil anos se transformam em duas semanas. 8.5 Gerenciamento de chaves públicas A criptografia de chave pública torna possível a comu- nicação segura a pessoas que não compartilham uma chave comum, e também possibilita a assinatura de mensagens sem a presença de uma terceira parte confiável. Finalmente, os sumários assinados das mensagens permitem verificar com facilidade e segurança a integridade de mensagens recebidas. Porém, existe um problema que ignoramos até aqui: se Alice e Bob não conhecem um ao outro, como eles vão obter as respectivas chaves públicas para iniciar o proces- so de comunicação? A solução óbvia — colocar a chave pública no site — não funciona pela seguinte razão: supo- nha que Alice queira pesquisar a chave pública de Bob em seu site. Como ela fará isso? Bem, Alice começa digitando o URL de Bob. Seu navegador então pesquisa o endereço DNS da home page de Bob e lhe envia uma solicitação GET, como mostra a Figura 8.20. Infelizmente, Trudy intercepta a solicitação e responde com uma home page falsa, talvez uma cópia da de Bob, exceto pela substituição da chave pública de Bob pela chave pública de Trudy. Quando Alice codifica sua primeira mensagem com ET , ela a decodificará, lerá e recodificará com a chave pública de Bob, enviando a mensagem a Bob, que não sabe que ela está lendo suas mensagens recebidas. Pior ainda, Trudy poderia modificar as mensagens antes de recodificá-las para Bob. É claro que há necessidade de algum mecanismo para garantir que as chaves públicas possam ser trocadas em segurança. 8.5.1 Certificados Como uma primeira tentativa de distribuição de cha- ves públicas com segurança, poderíamos imaginar um cen- tro de distribuição de chaves, KDC (Key Distribution Center), disponível on-line 24 horas por dia, a fim de for- necer chaves públicas por demanda. Um dos muitos pro- blemas com essa solução é o fato de ela não ser escalável, e o centro de distribuição de chaves rapidamente se tornaria um gargalo. Além disso, se ele ficasse inativo, a segurança da Internet seria paralisada repentinamente. Por essas razões, as pessoas desenvolveram uma solu- ção diferente, que não exige que o centro de distribuição de chaves esteja on-line todo o tempo. De fato, ele não precisa estar on-line de modo algum. Em vez disso, ele certifica as chaves públicas pertencentes a pessoas, empresas e outras organizações. Uma organização que certifica chaves públi- cas é chamada autoridade de certificação, ou CA (Certifi- cation Authority). Como um exemplo, suponha que Bob queira permi- tir que Alice e outras pessoas se comuniquem com ele com segurança. Ele pode ir à CA com sua chave pública e seu passaporte ou algum outro documento de identidade e solicitar a certificação. A CA emite então um certifica- do semelhante ao da Figura 8.21 e assina seu hash SHA-1 com a chave privada da CA. Em seguida, Bob paga a taxa da CA e obtém um CD contendo o certificado e seu hash assinado. A principal função de um certificado é vincular uma chave pública ao nome de um protagonista (indivíduo, em- presa etc.). Os certificados em si não são secretos ou prote- gidos. Por exemplo, Bob poderia decidir colocar seu novo certificado em seu site, com um link na página principal informando: clique aqui para ver meu certificado de cha- ve pública. O clique resultante retornaria o certificado e o bloco de assinatura (o hash SHA-1 assinado do certificado). Agora, vamos percorrer o cenário da Figura 8.20 no- vamente. Quando Trudy intercepta a solicitação de Alice para a home page de Bob, o que ela pode fazer? Trudy pode inserir seu próprio certificado e seu bloco de assina- tura na página falsa; porém, quando Alice ler o certifica- do, verá imediatamente que não está se comunicando com Bob, porque o nome de Bob não está no certificado. Trudy pode modificar a home page de Bob durante a execução, substituindo a chave pública de Bob por sua própria chave. Porém, quando Alice executar o algoritmo SHA-1 no cer- tificado, ela obterá um hash que não corresponde ao que ela recebe ao aplicar a chave pública conhecida da CA ao bloco de assinatura. Como Trudy não tem a chave privada da CA, ela não tem meios de gerar um bloco de assinatura que contenha o hash da página Web modificada com sua chave pública. Desse modo, Alice pode estar certa de que possui a chave pública de Bob e não a de Trudy ou de outra pessoa. Como afirmamos, esse esquema não exige que a CA esteja on-line para verificação, eliminando assim um gargalo em potencial. 4. EB(Mensagem) Alice Trudy 1. Obter a home page de Bob 2. Home page falsa com ET 3. ET(Mensagem) Bob Figura 8.20 z Um modo de Trudy subverter a criptografia de chave pública. 08_tanen0809_cap08 BR.indd 506 4/25/11 3:08 PM
- 29. Capítulo 8 Segurança deredes 507 Embora a função-padrão de um certificado seja vincular uma chave pública a um protagonista, um certificado tam- bém pode ser usado para vincular uma chave pública a um atributo. Por exemplo, um certificado poderia afirmar: ‘esta chave pública pertence a alguém com mais de 18 anos’. Ela pode ser usada para provar que o proprietário da chave pri- vada não é menor de idade e, portanto, pode acessar mate- rial não apropriado para crianças, e assim por diante, mas sem revelar a identidade do proprietário. Em geral, a pessoa que tivesse o certificado o enviaria ao site, ao protagonis- ta ou ao processo que solicitasse informações sobre a idade. Esse site, protagonista ou processo geraria então um número aleatório e o codificaria com a chave pública no certificado. Se o proprietário fosse capaz de decodificá-lo e enviá-lo de volta, essa seria a prova de que o proprietário de fato tinha o atributo declarado no certificado. Como alternativa, o nú- mero aleatório poderia ser usado para gerar uma chave de sessão pela duração da conversação. Outro exemplo de situação em que um certificado po- deria conter um atributo é um sistema distribuído orienta- do a objetos. Em geral, cada objeto tem diversos métodos. O proprietário do objeto poderia fornecer a cada cliente um certificado com um mapa de bits dos métodos que o cliente tem permissão para invocar e vincular o mapa de bits a uma chave pública, usando um certificado assinado. Mais uma vez, se o proprietário do certificado puder provar a posse da chave privada correspondente, ele terá permissão para executar os métodos no mapa de bits. A identidade do proprietário não precisa ser conhecida, uma característica útil em situações nas quais a privacidade é importante. 8.5.2 X.509 Se todos os que quisessem algo assinado fossem à CA com um tipo de certificado diferente, logo se tornaria um problema administrar todos os formatos diferentes. Para re- solver esse problema, foi criado e aprovado pela ITU um pa- drão para certificados. O padrão é chamado X.509 e seu uso está difundido na Internet. Ele passou por três versões desde a padronização inicial, em 1988. Vamos descrever a V3. O X.509 foi muito influenciado pelo mundo OSI, e toma emprestadas algumas de suas piores característi- cas (por exemplo, nomenclatura e codificação). De modo surpreendente, a IETF aceitou o X.509, embora em qua- se todas as outras áreas — desde endereços de máquina até protocolos de transporte e formatos de correio eletrônico — ela tenha ignorado o OSI e tentado fazer tudo da maneira certa. A versão da IETF do X.509 é descrita na RFC 3280. Em seu núcleo, o X.509 é um modo de descrever cer- tificados. Os principais campos em um certificado estão listados na Tabela 8.3. As descrições dadas na tabela de- vem fornecer uma ideia geral do significado dos campos. Para obter mais informações, consulte o próprio padrão ou a RFC 2459. Por exemplo, se Bob trabalhasse no departamento de em- préstimos do Money Bank, seu endereço X.500 poderia ser: /C=US/O=MoneyBank/OU=Loan/CN=Bob/ onde C é o país, O é a organização, OU é a unidade or- ganizacional e CN é o nome comum. As CAs e outras enti- dades são identificadas de modo semelhante. Um problema significativo com os nomes X.500 é que, se Alice estiver tentando entrar em contato com bob@moneybank.com e receber um certificado com um nome X.500, talvez não fique claro para ela a que Bob o certificado se refere. Feliz- mente, a partir da versão 3, os nomes DNS são permitidos, em lugar de nomes X.500; assim, esse problema por fim deve desaparecer. Os certificados são codificados com o uso da ASN.1 (Abstract Syntax Notation 1) da OSI, que pode ser con- siderada uma struct em C, exceto por sua notação muito peculiar e extensa. Para obter mais informações sobre o X.509, consulte Ford e Baum (2000). Certifico que a chave pública 19836A8B03030CF83737E3837837FC3s7092827262643FFA82710382828282A pertence a João Roberto da Silva Avenida Brasil, 12345 Rio das Ostras, RJ 28890-000 Nascimento: 7 de setembro de 1958 E-mail: bob@supernet.com.br Hash SHA-1 do certificado acima assinado com a chave privada da CA Figura 8.21 z Um certificado possível e seu hash assinado. 08_tanen0809_cap08 BR.indd 507 4/25/11 3:08 PM
- 30. 508 Redes decomputadores 8.5.3 Infraestruturas de chave pública Fazer uma única CA emitir todos os certificados do mundo é algo que com certeza não funcionaria. Ela entra- ria em colapso sob a carga e também seria um ponto central de falha. Uma solução possível poderia ser a existência de várias CAs, todas administradas pela mesma organização e todas usando a mesma chave privada para assinar certifi- cados. Embora isso pudesse resolver o problema da carga e da falha, há um novo problema: o vazamento de chaves. Se houvesse dezenas de servidores espalhados pelo mundo, todos com a chave privada da CA, o risco de que a chave privada fosse roubada ou sofresse algum outro tipo de va- zamento seria bastante aumentado. Tendo em vista que o comprometimento dessa chave arruinaria a infraestrutura de segurança eletrônica do mundo, a existência de uma única CA central é muito arriscada. Além disso, que organização operaria a CA? É difí- cil imaginar uma autoridade que fosse aceita em todo o mundo como uma entidade legítima e confiável. Em al- guns países, as pessoas insistiriam em que essa entidade fosse o governo; em outros países, elas insistiriam em que não fosse o governo. Por essas razões, foi desenvolvido um modo diferente de certificar chaves públicas, identificado pelo nome geral PKI (Public Key Infrastructure). Nesta seção, resumire- mos como ele funciona em linhas gerais, embora existam muitas propostas relativas aos detalhes que provavelmente vão evoluir com o tempo. Uma PKI tem vários componentes, incluindo usuários, CAs, certificados e diretórios. A função da PKI é fornecer um modo de estruturar esses componentes e definir pa- drões para os vários documentos e protocolos. Uma forma particularmente simples de PKI é uma hierarquia de CAs, como mostra a Figura 8.22. Nesse exemplo, apresentamos três níveis, mas, na prática, pode haver um número menor ou maior. A CA de nível superior, chamada raiz, certifica CAs do segundo nível, que denominamos RAs (Regional Authorities), porque podem cobrir alguma região geo- gráfica, como um país ou um continente. Entretanto, esse termo não é padrão; de fato, nenhum termo é realmen- te padrão para os diferentes níveis da árvore. Por sua vez, as RAs certificam as CAs reais, que emitem os certificados X.509 para organizações e indivíduos. Quando a raiz au- toriza uma nova RA, ela gera um certificado X.509 anun- ciando que aprovou a RA, inclui a chave pública da nova RA no certificado, assina o certificado e o entrega à RA. De modo semelhante, quando uma RA aprova uma nova CA, ela produz e assina um certificado declarando sua aprova- ção e contendo a chave pública da CA. Nossa PKI funciona de modo semelhante. Suponha que Alice precise da chave pública de Bob, a fim de se co- municar com ele; então, ela procura e encontra um certi- ficado contendo a chave, assinado pela CA 5. Porém, Alice nunca ouviu falar da CA 5. Pelo que ela sabe, a CA 5 pode- ria ser a filha de 10 anos de Bob. Ela poderia ir até a CA 5 e dizer: prove sua legitimidade. A CA 5 responde com o certi- ficado que recebeu da RA 2, que contém a chave pública da CA 5. Agora, munida da chave pública da CA 5, Alice pode confirmar que o certificado de Bob foi de fato assinado pela CA 5 e, portanto, é válido. A menos que a RA 2 seja o filho de 12 anos de Bob. Nesse caso, a próxima etapa é pedir à RA 2 que prove sua legitimidade. A resposta à consulta de Alice é um certificado assinado pela raiz contendo a chave pública da RA 2. Agora, Alice tem certeza de que possui a chave pública de Bob. Campo Significado Version A versão do X.509 Serial number Este número, somado ao nome da CA, identifica o certificado de forma exclusiva Signature algorithm O algoritmo usado para assinar o certificado Issuer Nome X.500 da CA Validity period Períodos inicial e final de validade Subject name A entidade cuja chave está sendo certificada Public key A chave pública da entidade certificada e a ID do algoritmo utilizado Issuer ID Uma ID opcional que identifica de forma exclusiva o emissor do certificado Subject ID Uma ID opcional que identifica de forma exclusiva a entidade certificada Extensions Muitas extensões foram definidas Signature A assinatura do certificado (assinado pela chave privada da CA) Tabela 8.3 z Os campos básicos de um certificado X.509. 08_tanen0809_cap08 BR.indd 508 4/25/11 3:08 PM
- 31. Capítulo 8 Segurança deredes 509 No entanto, como Alice encontra a chave pública da raiz? Por mágica. Supõe-se que todo mundo conheça a chave pública da raiz. Por exemplo, seu navegador pode ter sido distribuído já contendo a chave pública da raiz. Bob é o tipo de sujeito amigável e não quer dar muito trabalho a Alice. Ele sabe que Alice vai ter de verificar a CA 5 e a RA 2; assim, para evitar dificuldades, ele reú- ne os dois certificados necessários e os fornece a ela jun- to com seu próprio certificado. Agora, ela pode usar seu conhecimento da chave pública da raiz para confirmar o certificado de nível superior e a chave pública que ele contém para verificar o segundo certificado. Desse modo, Alice não precisa entrar em contato com ninguém para fazer a verificação. Como os certificados são todos assina- dos, ela pode detectar com facilidade quaisquer tentati- vas de falsificar seu conteúdo. Uma cadeia de certificados como essa, que volta à raiz, às vezes é chamada corrente de confiança ou caminho de certificação. A técnica é amplamente utilizada na prática. É claro que ainda temos o problema de saber quem vai administrar a raiz. A solução é não haver uma única, mas sim várias raízes, cada uma com suas próprias RAs e CAs. De fato, os navegadores modernos são previamente carregados com as chaves públicas de mais de 100 raízes, às vezes referidas como âncoras de confiança. Desse modo, pode-se evitar ter uma única autoridade confiável no mundo inteiro. Entretanto, agora existe a questão de como o forne- cedor do navegador decide quais das supostas âncoras de confiança são de fato confiáveis e quais são desprezíveis. Tudo se reduz à confiança do usuário no fornecedor do na- vegador para fazer escolhas sensatas e não aprovar simples- mente todas as âncoras de confiança dispostas a pagar por sua inclusão na lista. A maioria dos navegadores permite que os usuários inspecionem as chaves da raiz (em geral, sob a forma de certificados assinados pela raiz) e eliminem qualquer uma que parecer obscura. Diretórios Outra questão importante para qualquer PKI é onde estão armazenados os certificados (e suas cadeias de retor- no até alguma âncora de confiança conhecida). Uma possi- bilidade é fazer cada usuário armazenar seus próprios certi- ficados. Embora isso seja seguro (isto é, não existe nenhum meio de os usuários adulterarem certificados assinados sem detecção), também é inconveniente. Uma alternativa proposta é usar o DNS como um diretório de certificados. Antes de entrar em contato com Bob, é provável que Alice tenha de pesquisar seu endereço IP usando o DNS; então, por que não fazer o DNS retornar toda a cadeia de certifica- dos de Bob juntamente com seu endereço IP? Algumas pessoas acham que essa é a melhor alterna- tiva, mas outras talvez prefiram servidores de diretórios dedicados, cuja única tarefa seja administrar certificados X.509. Tais diretórios poderiam fornecer serviços de pes- quisa usando propriedades dos nomes X.500. Por exem- plo, na teoria tal serviço de diretório poderia transferir uma consulta como: ‘Forneça uma lista de todas as pessoas cha- madas Alice que trabalham em departamentos de vendas de algum lugar nos Estados Unidos ou no Canadá’. Revogação O mundo real também está repleto de certificados, como de passaportes e carteiras de habilitação. Às vezes, esses certificados podem ser revogados, bem como as car- teiras de habilitação para os que são flagrados dirigindo al- coolizados ou cometendo outras infrações de trânsito. O mesmo problema ocorre no mundo digital: a autoridade que concede um certificado pode decidir revogá-lo por- que a pessoa ou organização que o possui cometeu algum abuso. Ele também pode ser revogado se a chave privada foi exposta ou, pior ainda, se a chave privada da CA foi comprometida. Desse modo, uma PKI precisa lidar com a questão da revogação. A possibilidade de revogação torna as coisas mais complicadas. CA 1 CA 2 (a) (b) CA 3 CA 4 CA 5 RA 2 RA 2 é aprovada. Sua chave pública é 47383AE349... Assinatura da raiz RA 1 Raiz CA 5 é aprovada. Sua chave pública é 6384AF863B... Assinatura da RA 2 RA 2 é aprovada. Sua chave pública é 47383AE349... Assinatura da raiz CA 5 é aprovada. Sua chave pública é 6384AF863B... Assinatura da RA 2 Figura 8.22 z (a) Uma PKI hierárquica. (b) Uma cadeia de certificados. 08_tanen0809_cap08 BR.indd 509 4/25/11 3:08 PM
- 32. 510 Redes decomputadores Um primeiro passo nessa direção é fazer cada CA emi- tir periodicamente uma lista de revogação de certificados, ou CRL (Certificate Revocation List), fornecendo os números de série de todos os certificados que ela revogou. Como os certificados contêm prazos de validade, a CRL só precisa conter os números de série de certificados ainda não vencidos. Uma vez que seu prazo de validade tenha passado, um certificado se torna automaticamente inváli- do, e assim não há necessidade de distinção entre os que al- cançaram o prazo-limite e os que foram de fato revogados. Em ambos os casos, eles não podem mais ser utilizados. Infelizmente, a introdução de CRLs significa que um usuário prestes a usar um certificado deve agora adquirir a CRL para ver se o certificado foi revogado. Se foi, ele não deve ser usado. Porém, mesmo que o certificado não esteja na lista, ele poderia ter sido revogado logo após a lista ter sido publicada. Desse modo, a única forma de realmente ter certeza é consultar a CA. Além disso, no próximo uso do certificado, a CA tem de ser consultada de novo, pois o certi- ficado poderia ter sido revogado alguns segundos antes. Outra complicação é o fato de um certificado revoga- do poder ser reabilitado, por exemplo, se tiver sido revogado pelo não pagamento de alguma taxa que foi paga poste- riormente. Ter de lidar com a revogação (e talvez com a reabilitação) elimina uma das melhores propriedades dos certificados, ou seja, a possibilidade de usá-los sem ter de entrar em contato com uma CA. Onde as CRLs devem ser armazenadas? Um boa alter- nativa seria armazená-las no mesmo local em que estão os próprios certificados. Uma estratégia é a CA publicar ati- vamente CRLs periódicas e fazer com que os diretórios as processem apenas removendo os certificados revogados. Se os diretórios não forem usados para armazenar os certifica- dos, as CRLs poderão ser guardadas em cache em diversos locais convenientes na rede. Como uma CRL também é um documento assinado, se ela for adulterada, essa ação pode- rá ser facilmente detectada. Se os certificados tiverem uma longa duração, as CRLs também serão longas. Por exemplo, se os cartões de crédi- to forem válidos por cinco anos, o número de revogações pendentes será muito maior do que seria se fossem emitidos novos cartões a cada três meses. Um modo-padrão de lidar com CRLs longas é emitir uma lista mestra com pouca fre- quência, mas emitir atualizações frequentes para a lista. Isso reduz a largura de banda necessária para distribuir as CRLs. 8.6 Segurança da comunicação Agora, concluímos nosso estudo das principais ferra- mentas. A maior parte das técnicas e protocolos importan- tes foi abordada. O restante do capítulo estuda a aplicação dessas técnicas na prática para proporcionar segurança às redes, além de alguns conceitos sobre os aspectos sociais da segurança, no final do capítulo. Nas quatro seções a seguir, examinaremos a segurança da comunicação, isto é, como levar os bits secretamente e sem alteração da origem até o destino, e como manter bits indesejáveis do lado de fora. Essas não são de modo algum as únicas questões de segurança em redes, mas certamen- te estão entre as mais importantes, o que nos dá um bom ponto de partida. 8.6.1 IPsec A IETF sabia fazia muitos anos que havia carência de segurança na Internet. Não era fácil aumentá-la, porque havia uma disputa para definir onde colocá-la. A maioria dos especialistas em segurança acredita que, para serem realmente seguras, a criptografia e as verificações de inte- gridade devem ser realizadas fim a fim (isto é, na camada de aplicação). Desse modo, o processo de origem cripto- grafa e/ou protege a integridade dos dados e os envia ao processo de destino, onde eles são descriptografados e/ou verificados. Qualquer adulteração realizada entre esses dois processos, inclusive dentro de qualquer sistema operacio- nal, poderá então ser detectada. A dificuldade com essa abordagem é que ela exige a troca de todas as aplicações, a fim de torná-las cientes da segurança. Nessa visão, a se- gunda melhor abordagem é inserir a criptografia na camada de transporte ou em uma nova camada entre a camada de aplicação e a camada de transporte, tornando-a ainda fim a fim, mas sem exigir que as aplicações sejam alteradas. A visão oposta é que os usuários não entendem de segurança e não serão capazes de usá-la corretamente e, como ninguém quer modificar programas existentes, a ca- mada de rede devia autenticar e/ou codificar pacotes sem que os usuários estejam envolvidos. Depois de anos de ba- talhas, essa visão ganhou apoio suficiente para que fosse definido um padrão de segurança da camada de rede. Em parte, o argumento era que realizar a codificação na ca- mada de rede não impediria que usuários conscientes da segurança a implementassem na camada de aplicação e, até certo ponto, isso também poderia ajudar os usuários sem consciência da segurança. O resultado dessa guerra foi um projeto chamado IPsec (IP security), descrito nas RFCs 2401, 2402 e 2406, entre outras. Nem todos os usuários desejam a criptografia (por- que ela é dispendiosa em termos computacionais). Em vez de torná-la opcional, decidiu-se exigir a criptografia o tempo todo, mas permitir o uso de um algoritmo nulo. O algoritmo nulo é descrito e elogiado por sua simplicidade, facilidade de implementação e grande velocidade na RFC 2410. O projeto completo do IPsec é uma estrutura para vários serviços, algoritmos e detalhamentos. A razão para vários ser- viços é que nem todo mundo quer pagar o preço de ter to- dos os serviços o tempo todo, e assim os serviços estão dis- poníveis à escolha de cada usuário. Os principais serviços são sigilo, integridade de dados e proteção contra ataques de reprodução (em que o intruso reproduz uma conver- 08_tanen0809_cap08 BR.indd 510 4/25/11 3:08 PM
- 33. Capítulo 8 Segurança deredes 511 sação). Todos esses serviços se baseiam na criptografia de chave simétrica, porque o alto desempenho é fundamental. A razão de vários algoritmos é que um algoritmo que agora é considerado seguro poderá ser violado no futuro. Tornar o IPsec independente do algoritmo mantém a es- trutura mesmo se algum algoritmo específico for violado posteriormente. A razão para vários níveis de detalhamento é possibili- tar a proteção de uma única conexão TCP, de todo o tráfego entre um par de hosts ou de todo o tráfego entre um par de roteadores seguros, além de outras possibilidades. Um aspecto um tanto surpreendente do IPsec é que, embora esteja na camada IP, ele é orientado a conexões. Na realidade, isso não é muito surpreendente porque, para ter alguma segurança, uma chave tem de ser estabelecida e usada por um período de tempo — basicamente, uma espécie de conexão com um nome diferente. Além disso, as conexões amortizam os custos de configuração por vários pacotes. Uma “conexão” no contexto do IPsec é chamada associação de segurança, ou SA (Security Association). Uma SA é uma conexão simplex entre duas extremidades e tem um identificador de segurança associado a ela. Se houver necessidade de tráfego seguro em ambos os senti- dos, serão exigidas duas associações de segurança. Os iden- tificadores de segurança são transportados em pacotes que percorrem essas conexões seguras e são usados para pes- quisar chaves e outras informações relevantes ao chegar um pacote seguro. Tecnicamente, o IPsec tem duas partes principais. A primeira parte descreve dois novos cabeçalhos que podem ser acrescentados aos pacotes para transportar o identifica- dor de segurança, dados de controle de integridade e outras informações. A outra parte, ISAKMP (Internet Security Association and Key Management Protocol), trata do estabelecimento de chaves. ISAKMP é um framework. O protocolo principal para executar o trabalho é IKE (Inter- net Key Exchange). Deve-se usar a versão 2 do IKE, des- crita na RFC 4306, pois a versão anterior continha muitas falhas, conforme indicado por Perlman e Kaufman (2000). O IPsec pode ser usado de dois modos. No modo de transporte, o cabeçalho IPsec é inserido logo após o cabe- çalho IP. O campo Protocolo no cabeçalho IP é alterado para indicar que o cabeçalho IPsec vem após o cabeçalho IP nor- mal (antes do cabeçalho TCP). O cabeçalho IPsec contém informações de segurança, principalmente o identificador de SA, um novo número de sequência e possivelmente uma verificação de integridade da carga útil. No modo tunelamento, todo o pacote IP, incluindo o cabeçalho, é encapsulado no corpo de um novo pacote IP com um cabeçalho IP completamente novo. O modo túnel é útil quando o túnel termina em um local diferente do des- tino final. Em alguns casos, o fim do túnel é uma máquina com gateway de segurança, por exemplo, um firewall da empresa. Nesse modo, o gateway de segurança encapsula e desencapsula pacotes à medida que eles passam por ele. Quando o túnel termina nessa máquina segura, as máqui- nas da LAN da empresa não têm de tomar conhecimento do IPsec. Isso é tarefa do firewall. O modo túnel também é útil quando um conjunto de conexões TCP é agregado e tratado como um único flu- xo codificado, porque isso evita que um intruso veja quem está enviando, quem está recebendo e quantos pacotes são enviados. Às vezes, o simples conhecimento da quantidade de tráfego e de seu destino é uma informação valiosa. Por exemplo, se durante uma crise militar o volume de tráfego que flui entre o Pentágono e a Casa Branca cair de for- ma abrupta, mas o volume de tráfego entre o Pentágono e alguma instalação militar nas profundezas das Montanhas Rochosas do Colorado aumentar na mesma proporção, um intruso poderá deduzir algumas informações úteis desses dados. O estudo dos padrões de fluxo de pacotes, ainda que eles estejam codificados, é chamado análise de tráfego. O modo túnel fornece um meio para anular até certo ponto essa análise. A desvantagem do modo túnel é que ele acres- centa um cabeçalho IP extra, aumentando assim substan- cialmente o tamanho dos pacotes. Em contraste, o modo de transporte não afeta muito o tamanho dos pacotes. O primeiro cabeçalho novo é o cabeçalho de autentica- ção, ou AH (Authentication Header). Ele fornece veri- ficação de integridade e segurança contra reprodução, mas não oferece sigilo (isto é, não há criptografia de dados). O uso do AH no modo de transporte é ilustrado na Figura 8.23. No IPv4, ele é inserido entre o cabeçalho IP (incluin- do quaisquer opções) e o cabeçalho TCP. No IPv6 ele é sim- plesmente outro cabeçalho de extensão e é tratado como tal. De fato, o formato é próximo ao de um cabeçalho de extensão padrão do IPv6. É possível que a carga útil tenha de ser preenchida até completar algum tamanho específico para o algoritmo de autenticação, como mostra a figura. Agora, vamos examinar o cabeçalho AH. O campo Pró- ximo cabeçalho é usado para armazenar o valor anterior que o campo Protocolo do IP tinha antes de ser substituído por 51 para indicar que haverá um cabeçalho AH em seguida. Na maioria dos casos, o código para o TCP (6) ficará aqui. O campo Tamanho da carga útil é o número de palavras de 32 bits no cabeçalho AH, menos 2 unidades. O campo Índice de parâmetros de segurança é o identi- ficador da conexão. Ele é inserido pelo transmissor para indicar um registro específico no banco de dados do recep- tor. Esse registro contém a chave compartilhada usada nes- sa conexão e outras informações sobre a conexão. Se esse protocolo tivesse sido criado pela ITU e não pela IETF, esse campo seria chamado Número do circuito virtual. O campo Número de sequência é usado para numerar to- dos os pacotes enviados em uma SA. Todo pacote recebe um número exclusivo, até mesmo as retransmissões. Em outras palavras, a retransmissão de um pacote recebe um número diferente do original (embora seu número de sequência do 08_tanen0809_cap08 BR.indd 511 4/25/11 3:08 PM
- 34. 512 Redes decomputadores TCP seja o mesmo). A finalidade desse campo é detectar ata- ques de reprodução. Esses números de sequência não podem se repetir. Se todos os 232 se esgotarem, terá de ser estabelecida uma nova SA para dar continuidade à comunicação. Finalmente, chegamos ao campo Dados de autenticação, um campo de comprimento variável, que contém a assi- natura digital da carga útil. Quando a SA é estabelecida, os dois lados negociam o algoritmo de assinatura que vão usar. Normalmente, não é utilizada aqui a criptografia de chave pública, porque os pacotes devem ser processados de forma extremamente rápida e todos os algoritmos de chave pública conhecidos são lentos demais. Como o IPsec se ba- seia na criptografia de chave simétrica, e como o transmis- sor e o receptor negociam uma chave compartilhada antes de estabelecer uma SA, a chave compartilhada é usada no cálculo da assinatura. Um modo simples é calcular o hash sobre o pacote, somado à chave compartilhada. É claro que a chave compartilhada não é transmitida. Um esque- ma como esse é chamado HMAC (Hashed Message Au- thentication Code). É muito mais rápido calcular o valor desse esquema que executar primeiro o SHA-1 e depois executar o RSA sobre o resultado. O cabeçalho AH não permite criptografia dos dados; portanto, ele é útil principalmente quando a verificação da integridade é necessária, mas não o sigilo. Uma caracte- rística do AH que vale a pena notar é que a verificação de integridade abrange alguns dos campos do cabeçalho IP, ou seja, aqueles que não se alteram à medida que o pacote passa de um roteador para outro. Por exemplo, o campo Tempo de vida muda a cada hop e assim não pode ser incluí- do na verificação de integridade. Contudo, o endereço de origem IP é incluído na verificação, o que torna impossível para um intruso falsificar a origem de um pacote. O cabeçalho IPsec alternativo é a ESP (Encapsulating Security Payload). Seu uso no modo de transporte e no modo túnel é mostrado na Figura 8.24. O cabeçalho ESP consiste em duas palavras de 32 bits. Elas constituem os campos Índice de parâmetros de segurança e Número de sequência, que vimos no AH. Uma terceira pala- vra que geralmente segue esses campos (mas tecnicamente não faz parte do cabeçalho) é o Vetor de referência, usado para a criptografia de dados, a menos que não seja utilizada criptografia, e nesse caso ele será omitido. A ESP também fornece verificações de integridade do HMAC, como o AH; porém, em vez de ser incluídas no cabeçalho, elas vêm depois da carga útil, como mostra a Fi- gura 8.24. A colocação do HMAC no final tem uma vanta- gem em uma implementação de hardware: o HMAC pode ser calculado à medida que os bits saem pela interface de rede e são acrescentados ao final. Por essa razão, as redes Cabeçalho IP AH 32 bits Índice de parâmetros de segurança Próximo cabeçalho Tam. carga útil (Reservado) Número de sequência Dados de autenticação (HMAC) Cabeçalho TCP Autenticado Carga útil + preenchimento Figura 8.23 z O cabeçalho de autenticação do IPsec em modo de transporte para o IPv4. Cabeçalho ESP Novo cabeçalho IP Antigo cabeçalho IP Cabeçalho TCP Autenticado Carga útil + preenchimento (b) Autenticação (HMAC) Cabeçalho ESP Cabeçalho IP Cabeçalho TCP Carga útil + preenchimento (a) Autenticação (HMAC) Autenticado Codificado Codificado Figura 8.24 z (a) ESP em modo de transporte. (b) ESP em modo túnel. 08_tanen0809_cap08 BR.indd 512 4/25/11 3:08 PM
- 35. Capítulo 8 Segurança deredes 513 Ethernet e outras LANs têm seus CRCs em um final (trai- ler), e não em um cabeçalho. Com o AH, o pacote tem de ser armazenado no buffer e a assinatura deve ser calculada antes que seja possível enviar o pacote, reduzindo poten- cialmente o número de pacotes/s que podem ser enviados. Considerando que a ESP pode fazer tudo o que o AH pode fazer e muito mais, além de ser mais eficiente durante a fase inicial, surge a questão: afinal, qual é a necessidade do AH? A resposta é principalmente histórica. No início, o AH cuidava apenas da integridade, enquanto a ESP tratava do sigilo. Mais tarde, a integridade foi acrescentada à ESP, mas as pessoas que projetaram o AH não queriam deixá-lo morrer depois de tanto trabalho. No entanto, o único argu- mento real dessas pessoas se baseava no fato de que o AH é capaz de verificar uma parte do cabeçalho IP, o que a ESP não faz. Porém, esse é um argumento fraco, como também o argumento de que um produto com suporte para o AH, mas não para a ESP, poderia ter menos problemas para obter uma licença de exportação, porque não poderia efetuar a codificação. É provável que o AH fique defasado no futuro. 8.6.2 Firewalls A capacidade de conectar um computador em qual- quer lugar a outro computador em qualquer lugar é uma faca de dois gumes. Para as pessoas que estão em casa, é muito divertido navegar pela Internet. Para os gerentes de segurança das empresas, trata-se de um pesadelo. Muitas empresas têm grandes quantidades de informações confi- denciais on-line — segredos comerciais, planos de desen- volvimento de produtos, estratégias de marketing, análises financeiras etc. A revelação dessas informações para um concorrente poderia ter consequências terríveis. Além do perigo das informações virem a público, tam- bém há o perigo do vazamento dessas informações dentro da empresa. Em particular, vírus, worms e outras pestes digitais podem burlar a segurança, destruir dados valiosos e consumir muito tempo dos administradores que tentam eliminar a confusão causada por eles. Com frequência, eles são trazidos por funcionários descuidados que querem brincar com algum jogo novo muito divertido. Em conse- quência disso, são necessários mecanismos para manter os ‘bons’ bits e descartar os ‘maus’ bits. Um dos métodos é usar o IPsec, que protege os dados em trânsito entre sites seguros. No entanto, o IPsec não faz nada para impedir as pragas digitais nem os intrusos de invadir a LAN da empre- sa. Para ver como alcançar esse objetivo, precisamos exa- minar os firewalls. Os firewalls são apenas uma adaptação moderna de uma antiga forma de segurança medieval: cavar um fosso profundo em torno do castelo. Esse recurso forçava todos aqueles que quisessem entrar ou sair do castelo a passar por uma única ponte levadiça, onde poderiam ser revistados por guardas. Nas redes, é possível usar o mesmo artifício: uma empresa pode ter muitas LANs conectadas de forma arbitrá- ria, mas todo o tráfego de saída ou de entrada da empresa é feito através de uma ponte levadiça eletrônica (firewall), como mostra a Figura 8.25. Não existe outra rota. O firewall atua como um filtro de pacotes. Ele ins- peciona todo e qualquer pacote que entra e que sai. Os pacotes que atenderem a algum critério descrito nas regras formuladas pelo administrador da rede serão remetidos normalmente, mas os que falharem no teste serão descar- tados sem cerimônia. O critério de filtragem normalmente é dado como regras ou em tabelas que listam as origens e os destinos aceitáveis, as origens ou destinos bloqueados e as regras- -padrão que orientam o que deve ser feito com os pacotes recebidos de outras máquinas ou destinados a elas. No caso comum de uma configuração TCP/IP, uma origem ou des- tino consiste em uma porta e um endereço IP. As portas indicam qual é o serviço desejado. Por exemplo, a porta 25 do TCP é para correio eletrônico, a porta 80 é para HTTP. Algumas portas podem simplesmente ser bloqueadas. Por exemplo, uma empresa poderia bloquear os pacotes rece- bidos em relação a todos os endereços IP combinados com a porta 79 do TCP. Antigamente, era comum usar o serviço Rede interna Zona desmilitarizada Externo Internet Servidor de e-mail Servidor Web Perímetro de segurança Firewall Figura 8.25 z Um firewall protegendo uma rede interna. 08_tanen0809_cap08 BR.indd 513 4/25/11 3:08 PM
- 36. 514 Redes decomputadores Finger para procurar os endereços de e-mail das pessoas, mas quase não é mais usado atualmente. Outras portas não são bloqueadas com tanta facilidade. A dificuldade é que os administradores da rede desejam se- gurança, mas não podem cortar a comunicação com o mun- do exterior. Esse esquema seria muito mais simples e melhor para a segurança, mas haveria infinitas reclamações por parte dos usuários. É para isso que existem esquemas como a zona desmilitarizada, ou DMZ (DeMilitarized Zone), mostrada na Figura 8.25. A DMZ é a parte da rede da empresa que se encontra fora do perímetro de segurança. Tudo passa por ali. Colocando uma máquina como um servidor Web na DMZ, os computadores na Internet podem fazer contato com ela para navegar pelo site Web da empresa. Agora, o firewall pode ser configurado para impedir o tráfego TCP que en- tra na porta 80, para que os computadores na Internet não possam usar essa porta para atacar os computadores na rede interna. Para permitir que o servidor seja administrado, o firewall pode ter uma regra para assegurar conexões entre as máquinas internas e o servidor Web. Os firewalls se tornaram muito mais sofisticados com o tempo, em uma corrida contra os invasores. Originalmente, os firewalls aplicavam um conjunto de regras independentes para cada pacote, mas se tornou difícil escrever regras que permitissem a funcionalidade e impedissem todo o tráfego indesejado. Firewalls em estado de conexão mapeiam os pacotes para conexões e usam campos do cabeçalho TCP/IP para cuidar da conectividade. Isso permite o uso de regras que, por exemplo, possibilitam que um servidor Web exter- no envie pacotes para um host interno, mas somente se o host interno primeiro estabelecer uma conexão com o ser- vidor Web externo. Essa regra não é possível em redes que não mantêm o estado das conexões , que precisam passar ou descartar todos os pacotes vindos do servidor Web externo. Outro nível de sofisticação possível com o processa- mento em estado de conexão é que o firewall implemente gateways em nível de aplicação. Esse processamento envolve o firewall examinando dentro dos pacotes, mes- mo além do cabeçalho TCP, para ver o que a aplicação está fazendo. Com essa capacidade, é possível distinguir entre o tráfego HTTP usado para navegação Web e o tráfego HTTP usado para compartilhamento de arquivos peer-to-peer. Os administradores podem escrever regras para livrar a em- presa do compartilhamento de arquivos peer-to-peer, mas permitir a navegação Web, que é vital para os negócios. Para todos esses métodos, o tráfego de saída pode ser ins- pecionado assim como o tráfego de entrada, por exemplo, para impedir que documentos confidenciais sejam remeti- dos para fora da empresa por correio eletrônico. Como a discussão anterior deve deixar claro, os fi- rewalls violam a disposição de camadas do padrão de pro- tocolos. Eles são dispositivos da camada de rede, mas, para realizar sua filtragem, examinam as camadas de transporte e aplicação. Isso os torna frágeis. Por exemplo, os firewalls costumam contar com as convenções-padrão de numera- ção de porta para determinar o tipo de tráfego transportado em um pacote. As portas-padrão normalmente são usadas, mas não por todos os computadores nem por todas as apli- cações. Algumas aplicações peer-to-peer selecionam portas dinamicamente, para evitar que sejam facilmente locali- zadas (e bloqueadas). A codificação com IPsec ou outros esquemas esconde do firewall as informações da camada mais alta. Finalmente, um firewall não pode falar pron- tamente com os computadores que se comunicam através dele para informar quais diretrizes estão sendo aplicadas e por que sua conexão está sendo descartada. Ele deve sim- plesmente fingir ser um fio partido. Por todas essas razões, os que se preocupam com a pureza das redes consideram os firewalls uma mancha na arquitetura da Internet. Po- rém, a Internet pode ser um local perigoso se você é um computador. Os firewalls ajudam nesse aspecto, e por isso provavelmente permanecerão. Mesmo que o firewall esteja perfeitamente configurado, ainda existem vários problemas de segurança. Por exemplo, se um firewall estiver configurado para permitir apenas a entrada de pacotes de redes específicas (por exemplo, ou- tras instalações da empresa), um intruso fora do firewall pode inserir falsos endereços de origem para ultrapassar essa verificação. Se um usuário interno quiser transportar documentos secretos para fora da empresa, ele poderá codi- ficar ou até mesmo fotografar os documentos e transportar as fotografias como arquivos JPEG, que conseguirão passar por quaisquer filtros de correio. Não discutimos nem mes- mo o fato de que, embora três quartos de todos os ataques venham de fora do firewall, os ataques que vêm de dentro do firewall (por exemplo, de funcionários insatisfeitos) nor- malmente são os mais perigosos (Verizon, 2009). Um problema diferente com os firewalls é que eles oferecem um único perímetro de defesa. Se essa defesa for rompida, tudo estará perdido. Por esse motivo, costumam ser usados em uma defesa em camadas. Por exemplo, um firewall pode proteger a entrada para a rede interna e cada computador também pode ter seu próprio firewall. Os leito- res que acharem que um ponto de verificação de segurança é suficiente certamente nenhum voo internacional em uma companhia aérea regular recentemente. Além disso, há toda uma classe de diferentes ataques com que os firewalls não podem lidar. A ideia básica por trás de um firewall é impedir a entrada de intrusos e a saída de dados secretos. Infelizmente, existem pessoas que não têm nada melhor para fazer do que tentar derrubar certos sites. Para isso, elas enviam ao destino pacotes legítimos em gran- de quantidade, até o site entrar em colapso com a carga. Por exemplo, para incapacitar um site Web, um intruso pode en- viar um pacote SYN do TCP para estabelecer uma conexão. Então, o site alocará um slot da tabela para a conexão e en- viará um pacote SYN + ACK como resposta. Se o intruso não responder, o slot da tabela ficará retido por alguns segundos até um tempo-limite. Se o intruso enviar milhares de solici- tações de conexão, todos os slots da tabela serão preenchidos 08_tanen0809_cap08 BR.indd 514 4/25/11 3:08 PM
- 37. Capítulo 8 Segurança deredes 515 e nenhuma conexão legítima poderá passar. Os ataques em que o objetivo do intruso é desativar o destino em vez de roubar dados são chamados ataques de negação de serviço, ou DoS (Denial of Service). Em geral, os pacotes solicita- dos têm endereços de origem falsos, para que o intruso não possa ser rastreado com facilidade. Os ataques de DoS contra sites importantes são comuns na Internet. Uma variante ainda pior é aquela em que o intruso já entrou em centenas de computadores em outros lugares do mundo, e depois comanda todos esses computadores em um ataque ao mesmo alvo ao mesmo tempo. Essa estraté- gia não apenas aumenta o poder de fogo do intruso, mas também reduz a chance de detecção, pois os pacotes estão vindo de um grande número de máquinas pertencentes a usuários insuspeitos. Um ataque desse tipo é chamado DDoS (Distributed Denial of Service), e é muito difícil proteger-se contra ele. Ainda que a máquina atacada possa reconhecer rapidamente uma solicitação falsa, processar e descartar a solicitação é uma operação que leva algum tem- po e, se chegarem solicitações em número suficiente por segundo, a CPU passará todo seu tempo lidando com elas. 8.6.3 Redes privadas virtuais Muitas empresas têm escritórios e fábricas espalha- dos por muitas cidades, às vezes por vários países. Anti- gamente, antes das redes públicas de dados, era comum tais empresas arrendarem linhas dedicadas da companhia telefônica entre alguns pares de locais ou entre todos eles. Algumas empresas ainda fazem isso. Uma rede construída a partir de computadores de empresas e de linhas telefônicas dedicadas é chamada rede privada. As redes privadas funcionam muito bem e são bastan- te seguras. Se as únicas linhas disponíveis forem as linhas dedicadas, nenhum tráfego poderá vazar para fora das ins- talações da empresa, e os intrusos terão de grampear fisica- mente as linhas para entrar, o que não é fácil. O problema das redes privadas é que arrendar uma única linha T1 custa milhares de dólares por mês, e as linhas T3 têm um custo muito elevado. Quando surgiram as redes públicas de dados e mais tarde a Internet, muitas empresas optaram por mover seu tráfego de dados (e possivelmente o de voz) para a rede pública, mas sem desistir da segurança da rede privada. Essa demanda logo levou à criação de redes privadas virtuais, ou VPNs (Virtual Private Networks), que são redes sobrepostas às redes públicas, mas com a maioria das propriedades das redes privadas. Elas são chamadas ‘virtuais’ porque são meramente uma ilusão, da mesma forma que os circuitos virtuais não são circuitos reais e que a memória virtual não é uma memória real. Uma técnica popular é construir as VPNs diretamente sobre a Internet. Um projeto comum é equipar cada escritó- rio com um firewall e criar túneis pela Internet entre todos os pares de escritórios, como ilustra a Figura 8.26(a). Ou- tra vantagem do uso da Internet para a conectividade é que os túneis podem ser criados por demanda para incluir, por exemplo, o computador de um funcionário que está em casa ou viajando, desde que a pessoa tenha uma conexão com a Internet. Essa flexibilidade é muito maior do que aquela oferecida com linhas dedicadas, embora, do ponto de vista dos computadores na VPN, a topologia seja exatamente a mesma que no caso da rede privada, como mostra a Figura 8.26(b). Quando o sistema é criado, cada par de firewalls tem de negociar os parâmetros de sua SA, incluindo os ser- viços, os modos, os algoritmos e as chaves. Se o IPsec for usado no tunelamento, será possível agregar todo o tráfego entre dois pares de escritórios quaisquer em uma única SA autenticada e criptografada, fornecendo assim controle de integridade, sigilo e até mesmo uma considerável imunidade à analise de tráfego. Muitos firewalls têm recursos internos para VPN. Alguns roteadores comuns podem fazer isso mui- to bem, porém, como os firewalls se destinam principalmen- te a questões de segurança, é natural fazer os túneis começar e terminar nos firewalls, proporcionando uma separação clara entre a empresa e a Internet. Desse modo, firewalls, VPNs e IPsec com ESP em modo túnel formam uma combi- nação natural e muito utilizada na prática. Depois que as SAs são estabelecidas, o tráfego pode começar a fluir. Para um roteador na Internet, um pacote que viaja por um túnel VPN é apenas um pacote comum. O único detalhe incomum com ele é a presença do cabe- Figura 8.26 z (a) Uma rede privada virtual. (b) Topologia vista de dentro. Residência Internet Escritório em Paris Escritório em Londres Viagem Residência Viagem Londres Paris (a) (b) 08_tanen0809_cap08 BR.indd 515 4/25/11 3:08 PM
- 38. 516 Redes decomputadores çalho IPsec depois do cabeçalho IP; porém, como esses ca- beçalhos extras não têm nenhum efeito sobre o processo de encaminhamento, os roteadores não se preocupam com esse cabeçalho extra. Outra técnica que está ganhando popularidade é fazer com que o ISP crie a VPN. Usando MPLS (conforme discu- timos no Capítulo 5), os caminhos para o tráfego da VPN podem ser criados pela rede do ISP entre os escritórios da empresa. Esses caminhos mantêm o tráfego da VPN sepa- rado do restante do tráfego da Internet e podem receber al- guma quantidade de largura de banda garantida, ou então outro tipo de qualidade de serviço. Uma vantagem importante dessa forma de organizar uma VPN é sua completa transparência para todo o software do usuário. Os firewalls configuram e gerenciam as SAs. A única pessoa consciente dessa configuração é o administrador do sistema, que tem de configurar e administrar os gateways de segurança, ou o administrador do ISP, que tem de configu- rar os caminhos MPLS. Para todas as outras pessoas, é como ter de novo uma rede privada de linha dedicada. Para obter mais informações sobre VPNs, consulte Lewis (2006). 8.6.4 Segurança em redes sem fios É fácil projetar um sistema com total segurança em ter- mos lógicos usando VPNs e firewalls, muito embora na prá- tica ele vaze como uma peneira. Essa situação pode ocorrer se algumas das máquinas forem sem fios e usarem comuni- cação por rádio, que passa pelo firewall em ambos os senti- dos (entrada e saída). O alcance das redes 802.11 frequen- temente é de algumas centenas de metros; assim, qualquer pessoa que queira espionar uma empresa pode se dirigir até o estacionamento dos funcionários pela manhã, deixar um notebook capaz de reconhecer sinais 802.11 dentro do carro para registrar tudo o que ouvir e se retirar no final do dia. À tarde, o disco rígido estará repleto de valiosas informações. Teoricamente, esse vazamento não deveria acontecer. Na teoria, as pessoas também não deveriam roubar bancos. Grande parte do problema de segurança pode ter sua origem nos fabricantes de estações-base sem fios (pontos de acesso) que tentam tornar seus produtos amigáveis para o usuário. Em geral, se o usuário retirar o dispositivo da caixa e o conectar à tomada da rede elétrica, ele começará a operar de imediato — quase sempre sem nenhuma se- gurança, revelando segredos para todo mundo que estiver dentro do alcance de rádio. Se ele for conectado a uma rede Ethernet, todo tráfego da Ethernet também aparecerá de repente no estacionamento. A rede sem fios é um sonho que se tornou realidade para o espião: dados gratuitos sem nenhum trabalho. Por isso, não é preciso dizer que a segu- rança é ainda mais importante para sistemas sem fios que para sistemas fisicamente conectados. Nesta seção, exami- naremos alguns aspectos de segurança das redes sem fios. Algumas informações adicionais podem ser encontradas em Nichols e Lekkas (2002). Segurança de redes 802.11 Parte do padrão 802.11, originalmente chamado 802.11i, prescreve um protocolo de segurança do nível de enlace de dados para impedir que um nó sem fios leia ou interfira nas mensagens enviadas entre outro par de nós sem fios. Ele também é chamado de WPA2 (WiFi Protec- ted Access 2). O WPA puro é um esquema intermediário que implementa um subconjunto do 802.11i. Ele deve ser evitado em favor do WPA2. Vamos descrever o 802.11i em breve, mas primeiro indicaremos que ele é um substituto para o WEP (Wired Equivalent Privacy), a primeira geração de protocolos de segurança 802.11. O WEP foi criado por um comitê de pa- drões de rede, que é um processo completamente diferente, por exemplo, do modo como o NIST selecionou o projeto do AES. Os resultados foram devastadores. O que saiu errado com ele? Quase tudo, do ponto de vista da segurança. Por exemplo, WEP codificava dados por confidencialidade rea- lizando um XOR com a saída de um fluxo de cifras. Infeliz- mente, arrumações de chave fracas fizeram com que a saída geralmente fosse reutilizada. Isso ocasionou formas triviais de ataque. Como outro exemplo, a verificação de integridade era baseada em um CRC de 32 bits. Esse é um código eficien- te para detectar erros de transmissão, mas não é um meca- nismo criptograficamente forte para combater os invasores. Essas e outras falhas de projeto tornaram o WEP muito fácil de ser comprometido. A primeira demonstração práti- ca de que o WEP tinha falhas veio quando Adam Stubble- field era um estagiário na ATT (Stubblefield et al., 2002). Ele conseguiu codificar e testar um ataque esboçado por Fluhrer et al. (2001) em uma semana, em que a maior par- te do tempo foi gasta convencendo a gerência para que lhe comprasse uma placa WiFi para usar em seus experimen- tos. O software para quebrar senhas WEP em um minuto agora está livremente disponível e o uso de WEP é bas- tante desencorajado. Embora ele impeça o acesso casual, não oferece nenhuma forma de segurança real. O grupo 802.11i foi reunido às pressas quando ficou claro que o WEP estava seriamente em perigo. Esse grupo produziu um padrão formal em junho de 2004. Agora, vamos descrever o 802.11i, que oferece segu- rança real se for montado e usado devidamente. Existem dois cenários comuns em que o WPA2 é usado. O primeiro é um ambiente corporativo, em que uma empresa tem um servidor de autenticação separado, com um banco de dados de nomes de usuários e senhas, que pode ser usado para determinar se um cliente sem fios tem permissão para aces- sar a rede. Nesse ambiente, os clientes usam protocolos-pa- drão para ser autenticados na rede. Os principais padrões são o 802.1X, com o qual o ponto de acesso permite que o cliente trave um diálogo com o servidor de autenticação e observe o resultado, e o EAP (Extensible Authentica- tion Protocol) (RFC 3748), que informa como o cliente e o servidor de autenticação devem interagir. Na realidade, 08_tanen0809_cap08 BR.indd 516 4/25/11 3:08 PM
- 39. Capítulo 8 Segurança deredes 517 EAP é um framework e outros padrões definem as men- sagens do protocolo. Porém, não vamos entrar em muitos detalhes dessa troca, pois eles não são muito importantes para uma visão geral do assunto. O segundo cenário está em um ambiente domésti- co, em que não existe um servidor de autenticação. Em vez disso, há uma senha única compartilhada, usada pe- los clientes para acessar a rede sem fios. Esse ambiente é menos complexo do que aquele com um servidor de au- tenticação, motivo pelo qual é usado em casa e em peque- nas empresas, porém também é menos seguro. A principal diferença é que, com um servidor de autenticação, cada cliente recebe uma chave para codificar o tráfego, que não é conhecida pelos outros clientes. Com uma única senha compartilhada, diferentes chaves são derivadas para cada cliente, mas todos têm a mesma senha e podem derivar as chaves uns dos outros, se quiserem. As chaves usadas para codificar o tráfego são calculadas como parte de um handshake de autenticação. O handshake ocorre logo depois que o cliente se associa a uma rede sem fios e se autentica com um servidor de autenticação, se houver. No início do handshake, o cliente tem a senha de rede compartilhada ou sua senha para o servidor de auten- ticação. Essa senha é usada para derivar uma chave mestra. Porém, a chave mestra não é usada diretamente para co- dificar pacotes. É uma prática criptográfica padrão derivar uma chave de sessão para cada período de uso, mudar a chave para diferentes sessões e expor a chave mestra à ob- servação o mínimo possível. É essa chave de sessão que é calculada no handshake. A chave de sessão é calculada com o handshake de quatro pacotes mostrado na Figura 8.27. Primeiro, o ponto de acesso, ou AP (Access Point), envia um núme- ro qualquer para identificação. Nos protocolos de segu- rança como esse, os números aleatórios, usados apenas uma vez, são chamados nonces, que é uma contração de ‘number used once’ (número usado uma vez). O cliente também escolhe seu próprio nonce. Ele usa os nonces, seu endereço MAC e o do AP, e a chave mestra para calcular uma chave de sessão, KS . A chave de sessão é dividida em partes, usadas para diferentes finalidades, mas omitiremos esse detalhe. Agora, o cliente tem cha- ves de sessão, mas o AP não tem. Assim, o cliente envia seu nonce ao AP, e este realiza o mesmo cálculo para derivar as mesmas chaves de sessão. Os nonces podem ser enviados abertamente, pois as chaves não podem ser derivadas a partir deles sem informações extras, secretas. A mensagem do cliente é protegida com uma verificação de integridade chamada verificação de integridade da mensagem, ou MIC (Message Integrity Check), com base na chave da sessão. O AP pode verificar se a MIC está correta, e portanto se a mensagem realmente veio do cliente, depois de calcular as chaves de sessão. Uma MIC é apenas outro nome para um código de autentica- ção de mensagem, como em um HMAC. Em seu lugar, o termo MIC é frequentemente utilizado para protocolos de rede, devido ao potencial de confusão com endereços MAC (Medium Access Control). Nas duas últimas mensagens, o AP distribui uma cha- ve de grupo, KG , ao cliente, e este confirma a mensagem. O recebimento dessas mensagens permite que o cliente verifique se o AP tem as chaves de sessão corretas e vice- -versa. A chave de grupo é usada para tráfego de broadcast e multicast na LAN 802.11. Tendo em vista que o resul- tado do handshake é que cada cliente tem suas próprias chaves de codificação, nenhuma delas pode ser usada pelo AP para transmitir pacotes por broadcast a todos os clien- tes sem fios; uma cópia separada teria de ser enviada a cada cliente usando sua chave. Em vez disso, uma chave compartilhada é distribuída para que o tráfego de broad- cast possa ser enviado apenas uma vez e recebido por to- dos os clientes. Ela precisa ser atualizada à medida que os clientes entram e saem da rede. Figura 8.27 z O handshake de definição de chave no 802.11i. Cliente NonceAP NonceC, MICS KS (KG), MICS 2 4 1 3 Ponto de acesso (AP) Calcula chaves de sessão KS a partir dos endereços MAC, nonces e chave mestra Distribui chave do grupo, KG Verifica se o cliente tem KS Verifica se AP tem KS Confirmação Calcula chaves de sessão KS, da mesma forma que o cliente KS (ACK), MICS 08_tanen0809_cap08 BR.indd 517 4/25/11 3:08 PM
- 40. 518 Redes decomputadores Por fim, chegamos à parte em que as chaves são real- mente usadas para fornecer segurança. Dois protocolos po- dem ser usados no 802.11i para fornecer confidencialida- de, integridade e autenticação da mensagem. Assim como WPA, um dos protocolos, chamado TKIP (Temporary Key Integrity Protocol), foi uma solução temporária. Ele foi criado para melhorar a segurança em placas 802.11 an- tigas e lentas, de modo que pelo menos alguma segurança melhor que o WEP pudesse ser implementada como um upgrade no firmware. Contudo, ele também foi quebrado, e por isso é melhor ficar com o outro protocolo recomenda- do, o CCMP. O que significa CCMP? Essa é uma abreviação para o nome espetacular ‘Counter mode with Cipher block chaining Message authentication code Protocol’ (protocolo de código de autenticação de mensagem de modo contador com encadeamento de blocos de cifras). Vamos chamá-lo simplesmente de CCMP. Você pode chamá-lo como quiser. O CCMP funciona de uma maneira relativamente simples. Ele usa a codificação AES com uma chave e um tamanho de bloco de 128 bits. A chave vem da chave de sessão. Para fornecer confidencialidade, as mensagens são codificadas com AES no modo contador. Lembre-se de que discutimos sobre os modos de cifras na Seção 8.2.3. Esses modos são o que impede que a mesma mensagem seja co- dificada para o mesmo conjunto de bits todas as vezes. O modo contador insere um contador junto com a codificação. Para oferecer integridade, a mensagem, incluindo os campos de cabeçalho, é codificada com o modo de encadeamento de blocos de cifras e o último bloco de 128 bits é mantido como o MIC. Em seguida, tanto a mensagem (codificada com o modo contador) como o MIC são enviados. O cliente e o AP podem realizar essa codificação individualmente, ou en- tão verificar essa codificação quando um pacote for recebido pela rede sem fios. Para o broadcast ou multicast de mensa- gens, o mesmo procedimento é usado com a chave de grupo. Segurança do Bluetooth O Bluetooth tem um alcance bem mais curto que o 802.11, portanto não pode ser atacado do estacionamento, embora a segurança ainda seja uma questão importante nesse caso. Por exemplo, imagine que o computador de Alice esteja equipado com um teclado Bluetooth sem fio. Na ausência de segurança, se Trudy estiver no escritório ao lado, ela poderá ler tudo o que Alice digitou, inclusive todo e-mail enviado. Ela também poderá captar tudo que o computador de Alice enviar à impressora Bluetooth mais próxima (por exemplo, as men- sagens de correio eletrônico recebidas e os relatórios confiden- ciais). Felizmente, o Bluetooth tem um esquema de segurança elaborado para tentar anular as Trudies desse mundo. Agora vamos resumir as principais características desse esquema. A partir da versão 2.1, o Bluetooth tem quatro modos de segurança, variando desde nenhuma segurança até total criptografia de dados e controle de integridade. Como ocor- re com o 802.11, se a segurança for desativada (o padrão para dispositivos mais antigos), não haverá nenhuma segu- rança. A maioria dos usuários mantém a segurança desati- vada até ocorrer uma séria violação; depois eles a ativam. No mundo agrícola, essa abordagem é conhecida como trancar a porteira depois que o cavalo escapou. O Bluetooth fornece segurança em várias camadas. Na camada física, os saltos de frequência oferecem um nível mí- nimo de segurança, mas, como qualquer dispositivo Blue- tooth que se desloca em uma piconet tem de ser informado da sequência de saltos de frequência, é óbvio que essa frequ- ência não é um segredo. A segurança real começa quando o escravo recém-chegado solicita um canal ao mestre. Antes do Bluetooth 2.1, havia o pressuposto de que os dois dis- positivos compartilhavam uma chave secreta configurada com antecedência. Em alguns casos, ambos são fisicamente conectados pelo fabricante (por exemplo, um fone de ou- vido e um telefone celular vendidos como uma unidade). Em outros, um dispositivo (como o fone de ouvido) tem uma chave embutida no código e o usuário tem de digitar essa chave no outro dispositivo (o telefone celular) como um número decimal. Essas chaves compartilhadas são cha- madas passkeys (ou chaves de passagem). Infelizmente, as passkeys costumam vir definidas como ‘1234’ ou outro valor previsível, e de qualquer forma são quatro dígitos decimais, permitindo apenas 104 escolhas. Com o emparelhamento se- guro simples do Bluetooth 2.1, os dispositivos escolhem um código a partir de uma faixa de seis dígitos, tornando a pas- skey muito menos previsível, mas ainda longe de ser segura. Para estabelecer um canal, o escravo e o mestre verifi- cam se a outra máquina conhece a passkey. Nesse caso, eles negociam para ver se esse canal será criptografado, terá sua integridade controlada ou ambos. Em seguida, selecionam umachavedesessãoaleatóriade128bits,naqualalgunsbits podem ser públicos. A razão para permitir o enfraquecimen- to dessa chave é obedecer a algumas restrições do governo de vários países, criadas para impedir a exportação ou o uso de chaves mais longas do que aquelas que o governo é capaz de violar. A criptografia utiliza um fluxo de cifras chamado E0 ; o controle de integridade emprega o SAFER+. Ambos são blocos de cifras de chave simétrica tradicional. O SAFER+ foi submetido aos rígidos testes de aprovação do AES, mas foi eliminado na primeira rodada, por ser mais lento que os outros candidatos. O Bluetooth ficou pronto antes de ser escolhida a cifra do AES; caso contrário, é mais provável que ele tivesse usado o Rijndael. A criptografia real usando um fluxo de cifras é mostra- da na Figura 8.12, com o texto simples sendo submetido a um XOR com o fluxo de chaves para gerar o texto cifrado. Infelizmente, o próprio E0 (como o RC4) pode ter defici- ências fatais (Jakobsson e Wetzel, 2001). Embora ele não tenha sido rompido na época em que escrevemos, sua se- melhança com a cifra A5/1, cuja falha espetacular compro- mete todo o tráfego de telefones GSM, causa preocupação (Biryukov et al., 2000). Às vezes, é espantoso perceber (até mesmo para os autores deste livro) que, no eterno jogo de 08_tanen0809_cap08 BR.indd 518 4/25/11 3:08 PM
- 41. Capítulo 8 Segurança deredes 519 gato e rato entre criptógrafos e criptoanalistas, os criptoa- nalistas frequentemente sejam os vencedores. Outra questão de segurança é que o Bluetooth autentica apenas dispositivos, não usuários; assim, o furto de um dis- positivo Bluetooth pode dar ao ladrão acesso às finanças e às outras contas do usuário. No entanto, o Bluetooth também implementa segurança nas camadas superiores. Portanto, até mesmo na eventualidade de uma violação da segurança no nível de enlace, deve restar alguma segurança, especial- mente para aplicações que exigem a digitação de um código PIN em algum tipo de teclado para completar a transação. 8.7 Protocolos de autenticação A autenticação é a técnica pela qual um processo confirma que seu parceiro na comunicação é quem deve ser e não um impostor. Confirmar a identidade de um pro- cesso remoto, diante da presença de um intruso ativo mal- -intencionado, é surpreendentemente difícil e exige pro- tocolos complexos baseados em criptografia. Nesta seção, estudaremos alguns dos protocolos de autenticação usados em redes de computadores com falhas na segurança. A propósito, algumas pessoas confundem autorização com autenticação. A autenticação visa a determinar se você está ou não se comunicando com um processo específico. A autorização se preocupa com o que esse processo tem per- missão para fazer. Por exemplo, um processo cliente entra em contato com um servidor de arquivos e afirma: ‘Sou o processo do Scott e quero excluir o arquivo receitas.old’. Do ponto de vista do servidor de arquivos, as seguintes per- guntas devem ser respondidas: 1. Esse processo é realmente de Scott (autenticação)? 2. Scott tem permissão para excluir receitas.old (autori- zação)? Somente depois que ambas as perguntas forem res- pondidas afirmativamente, sem nenhuma ambiguidade, a ação solicitada poderá ser executada. Na verdade, a primei- ra é a mais importante. Depois que o servidor de arquivos souber com quem está se comunicando, verificar a autori- zação é uma simples questão de pesquisar entradas de ta- belas ou bancos de dados locais. Por isso, nesta seção vamos nos concentrar na autenticação. O modelo genérico que todos os protocolos de auten- ticação utilizam é descrito a seguir. Alice começa enviando uma mensagem para Bob ou para um KDC (Key Distri- bution Center) no qual confia e que sempre é honesto. Acontecem muitas outras trocas de mensagens em diferen- tes sentidos. À medida que elas são enviadas, uma intrusa mal-intencionada, Trudy, pode interceptar, modificar ou reproduzir essas mensagens a fim de enganar Alice e Bob, ou apenas para atrapalhar. Todavia, quando a execução do protocolo tiver sido con- cluída, Alice terá certeza de que está se comunicando com Bob e vice-versa. Além disso, na maioria dos protocolos, os dois também terão estabelecido uma chave de sessão se- creta que deverá ser usada durante a conversação. Na prá- tica, por motivos de desempenho, todo o tráfego de dados é criptografado utilizando-se o modo de chave simétrica (em geral, AES ou DES triplo) — embora a criptografia de chave pública seja muito utilizada nos próprios protocolos de au- tenticação e para estabelecer a chave de sessão. O objetivo de utilizar uma nova chave de sessão, esco- lhida ao acaso para cada nova conexão, é minimizar o vo- lume de tráfego provocado pelo envio das chaves secretas ou públicas dos usuários, reduzir o volume de texto cifra- do que um intruso pode obter e minimizar os danos, caso haja uma pane em um processo e seu dump de memória caia em mãos erradas. É muito provável que a única chave presente seja a de sessão. Todas as chaves permanentes de- verão ser cuidadosamente zeradas depois que a sessão for estabelecida. 8.7.1 Autenticação baseada em chave secreta compartilhada Para nosso primeiro protocolo de autenticação, vamos supor que Alice e Bob já compartilham uma chave secreta, KAB . Essa chave compartilhada pode ter sido definida pe- los dois em uma conversa telefônica ou pessoalmente, mas não na rede (que não é segura). Ele se baseia em um princípio encontrado em muitos protocolos de autenticação: um dos lados envia um nú- mero aleatório ao outro, que em seguida o transforma de algum modo especial e retorna o resultado. Tais protoco- los são chamados protocolos de desafio-resposta. Nesse e nos próximos protocolos de autenticação, será usada a seguinte notação: A e B são as identidades de Alice e Bob. Ri ’s são desafios, e i identifica o desafiante Ki ’s são chaves, onde i indica o proprietário KS é a chave da sessão A sequência de mensagens de nosso primeiro protoco- lo de autenticação de chave compartilhada é mostrada na Figura 8.28. Na mensagem 1, Alice envia sua identidade A para Bob, de uma forma que Bob entenda. É claro que Bob não tem como saber se essa mensagem veio de Alice ou de Trudy; portanto, ele escolhe um desafio, um número aleató- rio muito extenso, RB , e o envia de volta a ‘Alice’ como sua mensagem número 2 em texto simples. Em seguida, Alice criptografa a mensagem com a chave que compartilha com Bob e envia o texto cifrado, KAB (RB ), de volta na mensagem 3. Quando vê a mensagem, Bob sabe de imediato que ela veio de Alice, pois Trudy não conhece KAB e, portanto, não poderia tê-la gerado. Além disso, como o número RB foi es- colhido ao acaso a partir de um espaço muito extenso (di- gamos, números aleatórios de 128 bits), é muito imprová- vel que Trudy tenha visto RB e sua resposta em uma sessão anterior. É também improvável que ela consiga adivinhar a resposta correta a qualquer desafio. 08_tanen0809_cap08 BR.indd 519 4/25/11 3:08 PM
- 42. 520 Redes decomputadores A essa altura, Bob tem certeza de que está se comuni- cando com Alice, mas Alice não tem certeza de nada, pois sabe que Trudy pode ter interceptado a mensagem 1 e en- viado RB como resposta. Talvez Bob tenha morrido na noite passada. Para descobrir com quem está se comunicando, Alice seleciona um número aleatório, RA , e o envia a Bob como texto simples, na mensagem 4. Quando Bob respon- de com KAB (RA ), Alice se certifica de que está se comuni- cando com Bob. Se eles quiserem estabelecer uma chave de sessão agora, Alice poderá selecionar uma, KS , e enviá-la a Bob criptografada com KAB . O protocolo da Figura 8.28 contém cinco mensagens. Vamos ver se podemos eliminar algumas delas. Uma abor- dagem é ilustrada na Figura 8.29. Nessa figura, Alice inicia o protocolo de desafio-resposta em vez de esperar que Bob o faça. Da mesma forma, enquanto responde ao desafio de Alice, Bob envia o dele: o protocolo inteiro pode ser redu- zido a três mensagens, em vez de cinco. Esse novo protocolo representa um aperfeiçoamento em relação ao original? Em certo sentido, isso é verdade, pois agora o protocolo está mais curto. Infelizmente, tam- bém está errado. Sob determinadas circunstâncias, Trudy é capaz de enganar esse protocolo utilizando o método co- nhecido como ataque por reflexão. Isso quer dizer que Trudy poderá rompê-lo se for possível abrir várias sessões com Bob ao mesmo tempo. Por exemplo, essa situação se- ria verdadeira se Bob fosse um banco e estivesse preparado para aceitar muitas conexões simultâneas enviadas por cai- xas eletrônicos ao mesmo tempo. O ataque por reflexão de Trudy é mostrado na Figura 8.30. Ele começa com Trudy afirmando ser Alice e envian- do RT . Bob responde, como sempre, com seu próprio desa- fio, RB . Agora Trudy está em apuros. O que ela pode fazer? Ela não conhece KAB (RB ). Ela pode abrir outra sessão com a mensagem 3, forne- cendo o RB extraído da mensagem 2 como seu desafio. Bob o criptografa calmamente e envia KAB (RB ) na mensagem 4. Representamos com sombreados as mensagens da segun- da sessão, a fim de destacá-las. Agora, Trudy tem as infor- mações que faltavam e, portanto, pode concluir a primeira sessão e abandonar a segunda. Nesse momento, Bob está convencido de que Trudy é Alice e, quando ela pede o saldo da conta, ele o informa sem mais perguntas. Em seguida, quando Trudy pede a Bob que transfira todo o dinheiro para uma conta secreta na Suíça, ele não hesita em fazê-lo. A moral da história é a seguinte: Projetar um protocolo de autenticação correto é mais difícil do que parece. As quatro regras gerais a seguir frequentemente aju- dam o projetista a evitar as armadilhas mais comuns: 1. fazer que o transmissor prove quem é antes de o receptor responder. Nesse caso, Bob revela informa- ções valiosas antes de Trudy fornecer alguma prova de quem é ela; 2. fazer que o transmissor e o receptor utilizem cha- ves específicas para provar quem são, mesmo que isso signifique ter duas chaves compartilhadas, KAB e K’AB ; 3. fazer que o transmissor e o receptor extraiam seus desafios de conjuntos distintos. Por exemplo, o transmissor deve usar números pares e o receptor deve usar números ímpares. 4. Tornar o protocolo resistente a ataques que en- volvam uma segunda sessão paralela, nos quais as informações obtidas em uma sessão são usadas em uma sessão diferente. A Alice RB 1 2 4 5 3 KAB (RB) KAB (RA) Bob RA Figura 8.28 z Uma autenticação bidirecional utilizando um protocolo de desafio-resposta. Alice 1 3 2 RB, KAB (RA) KAB (RB) A, RA Bob Figura 8.29 z Um protocolo de autenticação bidirecional reduzido. Trudy 1 5 2 RB, KAB (RT) KAB (RB) A, RT 3 4 RB2, KAB (RB) A, RB Primeira sessão Segunda sessão Primeira sessão Bob Figura 8.30 z O ataque por reflexão. 08_tanen0809_cap08 BR.indd 520 4/25/11 3:08 PM
- 43. Capítulo 8 Segurança deredes 521 Se apenas uma dessas regras for violada, isso signi- fica que o protocolo poderá ser violado com frequência. Nesse caso, todas as quatro regras foram violadas, com consequências desastrosas. Agora, vamos examinar mais de perto a Figura 8.28. É possível garantir que esse protocolo não esteja sujeito a um ataque por reflexão? Bem, talvez. Essa é uma questão bastante sutil. Trudy foi capaz de violar nosso protocolo usando um ataque por reflexão, porque foi possível abrir uma segunda sessão com Bob e enganá-lo, respondendo a suas próprias perguntas. O que aconteceria se Alice fosse um computador de uso geral que também aceitasse várias sessões, em vez de ser uma pessoa diante de um computa- dor? Vejamos o que Trudy poderia fazer nesse caso. Para ver como funciona o ataque de Trudy, observe a Figura 8.31. Alice começa anunciando sua identidade na mensagem 1. Trudy intercepta essa mensagem e inicia sua própria sessão com a mensagem 2, afirmando ser Bob. No- vamente sombreamos as mensagens da sessão 2. Alice res- ponde a mensagem 2 com a mensagem 3, dizendo: ‘Você afirma ser Bob? Então, prove’. Nesse momento Trudy não tem saída, porque não pode provar ser Bob. O que Trudy faz agora? Ela volta para a primeira ses- são, já que é sua vez de enviar um desafio, e transmite a RA que obteve na mensagem 3. Alice gentilmente responde na mensagem 5 e, desse modo, fornece a Trudy as informações de que ela precisa para enviar a mensagem 6 na sessão 2. Nes- se momento, Trudy está à vontade, porque conseguiu res- ponder com sucesso ao desafio de Alice na sessão 2. Agora ela pode cancelar a sessão 1, transmitir qualquer número antigo para o restante da sessão 2, e terá uma sessão auten- ticada com Alice na sessão 2. Contudo, Trudy é malvada e quer causar ainda mais danos. Em vez de enviar qualquer número antigo para concluir a sessão 2, ela espera até Alice enviar a men- sagem 7, o desafio de Alice para a sessão 1. É claro que Trudy não sabe como responder, e portanto utiliza outra vez o ataque por reflexão, devolvendo RA2 como a men- sagem 8. Alice codifica RA2 de maneira conveniente na mensagem 9. Agora, Trudy volta para a sessão 1 e envia a Alice, na mensagem 10, o número que ela deseja, cui- dadosamente copiado do número que a própria Alice en- viou na mensagem 9. Nesse momento, Trudy tem duas sessões completamente autenticadas com Alice. Esse ataque tem um resultado um pouco diferen- te do ataque no protocolo de três mensagens, ilustra- do na Figura 8.30. Dessa vez, Trudy tem duas conexões autenticadas com Alice. No exemplo anterior, ela tinha uma conexão autenticada com Bob. Mais uma vez, se aplicássemos todas as regras gerais de protocolos de au- tenticação discutidas anteriormente, esse ataque poderia ter sido interrompido. Uma descrição detalhada desses tipos de ataques e de como frustrá-los é apresentada em Bird et al. (1993), que também mostram como é possível construir, de forma sistemática, protocolos que compro- vadamente são corretos. Porém, o mais simples desses protocolos é um pouco complicado; portanto, mostrare- mos agora uma classe de protocolo diferente, que tam- bém funciona. O novo protocolo de autenticação é mostrado na Fi- gura 8.32 (Bird et al., 1993). Ele emprega um HMAC do tipo que vimos quando estudamos o IPsec. Alice começa enviando a Bob um nonce RA como mensagem 1. Bob responde selecionando seu próprio nonce, RB , e devol- vendo-o juntamente com um HMAC. O HMAC é forma- do com o objetivo de construir uma estrutura de dados que consiste no nonce de Alice, no nonce de Bob, em suas identidades e na chave secreta compartilhada, KAB . Esses dados estruturados passam então por um hash no HMAC, por exemplo, usando SHA-1. Quando receber a mensagem 2, Alice terá RA (que ela própria escolheu), RB , que chegará sob a forma de texto simples, as duas identidades e a chave secreta KAB , conhecida desde o iní- cio, e depois ela mesma poderá calcular o HMAC. Se este corresponder ao HMAC da mensagem, ela saberá que está se comunicando com Bob, porque Trudy não conhe- ce KAB e, desse modo, não terá como saber qual HMAC enviar. Alice responde a Bob com um HMAC contendo apenas os dois nonces. Trudy pode subverter de algum modo esse protoco- lo? Não, porque ela não é capaz de forçar nenhuma das partes a codificar ou fazer o hash de um valor de sua es- colha, como aconteceu na Figura 8.30 e na Figura 8.31. Ambos os HMACs incluem valores escolhidos pela parte transmissora, algo que Trudy não pode controlar. A Alice B 1 2 4 5 3 KAB (RA) Trudy RA RA 6 KAB (RA) 7 RA2 8 9 KAB (RA2) RA2 10 KAB (RA2) Primeira sessão Primeira sessão Primeira sessão Primeira sessão Segunda sessão Segunda sessão Segunda sessão Figura 8.31 z Um ataque por reflexão no protocolo da Figura 8.28. 08_tanen0809_cap08 BR.indd 521 4/25/11 3:08 PM
- 44. 522 Redes decomputadores Utilizar HMACs não é o único meio de empregar essa ideia. Um esquema alternativo usado com frequência em vez de calcular o HMAC sobre uma série de itens é codificar os itens em sequência utilizando o encadeamento de blocos de cifras. 8.7.2 Como estabelecer chave compartilhada: a troca de chaves de Diffie-Hellman Até agora, partimos do princípio de que Alice e Bob compartilham uma chave secreta. Suponha que isso não seja verdade (porque até agora não há nenhuma PKI uni- versalmente aceita para assinar e distribuir certificados). Como eles podem estabelecer uma chave secreta? Uma possibilidade seria Alice telefonar para Bob e dar sua chave a ele, mas provavelmente ele começaria a conversa dizen- do: ‘Como posso saber que você é Alice e não Trudy?’ Eles poderiam tentar se encontrar pessoalmente, com cada um levando passaporte, carteira de identidade e três cartões de crédito. No entanto, como são muito ocupados, talvez não consigam encontrar uma data conveniente para ambos durante meses. Felizmente, apesar de parecer incrível, há uma forma de pessoas que não se conhecem estabelecerem uma chave secreta em plena luz do dia, mesmo com Trudy registrando cuidadosamente cada mensagem. O protocolo que permite o estabelecimento de uma chave secreta entre pessoas que não se conhecem é cha- mado troca de chaves de Diffie-Hellman (Diffie e Hell- man, 1976) e funciona da forma descrita a seguir. Alice e Bob têm de concordar em relação a dois números grandes, n e g, onde n é um número primo, (n – 1)/2 também é um número primo e onde certas condições se aplicam a g. Esses números podem ser públicos; portanto, um deles só precisa selecionar n e g e informar ao outro abertamente. Agora, Alice escolhe um número grande x (digamos, de 1.024 bits) e o mantém em segredo. Da mesma forma, Bob seleciona um número grande secreto, y. Alice inicia um protocolo de troca de chaves envian- do a Bob uma mensagem contendo (n, g, gx mod n), como mostra a Figura 8.33. Bob responde enviando a Alice uma mensagem contendo gy mod n. Agora, Alice eleva à x-ésima potência em módulo n o número que Bob lhe enviou, a fim de obter (gy mod n)x mod n. Bob executa uma operação semelhante para obter (gx mod n)y mod n. Pelas leis da arit- mética modular, os dois cálculos geram gxy mod n. Eis que, como por mágica, Alice e Bob de repente compartilham uma chave secreta, gxy mod n. É obvio que Trudy viu as duas mensagens. Com base na mensagem 1, ela conhece g e n. Se pudesse calcular x e y, Trudy poderia descobrir a chave secreta. O problema é que, com apenas gx mod n, ela não consegue encontrar x. Não existem algoritmos práticos para o cálculo de logarit- mos discretos cuja base é um número primo muito grande. Para tornar o exemplo mostrado anteriormente mais concreto, utilizaremos os valores (completamente falsos): n = 47 e g = 3. Alice seleciona x = 8 e Bob seleciona y = 10, o que é mantido em segredo. A mensagem de Alice para Bob é (47, 3, 28), pois 38 mod 47 é igual a 28. A mensagem de Bob para Alice é (17). Alice calcula 178 mod 47, que é igual a 4. Bob calcula 2810 mod 47, que é igual a 4. Alice e Bob determinaram de forma independente que agora a chave secreta é 4. Para descobrir a chave, Trudy tem de re- solver a equação 3x mod 47 = 28, o que pode ser feito por pesquisa exaustiva de números pequenos como esse, mas não quando todos os números têm centenas de bits. Todos os algoritmos conhecidos até o momento demoram muito tempo para realizar esse cálculo, mesmo em supercompu- tadores paralelos e supervelozes. Alice 1 3 2 RA Bob RB, HMAC(RA , RB , A, B, KAB) HMAC(RA , RB , KAB) Figura 8.32 z Autenticação usando HMACs. 1 Alice escolhe x Bob escolhe y 2 gy mod n n, g, gx mod n Alice calcula (gy mod n)x = gxy mod n Bob calcula (gx mod n)y = gxy mod n Bob Alice mod n mod n Figura 8.33 z A troca de chaves de Diffie-Hellman. 08_tanen0809_cap08 BR.indd 522 4/25/11 3:08 PM
- 45. Capítulo 8 Segurança deredes 523 Apesar da elegância do algoritmo de Diffie-Hellman, há um problema: quando Bob obtém a tripla (47, 3, 28), como ele pode saber se ela veio de Alice e não de Trudy? Ele não tem mesmo como saber. Infelizmente, Trudy pode explorar esse fato para enganar Alice e Bob, como ilus- tra a Figura 8.34. Aqui, enquanto Alice e Bob escolhem x e y, respectivamente, Trudy escolhe seu próprio número aleatório, z. Alice envia a mensagem 1 para Bob. Trudy a intercepta e envia a mensagem 2 para Bob, usando g e n corretos (que, de qualquer forma, são públicos), mas com seu próprio z em vez de x. Ela também envia a mensagem 3 de volta para Alice. Mais tarde, Bob envia a mensagem 4 para Alice, que Trudy mais uma vez intercepta e guarda. Agora, todos utilizam a aritmética modular. Alice cal- cula a chave secreta como gxz mod n, e Trudy faz o mesmo (para mensagens enviadas a Alice). Bob calcula gyz mod n e Trudy também (nas mensagens enviadas a Bob). Alice pensa que se comunica com Bob e, portanto, estabelece uma chave de sessão (com Trudy). Bob faz o mesmo. Todas as mensagens que Alice envia na sessão criptografada são capturadas, armazenadas e modificadas por Trudy para en- tão (talvez) ser passadas a Bob. Da mesma forma, no outro sentido, Trudy vê tudo e pode modificar todas as mensa- gens como quiser, enquanto Alice e Bob têm a ilusão de que há um canal seguro entre os dois. Por isso, esse ataque é chamado ataque do homem no meio. Ele também é chamado ataque da brigada de incêndio, pois lembra um antigo corpo de bombeiros formado por voluntários que, enfileirados, passavam baldes d’água de mão em mão do caminhão até o incêndio. 8.7.3 Autenticação com o uso de um centro de distribuição de chaves A ideia de compartilhar um segredo com uma pessoa estranha quase funcionou. Por outro lado, talvez não tenha valido a pena a tentativa (ataque da raposa e das uvas). Para conversar com n pessoas dessa forma, você precisa- rá de n chaves. Para pessoas famosas, o gerenciamento de chaves poderia se tornar uma grande dor de cabeça, espe- cialmente se cada chave tivesse de ser guardada em um cartão plástico com chip embutido. Outra estratégia é introduzir um centro de distribui- ção de chaves (KDC — Key Distribution Center) confiável. Nesse modelo, cada usuário tem uma única chave compar- tilhada com o KDC. Agora o gerenciamento de sessão e de autenticação passa pelo KDC. O protocolo de autenticação para o KDC mais simples envolve duas partes e um KDC confiável, e é descrito na Figura 8.35. A ideia por trás desse protocolo é simples: Alice escolhe uma chave de sessão KS e informa ao KDC que deseja se co- municar com Bob usando KS . Essa mensagem é criptogra- fada com a chave secreta que Alice compartilha (apenas) com o KDC, KA . O KDC a descriptografa e extrai a identida- de de Bob e a chave de sessão. Em seguida, cria uma nova mensagem contendo a identidade de Alice e a chave de sessão, depois envia essa mensagem a Bob. A criptografia é feita com KB , a chave secreta que Bob compartilha com o KDC. Quando descriptografa a mensagem, Bob fica saben- do que Alice quer se comunicar com ele e qual chave ela desejar usar. Aqui, a autenticação ocorre sem maiores problemas. O KDC sabe que a mensagem 1 deve vir de Alice, pois nin- guém mais teria sido capaz de criptografá-la com a chave secreta de Alice. Da mesma forma, Bob sabe que a mensa- gem 2 deve ter vindo do KDC, em quem ele confia, pois ninguém mais conhece sua chave secreta. Infelizmente, esse protocolo tem uma falha muito sé- ria. Trudy precisa de dinheiro; portanto, ela descobre al- guns serviços legítimos que pode prestar a Alice, faz uma oferta interessante e consegue o trabalho. Depois de fazer o serviço, Trudy educadamente solicita que Alice pague por transferência bancária. Alice estabelece uma chave de ses- são com o funcionário do banco, Bob. Em seguida, envia a Bob uma mensagem solicitando que o dinheiro seja trans- ferido para a conta de Trudy. Nesse ínterim, Trudy volta a bisbilhotar a rede. Ela co- pia tanto a mensagem 2 da Figura 8.35 quanto a solicitação de transferência de dinheiro enviada depois da mensagem. 1 Alice escolhe x Trudy escolhe z 3 gz mod n n, g, gx mod n Trudy 2 Bob escolhe y 4 gy mod n n, g, gz mod n Bob Alice Figura 8.34 z O ataque do homem no meio. 08_tanen0809_cap08 BR.indd 523 4/25/11 3:08 PM
- 46. 524 Redes decomputadores Mais tarde, ela responde a ambas as mensagens de Bob. Ele as recebe e pensa: ‘Alice deve ter contratado Trudy ou- tra vez. Percebe-se que o trabalho dela é muito bom’. Em seguida, Bob transfere uma quantia igual em dinheiro da conta de Alice para a conta de Trudy. Algum tempo depois do 50o par de mensagens, Bob vai até Trudy e oferece um bom empréstimo para que ela possa expandir seus negó- cios, que obviamente vão muito bem. Esse problema é cha- mado ataque por replay. Existem várias soluções para o ataque por replay. A primeira é incluir um registro de tempo em cada mensa- gem. Então, se alguém receber uma mensagem obsole- ta, ela poderá ser descartada. O problema é que os clocks nunca estão sincronizados com exatidão na rede; portan- to, deve haver um período durante o qual esse registro de tempo será válido. Trudy pode repetir a mensagem durante esse período e se livrar dela. A segunda solução é colocar um nonce em cada men- sagem. Nesse caso, cada parte terá de se lembrar de todos os nonces anteriores e rejeitar as mensagens que conte- nham algum já utilizado. No entanto, os nonces têm de ser memorizados para sempre, por receio de que Trudy tente repetir uma mensagem de cinco anos. Além disso, se algu- ma máquina apresentar falha e perder sua lista de nonces, ela estará vulnerável a um ataque por replay. Os registros de tempo e os nonces podem ser combinados para limitar o tempo durante o qual estes têm de ser memorizados, mas é óbvio que o protocolo ficará muito mais complicado. Um enfoque mais sofisticado para a autenticação mú- tua é usar um protocolo de desafio-resposta que funcione em diversas direções. Um exemplo bastante conhecido é o protocolo de autenticação de Needham-Schroeder (Needham e Schroeder, 1978), do qual uma das variantes é mostrada na Figura 8.36. O protocolo começa com Alice informando ao KDC que deseja se comunicar com Bob. Essa mensagem contém um número grande aleatório, RA , que é usado como nonce. O KDC retorna a mensagem 2 contendo o número alea- tório de Alice, uma chave de sessão e um bilhete que ela pode enviar a Bob. O objetivo do número aleatório, RA , é garantir a Alice que a mensagem 2 é nova e não um replay. A identidade de Bob também é enviada, caso Trudy pense na possibilidade de substituir B na mensagem 1 por sua própria identidade, para que o KDC codifique o bilhete no fim da mensagem 2 com KT em vez de KB . O bilhete codi- ficado com KB é incluído na mensagem criptografada para impedir que Trudy o substitua por algo diferente quando ele retornar a Alice. Agora Alice envia o bilhete a Bob, junto com um novo número aleatório, RA2 , criptografado com a chave de sessão, KS . Na mensagem 4, Bob envia KS (RA2 - 1), a fim de provar a Alice que ela está se comunicando com o verdadeiro Bob. Retornar KS (RA2 ) não teria funcionado, pois Trudy poderia ter acabado de roubar essa chave na mensagem 3. Depois de receber a mensagem 4, Alice estará conven- cida de que está se comunicando com Bob e de que ne- nhum replay poderia ter sido usado até então. Afinal, ela acabou de gerar RA2 alguns milissegundos antes. O objetivo 1 A, KA (B, KS) KDC 2 Bob Alice KB (A, KS) Figura 8.35 z Uma primeira tentativa de protocolo de autenticação usando um KDC. Figura 8.36 z O protocolo de autenticação Needham-Schroeder. 1 RA, A, B 2 KA (RA, B, KS, KB(A, KS)) KDC 3 Bob Alice KB(A, KS), KS (RA2) 4 KS (RA2 –1), RB 5 KS (RB –1) 08_tanen0809_cap08 BR.indd 524 4/25/11 3:08 PM
- 47. Capítulo 8 Segurança deredes 525 da mensagem 5 é convencer Bob de que ele está se comu- nicando realmente com Alice, e que nenhum replay está sendo usado aqui. Ao fazer com que cada parte gere um desafio e responda a outro, a possibilidade de qualquer tipo de ataque por replay é eliminada. Apesar de parecer bastante sólido, esse protocolo tem uma pequena falha. Se Trudy conseguir obter uma antiga chave de sessão em texto simples, poderá iniciar uma nova sessão com Bob repetindo a mensagem 3 correspondente à chave comprometida e convencê-lo de que é Alice (Den- ning e Sacco, 1981). Dessa vez, ela poderá desfalcar a con- ta bancária de Alice sem precisar prestar nenhum serviço honesto. Mais tarde, Needham e Schroeder (1987) publicaram um protocolo que corrige esse problema. No mesmo exem- plar do mesmo periódico, Otway e Rees (1987) também publicaram um protocolo que resolve o problema de uma forma mais simples. A Figura 8.37 mostra o protocolo de Otway-Rees ligeiramente modificado. No protocolo de Otway-Rees, Alice começa gerando um par de números aleatórios, R, que será usado como um identificador comum, RA , que Alice utilizará para desa- fiar Bob. Quando receber essa mensagem, Bob criará uma nova com a parte criptografada da de Alice e mais uma semelhante de sua própria autoria. Ambas as partes cripto- grafadas com KA e KB identificam Alice e Bob, e contêm o identificador comum e um desafio. O KDC verifica se o R de ambas as partes é igual. Tal- vez não seja, porque Trudy adulterou R na mensagem 1 ou substituiu parte da mensagem 2. Se os dois números R coincidirem, o KDC considerará válida a mensagem de solicitação de Bob. Em seguida, o KDC vai gerar uma chave de sessão criptografada duas vezes, uma para Alice e outra para Bob. Cada mensagem conterá o número aleatório do receptor, como prova de que o KDC, e não Trudy, gerou a mensagem. Nesse momento, tanto Alice quanto Bob têm a mesma chave de sessão e podem começar a comunicação. Na primeira vez que eles trocarem mensagens de dados, cada um poderá ver que o outro tem uma cópia idêntica de KS , e assim a autenticação é concluída. 8.7.4 Autenticação com a utilização do Kerberos Um protocolo de autenticação usado em muitos siste- mas reais (inclusive no Windows 2000 e versões posterio- res) é o Kerberos, que se baseia em uma variante do pro- tocolo de Needham-Schroeder. Seu nome se deve ao cão de várias cabeças da mitologia grega que guardava a entra- da do Hades (provavelmente para manter as pessoas inde- sejáveis à distância). O Kerberos foi projetado no MIT para permitir que os usuários de estações de trabalho tivessem acesso a recursos da rede de uma forma segura. Sua grande diferença em relação ao protocolo de Needham-Schroeder é a suposição de que todos os clocks estão muito bem sin- cronizados. O protocolo passou por várias iterações. A V5 é a versão mais usada na indústria, e está definida na RFC 4120. A anterior, V4, por fim, foi retirada após sérias falhas (Yu et al., 2004). A V5 melhora a V4 com muitas mudan- ças pequenas no protocolo e alguns recursos melhorados, como o fato de não contar mais com o DES, agora desatua lizado. Para obter mais informações, consulte Neuman e Ts’o (1994). O Kerberos envolve três servidores além de Alice (uma estação de trabalho cliente): 1. o Authentication Server (AS): verifica a identidade dos usuários durante o processo de login; 2. o Ticket-Granting Server (TGS): emite ‘bilhetes de comprovação de identidade’; 3. o servidor Bob: na verdade, faz o trabalho que Alice deseja ver pronto. O AS é semelhante a um KDC, porque compartilha uma senha secreta com todos os usuários. O trabalho do TGS é emitir bilhetes que possam convencer os servidores reais de que o portador de um bilhete TGS realmente é quem afirma ser. Para iniciar uma sessão, Alice utiliza uma estação de trabalho pública qualquer e digita seu nome. A estação de trabalho envia seu nome e o do TGS ao AS em texto sim- ples, como mostra a mensagem 1 da Figura 8.38. O retorno é uma chave de sessão e um bilhete, KTGS (A, KS , t), desti- nado ao TGS. A chave de sessão é codificada com a chave secreta de Alice, de modo que apenas Alice possa decodifi- 4 KA(RA, KS) 3 2 KB(RB, KS) KDC 1 Bob Alice A, B, R, KA (A, B, R, RA) A, KA (A, B, R, RA), B, KB (A, B, R, RB) Figura 8.37 z O protocolo de autenticação de Otway-Rees (ligeiramente simplificado). 08_tanen0809_cap08 BR.indd 525 4/25/11 3:08 PM
- 48. 526 Redes decomputadores cá-la. Somente quando a mensagem 2 chega, a estação de trabalho pede a senha de Alice não antes. Em seguida, a senha é usada para gerar KA , a fim de descriptografar a mensagem 2 e obter a chave de sessão. Nesse momento, a estação de trabalho substitui a se- nha de Alice, para garantir que a senha só estará na esta- ção durante alguns milissegundos, no máximo. Se Trudy tentar estabelecer um login como Alice, a senha que ela digitar estará errada e a estação de trabalho detectará o problema, porque o trecho-padrão da mensagem 2 esta- rá incorreto. Depois de estabelecer o login, Alice pode informar à estação de trabalho que deseja contatar Bob, o servidor de arquivos. Em seguida, a estação de trabalho envia a mensagem 3 ao TGS solicitando um bilhete para usar com Bob. O principal elemento nessa solicitação é KTGS (A, KS , t), criptografado com a chave secreta de TGS e usado como prova de que o transmissor realmente é Ali- ce. O TGS responde criando uma chave de sessão, KAB , para que Alice a utilize com Bob. Duas versões dessa chave são retornadas. A primeira é criptografada apenas com KS , para que Alice possa ler a mensagem. A segun- da, com a chave de Bob, KB , de forma que ele também possa ler a mensagem. Trudy pode copiar a mensagem 3 e tentar usá-la mais uma vez, mas será frustrada pelo registro de tempo crip- tografada, t, enviada junto. Trudy não pode substituir o registro de tempo por outro mais recente, porque não conhece KS , a chave de sessão que Alice utiliza para se comunicar com o TGS. Mesmo que Trudy repita a men- sagem 3 rapidamente, tudo o que obterá será outra cópia da mensagem 4 — que não pôde descriptografar antes e que também não poderá descriptografar no momento. Então, Alice envia KAB a Bob, para estabelecer uma sessão com ele. Essa troca também recebe um registro de tempo. A resposta é a prova de que Alice está realmente se comunicando com Bob, e não com Trudy. Depois de uma série de trocas, Alice pode se comu- nicar com Bob sob a proteção de KAB . Se mais tarde ela chegar à conclusão de que precisa se comunicar com ou- tro servidor, Carol, Alice simplesmente repetirá a mensa- gem 3 para o TGS, apenas especificando C em vez de B. O TGS responderá prontamente com um bilhete criptogra- fado com KC , que Alice poderá enviar a Carol e que Carol aceitará como prova de que Alice o enviou. O objetivo de todo esse trabalho é que agora Ali- ce pode acessar servidores instalados por toda a rede de forma segura, e sua senha nunca terá de percorrer a rede. Na verdade, a senha só precisaria permanecer na estação de trabalho da própria Alice durante alguns milissegundos. No entanto, observe que cada servidor faz sua própria autorização. Quando Alice apresenta seu bilhete a Bob, isso prova a ele quem o enviou. Na verdade, a decisão sobre o que Alice está autorizada a fazer cabe a Bob. Como os projetistas do Kerberos não esperavam que o mundo inteiro confiasse em um único servidor de auten- ticação, reservaram espaço para o uso de diversos realms (domínios), cada um com seu próprio AS e TGS. Para obter um bilhete referente a um servidor de um domínio distante, Alice solicitaria a seu próprio TGS um bilhete aceito pelo TGS do domínio distante. Se o TGS distante tiver sido registrado com o local (exatamente como fa- zem os servidores locais), este dará a Alice um bilhete válido no TGS distante. Depois disso, ela poderá usá-lo para executar ações como obter bilhetes para os servido- res desse domínio. No entanto, observe que, para partes pertencentes a dois domínios interagirem, cada uma de- verá confiar no TGS da outra. Caso contrário, não haverá interação. Alice AS TGS Bob KAB(A, t), KB(A, B, KAB, t) A,TGS KA(TGS, KS, t), KTGS(A, KS, t) B, KS(A, t), KTGS(A, KS, t) KS(B, KAB, t), KB(A, B, KAB, t) KAB (t) 6 5 2 4 1 3 Figura 8.38 z A operação do Kerberos V5. 08_tanen0809_cap08 BR.indd 526 4/25/11 3:08 PM
- 49. Capítulo 8 Segurança deredes 527 8.7.5 Autenticação com a criptografia de chave pública Também é possível fazer uma autenticação mútua com o uso da criptografia de chave pública. Para come- çar, Alice precisa da chave pública de Bob. Se existir uma PKI com o servidor de diretórios que entregue cer- tificados para chaves públicas, Alice poderá solicitar o de Bob, como mostra a Figura 8.39, na mensagem 1. A resposta, na mensagem 2, é um certificado X.509 que contém a chave pública de Bob. Quando verifica que a assinatura está correta, Alice envia a Bob uma mensa- gem contendo sua identidade e um nonce. Quando recebe essa mensagem, Bob não sabe com certeza se ela veio de Alice ou de Trudy, mas continua e pede ao servidor de diretórios a chave pública de Ali- ce (mensagem 4) e logo a recebe (mensagem 5). Em seguida, envia a Alice uma mensagem contendo o RA de Alice, seu próprio nonce, RB , e uma chave de sessão sugerida, KS . Quando recebe a mensagem 6, Alice a descriptogra- fa usando sua própria chave privada. Ela vê RA na men- sagem e fica feliz. A mensagem deve ter vindo de Bob, pois Trudy não tem como determinar RA . Além disso, a mensagem deve ser nova, e não um replay, pois ela acabou de enviar RA a Bob. Alice concorda com a sessão retornando a mensagem 7. Quando vê RB criptografada com a chave de sessão que acabou de gerar, Bob fica sabendo que Alice recebeu a mensagem 6 e confirmou RA . Agora Bob está feliz. O que Trudy pode fazer para subverter esse proto- colo? Ela pode falsificar a mensagem 3 e enganar Bob fazendo-o pensar que ela é Alice, mas Alice verá um RA que não enviou e não prosseguirá com a transmissão. Trudy não poderá forjar a mensagem 7 de volta para Bob, pois não conhece os valores de RB e de KS e não pode determiná-los sem a chave privada de Alice. Ela está sem sorte. 8.8 Segurança de correio eletrônico Quando uma mensagem de correio eletrônico é en- viada entre dois sites distantes, geralmente ela transita por dezenas de máquinas até chegar a seu destino. Qualquer uma dessas máquinas pode ler e armazenar a mensagem para usá-la posteriormente. Na prática, não há privacidade, apesar de muita gente achar o contrário. Todavia, muita gente gostaria de enviar mensagens de correio eletrônico para que fossem lidas pelo destinatário pretendido e por ninguém mais (nem seu chefe, nem o governo). Esse dese- jo estimulou muitas pessoas e grupos a aplicar os princípios da criptografia que estudamos anteriormente para produzir mensagens seguras. Nas seções a seguir, estudaremos um sistema de correio eletrônico seguro e bastante utilizado, o PGP, e depois mencionaremos brevemente outro sistema, o S/MIME. Para obter mais informações sobre correio ele- trônico seguro, consulte Kaufman et al. (2002) e Schneier (1995). 8.8.1 PGP — Pretty Good Privacy Nosso primeiro exemplo, o PGP (Pretty Good Pri- vacy), foi criado por uma única pessoa, Phil Zimmermann (1995a, 1995b). Zimmermann é um defensor da privacidade cujo lema é: ‘Se a privacidade for ilegal, somente os ilegais terão privacidade’. Lançado em 1991, o PGP é um pacote completo para segurança de mensagens de correio eletrôni- co que fornece privacidade, autenticação, assinaturas digitais e compactação, tudo de uma forma fácil de usar. Além disso, o pacote completo, incluindo o código-fonte, é distribuído de graça via Internet. Graças à qualidade, ao preço (zero) e à disponibilidade em plataformas UNIX, Linux, Windows e Mac OS, é um sistema bastante utilizado hoje. O PGP codifica dados usando uma cifra de bloco cha- mada IDEA (International Data Encryption Algori- thm), que utiliza chaves de 128 bits. Ele foi criado na Suíça em uma época na qual o DES era considerado decadente e o AES ainda não tinha surgido. Em termos conceituais, o IDEA é semelhante ao DES e ao AES: ele embaralha os bits em uma série de rodadas, mas os detalhes das funções exe- cutoras são diferentes dos de DES e AES. O gerenciamento de chaves utiliza o RSA e a integridade de dados utiliza o MD5, tópicos que já discutimos. O PGP também esteve envolvido em controvérsias des- de o início (Levy, 1993). Como Zimmermann não fez nada para impedir que outras pessoas colocassem o PGP na Inter- net, onde gente de todo o mundo poderia obtê-lo, o governo dos Estados Unidos afirmou que Zimmermann violou leis norte-americanas que proibiam a exportação de munições. A investigação durou cinco anos, mas foi abandonada, pro- vavelmente por dois motivos. Primeiro, Zimmermann não colocou o PGP na Internet, e assim seu advogado afirmou que ele nunca exportou nada (e, na época, havia dúvidas sobre se criar um site constituiria uma forma de exportação). 3 EB (A, RA) 7 KS (RB) 6 EA (RA, RB, KS) Bob Alice Diretório 2. Aqui está EB 4. Dê-me E A 5. Aqui está E A 1. Dê-me EB Figura 8.39 z Autenticação mútua com a utilização da criptografia de chave pública. 08_tanen0809_cap08 BR.indd 527 4/25/11 3:08 PM
- 50. 528 Redes decomputadores Segundo, o governo percebeu mais tarde que vencer uma disputa judicial significava convencer um júri de que um site contendo um programa de privacidade passível de ser transferido por download era uma infração sujeita às penas da lei contra tráfico de armas — que proibia a exportação de materiais de guerra como tanques, submarinos, aeronaves militares e armas nucleares. Vários anos de publicidade ne- gativa provavelmente também não ajudariam muito. A propósito, as regras de exportação são bizarras, para dizer o mínimo. O governo considerava a colocação de código em um site um ato de exportação ilegal e pro- cessou Zimmermann durante cinco anos. Por outro lado, quando alguém publicava o código-fonte completo do PGP em linguagem C sob a forma de um livro (em uma fonte de tamanho grande com um checksum em cada página, para facilitar a digitalização) e depois exportava o livro, isso era legal, porque os livros não são classifi- cados como munições. A espada é mais poderosa que a caneta, pelo menos para o Tio Sam. Outro problema que o PGP enfrentou envolvia a viola- ção de patentes. A empresa que detinha a patente do RSA, denominada RSA Security, Inc., alegou que o uso que o PGP fazia do algoritmo RSA infringia sua patente, mas esse problema foi contornado nas versões seguintes, a partir da versão 2.6. Além disso, o PGP usa outro algoritmo de crip- tografia patenteado, o IDEA, o que causou alguns proble- mas no início. Tendo em vista que o PGP tem código-fonte aberto, muitas pessoas e grupos o modificaram e produziram vá- rias versões. Algumas delas foram projetadas para contor- nar as leis de munições; outras se concentraram em evitar o uso de algoritmos patenteados; e ainda outras queriam transformá-lo em um produto comercial com código-fonte fechado. Embora as leis de munições tenham sido ligeira- mente atenuadas (do contrário, produtos que usassem o AES não poderiam ter sido exportados pelos Estados Uni- dos) e a patente do RSA tenha expirado em setembro de 2000, o legado de todos esses problemas foi a existência de várias versões incompatíveis do PGP, identificadas por diversos nomes. A descrição a seguir se concentra no PGP clássico, a versão mais antiga e mais simples. Outra versão popular, o Open PGP, é descrita na RFC 2440. Ainda outra é o Privacy Guard do GNU. O PGP utilizou intencionalmente algoritmos criptográ- ficos que já existiam, em vez de criar novos. Ele se baseia em algoritmos que passaram por intensas revisões e não foram projetados ou influenciados por nenhuma agência governamental que tentasse enfraquecê-los. Para pessoas que tendem a não acreditar no governo, essa característica representa uma excelente opção. O PGP aceita compactação de textos, sigilo e assinatu- ras digitais, e também oferece amplos recursos de geren- ciamento de chaves, mas, estranhamente, não oferece re- cursos de correio eletrônico. Ele é mais parecido com um pré-processador que recebe texto simples como entrada e produz texto cifrado assinado em base64 como saída. Essa saída pode então ser enviada por correio eletrônico. Algu- mas implementações do PGP chamam um agente do usuá- rio na etapa final para enviar de fato a mensagem. Para ver como o PGP funciona, considere o exemplo da Figura 8.40. Alice deseja enviar uma mensagem em texto simples assinada, P, para Bob de forma segura. Tanto Alice quanto Bob têm chaves RSA privadas (DX ) e públicas (EX ). Vamos supor que cada um conheça a chave pública do outro; examinaremos em breve o gerenciamento de chaves do PGP. Alice começa invocando o programa PGP em seu com- putador. Primeiro, o PGP submete sua mensagem P a um processo de hash, utilizando o MD5; em seguida, criptogra- fa o resultado com sua chave privada RSA, DA . Quando re- ceber a mensagem, Bob poderá descriptografar o hash com MD5 RSA Zip IDEA Base 64 RSA Texto ASCII para a rede P1.Z P P1 Mensagem de texto simples original de Alice Concatenação de P e o hash sinalizado de P Concatenação de P1.Z codificado com IDEA e KM codificado com EB Chave RSA privada de Alice, DA P1 compactado Chave RSA pública de Bob, EB KM : Chave de mensagem única para IDEA : Concatenação KM Figura 8.40 z O PGP em operação para enviar uma mensagem. 08_tanen0809_cap08 BR.indd 528 4/25/11 3:08 PM
- 51. Capítulo 8 Segurança deredes 529 a chave pública de Alice e confirmar que o hash está corre- to. Mesmo que alguma outra pessoa (por exemplo, Trudy) pudesse adquirir o hash nesse estágio e descriptografá-lo com a chave pública de Alice, a robustez do MD5 garante que seria inviável em termos computacionais produzir ou- tra mensagem com o mesmo hash MD5. O hash criptografado e a mensagem original são conca- tenados em uma única mensagem P1 e compactados com o programa ZIP, que emprega o algoritmo de Ziv-Lempel (Ziv e Lempel, 1977). Chame a saída dessa etapa de P1.Z. Em seguida, o PGP solicita a Alice que informe dados aleatoriamente. O conteúdo e a velocidade de digitação são usados para gerar uma chave IDEA de 128 bits, KM (denomi- nada chave de sessão na literatura sobre o PGP; no entanto, essa denominação não é adequada, pois não há sessão). Em seguida, KM é usada para criptografar P1.Z com o IDEA no modo de feedback de cifra. Além disso, KM é criptografada com a chave pública de Bob, EB . Em seguida, esses dois com- ponentes são concatenados e convertidos para base64, como discutimos na seção sobre o MIME no Capítulo 7. A mensa- gem resultante contém apenas letras, dígitos e os símbolos +, / e =, o que significa que ela pode ser incluída em um corpo RFC 822 e chegar intacta a seu destino. Ao receber a mensagem, Bob reverte a codificação base64 e decodifica a chave IDEA utilizando sua chave pri- vada RSA. Ao usar essa chave, ele decodifica a mensagem para obter P1.Z. Após a descompactação, Bob separa o tex- to simples do hash criptografado e descriptografa o hash utilizando a chave pública de Alice. Se o hash de texto sim- ples coincidir com seu próprio cálculo MD5, ele saberá que P é a mensagem correta e que ela veio de Alice. Vale a pena observar que o RSA só é usado em duas situações: para criptografar o hash MD5 de 128 bits e para criptografar a chave IDEA de 128 bits. Apesar de o RSA ser lento, ele só precisa criptografar 256 bits, e não um grande volume de dados. Além disso, todos os 256 bits de texto simples são excessivamente aleatórios; portanto, Trudy terá muito trabalho para descobrir se uma suposta chave está correta. O trabalho de criptografia é feito pelo IDEA, que é várias ordens de grandeza mais rápido que o RSA. Portan- to, o PGP oferece segurança, compactação e assinatura di- gital de uma forma muito mais eficiente do que o esquema ilustrado na Figura 8.16. O PGP aceita quatro tamanhos de chaves RSA. Cabe ao usuário selecionar o mais apropriado. Os tamanhos são: 1. casual (384 bits): pode ser decifrado com facilidade atualmente. 2. comercial (512 bits): pode ser decifrado por empre- sas de informática. 3. militar (1.024 bits): ninguém no planeta consegue decifrar. 4. alienígena (2.048 bits): não pode ser decifrado por ninguém, nem de outros planetas. Como o RSA só é usado para efetuar dois pequenos cálculos, todos deveriam usar chaves fortes alienígenas o tempo todo. O formato de uma mensagem PGP clássica é mostra- do na Figura 8.41. Diversos outros formatos também es- tão sendo usados. A mensagem tem três partes — a chave IDEA, a assinatura e a mensagem. A parte referente à chave contém não só a chave, mas também um identificador de chave, pois os usuários podem ter várias chaves públicas. A parte referente à assinatura contém um cabeçalho, que não nos interessará aqui. O cabeçalho é seguido por um registro de tempo, pelo identificador da chave pública do transmissor — que pode ser usada para descriptografar o hash de assinatura — , algum tipo de informação que identifique os algoritmos utilizados (para permitir que o MD6 e o RSA2 sejam usados quando forem criados) e pelo próprio hash criptografado. A parte referente à mensagem também contém um cabeçalho, o nome-padrão do arquivo a ser usado se o re- ceptor gravar o arquivo no disco, o registro de tempo de criação da mensagem e, por fim, a própria mensagem. No PGP, o gerenciamento de chaves recebeu muita atenção por ser o calcanhar de aquiles de todos os sistemas de segurança. O gerenciamento de chaves funciona da se- guinte forma. Cada usuário mantém duas estruturas de da- ID de EB ID de EA Cab. assinatura Hash MD5 Cab. mens. Nome arq. H o r a H o r a T i p o s KM Mensagem Criptografado por EB DA Compactado, criptografado por IDEA Base64 Parte da assinatura Parte de chave da mensagem Parte da mensagem Figura 8.41 z Uma mensagem PGP. 08_tanen0809_cap08 BR.indd 529 4/25/11 3:08 PM
- 52. 530 Redes decomputadores dos localmente: um anel de chaves privadas e um anel de chaves públicas. O anel de chaves privadas contém um ou mais pares de chave pública/privada. A razão para acei- tar vários pares por usuário é permitir que estes alterem suas chaves públicas periodicamente ou quando uma delas for considerada comprometida, sem invalidar as mensa- gens que estiverem sendo preparadas ou em trânsito. Cada par tem um identificador associado, para que o remeten- te da mensagem informe ao destinatário qual chave pú- blica foi utilizada para criptografá-la. Os identificadores de mensagem consistem nos 64 bits de baixa ordem da chave pública. Os usuários são responsáveis por evitar conflitos em seus identificadores de chave pública. As chaves priva- das armazenadas em disco são criptografadas com o uso de uma senha especial (arbitrariamente longa) para protegê- -las contra ataques sorrateiros. O anel de chaves públicas contém as chaves públi- cas correspondentes do usuário. Elas são necessárias para criptografar as chaves associadas a cada mensagem. Cada entrada do anel contém não só a chave pública, mas tam- bém seu identificador de 64 bits e uma indicação de até que ponto o usuário confia na chave. O problema que está sendo resolvido é explicado a se- guir. Vamos supor que as chaves públicas sejam mantidas em sistemas de BBS. Uma forma de Trudy ler a correspon- dência secreta de Bob é atacar o BBS e substituir a cha- ve pública de Bob por outra de sua escolha. Quando Alice obtiver a chave que supostamente pertence a Bob, Trudy poderá montar um ataque do homem no meio (man-in- -the-middle, bucket brigade attack) contra Bob. Para impedir tais ataques, ou pelo menos minimizar suas consequências, Alice precisa saber até que ponto pode confiar no item ‘chave de Bob’ em seu anel de chaves públicas. Se souber que Bob entregou pessoalmente um disquete contendo a chave, ela poderá definir o valor de confiança como o mais alto. Essa é uma abordagem descen- tralizada e controlada pelo usuário para o gerenciamento de chaves públicas, o que distingue o PGP dos esquemas centralizados de PKI. No entanto, na prática, frequentemente as pessoas re- cebem chaves públicas consultando um servidor de chaves confiável. Por essa razão, depois da padronização do X.509, o PGP também passou a admitir esses certificados, bem como o mecanismo tradicional de anel de chaves públicas do PGP. Todas as versões atuais do PGP têm suporte ao X.509. 8.8.2 S/MIME O próximo empreendimento da IETF relacionado à segurança do correio eletrônico foi denominado S/MIME (Secure/MIME), e é descrito nas RFCs 2632 a 2643. Ele oferece autenticação, integridade de dados, sigilo e não re- púdio. É bastante flexível, pois admite uma variedade de algoritmos criptográficos. Considerando-se o nome, não surpreende que o S/MIME se integre bem ao MIME, per- mitindo que todos os tipos de mensagens sejam protegidos. Foi definida uma grande variedade de novos cabeçalhos MIME, por exemplo, para conter assinaturas digitais. O S/MIME não tem uma estrutura rígida de certifica- dos começando em uma única raiz, o que tem sido um dos problemas políticos que arruinaram um sistema mais antigo, chamado PEM (Privacy Enhanced Mail). Em vez disso, os usuários podem ter várias âncoras de confiança. Desde que a origem de um certificado possa ser acompanhada até alguma âncora de confiança em que o usuário acredite, ele é consi- derado válido. O S/MIME utiliza os algoritmos e protocolos- -padrão que examinamos até agora; portanto, não o discutire- mos mais aqui. Para ver os detalhes, consulte as RFCs. 8.9 Segurança da Web Acabamos de estudar duas áreas importantes em que a segurança é necessária: comunicações e correio eletrônico. Considere-as entrada e aperitivo. Agora, vamos ao prato principal: a segurança da Web. O lugar onde encontramos a maioria dos intrusos, espionando e fazendo seu trabalho sujo é a Web. Nas próximas seções examinaremos alguns problemas e questões relacionados à segurança da Web. Grosso modo, a segurança da Web pode ser dividida em três partes. Primeiro: como os objetos e os recursos são no- meados com segurança? Segundo: como é possível esta- belecer conexões seguras e autenticadas? Terceiro: o que acontece quando um site envia a um cliente um fragmen- to de código executável? Depois de estudarmos algumas ameaças, vamos examinar todas essas questões. 8.9.1 Ameaças Quase toda semana, lemos nos jornais notícias sobre problemas de segurança de sites. A situação é realmente bastante séria. Vamos examinar alguns exemplos do que já aconteceu. Primeiro, a home page de inúmeras organizações é atacada e substituída por uma nova home page escolhida pelos crackers. (A imprensa popular chama as pessoas que invadem computadores de ‘hackers’, mas muitos programa- dores reservam esse termo para os ótimos programadores. Preferimos chamar esses invasores de ‘crackers’.) Entre os sites invadidos incluem-se Yahoo, o Exército dos Estados Unidos, a CIA, a NASA e o New York Times. Na maioria dos casos, os crackers simplesmente colocavam algum texto engraçado, e os sites eram arrumados dentro de algumas horas. Agora, vamos observar alguns casos muito mais sérios. Diversos sites foram derrubados por ataques de negação de serviço, nos quais o cracker inunda o site com tráfe- go, tornando-o incapaz de responder a consultas legítimas. Com frequência, o ataque é montado a partir de um gran- de número de máquinas que o cracker já invadiu (ataques DDoS). Esses ataques são tão comuns que já não geram mais notícias, mas podem custar ao site atacado milhares de dólares em negócios perdidos. 08_tanen0809_cap08 BR.indd 530 4/25/11 3:08 PM
- 53. Capítulo 8 Segurança deredes 531 Em 1999, um cracker sueco invadiu o site Hotmail da Microsoft e criou um site-espelho que permitia a qualquer pessoa digitar o nome de um usuário do Hotmail e depois ler todo o correio eletrônico atual e arquivado da pessoa. Em outro caso, um cracker russo de 19 anos chamado Maxim invadiu um site de comércio eletrônico e roubou 300 mil números de cartão de crédito. Em seguida, abor- dou os proprietários do site e informou que, se não rece- besse 100 mil dólares, iria postar todos os números de car- tões de crédito na Internet. Eles não cederam à chantagem, e o cracker realmente publicou os números dos cartões de crédito causando muitos danos a muitas vítimas inocentes. Em um cenário diferente, um aluno de 23 anos na Cali- fórnia enviou por correio eletrônico um comunicado a uma agência de notícias, afirmando falsamente que a Emulex Cor- poration iria anunciar um grande prejuízo trimestral e que o CEO da empresa renunciaria imediatamente. Dentro de pou- cas horas, as ações caíram 60%, fazendo os acionistas perder mais de 2 bilhões de dólares. O atacante ganhou 250.000 dó- lares vendendo suas ações pouco antes de enviar o anúncio. Embora esse evento não represente a invasão de um site, é claro que a inserção de um anúncio desse tipo na home page de qualquer grande corporação teria um efeito semelhante. Poderíamos (infelizmente) continuar com esse assunto por muitas páginas, mas agora devemos examinar algumas questões técnicas relacionadas à segurança da Web. Para obter mais informações sobre problemas de segurança de todos os tipos, consulte Anderson (2008a); Stuttard e Pinto (2007); e Schneier (2004). A pesquisa na Internet também resultará na apresentação de um grande número de casos específicos. 8.9.2 Nomenclatura segura Vamos iniciar com algo bastante básico: Alice quer visi- tar o site de Bob. Ela digita o URL de Bob em seu navegador e, em alguns segundos, surge uma página Web. Porém, será a página de Bob? Talvez sim e talvez não. Trudy poderia colocar em prática mais uma vez seus velhos truques. Por exemplo, ela poderia interceptar todos os pacotes enviados por Alice e examiná-los. Quando capturar uma solicitação GET do HTTP endereçada ao site de Bob, ela mesma poderá ir até o site de Bob para obter a página, modificá-la como desejar e retornar a Alice a página falsa. Alice nem ficaria sabendo. Pior ainda, Trudy poderia diminuir os preços da loja eletrônica de Bob para tornar suas mercadorias muito atraentes, fazendo Alice enviar seu número de cartão de crédito para ‘Bob’, a fim de adquirir algumas mercadorias. Uma desvantagem desse clássico ataque do homem no meio é que Trudy tem de estar em uma posição convenien- te para interceptar o tráfego enviado por Alice e forjar seu tráfego de entrada. Na prática, ela tem de grampear a linha telefônica de Alice ou de Bob, pois é muito difícil grampear o backbone de fibra óptica. Embora a espionagem ativa certa- mente seja possível, ela exige determinado volume de traba- lho e, embora seja inteligente, Trudy também é preguiçosa. Além disso, existem maneiras mais fáceis de enganar Alice. DNS spoofing Suponha que Trudy seja capaz de invadir o sistema DNS, ou talvez apenas o cache DNS no ISP de Alice, e substitua o en- dereço IP de Bob (digamos, 36.1.2.3) por seu próprio endereço IP (digamos, 42.9.9.9). Isso leva ao ataque explicado a seguir. O modo como ele deve funcionar é ilustrado na Figura 8.42(a). Aqui (1) Alice solicita ao DNS o endereço IP de Bob, (2) recebe esse endereço, (3) pergunta a Bob por sua home page e (4) também recebe a home page. Depois de Trudy ter modificado o registro de DNS de Bob para conter seu próprio endereço IP em lugar do endereço de Bob, temos a situação da Figura 8.42(b). Nesse caso, quando Alice procurar o endereço IP de Bob, rece- berá o de Trudy, e então todo o tráfego destinado a Bob irá para Trudy. Agora, Trudy pode montar um ataque do homem no meio sem ter o trabalho de grampear linhas telefônicas. Em vez disso, ela terá de invadir um servidor DNS e alterar um único registro, uma proposta muito mais fácil. Como Trudy poderia enganar o DNS? Na verdade, isso é relativamente fácil. Em resumo, Trudy pode enganar o servidor DNS no ISP de Alice, enviando-lhe uma consulta do endereço IP de Bob. Infelizmente, como o DNS utiliza o UDP, o servidor DNS não tem nenhum meio real de verificar quem forneceu a resposta. Trudy pode explorar essa propriedade forjando a res- posta esperada e, desse modo, injetar um falso endereço IP no cache do servidor DNS. Por simplicidade, vamos supor que o ISP de Alice não tenha uma entrada para o site de Bob, bob. com. Se tiver, Trudy poderá esperar até ele entrar em timeout e tentar mais tarde (ou usar outros truques). Trudy inicia o ataque enviando uma solicitação de pesquisa ao ISP de Alice, pedindo o endereço IP de bob.com. Tendo em vista que não existe nenhuma entrada correspondente a esse nome no DNS, o servidor cache consulta o servidor de nível superior em busca do domínio com, a fim de obter uma entra- da. No entanto, Trudy invade o servidor com e envia de volta uma resposta falsa que informa: “bob.com é 42.9.9.9”, mas, na realidade, o endereço IP é o dela. Se sua falsa resposta voltar primeiroaoISPdeAlice,elaseráguardadanocacheearesposta real será rejeitada como uma resposta não solicitada a uma con- sulta que não está mais pendente. Enganar um servidor DNS fazendo-o instalar um falso endereço IP é uma ação chamada DNS spoofing. Um cache que contém um endereço IP inten- cionalmente falso como esse é chamado cache envenenado. Na realidade, nem tudo é assim tão simples. Primeiro, o ISP de Alice verifica se a resposta contém o endereço IP de origem correto do servidor de nível superior. Porém, como Trudy pode colocar o que quiser nesse campo de endereço IP, ela pode anular com facilidade esse teste, pois os endere- ços IP dos servidores de nível superior têm de ser públicos. Em segundo lugar, para permitir que os servidores DNS saibam a resposta para cada solicitação, todas as solicitações têm um número de sequência. Para enganar o ISP de Alice, Trudy tem de conhecer seu número de sequência atual. O modo mais fácil de descobrir o número de sequência atual é Trudy registrar um domínio ela mesma, digamos, trudy- -a-intrusa.com. Vamos supor que seu endereço IP também 08_tanen0809_cap08 BR.indd 531 4/25/11 3:08 PM
- 54. 532 Redes decomputadores seja 42.9.9.9. Ela também cria um servidor DNS para seu novo domínio, dns.trudy-a-intrusa.com. Esse servidor uti- liza ainda o endereço IP de Trudy, 42.9.9.9, pois Trudy só tem um computador. Agora, ela tem de dar ciência ao ISP de Alice de seu servidor DNS. Isso é fácil. Tudo o que tem a fazer é pedir ao ISP de Alice que lhe forneça foobar.trudy- -a-intrusa.com. Isso fará com que o ISP de Alice descubra quem serve ao novo domínio de Trudy, solicitando o ende- reço ao servidor de endereços com de nível superior. Com dns.trudy-a-intrusa.com em segurança no cache do ISP de Alice, o ataque real pode começar. Agora, Trudy consulta o ISP de Alice em busca de www.trudy-a-intrusa. com. Naturalmente, o ISP envia ao servidor DNS de Trudy uma consulta solicitando essa página. Essa consulta contém o número de sequência que Trudy está procurando. Mais que depressa, Trudy pede ao ISP de Alice que procure Bob. Ela responde de imediato sua própria pergunta, enviando ao ISP uma resposta forjada, supostamente do servidor com de nível superior, afirmando: ‘bob.com é 42.9.9.9’. Essa resposta contém um número de sequência uma unidade maior que o endereço que ela acabou de receber. Enquanto isso, ela também pode enviar uma segunda falsificação com um número de sequência duas unidades mais alto, e talvez mais uma dezena de números de sequência crescentes. Um deles deverá corresponder. Os restantes serão simplesmen- te descartados. Quando chegar a resposta forjada de Alice, ela ficará em cache; mais tarde, quando chegar a resposta real, ela será rejeitada, pois não haverá nenhuma consulta pendente nesse momento. Agora, quando Alice procurar bob.com, será informada de que deve usar 42.9.9.9, o endereço de Trudy. No confor- to de sua própria sala de estar, Trudy montou um ataque do homem no meio bem-sucedido, cujas etapas estão ilustradas na Figura 8.43. Esse ataque específico pode ser anulado se os servidores DNS usarem IDs aleatórias em suas consultas, em vez de simplesmente contarem; porém, parece que toda vez que um furo é vedado, surge outro. Em particular, as IDs têm apenas 16 bits, de modo que é fácil trabalhar com todas elas quando é um computador que está fazendo as tentativas. DNS Seguro O problema real é que o DNS foi projetado em uma épo- ca na qual a Internet era um recurso de pesquisa para algu- mas centenas de universidades e nem Alice, nem Bob, nem Trudy faziam parte da turma. Naquele tempo, o importante não era a segurança, mas sim fazer a Internet funcionar. O ambiente mudou de forma radical ao longo dos anos; assim, em 1994, a IETF instalou um grupo de trabalho para tornar o DNS fundamentalmente seguro. Esse projeto (contínuo) é conhecido como DNSsec (DNS security), e seu resultado é apresentado na RFC 2535. Infelizmente, o DNSsec ainda não foi totalmente implementado, e portanto diversos ser- vidores DNS ainda estão vulneráveis a ataques de spoofing. Em termos conceituais, o DNSsec é extremamente sim- ples. Ele se baseia na criptografia de chave pública. Cada zona DNS (no sentido da Figura 7.2) tem um par de chave pública/chave privada. Todas as informações enviadas por um servidor DNS são assinadas com a chave privada da zona de origem, de forma que o receptor possa verificar sua autenticidade. O DNSsec oferece três serviços fundamentais: 1. prova de onde os dados se originaram; 2. distribuição de chave pública; 3. autenticação de transação e solicitação. Figura 8.42 z (a) Situação normal. (b) Um ataque baseado na invasão do DNS e na modificação do registro de Bob. 1. Dê-me o endereço IP de Bob 2. 36.1.2.3 (endereço IP de Bob) 3. GET index.html 4. Home page de Bob Servidor Web de Bob (36.1.2.3) Servidor DNS Alice 1 2 3 (a) 4 1. Dê-me o endereço IP de Bob 2. 42.9.9.9 (endereço IP de Trudy) 3. GET index.html 4. Home page de Bob modificada por Trudy Servidor Web de Trudy (42.9.9.9) Servidor DNS atacado Alice 1 2 3 (b) 4 08_tanen0809_cap08 BR.indd 532 4/25/11 3:08 PM
- 55. Capítulo 8 Segurança deredes 533 O principal serviço é o primeiro, que verifica se os dados que estão sendo retornados foram aprovados pelo proprietário da zona. O segundo é útil para armazenar e recuperar chaves públicas com segurança. O terceiro é ne- cessário como proteção contra ataques por reprodução e spoofing. Observe que o sigilo não é um serviço oferecido, pois todas as informações no DNS são consideradas públi- cas. Tendo em vista que a implantação do DNSsec deverá demorar vários anos, a habilidade de servidores conscientes da segurança para interoperar com servidores que ignoram os aspectos da segurança é algo essencial; isso implica que o protocolo não pode ser alterado. Agora, vamos observar alguns detalhes. Os registros DNS são agrupados em conjuntos chamados RRSets (Resource Record Sets), com todos aqueles que têm o mesmo nome, a mesma classe e o mesmo tipo reunidos em um único conjunto. Por exemplo, um RRSet pode conter vários registros A, se um nome DNS for resolvido em um en- dereço IP primário e um endereço IP secundário. Os RRSets são estendidos com vários tipos novos de registros (descritos a seguir). Cada RRSet passa por um hash criptográfico (por exemplo, usando SHA-1). O hash é assinado pela chave pri- vada da zona (por exemplo, usando-se o RSA). A unidade de transmissão para clientes é o RRSet assinado. Ao receber um RRSet assinado, o cliente pode verificar se ele foi assinado pela chave privada da zona de origem. Se a assinatura coin- cidir, os dados serão aceitos. Tendo em vista que cada RRSet contém sua própria assinatura, os RRSets podem ser armaze- nados em cache em qualquer lugar, até mesmo em servidores não confiáveis, sem trazer perigo à segurança. O DNSsec introduz vários tipos novos de registros. O primeiro deles é o registro KEY. Esse registro contém a cha- ve pública de uma zona, um usuário, um host ou outro protagonista, o algoritmo de criptografia usado na assinatu- ra, o protocolo empregado na transmissão e alguns outros bits. A chave pública é armazenada em estado bruto. Os certificados X.509 não são usados devido a seu tamanho. O campo do algoritmo contém um valor 1 para assinaturas MD5/RSA (a opção preferida) e outros valores para outras combinações. O campo de protocolo pode indicar o uso do IPsec ou de outros protocolos de segurança, se houver. O segundo entre os novos tipos de registros é o registro SIG. Ele contém o hash assinado de acordo com o algoritmo especificado no registro KEY. A assinatura se aplica a todos os registros no RRSet, incluindo quaisquer registros KEY presentes, mas excluindo ela própria. Ele também contém os horários em que a assinatura inicia seu período de vali- dade e de vencimento, bem como o nome do signatário e de alguns outros itens. O projeto do DNSsec é tal que a chave privada de uma zona pode ser mantida off-line. Uma ou duas vezes por dia, o conteúdo do banco de dados de uma zona pode ser transportado manualmente (por exemplo, em CD-ROM) para uma máquina desconectada na qual a chave priva- da está localizada. Todos os RRSets podem ser assinados nessa máquina e os registros SIG assim produzidos podem ser transportados de volta ao servidor primário da zona em CD-ROM. Desse modo, a chave privada pode ser armaze- nada em um CD-ROM bloqueado de forma segura, exceto quando é inserido na máquina desconectada para assinar os novos RRSets do dia. Depois que o processo de assina- tura é concluído, todas as cópias da chave são apagadas da memória, sendo o disco e o CD-ROM devolvidos a um local seguro. Esse procedimento reduz a segurança eletrônica à segurança física, algo que as pessoas entendem como tratar. Esse método de assinatura prévia de RRSets aumenta bastante a velocidade do processo de responder a consul- tas, pois nenhuma criptografia tem de ser feita durante a execução. Em compensação, é necessário um grande vo- lume de espaço de disco para armazenar todas as chaves e assinaturas nos bancos de dados DNS. Alguns registros aumentarão dez vezes em tamanho devido à assinatura. Quando um processo cliente obtém um RRSet assina- do, ele tem de aplicar a chave pública da zona de origem 1. Procura foobar.trudy-the-intruder.com (para forçá-lo para o cache do ISP) 2. Procura www.trudy-the-intruder.com (para obter o próximo número de sequência do ISP) 3. Pedido para www.trudy-the-intruder.com (para forçar o ISP a consultar o servidor .com na etapa 5) 4. Rapidamente, procura bob.com (para forçar o ISP a consultar o servidos no passo 5) 5. Consulta legítima para bob.com com seq = n+1 6. Resposta forjada de Trudy: Bob é 42.9.9.9, seq = n+1 7. Resposta real (rejeitada; tarde demais) Cache do ISP de Alice Servidor DNS .com Trudy 5 7 1 2 3 4 6 Figura 8.43 z Como Trudy engana o ISP de Alice. 08_tanen0809_cap08 BR.indd 533 4/25/11 3:08 PM
- 56. 534 Redes decomputadores para decifrar o hash, calcular o próprio hash e comparar os dois valores. Se eles concordarem, os dados serão considera- dos válidos. Porém, esse procedimento faz surgir a seguin- te questão: como o cliente obtém a chave pública da zona? Uma alternativa é adquiri-la de um servidor confiável, utili- zando uma conexão segura (por exemplo, usando o IPsec). Porém, na prática, espera-se que os clientes sejam pré- -configurados com as chaves públicas de todos os domínios de nível superior. Se agora Alice quiser visitar o site de Bob, ela poderá solicitar ao DNS o RRSet de bob.com, que con- terá seu endereço IP e um registro KEY contendo a chave pública de Bob. Esse RRSet será assinado pelo domínio com de nível superior, e assim Alice poderá verificar facilmente sua validade. Um exemplo do que esse RRSet pode conter é mostrado na Tabela 8.4. Agora, munida de uma cópia verificada da chave pú- blica de Bob, Alice pode pedir ao servidor DNS de Bob (controlado por Bob) o endereço IP de www.bob.com. Esse RRSet será assinado pela chave privada de Bob, e assim Ali- ce pode verificar a assinatura de Bob no RRSet que ele re- torna. Se Trudy, de alguma maneira, conseguir injetar um falso RRSet em qualquer dos caches, Alice poderá detectar essa falta de autenticidade facilmente, porque o registro SIG contido nele será incorreto. Porém, o DNSsec também fornece um mecanismo criptográfico para vincular uma resposta a uma consulta específica, a fim de impedir o tipo de ataque que Trudy tentou realizar na Figura 8.43. Essa medida (opcional) contra o spoofing adiciona à resposta um hash da mensa- gem de consulta assinado com a chave privada do autor da resposta. Como Trudy não conhece a chave privada do servidor com de nível superior, ela não pode forjar uma resposta a uma consulta ao ISP de Alice enviada pelo ISP. Sem dúvida, ela pode receber sua resposta de volta pri- meiro, mas essa resposta será rejeitada devido à assinatu- ra inválida do hash. O DNSsec também admite alguns outros tipos de re- gistros. Por exemplo, o registro CERT pode ser usado para armazenar certificados (por exemplo, X.509). Esse registro é fornecido porque algumas pessoas querem transformar o DNS em uma PKI. Resta saber se de fato isso é possível. In- terromperemos nossa discussão sobre o DNSsec aqui. Para obter mais detalhes, consulte a RFC 2535. 8.9.3 SSL — Secure Sockets Layer A nomenclatura segura é um bom começo, mas exis- tem vários outros detalhes sobre segurança da Web. A próxima etapa é gerar conexões seguras. Agora, vamos examinar como podem ser alcançadas. Nada que envolva segurança é simples, e isto não é uma exceção. Quando estourou para o público, a Web foi usada no início apenas para distribuir páginas estáticas. Porém, em pouco tempo, algumas empresas tiveram a ideia de usá- -la para transações financeiras, como a compra de merca- dorias por cartões de crédito, transações bancárias on-line e mercado de capitais eletrônico. Essas aplicações criaram uma demanda por conexões seguras. Em 1995, a Netscape Communications Corp., que então dominava o mercado de fabricantes de navegadores, respondeu introduzindo um pacote de segurança chamado SSL (Secure Sockets Layer) para atender a essa demanda. Esse software e seu protocolo agora também são amplamente utilizados, por exemplo, por Firefox, Safari e Internet Explorer, e portanto vale a pena examiná-los com mais detalhes. O SSL constrói uma conexão segura entre dois soque- tes, incluindo: 1. negociação de parâmetros entre cliente e servidor. 2. autenticação mútua de cliente e servidor. 3. comunicação secreta. 4. proteção da integridade dos dados. Já vimos esses itens antes e, portanto, não há necessi- dade de desenvolvê-los. O posicionamento do SSL na pilha de protocolos ha- bitual é ilustrado na Figura 8.44. Efetivamente, trata-se de uma nova camada colocada entre a de aplicação e a de trans- porte, aceitando solicitações do navegador e enviando-as ao TCP para transmissão ao servidor. Depois que a conexão se- gura é estabelecida, a principal tarefa do SSL é manipular a compactação e a criptografia. Quando o HTTP é usado sobre SSL, ele se denomina HTTPS (Secure HTTP), embora seja o protocolo HTTP padrão. Às vezes, ele está disponível em uma nova porta (443), em lugar da porta-padrão (80). A propósito, SSL não se limita ao uso apenas com navegadores da Web, mas essa é sua aplicação mais comum. Ele também pode oferecer autenticação mútua. Nome de domínio Tempo de vida Classe Tipo Valor bob.com. 86400 IN A 36.1.2.3 bob.com. 86400 IN KEY 3682793A7B73F731029CE2737D... bob.com. 86400 IN SIG 86947503A8B848F5272E53930C... Tabela 8.4 z Um exemplo de RRSet para bob.com. O registro KEY é a chave pública de Bob. O registro SIG é o hash assinado do servidor com de nível superior dos registros A e KEY, a fim de verificar sua autenticidade. 08_tanen0809_cap08 BR.indd 534 4/25/11 3:08 PM
- 57. Capítulo 8 Segurança deredes 535 O protocolo SSL passou por várias versões. Descreve- remos apenas a versão 3, que é a mais utilizada. O SSL admite uma variedade de opções, que incluem a presença ou a ausência de compactação, os algoritmos criptográfi- cos a ser usados e algumas questões relativas a restrições de exportação impostas à criptografia. A última se destina principalmente a assegurar que a criptografia é utilizada apenas quando ambas as extremidades da conexão estão nos Estados Unidos. Em outros casos, as chaves serão limi- tadas a 40 bits, que os criptógrafos consideram uma piada. A Netscape foi forçada a colocar essa restrição para obter uma licença de exportação do governo dos Estados Unidos. O SSL consiste em dois subprotocolos, um para esta- belecer uma conexão segura e outro para usá-la. Vamos começar examinando como as conexões seguras são esta- belecidas. O subprotocolo de estabelecimento de conexões é mostrado na Figura 8.45. Ele começa com a mensagem 1, quando Alice envia uma solicitação a Bob para estabelecer uma conexão. A solicitação especifica a versão do SSL que Alice tem e suas preferências com relação aos algoritmos de compactação e de criptografia. Ela também contém um nonce RA , a ser usado mais tarde. Agora é a vez de Bob. Na mensagem 2, Bob escolhe entre os diversos algoritmos que Alice pode admitir e en- via seu próprio nonce, RB . Em seguida, na mensagem 3, ele envia um certificado contendo sua chave pública. Se esse certificado não for assinado por alguma autoridade conhecida, ele também envia uma cadeia de certificados que pode ser seguida de volta até chegar a uma autoridade original. Todos os navegadores, inclusive o de Alice, são pré-carregados com cerca de 100 chaves públicas; assim, se Bob puder estabelecer uma cadeia ancorada em uma dessas chaves, Alice será capaz de verificar a chave pública de Bob. Nesse momento, Bob pode enviar algumas outras mensagens (como uma solicitação do certificado de chave pública de Alice). Ao terminar, Bob envia a mensagem 4 para dizer a Alice que agora é a vez dela. Alice responde escolhendo ao acaso uma chave pré- -mestre aleatória de 384 bits e a envia para Bob, codifica- da com a chave pública de Bob (mensagem 5). A chave de sessão real usada para codificar os dados é derivada da cha- ve pré-mestre combinada com ambos os nonces de modo complexo. Depois que a mensagem 5 é recebida, Alice e Bob são capazes de calcular a chave de sessão. Por essa ra- zão, Alice informa a Bob que ele deve passar para a nova cifra (mensagem 6) e também que ela concluiu o subproto- colo de estabelecimento (mensagem 7). Bob então confir- ma as mensagens de Alice (mensagens 8 e 9). Aplicação (HTTP) Segurança (SSL) Transporte (TCP) Rede (IP) Enlace de dados (PPP) Física (modem, ADSL, TV a cabo) Figura 8.44 z Camadas (e protocolos) para um usuário doméstico navegando com SSL. Versão SSL, preferências, RA Versão SSL, escolhas, RB Cadeia de certificados X.509 Servidor pronto EB (chave pré-mestre) Muda cifra Terminado Muda cifra Terminado 9 7 8 Alice Bob 6 5 4 3 2 1 Figura 8.45 z Uma versão simplificada do subprotocolo de estabelecimento de conexões SSL. 08_tanen0809_cap08 BR.indd 535 4/25/11 3:08 PM
- 58. 536 Redes decomputadores Porém, embora Alice saiba quem é Bob, ele não sabe quem é Alice (a menos que ela tenha uma chave pública e um certificado correspondente, uma situação imprová- vel para um indivíduo). Portanto, a primeira mensagem de Bob pode ser uma solicitação para Alice se conectar usando um nome de login e uma senha estabelecidos anteriormen- te. No entanto, o protocolo de login está fora do escopo do SSL. Depois que ele é realizado por quaisquer meios, o transporte de dados pode se iniciar. Como mencionamos antes, o SSL admite vários algo- ritmos de criptografia. O mais forte usa o DES triplo com três chaves separadas para criptografia e com o SHA-1, a fim de manter a integridade das mensagens. Essa combi- nação é relativamente lenta, e assim é usada principalmen- te em aplicações bancárias e outras aplicações nas quais é exigida a mais alta segurança. Para aplicações comuns de comércio eletrônico, é usado o RC4 com uma chave de 128 bits para criptografia, e o MD5 é empregado para auten- ticação de mensagens. O RC4 utiliza a chave de 128 bits como semente e a expande até um número muito maior para uso interno. Em seguida, ele usa esse número interno para gerar um fluxo de chaves. O fluxo de chaves é subme- tido a uma operação XOR com texto simples para fornecer um fluxo de cifras clássico, como vimos na Figura 8.12. As versões de exportação também utilizam o RC4 com chaves de 128 bits, mas 88 dos bits são divulgados ao público para facilitar a violação da cifra. Para o transporte real, é usado um segundo subproto- colo, como mostra a Figura 8.46. Primeiro, as mensagens do navegador são divididas em unidades de até 16 KB. Se a compactação estiver ativa, cada unidade será então compactada em separado. Depois disso, uma chave secre- ta derivada dos dois nonces e da chave pré-mestre é con- catenada com o texto compactado, e o resultado passa por um hash com o algoritmo de hash combinado (normal- mente, o MD5). Esse hash é anexado a cada fragmento como o MAC. O fragmento compactado somado ao MAC é então codificado com o algoritmo de criptografia simé- trica estabelecido de comum acordo (em geral, por uma operação XOR entre ele e o fluxo de chaves do RC4). Por fim, é anexado o cabeçalho do fragmento que é transmi- tido pela conexão TCP. No entanto, é importante um alerta. Por ter sido mos- trado que o RC4 tem algumas chaves fracas, que podem ser facilmente criptoanalisadas, a segurança do SSL usando o RC4 é precária. (Fluhrer et al., 2001). Os navegadores que permitem ao usuário escolher o conjunto de cifras devem ser configurados para usar o DES triplo com chaves de 168 bits e o SHA-1 o tempo todo, embora essa combinação seja mais lenta que o RC4 e o MD5. Ou, melhor ainda, os usuá- rios devem fazer o upgrade para navegadores que ofereçam suporte ao sucessor do SSL, que descreveremos em breve. Um problema com o SSL é que os protagonistas não podem ter certificados e, mesmo que tenham, nem sempre verificam se as chaves que estão sendo usadas correspon- dem aos certificados. Em 1996, a Netscape Communica- tions Corp. submeteu o SSL à IETF para padronização. O resultado foi o TLS (Transport Layer Security), descrito na RFC 5246. O TLS foi embutido no SSL versão 3. As mudanças fei- tas no SSL foram relativamente pequenas, mas suficientes para o SSL versão 3 e o TLS não conseguirem interoperar. Por exemplo, o modo como a chave de sessão é derivada da chave pré-mestre e dos nonces mudou para tornar a chave mais forte (isto é, mais difícil de ser violada por criptoanáli- se). Devido à incompatibilidade, a maioria dos navegadores implementa os dois protocolos, com o TLS passando para SSL durante a negociação, se for necessário. Isso é conhecido Código de autenticação de mensagem Cabeçalho anexado Criptografia MAC anexado Compressão Fragmentação Parte 1 Parte 2 Mensagem do navegador Figura 8.46 z Transmissão de dados com SSL. 08_tanen0809_cap08 BR.indd 536 4/25/11 3:08 PM
- 59. Capítulo 8 Segurança deredes 537 como SSL/TLS. A primeira implementação do TLS apareceu em 1999 com a versão 1.2 definida em agosto de 2008. Ela inclui suporte para conjuntos de cifras mais fortes (princi- palmente AES). O SSL continuou sendo forte no mercado, embora o TLS provavelmente o substituísse aos poucos. 8.9.4 Segurança em código móvel A nomenclatura e as conexões são duas áreas de preo- cupação relacionadas à segurança da Web, mas existem outras. No início, quando as páginas Web eram apenas ar- quivos HTML estáticos, elas não continham código execu- tável. Agora, as páginas frequentemente contêm pequenos programas, inclusive miniaplicativos Java, controles Acti- veX e JavaScripts. Baixar e executar esse código móvel é sem dúvida um grande risco de segurança; por essa razão, foram criados vários métodos para minimizá-lo. Agora, ve- remos rapidamente algumas questões geradas pelo código móvel e algumas abordagens para lidar com ele. Segurança em miniaplicativos Java Os miniaplicativos (applets) Java são pequenos progra- mas em Java, compilados para uma linguagem de máquina orientada a pilhas de instruções (stacks), chamada JVM (Java Virtual Machine). Eles podem ser colocados em uma página Web para ser transferidos por download jun- tamente com a página. Depois que a página é carregada, os miniaplicativos são inseridos em um interpretador JVM no navegador, como ilustra a Figura 8.47. A vantagem de executar código interpretado sobre código compilado é que cada instrução é examinada pelo interpretador antes de ser executada. Isso dá ao interpreta- dor a oportunidade de verificar se o endereço da instrução é válido. Além disso, as chamadas do sistema também são capturadas e interpretadas. A forma como essas chamadas são manipuladas é um assunto relacionado à política de segurança. Por exemplo, se um miniaplicativo for confiável (como no caso de ele vir do disco local), suas chamadas do sistema poderão ser executadas sem questionamentos. Po- rém, se um miniaplicativo não for confiável (por exemplo, se veio da Internet), ele poderá ser encapsulado em uma caixa de brita (sandbox) para limitar seu comportamento e bloquear suas tentativas de usar recursos do sistema. Quando um miniaplicativo tenta usar um recurso do sistema, sua chamada é repassada a um monitor de segu- rança para aprovação. O monitor examina a chamada le- vando em conta a política de segurança local e depois toma a decisão de permiti-la ou rejeitá-la. Desse modo, é possível dar aos miniaplicativos acesso a alguns recursos, mas não a todos. Infelizmente, a realidade é que o modelo de segu- rança funciona mal e que os bugs que ele contém surgem o tempo todo. ActiveX Os controles ActiveX são programas binários do x86 que podem ser incorporados às páginas Web. Quando um deles é encontrado, é realizada uma verificação para saber se deve ser executado e, se passar no teste, assim é feito. Um controle ActiveX não é interpretado ou colocado em uma caixa de brita de forma alguma; portanto, tem tanto poder como qualquer outro programa do usuário e tem po- tencial para causar grandes danos. Desse modo, toda a se- gurança se resume à decisão de executar ou não o controle ActiveX. Concluindo, a ideia geral é um furo de segurança gigantesco. O método que a Microsoft escolheu para tomar essa decisão se baseia na ideia de assinatura de código. Cada controle ActiveX é acompanhado por uma assinatura digi- tal — um hash do código assinado por seu criador com o uso de criptografia de chave pública. Quando um controle ActiveX aparece, primeiro o navegador verifica a assinatu- ra para ter certeza de que ele não foi adulterado em trân- sito. Se a assinatura estiver correta, o navegador consulta suas tabelas internas para ver se o criador do programa é confiável, ou se existe uma cadeia de confiança que leve de volta até um criador confiável. Se o criador for confiável, o programa será executado; caso contrário, não. O sistema da Microsoft para verificar controles ActiveX é chamado Authenticode. E útil comparar as abordagens Java e ActiveX. Com a abordagem Java, não é feita nenhuma tentativa para deter- minar quem escreveu o miniaplicativo. Em vez disso, um interpretador runtime certifica-se de que ele não executa ações que o proprietário da máquina afirmou que os mi- niaplicativos não poderiam executar. Em contraste, no caso da assinatura de código, não é feita nenhuma tentativa de monitorar o comportamento de runtime do código móvel. Se veio de uma origem confiável e não foi modificado em trânsito, ele simplesmente é executado. Não há nenhuma tentativa de verificar se o código é malicioso ou não. Se era intenção do programador original criar um código que formatasse o disco rígido e depois apagasse a ROM flash Miniaplicativo não confiável Miniaplicativo confiável Navegador Web Caixa de brita Interpretador Espaço de endereço virtual 0xFFFFFFFF 0 Figura 8.47 z Os miniaplicativos podem ser interpretados por um navegador Web. 08_tanen0809_cap08 BR.indd 537 4/25/11 3:08 PM
- 60. 538 Redes decomputadores para que o computador nunca mais pudesse ser iniciado, isso não importa: se o programador foi certificado como confiável, o código será executado e destruirá o computa- dor (a menos que os controles ActiveX estejam desativados no navegador). Muitas pessoas têm receio de confiar em uma em- presa de software desconhecida. Para demonstrar o pro- blema, um programador em Seattle formou uma em- presa de software e conseguiu certificação como origem fidedigna, o que é fácil. Em seguida, desenvolveu um controle ActiveX que provocava um desligamento limpo da máquina e distribuiu amplamente seu controle Acti- veX. Ele desativou muitas máquinas, mas elas podiam simplesmente ser reiniciadas, e, portanto, não havia ne- nhum dano. O programador estava apenas tentando ex- por o problema ao mundo. A resposta oficial foi revogar o certificado para esse controle ActiveX, o que encerrou um breve episódio de forte embaraço, mas o problema subjacente ainda persiste, à espera de que um programa- dor terrível o explore (Garfinkel com Spafford, 2002). Tendo em vista que não há como policiar milhares de empresas de software que poderiam escrever código mó- vel, a técnica de assinatura de código é um desastre que pode ocorrer a qualquer momento. JavaScript O JavaScript não tem nenhum modelo de segurança formal, mas um longo histórico de implementações inse- guras. Cada fornecedor cuida da segurança de um modo diferente. Por exemplo, a versão 2 do Netscape Navigator usava algo similar ao modelo do Java mas, na versão 4, essa estratégia foi abandonada em favor de um modelo de assinatura de código. O problema fundamental é que permitir a execução de código estranho em sua máquina significa procurar problemas. Do ponto de vista da segurança, seria como convidar um assaltante a entrar em sua casa, e depois tentar observá-lo com cuidado para que ele não possa es- capar da cozinha para a sala de estar. Se acontecer algo inesperado e você estiver distraído por um momento, po- derão surgir consequências desastrosas. A tensão aqui é o fato de que o código móvel permite imagens gráficas atraentes e interação rápida, e muitos projetistas de sites acham que isso é muito mais importante que a segurança, especialmente quando é a máquina de outra pessoa que está correndo riscos. Extensões do navegador Além de estender as páginas Web com código, existe um mercado em explosão nas extensões do navegador, suplementos e plug-ins. Eles são programas de com- putador que estendem a funcionalidade dos navegadores Web. Os plug-ins normalmente oferecem a capacidade de interpretar ou exibir um certo tipo de conteúdo, como PDFs ou animações Flash. Extensões e suplementos ofe- recem novos recursos ao navegador, como melhor geren- ciamento de senhas ou formas de interagir com páginas, por exemplo, marcando-as ou facilitando a compra para itens relacionados. Instalar uma extensão, suplemento ou plug-in é tão simples quanto encontrar algo que você deseja ao navegar e selecionar o link para instalar o programa. Essa ação fará o código ser baixado pela Internet e instalado no navega- dor. Todos esses programas são escritos para frameworks que diferem dependendo do navegador que está sendo me- lhorado. Porém, de certa forma, eles se tornam parte da base de computação confiável do navegador. Ou seja, se o código que for instalado tiver bugs, o navegador inteiro pode ser comprometido. Também existem dois outros modos de falha óbvios. O primeiro é que o programa pode se comportar de for- ma maliciosa, por exemplo, reunindo informações pes- soais e enviando-as para um servidor remoto. Por tudo o que o navegador sabe, o usuário instalou a extensão exatamente para essa finalidade. O segundo problema é que os plug-ins dão ao navegador a capacidade de inter- pretar novos tipos de conteúdo. Frequentemente, esse conteúdo é uma linguagem de programação completa por si só. PDF e Flash são bons exemplos. Quando os usuários exibem páginas com conteúdo PDF ou Flash, os plug-ins em seu navegador estão executando o código PDF e Flash. É melhor que esse código seja seguro; cos- tuma haver vulnerabilidades que se pode explorar. Por todas essas razões, os suplementos e plug-ins só devem ser instalados se realmente forem necessários e apenas de fornecedores confiáveis. Vírus Os vírus são outra forma de código móvel. Porém, diferentemente dos exemplos anteriores, os vírus sempre chegam sem ser convidados. A diferença entre um vírus e o código móvel comum é que o vírus é desenvolvido para se reproduzir. Quando um vírus chega, através de uma pá- gina, de um anexo de correio eletrônico ou de algum outro modo, em geral ele começa infectando programas executá- veis no disco. Quando um desses programas é executado, o controle é transferido para o vírus, que, em geral, tenta se difundir para outras máquinas, por exemplo, envian- do cópias de si mesmo por correio eletrônico para todas as pessoas que têm seu nome no catálogo de endereços da vítima. Alguns vírus infectam o setor de inicialização do disco rígido; assim, quando a máquina é inicializada, o vírus é executado. Os vírus se tornaram um problema enorme na Internet e causam prejuízos de bilhões de dóla- res. Não existe nenhuma solução óbvia. Talvez uma nova geração de sistemas operacionais, inteiramente baseada em microkernels seguros e rígida divisão dos usuários, proces- sos e recursos em compartimentos estanques possa ajudar a resolver o problema. 08_tanen0809_cap08 BR.indd 538 4/25/11 3:08 PM
- 61. Capítulo 8 Segurança deredes 539 8.10 Questões sociais A Internet e sua tecnologia de segurança compoõem uma área para a qual convergem as questões sociais, a po- lítica pública e a tecnologia, não raro com enormes conse- quências. Apresentaremos a seguir um breve exame de três áreas: privacidade, liberdade de expressão e direito autoral. É desnecessário dizer que trataremos o assunto de manei- ra superficial. Para leitura adicional, consulte Anderson (2008a), Garfinkel com Spafford (2002) e Schneier (2004). A Internet também está repleta de material sobre o tema. Basta digitar palavras como ‘privacidade’, ‘censura’ e ‘direi- to autoral’ em qualquer mecanismo de pesquisa. 8.10.1 Privacidade As pessoas têm direito à privacidade? Boa pergunta. A Quarta Emenda da Constituição dos Estados Unidos proíbe o governo de realizar buscas na casa das pessoas, vasculhar seus documentos e seus bens sem uma boa razão, e con- tinua a restringir as circunstâncias sob as quais devem ser emitidos os mandados de busca. Desse modo, a privacidade é um direito público há mais de 200 anos, pelo menos nos Estados Unidos. O que mudou na última década foi a facilidade com que os governos podem espionar seus cidadãos e a facilida- de com que os cidadãos podem impedir tais atos de espio- nagem. No século XVIII, para o governo realizar buscas nos documentos de um cidadão, ele tinha de enviar um policial a cavalo até a sua fazenda, exigindo a apresentação de cer- tos documentos. Era um procedimento incômodo. Hoje em dia, as companhias telefônicas e os provedores da Internet fornecem prontamente grampos ao receber mandados de busca. Isso facilita a vida do policial e ele não corre o risco de cair do cavalo. A criptografia muda tudo isso. Qualquer pessoa que se dê ao trabalho de baixar e instalar o PGP e que utilize uma chave com força de alienígena bem protegida pode ter certeza de que ninguém no universo conhecido poderá ler sua correspondência de correio eletrônico, com ou sem mandado de busca. Os governos entendem bem esse pro- blema e não o apreciam. A privacidade real significa que é muito mais difícil seus agentes espionarem criminosos de todos os tipos, mas também é muito mais difícil espionar jornalistas e adversários políticos. Como resultado, alguns governos restringem ou proíbem o uso ou a exportação de criptografia. Por exemplo, na França, antes de 1999, toda criptografia era proibida, a menos que o governo recebesse as chaves. A França não estava só. Em abril de 1993, o governo dos Estados Unidos anunciou sua intenção de criar um crip- toprocessador em hardware, o clipper chip, o padrão para todas as comunicações em rede. Desse modo, diziam, a pri- vacidade dos cidadãos estaria garantida. Ele também men- cionava que o chip fornecia ao governo a possibilidade de decodificar todo tráfego por meio de um esquema chamado custódia de chaves, que permitia o acesso do governo a todas as chaves. No entanto, ele prometia só espiar quando tivesse um mandado de busca válido. Não é preciso dizer que o resultado foi uma enorme agitação, com os defensores da privacidade denunciando todo o plano e os promotores de justiça elogiando o esquema. Por fim, o governo voltou atrás e descartou a ideia. Há um grande volume de informações sobre privaci- dade eletrônica disponível no site da Electronic Frontier Foundation, em www.eff.org. Repostadores anônimos PGP, SSL e outras tecnologias tornam possível duas partes estabelecerem comunicação segura e autenticada, livre de vigilância e interferência de terceiros. Porém, às vezes a privacidade é mais bem servida quando não há autenticação, tornando a comunicação anônima. O anoni- mato pode ser interessante em mensagens ponto a ponto, newsgroups ou ambos. Vamos considerar alguns exemplos. Primeiro, dissiden- tes políticos que vivem em regimes autoritários muitas vezes desejam se comunicar de forma anônima para escapar da prisão ou de ser assassinados. Segundo, delitos em muitas organizações corporativas, educacionais, governamentais e outras frequentemente são expostos por delatores, que muitas vezes preferem permanecer anônimos para evitar represálias. Terceiro, pessoas com visões sociais, políticas ou religiosas impopulares podem desejar se comunicar umas com as outras por correio eletrônico ou newsgroups, sem se expor. Em quarto lugar, as pessoas podem desejar discutir alcoolismo, doenças mentais, abusos sexuais, pedofilia, ou ainda participar de um newsgroup formado por uma mino- ria perseguida sem ter de revelar sua identidade. É claro que existem vários outros exemplos. Vamos considerar um exemplo específico. Na década de 1990, alguns críticos de um grupo religioso não tra- dicional postaram suas opiniões em um newsgroup da USENET por meio de um repostador anônimo. Esse servidor permitiu que os usuários criassem pseudônimos e enviassem mensagens de correio eletrônico ao servidor, que então reencaminhava ou repostava as mensagens usando o pseudônimo; assim, ninguém poderia saber de onde a mensagem veio de fato. Algumas postagens revelavam que as afirmações do grupo religioso eram segredos comerciais e documentos protegidos por direitos autorais. O grupo religioso respon- deu informando às autoridades locais que seus segredos comerciais tinham sido descobertos e seus direitos auto- rais infringidos, o que é crime no local onde o servidor se encontrava. Seguiu-se um processo criminal e o operador do servidor foi compelido a entregar às autoridades as in- formações de mapeamento que revelavam as verdadeiras identidades das pessoas que tinham feito as postagens. (A propósito, essa não foi a primeira vez que um grupo religio- 08_tanen0809_cap08 BR.indd 539 4/25/11 3:08 PM
- 62. 540 Redes decomputadores so ficou insatisfeito porque alguém divulgou seus segredos: William Tyndale foi queimado na fogueira em 1536 por traduzir a Bíblia para o idioma inglês). Um segmento significativo da comunidade da Inter- net foi ultrajado por essa brecha de confidencialidade. Todos chegaram à conclusão de que um repostador anô- nimo que armazena um mapeamento entre endereços reais de correio eletrônico e pseudônimos (chamado re- postador do tipo 1) não vale a pena. Esse caso estimulou diversas pessoas a criar repostadores anônimos capazes de resistir a ataques por intimação. Esses novos repostadores, com frequência chama- dos repostadores cypherpunk, funcionam da maneira ilustrada a seguir. O usuário produz uma mensagem de correio eletrônico completa, com cabeçalhos RFC 822 (exceto From:, é claro), codifica a mensagem com a cha- ve pública do repostador e a envia ao repostador. Lá, os cabeçalhos RFC 822 externos são extraídos, o conteúdo é decodificado e a mensagem é repostada. O repostador não tem contas e não mantém nenhum log; assim, mes- mo que o servidor seja confiscado mais tarde, não con- servará nenhum traço de mensagens que tenham passa- do por ele. Muitos usuários que desejam anonimato encadeiam suas solicitações por vários repostadores anônimos, como mostra a Figura 8.48. Aqui, Alice deseja enviar a Bob um cartão pelo dia dos namorados (um cartão realmente anônimo) e para isso utiliza três repostado- res. Ela redige a mensagem, M, e insere um cabeçalho contendo endereço de correio eletrônico de Bob. Em seguida, codifica toda a mensagem com a chave pública do repostador 3, E3 (indicada na figura pela hachura horizontal). Para tanto, ela anexa um cabeçalho com o endereço de correio eletrônico do repostador 3 em texto simples. Essa é a mensagem mostrada entre os repostadores 2 e 3 na figura. Depois, Alice codifica a mensagem com a chave pú- blica do repostador 2, E2 (indicada pela hachura vertical) e acrescenta um cabeçalho de texto simples contendo o endereço de correio eletrônico do repostador 2. Essa mensagem é mostrada entre 1 e 2 na Figura 8.48. Por fim, ela codifica a mensagem inteira com a chave pública do repostador 1, E1 , e acrescenta um cabeçalho de texto simples com o endereço de correio eletrônico do reposta- dor 1. Essa é a mensagem mostrada à direita de Alice na figura e é a mensagem que ela de fato transmite. Quando a mensagem chega ao repostador 1, o cabe- çalho exterior é extraído. O corpo é decodificado e depois enviado por correio eletrônico para o repostador 2. Etapas semelhantes ocorrem nos outros dois repostadores. Embora seja extremamente difícil para alguém ras- trear a mensagem final de volta até Alice, muitos repos- tadores tomam precauções adicionais de segurança. Por exemplo, eles podem reter as mensagens por um período de tempo aleatório, adicionar ou remover lixo no fim de uma mensagem e ainda reordenar as mensagens, tudo para tornar mais difícil alguém descobrir que saída de mensagem de um repostador corresponde a cada entra- da, a fim de frustrar a análise de tráfego. Para ver a des- crição de um sistema que representa o estado da arte em correio eletrônico anônimo, consulte Mazières e Ka- ashoek (1998). O anonimato não se restringe ao correio eletrôni- co. Também existem serviços que permitem a navegação anônima na Web usando a mesma forma de caminho em camadas, em que um nó só conhece o próximo nó na ca- deia. Esse método é chamado roteamento cebola, pois cada nó descasca outra camada para determinar para onde encaminhar o pacote seguinte. O usuário configura seu navegador para usar o serviço anonymizer como um proxy. Tor é um exemplo bem conhecido de tal sistema (Dingledine et al., 2004). Daí em diante, todas as solici- tações HTTP vão para o anonymizer, que solicita a página e a devolve. O site vê um nó de saída do anonymizer como a origem da solicitação, não o usuário. Tendo em vista que a rede do anonymizer se recusa a manter um log, depois do fato ninguém pode determinar quem soli- citou cada página. Alice Bob 1 Para 1 2 3 Para 2 Repostador anônimo Criptografado com E1 Criptografado com E2 Criptografado com E3 Para Bob Para 3 M Para Bob M Para 3 Para Bob M Para 3 Para 2 Para Bob M Figura 8.48 z Como Alice utiliza 3 repostadores para enviar uma mensagem a Bob. 08_tanen0809_cap08 BR.indd 540 4/25/11 3:08 PM
- 63. Capítulo 8 Segurança deredes 541 8.10.2 Liberdade de expressão A privacidade se relaciona a indivíduos que desejam restringir o que outras pessoas podem ver sobre eles. Uma segunda questão social importante é a liberdade de expres- são e sua oponente, a censura, relacionada com o fato de órgãos governamentais desejarem restringir o que os indi- víduos podem ler e publicar. Contendo milhões e milhões de páginas, a Web se tornou um paraíso para o censor. De- pendendo da natureza e da ideologia do regime, o mate- rial proibido pode incluir sites que contêm quaisquer dos seguintes itens: 1. material impróprio para crianças ou adolescentes; 2. ódio que tem como alvos vários grupos étnicos, re- ligiosos, sexuais ou outros; 3. informações sobre democracia e valores democráti- cos; 4. relatos de eventos históricos que contradizem a ver- são do governo; 5. manuais de arrombamento, montagem de armas, codificação de mensagens etc. A justificativa habitual é proibir os sites considerados ‘maus’. Às vezes, os resultados são inesperados. Por exemplo, algumas bibliotecas públicas instalaram filtros da Web em seus computadores, a fim de torná-los amigáveis para as crianças, bloqueando sites de pornografia. Os filtros vetam os sites contidos em suas listas negras, mas também exami- nam páginas em busca de palavras obscenas antes de exibi- -las. No condado de Loudoun, estado da Virgínia, o filtro bloqueou a busca de informações sobre câncer de mama, porque o filtro encontrou a palavra ‘mama’. O patrono da biblioteca processou o condado de Loudoun. Porém, em Livermore, Califórnia, um pai processou a biblioteca pú- blica por não instalar um filtro depois que seu filho de 12 anos foi pego vendo um site de pornografia. O que uma biblioteca pode fazer? Muitas pessoas não percebem que a World Wide Web é de fato uma teia mundial e, portanto, abrange o mundo inteiro. Nem todos os países concordam sobre o que deve ser permitido na Web. Por exemplo, em novembro de 2000, um tribunal francês pediu ao Yahoo! — uma corporação da Califórnia — para impedir que usuários franceses visualizas- sem leilões de lembranças nazistas no site porque a posse de tal material infringe a lei francesa. O Yahoo apelou a um tribunal dos Estados Unidos que o apoiou, mas a questão das leis que se aplicam a cada país está longe de ser definida. Imagine estas situações: o que aconteceria se algum tribunal em Utah instruísse a França a bloquear sites que lidassem com vinhos, porque eles não concordam com as leis rigorosíssimas do estado de Utah sobre bebidas alcoóli- cas? E se a China exigisse que todos os sites sobre democra- cia fossem proibidos por não ser de interesse do Estado? As leis iranianas sobre religião se aplicam à liberal Suécia? A Arábia Saudita pode bloquear sites que tratam dos direitos das mulheres? A questão inteira é uma verdadeira caixa de Pandora. Um comentário relevante de John Gilmore é: “A rede interpreta a censura como algo danoso e procura contorná- -la”. Para ver uma implementação concreta, considere o serviço eternity (Anderson, 1996). Seu objetivo é assegu- rar que informações publicadas não poderão ser retiradas de circulação ou reescritas, como era comum na União So- viética durante o regime de Josef Stalin. Para usar o serviço eternity, o usuário especifica quanto tempo o material deve ser preservado, paga uma taxa proporcional à sua duração e ao tamanho, e o transfere por upload. Daí em diante, nin- guém poderá removê-lo ou editá-lo, nem mesmo o próprio usuário que fez o upload. Como tal serviço poderia ser implementado? O mo- delo mais simples é usar um sistema não hierárquico, no qual os documentos armazenados seriam colocados em dezenas de servidores participantes, cada um dos quais re- ceberia uma fração da tarifa, e portanto um incentivo para se unir ao sistema. Os servidores devem estar espalhados por muitas jurisdições legais, a fim de proporcionar a má- xima resiliência. Listas de dez servidores selecionados ao acaso seriam armazenadas com segurança em vários lu- gares; assim, se alguma delas fosse comprometida, ainda existiriam outras. Uma autoridade disposta a destruir o documento nunca poderia ter certeza de haver encon- trado todas as cópias. O sistema também poderia ser ela- borado para reparação automática: caso algumas cópias fossem destruídas, os sites restantes tentariam encontrar novos repositórios para substituí-las. O serviço eternity foi a primeira proposta de um sis- tema resistente à censura. Desde então, outros esquemas foram propostos e, em alguns casos, implementados. Di- versas características novas foram acrescentadas, como criptografia, anonimato e tolerância a falhas. Com frequên- cia, os arquivos a ser armazenados são divididos em vários fragmentos, com cada fragmento armazenado em muitos servidores. Alguns desses sistemas são o Freenet (Clarke et al., 2002), PASIS (Wylie et al., 2000) e Publius (Wald- man et al., 2000). Outro trabalho é relatado em Serjantov (2002). Muitos países procuram cada vez mais regulamentar a exportação de itens intangíveis, o que em geral inclui sites, software, artigos científicos, correio eletrônico, assistência técnica por telefone e outros. Até mesmo o Reino Unido, com uma tradição de séculos de liberdade de expressão, agora considera seriamente leis bastante restritivas que, por exemplo, definiriam discussões técnicas entre um pro- fessor britânico e seu aluno estrangeiro na University of Cambridge como uma forma de exportação regulamentada que necessita de uma licença governamental (Anderson, 2002). É desnecessário dizer que tal política é absurda. 08_tanen0809_cap08 BR.indd 541 4/25/11 3:08 PM
- 64. 542 Redes decomputadores Esteganografia Em países onde a censura é abundante, os dissidentes com frequência tentam usar a tecnologia para burlar sua rigidez. A criptografia permite que mensagens secretas se- jam enviadas (embora talvez isso não seja legal); porém, se o governo imaginar que Alice é uma pessoa nociva, o mero fato de ela se comunicar com Bob pode incluí-lo nes- sa categoria, pois governos repressivos entendem o concei- to de fechamento transitivo, ainda que não tenham muitos matemáticos entre eles. Os repostadores anônimos podem ajudar, mas, se forem proibidos internamente e as mensa- gens para o exterior exigirem uma licença de exportação do governo, eles não serão muito úteis. No entanto, a Web pode ser de grande auxílio. Com frequência, as pessoas que desejam se comunicar secretamente tendem a ocultar o fato de haver qualquer comunicação. A ciência de ocultar mensagens é chamada esteganografia, das palavras gregas que correspondem a ‘escrita cifrada’. Na verdade, os próprios gregos antigos a utilizavam. Heródoto escreveu sobre um general que ras- pou a cabeça de um mensageiro, tatuou uma mensagem em seu couro cabeludo e deixou o cabelo crescer de novo antes de enviá-lo ao destino. As técnicas modernas são conceitualmente as mesmas, apenas com uma largura de banda mais alta e uma latência mais baixa (e não exigem os serviços de um barbeiro). Um caso interessante é o da Figura 8.49(a). Essa fo- tografia, tirada pelo autor no Quênia, contem três zebras contemplando uma acácia. A Figura 8.49(b) parece ter exa- tamente as mesmas três zebras e a acácia, mas, além disso, ela tem uma atração a mais. A segunda fotografia contém o texto completo de cinco peças de Shakespeare incorpora- do: Hamlet, Rei Lear, Macbeth, O mercador de Veneza e Julio Cé- sar. Juntas, essas peças totalizam mais de 700 KB de texto. Como funciona esse canal esteganográfico? A imagem em cores original tem 1024 × 768 pixels. Cada pixel consis- te em três números de 8 bits, cada um representando a in- tensidade de uma das cores, vermelha, verde e azul, desse pixel. A cor do pixel é formada pela superposição linear das três cores. O método de codificação esteganográfico utiliza o bit de baixa ordem de cada valor de cor RGB como um canal oculto. Desse modo, cada pixel tem espaço para 3 bits de informações secretas, um no valor vermelho, um no valor verde e um no valor azul. Com uma imagem desse tamanho, podem ser armazenados até 1024 × 768 × 3 bits, ou 294.912 bytes de informações secretas. O texto completo das cinco peças e uma peque- na nota chegam a 734.891 bytes. Primeiro, o texto foi compactado para cerca de 274 KB com um algoritmo de compactação-padrão. A saída compactada foi então crip- tografada com o uso do IDEA e inserida nos bits de bai- xa ordem de cada valor de cor. Como podemos ver (ou melhor, como não podemos ver), a existência das infor- mações é completamente invisível. Elas são igualmente invisíveis na versão ampliada e em cores da fotografia. O olho não consegue distinguir com facilidade entre cores de 21 bits e cores de 24 bits. Para usar a esteganografia na comunicação não detec- tada, os dissidentes poderiam criar um site repleto de ima- gens politicamente corretas, como fotografias do Grande Líder, esportes locais, filmes e estrelas de televisão etc. É claro que as figuras estariam recheadas de mensagens este- ganográficas. Se as mensagens fossem primeiro compacta- das e depois criptografadas, mesmo que alguém suspeitasse de sua presença, teria imensa dificuldade para distinguir as mensagens de ruído branco. É lógico que as imagens devem ser novas; copiar uma figura da Internet e alterar alguns bits é um segredo inútil. As imagens não são de forma alguma o único tipo de su- porte para mensagens esteganográficas. Informações ocultas podem ser transportadas em uma chamada de Voice over IP manipulando os atrasos de pacote, distorcendo o áudio ou Figura 8.49 z (a) Três zebras e uma árvore. (b) Três zebras, uma árvore e o texto completo de cinco peças de William Shakespeare. 08_tanen0809_cap08 BR.indd 542 4/25/11 3:08 PM
- 65. Capítulo 8 Segurança deredes 543 ainda nos campos de cabeçalho dos pacotes (Lubacz et al., 2010). Até mesmo o layout e a ordenação de tags em um arquivo HTML podem transportar informações. Embora tenhamos examinado a esteganografia no contexto da liberdade de expressão, ela tem vários outros usos. Um uso comum permite que os proprietários de ima- gens codifiquem mensagens secretas nessas imagens, de- clarando seus direitos de propriedade. Se tal imagem for roubada e colocada em um site, o dono legal poderá re- velar a mensagem esteganográfica no tribunal para provar a quem pertence. Essa técnica é conhecida como marca d’água. Ela é descrita em Piva et al. (2002). Para obter mais informações sobre a esteganografia, consulte Wayner (2008). 8.10.3 Direitos autorais A privacidade e a censura são apenas duas áreas nas quais a tecnologia encontra a política pública. O direito autoral significa a concessão aos criadores de IP (Intel- lectual Property), incluindo escritores, artistas, composi- tores, músicos, fotógrafos, cineastas, coreógrafos e outros, do direito exclusivo de explorar sua IP por certo período de tempo, em geral durante a vida do autor somada a 50 anos ou 75 anos, no caso da propriedade corporativa. De- pois de expirar o período de proteção pelos direitos autorais de uma obra, ela passa para o domínio público e qualquer pessoa pode usá-la ou vendê-la como desejar. Por exemplo, o Projeto Gutenberg (www.promo.net/pg) colocou milha- res de obras de domínio público (por exemplo, obras de Shakespeare, Twain, Dickens) na Web. Em 1998, a pedido de Hollywood, o Congresso dos Estados Unidos estendeu os direitos autorais nos EUA por mais 20 anos. O pessoal do cinema alegava que, sem uma extensão desse período, nin- guém criaria mais nada. Em contraste, as patentes duram apenas vinte anos e, mesmo assim, as pessoas não param de apresentar novas invenções. A discussão sobre os direitos autorais ganhou espaço quando o Napster, um serviço de troca de obras musicais, alcançou 50 milhões de membros. Embora o Napster real- mente não copiasse nenhuma música, os tribunais susten- taram que manter um banco de dados central de quem ti- nha uma cópia de cada música era infração contribuinte, isto é, ele ajudava outras pessoas a infringir a lei. Apesar de ninguém afirmar que os direitos autorais sejam má ideia (embora muitos reclamem que o processo é muito longo, favorecendo assim as grandes empresas em detrimento do público), a próxima geração de compartilhamento de músi- ca já está levantando questões éticas importantes. Por exemplo, considere uma rede não hierárquica em que pessoas compartilham arquivos legais (música de do- mínio público, vídeos domésticos, tratados religiosos que não representem segredos comerciais etc.) e talvez alguns deles sejam protegidos por direitos autorais. Suponha que todas essas pessoas estejam on-line o tempo todo, por meio de ADSL ou cabo. Cada máquina tem um índice do que está no disco rígido, além de uma lista de outros membros. Alguém que procurar um item específico pode escolher um membro ao acaso e ver se ele tem o item. Caso contrário, a pessoa pode procurar o item em todos os membros da lista desse primeiro membro, e depois em todos os membros das listas desses outros membros, e assim por diante. Os com- putadores são muito bons nesse tipo de trabalho. Tendo encontrado o item, o solicitante simplesmente o copia. Se o trabalho estiver protegido por direitos autorais, as chances são de que o solicitante esteja infringindo a lei (embora, no caso de transferências internacionais, não esteja claro que lei deve ser aplicada). Entretanto, como classificar o fornecedor? É crime manter em seu disco rígi- do uma música pela qual você pagou e baixou legalmente, apenas porque outras pessoas podem encontrá-la? Se você tem uma cabana no campo e um ladrão de IP invade sua cabana levando um notebook e um scanner, copia um livro protegido por direitos autorais e escapa sorrateiramente, você é culpado do crime de deixar de proteger os direitos autorais de outra pessoa? No entanto, existem mais dificuldades nessa área. Há uma grande batalha entre Hollywood e a indústria de in- formática. Hollywood deseja a proteção rígida de toda a propriedade intelectual, e a indústria de informática não quer ser a polícia a serviço de Hollywood. Em outubro de 1998, o Congresso norte-americano aprovou o DMCA (Digital Millennium Copyright Act), que torna crime frustrar qualquer mecanismo de proteção presente em uma obra protegida por direitos autorais ou informar outras pes- soas sobre como lográ-lo. Legislação semelhante está sur- gindo na União Europeia. Embora quase ninguém pense que piratas do Extremo Oriente devam ter permissão para duplicar obras protegidas, muitas pessoas imaginam que o DMCA desloca completamente o equilíbrio entre o interes- se do detentor dos direitos autorais e o interesse público. Vejamos um exemplo prático. Em setembro de 2000, um consórcio da indústria da música encarregado de elabo- rar um sistema inviolável para venda de obras musicais on- -line patrocinou um concurso convidando pessoas a tentar violar o sistema (exatamente o que deve ser feito no caso de qualquer sistema de segurança novo). Pesquisadores da área de segurança provenientes de várias universidades for- maram uma equipe, liderada pelo professor Edward Felten de Princeton, que aceitou o desafio e conseguiu quebrar o sistema. Em seguida, eles escreveram um artigo sobre suas descobertas e o submeteram a uma conferência de seguran- ça do USENIX, em que esse artigo passou por uma revisão e foi aceito. Antes de apresentar seu trabalho, Felten recebeu uma carta da Recording Industry Association of America que ameaçava processar os autores com base no DMCA 08_tanen0809_cap08 BR.indd 543 4/25/11 3:08 PM
- 66. 544 Redes decomputadores se eles publicassem o artigo. A resposta dos pesquisado- res foi abrir um processo pedindo que um tribunal federal decidisse se a publicação de documentos científicos sobre pesquisas na área de segurança ainda era legal. Temendo uma decisão definitiva dos tribunais contra ela, a indústria retirou sua ameaça e o tribunal rejeitou a ação de Felten. Sem dúvida, os fabricantes de discos foram motivados pela fragilidade de sua posição: eles haviam convidado pesso- as a tentar violar seu sistema, e depois ameaçaram pro- cessar algumas delas por aceitar o desafio. Com a ameaça retirada, o ensaio foi publicado (Craver et al., 2001). Uma nova disputa é quase certa. Enquanto isso, música e filmes pirateados alimenta- ram o crescimento maciço das redes peer-to-peer. Isso não agradou as mantenedores de direito autoral, que usavam o DMCA para tomar ações. Atualmente, existem sistemas automatizados que procuram redes peer-to-peer e depois disparam avisos para operadores de rede e usuários que são suspeitos de infringir direitos autorais. Nos Estados Unidos, esses avisos são conhecidos como notas de desativação do DMCA. Essa busca é uma corrida de braços, pois é difí- cil apanhar infratores de direitos autorais de modo confiá vel. Até mesmo seu tipógrafo poderia ser confundido com um criminoso (Piatek et al., 2008). Uma questão relacionada a essa é a extensão da dou- trina de uso legal, estabelecida por decisões judiciais em vários países. Essa doutrina afirma que os compradores de uma obra protegida por direitos autorais têm certos direitos limitados de copiar a obra, inclusive o direito de citar partes dela para fins científicos, usá-la como material didático em escolas ou faculdades e, em alguns casos, criar cópias de re- serva para uso pessoal no caso de falha do meio original. Os testes para definir o que constitui uso legal incluem (1) se o uso é comercial, (2) que porcentagem do todo está sendo copiada e (3) o efeito da cópia sobre as vendas da obra. Tendo em vista que o DMCA e leis semelhantes dentro da União Europeia proíbem frustrar os esquemas de proteção contra cópia, essas leis também proíbem o uso legal. Na realidade, o DMCA prejudica os direitos históricos dos usuários para dar mais poder aos vendedores de conteúdo. É inevitável um confronto. Outro desenvolvimento na área que reduz a importân- cia até mesmo do DMCA em seu deslocamento do equilí- brio entre os detentores de direitos autorais e os usuários é a computação confiável, defendida por setores da indús- tria como o TCG (Trusted Computing Group), liderado por empresas como Intel e Microsoft. A ideia é oferecer su- porte para monitoramento cuidadoso do comportamento do usuário em diversos aspectos (por exemplo, reprodução de música pirateada) em um nível abaixo do sistema ope- racional, a fim de proibir o comportamento indesejável. O sistema permite que o software escrito por detentores de conteúdo manipule PCs de maneiras que os usuários não possam mudar. Isso levanta a questão de quem é confiável na confiável computação. Certamente, não é o usuário. É desnecessário dizer que as consequências sociais desse es- quema são imensas. É ótimo que a indústria esteja final- mente prestando atenção à segurança, mas é lamentável que ela esteja inteiramente voltada para impor a lei de di- reitos autorais, em vez de lidar com vírus, crackers, intru- sos e outras questões de segurança com as quais a maioria das pessoas está preocupada. Em resumo, os legisladores e juristas estarão ocupa- dos tentando equilibrar os interesses econômicos dos pro- prietários de direitos autorais com o interesse público nos próximos anos. O espaço virtual não é diferente do espa- ço físico: ele constantemente joga um grupo contra outro, resultando em lutas pelo poder, litígio e (esperamos) por fim algum tipo de resolução, pelo menos até surgir alguma nova tecnologia capaz de resolver a situação. 8.11 Resumo A criptografia é uma ferramenta que pode ser usada para manter informações confidenciais e garantir sua in- tegridade e autenticidade. Todos os sistemas criptográficos modernos se baseiam no principio de Kerckhoff de um algoritmo publicamente conhecido e uma chave secre- ta. Muitos algoritmos criptográficos usam transformações complexas que envolvem substituições e permutações para transformar o texto simples em texto cifrado. Porém, se a criptografia quântica puder se tornar prática, o uso de blo- cos de uma única vez poderá fornecer sistemas criptográfi- cos verdadeiramente invioláveis. Os algoritmos criptográficos podem ser divididos como de chave simétrica e de chave pública. Os algoritmos de chave simétrica desfiguram os bits em uma série de rodadas parametrizados pela chave para transformar o texto sim- ples no texto cifrado. AES (Rijndael) e o DES triplo são os algoritmos de chave simétrica mais populares no mo- mento. Esses algoritmos podem ser usados no modo livro de códigos eletrônicos, modo blocos de cifras encadeados, modo fluxo de cifra, modo contador e outros. Nos algoritmos de chave pública, são usadas chaves di- ferentes para codificação e decodificação, e a chave de deco- dificação não pode ser derivada a partir da chave de codifi- cação. Essas propriedades tornam possível divulgar a chave pública. O principal algoritmo de chave pública é o RSA, cuja força deriva da grande dificuldade de fatorar números muito grandes. Documentos legais, comerciais e outros precisam ser assinados. Consequentemente, foram criados vários es- quemas de assinaturas digitais, empregando algoritmos de chave simétrica e algoritmos de chave pública. Em geral, as mensagens que devem ser assinadas são submetidas a um hash com a utilização de algoritmos como SHA-1, e então o hash é assinado em lugar das mensagens originais. O gerenciamento de chaves públicas pode ser imple- mentado com o emprego de certificados, documentos que 08_tanen0809_cap08 BR.indd 544 4/25/11 3:08 PM
- 67. Capítulo 8 Segurança deredes 545 vinculam um protagonista a uma chave pública. Os certi- ficados são assinados por uma autoridade confiável ou por alguém aprovado (recursivamente) por uma autoridade confiável. A raiz da cadeia tem de ser obtida com antece- dência, mas os navegadores em geral têm muitos certifica- dos de raiz embutidos. Essas ferramentas criptográficas podem ser usadas para proteger o tráfego de rede. O IPsec opera na camada de rede, codificando fluxos de pacotes de host para host. Os firewalls podem efetuar a triagem do tráfego que entra ou sai de uma organização, muitas vezes com base no proto- colo e na porta utilizados. As redes privadas virtuais podem simular uma antiga rede dedicada para oferecer certas pro- priedades de segurança desejáveis. Por fim, as redes sem fios precisam de uma boa segurança a fim de evitar que mais alguém leia todas as mensagens, e protocolos como 802.11i oferecem isso. Quando duas partes estabelecem uma sessão, elas têm de autenticar uma à outra e, se necessário, estabelecer uma chave de sessão compartilhada. Existem diversos protoco- los de autenticação, incluindo alguns que usam uma tercei- ra parte confiável, Diffie-Hellman, Kerberos e criptografia de chave pública. A segurança de correio eletrônico pode ser alcançada por uma combinação das técnicas que estudamos neste ca- pítulo. Por exemplo, o PGP compacta as mensagens, depois as codifica usando uma chave secreta e envia essa chave codificada com a chave pública do receptor. Além disso, ele também efetua o hash da mensagem e envia o hash assina- do para confirmar a integridade da mensagem. A segurança da Web também é um tópico importante, começando com a nomenclatura segura. O DNSsec ofere- ce um modo de evitar o DNS spoofing, bem como realizar a certificação automática de nomes. A maioria dos sites de comércio eletrônico na Web utiliza SSL/TLS para esta- belecer sessões autenticadas e seguras entre o cliente e o servidor. São usadas várias técnicas para lidar com código móvel, em especial caixas de brita e assinatura de código. A Internet levanta muitas questões em que a tecno- logia interage fortemente com a política pública. Algumas áreas relevantes incluem privacidade, liberdade de expres- são e direitos autorais. Problemas 1. Resolva a cifra monoalfabética a seguir. O texto simples, formado apenas por letras, é um trecho de um conhecido poema de Lewis Carroll. mvyy bek mnyx n yvjjyr snijrh invq n muvjvdt je n idnvy jurhri n fehfevir pyeir oruvdq ki ndq uri jhrnqvdt ed zb jnvy Irr uem rntrhyb jur yeoijrhi ndq jur jkhjyri nyy nqlndpr Jurb nhr mnvjvdt ed jur iuvdtyr mvyy bek pezr ndq wevd jur qndpr mvyy bek, medj bek, mvyy bek, medj bek, mvyy bek wevd jur qndpr mvyy bek, medj bek, mvyy bek, medj bek, medj bek wevd jur qndpr 2. Uma cifra afim é uma versão de uma cifra de substitui- ção monoalfabética, em que as letras de um alfabeto de tamanho m são primeiro mapeadas para os inteiros no in- tervalo de 0 a m - 1. Na sequência, o inteiro represen- tando cada letra em texto simples é transformado em um inteiro representando a letra correspondente no texto. A função de codificação para uma única letra é E(x) = (ax + b) mod m, onde m é o tamanho do alfabeto e a e b são a chave da cifra, e são primos entre si. Trudy descobre que Bob gerou um texto cifrado usando uma cifra afim. Ela apanha uma cópia do texto cifrado e descobre que a letra mais frequente do texto cifrado é ‘R’, e a segunda letra mais frequente do texto cifrado é ‘K’. Mostre como Trudy pode quebrar o código e recuperar o texto simples. 3. Resolva a seguinte cifra de transposição de colunas. O tex- to simples foi extraído de um livro sobre computadores; portanto, ‘computer’ é uma palavra muito provável. O texto simples é formado apenas por letras (sem espaços). O texto cifrado está dividido em blocos de cinco caracteres para proporcionar melhor legibilidade. aauan cvlre rurnn dltme aeepb ytust iceat npmey iicgo gorch srsoc nntii imiha oofpa gsivt tpsit lbolr otoex 4. Alice usou uma cifra de transposição para codificar suas mensagens para Bob. Para aumentar a segurança, ela criptografou a chave da cifra de transposição usando uma cifra de substituição e manteve a cifra criptografada em seu computador. Trudy conseguiu se apossar da chave da cifra de transposição criptografada. Poderá ela decifrar as mensagens de Alice para Bob? Por quê? 5. Encontre um bloco de 77 bits que gere o texto ‘Hello World’ a partir do texto cifrado da Figura 8.3. 6. Você é um espião e, de modo conveniente, tem uma bi- blioteca com um número infinito de livros à sua disposi- ção. Seu operador também tem essa biblioteca à dispo- sição. Você concordou em usar o Senhor dos Anéis como uma chave única. Explique como você poderia usar esses recursos para gerar uma chave única infinitamente longa. 7. A criptografia quântica exige uma pistola de fótons que possa, por demanda, disparar um único fóton transpor- tando 1 bit. Neste problema, calcule quantos fótons um bit transporta em um enlace de fibra de 250 Gbps. Su- ponha que o comprimento de um fóton seja igual a seu comprimento de onda que, para fins deste problema, é 1 micron. A velocidade da luz na fibra é 20 cm/ns. 8. Se Trudy capturar e regenerar fótons quando a criptogra- fia quântica estiver em uso, ela obterá alguns fótons erra- dos e provocará o surgimento de erros na chave única de Bob. Em média, que fração dos bits do bloco de uma só vez de Bob estarão errados? 08_tanen0809_cap08 BR.indd 545 4/25/11 3:08 PM
- 68. 546 Redes decomputadores 9. Um princípio criptográfico fundamental estabelece que todas as mensagens devem ter redundância. Porém, tam- bém sabemos que a redundância ajuda um intruso a saber se uma chave hipotética está correta. Considere duas for- mas de redundância. Primeiro, os n bits iniciais do texto simples contêm um padrão conhecido. Segundo, os n bits finais da mensagem contêm um hash sobre a mensagem. Do ponto de vista da segurança, essas duas alternativas são equivalentes? Comente sua resposta. 10. Na Figura 8.5, as caixas P e S se alternam. Apesar da apa- rência esteticamente agradável dessa organização, não seria mais seguro primeiro ter todas as caixas P e depois todas as caixas S? Comente sua resposta. 11. Projete um ataque ao DES baseado no conhecimento de que o texto simples é formado exclusivamente por letras ASCII em caixa alta, além de espaço, vírgula, ponto, pon- to e vírgula, retorno de cursor e avanço de linha. Nada é conhecido sobre os bits de paridade do texto simples. 12. No texto, calculamos que uma máquina de análise de ci- fras com um milhão de processadores que pudesse anali- sar uma chave em 1 nanossegundo demoraria apenas 1016 anos para quebrar a versão de 128 bits do AES. Vamos calcular quanto tempo levará desta vez para reduzir para 1 ano, o que, logicamente, ainda é muito tempo. Para conseguir isso, precisamos que os computadores sejam 1016 vezes mais rápidos. Se a lei de Moore (a potência de computação duplica a cada 18 meses) continuar a ser vá- lida, quantos anos serão necessários até que um compu- tador paralelo possa reduzir o tempo de quebra da senha para um ano? 13. O AES admite uma chave de 256 bits. Quantas chaves tem o AES-256? Veja se é possível encontrar algum número em física, química ou astronomia com aproximadamente o mesmo tamanho. Use a Internet para ajudá-lo a procurar números grandes. Tire uma conclusão de sua pesquisa. 14. Suponha que uma mensagem tenha sido criptografada com a utilização do DES no modo de contador. Um bit do texto cifrado no bloco Ci é acidentalmente transformado de 0 para 1 durante a transmissão. Quanto do texto sim- ples será adulterado em decorrência disso? 15. Agora, considere o encadeamento de blocos de texto ci- frado. Em vez de um único bit 0 ser transformado em um bit 1, um bit 0 extra é inserido no fluxo de texto cifrado depois do bloco Ci . Que proporção do texto simples será adulterado em decorrência disso? 16. Compare o encadeamento de blocos de cifras com o modo de feedback de cifra no que se refere ao número de operações necessárias para a transmissão de um arquivo muito grande. Qual dos dois é o mais eficiente e em que proporção? 17. Usando o sistema de criptografia de chave pública RSA, com a = 1, b = 2 ... y = 25, z = 26. (a) Se p = 5 e q = 13, cite cinco valores válidos para d. (b) Se p = 7 e q = 11, cite cinco valores válidos para d. (c) Usando p = 5, q = 11 e d = 9, encontre e e criptografe “hello”. 18. Alice e Bob usam a criptografia de chave privada RSA para se comunicarem. Trudy descobre que Alice e Bob compartilharam um dos primos usados para determinar o número n de seus pares de chave pública. Em outras palavras, Trudy descobriu que na = pa × q e nb = pb × q. Como Trudy pode usar essa informação para quebrar o código de Alice? 19. Considere o uso do modo de contador, como mostra a Figura 8.13, mas com IV = 0. O uso de 0 ameaça a segu- rança da cifra em geral? 20. Na Figura 8.17, vemos como Alice pode enviar a Bob uma mensagem assinada. Se Trudy substituir P, Bob poderá descobrir. No entanto, o que acontecerá se Trudy substi- tuir ao mesmo tempo P e a assinatura? 21. As assinaturas digitais têm uma deficiência potencial de- vido a usuários preguiçosos. Em transações de comér- cio eletrônico, um contrato poderia ser interrompido e o usuário poderia ser solicitado a assinar seu hash SHA-1. Se o usuário não verificar realmente que o con- trato e o hash correspondem, ele poderá assinar inad- vertidamente um contrato diferente. Suponha que a Máfia tente explorar essa fraqueza para ganhar algum dinheiro. Os mafiosos configuram um site com paga- mento (por exemplo, pornografia, jogo etc.) e pedem aos novos clientes um número de cartão de crédito. Em seguida, enviam um contrato ao cliente confirmando que este deseja usar seus serviços e que pagará com o cartão de crédito; depois, solicitam que o cliente as- sine o contrato, sabendo que a maioria dos clientes simplesmente assinará sem verificar se o contrato e o hash coincidem. Mostre como a Máfia pode comprar diamantes pela Internet de um joalheiro legítimo e de- bitá-los de clientes desatentos. 22. Uma turma de matemática tem 20 alunos. Supondo que todos os nasceram no primeiro semestre do ano — entre 1 de janeiro e 30 de junho —, qual é a probabilidade de pelo menos dois alunos fazerem aniversário no mesmo dia? Suponha que ninguém tenha nascido em um ano bissexto, de modo que existem 181 dias possíveis. 23. Depois de Ellen ter confessado a Marilyn que a enganou no episódio da indicação de Tom, Marilyn resolveu evi- tar esse problema ditando o conteúdo de futuras men- sagens a um gravador e fazendo sua nova secretária simplesmente digitá-las. Marilyn planejava examinar as mensagens em seu terminal depois de ser digitadas, para ter certeza de que continham suas palavras exatas. A nova secretária ainda pode usar o ataque do aniver- sário para falsificar uma mensagem? De que maneira? Dica: Ela pode fazê-lo. 24. Considere a tentativa malsucedida de Alice de conseguir a chave pública de Bob na Figura 8.20. Suponha que Bob e Alice já compartilhem uma chave secreta, mas Alice ain- da quer a chave pública de Bob. Agora existe um modo de obtê-la em segurança? Em caso afirmativo, como? 25. Alice quer se comunicar com Bob, usando a criptogra- fia de chave pública. Ela estabelece uma conexão com alguém que espera que seja Bob. Alice pede a ele sua 08_tanen0809_cap08 BR.indd 546 4/25/11 3:08 PM
- 69. Capítulo 8 Segurança deredes 547 chave pública e ele a envia em texto simples, junta- mente com um certificado X.509 assinado pela CA raiz. Alice já tem a chave pública da CA raiz. Que etapas ela deve executar para verificar se está se comunicando com Bob? Suponha que Bob não se importe em saber com quem está se comunicando (por exemplo, Bob e alguma espécie de serviço público). 26. Suponha que um sistema utilize a PKI baseada em uma hierarquia estruturada em árvore de CAs. Alice quer se comunicar com Bob e recebe um certificado de Bob assi- nado por uma CA X, depois de estabelecer um canal de comunicação com Bob. Suponha que Alice nunca tenha ouvido falar em X. Que etapas Alice deve executar para confirmar que está se comunicando com Bob? 27. O IPsec usando a AH pode ser empregado em modo de transporte quando uma das máquinas está atrás de um NAT? Explique sua resposta. 28. Alice deseja enviar uma mensagem a Bob usando hashes SHA-1. Ela consulta você em relação ao algoritmo de assi- natura apropriado que será usado. O que você sugeriria? 29. Apresente uma razão que justifique o fato de um firewall poder ser configurado de modo a inspecionar o tráfego de entrada. Apresente uma razão que justifique o fato de um firewall poder ser configurado de modo a inspecionar o tráfego de saída. Você acredita que as inspeções têm pro- babilidade de sucesso? 30. Suponha que uma organização utilize uma VPN para se conectar em segurança a seus sites pela Internet. Jim, um usuário na organização, usa a VPN para se comunicar com sua chefe Mary. Descreva um tipo de comunicação entre Jim e Mary que não exigiria o uso de criptografia ou outro mecanismo de segurança, e outro tipo de comuni- cação que exigiria criptografia ou outros mecanismos de segurança. Explique sua resposta. 31. Faça uma pequena alteração em uma mensagem no proto- colo da Figura 8.30, de modo a torná-lo resistente ao ata- que por reflexão. Explique por que sua mudança funciona. 32. A troca de chaves de Diffie-Hellman está sendo usada para estabelecer uma chave secreta entre Alice e Bob. Ali- ce envia a Bob a mensagem (227, 5, 82). Bob responde com (125). O número secreto de Alice, x, é 12, e o nú- mero secreto de Bob, y, é 3. Mostre como Alice e Bob calculam a chave secreta. 33. Dois usuários podem estabelecer uma chave secreta com- partilhada usando o algoritmo de Diffie-Hellman, mesmo que nunca tenham se encontrado, não compartilhem se- gredos e não tenham certificados. (a) Explique como esse algoritmo é suscetível a um ata- que do homem no meio. (b) Como essa suscetibilidade mudaria se n ou g fossem secretos? 34. No protocolo da Figura 8.35, por que A é enviado em tex- to simples junto com a chave de sessão criptografada? 35. No protocolo de Needham-Schroeder, Alice gera dois desafios, RA e RA2 . Isso parece exagero. Apenas um não seria suficiente? 36. Suponha que uma organização utilize o Kerberos para autenticação. Em termos de segurança e disponibilidade de serviço, qual será o efeito se AS ou TGS for desativado? 37. Alice está usando o protocolo de autenticação por cha- ve pública da Figura 8.39 para autenticar a comunicação com Bob. Porém, ao enviar a mensagem 7, Alice se es- queceu de criptografar RB . Trudy agora conhece o valor de RB . Alice e Bob precisam repetir o procedimento de autenticação com novos parâmetros a fim de garantir a comunicação segura? Explique sua resposta. 38. No protocolo de autenticação por chave pública da Figura 8.39, na mensagem 7, RB é criptografado com KS . Essa crip- tografia é necessária, ou teria sido melhor enviar a mensa- gem de volta em texto simples? Explique sua resposta. 39. Terminais de pontos de venda que utilizam cartões com tar- ja magnética e códigos PIN têm uma falha fatal: um comer- ciante inescrupuloso pode modificar sua leitora de cartões para armazenar todas as informações do cartão, assim como o código PIN, a fim de informar outras transações (falsas) no futuro. A próxima geração de terminais de pontos de venda utilizará cartões com uma CPU completa, teclado e um pequeno visor. Imagine um protocolo para esse sistema que comerciantes inescrupulosos não consigam burlar. 40. Seria possível enviar uma mensagem PGP por multicast? Que restrições se aplicariam? 41. Supondo que todos na Internet usassem o PGP, uma men- sagem PGP poderia ser enviada a um endereço qualquer da Internet e ser decodificada corretamente por todos os envolvidos? Comente sua resposta. 42. O ataque mostrado na Figura 8.42 omite uma etapa. A etapa não é necessária para o spoofing funcionar, mas in- cluí-la poderia reduzir a suspeita potencial depois do fato. Qual é a etapa omitida? 43. O protocolo de transporte de dados SSL envolve dois non- ces, bem como uma chave pré-mestre. Que valor, se for o caso, tem o uso dos nonces? 44. Considere uma imagem de 2048 × 512 pixels. Você deseja criptografar um arquivo com tamanho de 2,5 MB. Que fração do arquivo você pode criptografar nessa imagem? Que fração você poderia criptografar se compactasse o ar- quivo para um quarto de seu tamanho original? Mostre seus cálculos. 45. A imagem da Figura 8.49 (b) contém o texto ASCII de cinco peças de Shakespeare. Seria possível ocultar músi- ca em vez de texto entre as zebras? Em caso afirmativo, como isso seria feito e que quantidade de música você ocultaria na imagem? Em caso negativo, por que não? 46. Você recebe um arquivo de texto de 60 MB, que deve ser criptografado usando a esteganografia nos bits de baixa ordem de cada cor em um arquivo de imagem. Que tama- nho de imagem seria necessário para poder criptografar o arquivo inteiro? Que tamanho seria necessário se o arqui- vo fosse primeiro compactado para um terço de seu tama- nho original? Mostre suas respostas em pixels e apresente os cálculos. Suponha que as imagens tenham uma relação entre os eixos de 3:2, por exemplo, 3000 x2000 pixels. 08_tanen0809_cap08 BR.indd 547 4/25/11 3:08 PM