Bem, pelo companheiro na foto podemos ter uma idéia. Thomson é um dos criadores do Unix e criador da linguagem B, precursora de C (:-P). É um dos responsáveis pelas expressões regulares, por UTF-8 e pelo desenvolvimento de programas de jogo de xadrez. Atualmente está no Google.
No artigo "Reflections on trusting trust" Thomson faz uma descrição de como um compilador pode ser alterado para inserir um cavalo-de-tróia no código do programa que faz o login em um sistema Unix e, com isso, prepará-lo para responder positivamente a uma certa palavra-chave. Também demonstrou como o compilador C poderia ser alterado para propagar este comportamento malígno mesmo quando tentar-se recompilar o código-fonte - original, não modificado - do próprio compilador. Ou seja, mesmo compilando-se um código-fonte correto com este compilador alterado, o código-objeto resultante conterá a alteração para o login. De fato o compilador está plantando um backdoor no sistema operacional [3].
Em resumo, o que Thomson questiona é: o quanto podemos confiar em um código-fonte confiável, se não temos referências de confiabilidade nos demais elementos utilizados para produzir e executar o código-objeto dele derivado?
O artigo de Thomson data de 1984, mas não se tratava de conjectura. Em uma análise relativamente recente (Agosto de 2009) o SophosLab demostrou que um arquivo infectado com o vírus W32/Induc-A executava um código que procurava por uma instalação do compilador Delphi e, caso o encontrasse, o alterava. A partir daí todo código gerado por aquele compilador passaria a incluir o W32/Induc-A em seu código-objeto [4]. Exatamente o mesmo caso descrito por Thomson.
Portanto, suponha que você está desenvolvendo neste momento um sistema para uma grande corporação financeira, que irá processar milhares de transações diariamente, trafegando dados sigilosos. Questione: o quanto pode-se confiar em sua plataforma de desenvolvimento e na plataforma que irá executar o sistema em produção?
No contexto de desenvolvimento seguro de software o que Thomson nos alerta é que possuir uma metodologia de desenvolvimento seguro, por si só, não é suficiente para garantir que o produto do desenvolvimento resulte em um processamento seguro.
De fato, o que seria necessário é uma plataforma de computação confiável. E este conceito existe. Em 2003, por iniciativa da AMD, Hewlett-Packard, IBM, Intel e Microsoft foi formado o Trusting Computing Group (TCG), cujo objetivo inicial era o desenvolvimento de um módulo de computação confiável (trusting computing module) baseado tanto em hardware como em software, para garantir, através de serviços de criptografia e verificação de integridade de código e memória, que apenas código autorizado pudesse rodar na plataforma. Em 2009 o TCG liberou um conjunto de especificações que descrevem o protocolo para comunicação com hard-disks auto-encriptáveis. Ou seja, os produtos do TCG são ainda recentes.
Existe também um conjunto de especificações da ISO que tratam do tema:
- ISO/IEC 11889-1:2009 Information technology -- Trusted Platform Module -- Part 1: Overview
- ISO/IEC 11889-2:2009 Information technology -- Trusted Platform Module -- Part 2: Design principles
- ISO/IEC 11889-3:2009 Information technology -- Trusted Platform Module -- Part 3: Structures
- ISO/IEC 11889-4:2009 Information technology -- Trusted Platform Module -- Part 4: Commands
Para quem se interessa no tema, vale a pena dar uma olhada.
Então, fica a questão: mesmo com uma metodologia de desenvolvimento seguro, podemos garantir que estamos desenvolvendo e executando código seguro? Podemos confiar nos códigos que utilizamos em nossos computadores pessoais, nas plataformas executadas pelos Bancos e até mesmo nos códigos que rodam na nuvem ?
Referências
[1] Thomson, K., "Reflections on trusting trust", Communications of the ACM, volume 27, issue 8, pag. 761 - 763, 1984.
[5] Spinellis, D., "Reflections on trusting trust revisited", Communications of the ACM, volume 46, issue 6, pag. 112, 2003.