Casos de Uso: Cenários 1 a 3

Cenário 1 - Emissão de PIN para Novo Cartão

O emissor produz um cartão novo e necessita de gerar um PIN aleatório, persisti-lo cifrado na sua base de dados e enviá-lo cifrado à gráfica de personalização para impressão num PIN mailer ou exibição num PIN pad seguro ao titular .

Sequência de Etapas

1. Solicitação do PIN: O sistema do emissor invoca o endpoint GeneratePinIssuerKey passando o pan do novo cartão, o pinLength desejado e o keyIdDb da ZPK do emissor que protegerá o PIN durante o trânsito .

2. Geração do PIN: O HoP gera um PIN aleatório no HSM, cifra-o sob a ZPK do emissor e devolve-o no campo retMultiValue.generatedPin. O PIN em claro nunca sai do HSM .

3. Persistência: O sistema do emissor persiste o PIN cifrado vinculado ao PAN na Base de Cartões. O keyIdDb utilizado é armazenado em conjunto para suportar futuras rotações de chave .

4. Envio à gráfica: O sistema envia o PIN cifrado para a gráfica/personalização através de um canal seguro (TLS + chave partilhada). A gráfica necessita de ter a ZPK correspondente disponível no seu próprio HSM .

5. Impressão segura: A gráfica decifra o PIN dentro do seu PIN pad seguro e imprime o PIN mailer físico (ou exibe-o num canal eletrónico controlado). O PIN nunca é manipulado em claro fora do hardware seguro .

---

Cenário 2 - Validação de PIN em Compra com Cartão

O titular insere o cartão num POS e digita o PIN para autorizar uma compra. A transação percorre o ecossistema clássico de quatro partes (POS → adquirente → bandeira → emissor) até chegar ao HoP do emissor para validação criptográfica do PIN .

Sequência de Etapas

1. Inserção do cartão e PIN: O titular insere o cartão na máquina (POS) e digita o PIN. O POS cifra o PIN imediatamente sob a TPK (chave do terminal) .

2. Envio ao adquirente: O POS envia ao adquirente uma mensagem ISO 8583 com o PIN cifrado e os dados da transação .

3. Encaminhamento à bandeira: O adquirente encaminha a transação (após eventualmente traduzir o PIN para a ZPK partilhada com a bandeira) .

4. Encaminhamento ao emissor: A bandeira encaminha a transação ao emissor do cartão, incluindo o PIN cifrado pela ZPK partilhada entre a bandeira e o emissor.

5. Validação no HoP: O emissor invoca o endpoint ValidatePinIssuerKey passando o PIN recebido (pin sob keyId), o PIN armazenado na sua base (pinDb sob keyIdDb), e o PAN. O HoP traduz o PIN recebido para a LMK, decifra ambos dentro do HSM e compara os valores .

6. Resultado da validação: O HoP retorna retValid = true se o PIN for válido, ou false caso contrário. O emissor verifica então as restantes variáveis de negócio (saldo, limite, fraude) para decidir a autorização .

7. Resposta à cadeia: O emissor envia a resposta de autorização (aprovação ou recusa) à bandeira . A bandeira repassa a resposta ao adquirente , que a transmite de volta ao POS .

8. Notificação ao titular: O POS informa o titular sobre a aprovação ou recusa, finalizando a transação .

---

Cenário 3 - Reset de PIN via Canal Digital

O titular esqueceu o PIN e solicita um novo através da aplicação móvel ou internet banking. O emissor gera um PIN novo, persiste o dado e exibe-o ao titular através de um componente seguro (PIN pad virtual na app ou canal homologado) .

Sequência de Etapas

1. Solicitação do reset: O cliente, após autenticação multifator, solicita o reset de PIN na aplicação. O backend valida a elegibilidade e dispara o processo .

2. Geração do novo PIN: O backend invoca o endpoint GeneratePinIssuerKey passando o PAN e o keyIdDb da ZPK do emissor .

3. Retorno do PIN cifrado: O HoP retorna o PIN gerado no campo retMultiValue.generatedPin, devidamente cifrado sob a ZPK do emissor .

4. Atualização da base: O backend atualiza o PIN cifrado no cadastro do cartão na Base de PINs. O PIN antigo é invalidado .

5. Tradução para o canal de exibição: O backend invoca o endpoint PinEmbossing (ou TranslatePinLmkToZpk se o PIN pad for AES) para traduzir o PIN da ZPK do emissor para a ZPK do componente seguro de exibição .

6. Retorno do PIN sob chave do PIN pad: O HoP devolve o PinBlock cifrado sob a chave de destino .

7. Envio ao componente seguro: O backend envia o PinBlock cifrado ao componente, que o decifra dentro do seu próprio enclave seguro (HSM ou secure element local) .

8. Exibição ao cliente: O componente exibe o PIN ao cliente em modo de leitura única (sem permissão de screenshot e sem persistência local). O cliente memoriza o PIN .