VPNs e IPsec

ARQUITETURA E PROTOCOLOS

CARLOS EDUARDO R MELO

UNIVERSIDADE FEDERAL DE GOIÁS
Introdução
 Túneis

 Introdução

 General Routing Encapsulation

 Point-to-Point Tuneling Protocol

VPNs e IPsec: Arquitetura e Protocolos 3

 Túneis - Introdução

 Encapsulamento dos dados de um protocolo em

outro do mesmo nível ou em um nível mais alto;

 Não fornece nenhum tipo de segurança;

VPNs e IPsec: Arquitetura e Protocolos 4

 H1 H129
Diagrama 1 GW1 Túnel IP-em-IP GW2

Exemplo de tunelamento H2
onde um datagrama do H130
protocolo IP é encapsulado
em outro datagrama IP.

(Túnel IP-em-IP)
H1

IP H1: 10.1.1.1 Cabeçalho IP

S: 10.1.1.1
ICMP
echo req.
IP H129: 10.1.1.129 D: 10.1.1.129

IP GW1: 200.223.51.1 GW1

IP GW2: 200.223.51.2 Cabeçalho IP

S: 200.223.51.1
Cabeçalho IP
S: 10.1.1.1
ICMP
echo req,
D: 200.223.51.2 D: 10.1.1.129
GW2

Cabeçalho IP ICMP
S: 10.1.1.1 echo req.
D: 10.1.1.129
H129
Arquitetura do IPsec

RFC 2401
 Introdução

 Aplica-se exatamente ao conceito de VPN;

 Pode ser implementado de diversas formas;
 Ex:
 Pode ser integrado na pilha TCP/IP diretamente;
 Pode ser adicionado logo abaixo da pilha TCP/IP;
 Pode ser implementado como um dispositivo de criptografia;
 Funciona em dois modos:
 Modo de transporte;
 Modo túnel;

 Consiste de três protocolos:

 Authentication Header (AH)
 Encapsulating Security Payload (ESP)
 Internet Key Exchange (IKE)

VPNs e IPsec: Arquitetura e Protocolos 7

 Modo de transporte

 Utilizado para conexão entre dois hosts;

 Os cabeçalhos AH e ESP são inseridos logo após o
cabeçalho IP;
 Fornece segurança ponto-a-ponto;

Internet

H1 VPN em modo de transporte H2

Cabeçalho IP Cabeçalho IPsec Dados da camada de transporte Trailer Ipsec (ESP)

VPNs e IPsec: Arquitetura e Protocolos 8

 Modo túnel

 Mais flexível que o modo de transporte;

 Conexão entre redes ou entre um host e uma rede;
 Encapsula o datagrama IP completo;

Rede
Rede da
Remota GW1 GW2
Empresa

H1

Cabeçalho IP Cabeçalho Cabeçalho IP Trailer Ipsec

Dados da camada de transporte
Externo IPsec Interno (ESP)

VPNs e IPsec: Arquitetura e Protocolos 9

 Security Associations (SA)

 É a sincronia de um estado compartilhado entre dois pontos;

 Guarda o protocolo utilizado, os algoritmos de encriptação e autenticação e
suas chaves, o número de sequência atual, a janela anti-replay, o seu
tempo de vida e um número de identificação (SPI);
 São do tipo simplex, ou seja, controlam o tráfego de uma
direção apenas;
 A identificação é feita através dos campos SPI, Endereço de
destino e o Protocolo;
 Existem dois tipos de criação de uma SA:
 Manual, pelo administrador
 Automática, através do IKE
 São armazenadas em um Security Associations Database.

VPNs e IPsec: Arquitetura e Protocolos 10

 Políticas

 São regras que se aplicam aos datagramas que

entram e saem de um host ou gateway seguro;
 Toda política possui uma ação:
 Drop: Descarta o pacote;
 Bypass: Envia o pacote normalmente sem efetuar operações
IPsec;
 Apply: Aplica as ações do protocolo especificado na política;
 Todo pacote deve se aplicar a uma politica;
 São armazenadas em um Security Policy Database.

VPNs e IPsec: Arquitetura e Protocolos 11

 Processamento de Saída

 Compara os campos de seleção do datagrama com o

objetivo de se encontrar uma política que se aplique;

 Busca a primeira SA no conjunto que se aplica ao

datagrama;

 Utiliza a SA para aplicar os serviços IPsec apropriados no

datagrama.

VPNs e IPsec: Arquitetura e Protocolos 12

 Processamento de Entrada

 Utiliza os campos específicos do datagrama para

encontrar um SA que se aplique ao cabeçalho;
 Caso o anti replay esteja habilitado, checa se o
