Valor Para Codificar Chave

O que é valor para codificar chave e por que todo mundo erra nisso

Você tem um dado sensível — um número de cartão, um PIN, uma string qualquer — e precisa transformá-lo em algo ilegível usando uma chave criptográfica. Esse é o valor para codificar chave no sentido prático. A terminologia varia conforme o provedor do hardware security module (HSM), o gerador de MAC, ou a biblioteca de criptografia que você está usando, mas o conceito é sempre o mesmo: injetar um plaintext, aplicar uma operação criptográfica com uma chave ativa, e obter um ciphertext ou MAC. A parte que as documentações bonitas não mostram é como isso funciona quando o dado de entrada não é limpo. Cartão tem espaços, números têm formatação diferente, o terminal envia em BCD e a máquina espera binário. Se você não tratar isso antes de passar para o módulo criptográfico, o resultado não é apenas errado — é silenciosamente errado. E você só descobre quando a transação é estornada três dias depois.

Valor para codificar chave na prática

No dia a dia operacional, o valor para codificar chave geralmente aparece em três cenários principais: codificação de PAN (Primary Account Number) para tokenização, geração de MAC para integridade de mensagem, e encriptação de PIN block para transmissão segura entre terminal e adquirente. O fluxo básico é este:

• Você recebe o dado bruto do terminal ou da aplicação
• Você aplica o padding e o formatamento corretos (ISO 9797-1, pad method 2, ou ISO 0 padding, dependendo do requisito)
• Você seleciona o bloco de chave ativo no HSM — MCK, MEK,TDEA key — conforme o domínio
• Você executa a operação (ECB, CBC, MAC-, etc.)
• Você converte a saída para a representação que o sistema consumidor espera (hex, base64, TLV)

Cada uma dessas etapas tem armadilhas. A maioria dos erros acontece nos passos 2 e 5, onde a conversão de formatação é feita de forma imprecisa.

Como implementar passo a passo

Vou explicar usando um cenário real: codificar um PAN de 19 dígitos (type 2, ISO 8583) usando uma chave Triple DES no domínio de codificação de PAN, com padding ISO 9797-1 Method 2. Isso é padrão em muitas redes de troca no Brasil e na América Latina. Passo 1 — Preparar o dado de entrada. O PAN precisa estar em BCD (Binary Coded Decimal) de 10 bytes para um número de 19 dígitos. Se o seu sistema recebe o PAN como string ASCII, você converte. Cada par de dígitos ocupa um byte: "4532 0123 4567 8901 2" vira 0x45 0x32 0x01 0x23 0x45 0x67 0x89 0x01 0x20 (o último nibble é preenchido com zero à direita, que é o padding natural do BCD).

Passo 2 — Aplicar padding ISO 9797-1 Method 2. Você adiciona um byte 0x80 seguido de zeros até completar o múltiplo do tamanho do bloco. Para DES (8 bytes) ou TDEA (16 bytes), o resultado final deve ter exatamente 8 ou 16 bytes antes da criptografia. Exemplo para TDEA com PAN de 10 bytes BCD: os 10 bytes do BCD mais 6 bytes (0x80 + 5x0x0) = 16 bytes totais. Não invoque o padding antes de confirmar o tamanho — alguns HSMs aceitam dados de tamanho arbitrário e fazem o padding internamente, outros exigem que você envie exatamente o bloco cheio. Verifique a documentação do fabricante antes de assumir. Passo 3 — Selecionar a chave. No HSM, chaves são organizadas por domínio e tipo. Para codificação de PAN, você normalmente usa uma chave do tipo "PAN encryption key" ou "Data Encryption Key (DEK)" no domínio de segurança apropriado. A chave deve estar ativa e com a permissão de uso para criptografia ECB ou CBC, dependendo do protocolo.

Passo 4 — Executar a operação criptográfica. Para PAN, o modo mais comum é ECB (Electronic Codebook) com TDEA (Triple DES). Some o resultado em hexadecimal. Alguns sistemas exigem CBC com IV zerado; outros usam ECB puro. A escolha afeta diretamente a interoperabilidade com a bandeira ou adquirente. Errar o modo aqui é o erro mais comum que vejo em auditorias. Passo 5 — Converter a saída. O ciphertext em hexadecimal precisa ser formatado conforme o esperado pelo sistema receptor. Às vezes é necessário remover o padding, inverter a ordem dos bytes (endianismo), ou embutir em uma estrutura TLV. Se for para transmitir via ISO 8583, o campo 35 ou 53 pode exigir formatação específica.

