Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Cryptogramme de demande d'authentification (ARQC)
L'API de cryptogramme de demande d'authentification de vérification est utilisée pour vérifier l'ARQC. La génération de l'ARQC n'entre pas dans le cadre de la cryptographie des AWS paiements et est généralement effectuée sur une carte à puce EMV (ou un équivalent numérique tel qu'un portefeuille mobile) pendant le temps d'autorisation de la transaction. Un ARQC est unique à chaque transaction et est destiné à montrer de manière cryptographique à la fois la validité de la carte et à garantir que les données de transaction correspondent exactement à la transaction en cours (attendue).
AWS La cryptographie des paiements fournit diverses options pour valider l'ARQC et générer des valeurs ARPC facultatives, notamment celles définies dans le livre 2 de l'EMV 4.4
Les cryptogrammes ARQC nécessitent généralement les entrées suivantes (bien que cela puisse varier en fonction de l'implémentation) :
-
PAN - Spécifié dans le PrimaryAccountNumber champ
-
Numéro de séquence PAN (PSN) - spécifié dans le champ PanSequenceNumber
-
Méthode de dérivation des clés, telle que la clé de session commune (CSK), spécifiée dans le SessionKeyDerivationAttributes
-
Mode de dérivation de la clé principale (tel que l'option A EMV) - Spécifié dans le MajorKeyDerivationMode
-
Données de transaction - une chaîne de diverses données de transaction, de terminal et de carte telles que le montant et la date - spécifiées dans le TransactionData champ
-
Clé principale de l'émetteur : clé principale utilisée pour dériver la clé cryptographique (AC) utilisée pour protéger les transactions individuelles et spécifiée dans le champ KeyIdentifier
Création de données de transaction
Le contenu exact (et l'ordre) du champ de données de transaction varie en fonction de l'implémentation et du schéma de réseau, mais les champs minimaux recommandés (et la séquence de concaténation) sont définis dans le livre 2 de l'EMV 4.4, section 8.1.1
-
000000001700 - montant - 12 positions décimales implicites à deux chiffres
-
000000000000 - autre montant - 12 positions décimales implicites à deux chiffres
-
0124 - code de pays à quatre chiffres
-
Données de transaction (partielles) de sortie - 0000000017000000000000000124
Rembourrage des données de transaction
Les données de transaction doivent être complétées avant d'être envoyées au service. La plupart des schémas utilisent le remplissage de la méthode 2 ISO 9797, où une chaîne hexadécimale est ajoutée par 80 puis par 00 jusqu'à ce que le champ soit un multiple de la taille du bloc de chiffrement ; 8 octets ou 16 caractères pour TDES et 16 octets ou 32 caractères pour AES. L'alternative (méthode 1) n'est pas aussi courante mais utilise uniquement 00 comme caractères de remplissage.
Rembourrage ISO 9797 Méthode 1
Non rembourré : 000000000000000000000008400080008000084016051700000000093800000B03011203 (74 caractères ou 37 octets)
Rembourré : 000000000000000000000008400080008000084016051700000000093800000B03011203 000000 (80 caractères ou 40 octets)
Rembourrage ISO 9797 Méthode 2
Non rembourré : 000000000000000000000008400080008000084016051700000000093800000B1F220103000000 (80 caractères ou 40 octets)
Rembourré : 000000000000000000000008400080008000084016051700000000093800000B1F220103000000 8000000000000000 (88 caractères ou 44 octets)
Exemples
Visa CVN1 0
Dans cet exemple, nous allons valider un ARQC généré à l'aide de Visa CVN1 0.
Si AWS Payment Cryptography est en mesure de valider l'ARQC, un http/200 est renvoyé. Si l'ARCQ (Authorization Request Cryptogram) n'est pas validé, il renverra une réponse 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 et visa CVN22
Dans cet exemple, nous allons valider un ARQC généré à l'aide de Visa CVN18 ou CVN22. Les opérations cryptographiques sont les mêmes entre CVN18 et CVN22 mais les données contenues dans les données de transaction varient. Par rapport à CVN1 0, un cryptogramme complètement différent est généré même avec les mêmes entrées.
Si AWS Payment Cryptography est en mesure de valider l'ARQC, un http/200 est renvoyé. Si l'ARCQ n'est pas validé, il renverra 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" }
