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
- Verwenden Sie beim Signieren
SHA384
als Digest-Algorithmus und nichtSHA1
oderMD5
. - Beim Verschlüsseln sollten Sie
AES256
als Algorithmus für die symmetrische Verschlüsselung verwenden. Verwenden Sie nichtCAST5
oderIDEA
. - 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 denENCRYPT_COMMS
/ENCRYPT_STORAGE
-Schlüssel zum Verschlüsseln.
Empfang von Nutzlasten
- 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. - 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.
- Wird im
alg
-Header eingetragen (rfc7518-Abschnitt 4.1).
- Wird im
- Der Algorithmus A256GCM, A128GCM, A128CBC-HS256 oder A256CBC-HS512 für die Inhaltsverschlüsselung.
- Wird im
enc
-Header eingefügt.
- Wird im
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.
- Wird im
alg
-Header eingetragen (rfc 7518 section 3.1).
- Wird im
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.