Protocolos de Segurança
Érika Benning Salgado --> PGP
Maria Eugênia Shuler --> Kerberos
Simone Antunes --> SSL
SSL
Secure Socket Layer
Introdução
Privacidade e Confiabilidade
 Composto de 2 níveis:

Protocolos de Aplicação...
SSL Handshake Protocol
SSL
SSL Record Protocol
TCP ...
Propiedades da Conexão SSL
Privada. Criptografia para definição da
chave secreta, depois do handshake.
Criptografia simétrica para dados, ex.: DES
 Identidade do par é autenticado através de
criptografia assimétrica ou de chave
pública, ex.: DSS e RSA
 Confiável. Existe checagem de integridade
de mensagens através de MAC c/ chave.

Objetivos
Segurança criptográfica
 Interoperabilidade
 Extensiabilidade
 Eficiência

...
Passos
Mesagem a ser transmitida:
Fragmenta os dados
Comprime os dados
Aplica Mac e
encriptografa
Transmite o resultado
...
Mensagem Recebida:
Reassembled
Expandido
Decriptografado e
Verificado
Estado de Sessão e Conexão
Sessão “Stateful”. Estados controladados
pelo SSL Handshake Protocol.
 O estado é representado 2 vezes.
 Mensagens de Alerta. Contém a importância
da mensagem e descrição da alerta.
 Mensagens de Fechamento(Close_notify)
 Alertas de Erro. Ex.: unexpected_message.

Continuação...

Elementos do estado da sessão:
– id da conexão - seq. de bytes escolhidas pelo servidor
– Mét. de Compressão
– CipherSpec - especifica o algoritmo de criptografia dos dados
e um algoritmo MAC.
Handshake Protocol
Cliente
Servidor
Client Hello
Server Hello
Certificado(*)
Pedido de Cerfificado(*)
Fim do Server Hello
Verificação do Certificado(*)
Certificado(*)
[ Cipher Spec]
Fim
Dados de Aplicação
[CipherSpec]
Fim
Dados de Aplicação
Implementações SSL
SSL Netscape
 SSLRef
 SSLjava

Usando SSL para mandar dados
seguramente...
Web Server e Web Browsers
 http -> https
 Exemplo:

<form method =POST action = “http://www.company.com/cgi-bin/enter”>
mude para:
<form method =POST action = “https://www.company.com/cgi-bin/enter”>
Kerberos

Serviço de autenticação

Parte do projeto ATHENA
Problema a ser resolvido
Sistema distribuído aberto
usuários de workstations -> acessam serviços em
servidores da rede
servidores DEVEM ser capazes de:
restringir acesso
autenticar pedidos de serviços
Ameaças


Usuário se passar por um outro usuário
alteração do endereço de rede
consequência
Usuário não autorizado pode ser capaz de acessar
serviços e dados que ele não possui autorização
Kerberos oferece:
autenticação centralizada
criptografia convencional
Motivação


Cenário mais comum atualmente
- arquitetura distribuída com:
- workstations
- servidores distribuídos ou centralizados
Abordagens para segurança
1. Ambientes pequenos e fechados
- workstation garante identidade do usuário
- servidor utiliza políticas baseadas no ID do
usuário
Motivação
2. ambientes pequenos e fechados
- cliente se autentica para servidor
- cliente faz identificação do usuário
3. Sistemas mais abertos que suportam conexões de
rede para outras máquinas
- usuário informa identificação para cada serviço
invocado
- servidores provam identidade para cliente
Motivação
Abordagem 3 é suportada por Kerberos

Requisitos
* Segurança
* Confiabilidade
* Transparência
* Escalonável
Kerberos Versão 4

Utiliza DES no serviço de autenticação
um simples diálogo de autenticação
C -> AS:
IDc, Pc, Idv
AS -> C:
Ticket
C -> V:
IDc, Ticket
Ticket = Ek [ IDc, ADc, IDv ]

problemas ainda existem:
número de vezes que o usuário entra com a password
 transmissão plaintext da password
Versão 4
Solução: * esquema para evitar password plaintext
* TGS ( novo servidor)
um diálogo de autenticação mais seguro
uma vez por sessão de logon
C -> AS:
IDc, IDtgs
AS -> C:
Ekc [ Tickettgs ]
Tickettgs = Ektgs [IDc, ADc, IDtgs, TS1, Lifetime1]
uma vez por tipo de serviço
C -> TGS:
IDc, IDv, Tickettgs
TGS -> C:
Ticketv
Ticketv = Ekv [IDc, ADc, IDv, TS2, Lifetime2]
uma vez por sessão de serviço
C -> V:
IDc, Ticketv
Versão 4
Restam dois problemas adicionais:
P - tempo de vida associado com o ticket ticket-granting
(Tickettgs)
Tempo de vida: longo ou curto (?)
S - é preciso provar que o usuário que está utilizando o
ticket é o mesmo para o qual o ticket foi cedido
P- Servidor Falso => Pedidos de serviços negados
 Examinando os problemas...
