Verificar el criptograma de solicitud de autenticación (ARQC) - AWS Criptografía de pagos
Creación de datos de transacciones Relleno de datos de transacciones Ejemplos

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Verificar el criptograma de solicitud de autenticación (ARQC)

La API de verificación del criptograma de solicitud de autenticación se utiliza para verificar el ARQC. La generación del ARQC está fuera del alcance de la criptografía de AWS pagos y, por lo general, se realiza en una tarjeta con chip EMV (o un equivalente digital, como una billetera móvil) durante el tiempo de autorización de la transacción. Un ARQC es único para cada transacción y su objetivo es mostrar criptográficamente la validez de la tarjeta y garantizar que los datos de la transacción coincidan exactamente con los de la transacción actual (esperada).

AWS La criptografía de pagos ofrece una variedad de opciones para validar el ARQC y generar valores ARPC opcionales, incluidos los definidos en la EMV 4.4, libro 2, y otros esquemas utilizados por Visa y Mastercard. Para obtener una lista completa de todas las opciones disponibles, consulte la sección de la VerifyCardValidationData Guía de API.

Los criptogramas ARQC suelen requerir las siguientes entradas (aunque esto puede variar según la implementación):

  • PAN: especificado en el campo PrimaryAccountNumber

  • Número de secuencia PAN (PSN): especificado en el campo PanSequenceNumber

  • Método de derivación de claves, como la clave de sesión común (CSK), especificado en el SessionKeyDerivationAttributes

  • Modo de derivación de clave maestra (como la opción A de EMV): especificado en el MajorKeyDerivationMode

  • Datos de la transacción: una cadena de varios datos de transacciones, terminales y tarjetas, como el importe y la fecha, especificados en el campo TransactionData

  • Clave maestra del emisor: la clave maestra utilizada para derivar la clave de criptograma (AC) utilizada para proteger las transacciones individuales y especificada en el campo KeyIdentifier

Creación de datos de transacciones

El contenido (y el orden) exactos del campo de datos de la transacción varían según la implementación y el esquema de red, pero los campos mínimos recomendados (y la secuencia de concatenación) se definen en la sección 8.1.1 del libro 2 de EMV 4.4: Selección de datos. Si los tres primeros campos son importe (17.00), otro importe (0,00) y país de compra, los datos de la transacción comenzarán de la siguiente manera:

  • 000000001700 - cantidad: 12 posiciones implican un decimal de dos dígitos

  • 000000000000 - otra cantidad: 12 posiciones implican un decimal de dos dígitos

  • 0124: código de país de cuatro dígitos

  • Datos de transacción de salida (parciales): 0000000017000000000000000124

Relleno de datos de transacciones

Los datos de las transacciones deben rellenarse antes de enviarlos al servicio. La mayoría de los esquemas utilizan el relleno ISO 9797 Método 2, en el que se añade una cadena hexadecimal 80 seguida de 00 hasta que el campo es un múltiplo del tamaño del bloque de cifrado; 8 bytes o 16 caracteres para TDES y 16 bytes o 32 caracteres para AES. La alternativa (método 1) no es tan común pero utiliza sólo 00 como caracteres de relleno.

Relleno ISO 9797 Método 1

Sin relleno: 00000000170000000000000008400080008000084016051700000000093800000B03011203 (74 caracteres o 37 bytes)

Con relleno: 00000000170000000000000008400080008000084016051700000000093800000B03011203000000 (80 caracteres o 40 bytes)

Relleno ISO 9797 Método 2

Sin relleno: 00000000170000000000000008400080008000084016051700000000093800000B1F220103000000 (80 caracteres o 40 bytes)

Sin relleno: 00000000170000000000000008400080008000084016051700000000093800000B1F2201030000008000000000000000 (88 caracteres o 44 bytes)

Ejemplos

Visa CVN10

En este ejemplo, validaremos un ARQC generado con Visa CVN10.

Si la criptografía AWS de pagos puede validar el ARQC, se devuelve un http/200. Si el arqc no se valida, devolverá una respuesta http/400.

$ aws payment-cryptography-data verify-auth-request-cryptogram --auth-request-cryptogram D791093C8A921769 \
--key-identifier arn:aws:payment-cryptography:us-east-2:111122223333:key/pw3s6nl62t5ushfk \
--major-key-derivation-mode EMV_OPTION_A \ 
--transaction-data 00000000170000000000000008400080008000084016051700000000093800000B03011203000000 \
--session-key-derivation-attributes='{"Visa":{"PanSequenceNumber":"01" \ 
,"PrimaryAccountNumber":"9137631040001422"}}'
{
  "KeyArn": "arn:aws:payment-cryptography:us-east-2:111122223333:key/pw3s6nl62t5ushfk",
  "KeyCheckValue": "08D7B4"
}

Visa CVN18 y Visa CVN22

En este ejemplo, validaremos un ARQC generado con Visa CVN18 o CVN22. Las operaciones criptográficas son las mismas entre el CVN18 y el CVN22, pero los datos contenidos en los datos de las transacciones varían. En comparación con el CVN10, se genera un criptograma completamente diferente incluso con las mismas entradas.

Si la criptografía AWS de pagos puede validar el ARQC, se devuelve un http/200. Si el arqc no se valida, devolverá un http/400.

$ aws payment-cryptography-data verify-auth-request-cryptogram \ 
--auth-request-cryptogram 61EDCC708B4C97B4
--key-identifier arn:aws:payment-cryptography:us-east-2:111122223333:key/pw3s6nl62t5ushfk \ 
--major-key-derivation-mode EMV_OPTION_A 
--transaction-data 00000000170000000000000008400080008000084016051700000000093800000B1F22010300000000000 \
00000000000000000000000000000000000000000008000000000000000
--session-key-derivation-attributes='{"EmvCommon":{"ApplicationTransactionCounter":"000B", \
"PanSequenceNumber":"01","PrimaryAccountNumber":"9137631040001422"}}'
                  
{
  "KeyArn": "arn:aws:payment-cryptography:us-east-2:111122223333:key/pw3s6nl62t5ushfk",
  "KeyCheckValue": "08D7B4"
}