> For the complete documentation index, see [llms.txt](https://ftcoders.first-tech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ftcoders.first-tech.com/hop-kms/key-derivation/introducao-e-fundamentos.md).

# Introdução e Fundamentos

Esta página apresenta os conceitos de criptografia e gerenciamento de chaves que fundamentam o funcionamento do HoP KMS v4. 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 v4, 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. Ela nunca é exposta para fora do hardware seguro.
* KSN (Key Serial Number): Um número público identificador enviado junto com cada transação. No padrão AES DUKPT, o KSN possui 24 caracteres hexadecimais (12 bytes) e é estruturado da seguinte forma:

<p align="center"><span class="math">\text{KSN} = \text{Key Set ID} \parallel \text{Device ID} \parallel \text{Transaction Counter}</span></p>

* IKEY (Initial Key / IPEK): A chave gerada a partir da primeira derivação da BDK usando o KSN inicial do terminal. É esta chave que o HoP KMS v4 devolve para a sua aplicação realizar o provisionamento seguro do mPOS.

### 2. O Papel da IKEY (Initial Key)

Diferente do modelo v3 (onde o servidor KMS entregava chaves de sessão prontas para a aplicação), a versão v4 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 v4 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:

<figure><img src="/files/P7U9g5dyJCub9Uxgavl5" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/qPOdeXq1nf2DQLF8REtT" alt=""><figcaption></figcaption></figure>

### 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 a curva de alta segurança 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:

<p align="center"><span class="math">S = d_A \cdot Q_B = d_B \cdot Q_A</span></p>

5. 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).
6. O HoP KMS cifra a IKEY dentro do TR-31 utilizando esta ZMK efêmera e envia o resultado no payload.
7. Sua aplicação, tendo calculado o mesmo segredo $$S$$, decifra o TR-31 localmente e recupera a IKEY com segurança absoluta.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ftcoders.first-tech.com/hop-kms/key-derivation/introducao-e-fundamentos.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
