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
Öffentliche PGP-Schlüssel, die Google zur Verfügung gestellt werden, 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 in 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 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 Produktionstests und der Einführung müssen Sie einen weiteren Austausch von Produktionsschlüsseln durchführen.
Neuen PGP-Schlüssel generieren
Wenn sich eine GPG-Binärdatei in Ihrem Systempfad befindet, 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 Gültigkeitsdauer 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“ertificate generation, Zertifikaterstellung) als auch ein Unterschlüssel (mit der Bezeichnung E für „E“ncryption, Verschlü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
- Beim Signieren sollten Sie
SHA384als Digest-Algorithmus verwenden. Verwenden Sie nichtSHA1oderMD5. - Beim Verschlüsseln sollten Sie
AES256als symmetrischen Verschlüsselungsalgorithmus verwenden. Verwenden Sie nichtCAST5oderIDEA. - Wenn Sie Nachrichten verschlüsseln oder signieren, wählen Sie den Unterschlüssel mit dem entsprechenden Zweck aus. Verwenden Sie den Schlüssel
CAN_SIGNzum Signieren und den SchlüsselENCRYPT_COMMS/ENCRYPT_STORAGEzum Verschlüsseln.
Nutzlasten empfangen
- Achten Sie beim Überprüfen einer Nutzlast darauf, dass Ihre Bibliothek moderne Hash-Algorithmen wie
SHA384unterstützt. Google verwendet ihn ab dem 14. Mai 2023 für alle neuen Schlüssel. - Achten Sie beim Entschlüsseln einer Nutzlast darauf, dass Ihre Bibliothek moderne symmetrische Verschlüsselungsalgorithmen wie
AES256unterstü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 sichere Optionen auswählen, wenn Sie GPG verwenden. Es wird davon ausgegangen, 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 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 der 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
- Im
algHeader angegeben (RFC7518, Abschnitt 4.1)
- Im
- Der A256GCM,
A128GCM,
A128CBC-HS256 oder
A256CBC-HS512
Algorithmus für die Inhaltsverschlüsselung
- Im Header
encangegeben
- Im Header
- Header
kidzur 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
- Im Header
algangegeben (RFC7518, Abschnitt 3.1)
- Im Header
- Header
kidzur 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 in einem Jahr ablaufen und eine maximale Lebensdauer von zwei Jahren haben. Alle Identitäten privater Schlüssel müssen sich immer auf dem Server des Partners befinden 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 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 Produktionstests und der Einführung müssen Sie einen weiteren Austausch von Produktionsschlüsseln durchführen.