S - informação secreta para C e TGS por AS
isto é,
utilizar chave de criptografia = CHAVE DE SESSÃO
O Protocolo
Autenticação
C -> AS:
IDc, IDtgs, TS1
AS -> C:
Ekc [ Kc,tgs, IDtgs, TS2, Lifetime2, Tickettgs]
Tickettgs = Ekc[Kc,tgs, IDc, ADc, IDtgs, TS2, Lifetime2 ]
Ticket-Granting
C -> TGS:
IDv, Tickettgs, Autenticadorc
TGS -> C:
Ekc,tgs [ Kc,v, IDv, TS4, Ticketv]
Ticketv = Ekv [ Kc,v, IDc, ADc, IDv, TS4, Lifetime4]
Autenticadorc = Ekc,tgs[ IDc, ADc, TS3 ]
O Protocolo
Autenticação Cliente/Servidor
C -> V:
Ticketv, Autenticadorc
** V -> C: Ekc,v [ TS5 + 1]
Ekc,v : garante a C que esta mensagem é de V
TS5 + 1: garante a C que esta mensagem não é um
replay de um reply antigo
** Opcional
Realms Kerberos
Um ambiente consistindo de:

um servidor Kerberos

um número de clientes

um número de servidores de aplicação
possui os seguintes requisitos:

servidor kerberos deve ter o UID e password de todos os
usuários participantes em uma base de dados.

Servidor Kerberos deve compartilhar uma chave secreta
com cada servidor. Todos servidores são registrados no
servidor Kerberos
Realms Kerberos
...tal ambiente é chamado um REALM

Redes sob diferentes organizações => diferentes REALMS

Usuários de um REALM  servidores de outro REALM
Kerberos oferece mecanismo para autenticação inter-REALM
um requisito a mais é necessário:

Servidor Kerberos em cada REALM interoperando,
compartilha chave secreta com o servidor no outro
REALM. Servidores são registrados um no outro.
Realms Kerberos
Como é feita a comunicação:
(1) C -> AS
(2) AS -> C
(3) C -> TGS
(4) TGS -> C
(5) C -> TGSrem
(6) TGSrem -> C
(7) C -> Vrem
Versão 4 X Versão 5
Limitações encontradas em Versão 4:
- ambiental
- deficiências técnicas
Algumas delas:
 Dependência do sistema de criptografia
 Dependência do protocolo Interner
 Tempo de vida do ticket
 Forward de autenticação
Deficiências técnicas:





