A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Protocolos de Segurança Érika Benning Salgado --> PGP Maria Eugênia Shuler --> Kerberos Simone Antunes --> SSL.

Apresentações semelhantes


Apresentação em tema: "Protocolos de Segurança Érika Benning Salgado --> PGP Maria Eugênia Shuler --> Kerberos Simone Antunes --> SSL."— Transcrição da apresentação:

1 Protocolos de Segurança Érika Benning Salgado --> PGP Maria Eugênia Shuler --> Kerberos Simone Antunes --> SSL

2 SSL Secure Socket Layer

3 Introdução n Privacidade e Confiabilidade n Composto de 2 níveis: Protocolos de Aplicação... SSL Handshake Protocol SSL Record Protocol TCP... SSL

4 Propiedades da Conexão SSL n 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.

5 Objetivos n Segurança criptográfica n Interoperabilidade n Extensiabilidade n Eficiência

6 Passos Mesagem a ser transmitida: Fragmenta os dados Comprime os dados Aplica Mac e encriptografa Transmite o resultado Decriptografado e Verificado Expandido Reassembled Mensagem Recebida:...

7 Estado de Sessão e Conexão Estado de Sessão e Conexão n 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.

8 Continuação... n 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.

9 Handshake Protocol Cliente Servidor Client Hello Server Hello Certificado(*) Pedido de Cerfificado(*) Fim do Server Hello Verificação do Certificado(*) Certificado(*) [ Cipher Spec] Fim [CipherSpec] Fim Dados de Aplicação

10 Implementações SSL n SSL Netscape n SSLRef n SSLjava

11 Usando SSL para mandar dados seguramente... n Web Server e Web Browsers n http -> https n Exemplo: mude para:

12 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

13 Ameaças Ameaças n Usuário se passar por um outro usuário n 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

14 Motivação n Cenário mais comum atualmente - arquitetura distribuída com: - workstations - servidores distribuídos ou centralizados n 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

15 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

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

17 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 Ticket = Ek [ IDc, ADc, IDv ] problemas ainda existem: Y número de vezes que o usuário entra com a password X transmissão plaintext da password

18 Versão 4 Solução: * esquema para evitar password plaintext * TGS ( novo servidor) * TGS ( novo servidor) um diálogo de autenticação mais seguro uma vez por sessão de logon C -> AS: IDc, IDtgs C -> AS: IDc, IDtgs AS -> C: Ekc [ Tickettgs ] AS -> C: Ekc [ Tickettgs ] Tickettgs = Ektgs [IDc, ADc, IDtgs, TS1, Lifetime1] uma vez por tipo de serviço C -> TGS: IDc, IDv, Tickettgs C -> TGS: IDc, IDv, Tickettgs TGS -> C: Ticketv TGS -> C: Ticketv Ticketv = Ekv [IDc, ADc, IDv, TS2, Lifetime2] uma vez por sessão de serviço C -> V: IDc, Ticketv C -> V: IDc, Ticketv

19 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 n Examinando os problemas... S - informação secreta para C e TGS por AS isto é, utilizar chave de criptografia = CHAVE DE SESSÃO

20 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 ]

21 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

22 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

23 Realms Kerberos...tal ambiente é chamado um REALM n Redes sob diferentes organizações => diferentes REALMS Usuários de um REALM servidores de outro REALM 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.

24 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

25 Versão 4 X Versão 5 n 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 Criptografia dupla n Criptografia PCBC (plain - e - cipher block chaining) n Chaves de sessão n Ataques de password

26 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

27 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]

28 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

29 Flags n INITIAL: ticket foi liberado usando o protocolo AS n PRE-AUTHENT: durante autenticação inicial, cliente foi autenticado por KDC n HW-AUTHENT: autenticação inicial precisa usar hardware n RENEWABLE: ticket pode ser usado para obter um outro ticket com data de expiração posterior n INVALID: ticket é inválido e deve ser validado pelo KDC antes de ser utilizado n PROXIABLE: novo ticket service-granting com um endereço de rede diferente pode ser liberado com a apresentação deste ticket. n FORWARDABLE: novo ticket service-granting com u endereço de rede diferente pode ser liberado com a apresentação deste ticket.

30 Segurança no Correio Eletrônico n Alguns serviços solicitados: –Confidencialidade –Autenticação –Integridade

31 Pretty Good Privacy (PGP) n 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.

32 Pretty Good Privacy (PGP) n Oferece 5 recursos: –Autenticação –Confidencialidade –Compressão –Compatibilidade de –Segmentação

33 Autenticação n O transmissor cria a mensagem; n MD5 é usado para gerar o hash code; n O hash code é criptografado utilizando RSA com a chave privada do transmissor; n O receptor usa RSA com a chave pública do transmissor para descriptografar e restabelecer o hash code; n O receptor gera um novo hash code para a mensagem e compara-o com o hash code descritpografado.

34 Autenticação

35 Confidencialidade n O transmissor gera a mensagem e a chave de sessão; n A mensagem é cifrada, usando IDEA com a chave de sessão; n A chave de sessão é cifrada com RSA, usando a chave pública do receptor; n O receptor usa RSA com sua chave privada para decifrar e obter a chave de sessão; n A chave de sessão é usada para decifrar a mensagem.

36 Confidencialidade

37 Confidencialidade e Autenticação n 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.

38 Confidencialidade e Autenticação

39 Outros Serviços Compressão 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.

40 Diagrama de transmissão

41 Diagrama de recepção

42 Chaves usadas pelo PGP

43 Tabela de chaves privadas n Timestamp: Dia/hora que o par de chaves foi gerado; n Key ID: Os últimos 64 bits significantes da chave pública; n Chave pública; n Chave privada: Este campo é criptografado; n User ID: Geralmente o do usuário.

44 Tabela de chaves públicas n 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;

45 Gerenciamento das chaves públicas n 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


Carregar ppt "Protocolos de Segurança Érika Benning Salgado --> PGP Maria Eugênia Shuler --> Kerberos Simone Antunes --> SSL."

Apresentações semelhantes


Anúncios Google