

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.

# AS2805
<a name="advanced.regional.as2805"></a>

La norme australienne 2805 AS28 (05) est une norme pour les transferts électroniques de fonds utilisée principalement pour les transactions de paiement par carte. Il est géré par [Standards Australia](https://www.standards.org.au/). La norme comprend 6 livres qui couvrent de nombreux sujets allant du format des messages aux normes de cryptage.

La partie 6 fournit des conseils sur la gestion des clés, y compris host-to-host (node-to-node) la communication et les exigences cryptographiques pertinentes, tandis que d'autres aspects sont abordés dans d'autres parties. Toute la cryptographie de cette norme est actuellement basée sur le TDES. 

**Note**  
 AS2805 est actuellement disponible dans la région ap-southeast-2. Il sera déployé dans d'autres régions dans un futur proche. 

AS2805 présente un certain nombre de différences par rapport aux autres implémentations, qui sont résumées ci-dessous.

*Protection des clés*  
S'appuie sur des variantes de touches plutôt que sur des blocs-touches comme dans le TR-31/X9.143. AWS La cryptographie des paiements stocke toutes les clés sous forme de blocs clés en interne, mais permet l'importation, l'exportation et le calcul en utilisant AS28 05 variantes définies. 

*Clés unidirectionnelles*  
AS2805 impose l'utilisation de touches unidirectionnelles. Si les deux nœuds doivent générer des codes d'authentification des messages (MAC), ils utilisent deux clés. 

*Pins à épingles*  
AS2805 définit une technique de dérivation de clés pour des clés de chiffrement par code PIN uniques par transaction. Cela peut être utilisé à la place du DUKPT. Le schéma AS28 05 repose sur les données de transaction (numéro de trace et montant de la transaction) par rapport à l'utilisation du compteur de transactions par le DUKPT. 

*Validation des échanges de clés*  
Définit un processus pour valider le KEK avant de commencer à échanger des clés de travail telles que des clés PIN. Dans d'autres systèmes, les KEK sont rarement échangés et sont validés à l'aide du KCV. 

AS2805 utilise le concept de variantes de clés plutôt que de blocs de clés pour garantir que les clés ne sont utilisées que dans le but prévu (et unique). Voici comment la cryptographie des AWS paiements établit une correspondance entre les variantes et les blocs de touches lors de l'importation, de l'exportation ou de l'exécution d'autres fonctions cryptographiques à l'aide de clés.


| AS2805 Type de clé | AWS Type de clé de cryptographie de paiement | 
| --- | --- | 
| TERMINAL\$1MAJOR\$1KEY\$1VARIANT\$100 |  TR31\$1K0\$1KEY\$1CRYPTION\$1KEY | 
| VARIANTE DE LA CLÉ DE CHIFFREMENT PAR CODE PIN 28 |  TR31CLÉ DE CHIFFREMENT \$1P0\$1PIN | 
| VARIANTE\$1CLÉ\$1D' AUTHENTIFICATION DU MESSAGE\$124 |  TR31\$1M0\$1ISO\$116609\$1MAC\$1KEY | 
| VARIANTE\$1CLÉ\$1CHIFFRE\$1DONNÉES\$122 |  TR31\$1D0\$1CLÉ\$1DE CHIFFREMENT DES DONNÉES SYMÉTRIQUES | 
| VARIANT\$1MASK\$182, VARIANT\$1MASK\$182C0 |  Options disponibles dans le cadre du processus de validation KEK. Ces types de clés sont éphémères et ne sont pas stockés par le service. | 

Étant donné deux nœuds, node1 et node2, les exemples suivants sont du point de vue du nœud 1. AWS La cryptographie des paiements prend APIs en charge les deux côtés du processus.

**Topics**
+ [Échange de clé initiale (KEK)](as2805.kekexchange.md)
+ [Validation du KEK](as2805.kekvalidation.md)
+ [Création et transmission de clés de travail](as2805.workingkeys.create.md)
+ [Exportation de clés de travail](as2805.workingkeys.export.md)
+ [Traduction d'épingles](as2805.pintranslation.md)
+ [Génération et validation de Mac](as2805.mac.md)

# Échange de clé initiale (KEK)
<a name="as2805.kekexchange"></a>

 En AS28 2005, chaque camp possède son propre KEK. KEK (s) fait référence à la clé côté expéditeur qui sera utilisée chaque fois que le côté expéditeur aura besoin de protect/wrap clés et les enverra au nœud 2. KEK (r) est la clé créée par le côté opposé (node2).

**Note**  
Ces termes sont relatifs : un côté crée une clé (côté émetteur) et l'autre la reçoit. Ainsi donné KEY1, il est appelé KEK (s) sur le nœud 1 et KEK (r) sur le nœud 2.

 Les KEK pour AS28 05 sont toujours de type clé = TR31 \$1K0\$1KEY\$1ENCRYPTION\$1KEY car ils sont utilisés pour protéger les cryptogrammes et non les blocs de clés. Cela correspond à TERMINAL\$1MAJOR\$1KEY\$1VARIANT\$100 tel que défini dans 05 6.1 AS28 

Étapes :

**1. Création d'une clé**  
Créez une clé à l'aide de l'[CreateKey](create-keys.md)API. Vous allez créer une clé de type TR31 \$1K0\$1KEY\$1ENCRYPTION\$1KEY

**2. Déterminer la méthode d'échange de clés avec le nœud 2**  
Déterminez comment [échanger des KEK avec la contrepartie](keys-export.md). Pour AS28 2005, la méthode la plus courante et la plus interopérable est RSA Wrap.

**3. Exportation KEKs**  
Sur la base de votre sélection ci-dessus, vous recevrez un certificat de clé publique de la part de node2. Vous exécuterez l'exportation à l'aide de ce certificat pour protéger la clé (ou vous en déduirez une clé si vous utilisez l'ECDH).

**4. Importer KEKr**  
Sur la base de votre sélection ci-dessus, vous allez envoyer un certificat de clé publique à node2. Vous exécuterez l'importation en utilisant ce certificat pour charger les nœuds 2 KEKr dans le service.

# Validation du KEK
<a name="as2805.kekvalidation"></a>

![\[Exemple de schéma de réseau de haut niveau pour une application PIN utilisant la cryptographie des AWS paiements\]](http://docs.aws.amazon.com/fr_fr/payment-cryptography/latest/userguide/images/as2805/kek_validation.png)


Lorsque votre service (node1) se connecte au nœud 2, chaque partie s'assure qu'elle utilise le même KEK pour les opérations suivantes à l'aide d'un processus appelé validation KEK. 

**1. Étapes pour valider la première clé**

**1.1 Recevoir KRs**  
Node2 générera un KRs et vous l'enverra dans le cadre du processus de connexion. Ils peuvent utiliser la cryptographie des AWS paiements pour générer cette valeur ou une autre solution.

**1.2 Générer une réponse de validation KEK**  
Votre nœud générera une réponse de validation KEK avec des entrées telles que le KEK (r) et celui KRs fourni à l'étape 1.  

**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 Rendement calculé KRr**  
Renvoie le résultat calculé KRr à node2. Ce nœud la comparera à la valeur calculée à l'étape 1.

**2. Étapes pour valider la deuxième clé**

**2.1 Générer KRr et KRs**  
Votre nœud générera une valeur aléatoire et une copie inversée (inversée) de cette valeur à l'aide de la cryptographie des AWS paiements. Le service produira ces deux valeurs encapsulées par le ou les KEK. Ils sont appelés KR (s) et KR (r).  

**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 Envoyer KRs vers node2**  
Envoyez-le KRs au nœud 2. Conservez-le KRr pour une validation ultérieure.

**2.3 Node2 génère une réponse de validation KEK**  
Node2 utilise le KEKr et KRs, le génère KRr et le renvoie à votre service.

**2.4 Valider la réponse**  
Comparez KRr la valeur obtenue à l'étape 1 et la valeur renvoyée à l'étape 3. S'ils correspondent, continuez.

# Création et transmission de clés de travail
<a name="as2805.workingkeys.create"></a>

Les clés de travail typiques utilisées en AS28 05 incluent deux jeux de clés :

Clés entre les nœuds, telles que : clé PIN de zone (ZPK), clé de chiffrement de zone (ZEK) et clé d'authentification de zone (ZAK).

Clés entre les terminaux et les nœuds, telles que : touche principale du terminal (TMK) et touche PIN du terminal (TPK) si vous n'utilisez pas DUKPT.

**Note**  
Nous recommandons de minimiser le nombre de clés par terminal et de tirer parti de techniques telles que le TR-34 et le DUKPT dans la mesure du possible qui utilisent un plus petit nombre de clés.

**Example**  
Dans cet exemple, nous avons utilisé des balises facultatives pour suivre l'objectif et l'utilisation de cette clé. Les balises ne sont pas utilisées dans le cadre de la fonction cryptographique du système, mais peuvent être utilisées pour la catégorisation, le suivi financier et peuvent être utilisées pour appliquer des politiques IAM.  

```
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"
 }
}
```

# Exportation de clés de travail
<a name="as2805.workingkeys.export"></a>

Pour maintenir la compatibilité avec les autres parties, AWS Payment Cryptography prend en charge AS28 05 techniques d'encapsulage de clés symétriques qui utilisent des variantes de clés au lieu de blocs-clés tels que le TR-31. Si plusieurs clés sont partagées entre les parties, chacune doit être exportée individuellement. Si les données sont envoyées de manière bidirectionnelle, il peut y avoir deux clés entre les parties du même type, telles que ZAK (s) et ZAK (r), qui sont utilisées par chaque partie pour générer des codes d'authentification des messages. 

Les paramètres supplémentaires à importer et à exporter dans ces formats sont spécifiés dans les commandes.

```
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"
    }
}
```

# Traduction d'épingles
<a name="as2805.pintranslation"></a>

AS2805 décrit un mode de dérivation de clés spécifique à une session dans la section 6.4. Il a un objectif similaire à celui du DUKPT et l'un ou l'autre algorithme peut être utilisé car DUKPT est traité dans la section 6.7. Dans ce schéma, un code PIN de session (connu sous le nom de KPE) est dérivé du code PIN du terminal en utilisant SystemTraceAuditNumber (STAN) et en TransactionAmount tant que données de dérivation.

Translate pin est une fonction courante qui permet de traduire to/from une variété de formats. Dans cet exemple, nous traduisons un code PIN d'un KPE en clé de cryptage par code PIN (PEK), par exemple lors de l'envoi d'un code PIN à un réseau de paiement.

```
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"
    }
}
```

# Génération et validation de Mac
<a name="as2805.mac"></a>

Les commandes de génération et de vérification MAC prennent en charge une variété de commandes, MACs notamment HMAC, CMAC, EMV MAC, etc. Pour AS28 2005, il existe une variante supplémentaire définie au AS28 05.4.1. Généralement, en AS28 05, les messages entrants sont vérifiés à l'aide de ce MAC et les messages sortants incluent également un 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"
}
```