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

(1)

Protocolos Tolerantes a

Intrusões com base num Modelo

de Faltas Híbrido

Miguel P. Correia

Seminário Doutoral 12 de Dezembro de 2002

Navigators

Seminário Doutoral FC/UL

Sumário

• Modelo de faltas híbrido baseado numa

componente inovadora – a TTCB

• Protocolo de difusão fiável tolerante a intrusões

– BRM

F eficiente; não usa criptografia assimétrica;

F não impõe limite ao número de participantes falhados

• Contribuições de três protocolos tolerantes a

intrusões:

F dois protocolos de consenso distribuído F serviço de filiação “rápido”

(2)

1. Modelo de Faltas Híbrido.

A TTCB

Navigators

Modelo de Faltas Arbitrárias

• Os processos podem falhar de forma

“bizantina”:

F Parar, desobedecer ao protocolo, enviar mensagens contraditórias, fazer conluio com outros processos

• Rede:

F Pode corromper pacotes (devido a faltas acidentais)

F Um atacante pode modificar, apagar ou introduzir mensagens na rede

(3)

5

Modelo de Faltas Híbrido: TTCB

• Hibridização arquitectural:

F A maior parte do sistema está sujeito a faltas arbitrárias:

– processos, OS, rede

F A TTCB só pode falhar por paragem

TTCB Control Channel Payload Network Host n Local TTCB Processes OS Host 2 OS Local TTCB Processes Host 1 OS Local TTCB Processes Navigators

O Modelo TTCB

• Trusted Timely Computing Base

F Componente distribuída com a sua própria rede/canal F Segura, só pode falhar por paragem

F Tempo-real, realiza operações de forma atempada

TTCB Control Channel Host n Local TTCB Processes OS Host 2 OS Local TTCB Processes Host 1 OS Local TTCB Processes

(4)

7

Tolerância a Intrusões

• Segurança tradicional:

F Remover vulnerabilidades

F Prevenir que ataques conduzam a intrusões

• Tolerância a intrusões

F Assume-se que o sistema permanece vulnerável... F ... e que ataques às componentes ocorrem e conduzem a

intrusões

F Garante-se que o sistema globalmente permanece seguro e operacional

Navigators

Para que serve a TTCB?

• Suportar a execução de protocolos /

aplicações tolerantes a intrusões:

F Correm no sistema de payload (pode ser atacado) F Usam a TTCB para executar passos críticos (segura)

Host n Local TTCB Processes OS Host 2 OS Local TTCB Processes Host 1 OS Local TTCB Processes

(5)

9

Serviços da TTCB

• A TTCB é usada através dos seus serviços

• A TTCB tem de ser “pequena”:

F Tempo-real ⇒capacidade limitada de executar serviços F Segura ⇒simples para se poder verificar

• Logo oferece um conjunto limitado de

serviços

Navigators

Serviço de Autenticação Local

• Cria um canal seguro processo–TTCB Local

• Objectivos:

F Processos autenticarem a TTCB

F Estabelecer chave simétrica partilhada processo–TTCB

• Cada TTCB Local tem um par de chaves

assimétrico

F Assume-se que os processos conseguem obter uma cópia correcta da chave pública

• Protocolo:

processoà TTCB : Eu(Ket, Xe)

(6)

11

Serviço de Acordo

• Executa dentro da TTCB um protocolo de

acordo entre um conjunto de processos

• Não é suposto ser usado para executar

todos os acordos

F A TTCB tem recursos limitados

F Trabalha com pequenos blocos de dados (actualmente 20 bytes) F Ex.: BRM

• Serviço mais importante para protocolos

tolerantes a intrusões

Navigators

Serviço de Acordo (cont.)

• Processo faz duas operações: propose,

decide

• Um acordo é definido por (elist, tstart,

decision)

F elist: lista dos processos envolvidos

F tstart: instante quando a TTCB deixa de aceitar propostas e o acordo “começa” a correr

F decision = TTCB_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

(7)

13

Outros Serviços da TTCB

• Serviços de segurança:

F Geração de números aleatórios

– Retorna números aleatórios fiáveis

• Serviços de tempo:

F Estampilhas temporais, detecção de falhas temporais, etc. F Baseados no trabalho da Timely Computing Base

(Casimiro&Veríssimo)

Navigators

TTCB baseada em COTS

• A primeira concretização da TTCB é baseada

em COTS:

F PCs

F Núcleo tempo-real: RT Linux / RTAI F Fast-Ethernet

• Ideias básicas:

F TTCB Local dentro do núcleo

F Proteger o núcleo (removendo vulnerabilidades ) F Proteger acesso à rede da TTCB

(8)

15

Arquitectura da TTCB baseada

em COTS

Navigators

(9)

17

Modos de Falha de Processos (I)

• Um processo

correcto

basicamente segue o

protocolo até à sua terminação

• Casos em que se considera falhado:

F Se pára ou não segue o protocolo

F Se não consegue comunicar com a TTCB Local

