A Primeira Metade das Assinaturas Digitais e Algumas Consequências

No post anterior desta série, eu disse que as assinaturas digitais são uma espécie de "função de hash" turbinada. Neste post, vou discorrer sobre as semelhanças entre as funções de hash e as assinaturas digitais que decorrem justamente do fato desta última usar a primeira como insumo. Isso tem algumas consequências que às vezes surpreendem até os técnicos em informática; e já causou muita confusão entre os operadores do Direito que tentam se beneficiar da eficácia probante das assinaturas digitais.

Nota: Se você está lendo via algum agregador de RSS ou navegador do celular, sugiro voltar aqui usando o Firefox, Chrome ou algum navegador moderno com suporte a HTML5; este post contém algumas demonstrações interativas que o tornam muito mais divertido nessas plataformas. Se se navegador não suportar esses recursos, você vai ter de se contentar com o texto.

Uma Definição Conceitual Preliminar

A definição mais curta que eu conheço do que venha a ser uma assinatura digital cabe em duas palavras: uma assinatura digital é um número. Outra definição, um pouco maior, em uma frase, é: a assinatura digital é um número que é resultado de um cálculo.

Por simples que sejam, essas definições já nos permitem desfazer uma confusão comum: tem muita gente que acha que "assinatura digital" é a mesma coisa que assinatura manuscrita digitalizada (ou "escaneada") – tal como aquelas constam no verso da "nova carteira de motorista". Como uma figura vale mais do que mil palavras, eis aqui um slide tirado dos meus cursos para ilustrar visualmente:

Essa confusão é fruto do uso do termo "assinatura", que, ao meu ver, é um termo pouco adequado, pois se baseia em uma analogia fraca forçada ao extremo. Esse é mais outro exemplo de como a área da "certificação digital" é uma área cheia de nomenclatura ruim que gera diversos mal-entendidos.

Talvez um nome melhor para as "assinaturas digitais" fosse algo como "super dígitos verificadores". Dígitos verificadores também são números que resultam de um cálculo. A diferença é que as assinaturas digitais costumam ser bem maiores – os dígitos verificadores no final do seu número de CPF são apenas dois, ao passo que os "super dígitos verificadores" de uma assinatura digital normalmente têm centenas de dígitos.

A função básica das assinaturas digitais é muito parecida com a dos dígitos verificadores: verificar que você recebeu a mensagem que o remetente pretendia lhe enviar. No caso dos dígitos verificadores do CPF, a "mensagem" são os nove primeiros dígitos do CPF. No caso das assinaturas digitais, a "mensagem" pode ser praticamente qualquer coisa que seu computador consiga armazenar: um email, um documento digitalizado, uma foto, uma música, um programa, etc.

Evidentemente, as definições curtas acima estão patentemente incompletas, pois dizer que a assinatura digital é um número que resulta de um cálculo é muito pouco – se for por isso, o Produto Interno Bruto do Brasil ou o número de votos que o Tiririca teve também são números que resultam de um cálculo!

Um Pouco Mais de Detalhe

A verdadeira natureza das assinaturas digitais está no cálculo exato que é feito para criá-las. Tem muita gente que usa o termo "assinatura digital" nesse sentido, para se referir ao procedimento de cálculo, ao invés do(s) resultado(s) deste.

O cálculo para geração de uma assinatura digital tem duas etapas: na primeira, cria-se um identificador curto do material, dado ou docuemnto a ser assinado – isso é conhecido informalmente como "hashing" ou "tirar um hash" e é basicamente esse processo que calcula os "super dígitos verificadores". Na segunda etapa, vincula-se o identificador calculado na primeira etapa com um par de números chamados "chaves" (essa etapa se chama "cifragem").

Existem diversas variantes tanto do procedimento hashing quanto do procedimento de cifragem. Por exemplo, o esquema de hashing talvez mais conhecido que existe seja o MD5 e, por isso, é o que eu vou usar nos exemplos.1 Mas existem vários outros, como o SHA1 e o SHA256, o Whirlpool (um dos projetistas dele é um brasileiro), RIPEMD160, etc.

Algumas Experiências Práticas

Para mostrar isso tudo de forma mais prática, eu montei uma demonstração interativa. Digite o que quiser na caixa de texto no formulário abaixo. Você verá que, à medida em que for digitando, o seu navegador vai exibir no campo intitulado "MD5" o identificador resultante, com 32 caracteres alfanuméricos:

Por favor ative o suporte a JavaScript.

Note que cada caractere que você digita altera totalmente o resultado. Por exemplo, ao digitar teste, o número identificador se torna 698dc19d489c4e4db73e28a713eab07b. Acrescentando uma letra "s" para que o texto fique testes, já muda para 6e7906b7fb3f8e1c6366c0910050e595. Mas se você remover o "s", vai voltar exatamente para o valor anterior.

Ou seja: dados idênticos geram identificadores idênticos e dados diferentes quase certamente geram identificadores diferentes. Por trás desse "quase" há uma longa história, cheia de ramificações, que eu vou explicar melhor em um futuro post. Por hoje, faça de conta que esse "quase" não existe.

A geração de identificadores MD5 funciona não só pra trechos pequenos de texto, como no exemplo acima. Ela também funciona perfeitamente bem para arquivos quaisquer2 . Se você estiver usando um navegador recente, estará disponível no quadro abaixo uma demonstração interativa onde você poderá escolher arquivos quaisquer no seu computador e calcular seus identificadores MD5.

Por favor ative o suporte a JavaScript.

Como o processo de cáculo de identificadores MD5 é padronizado, diferentes programas calculadores de MD5 têm de dar os mesmos resultados quando apresentados com os mesmos arquivos. Se você usa Linux ou Mac, você quase certamente já tem um programa calculador desses instalado chamado md5sum (no Mac, ele se chama apenas md5): em uma janela de terminal, digite o seguinte comando:

md5sum o_mesmo_arquivo_que_voce_tentou_acima

Que eu saiba, o Windows não vem nativamente com um utilitário fácil e simples para calcular o identificador MD5 de arquivos quaisquer em um ou dois cliques do mouse. Mas há um programinha que faz isso – baixe-o daqui. Após instalado, clique com o botão direito do mouse no ícone que representa o arquivo e peça a opção "Enviar para > winMd5sum".

Independente de qual programa você use, o identificador MD5 que você obtiver deverá ser idêntico ao obtido através da demonstração interativa acima. Se não for, há algum bug no seu programa – ou no meu! :)

Identificadores MD5 são rotineiramente usados para se dar alguma certeza de que o arquivo que você recebeu ou baixou de algum site é mesmo o que o rementente pretendia que você recebesse. Por exemplo: a turma do Ubuntu mantém uma página com os identificadores MD5 dos arquivos de imagem dos CD-ROMs de instalação que eles disponibilizam. Para a conveniência do leitor, eis aqui uma captura de uma parte da tela com meu navegador nessa página. Note como eles publicam os nomes dos arquivos e os identificadores MD5 correspondentes:

Isso tudo pode parecer simples ou até banal. Mas há algumas lições profundas aqui:

  • A operação mais importante do processo todo é a conferência do hash. Isso é verdade tanto se usarmos hashes diretamente, quanto como se estivermos conferindo assinaturas digitais (como veremos adiante, a conferência de uma assinatura digital descamba na conferência de um hash.) Se você baixa o arquivo e não calcula o hash da sua cópia para ver se é idêntica à que o remetente pretendia que você recebesse, você não tem garantia nenhuma.

  • O usuário final precisa ter o programa que confere ou hash ou a assinatura digital. No exemplo acima com os arquivos de imagem de CD-ROMs do Ubuntu, eles estão se baseando no fato que o programa md5sum é amplamente disponível. Mas note como eles foram cuidadosos em explicar isso bem direitinho – logo no começo do texto há um link para uma outra página chamada "HowToMD5Sum", onde ele explica como usar e recomendações de onde baixar um programa calculador.

  • A conferência deve poder ser realizada em um sistema computacional totalmente sob controle de quem recebe, e totalmente independente do sistema computacional de quem enviou ou publicou o arquivo original. Colocar uma página dizendo "Conteúdo Autenticado" ou algum selinho de aprovação pode ser muito bonitinho e muitos usuários incautos podem até cair nessa esparrela, mas pouco ou nada garante. O que garante que você de fato recebeu o dado correto é você conferir tudo no seu computador e poder reconferir sempre que quiser, no seu computador, no computador do perito ou do juiz (em caso de litígio), etc.

