Apostila de Fundamentos de Redes de Computadores Prof: Ricardo Quinto

populares e servidores Web. Alm disso, ele a base do protocolo TLS (transport layer
security segurana da camada de transporte).
Os protocolos SSL e TLS no so limitados aplicao na Web; por exemplo, eles
podem ser usados de maneira semelhante para autenticao e criptografia de dados no
acesso ao correio IMAP. A camada SSL pode ser vista como uma camada que se situa
entre a camada de aplicao e a camada de transporte. No lado remetente, o protocolo SSL
recebe os dados (como uma mensagem HTTP ou IMAP vinda de uma aplicao),
criptografa-os e direciona os dados criptografados a uma porta TCP. No lado receptor, ele
l a porta TCP, decifra os dados e os direciona aplicao. Embora o protocolo SSL possa
ser usado com muitas aplicaes da Internet, ele ser discutido no contexto da Web, em que
utilizado principalmente para o comrcio pela Internet.
A SSL tem as seguintes caractersticas:
Autenticao do servidor SSL, que permite que um usurio confirme a identidade de
um servidor. Um browser habilitado para SSL mantm uma lista de CAs de confiana,
juntamente com as chaves pblicas dessas CAs. Quando um browser quer fazer
negcios com um servidor Web habilitado para SSL, ele obtm um certificado do
servidor contendo a chave pblica deste. O certificado emitido (ou seja, assinado
digitalmente) pela CA que aparece na lista de CAs de confiana do cliente. Essa
caracterstica permite que o browser autentique o servidor antes de o usurio informar o
nmero de seu carto de pagamento. No contexto do exemplo apresentado, essa
autenticao do servidor permite que Bob verifique se ele est realmente enviando o
nmero de seu carto de pagamento Alice Incorporated, e no a algum que possa
estar se fazendo passar pela Alice Incorporated.
Autenticao do cliente SSL, que permite que um servidor confirme a identidade de um
usurio. Anloga autenticao do servidor, a autenticao do cliente faz uso de
certificados dos clientes que tambm foram emitidos pelas CAs. Essa autenticao ser
importante se o servidor, por exemplo, for um banco que est enviando informaes
financeiras confidenciais para um cliente e quer verificar a identidade do receptor. A
autenticao do cliente, embora suportada pela SSL, opcional. Para mantermos nossa
discusso em um nico foco, vamos ignorar a autenticao do cliente daqui em diante.
Uma sesso SSL criptografada, na qual toda a informao enviada entre browser e
servidor criptografada pelo software remetente (browser ou servidor Web). Essa
confidencialidade pode ser importante tanto para o cliente quanto para o comerciante.
O protocolo SSL tambm fornecer um mecanismo que detecta a alterao de
informao por um intruso.
9.7.1.1 Como a SSL funciona
Um usurio digamos, Bob navega pela Web e pressiona um ponteiro que o
transporta a uma pgina segura abrigada pelo servidor habilitado SSL de Alice. A
parte do URL que se refere ao protocolo para essa pgina HTTPS, e no o HTTP
comum. O browser e o servidor ento rodam o protocolo de mtua apresentao SSL
que (1) autentica o servidor e (2) gera uma chave simtrica compartilhada. Ambas as
tarefas fazem uso da tecnologia de chaves pblicas RSA. O fluxo principal de eventos
na fase de mtua apresentao mostrado na Figura 9.27. Durante essa fase, Alice
envia a Bob seu certificado, a partir do qual Bob obtm a chave pblica de Alice. Bob
ento cria uma chave simtrica aleatria, criptografa-a com a chave pblica de Alice e
a envia criptografada para Alice. Agora, Bob e Alice compartilham uma chave de
sesso simtrica. Assim que esse protocolo de mtua apresentao se completa, todos

247
Apostila de Fundamentos de Redes de Computadores Prof: Ricardo Quinto

os dados enviados entre o browser e o servidor (pelas conexes TCP) so

criptografados usando a chave de sesso simtrica.

Figura 9.27 Viso de alto nvel da fase de mtua apresentao SSL.

