EFT

The APIs of the EFT(Electronic Funds Transfer) module are intended for user authentication and identity verification operations in Visa and Mastercard transactions.

The identity of the card user can usually be verified in two ways:

handwritten signature, compared to a signature card held by the card issuer;
via a PIN(Personal Identification Number) entered by the user; PIN verification can be done online, with validation by the card issuer, or offline, using a chip card.

The standards adopted are in accordance with Visa'sPayment Technology Standards Manual (October 2007).

In general terms, the process of transferring funds by card follows the flow in the figure below. There are several actors involved in the process. The Cardholder (card holder) presents thecard to the shopkeeper(Retailer/Merchant), the authenticity of Cardholder can be verified by means of a PIN, which Cardholder enters at the shopkeeper's station (e.g. a POS terminal, Point of Sale). The PIN is then encrypted (a PIN Block is generated) and the transaction data is sent to an electronic payment service provider contracted by the shopkeeper (Acquirer), which then sends the data to the corresponding card scheme, according to the brand of card used by Cardholder, and from there it is sent to the card issuer, which has the identification, credit and other data about Cardholder and maintains a contract with it to use the service. After analyzing the transaction data, in terms of registration, credit and authentication, among others, the issuer can authorize or refuse the transaction, and this response message travels in the opposite direction.

---
title: Processo genérico de transferência eletrônica de fundos
---

sequenceDiagram
    autonumber
    actor Portador
    participant Loja
    participant Rede
    participant Bandeira
    participant Banco

    Portador ->> Loja: Cartão/PIN/CVV
    activate Loja
    Loja ->> Rede: Dados<br>Transação
    deactivate Loja
    activate Rede
    Rede ->> Bandeira: Dados<br>Transação
    deactivate Rede
    activate Bandeira
    Bandeira ->> Banco: Dados<br>Transação
    deactivate Bandeira
    activate Banco
    Banco ->> Bandeira: $
    deactivate Banco
    activate Bandeira
    Bandeira ->> Rede: $
    deactivate Bandeira
    activate Rede
    Rede ->> Loja: $
    deactivate Rede
    activate Loja
    Loja ->> Portador: Mercadorias/<br>Serviços
    deactivate Loja
    Banco -->> Portador: Débito
    Portador -->> Banco: $

From the point of view of the encryption keys used in the process, the process is shown in the figure below. Each actor keeps their own keys, and whenever an encrypted message needs to go from one actor to another, the encryption must be translated, i.e. the corresponding key of the actor who is to decrypt the message must be used.

---
title: Chaves criptográficas na transferência de fundos
---
%%{init: {'sequence': { 'mirrorActors': false}}}%%

sequenceDiagram
    actor Portador
    participant Loja
    participant Rede
    participant Bandeira
    participant Banco

    destroy Portador
    Portador ->> Loja: Cartão/PIN/CVV
    destroy Loja
    Loja ->> Rede: PIN Block
    Note over Rede: HSM:<br>PIN Translation
    Note over Rede: ZCMK<br>AWK<br>...
    destroy Rede
    Rede ->> Bandeira: PIN Block
    Note over Bandeira: HSM:<br>PIN Translation
    Note over Bandeira: ZCMK<br>AWK<br>IWK<br>...
    destroy Bandeira
    Bandeira ->> Banco: PIN Block
    activate Banco
    Note over Banco: HSM:<br>PIN Block Verification<br>CVV Verification
    Note over Banco: ZCMK<br>IWK<br>CVK<br>PVK<br>...
    deactivate Banco

Variations or simplifications of the above scheme can be used, for example when the same entity has more than one role, or there is direct communication from theacquirer to theissuer, as can happen in certain debit transactions.

Info

Each cryptographic key must be dedicated to only one application, as determined by the Visa manual.
The sizes entered for the parameters refer to the data; the application must ensure that the buffer passed has enough space for the data plus the terminator character.
The module EFT works with a PIN size of 4 (MIN_EFT_PIN_LEN) a 12 (MAX_EFT_PIN_LEN) digits.

