

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à.

# Funzionalità specifiche della regione per la crittografia AWS dei pagamenti
<a name="advanced.regional"></a>

Alcune funzionalità possono essere specifiche dell'area geografica e non essere utilizzate in altro modo. Queste funzionalità sono descritte più dettagliatamente in questa sezione.

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

L'Australia Standard 2805 (AS2805) è uno standard per i trasferimenti elettronici di fondi utilizzato principalmente per le transazioni di pagamento basate su carta. È gestito da [Standards Australia](https://www.standards.org.au/). Lo standard è composto da 6 libri che trattano numerosi argomenti, dal formato dei messaggi agli standard di crittografia.

La parte 6 fornisce indicazioni sulla gestione delle chiavi, tra cui host-to-host (node-to-node) la comunicazione e i requisiti crittografici pertinenti, mentre altri aspetti sono trattati in altre parti. Tutta la crittografia di questo standard è attualmente basata su TDES. 

**Nota**  
 AS2805 è attualmente disponibile nella regione ap-southeast-2. Verrà esteso ad altre regioni nel prossimo futuro. 

AS2805 presenta una serie di differenze rispetto ad altre implementazioni, che sono riassunte di seguito.

*Protezione delle chiavi*  
Si basa su varianti chiave anziché su blocchi di chiavi come in TR-31/X9.143. AWS Payment Cryptography archivia internamente tutte le chiavi come blocchi chiave, ma consente l'importazione, l'esportazione e il calcolo utilizzando 05 varianti definite. AS28 

*Chiavi unidirezionali*  
AS2805 impone l'uso di chiavi unidirezionali. Se entrambi i nodi devono generare codici di autenticazione dei messaggi (MAC), utilizzano due chiavi. 

*Blocchi Pin*  
AS2805 definisce una tecnica di derivazione delle chiavi per chiavi di crittografia pin uniche per transazione. Questo può essere usato al posto di DUKPT. Lo schema AS28 05 si basa sui dati delle transazioni (numero di traccia e importo della transazione) rispetto all'uso del contatore delle transazioni da parte di DUKPT. 

*Convalida dello scambio di chiavi*  
Definisce un processo per convalidare KEK prima di iniziare a scambiare chiavi funzionanti come i pin key. In altri schemi, le KEK vengono scambiate raramente e vengono convalidate utilizzando KCV. 

AS2805 utilizza il concetto di varianti chiave anziché di blocchi chiave per garantire che le chiavi vengano utilizzate solo per lo scopo previsto (e unico). Di seguito viene illustrato il modo in cui AWS Payment Cryptography esegue la mappatura tra varianti e blocchi chiave durante l'importazione, l'esportazione o l'esecuzione di altre funzioni crittografiche con le chiavi.


| AS2805 Tipo di chiave | AWS Tipo di chiave di crittografia dei pagamenti | 
| --- | --- | 
| TERMINAL\$1MAJOR\$1KEY\$1VARIANT\$100 |  TR31CHIAVE\$1CHIAVE \$1K0\$1CRITTOGRAFIE | 
| PIN\$1ENCRYPTION\$1KEY\$1VARIANT\$128 |  TR31\$1P0\$1PIN\$1CHIAVE\$1CRITTOGRAFIA | 
| VARIANTE\$1CHIAVE\$1DI\$1AUTENTICAZIONE\$124 |  TR31\$1M0\$1ISO\$116609\$1MAC\$1KEY | 
| CHIAVE\$1CRITTOGRAFIA\$1DATI\$1VARIANT\$122 |  TR31CHIAVE\$1CRITTO\$1DATI SIMMETRICA \$1D0\$1SYMMETRICA\$1ENCRYPTION\$1 | 
| VARIANT\$1MASK\$182, VARIANT\$1MASK\$182C0 |  Opzioni disponibili come parte del processo di convalida KEK. Questi tipi di chiavi sono temporanei e non vengono memorizzati dal servizio. | 

Dati due nodi, node1 e node2, gli esempi seguenti sono dal punto di vista di node1. AWS La crittografia dei pagamenti è APIs supportata da entrambi i lati del processo.

**Topics**
+ [

# Scambio di chiavi iniziali (KEK)
](as2805.kekexchange.md)
+ [

# Convalida di KEK
](as2805.kekvalidation.md)
+ [

# Creazione e trasmissione di chiavi funzionanti
](as2805.workingkeys.create.md)
+ [

# Esportazione delle chiavi di lavoro
](as2805.workingkeys.export.md)
+ [

# Pin Translation
](as2805.pintranslation.md)
+ [

# Generazione e convalida di Mac
](as2805.mac.md)

# Scambio di chiavi iniziali (KEK)
<a name="as2805.kekexchange"></a>

 In AS28 05, ogni parte ha il proprio KEK. KEK (s) si riferisce alla chiave laterale di invio che verrà utilizzata ogni volta che la parte mittente avrà bisogno di protect/wrap chiavi e le invierà al nodo2. KEK (r) è la chiave creata dal lato opposto (node2).

**Nota**  
Questi termini sono relativi: un lato crea una chiave (lato mittente) e l'altro la riceve. Detto questo KEY1, viene indicato su node1 come KEK (s) e su node2 come KEK (r).

 I KEK per AS28 05 sono sempre del tipo di chiave = TR31 \$1K0\$1KEY\$1ENCRYPTION\$1KEY poiché vengono utilizzati per proteggere i crittogrammi e non i blocchi chiave. Questo è mappato a AS28 TERMINAL\$1MAJOR\$1KEY\$1VARIANT\$100 come definito in 05 6.1 

Fasi:

**1.Creare una chiave**  
Crea una chiave usando l'[CreateKey](create-keys.md)api. Creerai una chiave di tipo TR31 \$1K0\$1KEY\$1ENCRYPTION\$1KEY

**2.Determina il metodo per lo scambio di chiavi con node2**  
Determina come [scambiare KEK con](keys-export.md) la controparte. Per AS28 05, il metodo più comune e interoperabile è RSA Wrap.

**3. Esportazione KEKs**  
In base alla selezione effettuata sopra, riceverai un certificato a chiave pubblica da node2. Eseguirai l'esportazione utilizzando quel certificato per proteggere la chiave (o deriverai una chiave se usi ECDH).

**4. Importa KEKr**  
In base alla selezione effettuata sopra, invierai un certificato a chiave pubblica a node2. Eseguirai l'importazione utilizzando quel certificato per caricare i nodi 2 KEKr nel servizio.

# Convalida di KEK
<a name="as2805.kekvalidation"></a>

![\[Esempio di diagramma di rete di alto livello per applicazioni PIN che utilizzano la crittografia dei pagamenti AWS\]](http://docs.aws.amazon.com/it_it/payment-cryptography/latest/userguide/images/as2805/kek_validation.png)


Quando il servizio (node1) si connette al nodo2, ciascuna parte si assicurerà di utilizzare la stessa KEK per le operazioni successive utilizzando un processo chiamato KEK Validation. 

**1. Passaggi per convalidare la prima chiave**

**1.1 Ricevi KRs**  
Node2 genererà un messaggio KRs e te lo invierà come parte del processo di accesso. Possono utilizzare la crittografia dei AWS pagamenti per generare questo valore o un'altra soluzione.

**1.2 Genera una risposta di convalida KEK**  
Il nodo genererà una risposta di convalida KEK con input come KEK (r) e quelli forniti nel passaggio 1. KRs   

**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 Rendimento calcolato KRr**  
Restituisce il calcolo KRr a node2. Quel nodo lo confronterà con il valore calcolato dal passaggio 1.

**2.Passaggi per convalidare la seconda chiave**

**2.1 Generare e KRr KRs**  
Il tuo nodo genererà un valore casuale e una copia invertita (invertita) di questo valore utilizzando AWS la crittografia dei pagamenti. Il servizio emetterà entrambi questi valori racchiusi dai KEK. Questi sono noti come KR (s) e 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 Invia KRs a node2**  
Invia il a KRs node2. Conserva il codice KRr per una successiva convalida.

**2.3 Node2 genera una risposta di convalida KEK**  
Node2 utilizza KEKr e KRs, genera e lo rispedisce al servizio dell' KRr utente.

**2.4 Convalida la risposta**  
Confronta KRr il valore del passaggio 1 e il valore restituito dal passaggio 3. Se corrispondono, procedi.

# Creazione e trasmissione di chiavi funzionanti
<a name="as2805.workingkeys.create"></a>

Le chiavi di lavoro tipiche utilizzate in AS28 05 includono due set di chiavi:

Chiavi tra nodi come: chiave pin di zona (ZPK), chiave di crittografia di zona (ZEK) e chiave di autenticazione di zona (ZAK).

Chiavi tra terminali e nodi come: chiave principale del terminale (TMK) e chiave pin del terminale (TPK) se non si utilizza DUKPT.

**Nota**  
Consigliamo di ridurre al minimo le chiavi per terminale e di sfruttare tecniche come TR-34 e DUKPT, ove possibile, che utilizzano un numero inferiore di chiavi.

**Example**  
In questo esempio, abbiamo utilizzato tag opzionali per tracciare lo scopo e l'uso di questa chiave. I tag non vengono utilizzati come parte della funzione crittografica del sistema, ma possono essere utilizzati per la categorizzazione, il monitoraggio finanziario e possono essere utilizzati per applicare le politiche 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"
 }
}
```

# Esportazione delle chiavi di lavoro
<a name="as2805.workingkeys.export"></a>

Per mantenere la compatibilità con altre parti, AWS Payment Cryptography supporta AS28 05 tecniche di key wrapping simmetriche che utilizzano varianti chiave anziché blocchi chiave come TR-31. Se sono condivise più chiavi tra le parti, ognuna deve essere esportata singolarmente. Se i dati vengono inviati in modo bidirezionale, possono esserci due chiavi tra parti dello stesso tipo, ad esempio ZAK (s) e ZAK (r), utilizzate da entrambe le parti per generare codici di autenticazione dei messaggi. 

I parametri aggiuntivi da importare ed esportare in questi formati sono specificati nei comandi.

```
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 Translation
<a name="as2805.pintranslation"></a>

AS2805 descrive una modalità di derivazione delle chiavi specifica della sessione nella sezione 6.4. Ha uno scopo simile a quello di DUKPT e entrambi gli algoritmi possono essere utilizzati, come illustrato nella sezione 6.7 di DUKPT. In questo schema, una chiave pin di sessione (nota come KPE) viene derivata dalla Terminal Pin Key utilizzando SystemTraceAuditNumber (STAN) e come dati di derivazione. TransactionAmount 

Translate pin è una funzione comune che può tradurre to/from una varietà di formati. In questo esempio, traduciamo un pin da un KPE a una chiave di crittografia pin (PEK), ad esempio quando si invia un pin a una rete di pagamento.

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

# Generazione e convalida di Mac
<a name="as2805.mac"></a>

I comandi MAC di generazione e verifica supportano una varietà di comandi MACs tra cui HMAC, CMAC, EMV MAC, ecc. Per AS28 05, esiste una variante aggiuntiva definita in 05.4.1. AS28 In genere nella versione AS28 05, i messaggi in entrata vengono verificati utilizzando questo MAC e i messaggi in uscita includono anche 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"
}
```