Eu costumava achar que essas coisas eram óbvias, que decorriam naturalmente da maneira como os hashes funcionam e que todo mundo "captava" isso sem esforço. Ao longo dos anos, atuando como consultor em vários projetos envolvendo "Certificação Digital" e áreas correlatas, surpreendi-me repetidamente ao notar que vários desses pontos eram ignorados e que a implementação final de diversos sistemas acabou por refletir essa ignorância.

Não é preciso ir muito longe para achar, por exemplo, sites que se limitam a te dar um documento assinado digitalmente e não te diz onde você pode baixar o programa necessário para conferir a assinatura. Ou usa um programa proprietário que usa um formato de arquivo fechado, que dificulta uma perícia ou análise independente.

Inalterado versus Idêntico Bit-a-Bit

A área de "Certificação Digital" é cheia de idéias tecnicamente erradas que, por alguma razão, "grudam" no imaginário popular. Poucas criaram raízes tão profundas e geraram tanta confusão quando a idéia de que "se o hash é o mesmo, o arquivo não foi alterado"; ou, a versão equivalente no caso de assinaturas digitais: "se a conferência da assinatura der válida, o documento permance inalterado."

Eu não recomendo essa formulação não só porque ela não está certa, mas, pior ainda, passa uma imagem equivocada para os iniciantes. Pra começar, os dados digitais em trânsito pela rede são alterados o tempo todo: quando transmitidos pela Internet, são fatiados em pacotes, encapsulados e desencapsulados, codificados e decofidicados de várias maneiras à medida em que passam pelas várias camadas de software e hardware que compõem os meios de transmissão e de armazenamento. Em outras palavras, eles são alterados o tempo todo.

Acontece que quando você vai recalcular o identificador (MD5 ou por qualquer outro algoritmo) e o resultado bate com o previamente calculado, o que aconteceu é que todas essas altrerações se anularam exatamente. O que o fato do MD5 dar idêntico quando calculado em dois instantes diferentes garante é que, nesses dois instantes, os dados sâo idênticos bit-a-bit.

E eu considero esse "bit-a-bit" imprescindível. A maneira mais didática que eu conheço de exemplificar a razão disso é usando um arquivinho do Word que batizei de "Documento Mutante": clique neste link para baixar um arquivo chamado mutante.doc e salve-o no seu computador. Em seguida, confira o identificador MD5 dele (usando a demonstração interativa acima ou algum calculador que você porventura já tenha instalado no seu computador). O resultado deverá dar 077cc1d426cf8d8038a166ee03dc3f17. Se der (é quase certo que dará), você tem certeza absoluta que o arquivo que você baixou é exatamente o mesmo bit-a-bit que eu postei aqui.

Agora abra o arquivo no Word. Há um texto explicativo, mas o cerne do exemplo é uma "cláusula de contrato" dizendo que certas obrigações são de responsabilidade da "CONTRATANTE" ou "CONTRATADA". Eis aqui o que apareceu quando eu abri o arquivo agora:

Acontece que se eu fechar o arquivo (se o Word pedir para salvar o arquivo, não salve, feche sem salvar) e abri-lo uns 30 segundos depois, o que aparece é o seguinte:

Se você reconferir o identificador MD5, verá que ele permanece inalterado (se alterou, foi porque você se distraiu e apertou no botão "salvar", ou o seu Word está com o salvamento automático ativado). Ou seja: os "bits" do arquivo continuam os mesmos, mas sua representação visual, não.

É exatamente por isso que eu não gosto de dizer coisas como "o documento está inalterado"; do ponto de vista visual – que é o que o leigo entende –, ele parece alterado, sim! A despeito disso, o arquivo "mutante.doc" continua "idêntico bit-a-bit" em relação ao que você baixou, como evidenciado pelo mesmo identificador MD5. Mas o que interessa para o "usuário final" é o que ele vê; ele quase nunca vê os bits diretamente.

O verdadeiro culpado nesse exemplo do documento mutante é, em grande medida, a expectativa irreal que muita gente tem de que um documento do Word é "a mesma coisa que um documento em papel", bem como seu desconhecimento de alguns dos recursos do Word.

Explico: se, com o documento aberto no seu Word, você clicar na palavra "CONTRATADA" ou "CONTRATANTE" com o botão direito do mouse e, no menu de contexto que aparece, pedir a opção "Alternar códigos de campo", verá algo parecido com o mostrado na figura abaixo:

Na realidade, as palavras "CONTRATANTE" ou "CONTRATADA" são o resultado da execução de um mini-programa de computador que, se traduzido para o português, seria mais ou menos assim: "veja que horas são no relógio do computador, descartando as horas e os minutos e considerando somente os segundos. Se os segundos estiveram antes de 30, exiba 'CONTRATANTE'; caso contrário, exiba 'CONTRATADA'". É o texto desse programa, representado em bits, e não o resultado da execução dele, que foi incluído no cálculo do MD5. É por isso que o hash MD5 permanece o mesmo e as assinaturas digitais permanecem válidas, ainda que a aparência visual percebida do texto mude.

Esse foi um exemplo didático, otimizado para ser fácil de explicar e de entender. Contudo, versões mais sofisticadas desse tipo de truque poderiam ser usados para ludibriar leigos na hora de celebrar contratos por meios digitais, como muito bem discutiu o meu amigo Pablo Cerdeira nesse artigo.

O cerne da questão é que, entre os bits que estão armazenados no disco rígido do seu computador e o que o usuário realmente vê na tela existem os programas de computador, como o Word, que "interpretam" esse bits e desenham coisas na tela. Só que essa "interpretação" é, em muitos casos, complexa e variável. Por exemplo, se você abrir mesmo documento mutante no Open Office Writer, essa "ilusão de ótica" não funcionará, porque recurso de "campos calculados" do OO Writer não funciona de forma exatamente idêntica a do Word.

Os advogados me ensinaram que esse truque do documento mutante só é fatal se ele passar desapercebido: se, ao invés, ele for descoberto, ainda que a posteriori, poderá ser usado para provar má fé de uma das partes. Menos mal.

É por isso que eu recomendo que documentos digitais que pretendam espelhar atos jurídicos sejam gerados usando formatos de imagem tipo "bitmap" simples. Nos arquivos tipo "bitmap", há uma correspondência biunívoca precisa entre o "bit a bit" e o "visualmente percepível"; portanto, esses arquivos não admitem truques como o do "documento mutante" acima. Essa simplicidade e rigor simplificam as perícias digitais, tornando seus resultados menos dependentes de interpretações subjetivas e mais próximos da objetividade clara e desapaixonada que só a matemática tem.

Para citar um exemplo prático: foi por isso que, no Programa Minha Certidão do qual eu falei no post anterior, eu insisti para que os documentos fossem gerados e assinados usando arquivos tipo "BMP" em modo monocromático de um bit por pixel. Esses arquivos são tão simples que a parte principal deles dá pra explicar em uma frase: se o bit for zero, ele aparece como um pixel branco; se o bit for um, ele aparece como preto.

Conclusões

Eis aqui o que eu gostaria que o leitor lembrasse após ler este meu artigo (que, pra variar, acabou ficando mais longo do que eu queria – e olha que eu deletei um monte de "causos" legais que eu tinha pra contar):

  • A primeira etapa das geração de assinaturas digitais é o cálculo os tais "super dígitos verificadores" ou "identificadores", dos quais existem vários algoritmos específicos. Entre os mais famosos há o MD5, SHA1, SHA256, etc. Nos próximos posts, vou explicar como funciona e o que faz a segunda etapa da geração das assinaturas digitais.

  • Assinaturas digitais são totalmente diferentes de assinaturas manuscritas digitalizadas – elas não são nem sequer parecidas. Como veremos em futuros posts, por caminhos diferentes elas podem chegar a efeitos jurídicos "mais ou menos parecidos", mas são coisas diferentes.

  • Se você calculou o hash de um documento e o resultado bateu com o que você ou outra pessoa calcularam, não saia por aí dizendo que o documento está inalterado; diga que eles são "idênticos bit a bit". E, onde e quando couber, ressalte que "idêntico bit a bit" não necessariamente significa "visualmente idêntico" quando você abrir o arquivo através de algum programa.

  • No cálculo de um hash só entra o conteúdo do arquivo; o nome do arquivo, seu tamanho, permissões e metadados do sistema de arquivos não entram na parada.

  • Assinaturas e hashes são criados para ser conferidos. Se você ou o seu sistema não os conferem, ou não dá meios para seu usuários conferi-los, eles pouco ou nada adiantam.