número de seqüência é válido;
 Localiza a entrada no SPD que se aplica ao
datagrama;
 Verifica se as SAs utilizadas em 1 e 2 são as exigidas
pela política encontrada em 3;
 Encaminha o datagrama decapsulado para o
próximo ponto ou para o protocolo da camada de
nivel superior apropriada.

VPNs e IPsec: Arquitetura e Protocolos 13

Authentication Header

RFC 2402
 Introdução

 Fornece autenticação de mensagens e garante a

integridade dos dados;
 Calcula o seu Valor de Chacagem de Integridade
(ICV) sobre partes do cabeçalho IP e sobre os dados;
 Alguns campos do cabeçalho IP são mutáveis como o
Checksum, TTL, ToS etc.

Versão Tam. Cab. Tipo de Serviço (ToS) Tamanho Total (bytes)

D M
Identificação 0 F F Posição do Fragmento
Tempo de vida Protocolo Checksum do cabeçalho
Endereço de Origem
Endereço de Destino

VPNs e IPsec: Arquitetura e Protocolos 15

 Formato do Cabeçalho

Próximo Cabeçalho Tamanho do payload Reservado

Índice do Parâmetro de Segurança (SPI)
Número de seqüência

Dados de autenticação (ICV)

VPNs e IPsec: Arquitetura e Protocolos 16

 Números Seqüênciais e Janela anti-replay

 São utilizados para prevenir ataques de replay;

 Utiliza janelas anti-replay para guardar os números
já recebidos;
 A checagem de número de seqüência é opcional;

30 31 32 33 34 35 36 37 38 39
0 1 0 1 0 1 0 0 0 0

30 31 32 33 34 35 36 37 38 39
0 1 0 1 0 1 0 1 0 0
Janela anti-replay

VPNs e IPsec: Arquitetura e Protocolos 17

 Processamento de Saída

 Quando um pacote a ser enviado necessita de processamento

AH, o SA apropriado é localizado e são executados os
seguintes passos:
 Um modelo de cabeçalho é inserido entre os cabeçalhos do IP e do
protocolo de nível superior (Modo de transporte);
 O número de sequencia é incrementado e inserido no cabeçalho AH;
 Todos os outros campos do cabeçalho são preenchidos, com exceção do
ICV;
 Caso seja necessário, um preenchimento é adicionado para se assegurar de
que o tamanho do cabeçalho seja múltiplo de 32 (IPv4) ou 64 (IPv6);
 Os campos mutáveis do cabeçalho IP e o ICV são zerados e o ICV é
calculado sobre todo o datagrama;
 Os campos mutaveis são preenchidos novamente e o ICV é inserido no
cabeçalho AH;
 O colocado na fila de saída para transmissão até o seu destino.

VPNs e IPsec: Arquitetura e Protocolos 18

 Processamento de Entrada

 Quando um datagrama IP chega ao host, o AH executa

os seguintes procedimentos:
 Baseado no SPI no cabeçalho do AH e no endereço de destino no
cabeçalho IP, o SA correspondente é encontrado;
 Se a checagem número de sequência estiver habilitada, o AH
verifica o número;
 Os cabeçalhos AH e IP são copiados e os campos mutáveis do
cabeçalho IP e o ICV são zerados;
 O algoritmo de autenticação e a chave são utilizados para calcular o
ICV sobre o pacote inteiro e o resultado é comparado com o
original;
 O cabeçalho AH é removido do datagrama e o cabeçalho IP é
restaurado;
 O pacote é enviado até seu destino (Modo túnel) ou inserido na fila
de entrada para processamento IP (Modo de transporte).

VPNs e IPsec: Arquitetura e Protocolos 19

 Modos de transporte e túnel

 Modo de transporte

Cabeçalho IP Cabeçalho TCP Dados

Cabeçalho IP Cabeçalho AH Cabeçalho TCP Dados

Autenticado

 Modo túnel

Cabeçalho IP Cabeçalho TCP Dados

Cabeçalho IP Cabeçalho AH Cabeçalho IP Cabeçalho TCP Dados

Autenticado

VPNs e IPsec: Arquitetura e Protocolos 20

Encapsulating Security Payload

RFC 2406
 Introdução

 Fornece a mesma autenticação, integridade de

dados e proteção anti-replay do AH com a adição da
função de confidencialidade do Ipsec;
 A função de autenticação é idêntica à do AH, com
exceção do posicionamento dos dados da
autenticação no pacote e dos dados autenticados;
 Autenticação e encriptação são opcionais;

