EFT

Las API del módulo EFT(Electronic Funds Transfer) están destinadas a las operaciones de autenticación de usuarios y verificación de identidad en las transacciones de Visa y Mastercard.

Por lo general, la identidad del usuario de la tarjeta puede verificarse de dos maneras:

firma manuscrita, en comparación con una tarjeta de firma en poder del emisor de la tarjeta;
mediante un PIN(número de identificación personal) introducido por el usuario; La verificación del PIN puede hacerse en línea, con validación del emisor de la tarjeta, o fuera de línea, utilizando una tarjeta con chip.

Las normas adoptadas se ajustan alManual de Normas de Tecnología de Pagos de Visa(octubre de 2007).

En términos generales, el proceso de transferencia de fondos con tarjeta sigue el flujo de la figura siguiente. En el proceso intervienen varios actores. Eltitular de la tarjeta la presenta al minorista(minorista/comerciante), la autenticidad del titular de la tarjeta puede verificarse mediante un PIN, que el titular introduce en la estación del minorista (por ejemplo, un terminal de punto de venta). A partir de ahí, el PIN se encripta (se genera un Bloque PIN) y los datos de la transacción se envían a un proveedor de servicios de pago electrónico contratado por el comerciante (Adquirente), que a su vez envía los datos a la correspondiente red de tarjetas, según la marca de tarjeta utilizada por el titular, y de ahí se envían al emisor de la tarjeta, que dispone de los datos de identificación, crédito y otros sobre el titular y mantiene un contrato con el titular para el uso del servicio. Tras analizar los datos de la transacción, en términos de registro, crédito y autenticación, entre otros, el emisor puede autorizar o rechazar la transacción, y este mensaje de respuesta viaja en sentido contrario.

---
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: $

Desde el punto de vista de las claves de cifrado utilizadas en el proceso, éste se muestra en la figura siguiente. Cada actor conserva sus propias claves, y cada vez que un mensaje cifrado debe pasar de un actor a otro, el cifrado debe traducirse, es decir, debe utilizarse la clave correspondiente del actor que debe descifrar el mensaje.

---
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

Pueden utilizarse variaciones o simplificaciones del esquema anterior, por ejemplo, cuando una misma entidad desempeña más de una función, o existe una comunicación directa deladquirente con elemisor, como puede ocurrir en determinadas operaciones de débito.

Información

Cada clave criptográfica debe dedicarse a una sola aplicación, según determine el manual de Visa.
Los tamaños introducidos para los parámetros se refieren a los datos; la aplicación debe asegurarse de que el búfer pasado tiene espacio suficiente para los datos más el carácter terminador.
El módulo EFT funciona con un tamaño de PIN de 4 (MIN_EFT_PIN_LEN) a 12 (MAX_EFT_PIN_LEN) dígitos.

Acerca de la compatibilidad con los algoritmos del protocolo 3-D Secure:

Dinamo H SM implementa los algoritmos criptográficos que soportan el protocolo 3-D Secure, desarrollado por Visa. Los servicios Verified by Visa de Visa y Secure Code de Mastercard son ofrecidos por las marcas basadas en este protocolo. ElHSM implementa los algoritmos criptográficos de verificación de tarjetas que soportan el protocolo y los servicios, permitiendo al usuario del HSM generar y verificar los códigos, CVC2 (Card Verification Code 2) y HMAC SHA1 en el caso de Mastercard(Secure Payment Application Algorithm) y CAVV(Cardholder Authentication Verification Value, CVV2 con método ATN) en el caso de Visa.

El HSM es compatible con los mecanismos de autenticación CAP (Visa) y DPA (Mastercard).

El HSM ofrece soporte para la carga/transporte remoto de claves ATM mediante funcionalidades criptográficas basadas en funciones RSA y X.509.

La aplicación del HSM cumple las normas definidas en la documentación que se indica a continuación:

EMVCo

