EFT
As APIs do módulo EFT (Eletronic Funds Transfer) são destinadas às operações de autenticação e verificação de identidade de usuários em transações com cartões Visa e Mastercard.
A identidade do usuário de cartão normalmente pode ser verificada de duas formas:
    1.
    assinatura manuscrita, comparada com um cartão de assinatura mantido pelo emissor de cartão;
    2.
    através de um PIN (Personal Identification Number) informado pelo usuário; A verificação via PIN pode ser feita online, com uma validação feita pelo emissor do cartão, ou offline, usando um cartão com chip.
Os padrões adotados estão em conformidade com o Manual de Padrões de Tecnologia de Pagamentos da Visa (Payment Technology Standards Manual, October 2007).
De forma genérica, o processo de transferência de fundos com cartão, segue o fluxo da figura abaixo. Há vários atores envolvidos no processo. O portador do cartão (card holder) o apresenta ao lojista (Retailer/Merchant), a autenticidade do portador pode ser verificada através de um PIN, que o portador digita na estação do lojista (por exemplo um terminal tipo POS, Point of Sale). A partir daí o PIN é cifrado (é gerado um PIN Block) e os dados da transação são enviados para um prestador de serviços de pagamento eletrônicos, contratado pelo lojista (Acquirer), que por sua envia os dados para o esquema de cartão correspondente, conforme o brand do cartão usado pelo portador, e daí é enviado para o emissor do cartão, que tem os dados de identificação, crédito e outros a respeito do portador e mantém contrato com este para uso do serviço. Após analisar os dados da transação, quanto á cadastro, crédito e autenticação, entre outros, o emissor pode autorizar ou recusar a transação, e esta mensagem de resposta percorre o fluxo no sentido inverso.
Processo genérico de transferência eletrônica de fundos
Do ponto de vista das chaves de criptografia usadas no processo, o processo é mostrado na figura abaixo. Cada ator mantém suas próprias chaves, e sempre que uma mensagem criptografada precisa ir de um ator para outro, a criptografia deve ser traduzida, ou seja, deve ser usada a chave correspondente do ator que deverá fazer a decriptografia da mensagem.
Chaves criptográficas na transferência de fundos
Variações ou simplificações do esquema acima podem ser usados, por exemplo quando a mesma entidade tem mais de um papel, ou há uma comunicação direta do prestador (acquirer) com o emissor (issuer), como pode acontecer em certas transações de débito em conta.
    1.
    Cada chave criptográfica deve ser dedicada a apenas um aplicação, conforme determina o manual da Visa.
    2.
    Os tamanhos informados dos parâmetros se referem aos dados; a aplicação deve garantir que o buffer passado tenha espaço suficiente para os dados e mais o caracter terminador.
    3.
    O módulo EFT trabalha com tamanho de PIN de 4 (MIN_EFT_PIN_LEN) a 12 (MAX_EFT_PIN_LEN) dígitos.
Sobre o suporte ao algoritmos do protocolo 3-D Secure:
O HSM Dinamo implementa os algoritmos criptográficos que suportam o protocolo 3-D Secure, desenvolvido pela Visa. Os serviços Verified by Visa da Visa e Secure Code da Mastercard são oferecidos pelas bandeiras baseados neste protocolo. O HSM implementa os algoritmos criptográficos de verificação de cartão que dão suporte ao protocolo e aos serviços, permitindo ao usuário do HSM fazer a geração e a verificação dos códigos, CVC2 (Card Verification Code 2) e HMAC SHA1 no caso da Mastercard (Secure Payment Application Algorithm) e CAVV (Cardholder Authentication Verification Value, CVV2 com método ATN) no caso da Visa.
O HSM possui suporte aos mecanismos de autenticação CAP (Visa) e DPA (Mastercard).
O HSM fornece suporte ao ATM Remote Key Loading/Transport através de funcionalidades criptográficas baseadas em funções RSA e X.509.
A implementação do HSM está de acordo com os padrões definidos na documentação listada abaixo:
EMVCo
    Integrated Circuit Card Specifications for Payment Systems, Book 2, Security and Key Management v. 4.2, junho 2008
    EMV Card Personalization Specification, v. 1.1, julho 2007
