criptografia externa

Criptografando dados (P2P) em clientes externos

Home > Criptografando dados (P2P) em clientes externos

No RAL foi implementado a técnica de transferência de dados entre o Cliente (TRALClient) e o Servidor (TRALServer) de forma criptografada.

Podemos definir os seguintes tipos de criptografia: AES128, AES192 e AES256, todas no formato CBC (padrão) com padding PKCS7

Como até o momento não foi encontrada uma RFC que padronizasse o uso de criptografia para trafegar dados sob o protocolo HTTP, a mesma foi implementada utilizando cabeçalhos para que o Cliente e Servidor pudessem “conversar”.

Foi encontrada em pesquisas a RFC 8188, o qual trata apenas de criptografia no AES128_GCM, mas lembramos que existe a possibilidade de ter um conteúdo comprimido (ex: GZip ou Deflate) seguido de criptografia. Para solucionar isso foi criado os seguintes cabeçalhos: Content-Encription e Accept-Encription.

O cabeçalho Content-Encription define qual é a criptografia que foi utilizada para criptografar os dados, podendo ser: aes128cbc_pkcs7, aes192cbc_pkcs7 ou aes256cbc_pkcs7. Já o cabeçalho Accept-Encription define quais os tipos de criptografia aceita pelo cliente ou servidor, podendo ser: aes128cbc_pkcs7, aes192cbc_pkcs7 e aes256cbc_pkcs7.

Exemplos:

• Transferindo dados apenas criptografados

  POST /teste/dados HTTP/1.1
  Host: localhost:8000
  Authorization: Bearer "token"
  Connection: keep-alive
  Content-Encription: aes128cbc_pkcs7
  Acception-Encription: aes128cbc_pkcs7, aes192cbc_pkcs7, aes256cbc_pkcs7
  Content-Type: application/json
  Content-Length: 239
  
  <conteúdo criptogrado com aes128>
  

  Resposta

  HTTP/1.1 200 OK
  Date: Thu, 19 Oct 2023 21:27:21 GMT
  Content-Type: application/json; charset=utf-8
  Transfer-Encoding: chunked
  Connection: keep-alive
  Content-Encription: aes256cbc_pkcs7
  Content-Length: 540
  
  <conteúdo criptogrado com aes256>
  

  Note que no exemplo acima o cliente enviou os dados em aes128 e recebeu como resposta dados criptografados em aes256, o motivo disso esta no cabeçalho Accept-Encription

• Transferindo dados criptografados e comprimidos

  Nesse tipo de transferência devemos optar por comprimir primeiro os dados e depois criptografa-los, pois normalmente o algoritmo de criptografia é mais lento que o algoritmo de compressão

  POST /teste/dados HTTP/1.1
  Host: localhost:8000
  Authorization: Bearer "token"
  Connection: keep-alive
  Content-Encoding: gzip
  Accept-Encoding: gzip, deflate
  Content-Encription: aes128cbc_pkcs7
  Accept-Encription: aes128cbc_pkcs7, aes192cbc_pkcs7, aes256cbc_pkcs7
  Content-Type: application/json
  Content-Length: 239
  
  *<conteúdo comprimido e depois criptogrado com aes128>*
  

  Resposta

  HTTP/1.1 200 OK
  Date: Thu, 19 Oct 2023 21:27:21 GMT
  Content-Type: application/json; charset=utf-8
  Transfer-Encoding: chunked
  Connection: keep-alive
  Content-Encoding: gzip
  Content-Encription: aes256cbc_pkcs7
  Content-Length: 540
  
  <conteúdo *comprimido e depois* criptogrado com aes256>
  

  Note que no exemplo acima o cliente enviou os dados em aes128 e recebeu como resposta dados criptografados em aes256, o motivo disso esta no cabeçalho Accept-Encription

Configurando o RAL para usar criptografia

Foi criado nos clientes RAL a propriedade CriptoOptions, com as seguintes propriedades:

• CriptType: com as opções: crNone, crAES128, crAES192, crAES256
• Key: chave ou password

Uma vez definida a chave na propriedade do Cliente com a mesma chave definida no servidor ambos passam automaticamente a trocar mensagens criptografadas