1 / 45

Protocolos de Segurança

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

libra
Download Presentation

Protocolos de Segurança

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • Privacidade e Confiabilidade • Composto de 2 níveis: Protocolos de Aplicação... SSL Handshake Protocol SSL Record Protocol TCP ... SSL

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

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

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

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

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

  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 Dados de Aplicação

  10. Implementações SSL • SSL Netscape • SSLRef • SSLjava

  11. 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”>

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

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

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

  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 • Requisitos * Segurança * Confiabilidade * Transparência * Escalonável

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

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

  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 • 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: • 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

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

  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 • 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

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

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

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

  32. Pretty Good Privacy (PGP) • Oferece 5 recursos: • Autenticação • Confidencialidade • Compressão • Compatibilidade de e-mail • Segmentação

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

  34. Autenticação

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

  36. Confidencialidade

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

  38. Confidencialidade e Autenticação

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

  40. Diagrama de transmissão

  41. Diagrama de recepção

  42. Chaves usadas pelo PGP

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

  44. 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;

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

More Related