About support for 3-D Secure protocol algorithms:

HSM Dinamo implements the cryptographic algorithms that support the 3-D Secure protocol, developed by Visa. Visa's Verified by Visa and Mastercard's Secure Code services are offered by the brands based on this protocol. The HSM implements the cryptographic card verification algorithms that support the protocol and the services, allowing the HSM user to generate and verify the codes, CVC2 (Card Verification Code 2) and HMAC SHA1 in the case of Mastercard(Secure Payment Application Algorithm) and CAVV(Cardholder Authentication Verification Value, CVV2 with ATN method) in the case of Visa.

HSM supports CAP (Visa) and DPA (Mastercard) authentication mechanisms.

The HSM provides support for ATM Remote Key Loading/Transport through cryptographic functionalities based on RSA and X.509 functions.

The HSM implementation complies with the standards defined in the documentation listed below:

EMVCo

Integrated Circuit Card Specifications for Payment Systems, Book 2, Security and Key Management v. 4.2, June 2008
EMV Card Personalization Specification, v. 1.1, July 2007

Visa

Payment Technology Standards Manual, October 2007
Visa Certification Authority Public Keys for Visa Smart Debit/Credit (VSDC), February 2007
Visa Smart Debit/Credit Certification Authority Technical Requirements v. 2.1, April 2006
3-D Secure Functional Requirements Access Control Server v. 1.0.2, May 2006
Visa Integrated Circuit Card v. 1.4.0, October 2001

Mastercard

M/Chip Lite 2.1 Card Application Specifications for Debit and Credit, April 2003
M/Chip 4 Version 1.1 Issuer Guide to Debit and Credit Parameter Management, January 2007
M/Chip 4 Version 1.1 Security & Key Management, June 2006
Public Key Infrastructure (PKI) - Certification Authority Interface Specification, January 2005
Public Key Infrastructure (PKI) - Certification Authority Member Procedures, January 2006
SPA Algorithm for the MasterCard Implementation of 3-D Secure v1.04, May 2004

Link

ELO Chip Card, CCD Cryptographic Algorithms, no version, no date.
Elo Certificate Authority Manual - Issuer's Guide, version 1.2, September 2011

JCB

JCB IC Card Specification, v. 2.0, October 2012
JCB CA Interface Guide, unversioned, January 2014
JCB Key Guide, unversioned, January 2014

Others

ANSI X9.24 part 1, Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques
ASC X9 TR 31-2018, Interoperable Secure Key Exchange Key Block Specification, April 15, 2018
ASC X9 TR 34-2019, Interoperable Method for Distribution of Symmetric Keys using Asymmetric Techniques: Part 1 - Using Factoring-Based Public Key Cryptography Unilateral Key Transport, September 22, 2019
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)

Mechanisms of CVV

There are three ways of generating and verifying CVV(Card Verification Value) in HSM: 1. Card Verification Value (CVV), for transactions with magnetic stripe cards; 2. Card Verification Value 2 (CVV 2), for transactions without the physical presence of the card (via telephone, post or Internet, for example); 3. Alternate Card Verification Value (iCVV), for transactions with chip cards; The calculation mechanism is the same in all three forms, and the difference lies in the way the data is entered by the application.

The key used for CVV generation and verification calculations is called CVK(Card Verification Key). This key is internal to the HSM; the application only needs to enter its key name (id). Physically, it is a 112-bit 3DES key, which corresponds to two 56-bit DES keys.

The figure below illustrates the diagrams for generating and verifying CVV, iCVV and CVV2.

---
title: Geração de CVV / iCVV / CVV2
---