Visa
    Payment Technology Standards Manual, outubro 2007
    Visa Certification Authority Public Keys for Visa Smart Debit/Credit (VSDC), fevereiro 2007
    Visa Smart Debit/Credit Certification Authority Technical Requirements v. 2.1, abril 2006
    3-D Secure Functional Requirements Access Control Server v. 1.0.2, maio 2006
    Visa Integrated Circuit Card v. 1.4.0, outubro 2001
Mastercard
    M/Chip Lite 2.1 Card Application Specifications for Debit and Credit, abril 2003
    M/Chip 4 Version 1.1 Issuer Guide to Debit and Credit Parameter Management, janeiro 2007
    M/Chip 4 Version 1.1 Security & Key Management, junho 2006
    Public Key Infrastructure (PKI) — Certification Authority Interface Specification, janeiro 2005
    Public Key Infrastructure (PKI) — Certification Authority Member Procedures, janeiro 2006
    SPA Algorithm for the MasterCard Implementation of 3-D Secure v1.04, maio 2004
Elo
    ELO Chip Card, CCD Cryptographic Algorithms, s/ versão, s/ data.
    Manual da Autoridade Certificadora Elo - Guia do Emissor, versão 1.2, setembro 2011
JCB
    JCB IC Card Specification, v. 2.0, outubro 2012
    JCB CA Interface Guide, s/ versão, janeiro 2014
    JCB Key Guide, s/ versão, janeiro 2014
Outros
    ANSI X9.24 part 1, Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques
    IBM z/OS V1R9.0 Cryptographic Services ICSF Application Programmer's Guide (3624 PIN Formats and Algorithms)
    ISO/IEC 9797-1 Method 2, Information technology - Security techniques - Message Authentication Codes (MACs) - Part 1, 1999
    IDTECH USER MANUAL SecureMag Encrypted MagStripe Reader (80096504-001 RevL 06/19/14)

Mecanismos de CVV

Há três formas de geração e verificação de CVV (Card Verification Value) no HSM:
    1.
    Card Verification Value (CVV), para transações com cartões de tarja magnética;
    2.
    Card Verification Value 2 (CVV 2); para transações sem a presença física do cartão (via telefone, correios ou Internet, por exemplo);
    3.
    Alternate Card Verification Value (iCVV), para transações com cartões de chip; O mecanismo de cálculo é o mesmo nas três formas, e a diferença está na forma de entrada dos dados pela aplicação.
A chave usada para os cálculos de geração e verificação de CVV é denominada CVK (Card Verification Key). Esta chave é interna ao HSM, a aplicação precisa apenas informar seu nome de chave (id). Fisicamente é uma chave 3DES de 112 bits, o que corresponde à duas chaves de DES de 56 bits.
A Figura abaixo ilustra os esquema para geração e verificação de CVV, iCVV e CVV2.
Geração de CVV, iCVV e CVV 2

Mecanismos de PIN

O HSM trabalha com geração de PIN (Personal Identification Number) por mecanismo de derivação, a partir de uma chave interna, denominada PGK (PIN Generation Key). Esta forma de geração tem várias vantagens, principalmente em relação ao método de geração de PIN com valores aleatórios, pois dispensa o uso de um banco de dados para validação (com provável exposição de dados sigilosos) e ainda mantém tanto o processo de geração quanto de validação, mais seguros, já que são realizados internamente ao HSM.
O padrão utilizado na geração de PIN pelo HSM é o IBM 3624, com o emprego de offsets para permitir a troca de PIN pelo usuário ou pelo emissor do cartão. Para mitigar ataques de decimalização e verificação, o HSM emprega uma tabela de conversão interna, não exposta para a aplicação. Como fator de segurança adicional é empregado uma chave 3DES de 168 bits, ao invés de uma 3DES de 112 bits; não há interferência na operação do algoritmo, já que as chaves DES e 3DES utilizam blocos de entrada e saída do mesmo tamanho.
Geração PIN por derivação
Estão definidos três modos de geração de PIN por derivação:
    1.
    a partir do PAN (Personal Account Number), do PIN de entrada (inPIN) e da PGK;
    2.
    a partir de um PIN de entrada e da PGK, com o uso de um offset permite a troca do PIN pelo usuário;
    3.
    a partir do PAN, da PGK e um PIN de entrada, com o uso de um offset permite a troca de PIN automática;
