Protocolos Tolerantes a Intrusões com base num Modelo de ...
Transcript of 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
NavigatorsSeminá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
– 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
NavigatorsSeminário Doutoral FC/UL
1. Modelo de Faltas Híbrido. A TTCB
4
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
TTCB Control Channel
Payload Network
Host n
LocalTTCB
Processes
OS
Host 2
OS LocalTTCB
ProcessesHost 1
OS LocalTTCB
Processes
4
7
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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)
TTCB Control Channel
Payload Network
Host n
LocalTTCB
Processes
OS
Host 2
OS LocalTTCB
ProcessesHost 1
OS LocalTTCB
Processes
5
9
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
Arquitectura da TTCB baseada em COTS
NavigatorsSeminário Doutoral FC/UL
2. Protocolo de Difusão Fiável
9
17
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
MedidasBRM
IPmcast
Valor típico em trabalhos anteriores: ~50ms
28
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
3. Consenso e FiliaçãoTolerantes a Intrusões
30
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
Contribuições (I)• Não usa cripto assimétrica• Baixo número de mensagens enviadas:
32
NavigatorsSeminário Doutoral FC/UL
Contribuições (II)• Baixa complexidade temporal:
17
33
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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”
NavigatorsSeminário Doutoral FC/UL
4. Conclusão e Trabalho Futuro
19
37
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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
NavigatorsSeminário Doutoral FC/UL
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.