%%{ init: { 'flowchart': { 'curve': 'basis' } } }%%
flowchart TB
    PAN[PAN]
    Service[Código de serviço / 99/ 000]
    Data[Data de expiração]
    CVKid[CVK id]
    H[\"HSM: CVK (3DES 112)"/]
    cvv((CVV))
    icvv((iCVV))
    cvv2((CVV2))

    PAN --> H
    Service --> H
    Data --> H
    CVKid --> H
    H --> cvv
    H --> icvv
    H --> cvv2

PIN mechanisms

HSM works by generating PINs (Personal Identification Numbers) using a derivation mechanism, based on an internal key called PGK(PIN Generation Key). This form of generation has several advantages, especially compared to the method of generating PINs with random values, as it does not require the use of a database for validation (with the probable exposure of sensitive data) and also keeps both the generation and validation processes more secure, as they are carried out internally to the HSM.

The standard used to generate the PIN by the HSM is IBM 3624, using offsets to allow the PIN to be changed by the user or the card issuer. To mitigate decimalization and verification attacks, the HSM uses an internal conversion table, which is not exposed to the application. As an additional security factor, a 168-bit 3DES key is used instead of a 112-bit 3DES key; there is no interference in the operation of the algorithm, since the DES and 3DES keys use input and output blocks of the same size.

---
title: Geração de PIN por derivação
---

%%{ init: { 'flowchart': { 'curve': 'basis' } } }%%
flowchart TB
    PAN[PAN]
    InPIN[InPIN]
    Offset[offset]
    PGKid[PGK id]
    H[\"HSM: CVK (3DES 112)"/]
    r((PIN))

    PAN --> H
    InPIN --> H
    Offset --> H
    PGKid --> H
    H --> r

There are three ways of generating PINs by derivation: 1. from the PAN(Personal Account Number), the input PIN (inPIN) and the PGK; 2. from an input PIN and the PGK, with the use of an offset allowing the user to change the PIN; 3. from the PAN, the PGK and an input PIN, with the use of an offset allows automatic PIN change;

There is no business rule handling for PINs generated within the HSM; this function must be performed by the calling application.

The algorithms for generation using the IBM 3624 standard are shown in the diagrams below.

---
title: Algoritmo de Geração de PIN IBM 3624
---

%%{ init: { 'flowchart': { 'curve': 'basis' } } }%%
flowchart TD
    Dado{{Dado de Validação}}
    PGK{{PGK}}
    Op3DES[\Operação 3DES/]
    Troca[Troca de dígito]
    Ajuste[Ajuste de tamanho]
    Pin((PIN))

    Dado --> Op3DES
    PGK --> Op3DES
    Op3DES -- Tabela de decimalização interna --> Troca
    Troca -- PIN Intermediário --> Ajuste
    Ajuste --> Pin

To allow the user(cardholder) to select their own PIN, a PIN offset is used in the IBM 3624 method, so that two new entries are required, the PIN set by the user and a check of 4 bits. The offset operation is performed after the steps of the IBM 3624 algorithm shown above. This enables the HSM 's internal process to validate the PIN, even if the user defines a different PIN to the one initially generated by the HSM.

---
title: Algoritmo de Geração de PIN IBM 3624 com offset
---

%%{ init: { 'flowchart': { 'curve': 'basis' } } }%%
flowchart TD
    Dado{{Dado de Validação}}
    PGK{{PGK}}
    Op3DES[\Operação 3DES/]
    Troca[Troca de dígito]
    Ajuste[Ajuste de tamanho]
    Sub[\"Subtração em módulo 10<br>(InPin -PIN)"/]
    OpOff[\Operação de offset no PIN/]
    Pin((PIN))

    InPin{{"InPin<br>(PIN gerado pelo usuário)"}}
    Of{{"dado de offset<br>(4-bit)"}}

    Dado --> Op3DES
    PGK --> Op3DES
    Op3DES -- Tabela de decimalização interna --> Troca
    Troca -- PIN Intermediário --> Ajuste
    Ajuste --> Sub
    Sub --> OpOff
    OpOff --> Pin

    InPin --> Sub
    Of --> OpOff

