Sie sind auf Seite 1von 13

Detectando Falhas Bizantinas em Sistemas Distribudos Dinmicos

Murilo Santos de Lima


Departamento de Cincia da Computao Instituto de Matemtica e Estatstica Universidade de So Paulo (USP) Rua do Mato, 1010, Cidade Universitria 05508-090 So Paulo SP Brazil mslima@ime.usp.br

Fabola Gonalves Pereira Greve


Departamento de Cincia da Computao Instituto de Matemtica Universidade Federal da Bahia (UFBA) Av. Adhemar de Barros, S/N, Campus de Ondina 40170-110 Salvador BA Brazil fabiola@dcc.ufba.br

Resumo
Em um sistema distribudo dinmico, no qual os ns podem entrar e sair da rede aleatoriamente, o desao de implementar servios conveis grande. Nesse contexto, um fator preocupante, em especial, a segurana. Detectores de falhas bizantinas (ou arbitrrias) so uma soluo elegante para problemas de segurana, uma vez que separam o tratamento das falhas do protocolo distribudo que os utiliza. No entanto, desconhecem-se trabalhos na literatura descrevendo solues especcas para sistemas dinmicos. Este artigo prope um detector de falhas bizantinas para tais sistemas. Adicionalmente, o protocolo apresentado assncrono, isto , no se baseia no uso de temporizadores para a deteco das falhas, o que favorece sua escalabilidade e adaptabilidade. Palavras-chave: detectores de falhas, falhas bizantinas, sistemas distribudos dinmicos, sistemas autoorganizveis, detectores de falhas assncronos

Keywords: failure detectors, Byzantine failures, dynamic distributed systems, self-organizing systems, asynchronous failure detectors

Abstract
Byzantine failure detectors provide an elegant abstraction for solving security problems. However, as far as we know, there is no complete solution for this problem in a dynamic distributed system. This paper presents thus a rst Byzantine failure detector for this context. The protocol has the interesting feature to be asynchronous, that is, the failure detection process does not rely on timers to make suspicions. This characteristic favors its scalability and adaptability.
Uma

verso preliminar deste trabalho foi apresentada no SBRC 2009. O trabalho tem apoio da FAPESB-Bahia e do CNPq-Brasil. Murilo Bacharel em Cincia da Computao pela Universidade Federal da Bahia e este trabalho resultado do seu projeto de nal de curso. Parte deste trabalho foi desenvolvido por Murilo no Instituto Recncavo de Tecnologia Salvador Bahia Brasil.

1. I NTRODUO Um sistema distribudo dinmico [1] composto por uma populao de ns1 que podem entrar e sair da rede aleatoriamente, a qualquer momento da execuo do sistema. Comumente, as seguintes caractersticas so apresentadas: (1) a latncia na transmisso das mensagens imprevisvel, (2) a rede no est totalmente conectada, (3) no existem elementos centralizadores na rede, (4) no possvel prover aos processos uma viso global da topologia da rede, de forma que cada n tem um conhecimento parcial da composio do sistema e (5) os ns podem alterar sua posio quanto topologia da rede. Constata-se, portanto, que os protocolos distribudos clssicos, que supem uma rede com composio esttica e conhecida, no so mais adequados neste novo contexto, caracterstico das redes entre pares (P2P), redes mveis auto-organizveis (Manets) e redes de sensores sem o. Um fator preocupante em sistemas distribudos dinmicos, em especial, a segurana. A dinamicidade da populao dos ns e o uso comum de redes sem o ou da Internet como meios de comunicao facilitam a ao de agentes maliciosos sobre o sistema. O modelo de falhas bizantinas [2] lida com este tipo de ataque ao considerar a existncia de processos corruptos, que podem se comportar de maneira arbitrria na tentativa de impedir que o sistema funcione conforme a sua especicao. Um processo bizantino pode, por exemplo, tentar assumir
1 Neste

trabalho, os termos n e processo sero utilizados indistintamente.

Murilo de Lima e Fabola Greve

Detectando Falhas Bizantinas em Sistemas Distribudos Dinmicos

a identidade de outro, enviar mensagens com valores incorretos, duplicar mensagens ou simplesmente no enviar mensagens que o protocolo em execuo especicar. O desenvolvimento de sistemas tolerantes a faltas bizantinas [3], isto , que mantenham o seu funcionamento correto apesar do comportamento maligno de alguns de seus processos, portanto de especial interesse. A abstrao de detectores de falhas [4] prov uma forma modular de tratar as falhas em sistemas assncronos, isto , sistemas que no atendam a restries temporais. O detector separa o tratamento das falhas e os requisitos de sincronia do protocolo distribudo que o utiliza, de forma que este pode lidar apenas com a tarefa a que se prope. O problema do consenso [5], por exemplo, que sumariza diversos problemas de acordo distribudo, no pode ser resolvido num sistema sem quaisquer suposies de sincronia, mesmo se apenas um processo falhar por colapso (crash) [6]. Se o sistema dispe, no entanto, de um detector da classe S [4], o consenso pode ser resolvido para falhas por colapso sem lidar diretamente com questes de sincronia. A grande maioria das implementaes para detectores de falhas considera a existncia de uma rede esttica, cuja composio dos ns conhecida [7]. Mais recentemente, algumas propostas foram feitas para sistemas mveis e auto-organizveis. Em [8], Gupta et al. consideram uma populao dinmica dos ns; j Friedman e Tcharny [9] toleram a mobilidade dos ns. Todas essas propostas utilizam um mecanismo de temporizao para deteco das falhas, i.e., os ns monitoram a vivacidade dos demais ns da rede atravs da troca de mensagens do tipo eu estou vivo". Esse mecanismo, no entanto, no se adqua muito bem a sistemas distribudos dinmicos, devido imprevisibilidade na latncia da transmisso das mensagens. Detectores de falhas assncronos no fazem uso do recurso de temporizao. Nessa linha, um trabalho pioneiro foi apresentado por Mostefaoui et al. [10]. Entretanto, ele considera uma rede esttica com composio dos ns conhecida. Em [11], Sens et al. apresentam uma implementao assncrona de um detector de falhas que trata tanto a dinamicidade da composio da rede quanto a mobilidade dos ns. Todos esses trabalhos, no entanto, so focados na deteco de falhas por colapso, i.e., quando um processo se comporta de maneira benigna at falhar e haver o trmino da execuo. Alguns trabalhos [12, 13] so voltados para deteco de falhas bizantinas. Entretanto, nenhum deles lida com a dinamicidade do sistema e mobilidade dos seus ns. Alm disso, todos fundamentam-se no uso de temporizadores. Os autores desconhecem, portanto, trabalhos que proponham detectores de falhas bizantinas especcos para sistemas distribudos dinmicos e tambm desconhecem detectores de falhas bizantinas que sejam assncronos. Existem trabalhos voltados para problemas es2

