Protocolos de Segurana rika Benning Salgado PGP Maria
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 n Composto de 2 níveis: n Protocolos de Aplicação. . . SSL Handshake Protocol 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 n Identidade do par é autenticado através de criptografia assimétrica ou de chave pública, ex. : DSS e RSA n Confiável. Existe checagem de integridade de mensagens através de MAC c/ chave. n
Objetivos Segurança criptográfica n Interoperabilidade n Extensiabilidade n Eficiência n
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. n O estado é representado 2 vezes. n Mensagens de Alerta. Contém a importância da mensagem e descrição da alerta. n Mensagens de Fechamento(Close_notify) n Alertas de Erro. Ex. : unexpected_message. n
Continuação. . . n Elementos do estado da sessão: – id da conexão - seq. de bytes escolhidas pelo servidor – Mét. de Compressão – Cipher. Spec - 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(*) [ Cipher Spec] Fim Dados de Aplicação [Cipher. Spec] Fim Dados de Aplicação
Implementações SSL Netscape n SSLRef n SSLjava n
Usando SSL para mandar dados seguramente. . . Web Server e Web Browsers n http -> https n Exemplo: n <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 n Serviço de autenticação n 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 n n 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 n n 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 n Requisitos * Segurança * Confiabilidade * Transparência * Escalonável
Kerberos Versão 4 n 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 = Ek [ IDc, ADc, IDv ] Y problemas ainda existem: número de vezes que o usuário entra com a password X 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, TS 1, Lifetime 1] uma vez por tipo de serviço C -> TGS: IDc, IDv, Tickettgs TGS -> C: Ticketv = Ekv [IDc, ADc, IDv, TS 2, Lifetime 2] 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-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 n 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, TS 1 AS -> C: Ekc [ Kc, tgs, IDtgs, TS 2, Lifetime 2, Tickettgs] Tickettgs = Ekc[Kc, tgs, IDc, ADc, IDtgs, TS 2, Lifetime 2 ] Ticket-Granting C -> TGS: IDv, Tickettgs, Autenticadorc TGS -> C: Ekc, tgs [ Kc, v, IDv, TS 4, Ticketv] Ticketv = Ekv [ Kc, v, IDc, ADc, IDv, TS 4, Lifetime 4] Autenticadorc = Ekc, tgs[ IDc, ADc, TS 3 ]
O Protocolo Autenticação Cliente/Servidor C -> V: Ticketv, Autenticadorc ** V -> C: Ekc, v [ TS 5 + 1] Ekc, v : garante a C que esta mensagem é de V TS 5 + 1: garante a C que esta mensagem não é um replay de um reply antigo ** Opcional
Realms Kerberos Um ambiente consistindo de: n um servidor Kerberos n um número de clientes n um número de servidores de aplicação possui os seguintes requisitos: n servidor kerberos deve ter o UID e password de todos os usuários participantes em uma base de dados. n 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 n Redes sob diferentes organizações => diferentes REALMS n Usuários de um REALM servidores de outro REALM Kerberos oferece mecanismo para autenticação inter-REALM um requisito a mais é necessário: n 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: n Dependência do sistema de criptografia n Dependência do protocolo Interner n Tempo de vida do ticket n Forward de autenticação Deficiências técnicas: n n n 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, Nonces 1 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, Nonce 1, Realmtgs, IDtgs ] Tickettgs = Ek, tgs[ Flags, Kc, tgs, Realmc, IDc, ADc, Times ] Ticket-Granting C -> TGS: Opções, Idv, Realmc, Tickettgs, Times, Nonce 2, Autenticadorc TGS -> C: Realmc, IDc, Ticketv, Ekc, tgs [ Kc, v, Times, Nonce 2, Realmv, IDv] Ticketv = Ekv [Flags, Kc, v, Realmc, IDc, ADc, Times ] Autenticadorc = Ekc, tgs [ IDc, Realmc, TS 1]
Versão 5 Autenticação cliente/servidor C -> TGS: Opções, Ticketv, Autenticadorc ** TGS -> C: Ec, v [ TS 2, Sub. Key, Seq# ] Ticketv = Ekv [Flags, Kc, v, Realmc, IDc, ADc, Times ] Autenticadorc = Ekc, v [ IDc, Realmc, TS 2, Sub. Key, Seq#] Sub. Key: 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 n n n n 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 n Alguns serviços solicitados: – Confidencialidade – Autenticação – Integridade
Pretty Good Privacy (PGP) Roda em diferentes plataformas incluindo DOS/Windows, UNIX, Machintosh, e muitas outras. n A versão comercial do PGP dá direito a suporte. n Utiliza algoritmos considerados extremamente seguros. n Tem uma variedade de aplicações distintas. n
Pretty Good Privacy (PGP) n Oferece 5 recursos: – Autenticação – Confidencialidade – Compressão – Compatibilidade de e-mail – Segmentação
Autenticação n n n O transmissor cria a mensagem; MD 5 é 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
Confidencialidade n n n 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
Confidencialidade e Autenticação O transmissor primeiro assina a mensagem com sua chave privada; n Criptografa a mensagem com a chave de sessão; n Cifra a chave de sessão com a chave pública do receptor. n
Confidencialidade e Autenticação
Outros Serviços n Compressão – PGP faz a compressão dos dados depois de aplicar a assinatura, mas antes de cifrar a mensagem. n 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
Diagrama de recepção
Chaves usadas pelo PGP
Tabela de chaves privadas Timestamp: Dia/hora que o par de chaves foi gerado; n Key ID: Os últimos 64 bits significantes da chave pública; n Chave privada: Este campo é criptografado; n User ID: Geralmente o e-mail do usuário. n
Tabela de chaves públicas Timestamp: Dia/hora que esta entrada foi gerada; n Key ID: Os últimos 64 bits significantes da chave pública; n Chave pública; n User ID: Identifica o dono da chave; n
Gerenciamento das chaves públicas A deve receber fisicamente, pessoalmente, a chave de B. n Verificar a chave de B por telefone, se A reconhecer bem a voz de B. n Obter a chave de B através de um terceiro confiável D que pode ser uma autoridade com certificado n
- Slides: 45