Agora que apresentamos uma viso de alto nvel da SSL, vamos examinar
melhor alguns dos detalhes mais importantes. A fase de mtua apresentao SSL
percorre os seguintes passos:
1. O browser envia ao servidor o nmero da verso da SSL que utiliza e as
preferncias criptogrficas. Ele envia essas preferncias criptogrficas porque
browser e servidor negociam qual algoritmo de chaves simtricas vo usar.
2. O servidor envia ao browser o nmero da verso da SSL que utiliza, suas
preferncias criptogrficas e seu certificado. Lembre-se de que o certificado
contm a chave pblica RSA do servidor e certificado por uma CA, isto , o
certificado criptografado por uma chave pblica da CA.

3. O browser tem uma lista de CAs de confiana e uma chave pblica para cada CA
da lista. Se no tiver, o usurio ser avisado do problema e informado de que no
pode ser estabelecida uma conexo criptografada e autenticada. Se a CA estiver na
lista, o browser usar a chave pblica da CA para decifrar o certificado e obter a
chave pblica do servidor.
4. O browser gera uma sesso de chave simtrica, criptografa-a com a chave pblica
do servidor e envia a chave de sesso criptografada ao servidor.

248
Apostila de Fundamentos de Redes de Computadores Prof: Ricardo Quinto

5. O browser envia uma mensagem ao servidor informando que as futuras mensagens

do cliente sero criptografadas com a chave de sesso. Ele ento envia uma
mensagem separada (criptografada) mostrando que sua parte na mtua
apresentao est encerrada.
6. O servidor envia uma mensagem ao browser informando que as futuras mensagens
do servidor sero criptografadas com a chave de sesso. Ele ento envia uma
mensagem separada (criptografada) mostrando que sua parte na mtua
apresentao est encerrada.
7. Agora, a mtua apresentao SSL est completa e comea a sesso SSL. O
browser e o servidor usam as chaves de sesso para codificar e decifrar os dados
que enviam um ao outro e para validar sua integridade.

A mtua apresentao SSL tem na verdade mais passos do que os apresentados.