peccos, como o caso de Awerbuch et al. [14], que resolvem a deteco para o roteamento, ou ento, o de Aguilera et al. [15] que s toleram falhas de omisso e no consideram falhas de segurana. Este artigo apresenta, ento, o primeiro protocolo para deteco de falhas bizantinas em sistemas dinmicos e que, alm disso, tem a caracterstica de ser assncrono. O protocolo tem por base as abordagens descritas por Kihlstrom et al. [12] para falhas bizantinas e Sens et al. [11] para a deteco assncrona. Assim, as falhas de segurana so detectadas atravs da denio de um formato preestabelecido para as mensagens trocadas pelos processos. Estas devem ser autenticadas e seu contedo certicado. Quanto s falhas de omisso, a deteco se baseia no padro de mensagens imposto pelo algoritmo que utiliza o detector, o que razovel, uma vez que as falhas bizantinas so denidas como desvio do comportamento especicado pelo algoritmo [16]. A deteco assncrona possvel graas ao padro de troca de mensagens, topologia da rede e a certas propriedades comportamentais seguidas pelos processos no sistema. O protocolo no tolera, entretanto, a mobilidade dos ns. A deteco assncrona, na qual o protocolo se baseia, evidenciou dois importantes resultados. Primeiro, conjectura-se ser impossvel projetar algoritmos distribudos assncronos tolerantes a falhas bizantinas sem que o padro de troca de mensagens entre os processos seja distribudo. Alm disso, conclui-se que o uso da difuso local em canais conveis, comum em redes sem o, simplica o tratamento das falhas de segurana, de forma que determinadas classes de falhas no se conguram no sistema. O restante deste artigo encontra-se estruturado da seguinte forma: na Seo 2, dene-se o modelo de sistema. Uma caracterizao do modelo de falhas bizantinas apresentada na Seo 3. As Sees 4-6 apresentam o protocolo desenvolvido, as propriedades comportamentais que o sistema deve atender para que o protocolo funcione corretamente e sua implementao. A prova da sua correo exibido na Seo 7. Por m, na Seo 8 apresentam-se as concluses e propostas de trabalhos futuros.

2. M ODELO DE SISTEMA
Supe-se um sistema distribudo composto por um conjunto = {p1 , p2 , . . . , pn } com n > 4 processos. Ns podem entrar e sair da rede aleatoriamente, a qualquer momento da execuo do sistema. No so feitas quaisquer restries sobre a velocidade dos processadores, sobre o desvio relativo dos relgios ou sobre os atrasos de transmisso das mensagens; isto , supe-se um sistema assncrono. Supe-se a ocorrncia de falhas bi-

Murilo de Lima e Fabola Greve

Detectando Falhas Bizantinas em Sistemas Distribudos Dinmicos

zantinas: os processos podem falhar de maneira arbitrria, inclusive maliciosa; supe-se entretanto a existncia de um mecanismo de autenticao de mensagens. Os processos no tm conhecimento de ou n, apenas de um subconjunto de com os quais estabeleceram comunicao anteriormente. O nmero mximo de falhas tolerado f conhecido por todos os processos. Supe-se, para simplicao das denies e demonstraes apresentadas, a existncia de um tempo global t, embora o mesmo no seja conhecido pelos processos. Cada processo identicado unicamente e processos faltosos no podem obter mais de um identicador, de forma que impossvel a ocorrncia de ataques sybil [17]. Os processos trocam mensagens por difuso local (broadcast) atravs de uma rede de comunicao sem o. Supe-se a existncia de canais locais conveis, de forma que as mensagens difundidas so recebidas em algum momento no futuro por todos os processos corretos dentro da rea de cobertura (range) do transmissor. Os canais no duplicam, alteram ou inserem novas mensagens e todo processo correto autentica suas mensagens de forma incorruptvel. Implementaes de comunicao por difuso em canais conveis para redes sem o encontram-se em [18, 19]. O sistema pode ser representado por um grafo nodirecionado G(V, E ), sendo V = e {pi , pj } E se pi e pj encontram-se no range um do outro (pi e pj so denominados vizinhos). A rea de cobertura rangei de um n pi denida pelo conjunto rangei := {pj : (pi , pj ) E }. Note-se rangei corresponde vizinhana de pi em G, |rangei | equivale ao grau de pi em G e que pi rangej pj rangei . Ou seja, a comunicao entre os processos simtrica. Denio 1 (Densidade da rea de cobertura (d)) A densidade d de um grafo de comunicao G(V, E ) consiste no tamanho do menor range da rede, isto : d := min {|rangei | : i {1, 2, ..., n}}. d portanto o grau mnimo do grafo G. Considera-se que o parmetro d da rede conhecido por todos os processos. Denio 2 (Rede com f -cobertura bizantina) Uma rede de comunicao representada pelo grafo G(V, E ) tem f -cobertura bizantina se e somente se G (f + 1)conexo e d 2f + 1. Um grafo k -conexo possui k caminhos distintos nos vrtices entre quaisquer par de vrtices, o que leva seguinte observao: Observao 1 Em uma rede com f -cobertura bizantina, apesar da presena de f < n processos faltosos, existir pelo menos um caminho formado apenas por ns corretos entre cada par de ns corretos. 3

3. FALHAS BIZANTINAS A identicao das falhas bizantinas caracterizada pela satisfao de dois requisitos: (1) os processos corretos devem possuir uma viso coerente das mensagens enviadas por cada processo e (2) os processos corretos devem poder vericar se as mensagens enviadas pelos demais processos esto consistentes com os requisitos do algoritmo sendo executado, o que evidencia que a deteco de falhas bizantinas denida em funo de determinado algoritmo ou protocolo. O primeiro requisito pode ser atendido utilizando duas tcnicas distintas: a redundncia da informao e o uso de assinaturas digitais noforjveis [2]. O segundo, pela adio de informao s mensagens, na forma de certicados, que possam ser utilizados para validar o contedo sendo transmitido [12]. A Figura 1 ilustra as classes de falhas bizantinas descritas por Kihlstrom et al. [12], distinguindo-se duas superclasses: detectveis, quando comportamento externo do processo faltoso fornece evidncias de que o mesmo falhou e no-detectveis, caso contrrio. Falhas nodetectveis podem ser subdivididas em no-observveis, quando os demais processos no podem notar a ocorrncia da falha (por exemplo, um processo faltoso informa um parmetro fornecido pelo usurio incorretamente) e no-diagnosticveis, quando no possvel identicar o processo que gerou a falha (por exemplo, os processos recebem uma mensagem no assinada). As falhas detectveis so classicadas em falhas de progresso (ou falhas por omisso) e falhas de segurana (ou falhas por comisso). Falhas de progresso atrapalham a terminao da computao, uma vez que o processo faltoso no envia mensagens requeridas por sua especicao ou as envia a apenas parte dos processos do sistema. Falhas de segurana violam propriedades invariantes s quais os processos devem atender, podendo ser denidas como o no-cumprimento de uma das seguintes restries: (1) um processo deve enviar as mesmas mensagens para todos os outros (um processo faltoso poderia, portanto, enviar a mesma mensagem com valores distintos para processos distintos); (2) as mensagens enviadas devem estar de acordo com o algoritmo sendo executado.
Propriedades do detector de falhas. Kihlstrom et al. [12] tambm denem classes de detectores de falhas bizantinas que diferem das descritas por Chandra e Toueg [4], uma vez que ali so detectadas apenas falhas por colapso. Seja A um algoritmo que utiliza o detector de falhas como mdulo subjacente. A classe S (Byz, A), que o foco deste trabalho, denida pelas seguintes propriedades: (i) Completude forte bizantina (para algoritmo A): em algum momento no futuro todo processo correto suspeita permanentemente de todo processo que se desviou de A