Criptografia dupla
Criptografia PCBC (plain - e - cipher block chaining)
Chaves de sessão
Ataques de password
Versão 5
Autenticação
C -> AS:
Opções, IDc, Realmc, IDtgs, Times, Nonces1
Elementos adicionados a Versão 4
* Realm: realm do usuário
* Opções: alguns flags devemser setados no ticket que vai ser
retornado
* Times: configurações de tempo
- from: tempo inicial do ticket requisitado
- till: tempo de expiração do ticket requisitado
- rtime:renovação do tempo
* Nonce: número randômico para ser repetido em mensagem 2
Versão 5
AS -> C:
Realmc, Idc, Tickettgs,
Ekc[Kc,tgs, Times, Nonce1, Realmtgs, IDtgs ]
Tickettgs = Ek,tgs[ Flags, Kc,tgs, Realmc, IDc, ADc, Times ]
Ticket-Granting
C -> TGS:
Opções, Idv, Realmc, Tickettgs, Times, Nonce2,
Autenticadorc
TGS -> C:
Realmc, IDc, Ticketv, Ekc,tgs [ Kc,v, Times, Nonce2,
Realmv, IDv]
Ticketv = Ekv [Flags, Kc,v, Realmc, IDc, ADc, Times ]
Autenticadorc = Ekc,tgs [ IDc, Realmc, TS1]
Versão 5
Autenticação cliente/servidor
C -> TGS:
Opções, Ticketv, Autenticadorc
** TGS -> C: Ec,v [ TS2, SubKey, Seq# ]
Ticketv = Ekv [Flags, Kc,v, Realmc, IDc, ADc, Times ]
Autenticadorc = Ekc,v [ IDc, Realmc, TS2, SubKey, Seq#]
SubKey: cliente escolhe uma chave de criptografia para
proteger esta específica sessão de aplicação. Se omitido é
utilizada a chave de sessão Kc,v
Sequence number: número de sequência inicial para ser
usado por mensagens enviadas pelo cliente durante esta
sessão. Usado para detectar replay.
**Opcional
Flags







INITIAL: ticket foi liberado usando o protocolo AS
PRE-AUTHENT: durante autenticação inicial, cliente foi
autenticado por KDC
HW-AUTHENT: autenticação inicial precisa usar hardware
RENEWABLE: ticket pode ser usado para obter um outro
ticket com data de expiração posterior
INVALID: ticket é inválido e deve ser validado pelo KDC
antes de ser utilizado
PROXIABLE: novo ticket service-granting com um endereço
de rede diferente pode ser liberado com a apresentação deste
ticket.
FORWARDABLE: novo ticket service-granting com u
endereço de rede diferente pode ser liberado com a
apresentação deste ticket.
Segurança no Correio Eletrônico

Alguns serviços solicitados:
– Confidencialidade
– Autenticação
– Integridade
Pretty Good Privacy (PGP)
Roda em diferentes plataformas incluindo
DOS/Windows, UNIX, Machintosh, e
muitas outras.
 A versão comercial do PGP dá direito a
suporte.
 Utiliza algoritmos considerados
extremamente seguros.
 Tem uma variedade de aplicações distintas.

Pretty Good Privacy (PGP)

Oferece 5 recursos:
–
–
–
–
–
Autenticação
Confidencialidade
Compressão
Compatibilidade de e-mail
Segmentação
Autenticação





O transmissor cria a mensagem;
MD5 é usado para gerar o hash code;
O hash code é criptografado utilizando RSA
com a chave privada do transmissor;
O receptor usa RSA com a chave pública do
transmissor
para
descriptografar
e
restabelecer o hash code;
O receptor gera um novo hash code para a
mensagem e compara-o com o hash code
descritpografado.
Autenticação
Origem A
KRa
H
M
||
ER
Z
ERKRa[H(M)]
Destino B
KUa
Z-1
ER
M
Comparação
H
Confidencialidade





O transmissor gera a mensagem e a chave
de sessão;
A mensagem é cifrada, usando IDEA com a
chave de sessão;
A chave de sessão é cifrada com RSA,
usando a chave pública do receptor;
O receptor usa RSA com sua chave privada
para decifrar e obter a chave de sessão;
A chave de sessão é usada para decifrar a
mensagem.
Confidencialidade
Origem A
Destino B
KUb
KS
M
Z
EI
ER
ERKUb[KS]
KRb
DR
||
DI
Z-1
M
Confidencialidade e Autenticação
O transmissor primeiro assina a
mensagem com sua chave privada;
 Criptografa a mensagem com a chave
de sessão;
 Cifra a chave de sessão com a chave
pública do receptor.

Confidencialidade e Autenticação
Origem A
Destino B
ERKUb[KS]
ERKRa[H(M)]
KUb
KRb
KS
H
M
||
ER
Z
EI
ER
ER
KRa
||
KUa
M
Comparação
DR
DI
Z-1
H
Outros Serviços

Compressão
– PGP faz a compressão dos dados depois de aplicar a
assinatura, mas antes de cifrar a mensagem.

Segmentação e Remontagem
– PGP automaticamente divide as mensagens que são
muito longas em segmentos pequenos
– A segmentação é feita após todos os outros processos.
– A chave de sessão e a assinatura aparecem uma única
vez, no início do primeiro segmento.
Diagrama de transmissão
X:= arquivo
Sim
Assinatura?
Geração da assinatura X:= ass | | X
Não
Compressão
X:= Z(X)
Confidencialidade?
Não
Conversão
X:= R64[X]
Sim
X:= ERKUb[KS] | | EIKs[X]
Diagrama de recepção
Conversão
X:= R64-1 [X]
Sim
Confidencialidade?
K:= DRKUb [KS]; X:= DIK [X]
Não
Descompressão
X:= Z=-1 (X)
Assinatura?
Não
Sim
Capturar a assinatura de X e
verificá-la
Chaves usadas pelo PGP
Nome
Algoritmo de
Utilização
Cifragem
Chave de Sessão
IDEA
Cifrar mensagens para transmissão. É
usada
uma
única
vez
e
é
gerada
randomicamente.
Chave Pública
RSA
Cifrar chaves de sessão para transmissão
com a mensagem. Ambos, transmissor e
receptor devem ter uma cópia de cada
chave pública.
Chave Privada
RSA
Formar
uma
assinatura.
Apenas
o
receptor mantém uma cópia de sua chave
privada.
Chave baseada em
Passphrase
IDEA
Cifrar chave privada para ser estocada no
transmissor.
Tabela de chaves privadas
Timestamp: Dia/hora que o par de chaves
foi gerado;
 Key ID: Os últimos 64 bits significantes da
chave pública;
 Chave pública;
 Chave privada: Este campo é criptografado;
 User ID: Geralmente o e-mail do usuário.

Tabela de chaves públicas
Timestamp: Dia/hora que esta entrada foi
gerada;
 Key ID: Os últimos 64 bits significantes da
chave pública;
 Chave pública;
 User ID: Identifica o dono da chave;

Gerenciamento das chaves
públicas
A deve receber fisicamente,
pessoalmente, a chave de B.
 Verificar a chave de B por telefone, se A
reconhecer bem a voz de B.
 Obter a chave de B através de um
terceiro confiável D que pode ser uma
autoridade com certificado
