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.
Apportez votre propre autorité de certification (BYOCA)
Par défaut, lorsqu'un certificat de clé publique est requis pour les clés asymétriques (RSA, ECC) créées dans le cadre du service, ces certificats sont émis par une autorité de cryptographie des AWS paiements et une autorité de certification (CA) unique au compte. L'objectif est de simplifier son utilisation X.509 sans avoir à identifier ou à configurer une autorité de certification ou à gérer les demandes de signature de certificats (CSR).
AWS La cryptographie des paiements permet également d'utiliser votre propre autorité de certification lorsque cela est requis pour des raisons de politique ou de conformité.
Rubriques
Présentation de
Avec BYOCA, vous pouvez utiliser votre propre CA pour les transferts TR-34 import/export de clés RSA Unwrap et ECDH. Utilisez BYOCA lorsque vous avez besoin d'une chaîne de certificats cohérente au sein de votre organisation ou lorsque les partenaires ont besoin de certificats CA spécifiques. Les exemples suivants illustrent le flux de travail BYOCA pour l' TR-34 exportation et l'importation de TR-34 clés.
Il existe trois différences principales par rapport au TR-34 flux standard :
-
Vous créez la clé RSA avec CreateKey. Avant,
GetParametersForExportouGetParametersForImportcréé pour vous. -
L'GetCertificateSigningRequestAPI crée un CSR. Votre autorité de certification externe peut ensuite le signer.
-
Les ImportKey API ExportKey et acceptent un certificat au moment de l'appel. Le jeton est désormais facultatif.
Importantes considérations
-
Ces exemples utilisent RSA-2048 des clés et enveloppent une TDES-2KEY clé. Lors de l'exportation AES-128, assurez-vous que toutes les clés sont RSA-3072 ou RSA-4096.
-
L'erreur la plus courante est que la clé est représentée par
SigningKeyIdentifieretSigningKeyCertificatene correspond pas.
Flux de travail d'exportation BYOCA
Les étapes suivantes présentent le flux de travail BYOCA complet pour TR-34 l'exportation.
Étape 1 : Création d'une clé RSA
Tout d'abord, créez une paire de clés RSA qui sera finalement le certificat de signature KDH. Vous pouvez ajouter des balises pour identifier l'objectif de la clé.
Exemple Créer une clé RSA pour la signature
$aws payment-cryptography create-key --exportable \ --key-attributes KeyAlgorithm=RSA_2048,KeyUsage=TR31_S0_ASYMMETRIC_KEY_FOR_DIGITAL_SIGNATURE,KeyClass=ASYMMETRIC_KEY_PAIR,KeyModesOfUse='{Sign=True}'
{ "Key": { "KeyArn": "arn:aws:payment-cryptography:us-east-1:111122223333:key/xgmq6fs6uow736uc", "KeyAttributes": { "KeyUsage": "TR31_S0_ASYMMETRIC_KEY_FOR_DIGITAL_SIGNATURE", "KeyClass": "ASYMMETRIC_KEY_PAIR", "KeyAlgorithm": "RSA_2048", "KeyModesOfUse": { "Sign": true } }, "KeyCheckValue": "41E3723C", "KeyCheckValueAlgorithm": "SHA_1", "Enabled": true, "Exportable": true, "KeyState": "CREATE_COMPLETE", "KeyOrigin": "AWS_PAYMENT_CRYPTOGRAPHY" } }
Prenez-en note KeyArn car vous en aurez besoin à l'étape suivante.
Étape 2 : générer une demande de signature de certificat
Générez une demande de signature de certificat (CSR) à signer par votre autorité de certification externe à l'aide de l'GetCertificateSigningRequestAPI. La sortie est un fichier PEM codé en base64. Si vous décodez le contenu en base64 et que vous l'enregistrez, vous aurez un CSR valide au format PEM.
Exemple Générez du CSR
$aws payment-cryptography-data get-certificate-signing-request \ --key-identifier arn:aws:payment-cryptography:us-east-1:111122223333:key/xgmq6fs6uow736uc \ --signing-algorithm SHA512 \ --certificate-subject '{ "CommonName": "MyCertificateAWSUSEAST", "Organization": "Amazon", "OrganizationUnit": "PaymentCryptography", "Country": "US", "StateOrProvince": "Virginia", "City": "Arlington" }'
{ "CertificateSigningRequest": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0..." }
Le CertificateSigningRequest champ contient l'intégralité du fichier PEM, codé en base64. Le fichier PEM inclut les -----END CERTIFICATE REQUEST----- marqueurs -----BEGIN CERTIFICATE REQUEST----- et. Envoyez cette valeur à votre autorité de certification pour signature.
Étape 3 : Réviser le CSR (facultatif)
Vous pouvez éventuellement utiliser OpenSSL pour consulter le contenu du CSR et vous assurer qu'il est valide et conforme aux attentes.
Exemple Passez en revue la RSE avec OpenSSL
$echo "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0..." | base64 -d | openssl req -text
Étape 4 : Signez le CSR auprès d'une autorité de certification
Après avoir généré le CSR, vous devez le faire signer par une autorité de certification (CA). Dans les environnements de production, vous utilisez généralement l'infrastructure CA établie par votre organisation Autorité de certification privée AWS ou celle de votre entreprise. À des fins de test, vous pouvez utiliser OpenSSL pour créer un certificat auto-signé.
Utilisation Autorité de certification privée AWS
Pour signer le CSR à l'aide de Autorité de certification privée AWS, décodez d'abord le CSR codé en base64 et enregistrez-le dans un fichier, puis utilisez l'API. IssueCertificate
Exemple Signez CSR avec CA privée AWS
$echo "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0..." | base64 -d > csr.pem$aws acm-pca issue-certificate \ --certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/12345678-1234-1234-1234-123456789012 \ --csr fileb://csr.pem \ --signing-algorithm SHA256WITHRSA \ --validity Value=365,Type=DAYS
{ "CertificateArn": "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/12345678-1234-1234-1234-123456789012/certificate/abcdef1234567890" }
Récupérez ensuite le certificat signé :
Exemple Récupérer le certificat signé
$aws acm-pca get-certificate \ --certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/12345678-1234-1234-1234-123456789012 \ --certificate-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/12345678-1234-1234-1234-123456789012/certificate/abcdef1234567890
{ "Certificate": "-----BEGIN CERTIFICATE-----\nMIID...\n-----END CERTIFICATE-----", "CertificateChain": "-----BEGIN CERTIFICATE-----\nMIID...\n-----END CERTIFICATE-----" }
Enregistrez le contenu du certificat pour l'utiliser lors de l'étape d'exportation. Vous devrez l'encoder en base64 lorsque vous le fournirez à l'API. ExportKey
Utilisation d'OpenSSL pour les tests
À des fins de test, vous pouvez utiliser OpenSSL pour créer une autorité de certification auto-signée et signer le CSR. Tout d'abord, créez une clé privée CA et un certificat auto-signé :
Exemple Créer une autorité de certification de test avec OpenSSL
$# Generate CA private key openssl genrsa -out ca-key.pem 4096$# Create self-signed CA certificate openssl req -new -x509 -days 3650 -key ca-key.pem -out ca-cert.pem \ -subj "/C=US/ST=Virginia/L=Arlington/O=TestOrg/CN=Test CA"
Décodez ensuite le CSR de l'étape précédente et signez-le avec votre CA de test :
Exemple Signer un CSR avec OpenSSL
$# Decode the base64-encoded CSR echo "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0..." | base64 -d > csr.pem$# Sign the CSR with the CA openssl x509 -req -in csr.pem -CA ca-cert.pem -CAkey ca-key.pem \ -CAcreateserial -out signed-cert.pem -days 365 -sha512
Certificate request self-signature ok subject=C=US, ST=Virginia, L=Arlington, O=Amazon, OU=PaymentCryptography, CN=MyCertificateAWSUSEAST
Le certificat signé est maintenant disponiblesigned-cert.pem. Vous devrez encoder ce certificat en base64 lorsque vous le fournirez à l'API : ExportKey
Exemple Encodez le certificat signé en Base64
$cat signed-cert.pem | base64 -w 0
Étape 5 : Importer un certificat CA
Toute autorité de certification utilisée doit d'abord être approuvée pour empêcher l'utilisation de certificats arbitraires. Importez le certificat racine de votre autorité de certification externe à l'aide de l'ImportKeyAPI. Si vous utilisez une autorité de certification intermédiaire, appelez import-key à nouveau mais spécifiez à la TrustedPublicKey place RootCertificatePublicKey et spécifiez l'ARN de l'autorité de certification racine.
Exemple Importer un certificat Root CA
$aws payment-cryptography import-key --key-material='{ "RootCertificatePublicKey": { "KeyAttributes": { "KeyAlgorithm": "RSA_4096", "KeyClass": "PUBLIC_KEY", "KeyModesOfUse": { "Verify": true }, "KeyUsage": "TR31_S0_ASYMMETRIC_KEY_FOR_DIGITAL_SIGNATURE" }, "PublicKeyCertificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t..." } }'
{ "Key": { "KeyArn": "arn:aws:payment-cryptography:us-east-1:111122223333:key/xivpaqy7qbbm7cdw", "KeyAttributes": { "KeyUsage": "TR31_S0_ASYMMETRIC_KEY_FOR_DIGITAL_SIGNATURE", "KeyClass": "PUBLIC_KEY", "KeyAlgorithm": "RSA_4096", "KeyModesOfUse": { "Verify": true } }, "Enabled": true, "KeyState": "CREATE_COMPLETE", "KeyOrigin": "EXTERNAL" } }
Prenez note des CA à utiliser KeyArn lors de l'étape d'exportation.
Étape 6 : Obtenir le certificat de cryptage KRD
Dans cet exemple, nous procédons à une nouvelle importation dans AWS Payment Cryptography. Nous appelons donc le service pour recevoir un certificat de clé publique KRD à l'aide de l'GetParametersForImportAPI. Dans un scénario réel, cela serait fourni par l'autre système, comme un HSM, un guichet automatique, un terminal de paiement ou un système de gestion de terminaux de paiement.
Exemple Obtenir les paramètres pour l'importation
$aws payment-cryptography-data get-parameters-for-import \ --key-material-type "TR34_KEY_BLOCK" \ --wrapping-key-algorithm RSA_2048
{ "WrappingKeyCertificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...", "WrappingKeyCertificateChain": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...", "WrappingKeyAlgorithm": "RSA_2048", "ImportToken": "import-token-v2rxpl6drxeptn7w", "ParametersValidUntilTimestamp": "2025-11-01T18:45:31.271000-07:00" }
Étape 7 : Exporter la clé avec BYOCA
Enfin, exportez la clé TR-34 avec votre propre CA-signed certificat à l'aide de l'ExportKeyAPI. Fournissez le certificat de signature qui a été signé par votre autorité de certification externe.
Exemple TR-34 Exporter avec BYOCA
$aws payment-cryptography-data export-key \ --export-key-identifier arn:aws:payment-cryptography:us-east-1:111122223333:key/iox73p5f4c4yjiod \ --key-material '{ "Tr34KeyBlock": { "CertificateAuthorityPublicKeyIdentifier": "arn:aws:payment-cryptography:us-east-1:111122223333:key/j625deyfqlwctu57", "SigningKeyIdentifier": "arn:aws:payment-cryptography:us-east-1:111122223333:key/xgmq6fs6uow736uc", "SigningKeyCertificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...", "KeyBlockFormat": "X9_TR34_2012", "WrappingKeyCertificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t..." } }'
{ "WrappedKey": { "WrappedKeyMaterialFormat": "TR34_KEY_BLOCK", "KeyMaterial": "3082055A06092A864886F70D010702A082054B30820547...", "KeyCheckValue": "3DCA31", "KeyCheckValueAlgorithm": "ANSI_X9_24" } }
Le bloc-clé exporté peut désormais être importé par le système récepteur à l'aide du processus TR-34 d'importation standard.
Flux de travail d'importation BYOCA
Les étapes suivantes vous guident à travers le flux de travail BYOCA pour l'importation de TR-34 clés. Utilisez ce flux de travail pour recevoir une clé d'accès à AWS Payment Cryptography avec votre propre certificat de cryptage CA-signed KRD (Key Receiving Device). Avec l'importation BYOCA, vous contrôlez la chaîne de confiance en utilisant une autorité de certification que vous gérez déjà.
Étapes
Étape 1 : Création d'une clé RSA
Créez une paire de clés RSA à utiliser comme clé de chiffrement KRD. Cette clé déballe et déchiffre la clé entrante lors de l'importation. TR-34 La clé n'est pas exportable car elle reste dans le service en tant que clé de réception.
Exemple Créer une clé de cryptage KRD
$aws payment-cryptography create-key \ --key-attributes KeyAlgorithm=RSA_2048,KeyUsage=TR31_K2_TR34_ASYMMETRIC_KEY,KeyClass=ASYMMETRIC_KEY_PAIR,KeyModesOfUse='{Unwrap=True,Decrypt=True}'
{ "Key": { "KeyArn": "arn:aws:payment-cryptography:us-east-1:111122223333:key/bm7t4qv8hzk24jce", "KeyAttributes": { "KeyUsage": "TR31_K2_TR34_ASYMMETRIC_KEY", "KeyClass": "ASYMMETRIC_KEY_PAIR", "KeyAlgorithm": "RSA_2048", "KeyModesOfUse": { "Unwrap": true, "Decrypt": true } }, "KeyCheckValue": "7FA29C1E", "KeyCheckValueAlgorithm": "SHA_1", "Enabled": true, "Exportable": false, "KeyState": "CREATE_COMPLETE", "KeyOrigin": "AWS_PAYMENT_CRYPTOGRAPHY" } }
Notez la valeur KeyArn. Vous en avez besoin à l’étape suivante.
Étape 2 : générer une demande de signature de certificat
Générez une demande de signature de certificat (CSR) pour la clé de cryptage KRD à l'aide de l'GetCertificateSigningRequestAPI. La sortie est un fichier PEM codé en base64. Si vous décodez le contenu en base64 et que vous l'enregistrez, vous aurez un CSR valide au format PEM.
Exemple Générer une clé CSR pour KRD
$aws payment-cryptography-data get-certificate-signing-request \ --key-identifier arn:aws:payment-cryptography:us-east-1:111122223333:key/bm7t4qv8hzk24jce \ --signing-algorithm SHA512 \ --certificate-subject '{ "CommonName": "MyImportKRDCertAWSUSEAST", "Organization": "Amazon", "OrganizationUnit": "PaymentCryptography", "Country": "US", "StateOrProvince": "Virginia", "City": "Arlington" }'
{ "CertificateSigningRequest": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0..." }
Le CertificateSigningRequest champ contient l'intégralité du fichier PEM, codé en base64. Le fichier PEM inclut les -----END CERTIFICATE REQUEST----- marqueurs -----BEGIN CERTIFICATE REQUEST----- et. Envoyez cette valeur à votre autorité de certification pour signature.
Étape 3 : Réviser le CSR (facultatif)
Vous pouvez éventuellement utiliser OpenSSL pour consulter le contenu du CSR et vous assurer qu'il est valide et conforme aux attentes.
Exemple Passez en revue la RSE avec OpenSSL
$echo "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0..." | base64 -d | openssl req -text
Étape 4 : Signez le CSR auprès d'une autorité de certification
Après avoir généré le CSR, faites-le signer par une autorité de certification (CA). Dans les environnements de production, vous utilisez généralement l'infrastructure CA établie par votre organisation Autorité de certification privée AWS ou celle de votre entreprise. À des fins de test, vous pouvez utiliser OpenSSL pour créer un certificat auto-signé.
Utilisation Autorité de certification privée AWS
Pour signer le CSR à l'aide de Autorité de certification privée AWS, décodez d'abord le CSR codé en base64 et enregistrez-le dans un fichier, puis utilisez l'API. IssueCertificate
Exemple Signez CSR avec CA privée AWS
$echo "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0..." | base64 -d > krd-csr.pem$aws acm-pca issue-certificate \ --certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/12345678-1234-1234-1234-123456789012 \ --csr fileb://krd-csr.pem \ --signing-algorithm SHA256WITHRSA \ --validity Value=365,Type=DAYS
{ "CertificateArn": "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/12345678-1234-1234-1234-123456789012/certificate/fedcba0987654321" }
Récupérez ensuite le certificat signé :
Exemple Récupérer le certificat signé
$aws acm-pca get-certificate \ --certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/12345678-1234-1234-1234-123456789012 \ --certificate-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/12345678-1234-1234-1234-123456789012/certificate/fedcba0987654321
{ "Certificate": "-----BEGIN CERTIFICATE-----\nMIID...\n-----END CERTIFICATE-----", "CertificateChain": "-----BEGIN CERTIFICATE-----\nMIID...\n-----END CERTIFICATE-----" }
Enregistrez le contenu du certificat pour l'utiliser lors de l'étape d'importation. Base64-encode le certificat avant de le fournir à l'ImportKeyAPI.
Utilisation d'OpenSSL pour les tests
À des fins de test, vous pouvez utiliser OpenSSL pour créer une autorité de certification auto-signée et signer le CSR. Tout d'abord, créez une clé privée CA et un certificat auto-signé :
Exemple Créer une autorité de certification de test avec OpenSSL
$# Generate CA private key openssl genrsa -out ca-key.pem 4096$# Create self-signed CA certificate openssl req -new -x509 -days 3650 -key ca-key.pem -out ca-cert.pem \ -subj "/C=US/ST=Virginia/L=Arlington/O=TestOrg/CN=Test CA"
Décodez ensuite le CSR de l'étape précédente et signez-le avec votre CA de test :
Exemple Signer un CSR avec OpenSSL
$# Decode the base64-encoded CSR echo "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0..." | base64 -d > krd-csr.pem$# Sign the CSR with the CA openssl x509 -req -in krd-csr.pem -CA ca-cert.pem -CAkey ca-key.pem \ -CAcreateserial -out krd-signed-cert.pem -days 365 -sha512
Certificate request self-signature ok subject=C=US, ST=Virginia, L=Arlington, O=Amazon, OU=PaymentCryptography, CN=MyImportKRDCertAWSUSEAST
Le certificat signé est maintenant disponiblekrd-signed-cert.pem. Base64-encode ce certificat avant de le fournir à l'ImportKeyAPI :
Exemple Encodez le certificat signé en Base64
$cat krd-signed-cert.pem | base64 -w 0
Étape 5 : Importer un certificat CA
Avant d'utiliser une autorité de certification, vous devez d'abord lui faire confiance. Importez le certificat racine de votre autorité de certification externe à l'aide de l'ImportKeyAPI. Si vous utilisez une autorité de certification intermédiaire, appelez import-key à nouveau mais spécifiez à la TrustedPublicKey place RootCertificatePublicKey et spécifiez l'ARN de l'autorité de certification racine.
Exemple Importer un certificat Root CA
$aws payment-cryptography import-key --key-material='{ "RootCertificatePublicKey": { "KeyAttributes": { "KeyAlgorithm": "RSA_4096", "KeyClass": "PUBLIC_KEY", "KeyModesOfUse": { "Verify": true }, "KeyUsage": "TR31_S0_ASYMMETRIC_KEY_FOR_DIGITAL_SIGNATURE" }, "PublicKeyCertificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t..." } }'
{ "Key": { "KeyArn": "arn:aws:payment-cryptography:us-east-1:111122223333:key/nqr3c5v2wp6yl8az", "KeyAttributes": { "KeyUsage": "TR31_S0_ASYMMETRIC_KEY_FOR_DIGITAL_SIGNATURE", "KeyClass": "PUBLIC_KEY", "KeyAlgorithm": "RSA_4096", "KeyModesOfUse": { "Verify": true } }, "Enabled": true, "KeyState": "CREATE_COMPLETE", "KeyOrigin": "EXTERNAL" } }
Notez les CA KeyArn à utiliser lors de l'étape d'importation.
Étape 6 : Obtenir le certificat de signature KDH à partir du système d'envoi
Lors d'un échange de TR-34 clés, l'expéditeur (Key Distribution Host, ou KDH) fournit son certificat de clé publique à des fins de signature. Ce certificat est utilisé pour vérifier la signature sur le bloc-clé encapsulé lors de l'importation, afin de s'assurer que le matériel clé provient d'un expéditeur fiable. En production, ce certificat provient généralement du système émetteur, tel qu'un HSM, un terminal de paiement ou un système de gestion des clés, via son propre processus de distribution de certificats.
Dans cet exemple, vous utilisez la cryptographie des AWS paiements en tant qu'expéditeur et destinataire afin de raccourcir les étapes. Appelez GetParametersForExport pour obtenir le certificat de signature KDH qui serait normalement fourni par le système d'envoi.
Exemple Obtenir les paramètres pour l'exportation
$aws payment-cryptography-data get-parameters-for-export \ --key-material-type "TR34_KEY_BLOCK" \ --signing-key-algorithm RSA_2048
{ "ExportToken": "export-token-k8sfhe2w9rjy4bx6", "SigningKeyCertificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...", "SigningKeyCertificateChain": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...", "SigningKeyAlgorithm": "RSA_2048", "ParametersValidUntilTimestamp": "2025-11-01T18:45:31.271000-07:00" }
Notez le ExportToken et SigningKeyCertificate à utiliser lors de l'étape d'importation.
Étape 7 : Importer la clé avec BYOCA
Enfin, importez la clé TR-34 avec votre propre CA-signed certificat à l'aide de l'ImportKeyAPI. Fournissez le certificat de cryptage KRD qui a été signé par votre autorité de certification externe.
Le RandomNonce paramètre est obligatoire lors de l'utilisation du 2-pass TR-34. Le service ne génère pas de nonce pour vous. Il s'agit d'une valeur hexadécimale aléatoire que vous générez, qui doit être identique à la fois du côté émetteur et du côté récepteur. Lorsque vous utilisez 1-pass TR-34 (qui repose sur un horodatage au lieu d'un nonce), l'horodatage ne doit pas être dans le futur. Le service ne valide aucune fraîcheur particulière (par exemple, dans un certain nombre d'heures), mais vous pouvez appliquer des contrôles de fraîcheur de votre côté si nécessaire.
Exemple TR-34 Importer avec BYOCA
$aws payment-cryptography import-key --key-material='{ "Tr34KeyBlock": { "CertificateAuthorityPublicKeyIdentifier": "arn:aws:payment-cryptography:us-east-1:111122223333:key/nqr3c5v2wp6yl8az", "KeyBlockFormat": "X9_TR34_2012", "RandomNonce": "4997FBB4587D571F", "SigningKeyCertificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...", "WrappingKeyCertificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...", "WrappingKeyIdentifier": "arn:aws:payment-cryptography:us-east-1:111122223333:key/bm7t4qv8hzk24jce", "WrappedKeyBlock": "D0112B0AX00E0000B82679114F470F540165EDFBF407..." } }'
{ "Key": { "KeyArn": "arn:aws:payment-cryptography:us-east-1:111122223333:key/gwz7u3rfxd4o52sb", "KeyAttributes": { "KeyUsage": "TR31_K0_KEY_ENCRYPTION_KEY", "KeyClass": "SYMMETRIC_KEY", "KeyAlgorithm": "TDES_2KEY", "KeyModesOfUse": { "Encrypt": true, "Decrypt": true } }, "KeyCheckValue": "3DCA31", "KeyCheckValueAlgorithm": "ANSI_X9_24", "Enabled": true, "Exportable": true, "KeyState": "CREATE_COMPLETE", "KeyOrigin": "EXTERNAL" } }
La clé est maintenant importée dans AWS Payment Cryptography et prête à être utilisée. Le KeyOrigin champ EXTERNAL indique que la clé provient de l'extérieur du service.
Remarques supplémentaires
-
Ces exemples sont illustrés à l'aide de l'interface de ligne de commande AWS. Les mêmes fonctionnalités sont disponibles dans tous les kits SDK AWS, notamment Java, Python, Go et Rust.
-
Si vous effectuez des tests avec une autorité de certification auto-signée, vous pouvez utiliser OpenSSL pour créer une autorité de certification de test et signer la CSR. En production, utilisez l'infrastructure CA établie par votre organisation.