Na Invillia, toda quarta-feira, ao meio dia, paramos uma hora para nos nutrir com as dicas, how-tos, boas práticas e tendências selecionadas por nossos especialistas em Product, Agile, Back e Front, Mobile, Quality, Security e Data. Uma troca de experiência vital para quem adora o novo. E essencial para que a inovação nunca pare. Se tecnologia está no sangue. A gente faz questão de deixá-la circulando cada vez mais_
NA VEIA_ Encryption as the new normal_
5 minutos de leitura
Deixamos aqui os principais aprendizados da edição apresentada por Alexandre Braga, especialista em Segurança, incluindo alguns insights de seu paper.
O conceito
A criptografia (do grego kryptos, significando oculto) é a única tecnologia capaz de garantir o sigilo, a autenticidade, a integridade e a irrefutabilidade da informação em trânsito pelos meios eletrônicos:
- Confidencialidade (ou sigilo) é obtida para manter a informação secreta, confidencial. Enviar e-mails encriptados e manter arquivos encriptados são exemplos de confidencialidade.
- Autenticação é obtida para validar a identidade de uma entidade. Um exemplo é a assinatura digital para verificar a autoria de um documento eletrônico.
- Integridade é obtida para garantir que uma porção de dados não foi modificada desde a sua criação. Códigos de detecção de erros são exemplos de mecanismos para verificação de integridade de dados.
- Irrefutabilidade é obtida como meio de assegurar que o autor de uma mensagem autêntica não possa negar para um terceiro a sua autoria.
Na prática, estes serviços são usados juntos. Por exemplo, uma mensagem de correio eletrônico pode ser encriptada e assinada digitalmente. Deste modo, tanto a confidencialidade quanto a autenticação estarão garantidas. Visto que a assinatura digital é única para a mensagem, a integridade também é preservada.
O sistema criptográfico
A imagem abaixo mostra um sistema criptográfico e seus elementos fundamentais. Três personagens ilustram a figura: Ana, a remetente das mensagens; Beto, o destinatário das mensagens; e Ivo, o adversário com desejo de conhecer os segredos de Ana e Beto. As mensagens passam por um canal de comunicação inseguro e controlado por Ivo. O algoritmo criptográfico é usado para transformar o texto em claro (legível por qualquer um) em texto encriptado (o criptograma legível apenas por Ana e Beto) e vice-versa.
A chave criptográfica é o parâmetro de configuração do algoritmo que viabiliza a recuperação de um texto claro a partir do texto encriptado. Ana e Beto usam uma chave criptográfica conhecida apenas por eles e compartilhada (ou combinada) por um canal seguro diferenciado. Teoricamente, diz-se que a segurança do sistema criptográfico reside no segredo da chave e não no segredo do algoritmo criptográfico. Grosso modo, em sendo usado um algoritmo de boa reputação, a qualidade da implementação deste algoritmo e o tamanho da chave determinam a dificuldade em quebrar a encriptação da mensagem. A Figura tem os seguintes passos:
- Ana configura o algoritmo de encriptação com a chave compartilhada com Beto;
- Ana passa o texto claro para o algoritmo e obtém o criptograma;
- O criptograma é transmitido pelo canal inseguro e recebido por Beto;
- Beto configura o algoritmo de decriptação com a chave compartilhada com Ana;
- Beto decripta o criptograma recebido e obtém o texto claro original.
Os tipos de sistemas criptográficos
Existem dois tipos de sistemas criptográficos, conhecidos como criptografia de chave secreta (ou simétrica) e criptografia de chave pública (ou assimétrica). Na criptografia de chave secreta, uma única chave é usada para encriptar e decriptar a informação. Na criptografia de chave pública, duas chaves são necessárias. Uma chave é usada para encriptar; a outra chave, diferente, é usada para decriptar a informação. Estas duas chaves são matematicamente relacionadas e trabalham aos pares, de modo que o criptograma gerado com uma chave deve ser decriptado pela outra chave do par. Cada chave inverte o trabalho da outra e nenhuma pode ser usada sozinha em um sistema criptográfico. Nos sistemas de chave pública, uma das chaves do par é dita privada (a de decriptação), a outra é feita pública (a de encriptação).
O padrão de projeto de software criptográfico
A imagem abaixo mostra o diagrama de classes, em UML, de um sistema criptográfico simétrico para sigilo, em que Ana encripta e Beto decripta. Ana e Beto usam a criptografia por meio de um aplicativo (App), em instanciações distintas, AnaApp e BetoApp, respectivamente. O App possui uma classe com estereótipo de controlador (CriptoCtrl) que é responsável por orquestrar os serviços criptográficos e a configuração de parâmetros de segurança juntamente com a lógica da aplicação. Por exemplo, no caso de Ana, o CriptoCtrl formata a mensagem m em um formato adequado para a criptografia, encripta o texto claro tc com a chave ke e faz com que Beto receba o criptograma c. Beto, por sua vez, utiliza o seu orquestrador criptográfico para decriptar c com a chave kd e converter o texto claro tc para a formatação requerida m. Ana e Beto utilizam instâncias diferentes da mesma classe Algoritmo (criptográfico).
A criptografia e o programador
“Não gosto de criptografia, mas sou obrigado a usar. E agora?” é uma frase muito ouvida dos programadores porque antigamente ela era feita mais em infraestrutura e pouco em aplicação. Mas isso mudou radicalmente. Os softwares criptográficos mais populares são os aplicativos com criptografia na lógica de negócios. O uso correto da criptografia na aplicação já não é um problema de infraestrutura, não é resolvido apenas com TLS e não é só https.
Cada vez mais as empresas que têm requisitos de segurança rigorosos viabilizam isso via criptografia. Por exemplo, nas aplicações de pagamentos eletrónicos. Todas as FinTechs precisam inventar lógica de negócios misturando criptografia dentro da lógica da aplicação.
O software criptográfico é por isso cada vez mais comum. Você tem, usa ou faz. Numa busca na sua loja de aplicativos predileta, vai achar uma porção de software que se auto-declara criptográfico. E aí começam os problemas.
O mau uso
O mau uso da criptografia é demasiado frequente. Os times de desenvolvimento não têm necessariamente formação em segurança e muito menos em criptografia. Há diversos estudos que comprovam que a maior parte das vulnerabilidades de aplicação associadas à criptografia estão relacionadas ao seu uso e não a problemas de implementação do algoritmo. Não é a insegurança da matemática, não é a insegurança do algoritmo, não é a insegurança da biblioteca, é o modo como se usa:
Legenda: OJC – Oracle Java Cryptography | GAD, GASD – Google Android Developers / Security Discussions
E a grande questão é que o mau uso se mantém ao longo do tempo. Porque tudo é dinâmico e vai mudando. O “arroz com feijão” da criptografia é bom, mas não o suficiente:
- Evitar a criptografia fraca ou obsoleta
- DES, 3DES, RC4, MD5, MD2, SHA-1
- Evitar tamanhos de chave inseguros
- <2048 para RSA
- <2048 para DH
- < 128 para encriptação simétrica
- < 256 para hashes (tamanho da saída)
- < 256 para ECC
O código fonte
Uma vez que o “arroz com feijão” não é suficiente, há que partir para o que mais interessa, que é o código fonte. Numa adaptação da famosa frase da Mafalda: Viver sem ler código fonte é perigoso. Obriga a acreditar no que dizem.
Para uma visão prática, consulte https://bitbucket.org/alexmbraga/crypto4developers (pastas mc-2019 e tutorial) do nosso especialista Alexandre Braga com uma API criptográfica Java, que complementa os 3 capítulos de seu livro:
- Introdução à Criptografia para Programadores: Evitando Maus Usos da Criptografia em Sistemas de Software
- Criptografia Assimétrica para Programadores – Evitando Outros Maus Usos da Criptografia em Sistemas de Software
- Introdução à criptografia para administradores de sistemas com TLS, OpenSSL e Apache mod_ssl
Conclusão
Criptografia não é mais um problema só de infraestrutura. Criptografia é um problema de desenvolvimento. E na Invillia estamos bem cientes disso. Para garantir que as inovações que co-criamos com game-changers das mais avançadas indústrias, são seguras logo na origem. Em que a prioridade é a prevenção e não a reação.
Vamos desenvolver juntos seu próximo aplicativo super seguro? Fintech, Regtech, Govtech, Biotech, Healthtech, Agritech, Mediatech, Hometech, Edtech, Anytech_ conte conosco_