Murilo de Lima e Fabola Greve

Detectando Falhas Bizantinas em Sistemas Distribudos Dinmicos

Figura 1. Categorizao das falhas bizantinas [12]

de forma detectvel; (ii) Preciso fraca aps um tempo: em algum momento no futuro, um processo correto no ser suspeito por qualquer processo correto.

BSICOS DO PROTO COLO DE DETECO ASSNCRONA DE FA LHAS BIZANTINAS

4. P RINCPIOS

Nesta seo so apresentados os princpios fundamentais para o projeto do detector assncrono para falhas bizantinas.

4.1. PADRO DE TROCA DE MENSAGENS Grande parte dos protocolos de deteco de falhas por colapso baseiam-se num mecanismo de troca de mensagens do tipo eu estou vivo (Im alive). Entretanto, no modelo bizantino, devido ocorrncia de processos maliciosos, tal mecanismo no mais suciente. Um processo faltoso pode responder corretamente s mensagens do detector de falhas sem no entanto garantir o progresso e a segurana do algoritmo sendo executado. Conseqentemente, a deteco das falhas deve se basear no padro das mensagens enviadas na execuo do algoritmo A que utiliza o detector de falhas. Assim sendo, de forma similar ao feito por Kihlstrom et al. [12], as suspeitas so levantadas em funo das mensagens requeridas por A. Entretanto, neste trabalho tais suspeitas so identicadas de maneira assncrona, sem recorrer ao uso de temporizadores (mecanismos de timeout) para detectar falhas de omisso. Alm disso, a deteco segue um padro de troca de mensagens local, ou seja, entre os ns que se encontram na vizinhana. A deteco assncrona das falhas feita aguardandose a recepo de determinada mensagem a partir de (d f ) remetentes distintos. (d f ) corresponde quantidade mnima de ns corretos na vizinhana de determinado n na rede. Esta estratgia a mesma seguida por Sens et al. [11]. Entretanto, o padro de mensagens QUERY4

RESPONSE , no qual eles se fundamentam, no adequado ao modelo bizantino, pois, como dito anteriormente, um processo faltoso pode enviar mensagens RESPONSE sem no entanto atender aos requisitos de progresso do algoritmo A. O protocolo aqui apresentado ir, portanto, efetuar as suas suspeitas com base na troca de mensagens requeridas por A. Assim, prope-se que os processos aguardem a recepo das mensagens de A a partir de pelo menos (d f ) remetentes distintos, suspeitando-se da omisso dos demais processos. importante observar que para que tal suspeita possa ser feita, o padro de comunicao do algoritmo A deve ser distribudo. Ou seja, em cada passo, todos processos devem trocar mensagens entre si, seguindo o padro n n. Protocolos com esse padro so denominados simtricos. Como o detector segue um padro local de troca de mensagens, essa comunicao deve ocorrer pelo menos entre os processos que esto na mesma vizinhana. Algoritmos de consenso simtricos que utilizam um detector de falhas S foram sugeridos por Guerraoui e Raynal [20]. Um outro aspecto importante a considerar que a deteco segue um padro assncrono. Como as suspeitas so feitas com base no padro de troca de mensagens do algoritmo, conjectura-se ser impossvel realizar a deteco de falhas por omisso se tal padro do tipo 1 n. Ou seja, se, em algum momento da execuo do algoritmo, requer-se que apenas um processo envie mensagens. Isto porque no haveria como diferenciar uma falha por omisso de um retardo na recepo da mensagem proveniente de tal processo, dado que o sistema subjacente assncrono [4]. Portanto, identicamos a seguinte conjectura, que se correta deriva o seguinte corolrio:

Conjectura 1 Num sistema assncrono, impossvel detectar falhas bizantinas por omisso, de forma assncrona, caso o padro de troca de mensagens do algoritmo A seja do tipo 1 n; isto , se em determinado momento, o algoritmo A determina que apenas um processo envia mensagens aos demais (n). Corolrio 1 A forma assncrona da deteco de falhas bizantinas s pode ser adotada por protocolos simtricos,

Murilo de Lima e Fabola Greve

Detectando Falhas Bizantinas em Sistemas Distribudos Dinmicos

nos quais todos os ns executam o mesmo papel. 4.2. G ERAO DE SUSPEITAS E EQUVOCOS Gerao de suspeitas. Cada suspeita (suspicion) sobre um processo pi associada a uma mensagem m requerida por A. Requer-se, portanto, que as mensagens recebam identicadores nicos. As suspeitas so propagadas na rede e um processo correto adotar uma suspeita no gerada por ele prprio se e somente se receber pelo menos f + 1 ocorrncias devidamente autenticadas provenientes de processos distintos. O requisito de pelo menos f + 1 ocorrncias impede que processos maliciosos imponham suspeitas sobre processos corretos. A Figura 2 ilustra esse mecanismo para determinada poro da rede, supondo f = 1. Os vizinhos de um processo p1, faltoso por omisso, percebero que p1 no est enviando as mensagens que deveria. Numa rede com f -cobertura bizantina, pelos menos dois (f + 1) dos processos vizinhos a p1, neste caso p2 e p3, sero corretos e divulgaro uma suspeita de falha S para seus respectivos vizinhos. Qualquer processo correto da rede, por exemplo, p10, ter pelo menos um caminho para p2 (p10p9 p5p2) e p3 (p10p3) formado apenas por processos corretos (vide Observao 1), recebendo pelo menos duas (f + 1) ocorrncias de S , adotando portanto a suspeita. Gerao de equvocos. Seja pi um processo suspeito de no ter enviado uma mensagem m. Se em algum momento um processo correto pj receber m de pi , pj declarar um equvoco (mistake) sobre a suspeita e difundir a mensagem m aos demais, a m de que faam o mesmo. Na Figura 3, um processo lento p1, sobre o qual foi levantada uma suspeita, envia a mensagem requerida m (representada pelo envelope) a um processo correto p2. Numa rede com f -cobertura bizantina, haver pelo menos um caminho formado apenas por processos corretos de cada processo correto at p2. Por exemplo, para p10, temos o caminho p2p5 p9p10. Logo p10 (e qualquer outro processo correto) receber m e poder retirar sua suspeita correspondente. Esse procedimento permite que um processo malicioso, de forma intermitente, provoque uma suspeita e em seguida a revogue, levando-se a um mascaramento de parte das falhas por omisso e a uma degradao do desempenho do detector de falhas. No possvel, no entanto, distinguir um processo com este comportamento de um processo lento ou de um perodo de instabilidade no canal de comunicao.

