Boa noite amigos!
Hoje terminaremos a tradução de “Trusted Third Parties are Security Holes”. Vimos no versículo de ontem a quarta parte.
Decifrando a Terminologia
Alan Karp, Mark Miller e outros observaram a confusão sobre palavras como “trust” [confiar] e “trusted” [confiados/confiáveis], usadas na comunidade de segurança, e propuseram substituir o verbo “trust” [confia] por “is vulnerable to” [é vulnerável a]. Essa substituição é uma ótima maneira de esclarecer radicalmente os projetos de protocolos de segurança. “Terceiros confiáveis”, conforme usado neste ensaio, torna-se “vulnerável a terceiros”, e o objetivo deste artigo, de que se trata de uma falha de segurança, torna-se óbvio.
No contexto de projetos de protocolo, em vez de dizer que o projetista de protocolo confia em alguma classe genérica de partes pouco conhecida (referida no singular como “um terceiro confiável”) com uma determinada autorização (o que provavelmente significa realmente que o projetista de protocolo apenas não consegue descobrir como corrigir uma falha de segurança), um projetista honesto de protocolos admitirá que existe uma vulnerabilidade aqui – e que cabe a mecanismos “fora da banda” obstruir ou minimizar ou que os usuários ignorem sabidamente esse buraco. A classe das partes é pouco conhecida porque os projetistas de protocolos de segurança normalmente não sabem muito sobre as soluções tradicionais de segurança não digital, legais e institucionais necessárias para tornar essa parte confiável. A substituição de “vulnerável a” por “confiável” funciona bem no design do protocolo e na comunicação honesta sobre a segurança de um protocolo.
Infelizmente, os projetistas e vendedores de sistemas de segurança que invocam “terceiros confiáveis”, “computação confiável” e coisas do gênero realmente vão sair e admitir que seus protocolos são “vulneráveis”? Os projetos de segurança soam muito mais seguros quando usam o eufemismo “confiança”.
No mundo real, além do contexto técnico do design do protocolo de segurança, “confiança” tem vários significados. Um uso diferente de “confiança” é a confiança bem informada, por exemplo “Confio nesta armadura para me proteger de balas normais, porque foi muito bem testada”, “Confio neste site com esta autorização porque estamos usando um forte protocolo de segurança para me proteger quando concedo esta autorização” ou “confio na minha esposa com os filhos”, nos casos em que traduzir “confiança” para “sou vulnerável a” seria reverter seu significado. Essa “confiança” pode assumir significados praticamente opostos, dependendo do contexto, é outro argumento forte para evitar o uso da palavra ao descrever as vulnerabilidades, ou a falta delas, dos protocolos de segurança. Se um designer pensa que confia ou deve confiar em alguma classe genérica de partes é uma coisa. Se um usuário em particular realmente confiará em uma entidade específica nessa classe quando o protocolo realmente for executado é outra questão. Se a confiança do usuário ou a do designer está bem informada ainda é outra questão.
Conclusão
A segurança tradicional é cara e arriscada. A segurança digital, quando bem projetada, diminui drasticamente o custo ao longo do tempo. Quando um designer de protocolo invoca ou assume um TTP, ele está criando a necessidade de uma nova organização tentar resolver um problema de segurança não resolvido por meio dos métodos tradicionais de segurança e controle. Especialmente em um contexto digital, esses métodos requerem altas despesas contínuas por parte do TTP e o TTP cria um gargalo que impõe altos custos e riscos contínuos ao usuário final.
Uma metodologia muito melhor é trabalhar a partir de TTPs que sejam bem conhecidos ou fáceis de caracterizar e com custo mínimo. O melhor “TTP” de todos é aquele que não existe, mas cuja necessidade foi eliminada pelo design do protocolo ou que foi automatizada e distribuída entre as partes de um protocolo. A última estratégia deu origem às áreas mais promissoras da pesquisa de protocolos de segurança, incluindo mixes digitais, cálculos privados multipartidários e bancos de dados resilientes bizantinos. Essas e outras implementações semelhantes serão usadas para reduzir radicalmente o custo dos TTPs atuais e resolver os muitos problemas pendentes em privacidade, integridade, direitos de propriedade e execução de contratos, minimizando os custos muito altos da criação e operação de novas instituições TTP.
Referências
Links no texto. [alguns estão quebrados, os quais não coloquei.]
Reconhecimentos
Meus agradecimentos a Mark Miller, que me incentivou a escrever esses pensamentos e fez muitos bons comentários. Meus agradecimentos também a Hal Finney, Marc Stiegler, David Wager e Ian Grigg por seus comentários.
Terminamos mais uma obra, dessa vez foi “Trusted Third Parties are Security Holes”, do mestre Satoshi Nakamoto Nick Szabo. Espero que tenham curtido. O versículo de amanhã quinta será o nosso sexto Entrepost, no qual postarei um breve resumo das últimas 5 traduções. Deus os abençoe!
