Boa noite amigos!
Estamos hoje no terceiro versículo da tradução de “Trusted Third Parties are Security Holes”. No versículo de ontem vimos a segunda parte.
Propriedade Pessoal Não Pode e Não Deve Depender de TTPs
Durante a maior parte da história humana, a forma dominante de propriedade tem sido a propriedade pessoal. A funcionalidade da propriedade pessoal nunca, em condições normais, jamais dependeu de terceiros confiáveis. As propriedades de segurança de bens simples podiam ser verificadas na venda ou no primeiro uso, e não havia necessidade de interação contínua com o fabricante ou outros terceiros (exceto em casos de reparo ocasional após uso excepcional e de forma voluntária e temporária). Os direitos de propriedade de muitos tipos de bens móveis (propriedade portátil) eram minimamente dependentes de terceiros – o único problema em que os TTPs eram necessários era a defesa contra as depredações de outros terceiros. A principal propriedade de segurança dos bens pessoais geralmente não eram outros TTPs como protetores, mas sua portabilidade e intimidade.
Aqui estão alguns exemplos da onipresença da propriedade pessoal em que havia uma realidade ou pelo menos um forte desejo por parte dos proprietários de estarem livres da dependência dos TTPs para funcionalidade ou segurança:
- Jóias (muito mais frequentemente usadas como dinheiro nas culturas tradicionais do que moedas, por exemplo, norte da Europa até 1000 dC e usadas no corpo para melhor proteção da propriedade e decoração)
- Automóveis operados por e portas da casa abertas por chaves pessoais.
- Computadores pessoais – nas visões originais de muitos pioneiros da computação pessoal (por exemplo, muitos membros do Homebrew Computer Club), o PC era destinado como propriedade pessoal – o proprietário teria controle total (e entendimento) do software em execução no PC, incluindo a capacidade de copiar bits no PC à vontade. A complexidade do software, a conectividade com a Internet e as incompatibilidades não resolvidas de incentivo entre editores e usuários de software (proprietários de PCs) corroeram substancialmente a realidade do computador pessoal como propriedade pessoal.
Esse desejo é instintivo e permanece hoje. Ela se manifesta na resistência do consumidor quando descobre dependência inesperada e vulnerabilidade a terceiros nos dispositivos que usa. Sugestões de que a funcionalidade de bens pessoais seja dependente de terceiros, até mesmo acordadas com pessoas sob condições estritas, como credores, até que um empréstimo de bens móveis seja pago (uma garantia inteligente) são encontradas com forte resistência. Tornar a funcionalidade de propriedade pessoal dependente de terceiros confiáveis (ou seja, confiável e não forçada pelo protocolo a manter o contrato que rege o protocolo e a propriedade de segurança) é, na maioria dos casos, bastante inaceitável.
Metodologia de Minimização de TTP
Agora, propomos uma metodologia de design de protocolo de segurança na qual os protocolos são projetados para minimizar esses custos e riscos dos TTPs. Minimizar os custos e os riscos do (s) protocolo (s) de segurança em si é uma prioridade importante, mas secundária.
Atualmente, os designers de segurança geralmente invocam ou assumem TTPs para se adequarem ao protocolo de segurança mais elegante e seguro ou com o menor custo computacional. Esses TTPs ingênuos são então utilizados como prova de conceito de uma arquitetura geral de protocolo. Mas isso não descobre as coisas importantes que precisam ser descobertas. Depois que um protocolo de segurança é implementado, o próprio código custa muito pouco, e funções de custo exponenciais, como a lei de Moore, continuam reduzindo os custos computacionais, de largura de banda e muitos outros custos tecnológicos. Os custos do próprio protocolo de segurança (exceto os custos de rounds de mensagens, limitados pela velocidade da luz e os custos da interface do usuário, limitados pelos custos mentais de transação) se aproximam de zero. De longe, o maior custo de longo prazo do sistema (como aprendemos com a PKI) é o custo da implementação dos TTPs.
É muito mais proveitoso estimar desde o início o custo dos TTPs, em vez de tentar projetar os protocolos de segurança para minimizar os custos dos TTPs. Isso provavelmente levará o designer a diferentes suposições de confiança e, portanto, a protocolos de segurança, do que se ele assume TTPs puros e não analisados em determinados locais, a fim de simplificar o protocolo de segurança. Um corolário natural é que, se existe um protocolo de segurança que pode eliminar ou reduzir muito os custos de um TTP, vale a pena implementá-lo em vez de um que assuma um TTP caro. Mesmo que o último protocolo de segurança seja mais simples e muito mais eficiente em termos computacionais.
Um corolário de “terceiros confiáveis são falhas de segurança” é “todos os protocolos de segurança têm falhas de segurança”, uma vez que nenhum protocolo está totalmente livre de tais suposições. As principais etapas na estimativa de custos e riscos de TTP são: (1) examinar minuciosamente as premissas de alguém descobrir todas as premissas de TTP e caracterizar especificamente o que cada TTP deve ou não deve fazer; (2) observar que cada buraco e tarefa específicos têm um custo e risco associados.
Existem várias outras considerações importantes, incluindo:
- Custos de design [projeto]. Minimizar TTPs geralmente envolve aprender e aplicar técnicas não-intuitivas e complexas de criptografia e tolerância a falhas, como algumas das mencionadas abaixo. Isso pode ser um grande fardo ou impraticável para um projeto pequeno de contratos inteligentes. Por outro lado, os custos de projeto para uma nova instituição TTP são geralmente muito mais altos que os custos de projeto para um novo protocolo, por mais caro que seja o último. Determinar se a nova instituição é robusta a longo prazo ainda é mais caro, enquanto os protocolos podem ser formalmente analisados e as implementações auditadas nessa análise para alcançar um nível muito alto de confiança em um período típico de desenvolvimento de produtos.
- Custos mentais de transação do usuário – a multiplicação de TTPs, mesmo aqueles com uma função razoavelmente limitada, pode rapidamente tributar a capacidade dos usuários finais de rastrear a reputação e a qualidade das diferentes marcas confiáveis. Quando os TTPs são distribuídos (como na tecnologia descrita abaixo), o rastreamento de reputação deve ser automatizado, o que é muito mais fácil quando os TTPs executam redundantemente a mesma função.
Se, para um novo contexto como o comércio eletrônico, pudermos encontrar um protocolo de segurança que substitua uma organização TTP (um conjunto complexo de tradições não comprovadas no novo contexto) pela matemática (que pelo menos por si só é bastante claro e comprovável), será muito uma grande vitória fazê-lo. Mais frequentemente, substituiremos um TTP caro e complexo por um ou mais TTPs muito mais simples, mais a matemática. Isso também é uma grande vitória. Podemos apenas dizer se e em quanto isso é uma vitória, concentrando-nos nas premissas de confiança e nos custos resultantes dos TTPs, em vez de focar na eficiência do protocolo de segurança. A chave é focar no custo dos TTPs e projetar o protocolo de segurança para minimizá-los, em vez de assumir os TTPs para simplificar ou otimizar a eficiência do protocolo de segurança.
Um bom designer de protocolo de segurança digital não é apenas um especialista em ciência da computação e criptografia, mas também conhece muito bem as técnicas caras e tradicionais de segurança física, auditoria, lei e as relações comerciais a serem protegidas. Esse conhecimento não é usado para substituir esses métodos de segurança dispendiosos por uma segurança digital mais econômica, mas para minimizar a dependência oculta dos métodos dispendiosos para a segurança real. Um bom designer de protocolo também projeta, em vez de simplesmente assumir, TTPs que funcionam com o uso mínimo de técnicas caras.
Essa foi a terceira parte da obra, no próximo versículo a quarta. Ricas bençãos!
