Verschlüsselung auf Anwendungsebene

Standard Payments APIs unterstützen entweder PGP oder JWE für die Verschlüsselung auf Anwendungsebene.

PGP-Verschlüsselung

PGP ist ein Standardsatz von Verschlüsselungs-, Entschlüsselungs- und Signaturalgorithmen, die kryptografische Vertraulichkeit und Authentifizierung bieten.

Bei der Verwendung von PGP zum Verschlüsseln von Nutzlasten müssen Partner Folgendes unterstützen:

  • Verschlüsseln und Entschlüsseln von Nutzlasten mit mehreren PGP-Schlüsseln
  • Signieren von Nutzlasten mit mehreren PGP-Schlüsseln
  • Überprüfen einer Nutzlast mit mehreren Signaturen, von denen eine die Signatur mit dem von Google bereitgestellten Schlüssel sein kann
  • Entschlüsselung von websicheren, mit Base64 codierten Nutzlasten

Die an Google übermittelten öffentlichen PGP-Schlüssel müssen einen Unterschlüssel für die Verschlüsselung haben. Der Unterschlüssel ermöglicht eine unabhängige Rotation vom Primärschlüssel. Der Primärschlüssel wird zur Identitätsüberprüfung verwendet. Private Schlüssel müssen RSA-Schlüssel mit 2048 Bit (oder mehr) sein, die nach einem Jahr ablaufen und eine maximale Lebensdauer von zwei Jahren haben.

Vor Beginn der Entwicklung müssen Sie PGP-Schlüssel mit Google austauschen. In diesem Schritt generieren Sie ein öffentliches/privates PGP-Schlüsselpaar, stellen Google den öffentlichen Schlüssel zur Verfügung und erhalten von Google einen öffentlichen Schlüssel zurück. Während der Entwicklung müssen Sie nur Sandbox-Schlüssel austauschen, die für die Entwicklung und Tests außerhalb der Produktion verwendet werden. Vor Produktionstests und der Einführung müssen Sie einen weiteren Austausch von Produktionsschlüsseln durchführen.

Neuen PGP-Schlüssel generieren

Wenn Sie eine GPG-Binärdatei in Ihrem Systempfad haben, können Sie mit dem folgenden POSIX-Befehl ein neues Schlüsselpaar erstellen.

$ gpg --full-generate-key

Wählen Sie bei Aufforderung einen RSA-Schlüssel mit mindestens 2048 Bit Entropie und einer Ablaufzeit von ein bis zwei Jahren aus. Mit diesem Befehl sollten sowohl ein Primärschlüssel (mit der Bezeichnung SC für „S“ignieren und „C“ertifikatgenerierung) als auch ein Unterschlüssel (mit der Bezeichnung E für „E“ntschlüsselung) erstellt werden.

Schlüsselrotation

Um einen ununterbrochenen Dienst während der Schlüsselrotation zu gewährleisten, unterstützt das System mehrere aktive PGP-Schlüssel für Partner und Google.

  • Sie können Nutzlasten während der Rotation sowohl mit alten als auch mit neuen Schlüsseln signieren. Google überprüft die Signatur anhand aller aktiven öffentlichen Schlüssel, die Google gespeichert hat.

  • Wenn Sie Ihre öffentlichen Google-Schlüssel rotieren müssen, können Sie Nutzlasten sowohl mit alten als auch mit neuen öffentlichen Google-Schlüsseln verschlüsseln. Google kann mit beiden Schlüsseln entschlüsseln.

  • PGP-Schlüssel-IDs in der Nachricht selbst ermöglichen die automatische Schlüsselidentifizierung, sodass keine Felder für die Nutzlastversion oder koordinierte Umstellungs zeiten erforderlich sind.

PGP-Bibliothekskonfiguration

Nutzlasten senden

  1. Verwenden Sie beim Signieren SHA384 als Digest-Algorithmus. Verwenden Sie nicht SHA1 oder MD5.
  2. Verwenden Sie beim Verschlüsseln AES256 als symmetrischen Verschlüsselungsalgorithmus. Verwenden Sie nicht CAST5 oder IDEA.
  3. Wählen Sie beim Verschlüsseln oder Signieren von Nachrichten den Unterschlüssel mit dem entsprechenden Zweck aus. Verwenden Sie den Schlüssel CAN_SIGN zum Signieren und den Schlüssel ENCRYPT_COMMS/ENCRYPT_STORAGE zum Verschlüsseln.

