Protocolos Tolerantes a Intrusões com base num Modelo de ...

1

NavigatorsSeminário Doutoral FC/UL

Protocolos Tolerantes a Intrusões com base num Modelo

de Faltas HíbridoMiguel P. Correia

Seminário Doutoral12 de Dezembro de 2002

2


Sumário• Modelo de faltas híbrido baseado numa

componente inovadora – a TTCB• Protocolo de difusão fiável tolerante a intrusões

– BRMF 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ídoF serviço de filiação “rápido”

2


1. Modelo de Faltas Híbrido. A TTCB

4


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

LocalTTCB

Processes

OS

Host 2

OS LocalTTCB

ProcessesHost 1

OS LocalTTCB

Processes

6


O Modelo TTCB• Trusted Timely Computing BaseFComponente distribuída com a sua própria rede/canalF Segura, só pode falhar por paragem

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


Payload Network

Host n

LocalTTCB

Processes

OS

Host 2

OS LocalTTCB

ProcessesHost 1

OS LocalTTCB

Processes

4

7


Tolerância a Intrusões• Segurança tradicional:FRemover vulnerabilidadesF Prevenir que ataques conduzam a intrusões

• Tolerância a intrusõesF Assume-se que o sistema permanece vulnerável...F ... e que ataques às componentes ocorrem e conduzem a

intrusões

FGarante-se que o sistema globalmente permanece seguro e operacional

8


Para que serve a TTCB?• Suportar a execução de protocolos /

aplicações tolerantes a intrusões:FCorrem no sistema de payload (pode ser atacado)FUsam a TTCB para executar passos críticos (segura)


Payload Network

Host n

LocalTTCB

Processes

OS

Host 2

OS LocalTTCB

ProcessesHost 1

OS LocalTTCB

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çosF Segura ⇒ simples para se poder verificar

• Logo oferece um conjunto limitado de serviços

10


Serviço de Autenticação Local• Cria um canal seguro processo–TTCB Local• Objectivos:F Processos autenticarem a TTCBF Estabelecer chave simétrica partilhada processo–TTCB

• Cada TTCB Local tem um par de chaves assimétricoF Assume-se que os processos conseguem obter uma cópia correcta da

chave pública

• Protocolo: processoà TTCB : Eu(Ket, Xe)

TTCB à processo : Sr(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 acordosF A TTCB tem recursos limitadosF Trabalha com pequenos blocos de dados (actualmente 20 bytes)F Ex.: BRM

• Serviço mais importante para protocolos tolerantes a intrusões

12


Serviço de Acordo (cont.)• Processo faz duas operações: propose,

decide• Um acordo é definido por (elist, tstart,

decision)F elist: lista dos processos envolvidosF tstart: instante quando a TTCB deixa de aceitar propostas e o

acordo “começa” a correrF 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:FGeraçã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)

14


TTCB baseada em COTS

• A primeira concretização da TTCB é baseada em COTS:F PCsFNúcleo tempo-real: RT Linux / RTAIF Fast-Ethernet

• Ideias básicas:F TTCB Local dentro do núcleoF Proteger o núcleo (removendo vulnerabilidades )F Proteger acesso à rede da TTCB

• Cobertura das hipóteses... Fácil de instalar

8

15


Arquitectura da TTCB baseada em COTS


2. Protocolo de Difusão Fiável

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

18


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 mensagensF Se o remetente de uma mensagem é correcto, então todos os

processos correctos entregam a mensagem

20


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)

FUsa o Serviço de Acordo da TTCB para fornecer aos receptores um hash da mensagem

• Todos os processos:FUsam o resultado do Serviço de Acordo para saberem os

processos que forneceram o hash certo

F Se todos o fizeram o protocolo termina imediatamente

11

21


Exemplo: melhor caso (só 1ª fase)

P0

P3

P1

P2

TTCB agreement

tstart

propose

decide

DAT msg Od = kmsg delivery

M

H(M)H(M), all proposed ok

22


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

FOu até ter enviado Od+1 vezes– Os processos que não receberem são considerados falhados

24


Exemplo: remetente malicioso

P0

P3

P1

P2

TTCB agreement

tstart

propose

decide

DAT msg

ACK msg

Od = 1msg delivery

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 = 1msg delivery

msg lost

H(M)H(M)

Od+1Od+1

26


Avaliação do Desempenho• TTCB baseada em COTS:F 5 PCs: Pentium III, 450 MHz, 64 Mbytes RAMF Real-Time LinuxF 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• Os valores são médias de 4500 medidas

14

27


MedidasBRM

IPmcast

Valor típico em trabalhos anteriores: ~50ms

28


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 bizantinasF 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çãoTolerantes a Intrusões

30


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:FUm para decidir sobre valores que caibam no Serviço de AcordoFUm geral

16

31


Contribuições (I)• Não usa cripto assimétrica• Baixo número de mensagens enviadas:

32


Contribuições (II)• Baixa complexidade temporal:

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 falhasF Entrada de um novo membroF Saída voluntária de um membro

34


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

Tim

e (m

illis

econ

ds)

Protocol timeRemove Failed SiteSite JoinSite 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”


4. Conclusão e Trabalho Futuro

19

37


Conclusão• Novo modelo de faltas híbrido – TTCB• Desenho de protocolos baseados nesse

modelo. Contribuições:FNos limites de processos que podem falhar

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

estrangulamento no desempenho

FNa complexidade temporal e de mensagens

38


Trabalho Futuro• TTCBFConcretização usando módulo de hardwareFRedesenho do protocolo do Serviço de Acordo

F Estudo dos problemas de escalabilidade

• ProtocolosF Sincronia de vistas para se ter um SCG

FDifusão atómicaFReplicação de máquina de estadosF ...

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.

Protocolos Tolerantes a Intrusões com base num Modelo de ...

Documents

Transcript of Protocolos Tolerantes a Intrusões com base num Modelo de ...