5 Sistemas Distribu´ ıdos
5.2 Algoritmos para distribui¸ c˜ ao de dados
A motiva¸c˜ao para esta se¸c˜ao ´e o seguinte problema: dada uma certa informa¸c˜ao, presente em um n´o de um sistema distribu´ıdo, como transmitir esta informa¸c˜ao para todos os n´os do sistema da forma mais eficiente poss´ıvel? No contexto do algoritmo ECPP, esta informa¸c˜ao poderia ser, por exemplo, um comando para migrar para a pr´oxima tarefa de certifica¸c˜ao, ou as precomputa¸c˜oes necess´arias para execu¸c˜ao do algoritmo. Na literatura, esta opera¸c˜ao ´e conhecida como broadcast (7).
Vamos considerar o primeiro exemplo. Neste caso, o servidor central, que coordena todas as tarefas da rede, recebeu de um cliente a informa¸c˜ao de que ´e poss´ıvel proceder a uma nova etapa de certifica¸c˜ao. Ap´os verificar a veracidade dessa informa¸c˜ao, o servidor precisa notificar todos os clientes da rede que devem migrar para uma nova tarefa.
O servidor poderia conectar em cada um dos clientes e transferir esta informa¸c˜ao, por´em isto exigiria c conex˜oes (onde c ´e o n´umero de clientes na rede) por parte do servidor, implicando em um alto custo de comunica¸c˜ao para o mesmo. A quantidade de tempo necess´aria para realizar todas as conex˜oes tamb´em seria relativamente grande.
Permitindo aos clientes conectarem-se entre si, ´e poss´ıvel distribuir a carga de conex˜oes de maneira aproximadamente uniforme entre todos os elementos da rede. Primeiramente numera-se cada elemento da rede de maneira aleat´oria, exceto que ao servidor ´e atribu´ıdo o n´umero 0. Num primeiro instante, o n´o 0 (o servidor) envia os dados aos n´o 1. Num segundo instante, o n´o 0 envia os dados ao n´o 2, e o n´o 1 envia os dados ao n´o 3. Prosseguindo desta forma, ap´os dlog2ce passos, todos os n´os da rede ter˜ao recebido os dados, e a quantidade m´axima de conex˜oes realizadas por n´o tamb´em ´e dlog2ce. O processo ´e ilustrado graficamente na Figura 5.1.
Figura 5.1: Propaga¸c˜ao eficiente de dados.
Pode n˜ao ser desej´avel envolver todos os usu´arios na retransmiss˜ao das informa¸c˜oes, por exemplo por motivos de seguran¸ca. Outra raz˜ao ´e que dois usu´arios que estejam
por tr´as de firewalls n˜ao conseguir˜ao conectar-se entre si. Uma organiza¸c˜ao semelhante seria uma estrutura hier´arquica de n´os, conforme ilustrada na Figura 5.2. Estes n´os poderiam ser n´os privilegiados, executando um software diferente (e possivelmente nem mesmo contribuindo para as tarefas com tempo de processamento), ou simplesmente n´os comuns, em que o administrador da m´aquina configurou a rede de maneira a permitir conex˜oes. Em ambos os casos, estes n´os ser˜ao conhecidos como proxies.
Figura 5.2: Estrutura hier´arquica de rede.
Al´em de reduzir os requerimentos de comunica¸c˜ao no servidor central e o tempo necess´ario `a propaga¸c˜ao de informa¸c˜oes pela rede inteira, as estruturas hier´arquicas de rede apresentam outra vantagem: ´e poss´ıvel realizar verifica¸c˜oes distribu´ıdas de validade de resultados, uma medida descrita na se¸c˜ao seguinte para detec¸c˜ao de usu´arios maliciosos ou com hardware defeituoso. No entanto, utilizar m´aquinas n˜ao-confi´aveis para verificar a confiabilidade de resultados n˜ao provˆe garantias de validade, de modo que alguns n´os na hierarquia devem ser n´os cuja confiabilidade possa ser garantida de alguma forma. Mesmo assim, verifica¸c˜oes em n´ıveis mais baixos da hierarquia permitem a elimina¸c˜ao de alguns (sen˜ao todos) os resultados incorretos, diminuindo a carga sobre os n´ıveis superiores.
5.3 Computa¸c˜ao em ambientes n˜ao-confi´aveis
Como garantir que uma computa¸c˜ao realizada em um computador desconhecido esteja correta, ou mesmo que ela tenha sido realizada de fato? Este ´e um dos grandes problemas enfrentados pelas redes de computa¸c˜ao distribu´ıda atuais.
Primeiramente, ´e preciso questionar as raz˜oes que levam participantes da rede a reali-zar computa¸c˜oes incorretas. Alguns casos est˜ao relacionados a falhas de hardware, devidas a componentes de baixa qualidade, susperaquecimento, ou a pr´atica conhecida como
over-clocking, que ´e a opera¸c˜ao de alguns subsistemas do computador fora de sua espefica¸c˜ao. Outra possibilidade s˜ao indiv´ıduos com inten¸c˜oes maliciosas, dispostos a demonstrar a vulnerabilidade dos sistemas distribu´ıdos a ataques. Uma ´ultima e importante possibi-lidade est´a relacionada `as ‘estat´ısticas’ do projeto, que coletam dados como os usu´arios e times de usu´arios que mais contribu´ıram para o projeto; alguns indiv´ıduos, sem poder computacional para avan¸car nesta lista, empregam meios il´ıcitos para manipul´a-la.
A vulnerabilidade de um sistema distribu´ıdo a computa¸c˜oes incorretas depende, em ´
ultima instˆancia, da vulnerabilidade do algoritmo implementado no sistema (o ECPP no caso deste trabalho) para resolver o problema proposto. Felizmente, o ECPP possibi-lita diversas verifica¸c˜oes intermedi´arias da validade da computa¸c˜ao, todas de baixo ou m´edio custo, que ser˜ao estudadas agora. Ser˜ao feitas referˆencias aos passos do algoritmo fastECPP na ordem descrita na Se¸c˜ao 5.1.
Primeiramente, seja uma potencial fatora¸c˜ao da ordem do grupo de uma curva el´ıptica, realizada durante o passo 2 do algoritmo. A verifica¸c˜ao da validade deste resultado poderia proceder da seguinte maneira:
1. Primeiramente, verifica-se se o discriminante em quest˜ao ´e v´alido. ´E razo´avel exigir que, ao inv´es de transmitir o discriminante em si, o cliente transmita os fatores do discriminante, utilizando a representa¸c˜ao bin´aria de subconjuntos da base de fatores discutida na Se¸c˜ao 5.1. Atrav´es deste artif´ıcio, a verifica¸c˜ao da validade do discriminante ´e dispensada.
2. Verifica-se ent˜ao que a ordem do grupo ´e v´alida. Exceto para os casos D = −3, −4, a ordem ´e dada por ni+1±U , onde ni´e conhecido, e U satisfaz a rela¸c˜ao 4ni = U2+ DV2, sendo que D tamb´em ´e conhecido. Pode-se exigir a transmiss˜ao de V junto com o resultado, simplificando consideravelmente a verifica¸c˜ao, mas aumentando os requerimentos de comunica¸c˜ao; ou pode-se verificar que (4ni− U2)/D ´e um inteiro e quadrado perfeito. Nem ´e preciso calcular uma raiz quadrada do valor para verificar que o mesmo ´e um quadrado perfeito; pode-se utilizar os m´etodos descritos em (12), que testam se o inteiro em quest˜ao ´e um res´ıduo quadr´atico m´odulo primos pequenos, o que sempre ocorre quando o mesmo ´e um quadrado perfeito.
3. Por fim, determina-se se a fatora¸c˜ao relatada da ordem de grupo ´e v´alida. ´E desej´avel que os fatores encontrados sejam transmitidos junto com o resultado; geralmente o tamanho dos mesmos ser´a de algumas dezenas (ou no m´aximo poucas centenas) de bits. Dividindo a ordem do grupo pelos fatores, o resultado deve ser um inteiro,
o que ´e de f´acil verifica¸c˜ao, mas tamb´em um primo prov´avel; a verifica¸c˜ao desta ´
ultima propriedade exige uma quantidade razo´avel de computa¸c˜ao.
O ´ultimo passo, que envolve um teste de car´ater pseudoprimo, parece indicar que a verifica¸c˜ao de validade n˜ao possui t˜ao baixo custo quanto desej´avel. No entanto, ´e preciso colocar este fato em perspectiva: a obten¸c˜ao de valores que satisfa¸cam as verifica¸c˜oes anteriores ´e uma tarefa relativamente custosa, bem mais custosa que o teste de car´ater pseudoprimo. Isto sugere a seguinte estrat´egia: ao realizar o teste de car´ater pseudoprimo sobre o cofator do resultado em quest˜ao, caso o teste afirme que o cofator ´e composto, o proxy n˜ao descartar´a os parˆametros em quest˜ao (como discriminante, ordem de grupo, fatores, etc.) ap´os a verifica¸c˜ao, como poderia se esperar. Ao inv´es disso, estes parˆametros s˜ao armazenados (e possivelmente enviados a outros proxies) para que tentativas poste-riores de verifica¸c˜ao usando este resultado sejam detectadas imediatamente, evitando o desperd´ıcio de computa¸c˜ao. Assim, um advers´ario malicioso precisa executar uma quan-tidade muito grande de computa¸c˜ao em troca de um pequeno desperd´ıcio nos proxies, tornando tais ataques f´uteis.
Deve-se verificar tamb´em a validade dos resultados obtidos no item 3 e 4 do algoritmo fastECPP. Felizmente, isto tamb´em ´e f´acil, uma vez que ´e a mesma tarefa que deve ser realizada para verificar a validade de um certificado do ECPP. Poderia-se argumentar que o custo de O ((log ni)2+), onde ni ´e o primo atual da cadeia de certificados, n˜ao ´e t˜ao baixo assim. Por´em, deve-se lembrar que a constru¸c˜ao de curvas ´e um evento que ocorre com baix´ıssima frequˆencia; h´a no total O(log n) destes eventos durante a certifica¸c˜ao de um inteiro n.
Assumindo que resultados incorretos sejam devidos somente a hardware defeituoso, o custo computacional das verifica¸c˜oes ´e desprez´ıvel. No entanto, caso a rede seja alvo de um ataque malicioso bem planejado, os protocolos de rede do sistema dever˜ao levar este fato em conta para evitar desperd´ıcios e at´e uma poss´ıvel exaust˜ao de recursos.
Uma possibilidade ´e o esquema de (22) e seus sucessores; quando o cliente conectar a um proxy para retornar resultados, ser´a exigido do cliente a realiza¸c˜ao de uma computa¸c˜ao de alguns segundos, espec´ıfica para aquela conex˜ao. Isto limita a taxa de conex˜oes de advers´arios, enquanto usu´arios honestos, que conectam pouco frequentemente, n˜ao s˜ao afetados.
Ao mesmo tempo, pode-se empregar um sistema seguro de identifica¸c˜ao de usu´arios, baseado em assinaturas digitais. Deste modo, ´e poss´ıvel associar resultados ao usu´ario
que produziu os mesmos, e rejeitar resultados de usu´arios suspeitos. Poderia-se empre-gar o esquema de (23) ou as vers˜oes melhoradas de (24, 25), que permitem verifica¸c˜ao extremamente r´apida de assinaturas.
Por outro lado, devido aos problemas de hardware defeituoso j´a mencionados, n˜ao se deve assumir que um resultado incorreto ´e sinal de ataque `a rede: o usu´ario deve ser informado do fato e posto em quarentena at´e que corrija o suposto problema de hardware.