VPNs e IPsec: Arquitetura e Protocolos 22

 Formato do Cabeçalho

Índice do Parâmetro de Segurança (SPI)

Número de seqüência

IV e os dados do payload

Enchimento

Tam. do Enchimento Próx. Cabeçalho

Dados de autenticação (ICV)

VPNs e IPsec: Arquitetura e Protocolos 23

 Processamento de Saída

 O processo de saída se dá na seguinte forma:

 Uma busca é feita no SPD por uma SA que se aplique aos
campos de seleção apropriados;
 O número de sequencia do SA é incrementado e inserido no
cabeçalho ESP;
 O enchimento é adicionado, se necessáro, e os campos
Tamanho do enchimento e Próx. Cabeçalho são preenchidos.
Os dados, o IV e o trailer do ESP são criptografados com o
algoritmo especificado no SA;
 O ICV é calculado sobre o cabeçalho ESP, o IV, os dados e o
trailer ESP e inserido no campo Dados de autenticação;
 Se o pacote resultante requer fragmentação, ela é feita neste
ponto;

VPNs e IPsec: Arquitetura e Protocolos 24

 Processamento de Entrada

 Assim que um datagrama IP chega ao host (ou

gateway), os seguintes procedimentos são
executados:
 O SA é encontrado utilizando-se o endereço de destino,
protocolo (ESP) e o SPI do pacote;
 Caso o anti-replay esteja habilitado, verifica o numero de
sequencia do pacote;
 O pacote é autenticado através do cálculo do ICV feito sobre
o cabeçalho ESP, payload e os campos do trailer ESP
utilizando o algoritmo e a chave especificada no SA;
 Os dados e o trailer ESP são descriptografados utilizando o
algoritmo e a chave do SA. O datagrama IP é reconstruído
processado;

VPNs e IPsec: Arquitetura e Protocolos 25

 Modo de transporte

 Protege apenas os datagramas de nível superior;

 Não autentica o cabeçalho IP;
 Não possui problemas com NAT;

Cabeçalho IP Cabeçalho TCP Dados

Dados de
Cabeçalho IP Cabeçalho ESP Cabeçalho TCP Dados Trailer ESP autenticação

Criptografado

Autenticado

VPNs e IPsec: Arquitetura e Protocolos 26

 Modo túnel

 E construção do cabeçalho IP externo é feita

normalmente, sendo copiados do cabeçalho IP
interno apenas o campo ToS;

Cabeçalho Cabeçalho
Dados
IP TCP

Cabeçalho Cabeçalho Cabeçalho Cabeçalho Trailer

Dados ICV
IP ESP IP TCP ESP

Criptografado

Autenticado

VPNs e IPsec: Arquitetura e Protocolos 27

Diffie-Hellman Key Exchange

RFC 2631
 Diffie-Hellman

 Cria um segredo compartilhado sem base em

nenhuma informação compartilhada anterior;
 O processo acontece da seguinte forma:

 ya = gxa mod p
 yb = gxb mod p
 Ka = ybxa mod p
 Kb = yaxb mod p init recv

 Ka = ybxa mod p = gxbxa mod p = gxaxb mod p = yaxb mod p = Kb

VPNs e IPsec: Arquitetura e Protocolos 29

Internet Key Exchange

RFC 2409
 ISAKMP Framework

 Internet Security Assiciation and Key Management

Protocol
 Estabelece as SAs em duas fases:
 Na primeira fase cada host autentica a outra parte e
estabelece um canal de conexão segura;
 Na segunda fase, os ISAKMP negocia as SAs da VPN;
 Utiliza o algoritmo Diffie-Hellman para efetuar a
troca de um segredo compartilhado;

VPNs e IPsec: Arquitetura e Protocolos 31

 Cookies do ISAKMP

 Utiliza efetua a troca de cookies entre as partes antes

de iniciar os cálculos Diffie-Hellman;
 Quando o ISAKMP recebe uma mensagem, ele checa
se o cookie utilizado é o mesmo que foi enviado;
 Para que o sistema funcione, os cookies devem:
 Ser restritos às duas partes que o utilizam;
 Inforjável por um atacante;
 Ser limitados a uma negociação;
 Forma recomendada de geração do cookie:
 CKY = HASH(src || dst || ts || segredo)

VPNs e IPsec: Arquitetura e Protocolos 32

 Formato do Cabeçalho e Tipos de Payload

Valor Tipo de Payload

Cookie do iniciante 0 Nenhum

