Chiffrement de la couche d'application

Les API de paiement standards sont compatibles avec 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 assurent la confidentialité et l'authentification cryptographiques.

Lorsqu'ils utilisent PGP pour chiffrer des charges utiles, les partenaires doivent prendre en charge:

  • Chiffrer et déchiffrer des charges utiles avec plusieurs clés PGP
  • Signer des charges utiles avec plusieurs clés PGP
  • Valider une charge utile avec plusieurs signatures, dont une seule peut être la signature avec la clé fournie par Google.
  • Déchiffrement des charges utiles encodées au format base64 adaptés au Web.

Les clés publiques PGP fournies à Google doivent avoir 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 d'au moins 2 048 bits qui expirent dans un an avec une durée de vie maximale de deux ans.

Avant de commencer le développement, vous devez échanger vos clés PGP avec Google. Au cours de cette étape, vous allez générer une paire de clés publique-privée PGP, fournir la clé publique à Google et recevoir une clé publique de Google. Pendant le développement, vous n'aurez 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 des clés de production.

Générer une nouvelle clé PGP

En supposant que vous ayez un binaire GPG dans le 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 un délai d'expiration de 1 à 2 ans. Cette commande doit créer à la fois une clé principale (libellée SC, pour "S'igning and 'C'ertificategeneration) et une sous-clé (libellé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é, et non SHA1 ni MD5.
  2. Lors du chiffrement, vous devez utiliser AES256 comme algorithme de chiffrement symétrique, et non CAST5 ni IDEA.
  3. Lorsque vous chiffrez ou signez des messages, veillez à sélectionner la sous-clé ayant l'objectif correspondant. Utilisez la clé CAN_SIGN pour la signature et la clé ENCRYPT_COMMS/ENCRYPT_STORAGE pour le chiffrement.

Recevoir les charges utiles

  1. Lorsque vous vérifiez une charge utile, assurez-vous que votre bibliothèque est compatible avec les algorithmes de hachage modernes, tels que SHA384. Google commencera à l'utiliser pour toutes les nouvelles clés à compter 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 pour toutes les nouvelles clés à compter du 14 mai 2023.

Exemple de chiffrement de la charge utile GPG

La commande ci-dessous montre comment sélectionner des options de sécurisation lorsque vous utilisez GPG. Cette opération doit être effectuée dans un environnement de confiance 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électionne automatiquement la bonne clé dans le bundle 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 rfc7516 pour le chiffrement de contenu au niveau de l'application. La signature Web JSON (JWS) est une norme définie par rfc7515 pour la signature du 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. JWS utilise é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, vous devez d'abord signer la charge utile, puis la chiffrer. Lorsque vous recevez une charge utile, vous devez d'abord la déchiffrer, puis vérifier la signature.

Lorsqu'ils utilisent JWE, les Partenaires doivent prendre en charge les options suivantes:

  • Sérialisation compacte.
  • Déchiffrement des charges utiles à partir de l'une des nombreuses clés JWE.
  • Algorithme RSA-OAEP, RSA-OAEP-256 ou ECDH-ES pour la gestion des clés.
  • Les algorithmes A256GCM, A128GCM, A128CBC-HS256 ou A256CBC-HS512 pour le chiffrement de contenu.
    • Renseigné dans l'en-tête enc.
  • 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.

Lorsqu'ils utilisent JWS, les Partenaires doivent prendre en charge les options suivantes:

  • Sérialisation compacte.
  • Vérifier les charges utiles à partir de l'une des nombreuses clés JWS.
  • 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 au format 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. 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 vos clés JWE et JWS avec Google. Les clés doivent être échangées au format JWK, tel que défini dans le document rfc7517. Au cours de cette étape, vous allez générer une paire de clés publique/privée, fournir la clé publique à Google et recevoir une clé publique de sa part. Pendant le développement, vous n'aurez 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 des clés de production.