PIN BlockTranslate operations work with two keys, one source and one destination; there is an intermediate phase to make the input format compatible with the output format, if possible. There are certain block formats that are not interoperable, either because there is no data for conversion or because the standard is restricted.

HSM 's default translation mode involves translating the input block into ISO PIN Block Format 0. In automatic translation mode, the conversion is performed opaquely, converting from the block with the source key to the block with the target key, without analyzing the format or content of the block.

---
title: Operação de PIN Translate
---

%%{ init: { 'flowchart': { 'curve': 'basis' } } }%%
flowchart TD
    blockin{{Bloco de entrada}}
    keyin{{Chave de entrada}}
    OpDES1[\DES/]
    Prep[Preparação]
    OpDES2[\DES/]
    keyout{{Chave de destino}}
    blockout{{Bloco da saída}}

    blockin --> OpDES1
    keyin --> OpDES1
    OpDES1 --> Prep
    Prep --> OpDES2
    keyout --> OpDES2
    OpDES2 --> blockout

When verifying a PIN Block, two key operations take place: first the PIN Block is decrypted using the PTK(PIN Transport Key), the PIN is extracted from the decrypted PIN Block, and then the PIN is verified using the PGK(PIN Generation Key, the same key used to generate the original PIN). This verification can be done with or without the use of an offset; this PIN offset is not part of the PIN Block and is not encrypted by the PTK. The expected PIN Block format is ISO PIN Block Format 0 (equivalent to ANSI PIN Block Format 0 and VISA PIN Block Format 1).

---
title: Operação de Verificação de PIN Block
---

%%{ init: { 'flowchart': { 'curve': 'basis' } } }%%
flowchart TD
    pinblock{{PIN Block}}
    ptk{{PTK}}
    OpDES1[\DES/]
    Prep["PIN, PAN, ..."]
    pin[PIN]
    pgk{{PGK}}
    off{{offset}}
    OpDES2[\3DES/]
    r((Result))

    ptk --> OpDES1
    pinblock --> OpDES1
    OpDES1 --> Prep
    Prep --> pin
    pin --> OpDES2
    pgk --> OpDES2
    off --> OpDES2
    OpDES2 --> r

Mechanisms of DUKPT

DUKPT(Derived Unique Key Per Transaction) is a way of using unique keys per transaction, derived from a fixed key. This process is defined in ANSI X9.24 part 1.

The KSN(Key Serial Number) is the identifier of a transaction key and is divided into parts such as: KSI(Key Set ID), TRSM(Tamper Resistant Security Module), POS (Point of Sale) identifier also known as DID (Device ID) and the CTR(Transaction Counter).

---
title: Geração chaves DUKPT
---

sequenceDiagram
    participant hsm as HSM
    participant pos as PoS/ATM<br>Device

    Note over hsm: BDK
    activate hsm
    hsm ->> hsm: IPEK (Device Id)
    deactivate hsm
    hsm ->> pos: IPEK
    Note over pos: IPEK

HSM uses the parts of KSN separated into KSI and DID + CTR each containing 5 bytes.

The steps in the process of using DUKPT are, at each end of the communication:

At the POS:

Previously initialized with an IPEK derived from a BDK.
Generates (or retrieves from a table of future keys) the future key using the DID and CTR.
Encrypts the required block (e.g. PIN Block).
Sends KSN + encrypted block. KSN is made up of TRMS (or DID), KSI and CTR.
Increases internal CTR.

At HSM:

Receives KSN + Encrypted Block.
Selects the appropriate BDK based on the KSN received. KSN is made up of TRMS (or DID), KSI and CTR.
Generates the IPEK based on the selected BDK and KSN.
It uses the IPEK, DID and CTR contained in the KSN to generate the session key.
Decrypts the Block and does the necessary processing.
The POS has an IPEK(Initial Pin Encryption Key) derived from a BDK(Base Derivation Key). This BDK is stored within the HSM and is used in the regeneration of the IPEK of the respective POS and then this IPEK is used in the derivation of the unique transaction keys of this POS.