Especificaciones de tarjetas de circuito integrado para sistemas de pago, Libro 2, Seguridad y gestión de claves v. 4.2, junio de 2008
Especificación de personalización de tarjetas EMV, v. 1.1, julio de 2007

Visa

Manual de normas sobre tecnologías de pago, octubre de 2007
Claves públicas de la Autoridad de Certificación de Visa para Visa Smart Debit/Credit (VSDC), febrero de 2007
Requisitos técnicos de la Autoridad de Certificación de Visa Smart Debit/Credit v. 2.1, abril de 2006
Requisitos funcionales de 3-D Secure Servidor de control de acceso v. 1.0.2, mayo de 2006
Tarjeta de circuito integrado Visa v. 1.4.0, octubre de 2001

Mastercard

Especificaciones de la aplicación de tarjetas M/Chip Lite 2.1 para débito y crédito, abril de 2003
M/Chip 4 Versión 1.1 Guía del emisor para la gestión de parámetros de débito y crédito, enero de 2007
M/Chip 4 Versión 1.1 Seguridad y gestión de claves, junio de 2006
Infraestructura de clave pública (PKI) - Especificación de interfaz de autoridad de certificación, enero de 2005
Infraestructura de clave pública (PKI) - Procedimientos para los miembros de la autoridad de certificación, enero de 2006
Algoritmo SPA para la implementación de MasterCard de 3-D Secure v1.04, mayo de 2004

Enlace

Tarjeta chip ELO, algoritmos criptográficos CCD, sin versión, sin fecha.
Elo Certificate Authority Manual - Issuer's Guide, versión 1.2, septiembre de 2011

JCB

JCB IC Card Specification, v. 2.0, octubre de 2012
Guía de interfaz JCB CA, sin versionar, enero de 2014.
Guía de claves JCB, sin versionar, enero de 2014

Otros

ANSI X9.24 parte 1, Servicios financieros minoristas Gestión de claves simétricas Parte 1: Utilización de técnicas simétricas
ASC X9 TR 31-2018, Interoperable Secure Key Exchange Key Block Specification, 15 de abril de 2018.
ASC X9 TR 34-2019, Método interoperable para la distribución de claves simétricas utilizando técnicas asimétricas: Parte 1 - Uso de criptografía de clave pública basada en factorización Transporte unilateral de claves, 22 de septiembre de 2019.
IBM z/OS V1R9.0 Guía del programador de aplicaciones de servicios criptográficos ICSF (3624 Formatos y algoritmos PIN)
ISO/IEC 9797-1 Método 2, Tecnología de la información - Técnicas de seguridad - Códigos de autenticación de mensajes (MAC) - Parte 1, 1999
IDTECH MANUAL DEL USUARIO Lector SecureMag Encrypted MagStripe (80096504-001 RevL 19/06/14)

Mecanismos CVV

Existen tres formas de generar y verificar el CVV(Card Verification Value) en HSM: 1. Card Verification Value (CVV), para transacciones con tarjetas de banda magnética; 2. Card Verification Value 2 (CVV 2), para transacciones sin presencia física de la tarjeta (por teléfono, correo o Internet, por ejemplo); 3. Valor alternativo de verificación de la tarjeta (iCVV), para transacciones con tarjetas con chip; El mecanismo de cálculo es el mismo en las tres formas, y la diferencia radica en la forma en que la aplicación introduce los datos.

La clave utilizada para la generación del CVV y los cálculos de verificación se denomina CVK(Card Verification Key). Esta clave es interna al HSM, la aplicación sólo tiene que introducir su nombre de clave (id). Físicamente, es una clave 3DES de 112 bits, que corresponde a dos claves DES de 56 bits.

La figura siguiente ilustra los diagramas de generación y comprobación de CVV, iCVV y 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

Mecanismos PIN

