Boa noite povo!
Dando continuidade à tradução de “Trusted Third Parties are Security Holes”. Da qual, no versículo anterior, vimos a terceira parte. Hoje a quarta.
Protocolos de Minimização de TTP
Vimos acima que as chaves para minimizar os TTPs são identificá-los, caracterizá-los, estimar seus custos e riscos e, em seguida, projetar protocolos em torno de TTPs de custo e risco mínimos. Quando o risco é mitigado com técnicas como as desta sessão, ele pode ser reduzido substancialmente.
Três áreas de pesquisa e implementação mostram uma promessa especial em melhorar a confiança. Dois deles envolvem a área particularmente espinhosa da privacidade, onde a quebra de confiança é geralmente irreversível – uma vez que os dados saem, pode ser impossível recuperá-lo.
Compre seu Ingresso Agora
A primeira família de protocolos em que a confiança pode ser distribuída para preservar a privacidade são os mixes de Chaum. Os mixes permitem comunicações imunes ao rastreamento de terceiros. Somente qualquer um dos N proxies em uma cadeia de proxy precisa ser confiável para que a privacidade seja preservada. Infelizmente, todos os N dos proxies precisam ser confiáveis ou a mensagem será perdida e deverá ser reenviada. A desvantagem do protocolo de mix digital é aumentar os atrasos nas mensagens (reenviar) para minimizar o risco de perda irreversível da privacidade.
Outra família de protocolos na qual a confiança pode ser distribuída para preservar a privacidade é a computação multipartidária privada. Aqui, um computador virtual é distribuído pelas N partes que fornecem inputs especialmente criptografados entre si, e não com um terceiro confiável. O computador distribuído recebe inputs de cada uma das N partes, calcula um algoritmo acordado e, em seguida, gera o output. Cada parte aprende apenas o output e não as informações de qualquer outra parte. O limiar das partes que devem conspirar para violar a privacidade ou ameaçar a confiabilidade pode ser negociado e foi estudado em detalhes na ampla literatura sobre esse tópico. A computação multipartidária privada pode ser usada para auditoria confidencial, coleta de preferências confidenciais e mineração de dados, leilões e trocas com lances confidenciais, e assim por diante.
Uma família de protocolos que replica dados e distribui operações nesses dados, preservando a integridade desses dados, são os bancos de dados replicados resilientes bizantinos. As implementações de bancos de dados replicados resilientes bizantinos incluem o Fleet e o Phalanx. O Fleet implementa persistência replicada de objetos de uso geral. Algumas implementações de código aberto, que abordam, mas não atingem resiliência bizantina, uso geral ou descentralização completa, incluem o Mojo Nation e o Freenet. As aplicações incluem registros seguros de nomes e títulos de propriedade, além de conteúdo publicado com segurança no Mojo Nation e Freenet. O trabalho mais avançado nessa área envolve sistemas de quorum tolerantes a falhas bizantinas e outros avançados recentes em segurança distribuída.
É importante observar que essas técnicas de limite destinam-se apenas a aprimorar a integridade de uma única etapa ou execução do protocolo. Sistemas práticos, como o Mojo Nation, combinam a maioria ou super-maioria em uma execução específica com a detecção de falhas e a escolha pelos clientes dos servidores entre as execuções. Assim, podemos adicionar de volta todos os sistemas de reputação, auditoria e outros que adicionam robustez a longo prazo aos sistemas distribuídos. As maiorias ou super maiorias dentro de uma invocação criam uma robustez muito boa a curto prazo que está faltando nos sistemas atuais como Freenet e Mojo Nation. (Falta apenas uma parte do Mojo, que tem um esquema de votação de 4 em 8, mas isso não demonstrou ser resiliente bizantino até 4 em 8).
Atestado Remoto de Código do Servidor
O atestado remoto foi proposto para verificar o estado do software em execução nos clientes para proteger a propriedade intelectual. Um uso mais valioso para atestado remoto é verificar o comportamento dos servidores. Isso também é chamado de abordagem de servidor transparente. Por meio de atestado remoto, os clientes podem verificar se o código específico desejado está sendo executado em um servidor. Combinado com a capacidade de auditar esse código como código aberto, o atestado remoto de servidores pode diminuir bastante a vulnerabilidade de clientes e usuários ao servidor. Dada a importância do problema de confiança de terceiros que discutimos aqui, essa abordagem tem um grande potencial para converter protocolos de confiança em protocolos seguros e possibilitar uma ampla variedade de protocolos seguros até então impossíveis. Por exemplo, Hal Finney implementou uma versão do bit gold chamada provas de trabalho reutilizáveis (RPOW, reusable proof of work), com base em uma placa segura de co-processador que permite aos usuários atestar remotamente o código em execução no cartão. estado do software em execução nos clientes para proteger a propriedade intelectual. Um uso mais valioso para atestado remoto é verificar o comportamento dos servidores. Isso também é chamado de abordagem transparente do servidor. Por meio de atestado remoto, os clientes podem verificar se o código específico desejado está sendo executado em um servidor. Combinado com a capacidade de auditar esse código como código aberto, o atestado remoto de servidores pode diminuir bastante a vulnerabilidade de clientes e usuários ao servidor. Dada a importância do problema de confiança de terceiros que discutimos aqui, essa abordagem tem um grande potencial para converter protocolos de confiança em protocolos seguros e possibilitar uma ampla variedade de protocolos seguros até então impossíveis. Por exemplo, Hal Finney implementou uma versão do bit gold chamada provas de trabalho reutilizáveis, com base em uma placa segura de co-processador que permite aos usuários atestar remotamente o código em execução no cartão. Embora ainda seja necessário confiar no fabricante da placa, esse fabricante é separado da instalação do código do servidor e da operação do servidor na placa.
Deixando Pequenos Buracos Desplugados
Muitas vezes, o designer do protocolo não consegue descobrir como corrigir uma vulnerabilidade. Se o ataque de que um TTP precisa se proteger não é uma ameaça séria do mundo real no contexto do aplicativo que o designer está tentando proteger, é melhor simplesmente deixar o pequeno buraco desplugado do que atribuir a tarefa a um TTP. No caso da criptografia de chave pública, por exemplo, os projetistas de protocolos não descobriram como impedir um ataque de “homem do meio” (MITM, man-in-the-middle) durante a troca inicial de chaves. O SSL tentou evitar isso exigindo CAs [autoridades de certificação] como terceiros confiáveis, conforme descrito acima, e essa solução custou à comunidade da Web bilhões de dólares em taxas de certificado e oportunidades perdidas para proteger as comunicações. O SSH, por outro lado, decidiu simplesmente deixar esse pequeno buraco desplugado. Até onde eu sei, o buraco MITM nunca foi explorado para comprometer a privacidade de um usuário SSH, mas o SSH é muito mais usado para proteger a privacidade do que o SSL, por uma pequena fração do custo. Essa abordagem econômica de segurança foi analisada em maior detalhe por Ian Grigg.
Fim da quarta parte, amanhã a parte final. Abraços!
