Chiffrement de la couche d'application

Les API Payments standards prennent en charge PGP ou JWE pour le chiffrement de la couche application.

Chiffrement PGP

PGP est un ensemble standard d'algorithmes de chiffrement, de déchiffrement et de signature qui offre une confidentialité et une authentification cryptographiques.

Lorsque vous utilisez PGP pour chiffrer les charges utiles, les partenaires doivent prendre en charge les éléments suivants:

  • Chiffrement et déchiffrement des charges utiles avec plusieurs clés PGP
  • Signature des charges utiles avec plusieurs clés PGP
  • Vérification d'une charge utile avec plusieurs signatures, dont l'une peut être la signature avec la clé fournie par Google.
  • Décryptage des charges utiles encodées en base64 adapté au Web.

Les clés publiques PGP fournies à Google doivent comporter une sous-clé utilisée pour le chiffrement. La sous-clé permet une rotation indépendante de la clé principale. La clé principale est utilisée pour la validation de l'identité. Les clés privées doivent être des clés RSA de 2 048 bits (ou plus) qui expirent dans un an et ont une durée de vie maximale de deux ans.

Avant de commencer le développement, vous devez échanger des clés PGP avec Google. À cette étape, vous générez une paire de clés publique-privée PGP, fournissez la clé publique à Google et recevez une clé publique de Google. Pendant le développement, vous n'avez besoin d'échanger que les clés de bac à sable utilisées pour le développement et les tests en dehors de la production. Avant les tests et le lancement en production, vous devrez effectuer un autre échange de clés de production.

Générer une nouvelle clé PGP

En supposant que vous disposiez d'un binaire GPG dans votre chemin d'accès système, vous pouvez utiliser la commande POSIX suivante pour créer une paire de clés.

$ gpg --full-generate-key

Lorsque vous y êtes invité, sélectionnez une clé RSA avec au moins 2 048 bits d'entropie et une date d'expiration de 1 à 2 ans. Cette commande doit créer à la fois une clé principale (étiquetée SC, pour "S"igning and "C"ertificate generation) et une sous-clé (étiquetée E, pour "E"ncryption).

Configuration de la bibliothèque PGP

Envoyer des charges utiles

  1. Lors de la signature, vous devez utiliser SHA384 comme algorithme de condensé. N'utilisez pas SHA1 ni MD5.
  2. Lors du chiffrement, vous devez utiliser AES256 comme algorithme de chiffrement symétrique. N'utilisez pas CAST5 ni IDEA.
  3. Lorsque vous chiffrez ou signez des messages, veillez à sélectionner la sous-clé avec l'objectif correspondant. Utilisez la clé CAN_SIGN pour la signature et la clé ENCRYPT_COMMS/ENCRYPT_STORAGE pour le chiffrement.

Recevoir des charges utiles

  1. Lorsque vous vérifiez une charge utile, assurez-vous que votre bibliothèque est compatible avec des algorithmes de hachage modernes tels que SHA384. Google commencera à l'utiliser pour toutes les nouvelles clés à partir du 14 mai 2023.
  2. Lorsque vous déchiffrez une charge utile, assurez-vous que votre bibliothèque est compatible avec les algorithmes de chiffrement symétrique modernes tels que AES256. Google commencera à l'utiliser sur toutes les nouvelles clés à partir du 14 mai 2023.

Exemple de chiffrement de la charge utile GPG

La commande ci-dessous montre comment sélectionner des options sécurisées lorsque vous utilisez GPG. Cette opération doit être effectuée dans un environnement sécurisé où les utilisateurs n'ont pas accès aux clés privées ni aux fichiers d'entrée sensibles.

gpg --output signed-and-encrypted.pgp \
  --sign --digest-algo SHA384 \
  --encrypt --cipher-algo AES256 \
  --armor \
  --recipient {key_id} \
  input.txt

GPG sélectionnera automatiquement la bonne clé du lot pour chaque opération que vous lui demandez d'effectuer.

Chiffrement JWE avec signature JWS

Le chiffrement Web JSON (JWE) est une norme définie par la rfc7516 pour le chiffrement du contenu au niveau de l'application. La signature Web JSON (JWS) est une norme définie par la rfc7515 pour signer le contenu au niveau de l'application.

Les requêtes et les réponses seront des jetons JWE chiffrés à l'aide d'un chiffrement asymétrique (clé publique) avec l'option "Sérialisation compacte". Le jeton JWE contiendra la charge utile signée en tant que jeton JWS. Les JWS utilisent également des clés asymétriques : une clé privée pour la signature et une clé publique pour la validation.

Lorsque vous envoyez une charge utile, signez-la d'abord, puis chiffrez-la. Lorsque vous recevez une charge utile, commencez par la déchiffrer, puis vérifiez la signature.

Lorsque vous utilisez JWE, les partenaires doivent prendre en charge les options suivantes:

  • Sérialisation compacte.
  • Décrypter les charges utiles à partir de l'une des clés JWE
  • L'algorithme RSA-OAEP, RSA-OAEP-256 ou ECDH-ES pour la gestion des clés
  • L'algorithme A256GCM, A128GCM, A128CBC-HS256 ou A256CBC-HS512 pour le chiffrement de contenu.
    • Inséré dans l'en-tête enc.
  • En-tête kid pour identifier la clé de chiffrement publique.
  • Les charges utiles de message qui utilisent le chiffrement JWE doivent utiliser le type de contenu application/jose; charset=utf-8.

Lorsque vous utilisez JWS, les partenaires doivent prendre en charge les options suivantes:

  • Sérialisation compacte.
  • Vérification des charges utiles à partir de l'une des clés JWS.
  • L'algorithme HS256, HS384, HS512, RS256, RS384, RS512, ES256, PS256, PS384 ou PS512 pour la création de signature.
  • En-tête kid pour identifier la clé de signature privée.

Les chaînes JWE/JWS seront encodées en tant que chaînes UTF-8, et leurs charges utiles peuvent être des octets arbitraires.

Les clés privées doivent être des clés RSA/ECDH-ES qui expirent dans un an, avec une durée de vie maximale de deux ans. Toutes les identités de clé privée doivent toujours rester sur le serveur du partenaire et, par conséquent, toutes les valeurs de signature doivent être calculées sur le serveur du partenaire.

Avant de commencer le développement, vous devez échanger des clés JWE et JWS avec Google. Les clés doivent être échangées au format JWK, comme défini dans la rfc7517. À cette étape, vous générez une paire de clés publique/privée, fournissez la clé publique à Google et recevez une clé publique de Google. Pendant le développement, vous n'avez besoin d'échanger que les clés de bac à sable utilisées pour le développement et les tests en dehors de la production. Avant les tests et le lancement en production, vous devrez effectuer un autre échange de clés de production.