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.
# Regionalspezifische Funktionen für AWS Zahlungskryptografie
Bestimmte Funktionen können regionsspezifisch sein und werden nicht anderweitig verwendet. Diese Funktionen werden in diesem Abschnitt ausführlicher beschrieben.
# AS2805
Der Australien Standard 2805 (AS2805) ist ein Standard für elektronische Geldtransfers, der hauptsächlich für kartengestützte Zahlungsvorgänge verwendet wird. Es wird von [Standards Australien](https://www.standards.org.au/) verwaltet. Der Standard besteht aus 6 Büchern, die zahlreiche Themen vom Nachrichtenformat bis hin zu Verschlüsselungsstandards behandeln.
Teil 6 enthält Anleitungen zur Schlüsselverwaltung, einschließlich host-to-host (node-to-node) Kommunikation und relevanter kryptografischer Anforderungen. Andere Aspekte werden in anderen Teilen behandelt. Die gesamte Kryptografie in diesem Standard basiert derzeit auf TDES.
**Anmerkung**
AS2805 ist derzeit in der Region ap-southeast-2 verfügbar. Es wird in naher future in weiteren Regionen eingeführt.
AS2805 weist eine Reihe von Unterschieden im Vergleich zu anderen Implementierungen auf, die im Folgenden zusammengefasst werden.
*Wichtiger Schutz*
Verlässt sich auf Schlüsselvarianten anstelle von Schlüsselblöcken wie in TR-31/X9.143. AWS Die Zahlungskryptografie speichert alle Schlüssel intern als Schlüsselblöcke, ermöglicht aber Import, Export und Berechnung unter Verwendung von 05 definierten Varianten. AS28
*Unidirektionale Schlüssel*
AS2805 schreibt die Verwendung von unidirektionalen Schlüsseln vor. Wenn beide Knoten Nachrichtenauthentifizierungscodes (MAC) generieren müssen, verwenden sie zwei Schlüssel.
*Pin-Blöcke*
AS2805 definiert eine Technik zur Schlüsselableitung für eindeutige PIN-Verschlüsselungsschlüssel pro Transaktion. Dies kann anstelle von DUKPT verwendet werden. Das AS28 05-Schema stützt sich auf Transaktionsdaten (Trace-Nummer und Transaktionsbetrag) im Vergleich zur Verwendung des Transaktionszählers durch DUKPT.
*Überprüfung des Schlüsselaustauschs*
Definiert einen Prozess zur Validierung von KEK, bevor mit dem Austausch von funktionierenden Schlüsseln wie PIN-Schlüsseln begonnen wird. In anderen Schemata werden KEK selten ausgetauscht und mit KCV validiert.
AS2805 verwendet das Konzept der Schlüsselvarianten anstelle von Schlüsselblöcken, um sicherzustellen, dass Schlüssel nur für den vorgesehenen (und einzigen) Zweck verwendet werden. Im Folgenden wird beschrieben, wie AWS Zahlungskryptografie beim Import, Export oder beim Ausführen anderer kryptografischer Funktionen mit Schlüsseln Varianten und Schlüsselblöcken zuordnet.
| AS2805 Schlüsseltyp | AWS Schlüsseltyp für Zahlungskryptografie |
| --- | --- |
| TERMINAL\$1MAJOR\$1KEY\$1VARIANT\$100 | TR31\$1K0\$1KEY\$1VERSCHLÜSSELUNGSSCHLÜSSEL |
| PIN\$1ENCRYPTION\$1KEY\$1VARIANT\$128 | TR31\$1P0\$1PIN\$1VERSCHLÜSSELUNGSSCHLÜSSEL |
| MESSAGE\$1AUTHENTICATION\$1KEY\$1VARIANT\$124 | TR31\$1M0\$1ISO\$116609\$1MAC\$1KEY |
| DATENVERSCHLÜSSELUNGSSCHLÜSSEL\$1VARIANT\$122 | TR31\$1D0\$1SYMMETRISCHER\$1DATENVERSCHLÜSSELUNGSSCHLÜSSEL |
| VARIANT\$1MASK\$182, VARIANT\$1MASK\$182C0 | Optionen, die im Rahmen des KEK-Validierungsprozesses verfügbar sind. Diese Schlüsseltypen sind kurzlebig und werden nicht vom Dienst gespeichert. |
Bei zwei Knoten, node1 und node2, stammen die folgenden Beispiele aus der Perspektive von node1. AWS Payment Cryptography unterstützt APIs von beiden Seiten des Prozesses.
**Topics**
+ [
# Austausch des Anfangsschlüssels (KEK)
](as2805.kekexchange.md)
+ [
# Validierung von KEK
](as2805.kekvalidation.md)
+ [
# Erstellung und Übertragung von Arbeitsschlüsseln
](as2805.workingkeys.create.md)
+ [
# Arbeitsschlüssel exportieren
](as2805.workingkeys.export.md)
+ [
# Pin-Übersetzung
](as2805.pintranslation.md)
+ [
# Mac-Generierung und Validierung
](as2805.mac.md)
# Austausch des Anfangsschlüssels (KEK)
In AS28 05 hat jede Seite ihren eigenen KEK. KEK (s) bezieht sich auf den Schlüssel der sendenden Seite, der immer dann verwendet wird, wenn die sendende Seite zwei protect/wrap Schlüssel benötigt und sie an node2 sendet. KEK (r) ist der Schlüssel, der von der gegenüberliegenden Seite (node2) erzeugt wird.
**Anmerkung**
Diese Begriffe sind relativ — eine Seite erzeugt einen Schlüssel (sendende Seite) und die andere Seite empfängt ihn. KEY1Somit wird er auf Node1 als KEK (s) und auf Node2 als KEK (r) bezeichnet.
KEK für AS28 05 haben immer den Schlüsseltyp = TR31 \$1K0\$1KEY\$1ENCRYPTION\$1KEY, da sie zum Schutz von Kryptogrammen und nicht von Schlüsselblöcken verwendet werden. Dies entspricht AS28 TERMINAL\$1MAJOR\$1KEY\$1VARIANT\$100, wie in 05 6.1 definiert
Schritte:
**1. Erstellen Sie einen Schlüssel**
Erstellen Sie einen Schlüssel mit der [CreateKey](create-keys.md)API. Sie werden einen Schlüssel vom Typ TR31 \$1K0\$1KEY\$1ENCRYPTION\$1KEY erstellen
**2.Ermitteln Sie die Methode für den Austausch von Schlüsseln mit Node2**
Legen Sie fest, wie [KEK mit der Gegenpartei ausgetauscht](keys-export.md) werden soll. Für AS28 05 ist RSA Wrap die gängigste und interoperabelste Methode.
**3. Exportieren KEKs**
Basierend auf Ihrer obigen Auswahl erhalten Sie ein Public-Key-Zertifikat von node2. Sie führen den Export mit diesem Zertifikat aus, um den Schlüssel zu schützen (oder leiten einen Schlüssel ab, wenn Sie ECDH verwenden).
**4. Importieren KEKr**
Basierend auf Ihrer obigen Auswahl senden Sie ein Public-Key-Zertifikat an node2. Sie führen den Import mit diesem Zertifikat aus, um Knoten 2 KEKr in den Dienst zu laden.
# Validierung von KEK
![\[Beispiel für ein übergeordnetes Netzwerkdiagramm für PIN-Anwendungen, die AWS Zahlungskryptografie verwenden\]](http://docs.aws.amazon.com/de_de/payment-cryptography/latest/userguide/images/as2805/kek_validation.png)
Wenn Ihr Dienst (node1) eine Verbindung zu node2 herstellt, stellt jede Seite mithilfe eines Prozesses namens KEK-Validierung sicher, dass sie für nachfolgende Operationen denselben KEK verwenden.
**1. Schritte zur Validierung des ersten Schlüssels**
**1.1 Empfangen KRs**
Node2 generiert eine KRs und sendet sie Ihnen als Teil des Anmeldevorgangs. Sie können AWS Zahlungskryptografie verwenden, um diesen Wert oder eine andere Lösung zu generieren.
**1.2 Generieren Sie eine Antwort auf die KEK-Validierung**
Ihr Knoten generiert eine KEK-Validierungsantwort mit den Eingaben KEK (r) und den in Schritt 1 KRs angegebenen Eingaben.
**Example**
```
cat >> generate-kek-validation-response.json
{
"KekValidationType": {
"KekValidationResponse": {
"RandomKeySend": "9217DC67B8763BABCFDF3DADFCD0F84A"
}
},
"RandomKeySendVariantMask": "VARIANT_MASK_82",
"KeyIdentifier": "arn:aws:payment-cryptography:us-east-2:111122223333:key/ov6icy4ryas4zcza"
}
```
```
$ aws payment-cryptography-data generate-as2805-kek-validation --cli-input-json file://generate-kek-validation-response.json
```
```
{
"KeyArn": "arn:aws:payment-cryptography:us-east-2:111122223333:key/ov6icy4ryas4zcza",
"KeyCheckValue": "0A3674",
"RandomKeyReceive": "A4B7E249C40C98178C1B856DB7FB76EB",
"RandomKeySend": "9217DC67B8763BABCFDF3DADFCD0F84A"
}
```
**1.3 Rendite berechnet KRr**
Gibt das Berechnete KRr an node2 zurück. Dieser Knoten vergleicht ihn mit dem berechneten Wert aus Schritt 1.
**2. Schritte zur Validierung des zweiten Schlüssels**
**2.1 Generieren KRr und KRs**
Ihr Node generiert mithilfe von AWS Payment Cryptography einen zufälligen Wert und eine invertierte (umgekehrte) Kopie dieses Werts. Der Dienst gibt diese beiden Werte zusammen mit dem/den KEK (s) aus. Diese werden als KR (s) und KR (r) bezeichnet.
**Example**
```
cat >> generate-kek-validation-request.json
{
"KekValidationType": {
"KekValidationRequest": {
"DeriveKeyAlgorithm": "TDES_2KEY"
}
},
"RandomKeySendVariantMask": "VARIANT_MASK_82",
"KeyIdentifier": "arn:aws:payment-cryptography:us-east-2:111122223333:key/rhfm6tenpxapkmrv"
}
```
```
$ aws payment-cryptography-data generate-as2805-kek-validation --cli-input-json file://generate-kek-validation-request.json
```
```
{
"KeyArn": "arn:aws:payment-cryptography:us-east-2:111122223333:key/rhfm6tenpxapkmrv",
"KeyCheckValue": "DC1081",
"RandomKeyReceive": "A4B7E249C40C98178C1B856DB7FB76EB",
"RandomKeySend": "9217DC67B8763BABCFDF3DADFCD0F84A"
}
```
**2.2 An Node2 senden KRs **
Sende das an KRs Node2. Bewahren Sie das KRr für eine spätere Überprüfung auf.
**2.3 Node2 generiert eine KEK-Validierungsantwort**
Node2 verwendet das KEKr und KRs, generiert das KRr und sendet es an Ihren Dienst zurück.
**2.4 Antwort validieren**
Vergleichen Sie den Wert KRr aus Schritt 1 mit dem in Schritt 3 zurückgegebenen Wert. Wenn sie übereinstimmen, fahren Sie fort.
# Erstellung und Übertragung von Arbeitsschlüsseln
Zu den typischen funktionierenden Schlüsseln, die in AS28 05 verwendet wurden, gehören zwei Schlüsselsätze:
Schlüssel zwischen Knoten wie: Zonen-Pin-Schlüssel (ZPK), Zonenverschlüsselungsschlüssel (ZEK) und Zonenauthentifizierungsschlüssel (ZAK).
Schlüssel zwischen Terminals und Knoten wie: Terminal-Hauptschlüssel (TMK) und Terminal-Pin-Schlüssel (TPK), falls DUKPT nicht verwendet wird.
**Anmerkung**
Wir empfehlen, die Anzahl der Schlüssel pro Terminal so gering wie möglich zu halten und nach Möglichkeit Techniken wie TR-34 und DUKPT zu nutzen, die eine geringere Anzahl von Schlüsseln verwenden.
**Example**
In diesem Beispiel haben wir optionale Tags verwendet, um den Zweck und die Verwendung dieses Schlüssels nachzuverfolgen. Tags werden nicht als Teil der kryptografischen Funktion des Systems verwendet, können aber zur Kategorisierung und Finanzverfolgung sowie zur Anwendung von IAM-Richtlinien verwendet werden.
```
cat >> create-zone-pin-key.json
{
"KeyAttributes": {
"KeyUsage": "TR31_P0_PIN_ENCRYPTION_KEY",
"KeyClass": "SYMMETRIC_KEY",
"KeyAlgorithm": "TDES_2KEY",
"KeyModesOfUse": {
"Encrypt": true,
"Decrypt": true,
"Wrap": true,
"Unwrap": true,
"Generate": false,
"Sign": false,
"Verify": false,
"DeriveKey": false,
"NoRestrictions": false
}
},
"KeyCheckValueAlgorithm": "ANSI_X9_24",
"Exportable": true,
"Enabled": true,
"Tags": [
{
"Key": "AS2805_KEYTYPE",
"Value": "ZONE_PIN_KEY_VARIANT28"
}
]
}
```
```
$ aws payment-cryptography-data create-key --cli-input-json file://create-zone-pin-key.json --region ap-southeast-2
```
```
{
"Key": {
"KeyArn": "arn:aws:payment-cryptography:us-east-2:111122223333:key/alsuwfxug3pgy6xh",
"KeyAttributes": {
"KeyUsage": "TR31_P0_PIN_ENCRYPTION_KEY",
"KeyClass": "SYMMETRIC_KEY",
"KeyAlgorithm": "TDES_2KEY",
"KeyModesOfUse": {
"Encrypt": true,
"Decrypt": true,
"Wrap": true,
"Unwrap": true,
"Generate": false,
"Sign": false,
"Verify": false,
"DeriveKey": false,
"NoRestrictions": false
}
},
"KeyCheckValue": "9A325B",
"KeyCheckValueAlgorithm": "ANSI_X9_24",
"Enabled": true,
"Exportable": true,
"KeyState": "CREATE_COMPLETE",
"KeyOrigin": "AWS_PAYMENT_CRYPTOGRAPHY",
"CreateTimestamp": "2025-12-17T09:05:27.586000-08:00",
"UsageStartTimestamp": "2025-12-17T09:05:27.570000-08:00"
}
}
```
# Arbeitsschlüssel exportieren
Um die Kompatibilität mit anderen Anbietern aufrechtzuerhalten, unterstützt AWS Payment Cryptography AS28 05 symmetrische Schlüsselverpackungstechniken, bei denen Schlüsselvarianten anstelle von Schlüsselblöcken wie TR-31 verwendet werden. Wenn mehrere Schlüssel von mehreren Parteien gemeinsam genutzt werden, sollte jeder einzeln exportiert werden. Wenn Daten bidirektional gesendet werden, kann es zwischen Parteien desselben Typs zwei Schlüssel wie ZAK (s) und ZAK (r) geben, die von jeder Seite zur Generierung von Nachrichtenauthentifizierungscodes verwendet werden.
Die zusätzlichen Parameter für den Import und Export in diesen Formaten sind in den Befehlen angegeben.
```
cat >> export-zone-pin-key.json
{
"ExportKeyIdentifier": "arn:aws:payment-cryptography:us-east-2:111122223333:key/alsuwfxug3pgy6xh",
"KeyMaterial": {
"As2805KeyCryptogram": {
"WrappingKeyIdentifier": "arn:aws:payment-cryptography:us-east-2:111122223333:key/rhfm6tenpxapkmrv",
"As2805KeyVariant: "PIN_ENCRYPTION_KEY_VARIANT_28"
}
}
}
```
```
$ aws payment-cryptography-data export-key --cli-input-json file://export-zone-pin-key.json --region ap-southeast-2
```
```
{
"WrappedKey": {
"KeyCheckValue": "DC1081",
"KeyCheckValueAlgorithm": "ANSI_X9_24",
"KeyMaterial": "HDC10AEF038E695DDD72AF08DC1BB422D",
"WrappedKeyMaterialFormat": "KEY_CRYPTOGRAM",
"WrappingKeyArn": "arn:aws:payment-cryptography:us-east-2:111122223333:key/rhfm6tenpxapkmrv"
}
}
```
# Pin-Übersetzung
AS2805 beschreibt in Abschnitt 6.4 einen sitzungsspezifischen Schlüsselableitungsmodus. Er dient einem ähnlichen Zweck wie DUKPT, und jeder der beiden Algorithmen kann verwendet werden, da DUKPT in Abschnitt 6.7 behandelt wird. In diesem Schema wird ein Sitzungs-Pin-Schlüssel (bekannt als KPE) aus dem Terminal-Pin-Schlüssel unter Verwendung von SystemTraceAuditNumber (STAN) und TransactionAmount als Ableitungsdaten abgeleitet.
Translate Pin ist eine gängige Funktion, die to/from eine Vielzahl von Formaten übersetzen kann. In diesem Beispiel übersetzen wir eine PIN von einer KPE in einen PIN-Verschlüsselungsschlüssel (PEK), z. B. wenn eine PIN an ein Zahlungsnetzwerk gesendet wird.
```
cat >> translate-pin-as2805.json
{
"EncryptedPinBlock": "B3B34B43BAB5F81A",
"IncomingKeyIdentifier": "arn:aws:payment-cryptography:us-east-2:111122223333:key/ivi5ksfsuplneuyt",
"IncomingTranslationAttributes": {
"IsoFormat0": {
"PrimaryAccountNumber": "9999179999900013"
}
},
"IncomingAs2805Attributes": {
"SystemTraceAuditNumber": "000348",
"TransactionAmount": "000000000328"
},
"OutgoingKeyIdentifier": "",
"OutgoingTranslationAttributes": {
"IsoFormat0": {
"PrimaryAccountNumber": "9999179999900013"
}
}
}
```
```
$ aws payment-cryptography-data translate-pin-data --cli-input-json file://translate-pin-as2805.json --region ap-southeast-2
```
```
{
"WrappedKey": {
"KeyCheckValue": "DC1081",
"KeyCheckValueAlgorithm": "ANSI_X9_24",
"KeyMaterial": "HDC10AEF038E695DDD72AF08DC1BB422D",
"WrappedKeyMaterialFormat": "KEY_CRYPTOGRAM",
"WrappingKeyArn": "arn:aws:payment-cryptography:us-east-2:111122223333:key/rhfm6tenpxapkmrv"
}
}
```
# Mac-Generierung und Validierung
Die MAC-Befehle zum Generieren und Überprüfen unterstützen eine Vielzahl von MACs Programmen, darunter HMAC, CMAC, EMV MAC usw. Für AS28 05 gibt es eine zusätzliche Variante, die in 05.4.1 definiert ist. AS28 Typischerweise werden eingehende Nachrichten in AS28 05 mit diesem MAC verifiziert, und ausgehende Nachrichten enthalten ebenfalls einen MAC.
```
cat verify-mac.json
{
"KeyIdentifier": "arn:aws:payment-cryptography:us-east-2:111122223333:key/qnobl5lghrzunce6",
"Mac": "86304058",
"MessageData": "73D8BA54D3852951DAEA41",
"VerificationAttributes": {
"Algorithm": "AS2805_4_1"
}
}
```
```
$ aws payment-cryptography-data verify-mac --cli-input-json file://verify-mac.json --region ap-southeast-2
```
```
{
"KeyIdentifier": "arn:aws:payment-cryptography:us-east-2:111122223333:key/qnobl5lghrzunce6",
"KeyCheckValue": "2976E7"
}
```