HoP KMS - v1 > v2

Esta página detalha a evolução da nossa arquitetura de gerenciamento de chaves da versão v1 para a v2, os motivos de segurança que impulsionaram essa mudança e o impacto direto na integração do seu sistema.

1. Visão Geral da Mudança

Até a versão v1, o processo de derivação de chaves do HoP KMS entregava ao cliente final as chaves de transação prontas (Working Keys como a PIN Encryption Key, Data Decryption Key, entre outras).

Na versão v2, o HoP KMS adota o padrão estrito de segurança DUKPT (AES) em conformidade com as normas do PCI. Em vez de expor chaves de sessão individuais, a API da v2 agora entrega exclusivamente a IKEY (Initial Key) protegida por um envelope criptográfico seguro no formato TR-31 Key Block.

2. Comparativo de Arquitetura

Para entender o impacto prático dessa transição, veja abaixo como as duas versões se comportam em relação à entrega e ao ciclo de vida das chaves:

2.1 Fluxo na v1 (Modelo Anterior)

Na v1, o servidor de chaves calculava toda a árvore de derivação e entregava à sua aplicação um conjunto de chaves de sessão específicas para aquela transação:

Vulnerabilidade: Trafegar e armazenar chaves de sessão prontas (principalmente chaves de PIN e de dados sensíveis) no servidor da aplicação aumenta significativamente a superfície de ataque e viola diretamente as regras de segurança do PCI-DSS e PCI-PIN, mesmo cifradas.

2.2 Fluxo na v2 (Modelo Atual)

Na v2, o HoP KMS atua como um distribuidor de chaves de partida seguras. Ele gera e entrega apenas a IKEY protegida por um Key Block. A partir dela, o terminal ou o sistema de destino realiza a derivação das chaves de trabalho localmente:

3. Matriz de Diferenças Técnicas

Métrica	Versão v1 (Legada)	Versão v2 (Atual)
Chave Entregue	Múltiplas chaves de sessão (Working Keys).	Apenas a IKEY (Initial Key / IPEK).
Formato de Entrega	String Hexadecimal proprietária.	TR-31 Key Block (Criptografia AES padrão internacional).
Cálculo de Derivação	Executado inteiramente no servidor KMS.	Executado no dispositivo final (mPOS/COTS) a partir da IKEY conforme regras PCI MPoC.
Conformidade Regulatório	Parcialmente aderente ao PCI MPoC.	100% aderente ao PCI MPoC e ANSI X9.24-3.
Segurança de Tráfego	Chaves de uso sensível expostas no payload.	Chave inicial envelopada com metadados e restrição de uso.

4. Por que essa mudança é obrigatória para o seu negócio?

Se o seu produto lida com captura de transações em dispositivos móveis (smartphones, tablets ou POS), a adequação à v2 é essencial pelos seguintes fatores:

1. Adequação aos requisitos MPoC: Os normativos do PCI estabelecem que dispositivos comerciais (COTS) precisam isolar as chaves de transação. A entrega da IKEY permite que o seu aplicativo móvel utilize as APIs nativas do dispositivo seguro para derivar chaves dinâmicas sem nunca expor a chave mestre (BDK).

2. Uso de Key Blocks TR-31: O formato TR-31 não é apenas um algoritmo de criptografia, mas um mecanismo de blindagem. Ele impede o ataque de substituição de chaves, garantindo que uma chave destinada à decifragem de dados nunca possa ser usada, por exemplo, para decifrar uma senha (PIN).

3. Redução do Escopo de Auditoria (QSA): Ao remover o armazenamento e o tráfego de chaves de transação descriptografadas do seu servidor back-end, o escopo da auditoria PCI-DSS da sua empresa é drasticamente reduzido, economizando tempo e recursos de infraestrutura.