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 Record Protocol TCP ... SSL

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 ... ... Fragmenta os dados Aplica Mac e Mesagem a ser transmitida: Mensagem Recebida: Fragmenta os dados Reassembled Comprime os dados Expandido Aplica Mac e encriptografa Decriptografado e Verificado Transmite o resultado

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(*) [ Cipher Spec] Fim [CipherSpec] Dados de Aplicação 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 1

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 2

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 3

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 4

Motivação Requisitos * Segurança * Confiabilidade * Transparência Abordagem 3 é suportada por Kerberos Requisitos * Segurança * Confiabilidade * Transparência * Escalonável 5

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 6

uma vez por tipo de serviço 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 7

Tempo de vida: longo ou curto (?) 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 8

O Protocolo Autenticação Ticket-Granting 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 ] 9

Autenticação Cliente/Servidor 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 10

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 11

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. 12

Como é feita a comunicação: 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 13

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 14

Elementos adicionados a Versão 4 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 15

Versão 5 Ticket-Granting 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] 16

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 17

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. 18

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

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

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

Outros Serviços Compressão Segmentação e Remontagem 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

Diagrama de recepção

Chaves usadas pelo PGP

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