Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Kryptogramm für Authentifizierungsanfragen (ARQC) verifizieren
Die Kryptogramm-API für Verify Auth Requests wird zur Überprüfung von ARQC verwendet. Die Generierung des ARQC erfolgt in der Regel während der Transaktionsautorisierung auf einer EMV-Chipkarte (oder einem digitalen Äquivalent wie einer mobilen Geldbörse), obwohl der Dienst Generierungen für Entwicklungszwecke bereitstellen kann. Ein ARQC ist für jede Transaktion einzigartig und dient dazu, sowohl die Gültigkeit der Karte kryptografisch nachzuweisen als auch sicherzustellen, dass die Transaktionsdaten exakt mit der aktuellen (erwarteten) Transaktion übereinstimmen.
AWS Die Zahlungskryptografie bietet eine Vielzahl von Optionen zur Validierung von ARQC und zur Generierung optionaler ARPC-Werte, einschließlich der in EMV 4.4 Buch
ARQC-Kryptogramme erfordern normalerweise die folgenden Eingaben (obwohl dies je nach Implementierung variieren kann):
-
PAN — Im Feld angegeben PrimaryAccountNumber
-
PAN-Sequenznummer (PSN) — im PanSequenceNumber Feld angegeben
-
Methode zur Schlüsselableitung wie Common Session Key (CSK) — Spezifiziert in SessionKeyDerivationAttributes
-
Hauptschlüsselableitungsmodus (z. B. EMV-Option A) — Spezifiziert in MajorKeyDerivationMode
-
Transaktionsdaten — eine Zeichenfolge verschiedener Transaktions-, Terminal- und Kartendaten wie Betrag und Datum —, die im Feld angegeben sind TransactionData
-
Hauptschlüssel des Ausstellers — der Hauptschlüssel, der zur Ableitung des Kryptogrammschlüssels (AC) verwendet wird, der zum Schutz einzelner Transaktionen verwendet und im Feld angegeben ist KeyIdentifier
Transaktionsdaten erstellen
Der genaue Inhalt (und die Reihenfolge) des Transaktionsdatenfeldes variiert je nach Implementierung und Netzwerkschema, aber die empfohlenen Mindestfelder (und die Verkettungsreihenfolge) sind in EMV 4.4, Buch 2, Abschnitt 8.1.1
-
000000001700 — Betrag — 12 Stellen impliziert eine zweistellige Dezimalzahl
-
000000000000 — anderer Betrag — 12 Stellen impliziert eine zweistellige Dezimalzahl
-
0124 — vierstelliger Ländercode
-
Transaktionsdaten (teilweise) ausgeben - 0000000017000000000000000124
Auffüllen von Transaktionsdaten
Transaktionsdaten sollten vor dem Senden an den Dienst aufgefüllt werden. Die meisten Schemas verwenden das Auffüllen nach ISO 9797 Methode 2. Dabei wird an eine Hexadezimalzahl 80 gefolgt von 00 angehängt, bis das Feld ein Vielfaches der Größe des Verschlüsselungsblocks ist: 8 Byte oder 16 Zeichen für TDES und 16 Byte oder 32 Zeichen für AES. Die Alternative (Methode 1) ist nicht so üblich, verwendet aber nur 00 als Füllzeichen.
ISO 9797 Methode 1: Innenabstand
Ohne Füllung: 00000000170000000000000008400080008000084016051700000000093800000B03011203 (74 Zeichen oder 37 Byte)
Gepolstert: 0000000017000000000008400080008000084016051700000000093800000B03011203 000000 (80 Zeichen oder 40 Byte)
Polsterung nach ISO 9797 Methode 2
Ohne Füllung: 00000000170000000000000008400080008000084016051700000000093800000B1F220103000000 (80 Zeichen oder 40 Byte)
Gepolstert: 00000000170000000000000008400080008000084016051700000000093800000B1F220103000000 8000000000000000 (88 Zeichen oder 44 Byte)
Beispiele
Visum CVN10
Beispiel
In diesem Beispiel validieren wir einen mit Visa CVN10 generierten ARQC.
Wenn AWS Payment Cryptography den ARQC validieren kann, wird ein zurückgegeben. http/200 Wenn ARCQ (Authorization Request Cryptogram) dann nicht validiert wird, wird eine Antwort zurückgegeben. 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" }
Visum CVN-18 und Visum CVN-22
Beispiel
In diesem Beispiel validieren wir einen ARQC, der mit Visa CVN18 oder CVN22 generiert wurde. Die kryptografischen Operationen zwischen CVN18 und CVN22 sind dieselben, aber die in den Transaktionsdaten enthaltenen Daten variieren. Im Vergleich zu CVN10 wird selbst bei denselben Eingaben ein völlig anderes Kryptogramm generiert.
Wenn AWS Payment Cryptography den ARQC validieren kann, wird ein zurückgegeben. http/200 Wenn der ARCQ nicht validiert ist, wird ein zurückgegeben. 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" }
