PGP-Verschlüsselung
PGP ist ein Standardsatz von Verschlüsselungs-, Entschlüsselungs- und Signaturalgorithmen, die kryptografische Vertraulichkeit und Authentifizierung bieten.
Bei der Verschlüsselung von Nutzlasten mit PGP müssen Partner Folgendes unterstützen:
- Verschlüsselung und Entschlüsselung 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 mindestens 2048 Bit 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 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 den folgenden POSIX-Befehl verwenden, um ein neues Schlüsselpaar zu 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 „Signieren“ und „Zertifikatsgenerierung“) als auch ein Unterschlüssel (mit der Bezeichnung E für „Verschlüsselung“) erstellt werden.
PGP-Bibliothekskonfiguration
Nutzlasten senden
- Verwenden Sie beim Signieren
SHA384als Digest-Algorithmus. Verwenden Sie nichtSHA1oderMD5. - Verwenden Sie beim Verschlüsseln
AES256als symmetrischen Verschlüsselungsalgorithmus. Verwenden Sie nichtCAST5oderIDEA. - Wählen Sie beim Verschlüsseln oder Signieren von Nachrichten 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 wird ihn 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
AES256unterstützt. Google wird ihn ab dem 14. Mai 2023 für alle neuen Schlüssel verwenden.
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 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 Header
algenthalten (RFC7518, Abschnitt 4.1)
- Im Header
- Der A256GCM,
A128GCM,
A128CBC-HS256 oder
A256CBC-HS512
Algorithmus für die Inhaltsverschlüsselung
- Im Header
encenthalten
- 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
algHeader enthalten (RFC7518, Abschnitt 3.1)
- Im
- 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 dementsprechend müssen alle Signaturwerte 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.