Protocolos de Segurança

Apresentação em tema: "Protocolos de Segurança"— 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 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 ... ... 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

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(*) [ Cipher Spec] Fim [CipherSpec] 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 = “ mude para: <form method =POST action = “

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 1

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 2

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 3

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 4

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

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 6

18 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

19 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

20 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

21 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

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 11

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

24 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

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 14

26 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

27 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

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 17

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

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

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