---
title: Comunicação DUKPT entre o POS/ATM e o HSM
---

sequenceDiagram
    participant pos as PoS/ATM<br>Device
    participant hsm as HSM

    Note over pos: IPEK
    activate pos
    pos ->> pos: KSI,CTR
    pos ->> pos: Chave de sessão
    pos ->> pos: Texto claro > bloco cifrado
    deactivate pos
    pos ->> hsm: bloco cifrado<br>TRSM (Device Id)<br>KSI<br>CTR
    activate hsm
    Note over hsm: BDK
    hsm ->> hsm: IPEK (Device Id)
    hsm ->> hsm: KSI,CTR
    hsm ->> hsm: Chave de sessão
    hsm ->> hsm: bloco cifrado > texto claro

    deactivate hsm

Key-wrapping TR-31

It is a wrapping/unwrapping process with confidentiality and integrity protection for keys and associated data, defined in the ASC X9 TR 31-2018 document.

KBPK(Key Block Protection Key) is the derivation key used to derive the encryption and authentication keys. This key is only used for derivation. Also known as KWK (Key Wrapping Key). Stored in the HSM.

KBEK(Key Block Encryption Key) is the key derived from KBPK and used only for key klock encryption. It is generated with each wrap/unwrap operation and is not stored persistently in the HSM.

KBAK(Key Block Authentication Key) is the key derived from KBPK and used only for calculating the MAC of the key klock. It is generated with each wrap/unwrap operation and is not stored persistently in the HSM.

KDID(Key Derivation Input Data) is the data used to derive the KBEK and KBAK keys. It contains data such as: counter, key usage indicator, algorithm indicator and size. It varies according to the derivation method used, the key to be derived and other parameters.

The derivation of the KBEK and KBAK keys uses CMAC with the Key Derivation Input Data (specific to each derived key) and the KBPK key as input.

---
title: Processo de derivação KBEK e KBAK
---

%%{ init: { 'flowchart': { 'curve': 'basis' } } }%%
flowchart TD

    kbekin("Key derivation<br>input data<br>KBEK")
    kbakin("Key derivation<br>input data<br>KBAK")
    cmac1([CMAC])
    kbpk(KBPK)
    cmac2([CMAC])
    kbek("Key Block<br>Encryption Key")
    kbak("Key Block<br>Authentication Key")

    kbekin --> cmac1
    kbakin --> cmac2
    cmac1 --> kbek
    cmac2 --> kbpk
    cmac2 --> kbak
    cmac1 --> kbpk

Key block contains the data of the exported key. This block is divided into 3 parts:

KBH(Key Block Header) contains information about the key and the key block.
The confidential data that will be sent/saved. It is encrypted with the KBEK key. The input data for encryption is: the key size, the key and the padding.
The MAC that connects the KBH and the encrypted key block. It is generated using the KBAK key. The input data for the MAC operation is: the KBH, and the input data for encryption.

%%{init: { 'theme': 'dark' } }%%
timeline
    title Processo de Geração do Key Block

    section KBH
    section Bloco Cifrado<br>KBEK
        Input : tamanho da chave : chave : padding
    section MAC<br>KBAK
        Input : KBH : tamanho da chave : chave : padding

Definitions

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
KBPK: Key Block Protection Key
KBEK: Key Block Encryption Key
KBAK: Key Block Authentication Key
AESKW: AES Key Wrap
TDKW: Tripple DES Key Wrap
KWK: Key Wrapping Key
KBH: Key Block Header

API EFT

Specific API documentation for the EFT module, with functions, classes and examples.

C/C++

API C/C++
Java

Java API
.NET

NET API