Verschlüsselung auf Anwendungsebene

Standard-Zahlungs-APIs unterstützen entweder PGP oder JWE für die Verschlüsselung der Anwendungsschicht.

PGP-Verschlüsselung

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

Wenn Partner Nutzlasten mit PGP verschlüsseln, müssen sie Folgendes unterstützen:

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

An Google bereitgestellte öffentliche PGP-Schlüssel müssen einen Unterschlüssel für die Verschlüsselung haben. Der Unterschlüssel ermöglicht eine unabhängige Rotation vom Masterschlüssel. Der Masterschlüssel wird für die Identitätsbestätigung verwendet. Private Schlüssel müssen RSA-Schlüssel mit 2.048 Bit oder mehr sein, die in einem Jahr ablaufen und eine maximale Lebensdauer von zwei Jahren haben.

Bevor Sie mit der Entwicklung beginnen, müssen Sie PGP-Schlüssel mit Google austauschen. In diesem Schritt generieren Sie ein PGP-öffentliches/privates Schlüsselpaar, geben den öffentlichen Schlüssel an Google weiter und erhalten einen öffentlichen Schlüssel von Google 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 den Produktionstests und der Markteinführung müssen Sie die Produktionsschlüssel noch einmal austauschen.

Neuen PGP-Schlüssel generieren

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

$ gpg --full-generate-key

Wählen Sie auf Aufforderung einen RSA-Schlüssel mit mindestens 2.048 Bit Entropie und einer Gültigkeitsdauer von 1–2 Jahren aus. Mit diesem Befehl sollten sowohl ein Masterschlüssel (mit der Kennzeichnung „SC“, für „S“ignatur und „C“ertificate generation) als auch ein Unterschlüssel (mit der Kennzeichnung „E“, für „E“ncryption) erstellt werden.

PGP-Bibliothekskonfiguration

Nutzlasten senden

  1. Verwenden Sie bei der Signatur SHA384 als Hash-Algorithmus. Verwenden Sie nicht SHA1 oder MD5.
  2. Verwenden Sie bei der Verschlüsselung AES256 als symmetrischen Verschlüsselungsalgorithmus. Verwenden Sie nicht CAST5 oder IDEA.
  3. Achten Sie beim Verschlüsseln oder Signieren von Nachrichten darauf, den Unterschlüssel mit dem entsprechenden Zweck auszuwählen. 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 Verifizieren einer Nutzlast darauf, dass Ihre Bibliothek moderne Hash-Algorithmen wie SHA384 unterstützt. Google verwendet sie 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 sie ab dem 14. Mai 2023 auf allen neuen Schlüsseln.

Beispiel für die GPG-Nutzlastverschlüsselung

Der folgende Befehl ist ein Beispiel dafür, wie Sie sichere Optionen bei der Verwendung von GPG auswählen. Dieser Vorgang wird in einer vertrauenswürdigen Umgebung ausgeführt, in der Personen keinen Zugriff auf die privaten Schlüssel oder vertraulichen 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 für jeden Vorgang, den Sie ausführen lassen, automatisch den richtigen Schlüssel aus dem Bundle aus.

JWE-Verschlüsselung mit JWS-Signatur

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 Signatur von Inhalten auf Anwendungsebene definiert ist.

Anfragen und Antworten sind JWE-Token, die mit der Option „Kompakte Serialisierung“ mithilfe der asymmetrischen (Public-Key-)Verschlüsselung verschlüsselt werden. Das JWE-Token enthält die signierte Nutzlast als JWS-Token. JWS verwendet auch asymmetrische Schlüssel: einen privaten Schlüssel für die Signatur und einen öffentlichen Schlüssel für die Überprüfung.

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

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

  • Kompaktserialisierung.
  • Entschlüsseln von Nutzlasten mit einem von mehreren JWE-Schlüsseln
  • Der RSA-OAEP-, RSA-OAEP-256- oder ECDH-ES-Algorithmus für die Schlüsselverwaltung.
  • Der Algorithmus A256GCM, A128GCM, A128CBC-HS256 oder A256CBC-HS512 für die Inhaltsverschlüsselung.
    • Wird im enc-Header eingefügt.
  • kid-Header zur Identifizierung des öffentlichen Verschlüsselungsschlüssels.
  • Nachrichtennutzlasten, die die JWE-Verschlüsselung verwenden, müssen den Inhaltstyp „application/jose; charset=utf-8“ haben.

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

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

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

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

Bevor Sie mit der Entwicklung beginnen, 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, geben den öffentlichen Schlüssel an Google weiter und erhalten einen öffentlichen Schlüssel von Google 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 den Produktionstests und der Markteinführung müssen Sie die Produktionsschlüssel noch einmal austauschen.