1 Security Association
2 Proposta
3 Transform
Cookie do respondente
4 Key Exchange
5 Identificação
Minor 6 Certificado
Próx. Payload Version Tipo de troca Flags
7 Pedido de Certificado
ID da mensagem 8 HASH
9 Assinatura
Tamanho
10 Nonce
11 Notificação
12 Remoção (Delete)
13 ID do Fabricante
14-127 Reservado
128-255 Uso Privado

VPNs e IPsec: Arquitetura e Protocolos 33

 Payloads do ISAKMP

 Todo payload consiste de um cabeçalho genérico e

u m form ato d e d ad os “op aco” ao IS A K M P ;
 O formato dos dados é definido em um Domínio de
Interpretação (DOI);
 Alguns payloads possuem atributos associados.
Existem dois tipos de atributos: Básico e de tamanho
variável;

VPNs e IPsec: Arquitetura e Protocolos 34

 Cabeçalho genérico e Atributos

Próximo Payload

A Tamanho do atributo (AF=0)

Tipo de atributo
F Valor do atributo (AF=1)

Valor do atributo (AF=1)

VPNs e IPsec: Arquitetura e Protocolos 35

 Security Associations Payload

 Consiste de 3 partes:
 SA Payload

 Propostas

 Transforms

 Cada SA possui pelo menos uma proposta e cada

proposta possui pelo menos uma transform;
 Propostas indicam o protocolo que se deve utilizar
em uma VPN e transforms carregam informações
básicas sobre a criptografia utilizada;

VPNs e IPsec: Arquitetura e Protocolos 36

 SA Payload, Proposta e Transform

SA Payload

Próx. Payload Reservado Tamanho do Payload

Domínio de Interpretação (DOI)
Situação

Payload de Proposta

Próx. Payload Reservado Tamanho do Payload

Número da Proposta Número de transforms

SPI (Tam. Variável)

Payload de Transform

Próx. Payload Reservado Tamanho do Payload

Número do Transform

Atributos da SA (Tam. Variável)

VPNs e IPsec: Arquitetura e Protocolos 37

 Key Exchange, Identificação e Certificados

Key Exchange Payload

Próx. Payload Reservado Tamanho do Payload

Dados de troca de chaves

Payload de Identificação

Próx. Payload Reservado Tamanho do Payload

Tipo de ID ID do Protocolo Porta

Dados de Identificação

Payload de Certificados

Próx. Payload Reservado Tamanho do Payload

Tipo de Certificado (RQ)
Codificação de Cert. (CE)

Autoridade de Certificado (RQ)

Dados do certificado (CE)

VPNs e IPsec: Arquitetura e Protocolos 38

 HASH, Assinatura e Nonce

HASH Payload

Próx. Payload Reservado Tamanho do Payload

Dados do HASH

Payload de Assinatura

Próx. Payload Reservado Tamanho do Payload

Dados de Assinatura

Nonce Payload

Próx. Payload Reservado Tamanho do Payload

Dados do nonce

VPNs e IPsec: Arquitetura e Protocolos 39

 Payload de Notificação

Payload de Notificação

Próx. Payload Reservado Tamanho do Payload

Domínio de Interpretação
ID do Protocolo Tamanho do SPI Tipo de mensagem de notificação

SPI

Dados de notificação

VPNs e IPsec: Arquitetura e Protocolos 40

 Remoção e Fabricante

Payload de Remoção

Próx. Payload Reservado Tamanho do Payload

Domínio de Interpretação
ID do Protocolo Tamanho do SPI Número de SPIs

SPIs

Payload de Identificação do Fabricante

Próx. Payload Reservado Tamanho do Payload

Identificação do Fabricante

VPNs e IPsec: Arquitetura e Protocolos 41

 IKE, Fase 1

 IKE possui dois modos que podem ser utilizados para

negociar uma SA de fase 1:
 Main mode
 Agressive mode
 Existem quatro meios de se autenticar um cliente:
 Um segredo compartilhado
 Uma assinatura digital
 Encriptação de chave pública
 Encriptação de chave pública revisada
 Combinando estes modos, existem oito meios de se
negociar uma SA de fase 1;
 As SAs de fase 1 são bidirecionais.

VPNs e IPsec: Arquitetura e Protocolos 42

 Main mode e Aggressive Mode

Main mode Aggressive mode

init recv init recv

VPNs e IPsec: Arquitetura e Protocolos 43

 Geração das Chaves

 O IKE não gera nenhuma chave diretamente;

 O material de chaves depende dos cookies ISAKMP, dos
nonces e do segredo compartilhado Diffie-Hellman;
 O processo de criação de chaves se inicia com o cálculo do
