Protocolos Tolerantes a Intrusões com base num Modelo de Faltas Híbrido

Transcrição

1 Protocolos Tolerantes a Intrusões com base num Modelo de Faltas Híbrido Miguel P. Correia 12 de Dezembro de 2002 Sumário Modelo de faltas híbrido baseado numa componente inovadora a Protocolo de difusão fiável tolerante a intrusões BRM eficiente; não usa criptografia assimétrica; não impõe limite ao número de participantes falhados Contribuições de três protocolos tolerantes a intrusões: dois protocolos de consenso distribuído serviço de filiação rápido 2

2 1. Modelo de Faltas Híbrido. A Modelo de Faltas Arbitrárias Os processos podem falhar de forma bizantina : Parar, desobedecer ao protocolo, enviar mensagens contraditórias, fazer conluio com outros processos Rede: Pode corromper pacotes (devido a faltas acidentais) Um atacante pode modificar, apagar ou introduzir mensagens na rede 4

3 Modelo de Faltas Híbrido: Hibridização arquitectural: A maior parte do sistema está sujeito a faltas arbitrárias: processos, OS, rede A só pode falhar por paragem Host 1 Processes Host 2 Processes Host n Processes OS Local OS Local OS Local Control Channel Payload Network 5 O Modelo Trusted Timely Computing Base Componente distribuída com a sua própria rede/canal Segura, só pode falhar por paragem Tempo-real, realiza operações de forma atempada Host 1 Processes Host 2 Processes Host n Processes OS Local OS Local OS Local Control Channel Payload Network 6

4 Tolerância a Intrusões Segurança tradicional: Remover vulnerabilidades Prevenir que ataques conduzam a intrusões Tolerância a intrusões Assume-se que o sistema permanece vulnerável e que ataques às componentes ocorrem e conduzem a intrusões Garante-se que o sistema globalmente permanece seguro e operacional 7 Para que serve a? Suportar a execução de protocolos / aplicações tolerantes a intrusões: Correm no sistema de payload (pode ser atacado) Usam a para executar passos críticos (segura) Host 1 Processes Host 2 Processes Host n Processes OS Local OS Local OS Local Control Channel Payload Network 8

5 Serviços da A é usada através dos seus serviços A tem de ser pequena : Tempo-real capacidade limitada de executar serviços Segura simples para se poder verificar Logo oferece um conjunto limitado de serviços 9 Serviço de Autenticação Local Cria um canal seguro processo Local Objectivos: Processos autenticarem a Estabelecer chave simétrica partilhada processo Cada Local tem um par de chaves assimétrico Assume-se que os processos conseguem obter uma cópia correcta da chave pública Protocolo: processo : E u (K et, X e ) processo : S r (X e ) 10

6 Serviço de Acordo Executa dentro da um protocolo de acordo entre um conjunto de processos Não é suposto ser usado para executar todos os acordos A tem recursos limitados Trabalha com pequenos blocos de dados (actualmente 20 bytes) Ex.: BRM Serviço mais importante para protocolos tolerantes a intrusões 11 Serviço de Acordo (cont.) Processo faz duas operações: propose, decide Um acordo é definido por (elist, tstart, decision) elist: lista dos processos envolvidos tstart: instante quando a deixa de aceitar propostas e o acordo começa a correr decision = _TBA_RMULTICAST; retorna: valor proposto pelo primeiro processo em elist máscara proposed-ok: processos que propuseram o valor decidido máscara proposed-any : processos que propuseram qualquer valor 12

7 Outros Serviços da Serviços de segurança: Geração de números aleatórios Retorna números aleatórios fiáveis Serviços de tempo: Estampilhas temporais, detecção de falhas temporais, etc. Baseados no trabalho da Timely Computing Base (Casimiro&Veríssimo) 13 baseada em COTS A primeira concretização da é baseada em COTS: PCs Núcleo tempo-real: RT Linux / RTAI Fast-Ethernet Ideias básicas: Local dentro do núcleo Proteger o núcleo (removendo vulnerabilidades ) Proteger acesso à rede da Cobertura das hipóteses... Fácil de instalar 14

8 Arquitectura da baseada em COTS Protocolo de Difusão Fiável

9 Modos de Falha de Processos (I) Um processo correcto basicamente segue o protocolo até à sua terminação Casos em que se considera falhado: Se pára ou não segue o protocolo Se não consegue comunicar com a Local Por ex., por o SO ter sido corrompido e interromper a comunicação Se chaves criptográficas são descobertas por um atacante 17 Modos de Falha de Processos (II) Se a comunicação de um processo for sistematicamente interrompida é preciso considerá-lo falhado. Quando? Protocolos tolerantes a faltas por paragem: Grau de omissão (Od); máximo nº de mensagens corrompidas num intervalo de tempo Enviando Od+1 cópias essas omissões são toleradas Se Od+1 copias da mensagem são corrompidas considera-se o processo falhado 18

10 Difusão Fiável Um protocolo de difusão fiável pode ser definido em termos de duas propriedades: Todos os processos correctos entregam as mesmas mensagens Se o remetente de uma mensagem é correcto, então todos os processos correctos entregam a mensagem 19 Primeira Fase O protocolo termina na primeira fase se não há faltas nem grandes atrasos O remetente: Envia uma mensagem com dados (DAT) Usa o Serviço de Acordo da para fornecer aos receptores um hash da mensagem Todos os processos: Usam o resultado do Serviço de Acordo para saberem os processos que forneceram o hash certo Se todos o fizeram o protocolo termina imediatamente 20

