Introdução e Fundamentos

Esta página apresenta os conceitos de criptografia e gerenciamento de chaves que fundamentam o funcionamento do HoP KMS v2. Compreender esses pilares é essencial para garantir uma integração segura e em conformidade com as exigências do PCI (como o PCI-MPoC).

1. O Padrão DUKPT (AES)

O DUKPT (Derived Unique Key Per Transaction) é o padrão ouro na indústria de meios de pagamento para a proteção de transações financeiras. O seu principal objetivo é mitigar o impacto de vazamentos: se um invasor conseguir comprometer a chave de uma transação específica, ele não terá acesso às transações anteriores nem às futuras.

No HoP KMS v2, utilizamos a especificação AES DUKPT conforme a norma ANSI X9.24-3-2017.

Componentes Principais do DUKPT

• BDK (Base Derivation Key): Chave simétrica mestra custodiada com segurança máxima dentro do HSM do HoP KMS. Criada através de cerimonial de chaves, nunca é exposta fora do ambiente seguro e serve como raiz de confiança para a derivação de chaves filhas.

• IKEY / IPEK (Initial Key / Initial PIN Encryption Key): Chave inicial do terminal, derivada diretamente da BDK a partir do KSI do dispositivo. O HoP KMS v2 retorna esta chave para que a aplicação realize o provisionamento seguro do mPOS/PINpad.

• KSI (Key Set Identifier): Identificador estático do dispositivo e da família de chaves. No padrão AES / Key Block (ANSI X9.143 / TR-31), possui 16 caracteres hexadecimais (8 bytes / 64 bits) e é estruturado como: $\text{KSI} = \text{BDK ID} \parallel \text{Device ID}$

  • BDK ID (4 bytes / 8 hex): Identifica a BDK mestre no HSM para roteamento da transação e segmentação de segurança por cliente ou produto.

  • Device ID (4 bytes / 8 hex): Identifica univocamente o terminal físico (TRSM) ou aplicação móvel.

• KSN (Key Serial Number): Identificador único enviado a cada transação para indicar ao HSM qual chave individual utilizar no desacoplamento da mensagem. No padrão AES DUKPT, possui 24 caracteres hexadecimais (12 bytes / 96 bits) e é formado pela junção do KSI estático ao contador dinâmico:

  $\text{KSN} = \text{KSI} \parallel \text{Transaction Counter}$

  • KSI (8 bytes / 16 hex): Bloco estático de identificação da BDK e do dispositivo.

  • Transaction Counter (4 bytes / 8 hex): Contador incremental que muda a cada operação, garantindo o princípio DUKPT (Derived Unique Key Per Transaction).

2. O Papel da IKEY (Initial Key)

Diferente do modelo v1 (onde o servidor KMS entregava chaves de sessão prontas para a aplicação), a versão v2 foca no fornecimento seguro da IKEY.

💡 Por que a IKEY é suficiente?

A partir do momento em que o terminal mPOS (ou o seu ecossistema seguro de destino) recebe a IKEY e o KSN inicial, ele possui capacidade matemática de calcular de forma autônoma e offline todas as chaves de transação futuras (Working Keys).

Sempre que uma nova transação é realizada, o terminal incrementa o seu Transaction Counter (presente no KSN) e utiliza o algoritmo DUKPT local para derivar uma chave de uso específico para aquela operação, seja para criptografia de PIN, criptografia de dados confidenciais ou autenticação de mensagens (MAC).

3. Envelopamento com TR-31 Key Blocks

Para que a IKEY seja transmitida pela rede sem o risco de interceptação ou manipulação de finalidade, o HoP KMS v2 adota o formato de Key Blocks TR-31 (definido pela norma ANSI X9.143).

O TR-31 é uma estrutura que envolve a chave criptográfica em um envelope seguro composto por três partes:

4. Acordo de Chaves Híbrido (ECDH P-521)

A transmissão segura do TR-31 contendo a sua IKEY exige uma chave de criptografia de transporte exclusiva e dinâmica. Para isso, o HoP KMS implementa o algoritmo Elliptic Curve Diffie-Hellman (ECDH) sob as curva de alta segurança P-256, P-384 ou P-521.

O fluxo matemático para estabelecer o canal seguro ocorre da seguinte forma:

1. Sua aplicação gera um par de chaves efêmeras ECC (Privada $d_A$ e Pública $Q_A$).

2. Ao chamar a API, você envia sua chave pública $Q_A$ no parâmetro keyPublic.

3. O HoP KMS gera seu próprio par efêmero (Privada $d_B$ e Pública $Q_B$).

4. Ambos os lados calculam independentemente o ponto compartilhado secreto $S$ através da multiplicação de pontos na curva elíptica:

$S = d_A \cdot Q_B = d_B \cdot Q_A$

1. Esse ponto secreto $S$ passa por uma Função de Derivação de Chave (KDF) para gerar a ZMK efêmera (uma chave simétrica AES-256 temporária).

2. O HoP KMS cifra a IKEY dentro do TR-31 utilizando esta ZMK efêmera e envia o resultado no payload.

3. Sua aplicação, tendo calculado o mesmo segredo $S$, decifra o TR-31 localmente e recupera a IKEY com segurança absoluta.