El HSM funciona generando PINs (Números de Identificación Personal) mediante un mecanismo de derivación, basado en una clave interna denominada PGK(Clave de Generación de PIN). Esta forma de generación presenta varias ventajas, especialmente en comparación con el método de generación de PINs con valores aleatorios, ya que no requiere el uso de una base de datos para su validación (con la probable exposición de datos sensibles) y además mantiene tanto el proceso de generación como el de validación más seguros, al realizarse internamente al HSM.

El estándar utilizado para generar el PIN por el HSM es el IBM 3624, que utiliza compensaciones para que el PIN pueda ser modificado por el usuario o el emisor de la tarjeta. Para mitigar los ataques de decimalización y verificación, el HSM utiliza una tabla de conversión interna que no se expone a la aplicación. Como factor de seguridad adicional, se utiliza una clave 3DES de 168 bits en lugar de una clave 3DES de 112 bits; no hay interferencias en el funcionamiento del algoritmo, ya que las claves DES y 3DES utilizan bloques de entrada y salida del mismo tamaño.

---
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

Existen tres formas de generar PINs por derivación: 1. a partir del PAN(Personal Account Number), el PIN de entrada (inPIN) y el PGK; 2. a partir de un PIN de entrada y el PGK, con el uso de un offset que permite al usuario cambiar el PIN; 3. a partir del PAN, el PGK y un PIN de entrada, con el uso de un offset que permite el cambio automático del PIN;

No hay gestión de reglas de negocio para PINs generados dentro del HSM; esta función debe ser llevada a cabo por la aplicación llamante.

Los algoritmos de generación mediante el estándar IBM 3624 se muestran en los siguientes diagramas.

---
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

Para que el usuario(titular de la tarjeta) pueda seleccionar su propio PIN, en el método IBM 3624 se utiliza un desplazamiento del PIN, de modo que se requieren dos nuevas entradas, el PIN definido por el usuario y un tamaño de comprobación de 4 bits. La operación de desplazamiento se realiza después de los pasos del algoritmo IBM 3624 mostrados anteriormente. Esto permite que el proceso interno del HSM valide el PIN, aunque el usuario defina un PIN distinto al generado inicialmente por el 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

Las operaciones PIN BlockTranslate funcionan con dos claves, una de origen y otra de destino; existe una fase intermedia para compatibilizar, si es posible, el formato de entrada con el de salida. Hay determinados formatos de bloque que no son interoperables, ya sea porque no hay datos para la conversión o por una restricción de la norma.

El modo de traducción por defecto del HSM consiste en traducir el bloque de entrada al formato ISO PIN Block Format 0. En el modo de traducción automática, la conversión se realiza de forma opaca, convirtiendo del bloque con la clave de origen al bloque con la clave de destino, sin analizar el formato ni el contenido del bloque.

---
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