11 Exemplo: melhor caso (só 1ª fase) tstart P0 P1 M P2 P3 H(M) H(M), all proposed ok agreement propose DAT msg msg delivery Od = k decide 21 Segunda Fase (I) Usa um novo tipo de mensagens para confirmar recepções de mensagens não confirmadas pelo Acordo Mensagens de confirmação (ACK) A sua corrupção é detectada usando MACs: Para isso cada par de processos partilha uma chave criptográficasimétrica Cada ACK leva um vector de MACs, um calculado com cada chave partilhada 22

12 Segunda Fase (II) Cada processo que tem uma mensagem para a qual H(M) = valor retornado pelo Acordo reenvia M até: Todos os processos confirmarem a recepção: Através do Acordo Com um ACK Ou até ter enviado Od+1 vezes Os processos que não receberem são considerados falhados 23 Exemplo: remetente malicioso tstart P0 P1 P2 M M M M P3 M M H(M) H(M ) H(M) agreement propose DAT msg msg delivery Od = 1 decide ACK msg 24

13 Exemplo: perda/atraso de mensag. P0 tstart Od+1 Od+1 P1 P2 P3 H(M) H(M) agreement propose DAT msg msg delivery Od = 1 decide ACK msg msg lost 25 Avaliação do Desempenho baseada em COTS: 5 PCs: Pentium III, 450 MHz, 64 Mbytes RAM Real-Time Linux Mbps Fast-Ethernet LANs Protocolo em C (gcc) Difusão com IP multicast Hash = MD5 Um processo por máquina Não há processos falhados Os valores são médias de 4500 medidas 26

14 Medidas BRM IPmcast Valor típico em trabalhos anteriores: ~50ms 27 Contribuições Difusão fiável com faltas bizantinas exige: Sistema assíncrono: n 3f+1 [Bracha&Toueg] Sistema síncrono: não há limite (n f+2) [Lamport et al.] Modelo híbrido: Sistema de payload é assíncrono e sujeito a faltas bizantinas é síncrona e só pode falhar por paragem Temos n f+2 Não usa cripto assimétrica Eficiente 28

15 3. Consenso e Filiação Tolerantes a Intrusões Protocolos de Consenso Como pode um conjunto de processos distribuídos chegar a acordo sobre um valor, apesar da falha de alguns deles? Dois protocolos de consenso: Um para decidir sobre valores que caibam no Serviço de Acordo Um geral 30

16 Contribuições (I) Não usa cripto assimétrica Baixo número de mensagens enviadas: 31 Contribuições (II) Baixa complexidade temporal: 32

17 Serviço de Filiação Sistema de comunicação em grupo: Paradigma importante para suportar aplicações distribuídas tolerantes a faltas: replicação de BDs, serviços com elevada disponibilidade, etc. SCG = Serviço de Difusão + Serviço de Filiação Serviço de filiação: Fornece uma lista ( vista ) dos membros correctos em cada instante Operações: Remoção de um membro falhado detector de falhas Entrada de um novo membro Saída voluntária de um membro Contribuições (I) Time (milliseconds) Number of processes Protocol time Remove Failed Site Site Join Site Leave Valores em trabalhos anteriores: 210/250 ms; 400/500 ms. 34

18 Contribuições (II) Crescimento do tempo parece ser lento os baseados em criptografia assimétrica têm crescimento rápido e aparentemente exponencial Protocolo simétrico : As decisões são tomadas por todos os membros (correctos) Evita ataques que tentam evitar o progresso através de rotação do chefe Conclusão e Trabalho Futuro

19 Conclusão Novo modelo de faltas híbrido Desenho de protocolos baseados nesse modelo. Contribuições: Nos limites de processos que podem falhar No desempenho Não usamos cripto assimétrica que é uma conhecida causa de estrangulamento no desempenho Na complexidade temporal e de mensagens 37 Trabalho Futuro Concretização usando módulo de hardware Redesenho do protocolo do Serviço de Acordo Estudo dos problemas de escalabilidade Protocolos Sincronia de vistas para se ter um SCG Difusão atómica Replicação de máquina de estados... 38

20 Publicações M. Correia and N. F. Neves and L. C. Lung and P. Veríssimo. Fast Byzantine- Resilient Group Membership. Submetido para publicação. M. Correia and N. F. Neves and L. C. Lung and P. Veríssimo. Low Complexity Byzantine-Resilient Consensus. Submetido para publicação M. Correia, P. Veríssimo, Nuno F. Neves. The Design of a COTS Real-Time Distributed Security Kernel. In Proceedings of the Fourth European Dependable Computing Conference. Toulouse, France, October M. Correia and L. C. Lung and N. F. Neves and P. Veríssimo. Efficient Byzantine- Resilient Reliable Multicast on a Hybrid Failure Model. In Proceedings of the 21th IEEE Symposium on Reliable Distributed Systems. Suita, Japan, October Miguel Correia, Paulo Veríssimo, Nuno Ferreira Neves. The Architecture of a Secure Group Communication System Based on Intrusion Tolerance. In International Workshop on Applied Reliable Group Communication (WARGC'01), in conjunction with ICDCS 2001, Phoenix, USA, April Paulo Veríssimo, Nuno Ferreira Neves, Miguel Correia. The Middleware Architecture of MAFTIA: A Blueprint. In Proceedings of the IEEE Third Information Survivability Workshop (ISW-2000), pages , Boston, USA, October