Não há tratamento para regras de negócio dos PIN gerados dentro do HSM, tal função deve ser exercida pela aplicação chamadora.
Os algoritmos para geração usando o padrão IBM 3624 são mostrados nos diagramas abaixo.
Algoritmo de Geração de PIN IBM 3624
Para permitir que o usuário (cardholder) selecione o próprio PIN, um PIN offset é usado no método IBM 3624, com isso duas novas entradas são necessárias, o PIN definido pelo usuário e um check de tamanho de 4 bits. A operação com offset é realizada após os passos do algoritmo IBM 3624, mostrado acima. Com isso o processo interno do HSM consegue realizar a validação do PIN, mesmo que o usuário defina um PIN diferente daquele gerado inicialmente pelo HSM.
Algoritmo de Geração de PIN IBM 3624 com offset
As operações de tradução de PIN Block (PIN Block Translate) funcionam com duas chaves, uma de origem e uma de destino; há uma fase intermediária para compatibilizar o formato de entrada ao formato de saída, caso seja possível. Há certos formatos de blocos que não são interoperáveis, ou por ausência de dados para a conversão ou por restrição da norma.
O modo de tradução default do HSM implica na tradução do bloco de entrada para o formato ISO PIN Block Format 0. No modo de tradução automático, a conversão é realizada de forma opaca, convertendo do bloco com a chave de origem para o bloco com a chave de destino, sem análise do formato ou conteúdo do bloco.
Operação de PIN Translate
Na verificação de um PIN Block ocorrem duas operações com chaves, primeiro o PIN Block é decifrado com a chave PTK (PIN Transport Key), do bloco do PIN decifrado, é extraído o PIN, e a partir daí é realizada a verificação de PIN usando a PGK (PIN Generation Key, a mesma chave utilizada para a geração original do PIN). Esta verificação pode ser feita com ou sem o uso de um offset; este PIN offset não faz parte do PIN Block e não é criptografado pela PTK. O formato de PIN Block esperado é o ISO PIN Block Format 0 (equivalente ao ANSI PIN Block Format 0 e ao VISA PIN Block Format 1).
Operação de verificação de PIN Block

Mecanismos de DUKPT

DUKPT (Derived Unique Key Per Transaction) é uma forma de utilizar chaves únicas por transação, derivadas a partir de uma chave fixa, sendo este processo definido na ANSI X9.24 part 1.
A KSN (Key Serial Number) é o identificador de uma chave de transação, sendo dividida em partes como: KSI (Key Set ID), TRSM (Tamper Resistant Security Module), identificador do POS (Point of Sale) também conhecido como DID (Device ID) e o CTR (Transaction Counter).
Geração chaves DUKPT
O HSM utiliza as partes da KSN separadas em KSI e DID + CTR cada uma contendo 5 bytes.
Os passos do processo de utilização de DUKPT são, em cada ponta da comunicação:
No POS:
    1.
    Previamente inicializado com uma IPEK derivada de uma BDK.
    2.
    Gera (ou recupera de uma tabela de chaves futuras) a chave futura utilizando o DID e CTR.
    3.
    Encripta o bloco necessário (Ex.: PIN Block).
    4.
    Envia KSN + Bloco encriptado. KSN é composto de TRMS (ou DID), KSI e CTR.
    5.
    Incrementa o CTR interno.
No HSM:
    1.
    Recebe KSN + Bloco Encriptado.
    2.
    Seleciona a BDK apropriada baseado na KSN recebida. KSN é composto de TRMS (ou DID), KSI e CTR.
    3.
    Gera a IPEK baseado no BDK e KSN selecionados.
    4.
    Utiliza a IPEK, o DID e o CTR contidos no KSN para gerar a chave de sessão.
    5.
    Decripta o Bloco e faz o processamento necessário.
    6.
    O POS tem uma chave IPEK (Initial Pin Encryption Key) derivada de uma BDK (Base Derivation Key). Esta BDK está armazenada dentro do HSM e é utilizada na regeração da IPEK do respectivo POS e então esta IPEK é utilizada na derivação das chaves únicas de transação deste POS.
Comunicação DUKPT entre o POS/ATM e o HSM

Definições

    KSN: Key Serial Number
    KSI: Key Set ID
    TRSM: Tamper Resistant Security Module
    POS: Point of Sale
    CTR: Transaction Counter
    DID: Device ID
    BDK: Base Derivation Key
    IPEK: Initial Pin Encryption Key
    ATM: Automatic Teller Machine
Last modified 15h ago
Copy link