Quando eu estudei criptografia pela primeira vez através dos livros e entendi os teoremas, as técnicas e os algortimos, eu ingenuamente achava que tinha dominado o assunto. Quando fui usá-los em aplicações reais, sobretudo no mundo jurídico, "caí do cavalo": descobri que eu mal tinha arranhado o comecinho do assunto. O uso dessa tecnologia em aplicações práticas requer levarmos em conta esses "mal entendidos" aos quais as pessoas foram expostas, bem como outros fatores que transcendem a área de criptografia, como essa questão dos tipos de arquivos e a diferença entre "idêntico bit a bit" e "visualmente idêntico".

Mais ainda, aprendi que é preciso explicar isso para as pessoas e que se explicarmos direito – adivinhe! – elas entendem. Se os itens acima te ajudarem a se comunicar melhor com os "leigos", esse artigo terá cumprido sua função.



1 Sim, eu sei que o MD5 é considerado vulnerável e obsoleto, mas resolvi usá-lo mesmo assim porque: a) sendo o mais difundido, é o mais fácil de se encontrar programas calculadores; b) vai me dar chance de discutir, em posts futuros, suas fraquezas [ voltar ]

2 Sob o risco de soar pedante: a função MD5 só é definida para dados de até 264-1 bytes de tamanho. Mas isso equivale a mais de 18 quintilhões de bytes, mais do que a soma de todos os dados digitais no mundo inteiro. Por isso, podemos "arredondar" e assumir que ela vale para arquivos quaisquer. [ voltar ]

Parte anterior

Próxima parte

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.
Alex | 2013-10-09 20:11:04 | permalink | topo

Olá. Excelente texto. Estou procurando um meio de validar documentos do Word automatizando este cálculo de hash, mas pelo jeito isto não é possível, dada a vulnerabilidade do formato. Agradeço se auxiliar de alguma forma.

Victor Hora | 2011-09-19 22:07:53 | permalink | topo

Kiko,

Apesar de ter demorado meses pra comentar o seu artigo, aproveitei que o reli hoje pra fazer alguns comentários.

Parabéns pelo artigo! Desde que comecei a trabalhar com você (a mais de 6 anos!) não canso de me impressionar com a sua capacidade de "descer o nível" para os leigos e conseguir explicar de uma maneira compreensível.

Em todos esses anos de convivência eu realmente não me lembro de ter ouvido ou visto essa associação dos hashes a dígitos verificadores... Ou será que o tempo queimou os meus neurônios? :P

Brincadeiras a parte, a forma de explicar é interessante e bastante compreensiva. Vou tomar emprestado essa idéia quando eu for explicar PKI para alguém :P

Cheers.

BZoby | 2011-05-13 15:27:45 | permalink | topo

Grande Kikko!

Aqui quem lhe fala é um antigo colega de lista de um antigo provedor de internet que nem sei se ainda existe (o provedor, pois a noticias-l eu sou capaz de apostar que não mais, hehe).

Enfim, muito legais seus artigos, bem como os de seus colegas de blog. Bem informativos e numa linguagem de fácil leitura. Parabéns pelo trabalho.

Se me permite, tenho duas sugestões para futura exploração. Dois tópicos nos quais o Brasil tem ou compartilha liderança em âmbito mundial (de facto ou aparente):

* Os riscos envolvidos no processo do voto eletrônico no Brasil e a evolução do máquinário eleitoral utilizado (urna e backend).

* A implementação da Cardeira de Identidade Única e o trade-off entre agregação vs. compartimentalização de dados civis.

Abraço,

Marco Carnut | 2011-05-03 16:43:52 | permalink | topo

Enildo e Paulo: futuramente vou abordar longamente a questão dos tipos de arquivos complexos, inclusive o caso do PDF. O assunto é vasto o bastante para merecer um post só pra isso.

Enildo: puxa, esses posts estão enormes (nunca canso de me impressionar como o assunto é vasto) e você ainda quer que eu os torne maiores contando "causos"?!? Assim ninguém vai ter paciência de ler! :)

Enildo | 2011-05-03 16:17:14 | permalink | topo

Kiko, mais uma vez seus artigos são de grande valia, reforço o pedido de Pedro, assim como não é recomendado utilizar o formato do tipo .doc, o que você acha do formato PDF. E nos próximos artigos, pode colocar os causos deletados.

abs

Pedro | 2011-04-28 17:47:32 | permalink | topo

Muito Interessante o post. Seria bom também comentar o porque não usar o formato PDF, que é um meio bastante utilizado para o compartilhamento de documentos.