– Por ex., por o SO ter sido corrompido e interromper a comunicação

F Se chaves criptográficas são descobertas por um atacante

Navigators

Modos de Falha de Processos (II)

• Se a comunicação de um processo for

sistematicamente interrompida é preciso

considerá-lo falhado. Quando?

F 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

F Se Od+1 copias da mensagem são corrompidas considera-se o processo falhado

(10)

19

Difusão Fiável

• Um protocolo de difusão fiável pode ser

definido em termos de duas propriedades:

F Todos os processos correctos entregam as mesmas mensagens F Se o remetente de uma mensagem é correcto, então todos os

processos correctos entregam a mensagem

Navigators

Primeira Fase

• O protocolo termina na

primeira fase

se não

há faltas nem grandes atrasos

• O remetente:

F Envia uma mensagem com dados (DAT)

F Usa o Serviço de Acordo da TTCBpara fornecer aos receptores um hashda mensagem

• Todos os processos:

F Usam o resultado do Serviço de Acordo para saberem os processos que forneceram o hash certo

(11)

21

Exemplo: melhor caso

(só 1ª fase)

P0 P3 P1 P2 TTCB agreement tstart propose decide DAT msg _{msg delivery} Od = k M H(M) H(M), all proposed ok Navigators

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)

F 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

(12)

23

Segunda Fase (II)

• Cada processo que tem uma mensagem

para a qual H(M) = valor retornado pelo

Acordo reenvia M até:

F Todos os processos confirmarem a recepção:

– Através do Acordo – Com um ACK

F Ou até ter enviado Od+1 vezes

– Os processos que não receberem são considerados falhados

Navigators

Exemplo: remetente malicioso

P0 P3 P1 P2 TTCB agreement tstart propose DAT msg Od = 1 M M M’ H(M) H(M’) M M M’ H(M)

(13)

25

Exemplo: perda/atraso de mensag.

P0 P3 P1 P2 TTCB agreement tstart propose decide DAT msg ACK msg Od = 1 msg delivery msg lost H(M) H(M) Od+1 Od+1 Navigators

Avaliação do Desempenho

• TTCB baseada em COTS:

F 5 PCs: Pentium III, 450 MHz, 64 Mbytes RAM F Real-Time Linux

F 2 100 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

(14)

27

Medidas

BRM

IPmcast

Valor típico em trabalhos anteriores: ~50ms

Navigators

Contribuições

• Difusão fiável com faltas bizantinas exige:

F Sistema assíncrono: n ≥3f+1 [Bracha& Toueg]

F Sistema síncrono: não há limite (n ≥f+2) [Lamport et al.]

• Modelo híbrido:

F Sistema de payload é assíncrono e sujeito a faltas bizantinas F TTCB é síncrona e só pode falhar por paragem

• Temos n

≥

f+2

• Não usa cripto assimétrica

• Eficiente

(15)

3. Consenso e Filiação

Tolerantes a Intrusões

Navigators

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:

F Um para decidir sobre valores que caibam no Serviço de Acordo F Um geral

(16)

31

Contribuições (I)

• Não usa cripto assimétrica

• Baixo número de mensagens enviadas:

Navigators

Contribuições (II)

(17)

33

Serviço de Filiação

• Sistema de comunicação em grupo:

F Paradigma importante para suportar aplicações distribuídas tolerantes a faltas:

– replicação de BDs, serviços com elevada disponibilidade, etc.

F SCG = Serviço de Difusão + Serviço de Filiação

• Serviço de filiação:

F Fornece uma lista (“vista”) dos membros correctos em cada “instante”

• Operações:

F Remoção de um membro falhado ⇒detector de falhas F Entrada de um novo membro

F Saída voluntária de um membro

Navigators

Contribuições (I)

• Valores em trabalhos anteriores: 210/250 ms; 400/500 ms.

0 5 10 15 20 4 5 6 7 Number of processes Time (milliseconds) Protocol time Remove Failed Site Site Join Site Leave

(18)

35

Contribuições (II)

• Crescimento do tempo parece ser lento

F os baseados em criptografia assimétrica têm crescimento rápido e

aparentemente exponencial

• Protocolo “simétrico”:

F As decisões são tomadas por todos os membros (correctos) F Evita ataques que tentam evitar o progresso através de rotação do

“chefe”

Navigators

(19)

37

Conclusão

• Novo modelo de faltas híbrido – TTCB

• Desenho de protocolos baseados nesse

modelo. Contribuições:

F Nos limites de processos que podem falhar F No desempenho

– Não usamos cripto assimétrica que é uma conhecida causa de estrangulamento no desempenho

F Na complexidade temporal e de mensagens

Navigators

Trabalho Futuro

• TTCB

F Concretização usando módulo de hardware F Redesenho do protocolo do Serviço de Acordo F Estudo dos problemas de escalabilidade

• Protocolos

F Sincronia de vistas para se ter um SCG F Difusão atómica

F Replicação de máquina de estados F ...

(20)

39

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

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

• 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 24--26, Boston, USA, October 2000.