Criptografia em AdvPL – Parte 09

Introdução

No post anterior — Post 08 — aproveitamos o certificado criado e configurado no Post 06 para configurar uma conexão segura entre o SmartClient e o TOTVS Application Server. Agora, vamos ver um pouco mais sobre o que são e onde as chaves públicas entram nessa brincadeira, e como isso pode ser usado.

Posts anteriores

Chaves públicas

Até agora vimos superficialmente uma receita de bolo de criação de certificados auto-assinados que foram usados para testes em HTTPS e Conexão Segura entre SmartClient e o TOTVS Application Server. Mas, até agora só vimos chaves privadas — os arquivos .key criados até o momento. Então, cadê a tal da chave pública ?!

Obtendo a chave pública a partir de uma chave privada

Quando geramos o certificado auto-assinado no Post 06, a chave privada foi gerada no arquivo “note-automan-ssd.key“. Para obter a chave pública a partir desta chave privada, podemos usar o comando abaixo:

openssl rsa -in note-juliow-ssd.key -pubout -out note-juliow-ssd-public.key

A chave pública será gerada  e salva no arquivo “note-juliow-ssd-public.key“.

Legal, e  que eu faço com isso ?

Bem, uma chave pública têm muitos usos … vou ilustrar um cenário prático de uso. Imagine que você quer mandar um arquivo confidencial de forma encriptada para um determinado destinatário, porém apenas esse destinatário pode ter acesso ao conteúdo do arquivo. Para isso ser possível e feito de forma segura. a pessoa que vai receber essa mensagem deve ter uma chave privada dela ou criada por ela, extrair a chave pública — a partir da chave privada dela — e lhe enviar a chave pública. A chave pública consegue codificar uma informação, mas apenas a chave privada consegue ler ou decodificar esta informação.

A forma mais elegante de fazer essa troca de arquivos é você criptografar o arquivo usando uma método criptográfico simétrico com uma senha bem forte, que inclusive pode ser gerada dinamicamente, e então você usa a chave pública do destinatário para encriptar o arquivo com a senha — assim você não precisa codificar o arquivo inteiro para o destinatário, mas apenas codificar o arquivo com a senha.

Então você manda o arquivo criptografado para o destinatário, e manda o arquivo com a senha que ele deve usar para abrir esse arquivo, criptografada usando a chave pública dele. Quando ele receber esses dois arquivos, ele primeiro precisa decodificar o arquivo com a senha usando a chave privada dele — que só ele tem acesso — para então descobrir a senha de criptografia do arquivo de dados e poder decodificá-lo.

E onde entra o certificado digital nisso ?

Então, uma parte da mágica do certificado digital é a seguinte: Quando você cria um certificado digital, você deve informar uma chave — privada — para ser usada na criação do certificado. Quando o certificado digital é criado, a chave púbica que faz par com a chave privada utilizada vai dentro do certificado 😀

Logo, para o passo de criptografia anterior, se o cidadão tem um certificado digital, ele pode enviar apenas o certificado dele, que já tem a chave pública dentro. Você apenas extrai a chave pública do certificado que ele te enviar, e usa ela. Assim, inclusive, você pode exigir que o seu destinatário lhe envie um certificado de identidade oficial — como  um eCPF ou eCNPJ — e você pode confirmar com quem você está compartilhando o seu arquivo confidencial 😀

Por exemplo, para obter a chave pública a partir do certificado “note-juliow-ssd.cer” — que criamos para o HTTPS — usando a OpenSSL, usamos o seguinte comando:

openssl x509 -in note-juliow-ssd.cer -pubkey -noout >note-juliow-ssd-public.key 

O comando acima vai obter a chave pública do certificado e salvá-la no arquivo “note-juliow-ssd-public.key“. 

Logo, se alguém conseguir “roubar” apenas o seu certificado, sem a chave privada não dá pra usar ele pra abrir nenhum conteúdo codificado.

Então, uma conexão HTTPS usa a chave pública do certificado do servidor para criptografar os dados ?

R: QUASE ISSO …

Calma, vou explicar … vamos abordar primeiro a conexão HTTPS que configuramos para teste. Ela é uma conexão segura de uma via de autenticação, isto é, ela garante a identidade do servidor no qual o cliente está se conectando. E, a criptografia assimétrica — usada nas chaves públicas e privadas — exige um poder computacional muito maior para serem utilizadas, o que inviabiliza usar ela para codificar as informações, logo as mensagens serão criptografadas na conexão usando um método de criptografia simétrica. Basicamente, o Handhake de uma conexão segura entre o cliente e o servidor com um certificado e chave privada deve permitir ao cliente verificar a autenticidade do certificado usado pelo servidor, e prover um meio de comunicação seguro e inviolável entre eles, de modo que apenas o servidor entenda o que o cliente está enviando, e somente o cliente entenda o que o servidor está devolvendo para ele.

Então, COMO ?!

A versão simples da ópera é a seguinte: Em uma conexão usando criptografia RSA, o cliente gera uma chave criptográfica aleatória de 48 bytes, chamado de pre-master secrete criptografa essa chave usando a chave pública do certificado do servidor. O servidor recebe essa chave e decodifica usando a chave privada dele. Logo depois disso, como as duas pontas — cliente e servidor — tem o pre-master secret, agora ambos vão gerar uma nova chave — chamada master secret, baseada no pre-master secret, e ambos passam a usar essa nova chave para a criptografia simétrica das mensagens entre eles. E, para ter certeza que ambos estão “de acordo”, eles trocam uma mensagem adicional codificada com o algoritmo negociado, e quando ambas as partes finalizam o Handshake, a conexão está segura e pronta para  uso !

Assim, cada conexão de um novo cliente no mesmo servidor cria uma chave simétrica diferente e exclusiva para a conexão entre eles, que só eles sabem como foi gerada. Por isso que, mesmo que você consiga rastrear o inicio de uma conexão HTTPS em uma rede, a chave simétrica “base” da conexão foi gerada pelo cliente, e enviada criptografada para o servidor, e só ele sabe o que tem dentro, e sobre ela foi gerada uma chave mais forte ainda … e mesmo que os dados desde então sejam criptografados com uma chave simétrica, ela é única para esta conexão, e grande demais para ser quebrada.

Conclusão

Em 1976, Whitfield Diffie e Martin Hellman publicaram um estudo científico chamado “New Directions in Cryptography“, introduzindo uma forma radicalmente nova de troca de chaves criptográficas, que ajudaram a resolver um problema fundamental da criptografia. O método de troca de chaves criptográficas ficou conhecido como Diffie–Hellman key exchange, e a criptografia digital que usamos hoje é baseada nisso 😀

Espero que este conhecimento lhe seja tão proveitoso quanto a minha satisfação em compartilhá-lo, e desejo novamente a todos TERABYTES DE SUCESSO !!!

Referências

 

 

Um comentário sobre “Criptografia em AdvPL – Parte 09

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s