Boa noite amigos!
Vimos no versículo anterior a primeira parte da tradução de “Advances In Distributed Security”. Continuando então..
Tolerância a Falhas e Segurança em Redes e Seus Serviços
Como um resultado dessas novas possibilidades, estamos testemunhando uma mudança na maneira em que vemos a confiança. A visão antiga em segurança de rede e computadores era que confiança era tudo ou nada – ou devemos colocar uma fé essencialmente cega em uma terceira parte (por exemplo uma autoridade de certificação ou um emissor de dinheiro digital) ou devemos proteger contra um modo particular de ataque completamente (como, por exemplo, projetos de criptografia contra interceptores). A visão antiga não poderia lidar com a maioria das situações da vida real que não caem em nenhum desses dois extremos. Entre os designers de segurança distribuída mais inteligentes, as terceiras partes incondicionalmente confiadas agora são vistas como uma trapaça – “aqui oramos pela benevolência celestial”, análoga ao matemático da tirinha em quadrinhos cuja prova contém o passo crucial, “aqui um milagre ocorre”. Uma terceira parte totalmente confiada com uma propriedade de segurança significa que essa propriedade de segurança de fato permanece totalmente insegura – significa que o designer do protocolo despachou a segurança para outro alguém ao invés de solucionar um problema de segurança.
A nova visão reitera o desejo de proteção completa contra ataque onde for disponível, mas adiciona proteção contra vastas novas classes de ataques, e proteção de uma ampla variedade de outras propriedades desejáveis de sistema distribuído, que são impossíveis de proteger sem ao menos algumas suposições de confiança. As novas suposições de confiança são que participantes em um serviço público crítico são parcialmente, geralmente, ou mais frequentemente do que não confiáveis, e geralmente apenas sob certas condições. O conjunto de partes que formam um serviço distribuído crítico nunca é totalmente confiável nem totalmente malicioso.
Protocolos modernos para serviços críticos tais como diretórios públicos constroem, de todos os subconjuntos possíveis de todos participantes, estruturas de ataque consistindo da pior combinação de partes maliciosas que são toleradas, e seu complemento, estruturas de acesso, o conjunto mínimo de partes que precisam atuar corretamente durante essa operação para executar a função. (Note que estruturas de acesso não tem nada a ver com listas de controle de acesso, um método de segurança tradicional que assume uma terceira parte totalmente confiada e consiste de uma lista estática de pessoas ou classes de pessoas e os recursos ou classes de recursos a que tem acesso).
Um simples exemplo em particular de tal estrutura de ataque e acesso é uma estrutura limiar onde o comportamento malicioso de t de n participantes pode ser tolerado. Embora descreveremos os protocolos abaixo em termos de estruturas limiares, será geralmente possível substituir outras partições do conjunto de poder dos participantes por estruturas de acesso mínimo e máximo ataque.
Uma dada propriedade de um sistema tem segurança perfeita se sua estrutura de acesso é qualquer participante e sua estrutura de ataque é o conjunto vazio. Um exemplo de uma propriedade com segurança perfeita é o uso de uma estrela giratória de nêutrons chamada pulsar como um relógio. Sua estrutura de acesso é qualquer parte que possa receber suas transmissões naturais, e sua estrutura de ataque é o conjunto vazio – dada a razoável suposição de que não há alienígenas lá fora que podem e querem manipular os outputs de altíssima energia dos pulsares em busca de algum fim humano de que aprenderam sobre.
Outra propriedade de segurança perfeita é a criptografia contra terceiros, assumindo que a criptografia seja inquebrável. No entanto, se levarmos em conta o destinatário de uma mensagem como um possível atacante, a propriedade de privacidade mais ampla não é segura – o destinatário é uma estrutura de ataque de alguém que pode comprometer a privacidade de toda a mensagem criptografada para ele.
Uma propriedade de segurança é quase perfeita se sua estrutura de ataque contiver T-1 de N participantes. Por exemplo, no digital mix de Chaum [C81], para uma única mensagem, seria necessário a colusão de N-1 de N dos servidores de mix para rastrear uma mensagem. A propriedade de não rastreio desse sistema tem quase uma segurança perfeita para uma única mensagem. Por outro lado, a propriedade de confiabilidade do mix digital é quase perfeitamente insegura, uma vez que qualquer um dos n servidores de mix pode bloquear a passagem de uma mensagem. Geralmente devemos escolher entre duas propriedades diferentes como essas. Uma vez que a confiabilidade é um erro reversível pelo usuário final e uma brecha de privacidade não, o tradeoff feito aqui pelo Chaum faz sentido.
Infelizmente, para muitas propriedades desejáveis, não podemos alcançar uma segurança perfeita ou quase perfeita. Para algumas propriedades de serviços replicados – para alguns tipos de regras que eles anunciam como a seguir – podemos alcançar uma segurança quase perfeita por meio, por exemplo, do uso de criptografia.
Para qualquer outra propriedade, a estrutura de máximo ataque de servidores maliciosos e conspiradores que pode ser tolerada é o conjunto complemento da estrutura de acesso. Para o caso limiar, isso significa que T, o número máximo de servidores maliciosos e conspiradores que pode ser tolerados, é uma certa fração do número total de servidores, como ⅓ ou ½, do número total de servidores compreendendo o serviço, N. Ou seja, se T+1 de N dos servidores decidirem em conjunto violar as regras do serviço e assim corromper o sistema, eles podem fazê-lo. Aqueles que pretendem se manter nas regras devem sair da transação corrompida e reiniciar o serviço fora da banda. Para essa grande classe de propriedades de serviço em que a estrutura de acesso é o conjunto complemento da estrutura de ataque, a segurança de uma propriedade não é perfeita nem quase perfeita em um extremo, nem depende totalmente de uma única parte confiável no outro extremo. Dizemos que essa classe de propriedades de serviço pode ser implementada com segurança distribuída.
Três das propriedades que mais frequentemente queremos proteger são: privacidade, disponibilidade e integridade. Para um serviço replicado, o foco principal deste artigo, focamos na segurança da integridade e disponibilidade de uma única operação de um serviço. O objetivo é criar estruturas de ataque com grande probabilidade de não falhar. Se ou quando ocorrerem falhas de conluio generalizado, as partes dependentes, isto é, as partes que dependem das propriedades que estão sendo protegidas, devem sair da banda e usar sistemas suplementares para reparar o sistema. Esses sistemas suplementares podem incluir uma ampla variedade de restrições de integridade entre partes, auditorias, lista negra e outros esquemas que envolvem auditoria, reputação e / ou criptografia por participantes, partes dependentes ou terceiros confiáveis. Isso pode motivar ainda mais os servidores a preservar a integridade e a disponibilidade desses serviços e ajudar os usuários a se recuperarem após um ataque bem-sucedido (agora muito mais raro).
Já que uma ampla variedade de suposições agora podem ser feitas por um protocolo de segurança e essa variedade pode pela primeira vez ser descrita matematicamente – como estruturas de ataque e acesso – estes sistemas suplementares podem focar em manter as estruturas de ataque atuais menores do que as estruturas máximas de ataque toleradas, em vez de na tarefa muito mais difícil de obstruir brechas de segurança totalmente abertas chamadas “terceiros confiáveis” com essas instituições suplementares mais vagamente definidas e tradicionais.
Vista então a segunda parte da obra, no versículo próximo a terceira. Abraços!
