Esclarecendo alguns conceitos práticos importantes sobre criptografia

Versão curta deste post: Se você planeja enviar PIIs (Personally Identifiable Information — informações tais como CPFs, e-mails, números de telefone, etc.) a alguma ferramenta de web analytics, utilize no mínimo o algoritmo de hash SHA256, preferencialmente com algum sal. Além disso, garanta sempre a mesma codificação em todos os envios de dados (Base64/Hexadecimal, Uppercase/Lowercase) para facilitar o cruzamento.

A disciplina de criptografia possui a infeliz propriedade de ter aplicações práticas relevantes para praticamente todo mundo na atual era digital e ser tão vasta e complexa que não é razoável de se esperar que todas estas pessoas tenham um bom domínio sobre ela. Como consequência, alguns conceitos importantes são mal compreendidos ou simplificados de maneira perigosa.

O objetivo deste post é esclarecer alguns destes conceitos, tendo como foco principalmente o universo de web analytics, mas acreditamos que as informações possam ser úteis de maneira mais geral também.

A seguir vamos pincelar o que são e para que servem algoritmos de chave simétrica/assimétrica, algoritmos de hash e codificações, de modo a deixar claro que são todos conceitos diferentes e é interessante que, ainda que nem todos devam ser especialistas em segurança, aqueles mais envolvidos nos processos mais técnicos tenham essa distinção bem clara em mente.

Definições iniciais e algoritmos de hash

Existem três tipos de algoritmo de criptografia: chave simétrica, chave assimétrica e funções de hash (espalhamento, em português). Uma característica extremamente importante que separa os usos dos dois primeiros do último é a reversibilidade do processo.

No caso de algoritmos de chave simétrica ou assimétrica, o objetivo primário é produzir mensagens cujo conteúdo original deve ser recuperado pelo destinatário, sem que outras pessoas possam ler ou comprometer este conteúdo. Deste modo, é importante que o processo seja reversível, por meio de uma chave.

A noção de que não é possível reverter as funções de hash para obter a mensagem original pode assustar inicialmente, visto que esse é o método correto de enviar identificadores baseados em PIIs para o Analytics. Entretanto, para grande parte das aplicações práticas, isso não é um impeditivo.

Suponha que você já utilize o CPF no sistema do seu negócio e deseja enviá-lo para o Google Analytics como UserID ou chave para ingestão de dados offline. Sendo o CPF uma PII, não é permitido enviá-lo para o Google Analytics sem utilizar uma função de hash (no mínimo SHA256 e uso recomendado de sal, conforme este artigo). Vamos analisar os possíveis usos que você poderia ter para isso:

1. (É possível) Uso como identificador único (UserID): O uso de uma boa função de hash praticamente garante¹ que dois CPFs distintos gerarão dois códigos distintos. Ou seja, assim como cada usuário é representado por um CPF único no seu sistema, ele será representado por um código único equivalente no Google Analytics.
2. (É possível) Importar dados de usuário do seu sistema para o Google Analytics: Suponha que você tem disponível alguma informação sobre o usuário com CPF A na sua base de dados como, por exemplo, sexo ou idade cadastrados. O uso de uma função de hash garante que a aplicação desta sobre o CPF A sempre retorna o mesmo código. Deste modo, basta aplicar o mesmo algoritmo implementado na coleta de dados online no arquivo que será enviado ao Google Analytics, e o cruzamento irá ocorrer sem problemas.
3. (É possível) Extrair dados de navegação do Google Analytics para seu sistema: Este item é um pouco mais complicado que o anterior, mas segue de uma ideia simples: Não é proibido que o cliente mantenha uma relação de CPF e códigos gerados pela função de hash no sistema delas. Deste modo, ao exportar os dados de navegação cruzados com os códigos do Google Analytics, o próprio pode cruzá-los com sua base interna.
4. (Não é possível) Enriquecer os relatórios padrões do Analytics com PIIs: É permitido enviar, por exemplo, o e-mail de um usuário após passá-lo por uma função de hash e, posteriormente, montar um relatório customizado com essa informação. Entretanto, o relatório não seria legível, pois apresentaria apenas os códigos finais.

Também não seria possível, por exemplo, buscar pessoas pelos nomes nos relatórios padrões da ferramenta, caso o interesse seja analisar o comportamento de um indivíduo específico.