SKEYID:
 SKEYIDd = prf(SKEYID, gxigxr || CKYi || CKYr || 0)
 SKEYIDa = prf(SKEYID, SKEYIDd || gxigxr || CKYi || CKYr || 1)
 SKEYIDe = prf(SKEYID, SKEYIDa || gxigxr || CKYi || CKYr || 2)
 Caso o algoritmo de criptografia exija mais bits, eles são
expandidos da seguinte forma:
 K1 = prf(SKEYIDe, 0);
 K2 = prf(SKEYIDe, K1);
 ...
 Kn = prf(SKEYIDe, Kn-1);
 K = K1 || K2 || ... || Kn;

VPNs e IPsec: Arquitetura e Protocolos 44

 Autenticação com Segredo Compartilhado

 O segredo tem vida longa;

 Neste tipo de autenticação, tem-se o SKEYID
calculado da seguinte forma:
 SKEYID = prf(segredo_comp, body(NONCEi) || body(NONCEr))
 É o único lugar onde se utiliza o segredo compartilhado.
 Os HASHs de autenticação são calculados assim:
 HASHi = prf(SKEYID, gxi || gxr || CKYi || CKYr || body(SAi) ||
body(IDi))
 HASHr = prf(SKEYID, gxr || gxi || CKYr || CKYi || body(SAi) ||
body(IDr))

VPNs e IPsec: Arquitetura e Protocolos 45

 Autenticação com Assinaturas

 Os HASHs são assinados digitalmente;

 A função de cálculo do hash deve ser a prf;
 O cálculo do SKEYID é feito da seguinte forma:
 SKEYID = prf(body(NONCEi) || body(NONCEr), gxixr)

 Este método adiciona um payload de assinatura e,

opcionalmente, um certificado na troca;

VPNs e IPsec: Arquitetura e Protocolos 46

 Autenticação com Criptografia de Chave Pública

 Cada nó criptografa os payloads nonce e de

identificação com a chave pública do seu peer;
 A autenticação é feita através da verificação dos
hashes (HASHi, HASHr);
 O iniciante pode, opcionalmente, adicionar um hash
do certificado que contém a chave;
 O hash é calculado com o algoritmo negociado na
SA;

VPNs e IPsec: Arquitetura e Protocolos 47

 Autenticação com Chave Pública Revisada

 Algumas alterações foram feitas no processo

anterior:
 Apenas o nonce é encriptado com a chave pública;
 Os payloads de Key Exchange, de Identificação, e o de
Certificado [Opcional], são encriptados com um algoritmo de
criptografia simétrico;
 As chaves simétricas Ki e Kr são derivadas do material de
chaves Ni e Nr, respectivamente:
 Ni = prf(body(NONCEi), CKYi)
 Nr = prf(body(NONCEi), CKYr)

VPNs e IPsec: Arquitetura e Protocolos 48

 New Group Exchange

 Negocia um novo grupo Diffie-Hellman após a conclusão da fase 1;

 Raramente utilizado na prática;
 Fluxo das mensagens no NGE:

init recv

 Os hashes são calculados como:

 HASH1 = prf(SKEYIDa, MsgID || SA)
 HASH2 = prf(SKEYIDa, MsgID || SA)

VPNs e IPsec: Arquitetura e Protocolos 49

 Quick Mode

 Utilizado para negociar as SAs da fase 2;

 Permite uma negociação rápida da SA, com apenas três mensagens;
 O fluxo de mensagens do Quick mode se dá da seguinte forma:

init recv

 Os hashes são calculados da seguinte forma:

 HASH1 = prf(SKEYIDa, MsgID || SA || NONCEi [|| KE][|| IDi || IDr])
 HASH2 = prf(SKEYIDa, MsgID || SA || body(NONCEi) || NONCEr [|| KE][|| IDi || IDr])
 HASH3 = prf(SKEYIDa, 0 || MsgID || body(NONCEi) || body(NONCEr))

VPNs e IPsec: Arquitetura e Protocolos 50

 Referências Bibliográficas

[1] SNADER, John C., 2006. VPNs Illustrated: tunnels, VPNs, and IPsec.
Pearson Education, NJ;
[2] NIST 2005. Guide to IPsec VPNs (Draft), SPEC PUB 800-77, National
Institute of Standards and Technology (Jan.);
[3] DORASWAMY, Naganand e HARKINS, Dan, 2003. IPSec: the new security
standard for the Internet, intranets, and virtual private networks. Sec.
Edition. Prentice Hall, NY.;
[4] FERGUSON, N. e SCHNEIER, B. 1999. A Cryptographic Evaluation of IPsec.
White paper, Counterpane Internet Security.
http://www.counterpane.com/ipsec.pdf