Cuando se verifica un Bloque PIN, tienen lugar dos operaciones clave: primero se descifra el Bloque PIN con la PTK(Clave de Transporte PIN), se extrae el PIN del Bloque PIN descifrado, y luego se verifica el PIN utilizando la PGK(Clave de Generación PIN, la misma clave utilizada para generar el PIN original). Esta verificación puede realizarse con o sin el uso de un desplazamiento; este desplazamiento del PIN no forma parte del Bloque PIN y no está cifrado por la PTK. El formato de bloque de PIN esperado es el formato de bloque de PIN ISO 0 (equivalente al formato de bloque de PIN ANSI 0 y al formato de bloque de PIN VISA 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

Mecanismos de DUKPT

DUKPT(Derived Unique Key Per Transaction) es una forma de utilizar claves únicas por transacción, derivadas de una clave fija, y este proceso se define en ANSI X9.24 parte 1.

El KSN(Key Serial Number) es el identificador de una clave de transacción y se divide en partes como: KSI(Key Set ID), TRSM(Tamper Resistant Security Module), POS(Point of Sale) identificador también conocido como DID(Device ID) y el 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 utiliza las partes de KSN separadas en KSI y DID + CTR, cada una de las cuales contiene 5 bytes.

Las etapas del proceso de utilización de DUKPT son, en cada extremo de la comunicación:

En el punto de venta:

Inicializado previamente con un IPEK derivado de un BDK.
Genera (o recupera de una tabla de claves futuras) la clave futura utilizando el DID y el CTR.
Cifra el bloque requerido (por ejemplo, el bloque PIN).
Envía KSN + bloque cifrado. KSN se compone de TRMS (o DID), KSI y CTR.
Aumenta el CTR interno.

En HSM:

Recibe KSN + bloque cifrado.
Selecciona la BDK adecuada en función del KSN recibido. El KSN se compone de TRMS (o DID), KSI y CTR.
Genera el IPEK basándose en el BDK y el KSN seleccionados.
Utiliza el IPEK, el DID y el CTR contenidos en el KSN para generar la clave de sesión.
Descifra el bloque y realiza el procesamiento necesario.
El TPV tiene una IPEK(Clave Inicial de Cifrado de Clavijas) derivada de una BDK(Clave Base de Derivación). Esta BDK se almacena dentro del HSM y se utiliza en la regeneración de la IPEK del TPV correspondiente y, a continuación, esta IPEK se utiliza en la derivación de las claves de transacción únicas de este TPV.

---
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

Envoltura de llaves TR-31

Se trata de un proceso de envoltura/desenvoltura con protección de la confidencialidad y la integridad de las claves y los datos asociados, definido en el documento ASC X9 TR 31-2018.

KBPK(Key Block Protection Key) es la clave de derivación utilizada para derivar las claves de cifrado y autenticación. Esta clave sólo se utiliza para la derivación. También se conoce como KWK (Key Wrapping Key). Se almacena en el HSM.

KBEK(Key Block Encryption Key) es la clave derivada de KBPK y utilizada únicamente para el cifrado de bloques de claves. Se genera con cada operación de envoltura/desenvoltura y no se almacena de forma persistente en el HSM.

KBAK(Key Block Authentication Key) es la clave derivada de KBPK y utilizada únicamente para calcular la MAC de la clave klock. Se genera con cada operación de envoltura/desenvoltura y no se almacena de forma persistente en el HSM.

KDID(Key Derivation Input Data) son los datos utilizados para derivar las claves KBEK y KBAK. Contiene datos como: contador, indicador de uso de clave, indicador de algoritmo y tamaño. Varía en función del método de derivación utilizado, la clave que debe derivarse y otros parámetros.

La derivación de las claves KBEK y KBAK utiliza CMAC con los datos de entrada de derivación de claves (específicos de cada clave derivada) y la clave KBPK como entrada.

---
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

El bloque Clave contiene los datos de la clave exportada. Este bloque se divide en 3 partes:

KBH(Key Block Header) contiene información sobre la clave y el bloque de claves.
Los datos confidenciales que se enviarán/guardarán. Se cifra con la clave KBEK. Los datos de entrada para el cifrado son: el tamaño de la clave, la clave y el relleno.
La MAC que conecta el KBH y el bloque de claves cifrado. Se genera utilizando la clave KBAK. Los datos de entrada para la operación MAC son: el KBH, y los datos de entrada para el cifrado.

%%{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

Definiciones

KSN: Número de serie de la llave
KSI: ID del conjunto de claves
TRSM: Módulo de seguridad a prueba de manipulaciones
TPV: Punto de venta
CTR: Contador de transacciones
DID: ID del dispositivo
BDK: Clave de derivación base
IPEK: Clave inicial de cifrado de pines
Cajero automático
KBPK: Clave de protección del bloque de claves
KBEK: Clave de cifrado de bloque de claves
KBAK: Clave de autenticación de bloque de claves
AESKW: Envoltura de claves AES
TDKW: Envoltura triple de claves DES
KWK: Llave envolvente
KBH: Encabezado de bloque de claves

API EFT

Documentación específica de la API para el módulo EFT, con funciones, clases y ejemplos.

C/C++

API C/C++
Java

API Java
.NET

NET API