mensagem deve tambm incluir um certicado que possibilite aos demais processos vericar a coerncia da mesma com o algoritmo A. Caso um processo correto detecte a invalidade de uma mensagem recebida, seja por no atender ao formato ou por no estar devidamente justicada, suspeitar permanentemente do processo remetente e encaminhar a mensagem original aos demais processos, de forma que a suspeita seja propagada. A Figura 4 representa essa situao: um processo faltoso p1 comete uma falha de segurana divulgando uma mensagem corrompida m (representada pelo asterisco). A falha detectada por um vizinho correto p2, que encaminha a mensagem corrompida para o restante da rede. Uma vez que para cada processo correto h um caminho formado apenas por processos corretos at p2 (para p10, o caminho p10p9 p5p2), todos suspeitaro permanentemente de p1. No protocolo, suspeitas, equvocos e provas de falhas de segurana so todos encaminhados atravs de uma nica mensagem do tipo SUSPICION, as quais no precisam ser certicadas. Mensagens que no estejam devidamente autenticadas so descartadas, uma vez que conguram uma falha no-diagnosticvel (ver Seo 3). O detector, portanto, no comete erros na deteco das falhas de segurana do algoritmo A. No protocolo de Kihlstrom et al. [12], adicionalmente, necessrio detectar quando um processo encaminha duas verses diferentes da mesma mensagem, ou seja, mensagens mutantes. Para isto requer-se, de um lado, que os processos corretos reencaminhem para todos os demais cada mensagem recebida, e, por outro lado, seja gerado um histrico das mensagens provenientes de cada processo. Supe-se, no entanto, que a comunicao entre os processos ponto a ponto. No modelo aqui proposto, em que os processos se comunicam apenas por difuso local em canais conveis, natural supor que uma mensagem transmitida ser recebida, com contedo idntico, por todos os processos corretos, de forma que impossvel a ocorrncia de mensagens mutantes. Chega-se, portanto, seguinte observao: Observao 2 Em um ambiente de falhas bizantinas, a suposio de comunicao por difuso (broadcast) em canais conveis simplica o tratamento das falhas de segurana, uma vez que os processos vizinhos do remetente tm uma viso consistente das mensagens enviadas pelo mesmo.

4.3. D ETECO DE FALHAS DE SEGURANA Para ser possvel a deteco das falhas de segurana, um formato de mensagens deve ser estabelecido. Cada 5

5. P ROPRIEDADES COMPORTAMENTAIS DO SISTEMA Para que o protocolo proposto neste trabalho detecte as falhas de maneira assncrona e satisfaa as proprieda-

Murilo de Lima e Fabola Greve

Detectando Falhas Bizantinas em Sistemas Distribudos Dinmicos

Figura 2. Gerao de suspeitas no protocolo proposto (f = 1)

Figura 3. Gerao de equvocos no protocolo proposto (f = 1)

Figura 4. Deteco de falhas de segurana no protocolo proposto (f = 1)

Murilo de Lima e Fabola Greve

Detectando Falhas Bizantinas em Sistemas Distribudos Dinmicos

des denidas para a classe S (Byz, A), necessrio que o sistema atenda a certas propriedades comportamentais. Propriedade 1 (Incluso Bizantina (Byz MP )) Seja t t um instante de tempo e KBi o conjunto de processos que receberam uma mensagem SUSPICION de pi at o instante t. Um processo pi satisfaz a propriedade de incluso bizantina Byz MP se: t Byz MP (pi ) := t 0 : |KBi | 2f + 1 Esta propriedade garante que um processo novo pi no sistema em algum momento no futuro ser conhecido por pelo menos 2f + 1 processos, dos quais pelo menos f + 1 sero corretos. Para tanto, necessrio que pi se comunique com pelo menos 2f + 1 processos dentro de sua rea de cobertura, enviando-lhes uma mensagem SUSPICION por difuso. Dessa forma, se pi falhar, em algum momento no futuro pelo menos f + 1 processos corretos suspeitaro de pi e transmitiro a suspeita para o restante do sistema, de forma que a propriedade de completude forte bizantina do detector S (Byz, A) seja atendida. Notese que essas comunicaes devem ser realizadas antes do incio do prximo passo do algoritmo A, de forma a garantir a propriedade de completude forte bizantina do detector de falhas; antes disso, pi no deve ser considerado participante da computao. Se um processo novo no se comunicar com nenhum outro, impossvel atender propriedade de completude fraca [21]. Para que a propriedade de preciso fraca aps um tempo da classe S (Byz, A) seja atendida, necessrio que exista um processo correto pi cujas mensagens a partir de algum momento estejam sempre entre as d f primeiras recebidas pelos seus vizinhos, a cada requisio de A. Assim sendo, aps um tempo pi no ser mais suspeito por nenhum processo correto e ter quaisquer suspeitas anteriores revogadas atravs de mensagens de equvocos. Logo, a rede deve possuir um n correto que atenda propriedade de receptividade bizantina, denida como: Propriedade 2 (Receptividade Bizantina (Byz RP )) Sejam t e u instantes de tempo e seja rec_f romt j o conjunto de pelo menos d f processos dos quais pj recebeu a mensagem requerida por A no ltimo passo em execuo at o instante t. A propriedade Byz RP do processo correto pi denida como: Byz RP (pi ) := u : t > u, pj rangei , pi rec_f romt j

propriedades de f -cobertura bizantina, incluso bizantina e receptividade bizantina descritas anteriormente e que o protocolo executado pelo algoritmo A seja simtrico. Cada processo executa trs tarefas em paralelo, descritas a seguir. Posteriormente so descritas as variveis, primitivas e procedimentos para cada processo pi . T1. Gerao de novas suspeitas (linhas 5-14, Algoritmo 1). Quando o algoritmo A requer que os processos troquem entre si uma mensagem m (linha 6), cada processo pi aguarda receber m de pelo menos d f processos, cujos identicadores so armazenados no conjunto rec_f romi (linhas 7-8). Para os demais processos conhecidos por pi , adicionada uma suspeita interna de falha por omisso (linhas 9-11). Cada mensagem ento vericada quanto sua formao e certicao (linhas 12-14, Algoritmo 1 e 5-16, Algoritmo 2). Mensagens incorretas levam a suspeitas de falhas de segurana (linhas 9-10, Algoritmo 2) e atualizao da sada do detector; mensagens corretas levam gerao de equvocos de possveis suspeitas de falhas por omisso (linhas 12-13, Algoritmo 2). T2. Recepo de mensagens de processos lentos e de mensagens SUSPICION (linhas 16-18, Algoritmo 1). Uma vez que as mensagens enviadas por um processo lento podem ser recebidas aps a gerao das suspeitas pelos seus vizinhos, necessrio que estes identiquem tais eventos separadamente, o que feito por esta tarefa. As mensagens so tratadas de forma similar tarefa T1. O tratamento das mensagens SUSPICION ser explanado adiante. T3. Divulgao do novo estado de suspeitas e equvocos (linhas 20-23, Algoritmo 1). Tarefa executada periodicamente para enviar aos vizinhos de pi (linha 22) a viso de pi quanto s suspeitas (internas e externas), equvocos e provas de falhas de segurana. Os vizinhos de pi recebero esta mensagem na tarefa T2 e trat-la-o da seguinte forma: Atualizao do estado interno (linhas 15 e 18-40, Algoritmo 2). Ao receber uma mensagem SUSPICION de um vizinho q (linha 19), um processo pi atualiza seu estado interno com novas informaes. Suspeitas internas e externas de q so adicionadas ao conjunto de suspeitas externas de pi (linhas 20-31), possivelmente gerando novas suspeitas internas (linhas 32-34, Algoritmo 1). Note-se que ser gerada uma suspeita de falha de segurana do processo q (linhas 9-10) caso a mensagem SUSPICION m esteja malformada ou no justicada. Provas de falhas de segurana e informaes de equvoco so tratadas de forma similar s mensagens recebidas diretamente do remetente (linhas 34 e 38). Algumas otimizaes 7