Um detalhe que ninguém menciona em tutoriais: o resultado da codificação depende criticamente de qual versão da chave você está usando. Chaves TDEA podem ser executadas em 2TDEA (dois ciclos) ou 3TDEA (três ciclos), e a diferença muda completamente o output. Confirme o modo de execução da chave antes de integrar.

Um problema real que encontrei e como resolvi

Em um projeto de integração com adquirente, recebi um PAN codificado que não batia com o esperado. O HSM retornava um ciphertext, o adquirente rejeitava. Passei duas semanas debugando. Descobri que o problema não era na codificação em si — era no padding. O terminal enviava o PAN em ASCII com espaços ("4532 0123 4567 8901 2"), e meu código convertia para BCD de forma ingênua, mantendo os espaços como bytes 0x20. O HSM processava aqueles bytes extras e gerava um resultado completamente diferente do que o adquirente esperava. A solução foi adicionar uma etapa de limpeza do dado de entrada antes do passo 1: remover qualquer caractere que não fosse dígito, validar o comprimento, e só então converter para BCD. Também adicionei um log que mostra o estado do dado em cada etapa — BCD formatado, padding aplicado, tamanho final do bloco — para que futuros problemas sejam identificados em minutos, não em semanas.

Erros comuns que iniciantes cometem

O primeiro erro é assumir que o HSM ou a biblioteca vai normalizar os dados de entrada por você. Alguns fazem, outros não. Sempre valide e formate antes de enviar. O segundo erro é não documentar qual variante criptográfica está usando. TDEA-ECB com padding Method 2 é diferente de TDEA-CBC com IV aleatório, e ambos são diferentes de AES-128-ECB. A interoperabilidade depende disso. Anote tudo em uma tabela de especificações criptográficas que seja revisada a cada mudança de contrato com adquirente ou bandeira.

O terceiro erro é confiar em bibliotecas de alto nível sem verificar a implementação subjacente. Já vi código usando uma função chamada "encryptPAN" que internamente usava AES em vez de TDEA, gerando resultados incompatíveis com o que o esquema de segurança do contrato previa.

Limitações e quando isso não funciona

O valor para codificar chave baseado em HSM tradicional tem limitações claras. A latência de chamada ao HSM, mesmo via rede local, é da ordem de 10 a 50ms por operação. Em sistemas que precisam processar milhares de transações por segundo, esse overhead é significativo. Além disso, a disponibilidade depende inteiramente do HSM — se o módulo cair, toda a codificação para. Para cenários de alta performance, considere usar criptografia baseada em software com bibliotecas validadas como OpenSSL ou libsodium, desde que o manejo de chaves siga padrões como o NIST SP 800-57. Para tokenização em larga escala, plataformas de tokenização gerenciada (como as oferecidas por maiores processadoras) removem a complexidade operacional, ainda que aumentem a dependência de terceiros.

Também é importante notar que a codificação criptográfica não é a mesma coisa que tokenização. Codificação é reversível com a chave correta — é criptografia de verdade. Tokenização substitui o dado por um valor aleatório sem relação criptográfica reversível pelo operador. Se o requisito é conformidade com PCI DSS e você quer reduzir o escopo de CAR, tokenização é frequentemente a abordagem mais adequada, apesar de exigir infraestrutura diferente.

Resumo operacional

Para codificar um valor com chave de forma segura e interoperável:

• Receba o dado, limpe e normalize (remova espaços, valide comprimento, corrija endianismo)
• Converta para a representação binária requerida (BCD, binário puro, etc.)
• Aplique padding conforme o padrão do contrato (ISO 9797-1 Method 1 ou 2, PKCS#5/PKCS#7, ou zero-padding)
• Selecione a chave correta no domínio correto, verificando o modo de execução (2TDEA vs 3TDEA, AES-128 vs AES-256)
• Execute a operação criptográfica no modo especificado (ECB, CBC, MAC)
• Converta a saída para a representação esperada pelo sistema consumidor
• Logue cada etapa para depuração, sem logar o conteúdo sensível em si

Isso reduz o tempo médio de integração de algo como 2 a 3 semanas para cerca de 3 a 5 dias, desde que as especificações criptográficas do contrato estejam claras desde o início. Se estiverem ambíguas, gaste tempo esclarecendo antes de codificar — não depois.