Nutzlasten empfangen

  1. Achten Sie beim Überprüfen einer Nutzlast darauf, dass Ihre Bibliothek moderne Hash-Algorithmen wie SHA384 unterstützt. Google verwendet ihn ab dem 14. Mai 2023 für alle neuen Schlüssel.
  2. Achten Sie beim Entschlüsseln einer Nutzlast darauf, dass Ihre Bibliothek moderne symmetrische Verschlüsselungsalgorithmen wie AES256 unterstützt. Google verwendet ihn ab dem 14. Mai 2023 für alle neuen Schlüssel.

Beispiel für die GPG-Nutzlastverschlüsselung

Der folgende Befehl ist ein Beispiel dafür, wie Sie bei der Verwendung von GPG sichere Optionen auswählen. Es wird erwartet, dass dieser Vorgang in einer vertrauenswürdigen Umgebung ausgeführt wird, in der Personen keinen Zugriff auf die privaten Schlüssel oder sensiblen Eingabedateien haben.

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

GPG wählt automatisch den richtigen Schlüssel aus dem Bundle für jeden Vorgang aus, den Sie ausführen möchten.

JWE-Verschlüsselung mit JWS-Signierung

JSON Web Encryption (JWE) ist ein Standard, der in rfc7516 für die Verschlüsselung von Inhalten auf Anwendungsebene definiert ist. JSON Web Signature (JWS) ist ein Standard, der in rfc7515 für die Signierung von Inhalten auf Anwendungsebene definiert ist.

Anfragen und Antworten sind JWE-Tokens, die mit asymmetrischer (öffentlicher Schlüssel) Verschlüsselung mit der Option „Compact Serialization“ verschlüsselt werden. Das JWE-Token enthält die signierte Nutzlast als JWS-Token. JWS verwendet auch asymmetrische Schlüssel: einen privaten Schlüssel zum Signieren und einen öffentlichen Schlüssel zur Überprüfung.

Signieren Sie beim Senden einer Nutzlast zuerst die Nutzlast und verschlüsseln Sie sie dann. Entschlüsseln Sie beim Empfangen einer Nutzlast zuerst die Nutzlast und überprüfen Sie dann die Signatur.

Bei der Verwendung von JWE müssen Partner die folgenden Optionen unterstützen:

  • Compact Serialization
  • Entschlüsseln von Nutzlasten mit einem von mehreren JWE-Schlüsseln
  • Der Algorithmus RSA-OAEP, RSA-OAEP-256 oder ECDH-ES für die Schlüsselverwaltung
  • Der A256GCM, A128GCM, A128CBC-HS256 oder A256CBC-HS512 Algorithmus für die Inhaltsverschlüsselung
    • Wird im Header enc angegeben.
  • Header kid zur Identifizierung des öffentlichen Verschlüsselungsschlüssels
  • Für Nachrichten-Nutzlasten, die die JWE-Verschlüsselung verwenden, muss der Inhaltstyp „application/jose; charset=utf-8“ verwendet werden.

Bei der Verwendung von JWS müssen Partner die folgenden Optionen unterstützen:

  • Compact Serialization
  • Überprüfen von Nutzlasten mit einem von mehreren JWS-Schlüsseln
  • Der Algorithmus HS256, HS384, HS512, RS256, RS384, RS512, ES256, PS256, PS384 oder PS512 für die Signaturerstellung
  • Header kid zur Identifizierung des privaten Signaturschlüssels

JWE/JWS-Strings werden als UTF-8-Strings codiert und ihre Nutzlasten können beliebige Byte sein.

Private Schlüssel müssen RSA-/ECDH-ES-Schlüssel sein, die nach einem Jahr ablaufen und eine maximale Lebensdauer von zwei Jahren haben. Alle Identitäten privater Schlüssel müssen immer auf dem Server des Partners verbleiben und alle Signaturwerte müssen auf dem Server des Partners berechnet werden.

Vor Beginn der Entwicklung müssen Sie JWE- und JWS-Schlüssel mit Google austauschen. Schlüssel sollten im JWK-Format ausgetauscht werden, wie in rfc7517 definiert. In diesem Schritt generieren Sie ein öffentliches/privates Schlüsselpaar, stellen Google den öffentlichen Schlüssel zur Verfügung und erhalten von Google einen öffentlichen Schlüssel zurück. Während der Entwicklung müssen Sie nur Sandbox-Schlüssel austauschen, die für die Entwicklung und Tests außerhalb der Produktion verwendet werden. Vor Produktionstests und der Einführung müssen Sie einen weiteren Austausch von Produktionsschlüsseln durchführen.