DE DETECO ASSN CRONA DE FALHAS BIZANTINAS EM SISTE MAS DINMICOS Os Algoritmos 1 e 2 implementam um detector de falhas da classe S (Byz, A), desde que a rede atenda s

6. P ROTOCOLO

Murilo de Lima e Fabola Greve

Detectando Falhas Bizantinas em Sistemas Distribudos Dinmicos

Algoritmo 1 Detector Assncrono de Falhas Bizantinas em Sistemas Dinmicos 1: init: 2: outputi knowni ; extern_suspi [][] 3: intern_suspi mistakei []; byzantinei
4: 5: 6: 7:

Algoritmo 2 Detector Assncrono de Falhas Bizantinas em Sistemas Dinmicos (continuao) 1: procedure AddByzantine(q , m): 2: outputi outputi {q }; 3: byzantinei byzantinei { q, m }
4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21:

8: 9: 10: 11: 12: 13: 14: 15: 16:

Task T1: /* gerao de novas suspeitas */ when pi requer uma mensagem m do wait until receber m devidamente autenticada pela primeira vez de pelo menos (d f ) processos distintos rec_f romi {pj | pi recebeu uma mensagem de pj na linha 7} for all pj (knowni \ rec_f romi ) do AddInternalSusp(pj , m) end for for all mj recebida na linha 7 from pj do ValidateReceived(pj , mj ) end for

Task T2: /* recepo de mensagens de processos lentos e do estado interno de outro processo */ 17: upon receipt of m devidamente autenticada from pj do 18: ValidateReceived(pj , m) Task T3: /* difuso do estado das suspeitas */ loop broadcast SUSPICION, byzantinei , mistakei , intern_suspi , extern_suspi 23: end loop
24: 25: 26: 27: 28: 29: 30: 31: 19: 20: 21: 22:

procedure ValidateReceived(q , m): if m foi enviada diretamente por q then knowni knowni {q } end if if m no est devidamente formada or m no est devidamente justicada then AddByzantine(q , m) else if m.id intern_suspi [q ] or m foi reencaminhada then AddMistake(q , m) end if UpdateSuspicions(q , m) end if procedure UpdateSuspicions(q , m): if m = SUSPICION, byzantineq , mistakeq , intern_suspq , extern_suspq then for all px keys(extern_suspq ) do for all idmx keys(extern_suspq [px ]) devidamente autenticado | idmx / ids(mistakei [px ]) do for all py extern_suspq [px ][idmx ] do AddExternalSusp(px , idmx , py ) end for end for end for for all px keys(intern_suspq ) do for all idmx intern_suspq [px ] devidamente autenticado | idmx / ids(mistakei [px ]) do AddExternalSusp(px , idmx , q ) end for end for for all px keys(mistakeq ) do for all mx mistakeq [px ] devidamente autenticada do ValidateReceived(px , mx ) end for end for for all px , mx byzantineq | mx est devidamente autenticada do ValidateReceived(px , mx ) end for end if

22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40:

/* PROCEDIMENTOS AUXILIARES */ procedure AddInternalSusp(q , m): intern_suspi [q ] intern_suspi [q ] {m.id} outputi outputi {q }

procedure AddExternalSusp(q , idm, ps ): extern_suspi [q ][idm] extern_suspi [q ][idm] {ps } 32: if |extern_suspi [q ][idm]| f + 1 then 33: AddInternalSusp(q , message(idm)) 34: end if procedure AddMistake(q , m): mistakei [q ] mistakei [q ] {m} extern_suspi [q ][m.id] intern_suspi [q ] intern_suspi [q ] \ {m.id} 40: if intern_suspi [q ] = and q, byzantinei then 41: outputi outputi \ {q } 42: end if
35: 36: 37: 38: 39:

Murilo de Lima e Fabola Greve

Detectando Falhas Bizantinas em Sistemas Distribudos Dinmicos

nesse procedimento foram removidas nesta verso do protocolo, a m de simplicar as demonstraes da Seo 7. O leitor interessado poder encontr-las em [22]. VARIVEIS : outputi : armazena a sada do detector de falhas, isto , o conjunto de identicadores dos processos de que pi suspeita terem falhado; knowni : armazena o conjunto dos processos que se comunicaram com pi , isto , sua suposta vizinhana. atualizada a cada recepo de mensagem m, seja m do tipo SUSPICION ou uma mensagem inerente a A; extern_suspi : matriz que armazena suspeitas externas (geradas por outros processos). A matriz indexada por um identicador de processo q e por um identicador de mensagem idm. Cada entrada armazena o conjunto de processos dos quais pi recebeu suspeitas de q no ter enviado a mensagem com identicador idm; intern_suspi : vetor de suspeitas internas. Uma suspeita interna gerada pela no-recepo de uma mensagem requerida por A ou pela existncia de pelo menos f + 1 suspeitas externas sobre um mesmo par processo-mensagem; mistakei : vetor que armazena, para cada processo aplicvel pj , o conjunto de equvocos relacionados a pj , na forma de mensagens requeridas por A sobre as quais foram levantadas suspeitas; byzantinei : conjunto de duplas do tipo processo, mensagem que provam comportamento bizantino do processo associado. A notao p, indica qualquer dupla associada ao processo p; rec_f romi : conjunto de processos dos quais pi recebeu a mensagem requisitada por A. P RIMITIVAS : m.id - retorna o identicador da mensagem m; message(idm) - retorna a mensagem associada ao identicador idm; vericao de boa formao, justicao (certicao do contedo) e autenticao das mensagens; requisio por A de uma determinada mensagem; broadcast m - difunde a mensagem m para os vizinhos de pi ; keys(v ) - retorna o conjunto de ndices de um vetor dinmico v ; ids(s) - retorna o conjunto de identicadores associados s mensagens do conjunto s. P ROCEDIMENTOS AUXILIARES : AddInternalSusp(q , m) (linhas 26-28, Algoritmo 1): adiciona uma suspeita interna sobre o processo q em relao mensagem m; AddExternalSusp(q , idm, ps ) (linhas 30-34, Algoritmo 1): adiciona uma suspeita externa sobre o pro9

cesso q proveniente do processo ps em relao mensagem com identicado idm. Adicionalmente, caso existam f + 1 ou mais suspeitas externas sobre q em relao a message(idm), gera uma suspeita interna equivalente, caso ainda no exista; AddMistake(q , m) (linhas 36-42, Algoritmo 1): adiciona um equvoco sobre a suspeita de q no ter enviado m, retirando todas as suspeitas internas e externas associadas. Caso q no tenha outras suspeitas nem tenha apresentado comportamento bizantino, remove-o da sada do detector de falhas; AddByzantine(q , m) (linhas 1-3, Algoritmo 2): adiciona q permanentemente lista de processos maliciosos (e, conseqentemente, sada do FD), juntamente com a mensagem m associada falha bizantina, servindo como prova da falha; ValidateReceived(q , m) (Algoritmo 2, linhas 5-16): verica a validade (boa formao e justicao) da mensagem m recebida de q , retirando quaisquer suspeitas associadas ao par (q , m), caso m seja vlida, e gerando uma suspeita de falha de segurana, caso contrrio. Adicionalmente, atualiza o conjunto de ns conhecidos por pi (knowni ) e repassa as mensagens ao procedimento a seguir, de forma a atualizar o estado de suspeitas; UpdateSuspicions(q , m) (Algoritmo 2, linhas 18-40): caso m seja do tipo SUSPICION, atualiza o estado interno de pi com as informaes de falhas contidas em m.

