> 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/landing-page/modulo-pan/casos-de-uso-cenarios-4-a-6.md). # Casos de Uso: Cenários 4 a 6 ### Cenário 4 - Reissuance de Cartão Preservando PIN Um cartão é reemitido (devido a perda, roubo, vencimento ou programa de fidelidade) e ganha um PAN novo. O cliente não deve precisar de memorizar um novo PIN . O *endpoint* `TranslatePan` re-cifra o PIN existente para o novo PAN sem que o PIN em claro seja exposto em momento algum. #### Sequência de Etapas 1. Acionamento do processo: Um evento (perda reportada, roubo, vencimento programado ou novo programa) aciona o fluxo de *reissuance* no sistema do emissor . 2. Leitura do PIN antigo: O sistema lê o PIN cifrado vinculado ao PAN antigo no cadastro. O PIN ainda está cifrado sob LMK (ou ZPK do emissor, conforme a arquitetura) . 3. Tradução para o novo PAN: O sistema invoca o `TranslatePan` passando o `pin`, o `oldPan` e o `newPan`. O HoP decifra o PIN com referência ao PAN antigo, calcula a nova cifragem com referência ao PAN novo e retorna o resultado . 4. Retorno do PIN re-cifrado: O HoP devolve em `retMultiValue[0]` o PIN que se encontra agora vinculado criptograficamente ao novo PAN . 5. Persistência no novo cadastro: O sistema cria o cadastro do novo cartão com o PAN novo e o PIN re-cifrado. O cadastro antigo é marcado para descomissionamento . 6. Personalização do cartão: A gráfica imprime o cartão novo com o PAN novo. Não é necessário reimprimir o *PIN mailer*, uma vez que o cliente continua a usar a mesma senha . *** ### Cenário 5 - Saque em ATM com Tradução de PIN Um cliente realiza um levantamento de dinheiro num ATM. O PIN passa por múltiplas traduções de chave durante o seu trajeto: TPK (terminal) → LMK (adquirente) → ZPK (emissor) . Cada tradução acontece de forma segura dentro do HSM do ator correspondente. #### Sequência de Etapas 1. Inserção do cartão e PIN: O titular insere o cartão e digita o PIN no teclado (PIN pad) do ATM. O PIN é imediatamente cifrado sob a TPK (chave do terminal) . 2. Envio ao adquirente: O ATM envia ao adquirente o PIN cifrado sob TPK. Para o adquirente, esta TPK atua como uma ZPK específica do canal terminal . 3. Internalização no adquirente: O adquirente invoca o `PinInternalization` no seu HoP para trazer o PIN da TPK (3DES) para a LMK interna (AES). Isto permite a manipulação subsequente sob o domínio interno . 4. Retorno do PIN sob LMK: O HoP devolve o PIN cifrado sob a LMK do adquirente . 5. Tradução para o emissor: O adquirente invoca o `PinEmbossing` (LMK AES → ZPK 3DES, se a chave partilhada com o emissor for 3DES) ou o `TranslatePinLmkToZpk` (se for AES) para preparar o PIN para o envio ao emissor . 6. Retorno do PIN sob ZPK do emissor: O HoP devolve o PIN cifrado pela ZPK partilhada entre o adquirente e o emissor . 7. Encaminhamento da transação: O adquirente envia ao emissor a transação ISO 8583 (saque, MTI 0200) com o PIN cifrado sob a ZPK e os dados do levantamento . 8. Autorização: O emissor valida o PIN através do `ValidatePinIssuerKey` e verifica os critérios de negócio (saldo, limite), retornando a autorização ou a recusa . 9. Repasse ao ATM: O adquirente repassa a resposta ao ATM . 10. Dispensação ou recusa: O ATM dispensa as cédulas (se aprovada) ou exibe a recusa ao titular, finalizando a transação . *** ### Cenário 6 - Migração de Chaves Criptográficas Este cenário ilustra uma operação programada de modernização criptográfica. A base de dados existente está sob ZPK 3DES (legado) e precisa de ser migrada para ZPK AES (devido ao programa PCI DSS ou a uma política interna). O *job* lê os PINs antigos, traduz o domínio e o algoritmo, e persiste sob a nova chave . #### Sequência de Etapas 1. Leitura da base antiga: O *job* de migração lê em lote os registos (PIN cifrado + PAN) da base antiga sob ZPK 3DES . 2. Internalização (3DES → AES sob LMK): Para cada registo, o *job* invoca o `PinInternalization` passando o `zpkKeyIdSrc` (ZPK 3DES antiga), o `zpkKeyIdDst` (LMK AES interna), o `pinBlockSrc` e o `pinBlockFmtSrc` . 3. Retorno sob LMK AES: O HoP retorna o PIN cifrado sob a LMK AES . 4. Tradução para a nova ZPK: O *job* invoca o `TranslatePinLmkToZpk` passando o `keyId` (ZPK AES nova) e o PIN sob LMK AES, garantindo o envio do `formatCode = 4` (formato 48, o padrão para AES) . 5. Retorno sob nova ZPK: O HoP devolve o PIN cifrado sob a nova ZPK AES . 6. Persistência: O *job* grava o registo na nova base de dados com o `keyId` novo. A base antiga é marcada para descomissionamento apenas após a reconciliação completa do lote processado . --- # 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/landing-page/modulo-pan/casos-de-uso-cenarios-4-a-6.md?ask=&goal= ``` `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.