Este sec¸˜ao descreve como os protocolos de escrita e leitura, anteriormente apresentados, podem ser integrados nos espac¸os de tuplas definidos nesta tese.
5.6.1 Replicac¸˜ao M´aquina de Estados
A aplicac¸˜ao do esquema de confidencialidade em um espac¸o de tuplas com este tipo de replicac¸˜ao ´e relativamente simples e direta, no entanto, alguns cuidados a mais s˜ao necess´arios. Devido a neces- sidade de acordo no estado das r´eplicas, todas as requisic¸˜oes ao servic¸o devem ser feitas utilizando uma primitiva de difus˜ao com ordem total [36, 115]. Desta forma, n˜ao ´e poss´ıvel enviar diferentes vers˜oes de uma requisic¸˜ao para diferentes servidores (contendo apenas seu fragmento da tupla). A forma de usar o esquema neste modelo ´e fazer com que o cliente cifre cada um dos fragmentos com a chave secreta compartilhada entre ele e o servidor que vai armazenar esse fragmento (caso contr´ario, um servidor falho teria acesso a todos os fragmentos e poderia recuperar a tupla). Sendo assim, cada servidor ter´a acesso apenas ao fragmento a ele enderec¸ado.
Como lidamos com clientes maliciosos e precisamos manter uma equivalˆencia entre o estado das r´eplicas, mesmo que um servidor n˜ao aceite um fragmento recebido (passo 1 do servidor no Algoritmo 9) ele deve manter os dados referentes a inserc¸˜ao da tupla (como o molde e a prova). Isto ´e feito para evitar que os estados (conjunto de tuplas presentes no espac¸o) de diferentes r´eplicas corretas sejam n˜ao equivalentes, o que pode facilmente ocorrer se algumas r´eplicas descartam uma tupla sendo inserida (devido ao recebimento de um fragmento inv´alido) enquanto outras a mant´em no espac¸o. Esta n˜ao equivalˆencia permitiria a ocorrˆencia de resultados inesperados nas operac¸˜oes de leitura/remoc¸˜ao.
Al´em das modificac¸˜oes descritas acima, trˆes outras modificac¸˜oes menores se fazem necess´arias. Em primeiro lugar, a func¸˜ao extract response usada no algoritmo do espac¸o de tuplas replicado (al- goritmo 2), agora deve tentar extrair as respostas conforme definido nos passos 3 e 4 do algoritmo 10, e n˜ao mais esperar f + 1 respostas iguais. A segunda modificac¸˜ao diz respeito a aplicac¸˜ao dessa mesma estrat´egia na leitura otimizada (procedimento execute rd do algoritmo 2): a tupla s´o ´e lida se s˜ao recebidas n − f mensagens contendo o mesmo the PROOFt, com pelo menos f + 1 fragmentos
v´alidos da tupla. A ´ultima modificac¸˜ao diz respeito ao envio de mensagens invalidando tuplas. Estas mensagens devem ser enviadas a todos os servidores atrav´es de difus˜ao com ordem total a fim de ga- rantir que n˜ao existam inconsistˆencias enquanto uma tupla inv´alida esteja sendo removida do espac¸o replicado.
Apesar de acrescentar um custo adicional ao protocolo de confidencialidade apresentado na sec¸˜ao anterior, tal custo ´e bastante aceit´avel se considerarmos que: (i.) apenas criptografia sim´etrica ´e usada, e esta ´e muito r´apida se comparada as demais operac¸˜oes criptogr´aficas do esquema; (ii.) o n´umero de servidores n n˜ao ´e esperado ser muito grande (uma boa estimativa seria n ≤ 10), e portanto o n´umero de cifragens no cliente n˜ao ser´a grande; e (iii.) o servidor realiza apenas uma operac¸˜ao criptogr´afica
a mais para recuperar seu fragmento da requisic¸˜ao, portanto a maior parte do trabalho extra fica no cliente, o que permite ao sistema atender um (potencial) grande n´umero de clientes.
Como ´ultima nota a respeito da integrac¸˜ao de confidencialidade ao espac¸o de tuplas baseado em replicac¸˜ao ativa ´e preciso dizer que ´e imposs´ıvel garantir linearizac¸˜ao irrestrita quando existem clientes maliciosos inserindo tuplas no espac¸o. A raz˜ao para isso ´e que uma tupla inserida por um processo malicioso pode ser inv´alida para algumas r´eplicas e v´alida para outras, j´a que tal processo pode enviar fragmentos corretos apenas para algumas r´eplicas. Isto significa que uma tupla nestas condic¸˜oes pode ser lida se o processo leitor obtiver f + 1 fragmentos v´alidos, que podem ou n˜ao ser retornados nas primeiras n − f respostas recebidas do sistema. Conseq¨uentemente, tal tupla pode ser lida eventualmente no sistema. Desta forma, o espac¸o de tuplas baseado em replicac¸˜ao ativa com confidencialidade garante linearizac¸˜ao apenas no acesso `as tuplas inseridas corretamente.
5.6.2 BTS
O BTS (ver sec¸˜ao 4.3) ´e a mais simples construc¸˜ao para espac¸o de tuplas baseada em sistemas de qu´oruns bizantinos. Seus algoritmos para inserc¸˜ao e leitura de tuplas (operac¸˜oes out e rdp, res- pectivamente) s˜ao bastante simples e eficientes. A integrac¸˜ao dos algoritmos 9 e 10 do esquema de confidencialidade neste espac¸o ´e direta, praticamente nenhuma modificac¸˜ao ´e necess´aria. Isto ocorre por trˆes motivos b´asicos: (i.) o BTS requer n ≥ 3 f + 1, logo n − f > f + 1 e portanto sempre exis- tir˜ao f + 1 servidores corretos para retornar fragmentos v´alidos de uma tupla corretamente inserida; (ii.)a inserc¸˜ao de uma tupla no BTS ´e feita atrav´es de um protocolo trivial onde o cliente envia uma mensagem com a tupla a ser inserida para todos os servidores do sistema, desta forma basta que ele envie os diferentes fragmentos (e demais informac¸˜oes associadas a tupla) aos diferentes servidores para inserir uma tupla com confidencialidade; e (iii.) a leitura de uma tupla no BTS se d´a quando a mesma est´a presente em pelo menos f + 1 servidores, desta forma, com o esquema de confidenci- alidade, mudamos o algoritmo de leitura para que o cliente considere f + 1 tuplas com os mesmos fingerprinte PROOFte que tenham fragmentos v´alidos.
5.6.3 LBTS
O esquema de confidencialidade descrito neste cap´ıtulo n˜ao pode ser integrado ao LBTS. Isto ocorre devido a fase de reescrita do protocolo rdp desta construc¸˜ao. O problema nesta fase ´e que ela exige que uma tupla seja lida e posteriormente reescrita nos servidores. O esquema de confidenciali- dade proposto na sec¸˜ao anterior exige que os fragmentos do segredo sejam gerados todos ao mesmo tempo (durante a distribuic¸˜ao), desta forma, a reescrita s´o seria poss´ıvel se o leitor combinasse o segredo para ent˜ao gerar novos fragmentos do mesmo e redistribu´ı-los aos servidores. Esta aborda- gem n˜ao ´e fact´ıvel no esquema de compartilhamento de segredos utilizado pois permite que clientes maliciosos reescrevam tuplas corretamente inseridas de tal forma a torn´a-las inv´alidas.
Tendo em vista este problema, ´e deixado como trabalho futuro a investigac¸˜ao de uma estrat´egia que permita o uso do esquema proposto quando reescritas forem necess´arias (ver sec¸˜ao 7.4).