7. P ROVA DE CORREO
A correo do algoritmo denida em funo das propriedades de completude forte bizantina e preciso fraca aps um tempo da classe S (Byz, A) de detectores de falhas. Dessa forma, os argumentos so exibidos para cada propriedade separadamente. 7.1. C OMPLETUDE FORTE BIZANTINA Lema 1 Se um processo pi nunca enviar uma mensagem m, jamais algum processo correto efetuar uma chamada ao procedimento AddMistake com parmetros (pi , m). Prova: Suponha-se, por contradio, que algum processo correto pj efetue uma chamada a AddMistake com parmetros (pi , m). Note-se que a nica chamada ao procedimento AddMistake est no procedimento ValidateReceived, na linha 13 do Algoritmo 2. O procedimento ValidateReceived, por sua vez, chamado nos seguintes casos: (1) na recepo de mensagens requeridas por A, seja durante o mecanismo de espera da tarefa T1, seja posteriormente na tarefa T2 (linhas 13 e 18 do Algoritmo 1, respectivamente); (2) na recepo de mensagens SUSPI CION , na tarefa T2; (3) na atualizao do estado interno com informaes de vizinhos (procedimento UpdateSuspicions, linhas 34 e 38 do Algoritmo 2). Em todos os

Murilo de Lima e Fabola Greve

Detectando Falhas Bizantinas em Sistemas Distribudos Dinmicos

casos, a autenticao de m vericada (respectivamente, nas linhas 7 e 17 do Algoritmo 1 e nas linhas 33 e 37 do Algoritmo 2). Desse fato e do uso de canais conveis, um processo bizantino no pode enviar m em lugar de pi . O caso (2), especicamente, no poderia causar uma chamada a AddMistake, j que no existem suspeitas relacionadas a mensagens SUSPICION e mensagens SUSPICION corretas no so reencaminhadas. Em todos os casos, chega-se contradio de ser necessrio que pi envie m em algum momento, do que o lema segue.

Lema 2 Seja pi um processo faltoso por omisso. Em algum momento no futuro, todo processo correto pj em incluir pi permanentemente em outputj . Prova: Seja m a primeira mensagem requerida por A no enviada por pi . Seja t o instante em que A requer m de u pi e u o primeiro instante tal que |KBi | 2f + 1, sendo u KBi como denido na Propriedade 1; um tal instante u existe devido a Byz MP . Tem-se que t u, pois antes de u pi no participava da computao distribuda (ver Seo 5). t Se pj est em KBi , ento pj recebeu uma mensagem do tipo SUSPICION de pi at o instante t, e portanto pi est em knownj , conforme as linhas 17-18 do Algoritmo 1 e 6-8 do Algoritmo 2. Quando A requerer m a pj , este aguardar somente at receber m de d f processos distintos (linhas 6-7 do Algoritmo 1); esse evento acontecer em algum momento, j que no mximo f processos so faltosos e |rangej | d. Como pi no envia m, no ser includo em rec_f romj (linha 8 do Algoritmo 1). Conforme as linhas 9-11 e 27-28 do Algoritmo 1, m.id ser includo em intern_suspj [pi ] e pi em outputj . Uma vez que pi tambm no enviar m em outro momento posterior, pelo Lema 1 e pelas linhas 39-42 do Algoritmo 1, m.id nunca ser removido de intern_suspj [pi ] nem pi de outputj . t Se pj no est em KBi , no entanto, uma vez que a rede possui f -cobertura bizantina, existe ao menos um caminho P formado apenas por processos corretos entre pj t e cada pk correto em KBi ; se houver mais de um tal caminho, tome-se o de latncia total mnima. Prova, por induo no comprimento de P , de que em algum momento pk adicionado a extern_suspj [pi ][m.id]: se P tem comprimento 1, pj vizinho de pk ; nesse caso, em algum momento pk difunde (linha 22 do Algoritmo 1) uma mensagem SUSPICION s com a informao autenticada de que m.id intern_suspk [pi ]; como os canais so conveis, em algum momento pj recebe s na linha 17 do Algoritmo 1. Como pk correto, s estar devidamente autenticada, formada e justicada; pelo Lema 1, m / mistakej [pi ]; assim, pela linha 18 do Algoritmo 10

1 e pelas linhas 15 e 27-31 do Algoritmo 2, pk adicionado a extern_suspj [pi ][m.id] na linha 31 do Algoritmo 1 e a armao vale. Se o comprimento de P maior que 1, pode-se supor por hiptese de induo que a armao vale para o caminho P pj entre pk e um processo correto pl , visto que tal caminho possui comprimento menor que P . Notadamente pl vizinho de pj em P ; por hiptese de induo, em algum momento pk adicionado a extern_suspl [pi ][m.id] e, futuramente, pl difunde (linha 22 do Algoritmo 1) uma mensagem SUSPI CION s com essa informao autenticada por pk ; como os canais so conveis, em algum momento pj recebe s na linha 17 do Algoritmo 1. Como pl correto, s estar devidamente autenticada, formada e justicada; pelo Lema 1, m / mistakej [pi ]; assim, pela linha 18 do Algoritmo 1 e pelas linhas 15 e 20-26 do Algoritmo 2, pk adicionado a extern_suspj [pi ][m.id] na linha 31 do Algoritmo 1 e a armao vale. t Desse fato, de |KBi | 2f + 1 e de existirem no mximo f processos faltosos segue que em algum momento pj executa a linha 33 do Algoritmo 1 e, pelas linhas 27-28, adiciona m.id a intern_suspj [pi ] e pi a outputj . Novamente, segue do Lema 1 que pi nunca ser removido de outputj . Lema 3 Seja pi um processo faltoso por comisso (isto , que cometa uma falha de segurana detectvel). Em algum momento no futuro, todo processo correto pj em , adiciona permanentemente pi a outputj . Prova: Uma falha por comisso consiste no envio por pi de uma mensagem m em desacordo com A, isto , uma mensagem mal formada ou no justicada (ver Seo 3); o uso de comunicao por difuso impede a ocorrncia de mensagens mutantes (ver Seo 4). Alm disso, m uma mensagem autenticada; caso contrrio, congura-se uma falha no-diagnosticvel (ver Seo 3). Devido propriedade de f -cobertura bizantina, existe um caminho P , entre pi e cada processo correto pj , formado apenas por processos corretos, exceto por pi ; se houver mais de um tal caminho, tome-se o de latncia total mnima. Prova, por induo no comprimento de P , de que em algum momento pj adiciona pi , m a byzantinej e pi a outputj : se o comprimento de P 1, ento pj rangei e, j que os canais so conveis e m autenticada, pj recebe m em algum momento na linha 7 ou na linha 17 do Algoritmo 1. Em ambos os casos, feita uma chamada ao procedimento ValidateReceived (linhas 13 e 18 do Algoritmo 1), que verica na linha 9 do Algoritmo 2 a invalidade de m. O procedimento AddByzantine (linhas 1-3 do Algoritmo 2), por sua vez, adiciona pi a outputj e pi , m a byzantinej , do que a armao segue. Se o comprimento de P maior que 1, a armao vlida por hiptese de induo para o caminho P pj

