Boa noite povo!

Terminamos ontem “The Cathedral and the Bazaar”, de Eric Raymond. Hoje começamos a nossa trigésima tradução. Dessa vez será “Trusted Third Parties are Security Holes”, do mestre Satoshi Nakamoto Nick Szabo, publicada em 2001.  Serão 5 versículos provavelmente, esse é o primeiro.

Terceiros Confiáveis são Buracos de Segurança

Nick Szabo

Originalmente publicada em 2001

Introdução

A segurança comercial é uma questão de resolver os problemas práticos das relações comerciais, como privacidade, integridade, proteção de propriedade ou detecção de quebra de contrato. Uma falha de segurança é qualquer fraqueza que aumenta o risco de violar esses objetivos. Nessa visão de segurança do mundo real, um problema não desaparece porque um designer o ignora. A invocação ou suposição em um projeto de protocolo de segurança de uma “terceira parte confiável” (TTP, Trusted-Third-Party) ou uma “base de computação confiável” (TCB, Trusted-Computing-Base) controlada por uma terceira parte constitui a introdução de uma falha de segurança nesse projeto. O buraco de confiança precisará ser tapado por outros meios.

Se os riscos e custos das alternativas institucionais de TTP não forem contabilizados no desenho do protocolo, o protocolo resultante será, na maioria dos casos, muito caro ou arriscado para ser prático. Se o protocolo vencer essas probabilidades e se mostrar prático, ele só será bem sucedido depois que um grande esforço tiver sido feito para conectar as lacunas de segurança do TTP. As suposições do TTP causam a maior parte dos custos e riscos em um protocolo de segurança, e a obstrução dos furos de segurança do TTP produz o máximo benefício e lucro.

Como resultado, propomos uma metodologia de design de protocolo de segurança na qual as partes mais arriscadas e caras de um protocolo de segurança, as terceiras partes confiáveis, são projetadas paralelamente aos protocolos de segurança que utilizam essas partes. Os objetivos da minimização de custos e riscos estão focados nos TTPs, e não nos próprios protocolos de segurança, que devem ser projetados para se adequar aos TTPs minimizados de custo e risco.

Também discutimos e fazemos uma breve referência à pesquisa e implementação em mecanismos de segurança que reduzem radicalmente os custos e riscos de terceiros ao distribuir TTPs automatizados entre várias partes, sendo que apenas uma parte deles precisa agir de maneira segura ou confiável para que o protocolo seja confiável ou seguro.

Novos Terceiros Confiáveis são Caros e Arriscados

Este autor tem experiência profissional implementando um TTP que foi assumido pelos primeiros defensores da criptografia de chave pública. Esse TTP passou a ser chamado de “autoridade de certificação” (CA, Certificate Authority). Foi-lhe dada a responsabilidade de atestar a “identidade” dos participantes. (Aqui me concentro nos custos impostos pelo TTP; alternativas como Web of Trust e SPKI do PGP foram discutidas amplamente em outros lugares).

A autoridade de certificação provou ser de longe o componente mais caro dessa infraestrutura de chave pública centralizada (PKI, Public Key Infrastructure). Isso é exacerbado quando a necessidade de um TTP considerado pelos projetistas de protocolo é traduzida, em padrões de PKI como SSL e S/MIME, em um requisito para um TTP. Um TTP que deve ser confiado por todos os usuários de um protocolo se torna um árbitro de quem pode ou não usar o protocolo. De forma que, por exemplo, para executar um servidor Web SSL seguro ou para participar do S/MIME, seja necessário obter um certificado de uma autoridade de certificação mutuamente confiável. O mais antigo e popular deles foi o Verisign. Ele conseguiu cobrar várias centenas de dólares pelos certificados de usuário final – superando em muito os poucos dólares cobrados (implicitamente no custo do software do usuário final) pelo próprio código do protocolo de segurança. O processo burocrático de solicitação e renovação de certificados leva muito mais tempo do que a configuração das opções SSL, e o processo de identificação da CA está sujeito a uma exposição muito maior do que o próprio protocolo SSL. A Verisign acumulou uma avaliação do mercado de ações na casa dos 10 bilhões de dólares (mesmo antes de entrar em outro negócio de TTP, o Sistema de Nomes de Domínio da Internet (DNS, Domain Name System) adquirindo a Network Solutions). Como? Ao apresentar uma solução – qualquer solução, quase, pois sua segurança é bastante grosseira e cara em comparação com os componentes criptográficos de uma PKI – com a suposição aparentemente inócua de um “terceiro confiável” feito pelos projetistas de protocolos de chave pública para email e para a Web.

Mais alguns problemas com autoridades de certificação são tratados aqui.

O DNS da Internet é outro exemplo dos altos custos e riscos impostos por um TTP. Esta pequena parte do stack do protocolo TCP/IP foi responsável pela maioria das disputas e quedas de braço envolvendo esse protocolo. Por quê? Porque é uma das poucas áreas do stack TCP/IP que depende de uma hierarquia centralizada de TTPs em vez de negociações de protocolo entre nodos individuais da Internet. O DNS também é o único componente da Internet que provavelmente falhará mesmo quando seus nomes não estiverem sendo contestados ou falsificados.

Os altos custos de implementação de um TTP ocorrem principalmente porque as soluções tradicionais de segurança, que devem ser invocadas quando o próprio protocolo deixa de existir, envolvem altos custos de pessoal. Para obter mais informações sobre os benefícios de necessidade e segurança dessas soluções de segurança tradicionais, especialmente controles de pessoal, ao implementar organizações de TTP, consulte o ensaio deste autor sobre controles de grupo. Os riscos e os custos assumidos pelos usuários do protocolo também passam a ser dominados pela falta de confiabilidade do TTP – as autoridades de DNS e de certificação são duas fontes bastante comuns de insegurança e frustração com a Internet e PKIs, respectivamente.

Terminada a primeira parte da obra, no próximo versículo a segunda. Abraços!