Chiffrement de la couche d'application

Les API Payments standards sont compatibles avec PGP ou JWE pour le chiffrement au niveau de la couche d'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.

Lorsque vous utilisez PGP pour chiffrer des charges utiles, les partenaires doivent être compatibles avec les éléments suivants :

  • 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 l'une peut être la signature avec la clé fournie par Google.
  • Déchiffrer des charges utiles encodées au format 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é primaire. La clé primaire 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 dont la durée de vie maximale est de deux ans.

Avant de commencer le développement, vous devez échanger des clés PGP avec Google. Au cours de 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'aurez besoin d'échanger que les clés du 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 clé PGP

Si vous disposez d'un binaire GPG dans votre chemin 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 expiration de un à deux ans. Cette commande doit créer à la fois une clé primaire (libellée SC, pour "S"ignature et génération de "C"ertificat) et une sous-clé (libellée E, pour "E"ncryption).

Rotation des clés

Pour garantir un service ininterrompu lors des rotations de clés, le système est compatible avec plusieurs clés PGP actives pour les partenaires et Google.

  • Vous pouvez signer des charges utiles avec les anciennes et les nouvelles clés pendant leur rotation. Google validera la signature par rapport à toute clé publique active dont Google dispose.

  • Lorsque vous devez faire tourner vos clés publiques Google, vous pouvez chiffrer les charges utiles avec les anciennes et les nouvelles clés publiques Google. Google peut déchiffrer avec l'une ou l'autre des clés.

  • Les ID de clé PGP dans le message lui-même permettent l'identification automatique des clés, ce qui élimine le besoin de champs de version de charge utile ou de délais de basculement coordonnés.

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 validez une charge utile, assurez-vous que votre bibliothèque est compatible avec les algorithmes de hachage modernes tels que SHA384. Google commencera à l'utiliser sur 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 charge utile GPG

La commande suivante montre comment sélectionner des options sécurisées lorsque vous utilisez GPG. Cette opération doit être effectuée dans un environnement de confiance où les personnes 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 clé appropriée dans le bundle pour chaque opération que vous lui demanderez d'effectuer.

Chiffrement JWE avec signature JWS

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

Les requêtes et les réponses seront des jetons JWE chiffrés à l'aide du chiffrement asymétrique (clé publique) avec l'option "Compact Serialization". 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, signez-la d'abord, puis chiffrez-la. Lorsque vous recevez une charge utile, déchiffrez-la d'abord, puis validez la signature.

Lorsque vous utilisez JWE, les partenaires doivent être compatibles avec 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.
  • Algorithme A256GCM, A128GCM, A128CBC-HS256 ou A256CBC-HS512 pour le chiffrement de contenu.
    • Rempli 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 être compatibles avec les options suivantes :

  • Sérialisation compacte.
  • Validation des 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 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 et dont la durée de vie maximale est 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 des clés JWE et JWS avec Google. Les clés doivent être échangées au format JWK, comme défini dans rfc7517. Au cours de 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'aurez besoin d'échanger que les clés du 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.