Murilo de Lima e Fabola Greve

Detectando Falhas Bizantinas em Sistemas Distribudos Dinmicos

entre pi e algum processo correto pk vizinho de pj . Nesse caso, pi , m est em byzantinek e, em algum momento posterior, pk difunde (linha 22 do Algoritmo 1) uma mensagem SUSPICION s com essa informao; como os canais so conveis, em algum momento pj recebe s na linha 17 do Algoritmo 1. Como pl correto, s estar devidamente autenticada, formada e justicada; assim, por m ser autenticada, pela linha 18 do Algoritmo 1 e pelas linhas 15 e 37-39 do Algoritmo 2, pj efetua uma chamada a ValidateReceived que conrma a invalidade de m; portanto pi adicionado a outputj e pi , m a byzantinej e a armao vale. Desse fato e uma vez que pj s remove pi de outputj se no houver um par pi , em byzantinej (linhas 40-42 do Algoritmo 1), pi adicionado denitivamente a outputj e o lema segue.

7.2. P RECISO FRACA APS UM TEMPO Lema 4 Se pi e pj so processos corretos ento, durante toda a computao, pj jamais efetua uma chamada ao procedimento AddByzantine tendo pi como primeiro parmetro. Prova: Note que a nica chamada a AddByzantine est na linha 10 do Algoritmo 2, no procedimento ValidateReceived. Conforme a linha 9, essa chamada s efetuada por um processo correto se pi enviar uma mensagem mal formada ou no justicada, o que no possvel, uma vez que pi correto. Se um processo bizantino enviar uma tal mensagem no lugar de pi , pj a descartar, uma vez que os canais de comunicao so conveis e pj verica a autenticao de toda mensagem que recebe (linhas 7 e 17 do Algoritmo 1 e linhas 33 e 37 do Algoritmo 2), logo o lema segue.

efetua a chamada a AddInternalSusp da linha 10 com parmetros (pi , m). Em ambas as situaes, o caso (1) conrma o lema. Quanto ao caso (2), note-se que chamadas a AddExternalSusp s so realizadas nas linhas 23 e 29 do Algoritmo 2. Uma vez que um processo correto s atualiza seu conjunto extern_susp no procedimento AddExternalSusp, toda suspeita externa proveniente de um processo correto foi gerada como uma suspeita interna (ver linhas 22 e 28 do Algoritmo 1). Pelo argumento do caso (1), um processo correto pj nunca adiciona m.id a intern_suspj [pi ] atravs tarefa T1; se um processo bizantino pk adicionar pj a extern_suspk [pi ][m.id], um processo correto no adotar tal suspeita, uma vez que sua autenticao vericada na linha 21 do Algoritmo 2. Um processo faltoso pj pode, no entanto, adicionar m.id a intern_suspj [pi ] e autenticar essa informao, mas s existem no mximo f processos faltosos, logo nenhum processo correto chama AddInternalSusp na linha 33 do Algoritmo 1 com parmetros (pi , m). Uma vez que todos os casos possveis foram analisados, o lema segue. Lema 6 Seja pi um processo correto. Se existe um mensagem m e um processo correto pj tal que m.id intern_suspj [pi ] em algum instante da computao, ento em algum momento no futuro pj efetua uma chamada a AddMistake com parmetros (pi , m). Prova: Se pj est em rangei , como pi correto, em algum momento pj recebe m de pi (devidamente autenticada, formada e justicada) na linha 17 do Algoritmo 1. Pela hiptese do lema, m.id intern_suspj [pi ], assim, pelas linhas 18 do Algoritmo 1 e pelas linhas 9 e 12 do Algoritmo 2, pj efetua uma chamada a AddMistake com parmetros (pi , m) na linha 13 do Algoritmo 2. Se pj no est em rangei , por argumento semelhante ao feito no lema anterior, pi / knownj . Ento, algum outro processo correto pk em rangei gerou a suspeita, isto , existe pk em rangei tal que m.id intern_suspk [pi ]. Como a rede possui f -cobertura bizantina, existe um caminho P formado apenas por processos corretos entre pk e pj ; se houver mais de um tal caminho, tome-se o de latncia total mnima. Prova, por induo no comprimento de P , de que em algum momento cada processo pl em P chama AddMistake com parmetros (pi , m) e portanto m mistakel [pi ]: se o comprimento de P zero, P contm apenas pk e, pelo argumento do pargrafo anterior, a armao vale. Se o comprimento de P maior que zero ento, por hiptese de induo, a armao vale para o caminho P pj entre pk e um processo pl e, em algum momento, m mistakel [pi ]. Futuramente, pl difunde uma mensagem SUSPICION s com m devidamente autenticada em mistakel [pi ]; como 11

Lema 5 Seja pi um processo correto e m uma mensagem requerida por A. Se todo n em rangei receber m de pi na linha 7 do Algoritmo 1, jamais algum processo correto pj em efetuar uma chamada a AddInternalSusp com parmetros (pi , m). Prova: O procedimento AddInternalSusp chamado em duas situaes: (1) na tarefa T1, durante a recepo de mensagens requeridas por A e (2) no procedimento AddExternalSusp, ao identicar a ocorrncia de f + 1 ou mais suspeitas externas de pi no ter enviado m. Pela hiptese do lema, processos em rangei adicionam pi a rec_f romj na linha 8 do Algoritmo 1, logo no chamam AddInternalSusp na linha 10 com parmetros (pi , m). Um processo pj fora de rangei no pode receber mensagens diretamente de pi , logo no adiciona pi a knownj em nenhum momento (linhas 6-8 do Algoritmo 2) nem

Murilo de Lima e Fabola Greve

Detectando Falhas Bizantinas em Sistemas Distribudos Dinmicos

os canais so conveis, em algum momento pj recebe s na linha 17 do Algoritmo 1. Como pl correto, s estar devidamente autenticada, formada e justicada e, pela linha 18 do Algoritmo 1 e pelas linhas 19 e 32-36 do Algoritmo 2, pj chama ValidateReceived com parmetros (pi , m). Como pi correto, m est devidamente formada e justicada. Como m foi reencaminhada por pl , pj chama AddMistake com parmetros (pi , m) na linha 13 do Algoritmo 2 (ver linhas 9 e 12-14) e a armao vale; portanto, o lema segue.

Lema 7 Seja pi um processo correto que atenda a Byz RP . Em algum momento no futuro, todo processo correto pj em tal que pi / outputj . Prova: Do Lema 4, arma-se que pi jamais ser adicionado a outputj na linha 2 do Algoritmo 2. Pela propriedade Byz RP , existe um instante t aps o qual toda mensagem m requerida por A recebida pelos vizinhos de pi na linha 7 do Algoritmo 1; do Lema 5 verica-se que pj no adiciona pi a outputj em uma chamada a AddInternalSusp com parmetros (pi , m). Para toda mensagem m requerida por A antes de t, se em algum instante m intern_suspj [pi ], pelo Lema 6, em algum momento futuro pj chama AddMistake com parmetros (pi , m ). Assim, pela linha 39 do Algoritmo 1, em algum momento tem-se que intern_suspj [pi ] = ; pelo Lema 4, no existe pi , em byzantinej , logo pi removido de outputj na linha 41 do Algoritmo 1 e o lema segue.

