Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

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 .

PreviousCasos de Uso: Cenários 1 a 3NextIntegração, Boas Práticas e Apêndices

Last updated