Voc pode encontrar mais informaes sobre a SSL na Security Developer Central da
Netscape. Alm das compras feitas com carto de crdito, destacamos que a SSL pode
ser (e ) usada para outras transaes financeiras, incluindo home banking e comrcio
de aes.
9.7.1.2 A SSL em ao
Recomendamos que visite um site seguro, como por exemplo um site da cidade
de Quebec de xarope de bordo (http://www.jam.ca/syrup). Quando entrar na seo de
segurana de um site desse tipo, a SSL executar o protocolo de mtua apresentao.
Supondo-se que o certificado do servidor passe na verificao, o browser o notificar,
por exemplo, apresentando um cone especial. Dali em diante, toda informao
trocada entre voc e o servidor ser criptografada. Seu browser dever permitir que
voc realmente veja o certificado do comerciante. (Por exemplo, com o Internet
Explorer, consulte Arquivo, Propriedades, Certificados.) Em fevereiro de 2000, o
certificado do site de xarope de bordo continha as seguintes informaes:

Empresa: Netfarmers Enterprises Inc.

Autoridade Cerlificadora: Thawte Certification
Chave pblica (em notao hexadecima/):
3E:BD:DD:46:10:D1:92:95:D6:12:ED:A8:18:88:51:60

Se seu browser permitir que se realizem transaes seguras com o comerciante,

ento voc dever tambm poder ver o certificado da CA, isto , da Thawte
Certification. Por exemplo, no Internet Explorer, consulte Ferramentas, Opes da
Internet, Contedo, Certificados.
9.7.1.3 As limitaes no comrcio pela internet
Devido sua simplicidade e a seu desenvolvimento precoce, a SSL
amplamente implementada em browsers, servidores e produtos para comrcio pela
Internet. Esses servidores e browsers habilitados SSL fornecem uma plataforma
popular para transaes com cartes de pagamento. No entanto, devemos ter sempre
em mente que a SSL no foi produzida especificamente para transaes com cartes de
pagamento, mas para comunicaes genricas seguras entre um cliente e um servidor.
Por causa de seu projeto genrico, faltam SSL muitas caractersticas que o setor de
cartes de pagamento gostaria de ver incorporadas a um protocolo de comrcio pela
Internet.

249
Apostila de Fundamentos de Redes de Computadores Prof: Ricardo Quinto

Considere novamente o que acontece quando Bob compra algo do site Alice
Incorporated por meio da SSL. O certificado assinado que Bob recebe de Alice
garante que ele est negociando com a Alice Incorporated e que a Alice Incorporated
uma empresa bona fide. Contudo, o certificado genrico no indica se a Alice
Incorporated est autorizada a aceitar compras com carto de pagamento nem se a
empresa um estabelecimento comercial de confiana. Isso abre uma porta para a
fraude do comerciante. E h um problema semelhante com a autorizao do cliente.
Mesmo que seja usada a autenticao do cliente SSL, o certificado do cliente no
vincula Bob a um determinado carto de pagamento autorizado; assim, a Alice
Incorporated no pode ter certeza de que Bob est autorizado a fazer uma compra
usando carto de pagamento. Isso abre a porta para todos os tipos de fraude, incluindo
compras com cartes de crdito roubados e recusa de bens comprados.
Evidentemente, esse tipo de fraude crescente nas compras pelo correio ou pelo
telefone (mail order and telephone order Moto). Nas transaes desse tipo, a lei
estabelece que o comerciante se responsabilize por transaes fraudulentas. Assim, se
um cliente fizer uma compra pelo correio ou telefone com um carto de pagamento e
declarar que nunca fez a compra, o comerciante ser responsvel, ou seja, ele ser
obrigado por lei a devolver o dinheiro ao cliente (a no ser que ele possa provar que o
cliente realmente pediu e recebeu a mercadoria). De maneira semelhante, se uma
compra pelo correio ou telefone for feita com um carto de pagamento roubado, o
responsvel ser o comerciante. Por outro lado, nas transaes feitas pessoalmente, o
banco do comerciante aceita a responsabilidade. Como era de esperar, mais difcil
um cliente recusar uma compra que fez pessoalmente e que envolve uma assinatura por
escrito ou um nmero de identificao pessoal.
As compras SSL so semelhantes s compras pelo correio ou telefone, e
naturalmente o comerciante responsvel por uma compra SSL fraudulenta. Seria
prefervel, claro, usar um protocolo que fornecesse autenticao superior do cliente e
do comerciante, algo que fosse to bom quanto uma transao realizada pessoalmente
ou at melhor. A autenticao que envolve a autorizao de cartes de pagamento
reduziria a fraude e a responsabilidade do comerciante.
9.7.2 Comrcio pela Internet usando SET
O protocolo de transaes eletrnicas seguras (Secure Electronic Transactions
SET) um protocolo especificamente projetado para transaes seguras com cartes de
pagamento pela Internet. Ele foi originalmente desenvolvido pela Visa International e
MasterCard International em fevereiro de 1996 com a participao de empresas de
tecnologia expoentes de todo o mundo. O protocolo SET LLC, comumente conhecido
como SETCo, foi estabelecido em dezembro de 1997 como uma entidade legal para
administrar e promover a adoo global do protocolo SET. Eis algumas das principais
caractersticas do protocolo SET:
O protocolo SET foi projetado para criptografar tipos especficos de mensagens
relacionadas com cartes de pagamento; ele no pode ser usado para criptografar dados
arbitrrios (como textos e imagens), como acontece com o protocolo SSL.
O protocolo SET envolve os trs participantes do ato de uma compra: o cliente, o
comerciante e o banco do comerciante. Todas as informaes importantes trocadas
entre as trs partes so criptografadas.
O protocolo SET requer que os trs participantes tenham certificados. Os certificados
dos clientes e dos comerciantes so emitidos por seus bancos, assegurando, dessa

250
Apostila de Fundamentos de Redes de Computadores Prof: Ricardo Quinto

maneira, que esses participantes tenham permisso para fazer compras e receber por
vendas realizadas com cartes de pagamento. O certificado do cliente d segurana ao
comerciante de que as cobranas das transaes fraudulentas no recairo sobre sua
cabea. Ele uma representao eletrnica do carto de pagamento do cliente e contm
informaes sobre sua conta, a instituio financeira que o emitiu e outras informaes
criptografadas. O certificado do comerciante assegura ao consumidor que aquele
comerciante est autorizado a aceitar compras feitas por cartes de pagamento. Ele
contm informaes sobre o comerciante, o banco do comerciante e a instituio
financeira que emitiu o certificado.
O protocolo SET especifica o significado legal do certificado em poder de cada
participante e a atribuio de responsabilidades vinculadas transao.
Em uma transao SET, o nmero do carto de pagamento do cliente passado ao
banco do comerciante sem que ele nunca veja esse nmero em texto aberto. Essa
caracterstica evita que comerciantes fraudulentos ou descuidados roubem ou deixem
vazar, acidentalmente, o nmero do carto.

Uma transao SET usa trs componentes de software:

Carteira do browser: a aplicao de carteira do browser integrada ao browser e

fornece ao cliente armazenagem e administrao de cartes de pagamento e certificados
durante as compras. Ela responde a mensagens SET do comerciante, solicitando ao
cliente que escolha um carto de pagamento para o pagamento da compra.
Servidor do comerciante: o servidor do comerciante o mecanismo da comercializao
e do fechamento de pedidos de compra para os comerciantes que vendem pela Web.
Para pagamentos, ele processa as transaes do portador do carto e se comunica com o
banco do comerciante para aprovao e subseqente captura do pagamento.
Gateway do adquirente: o gateway do adquirente o componente do software no banco
do comerciante. Ele processa a transao do carto de pagamento do comerciante
referente aprovao e ao pagamento.

Na descrio a seguir, apresentaremos uma viso bastante simplificada do protocolo

SET. Na realidade, esse protocolo substancialmente mais complexo.
9.7.2.1 Estgios de uma compra
Suponha que Bob queira comprar uma mercadoria da Alice Incorporated pela
Internet, usando o protocolo SET.

1. Bob diz a Alice que est interessado em fazer uma compra com carto de crdito.
2. Alice envia a Bob uma fatura e um identificador de transao exclusivo.
3. Alice envia a Bob o certificado do comerciante, que contm a chave pblica do
comerciante. Ela envia tambm o certificado de seu banco, que contm a chave
pblica do banco. Ambos os certificados so criptografados com a chave privada
de uma CA.
4. Bob usa a chave pblica da CA para decifrar os dois certificados. Ele agora tem a
chave pblica de Alice e a chave pblica do banco.
5. Bob gera dois pacotes de informao: o pacote de informao de ordem (IO) e o
pacote de instrues de compra (IC). O pacote de IO, destinado a Alice, contm

251
Apostila de Fundamentos de Redes de Computadores Prof: Ricardo Quinto

o identificador da transao e a bandeira do carto que est sendo usado; ele no

inclui o nmero do carto de Bob. O pacote de IC, destinado ao banco de Alice,
contm o identificador da transao, o nmero do carto e o valor da compra
acertado com Bob. Os pacotes de IO e IC so duplamente criptografados: o pacote
de IO criptografado com a chave pblica de Alice; o pacote de IC criptografado
com a chave pblica do banco de Alice. (Estamos distorcendo um pouco a
realidade aqui para entender melhor o quadro. Na realidade, os pacotes de IO e IC
so criptografados com uma chave de sesso cliente/comerciante e com uma chave
de sesso cliente/banco.) Bob envia os pacotes de IO e IC para Alice.
6. Alice gera um pedido de autorizao para a solicitao do carto de pagamento, o
qual contm o identificador da transao.
7. Alice envia a seu banco a mensagem criptografada com a chave pblica do banco.
(Na realidade, usada uma chave de sesso.) Essa mensagem contm o pedido de
autorizao, o pacote de IC recebido de Bob e o certificado de Alice.
8. O banco de Alice recebe a mensagem e a decodifica. Ele verifica se houve alguma
falsificao e tambm se certifica de que o identificador da transao contido no
pedido de autorizao combina com o existente no pacote de IC de Bob.
9. O banco de Alice ento envia uma solicitao de autorizao de pagamento ao
carto de pagamento de Bob por meio dos canais bancrios tradicionais para
cartes exatamente como o banco de Alice solicitaria autorizao para qualquer
transao normal de pagamento feita com carto.
10. Uma vez que o banco de Bob autoriza o pagamento, o banco de Alice envia a ela
uma resposta, que (obviamente) criptografada. A resposta contm o identificador
da transao.
11. Se a transao for aprovada, Alice enviar sua prpria mensagem de resposta a
Bob. Essa mensagem servir de recibo e informar a Bob que o pagamento foi
aceito e que a mercadoria ser entregue.

Uma das caractersticas principais do protocolo SET a no-exposio do

nmero do carto de crdito ao comerciante. Essa caracterstica dada pelo estgio 5,
no qual o cliente criptografa o nmero do carto de crdito com a chave do banco.
Criptografar o nmero com a chave do banco evita que o comerciante veja o carto de
crdito. Note que h uma grande simetria entre os estgios de uma compra com o
protocolo SET e os estgios de uma transao normal com carto de pagamento. Para
processar todas as tarefas do protocolo SET, o cliente ter uma carteira digital que roda
o lado cliente do protocolo SET e armazena as informaes do carto de pagamento do
cliente (como por exemplo: nmero do carto e data de validade).
9.8 Segurana na camada de rede: o IPsec
O protocolo de segurana IP, mais conhecido como IPsec, um conjunto de protocolos
que oferece segurana na camada de rede. O IPsec um mecanismo bastante complexo;
diferentes partes desse conjunto de protocolos so descritas em mais de uma dzia de RFCs.
Nesta seo, vamos discutir o IPsec em um contexto especfico, ou seja, em um cenrio em que
todos os hosts da Internet suportam o IPsec. Esse contexto, embora esteja ainda muito distante,
simplificar a discusso e ajudar a entender as caractersticas principais do IPsec. Dois RFCs-
chave so o RFC 2401, que descreve a arquitetura geral da segurana IP, e o RFC 2411, que
fornece uma viso do conjunto de protocolos IPsec e apresenta os documentos que o descrevem.

252
Apostila de Fundamentos de Redes de Computadores Prof: Ricardo Quinto

Antes de examinarmos em detalhes o IPsec, vamos dar um passo atrs e considerar o que
significa oferecer segurana na camada de rede. Considere, de incio, o que significa fornecer
sigilo na camada de rede. A camada de rede ofereceria sigilo se todos os dados transportados
pelos datagramas IP fossem criptografados. Isso significa que, sempre que um host quisesse
enviar um datagrama, ele criptografaria o campo de dados do datagrama antes de despach-lo
para a rede. Em princpio, a criptografia poderia ser feita com chaves simtricas, chaves
pblicas ou chaves de sesso que so negociadas com o uso de criptografia de chaves pblicas.
O campo de dados poderia ser um segmento TCP, um segmento UDP, uma mensagem ICMP e
assim por diante. Se esse servio de camada de rede existisse, todos os dados enviados pelos
hosts incluindo e-mail, pginas Web, mensagens de controle e de administrao (como ICMP
e SNMP) ficariam ocultos de qualquer terceiro que estivesse fazendo uma escuta eletrnica
na rede. Assim, esse servio forneceria uma cobertura completa para todo trfego da Internet
e daria a todos ns, por conseguinte, uma certa sensao de segurana.
Alm do sigilo, poderamos querer que a camada de rede fornecesse autenticao da fonte.
Quando um host destinatrio recebesse um datagrama IP com um endereo IP especfico, ele
autenticaria a fonte certificando-se de que o datagrama IP, na verdade, tinha sido gerado pelo
host cujo endereo IP de fonte aquele. Esse servio evitaria que estelionatrios falsificassem
endereos IP.
No conjunto IPsec, h dois protocolos principais: o protocolo de autenticao de
cabealho (Authentication Header AH) e o protocolo de segurana de encapsulamento da
carga til (Encapsulation Security Payload ESP). Quando um host de origem envia um
datagrama a um host de destino, ele o faz com o protocolo AH ou com o protocolo ESP. O
protocolo AH fornece autenticao da fonte e integridade de dados, mas no oferece sigilo. O
protocolo ESP fornece integridade de dados, autenticao da fonte e sigilo. Como oferece mais
servios, esse protocolo naturalmente mais complicado e exige mais processamento do que o
protocolo AH. Discutiremos esses dois protocolos mais adiante.
Tanto para o protocolo AH quanto para o ESP, antes de enviar datagramas seguros de um
a outro, os hosts de origem e de destino fazem uma mtua apresentao e criam uma ligao
lgica de camada de rede. Esse canal lgico chamado de acordo de segurana (Security
Agreement AS). Assim, o IPsec transforma a tradicional camada de rede no orientada
conexo em uma rede com conexes lgicas! A conexo lgica definida por um AS uma
conexo simples, isto , unidirecional. Se ambos os hosts quiserem enviar datagramas seguros
reciprocamente, ento dois ASs (isto , conexes lgicas) precisaro ser estabelecidos, um em
cada direo. Um AS identificado, exclusivamente, pelos seguintes trs elementos:

Um identificador de protocolo de segurana (AH ou ESP);

O endereo IP de fonte para a conexo simples, e
Um identificador de conexo de 32 bits chamado de ndice dos Parmetros de Segurana
(Security Parameter Index SPI).

Para um dado AS (isto , uma dada conexo lgica de host de origem a host de destino),
cada datagrama IPsec ter um campo especial para o SPI. Todos os datagramas do AS usaro
o mesmo valor do SPI nesse campo.
9.8.1 AH (protocolo de autenticao de cabealho)
Como mencionamos anteriormente, o protocolo AH fornece identificao do host de
origem e integridade de dados, mas no sigilo. Quando um determinado host de origem
quer enviar um ou mais datagramas seguros a um destino particular, ele primeiramente

253
Apostila de Fundamentos de Redes de Computadores Prof: Ricardo Quinto

estabelece um AS com o destino. Aps ter estabelecido o AS, ele pode enviar datagramas
seguros ao host de destino. Os datagramas seguros contm o cabealho AH, que inserido
entre o datagrama de dados IP original (por exemplo, um segmento TCP ou UDP) e o
cabealho IP, como mostra a Figura 9.28. Assim, o cabealho AH amplia o campo de
dados original, e esse campo ampliado encapsulado como um datagrama IP padro. Para
o campo de protocolo no cabealho IP, o valor 51 usado para mostrar que o datagrama
contm um cabealho AH. Quando o host de destino recebe o datagrama IP, ele percebe o
nmero 51 no campo de protocolo e processa o datagrama usando o protocolo AH.
(Lembre-se de que o campo de protocolo do datagrama IP usado para determinar o
protocolo da camada acima por exemplo, UDP, TCP ou ICMP para a qual ser passada
a poro de dados de um datagrama IP.) Roteadores intermedirios processam os
datagramas exatamente como sempre o fazem examinam o endereo de destino IP e
roteiam os datagramas de acordo com esse destino.

Figura 9.28 Posio do cabealho AH no datagrama IP.

O cabealho AH contm diversos campos, tais como:

Campo do prximo cabealho, que desempenha o papel do campo de protocolo de um
datagrama comum. Ele indica se os dados que se seguem ao cabealho AH so um
segmento TCP, um segmento UDP, um segmento ICMP etc. (Lembre-se de que o
campo de protocolo do datagrama IP agora est sendo usado para indicar o protocolo
AH e, assim, no pode mais ser utilizado para identificar o protocolo da camada de
transporte.)
Campo do SPI, um valor arbitrrio de 32 bits que, combinado ao endereo de destino IP
e ao protocolo de segurana, identifica exclusivamente o AS para o datagrama.
Campo do nmero de seqncia, um campo de 32 bits que contm um nmero de
seqncia para cada datagrama. Ele inicialmente estabelecido em zero quando do
estabelecimento do AS. O protocolo AH usa os nmeros de seqncia para evitar os
ataques de reproduo e do homem do meio (veja a Seo 9.3).
Campo da autenticao de dados, um campo de comprimento varivel que contm um
resumo de mensagem assinado (isto , uma assinatura digital) para esse datagrama. O
resumo de mensagem calculado sobre o datagrama IP original, fornecendo, desse
modo, autenticao do host de origem e integridade ao datagrama IP. A assinatura
digital processada usando o algoritmo de autenticao especificado pelo AS, como o
DES, o MD5 ou o SHA.
Quando o host de destino recebe um datagrama IP com um cabealho AH, ele
determina o AS para o datagrama e, em seguida, autentica a integridade do datagrama
processando o campo da autenticao de dados. O esquema de autenticao do IPsec (tanto
para o protocolo AH como para o ESP) usa um sistema chamado HMAC, que um resumo
de mensagem criptografado descrito no RFC 2104. O HMAC usa uma chave secreta
compartilhada pelas duas partes, em vez de mtodos de chaves pblicas para autenticao
de mensagens.

254
Apostila de Fundamentos de Redes de Computadores Prof: Ricardo Quinto

9.8.2 ESP (protocolo de segurana de encapsulamento da carga til)

O protocolo ESP fornece sigilo na camada de rede, bem como autenticao do host de
origem. Novamente, tudo comea com um host de origem estabelecendo um AS com
um host de destino. Como mostra a Figura 9.29, um datagrama seguro criado
envolvendo o datagrama IP original com campos de cabealho e de trailer e, em
seguida, inserindo esses dados encapsulados no campo de dados de um datagrama IP.
No campo de protocolo do cabealho do datagrama IP, o valor 50 usado para mostrar
que o datagrama contm um cabealho e um trailer ESP. Quando o host de destino
recebe um datagrama IP, ele percebe o nmero 50 no campo de protocolo e processa o
datagrama usando o protocolo ESP. Como mostra a Figura 9.29, o datagrama IP
original e o campo de trailer ESP so criptografados. O sigilo fornecido pela
criptografia DESCBC [RFC 2405]. O cabealho ESP consiste em um campo de 32
bits para o SPI e um campo de 32 bits para o nmero de seqncia, os quais
desempenham exatamente a mesma funo que exercem no protocolo AH. O trailer
contm o campo do prximo cabealho, cuja funo idntica funo realizada no
protocolo AH. Note que, como o campo do prximo cabealho criptografado
juntamente com os dados originais, um intruso no pode descobrir qual protocolo de
transporte est sendo usado. Aps o trailer, h um campo da autenticao de dados,
que tambm desempenha o mesmo papel que o campo da autenticao de dados no
protocolo AH.

Figura 9.29 Campos ESP no datagrama IP.

9.8.3 O AS e a administrao de chaves

Para a disponibilizao bem-sucedida do IPsec, necessrio um acordo de segurana
(AS) e um esquema automatizado de gerenciamento de chaves, cuja escala possa ser
expandida. Diversos protocolos foram definidos para realizar essas tarefas, entre os quais:
O algoritmo de troca de chaves da Internet (Internet Key Exchange IKE) [RFC 2409]
o protocolo default de administrao de chaves para o IPsec.
A associao de seguranas na Internet e protocolo de administrao de chave (Internet
Security Association and Key Management Protocol ISKMP) define procedimentos
para estabelecer e encerrar ASs [RFC 2407; RFC 2408]. A ISKMP completamente
independente da troca de chaves da IKE.
Isso encerra nosso resumo sobre o IPsec. Discutimos o IPsec no contexto do IPv4 e
do modo de transporte. O IPsec tambm determina um modo de tnel, no qual so os
roteadores e no os host que introduzem a funcionalidade de segurana. Por fim, ele
descreve os procedimentos de criptografia para o IPv6 e tambm para o IPv4.

255