Sobre codificações

Este tópico é especial, pois uma codificação (encoding) não é resultado de um algoritmo criptográfico, mas percebemos que existem duas confusões comuns que podem surgir e gostaríamos de esclarecê-las.

Falando de forma técnica, uma codificação consiste no mapeamento da representação em bytes das informações do computador para símbolos, tais como letras ou números. Por exemplo, uma codificação comum na internet é o UTF-8, que traduz cadeias de bytes em caracteres arábicos, chineses ou números que podem ser exibidos aos usuários. Outras codificações, com usos diferentes de comunicação, são hexadecimais, base64, url encoding (utilizado em requisições HTML), etc.

A primeira grande confusão surge do fato que o resultado de algoritmos criptográficos é geralmente uma cadeia de bytes. Poderíamos, sim, exibir na tela uma sequência tal como 01110111…, mas isso gastaria muito espaço. Desse modo, é comum que seja utilizada uma codificação tal como base-64 ou hexadecimal para representar essa informação. Ou seja, além do algoritmo criptográfico é necessário escolher uma codificação. Normalmente não é difícil converter de uma representação para outra, mas em alguns contextos como a importação de dados do Google Analytics é importante escolher apenas uma e utilizar a mesma em todos os métodos de envio.

A segunda confusão é uma consequência direta dessa facilidade de conversão: Uma codificação não proporciona segurança ou garantia legal nenhuma, pois qualquer um pode convertê-la, ou seja, é reversível sem esforço algum. No Javascript, as funções atob e encodeURIComponent ambas geram codificações (respectivamente, base-64 e url encoding), então não devem ser utilizadas para, por exemplo, mascarar PIIs no envio para o Google Analytics.

Para que os dois pontos acima fiquem claros, apesar de todo tequiniquês, sugiro que explorem a seguinte ferramenta online, que gera hashes utilizando vários métodos SHA diferentes e disponibiliza a representação em hexadecimal e base-64, que são totalmente equivalentes: https://approsto.com/sha-generator/

Voltando aos algoritmos reversíveis

Normalmente, não é comum trabalhar-se diretamente com algoritmos de criptografia de chave simétrica ou assimétrica, então quase todos os usos diretos dessas técnicas estão muito provavelmente equivocados. Isso pode parecer estranho, visto que obviamente toda comunicação em rede e até mesmo alguns dados em repouso (ex: Google Drive, BigQuery) são criptografados. O que ocorre é que essas não são aplicações simples dos algoritmos em contextos isolados e sim protocolos complexos que combinam múltiplas técnicas diferentes.

Encontramos uma boa analogia neste artigo: “AES é, para um sistema de criptografia seguro, o que dióxido de urânio é para um reator nuclear funcional”. No caso, AES é um uma especificação de algoritmo de chave simétrica. Gostamos dela pois deixa explícito o quão perigoso é o uso dessas tecnologias. A realidade é que os melhores do mundo cometem erros na implementação desses protocolos.

Apesar de existirem riscos no uso de algoritmos de hash, as aplicações mais comuns são simples o bastante para isso não ser um problema. Além disso, por eles serem irreversíveis por natureza, a garantia de segurança já é um pouco maior.

Para concluir, uma tabela

Apesar da grande diferenças técnica entre estes conceitos, neste post os diferenciamos em cima de três principais características diferentes:

1. É reversível? Define se é possível recuperar a informação original. Novamente, diversas aplicações práticas não requerem que isso seja possível, então um método não-reversível ainda pode ser útil.
2. Protege a informação? Se for possível recuperar a informação original, o quão difícil é isso? Utilizar métodos que não oferecem proteção nenhuma é um erro comum e pode ser desastroso.

3. Uso comum? Define o quão comum é o uso direto dessas técnicas no dia-a-dia. O uso desnecessários de técnicas mais sofisticadas pode ser perigoso.

Esperamos que a distinção entre estes três conceitos esteja mais clara após a leitura, principalmente quanto aos casos de uso de algoritmos de hash, clarificando o porquê desta ser uma boa prática recomendada para o envio de PIIs.

Perfil do autor: Gabriel Higa Takeshi | Formado em Ciência da Computação pela USP. Atualmente atua como engenheiro e analista de dados na DP6. Principais áreas de interesse: Estatística, otimização e aprendizado de máquina.