Crittogramma Verify Auth Request (ARQC) - AWS Crittografia dei pagamenti
Creazione di dati sulle transazioni Riempimento dei dati delle transazioni Esempi

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Crittogramma Verify Auth Request (ARQC)

L'API del crittogramma di verifica della richiesta di autenticazione viene utilizzata per verificare l'ARQC. La generazione dell'ARQC non rientra nell'ambito della crittografia dei AWS pagamenti e viene generalmente eseguita su una Chip Card EMV (o un equivalente digitale come un portafoglio mobile) durante il periodo di autorizzazione della transazione. Un ARQC è unico per ogni transazione e ha lo scopo di mostrare crittograficamente sia la validità della carta sia di garantire che i dati della transazione corrispondano esattamente alla transazione corrente (prevista).

AWS La crittografia dei pagamenti offre una varietà di opzioni per la convalida dell'ARQC e la generazione di valori ARPC opzionali, inclusi quelli definiti in EMV 4.4 Book 2 e altri schemi utilizzati da Visa e Mastercard. Per un elenco completo di tutte le opzioni disponibili, consulta la sezione della Guida API. VerifyCardValidationData

I crittogrammi ARQC richiedono in genere i seguenti input (sebbene ciò possa variare in base all'implementazione):

  • PAN - Specificato nel campo PrimaryAccountNumber

  • Numero di sequenza PAN (PSN) - specificato nel campo PanSequenceNumber

  • Metodo di derivazione delle chiavi come Common Session Key (CSK) - Specificato nel SessionKeyDerivationAttributes

  • Modalità di derivazione della chiave principale (ad esempio EMV Option A): specificata nella MajorKeyDerivationMode

  • Dati sulle transazioni: una stringa di vari dati relativi a transazioni, terminali e carte, come Importo e Data, specificati nel campo TransactionData

  • Chiave principale dell'emittente: la chiave master utilizzata per derivare la chiave crittografica (AC) utilizzata per proteggere le singole transazioni e specificata nel campo KeyIdentifier

Creazione di dati sulle transazioni

Il contenuto esatto (e l'ordine) del campo di dati della transazione varia in base all'implementazione e allo schema di rete, ma i campi minimi consigliati (e la sequenza di concatenazione) sono definiti nel Libro 2 di EMV 4.4, Sezione 8.1.1 - Selezione dei dati. Se i primi tre campi sono importo (17,00), altro importo (0,00) e paese di acquisto, i dati della transazione inizierebbero come segue:

  • 000000001700 - importo - 12 posizioni implicavano un decimale a due cifre

  • 000000000000 - altro importo - 12 posizioni implicavano un decimale a due cifre

  • 0124 - prefisso internazionale a quattro cifre

  • Dati di transazione (parziali) in uscita - 0000000017000000000000000124

Riempimento dei dati delle transazioni

I dati delle transazioni devono essere aggiunti prima dell'invio al servizio. La maggior parte degli schemi utilizza il padding ISO 9797 Metodo 2, in cui una stringa esadecimale viene aggiunta dall'esadecimale 80 seguito da 00 fino a quando il campo non è un multiplo della dimensione del blocco di crittografia; 8 byte o 16 caratteri per TDES e 16 byte o 32 caratteri per AES. L'alternativa (metodo 1) non è così comune, ma utilizza solo 00 come caratteri di riempimento.

ISO 9797 Metodo 1: Imbottitura

Senza imbottitura: 00000000000000000008400080008000084016051700000000093800000B03011203 (74 caratteri o 37 byte)

Imbottito: 0000000000000000000840008000084016051700000000093800000B03011203 000000 (80 caratteri o 40 byte)

Imbottitura ISO 9797 Metodo 2

Senza imbottitura: 00000000000000000008400080008000084016051700000000093800000B1F220103000000 (80 caratteri o 40 byte)

Imbottito: 000000000000000840008000084016051700000000093800000B1F220103000000 8000000000000000 (88 caratteri o 44 byte)

Esempi

Visa CVN10

In questo esempio, convalideremo un ARQC generato utilizzando Visa CVN10.

Se AWS Payment Cryptography è in grado di convalidare l'ARQC, viene restituito un http/200. Se l'arqc non è convalidato, restituirà una risposta 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 e Visa CVN22

In questo esempio, convalideremo un ARQC generato utilizzando Visa CVN18 o CVN22. Le operazioni crittografiche sono le stesse tra CVN18 e CVN22, ma i dati contenuti nei dati delle transazioni variano. Rispetto a CVN10, viene generato un crittogramma completamente diverso anche con gli stessi input.

Se AWS Payment Cryptography è in grado di convalidare l'ARQC, viene restituito un http/200. Se l'arqc non è convalidato, restituirà 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"
}