difuso (broadcast), tpica das redes sem o, simplica o tratamento de falhas bizantinas, uma vez que os processos vizinhos de um remetente tm uma viso uniforme das mensagens por ele enviadas. Especicamente, no necessrio tratar a ocorrncia de mensagens mutantes, isto , quando um mesmo processo envia a mesma mensagem com contedos diferentes para diferentes processos. Objetivam-se como trabalhos futuros (i) estender o protocolo para prover tolerncia mobilidade dos ns; (ii) implementar o protocolo, com o objetivo de avaliar seu desempenho e viabilidade prtica; (iii) provar ou contraexemplicar a impossibilidade de realizao de deteco de falhas de forma assncrona em sistemas sujeitos a falhas bizantinas com comunicao do tipo 1 n.

Referncias
[1] A. Mostefaoui, M. Raynal, C. Travers, S. Patterson, D. Agrawal, and A. El Abbadi. From Static Distributed Systems to Dynamic Systems. In Proc. of the 24th IEEE Symp. on Reliable Distributed Systems, pages 109118, Los Alamitos, CA, USA, 2005. IEEE Computer Society. [2] L. Lamport, R. Shostak, and M. Pease. The byzantine generals problem. ACM Trans. Program. Lang. Syst., 4(3):382401, 1982. [3] M. Castro and B. Liskov. Practical Byzantine Fault Tolerance and Proactive Recovery. ACM Transactions on Computer Systems, 20(4):398461, 2002. [4] T. D. Chandra and S. Toueg. Unreliable failure detectors for reliable distributed systems. J. ACM, 43(2):225267, 1996. [5] M. Correia, P. Verssimo, and N. F. Neves. Byzantine Consensus in Asynchronous Message-Passing Systems: a Survey. In Resilience-building Technologies: State of Knowledge, Deliverable D12, Part Algo, chapter 1. RESIST Network of Excellence, September 2006. [6] M. J. Fischer, N. A. Lynch, and M. S. Paterson. Impossibility of distributed consensus with one faulty process. J. ACM, 32(2):374382, 1985. [7] M. Larrea, A. Fernndez, and S. Arvalo. Optimal implementation of the weakest failure detector for solving consensus. In Proc. of the 19th IEEE Symp. on Reliable Distributed Systems, pages 52 59, Washington, DC, USA, 2000. IEEE Computer Society. [8] I. Gupta, T. D. Chandra, and G. S. Goldszmidt. On scalable and efcient distributed failure detectors. 12

Teorema 1 Os Algoritmos 1 e 2 implementam um detector de falhas da classe S (Byz, A). Prova: O teorema segue dos Lemas 2, 3 e 7 e da denio da classe S (Byz, A) (ver Seo 3).

8. C ONCLUSO E TRABALHOS FUTUROS


Este trabalho apresentou um detector de falhas bizantinas com duas caractersticas inovadoras: (i) ele foi projetado para sistemas distribudos dinmicos, cujo conjunto de participantes na rede desconhecido e, alm disso, (ii) tem a caracterstica de ser assncrono, isto , no se utiliza de temporizadores para a deteco das falhas de progresso. Para que a deteco seja realizada de forma assncrona, conjectura-se ser necessrio que o algoritmo que utiliza o detector de falhas seja simtrico, isto , que a cada passo todos os processos troquem mensagens entre si. Um aspecto interessante que a comunicao por

Murilo de Lima e Fabola Greve

Detectando Falhas Bizantinas em Sistemas Distribudos Dinmicos

In Proc. of the 20th Annual ACM Symp. on Principles of Distributed Computing, pages 170179, New York, NY, USA, 2001. ACM Press. [9] R. Friedman and G. Tcharny. Evaluating failure detection in mobile ad-hoc networks. Int. Journal of Wireless and Mobile Computing, 1(8), 2005. [10] A. Mostefaoui, E. Mourgaya, and M. Raynal. Asynchronous Implementation of Failure Detectors. In Proc. of the 2003 Int. Conf. on Dependable Systems and Networks, page 351, Los Alamitos, CA, USA, 2003. IEEE Computer Society. [11] P. Sens, F. Greve, L. Arantes, M. Bouillaguet, and V. Simon. Um Detector de Falhas Assncrono para Redes Mveis e Auto-Organizveis. In Anais do Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos, Rio de Janeiro, RJ, Brazil, 2008. Sociedade Brasileira de Computao. [12] K. P. Kihlstrom, L. E. Moser, and P. M. MelliarSmith. Byzantine Fault Detectors for Solving Consensus. The Computer Journal, 46(1):1635, 2003. [13] R. Baldoni, J.-M. Hlary, and S. T. Piergiovanni. A Component-Based Methodology to Design Arbitrary Failure Detectors for Distributed Protocols. In Proc. of the 10th IEEE Int. Symp. on Object and Component-Oriented Real-Time Distributed Computing, pages 5161, Washington, DC, USA, 2007. IEEE Computer Society. [14] B. Awerbuch, D. Holmer, C. Nita-Rotaru, and H. Rubens. An on-demand secure routing protocol resilient to byzantine failures. In Proc. of the 1st ACM Workshop on Wireless Security, pages 2130, New York, NY, USA, 2002. ACM. [15] M. K. Aguilera, W. Chen, and S. Toueg. Heartbeat: A Timeout-Free Failure Detector for Quiescent Reliable Communication. In Proc. of the 11th Int. Workshop on Distributed Algorithms, pages 126 140, London, UK, 1997. Springer-Verlag. [16] D. Malkhi and M. Reiter. Unreliable intrusion detection in distributed computations. In Proc. 10th Computer Security Foundations Workshop, pages 116 124, Rockport, MA, 1997. IEEE Computer Society Press, Los Alamitos, CA. [17] J. R. Douceur. The sybil attack. In Revised Papers from the First Int. Workshop on Peer-to-Peer Systems, pages 251260, London, UK, 2002. SpringerVerlag. 13

[18] K. Tang and M. Gerla. MAC reliable broadcast in ad hoc networks. In IEEE Military Communications Conference, 2001. MILCOM 2001. Communications for Network-Centric Operations: Creating the Information Force, volume 2, pages 10081013, 2001. [19] M.-T. Sun, L. Huang, A. Arora, and T.-H. Lai. Reliable MAC Layer Multicast in IEEE 802.11 Wireless Networks. In ICPP 02: Proceedings of the 2002 International Conference on Parallel Processing, pages 527536, Washington, DC, USA, 2002. IEEE Computer Society. [20] R. Guerraoui and M. Raynal. The Information Structure of Indulgent Consensus. IEEE Trans. Comput., 53(4):453466, 2004. [21] A. Fernndez, E. Jimnez, and S. Arvalo. Minimal system conditions to implement unreliable failure detectors. In 12th Pacic Rim Int. Symp. on Dependable Computing, pages 6372, Los Alamitos, CA, USA, 2006. IEEE Computer Society. [22] M. S. de Lima and F. G. P. Greve. Protocolo Assncrono para Deteco de Falhas Bizantinas em Sistemas Distribudos Dinmicos. In Anais do Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos, pages 887900, Recife, PE, Brazil, May 2009. Sociedade Brasileira de Computao.