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 kryptografischen Datenschutz und Authentifizierung ermöglichen.

Wenn Partner PGP zum Verschlüsseln von Nutzlasten verwenden, müssen sie Folgendes unterstützen:

  • Nutzlasten mit mehreren PGP-Schlüsseln verschlüsseln und entschlüsseln
  • Nutzlasten mit mehreren PGP-Schlüsseln signieren.
  • Verifizieren einer Nutzlast mit mehreren Signaturen, von denen jede die Signatur mit dem von Google bereitgestellten Schlüssel sein kann.
  • Entschlüsselung websicherer base64-codierter Nutzlasten.

Öffentliche PGP-Schlüssel, die Google bereitgestellt werden, 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 zur Identitätsüberprüfung 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 die PGP-Schlüssel mit Google austauschen. In diesem Schritt generieren Sie ein Paar aus öffentlichem und privatem PGP-Schlüssel, stellen Google den öffentlichen Schlüssel bereit und erhalten von Google einen öffentlichen Schlüssel zurück. Während der Entwicklung müssen Sie nur die Sandbox-Schlüssel austauschen, die Sie außerhalb der Produktion für Entwicklung und Tests verwendet haben. Vor dem Produktionstest und der Einführung müssen Sie die Produktionsschlüssel noch einmal austauschen.

Neuen PGP-Schlüssel generieren

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

$ gpg --full-generate-key

Wenn Sie dazu aufgefordert werden, wählen Sie einen RSA-Schlüssel mit mindestens 2.048 Bit Entropie und einer Ablaufzeit von 1–2 Jahren aus. Dieser Befehl sollte sowohl einen Masterschlüssel (mit dem Label SC, für 'S'igning and 'C'ertificate Generation) als auch einen Unterschlüssel (mit E, für 'Verschlüsselung) bezeichnet.

PGP-Bibliothekskonfiguration

Nutzlasten senden

  1. Verwenden Sie beim Signieren SHA384 als Digest-Algorithmus und nicht SHA1 oder MD5.
  2. Beim Verschlüsseln sollten Sie AES256 als Algorithmus für die symmetrische Verschlüsselung verwenden. Verwenden Sie nicht CAST5 oder IDEA.
  3. Wenn Sie Nachrichten verschlüsseln oder signieren, müssen Sie den Unterschlüssel mit dem entsprechenden Zweck auswählen. Verwenden Sie den CAN_SIGN-Schlüssel zum Signieren und den ENCRYPT_COMMS/ENCRYPT_STORAGE-Schlüssel zum Verschlüsseln.

Empfang von Nutzlasten

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

Beispiel für die Verschlüsselung der GPG-Nutzlast

Der folgende Befehl ist ein Beispiel dafür, wie sichere Optionen bei der Verwendung von GPG ausgewählt werden. 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 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 automatisch den richtigen Schlüssel aus dem Bundle für jeden Vorgang aus, den es ausführen soll.

JWE-Verschlüsselung mit JWS-Signatur

JSON Web Encryption (JWE) ist ein von rfc7516 definierter Standard für die Verschlüsselung von Inhalten auf Anwendungsebene. Die JSON Web Signature (JWS) ist ein von rfc7515 definierter Standard zum Signieren von Inhalten auf Anwendungsebene.

Anfragen und Antworten werden als JWE-Tokens verschlüsselt und mit der Option „Compact Serialization“ mit einem asymmetrischen (öffentlichen Schlüssel) verschlüsselt. Das JWE-Token enthält die signierte Nutzlast als JWS-Token. JWS verwendet auch asymmetrische Schlüssel: den privaten Schlüssel zum Signieren und den öffentlichen Schlüssel für die Verifizierung.

Signieren Sie beim Senden einer Nutzlast zuerst die Nutzlast und verschlüsseln Sie sie dann. Wenn Sie eine Nutzlast erhalten, entschlüsseln Sie diese und prüfen Sie dann die Signatur.

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

  • Kompakte Serialisierung.
  • Entschlüsseln von Nutzlasten aus 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, um den öffentlichen Verschlüsselungsschlüssel zu identifizieren.
  • Nachrichtennutzlasten mit JWE-Verschlüsselung müssen den Inhaltstyp "application/jose" (charset=utf-8) haben.

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

  • Kompakte Serialisierung.
  • Nutzlasten von 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, um den privaten Signaturschlüssel zu identifizieren.

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 in einem Jahr mit einer maximalen Lebensdauer von zwei Jahren ablaufen. Alle Identitäten mit privatem Schlüssel müssen immer auf dem Server des Partners bleiben. Dementsprechend müssen alle Signaturwerte auf dem Server des Partners berechnet werden.

Bevor Sie mit der Entwicklung beginnen, müssen Sie die 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 Paar aus öffentlichem und privatem Schlüssel, stellen Google den öffentlichen Schlüssel bereit und erhalten von Google einen öffentlichen Schlüssel zurück. Während der Entwicklung müssen Sie nur die Sandbox-Schlüssel austauschen, die Sie außerhalb der Produktion für Entwicklung und Tests verwendet haben. Vor dem Produktionstest und der Einführung müssen Sie die Produktionsschlüssel noch einmal austauschen.