Szyfrowanie PGP
PGP to standardowy zestaw algorytmów szyfrowania, odszyfrowywania i podpisywania, które zapewniają prywatność i uwierzytelnianie kryptograficzne.
Partnerzy korzystający ze standardu PGP do szyfrowania ładunków muszą obsługiwać:
- szyfrowanie i odszyfrowywanie ładunków za pomocą wielu kluczy PGP;
- podpisywanie ładunków za pomocą wielu kluczy PGP;
- weryfikowanie ładunków z wieloma podpisami, z których każdy może korzystać z klucza dostarczonego przez Google;
- odszyfrowywanie bezpiecznych dla sieci ładunków zakodowanych w standardzie base64.
Klucze publiczne PGP przekazywane do Google muszą mieć klucz podrzędny używany do szyfrowania. Klucz podrzędny umożliwia rotację niezależną od klucza głównego. Klucz główny służy do weryfikacji tożsamości. Klucze prywatne muszą być 2048-bitowymi (lub dłuższymi) kluczami RSA o rocznym terminie ważności i maksymalnie 2-letnim okresie użytkowania.
Przed rozpoczęciem programowania należy wymienić klucze PGP z Google. W tym celu należy wygenerować parę kluczy PGP (publiczny-prywatny), przekazać Google swój klucz publiczny i otrzymać klucz publiczny od Google. Podczas programowania wystarczy wymienić klucze piaskownicy używane do programowania i testowania poza produkcją. Przed testami produkcyjnymi i premierą musisz przeprowadzić kolejną wymianę kluczy produkcyjnych.
Generowanie nowego klucza PGP
Zakładając, że kod binarny PGP jest dostępny w ścieżce systemowej, do utworzenia nowej pary kluczy możesz użyć poniższego polecenia POSIX.
$ gpg --full-generate-key
Gdy pojawi się odpowiedni komunikat, wybierz klucz RSA o co najmniej 2048-bitowej entropii i terminie ważności od 1 do 2 lat. Polecenie to powinno utworzyć klucz główny (oznaczony SC: Signing and Certificate generation – podpisywanie i generowanie certyfikatów) oraz klucz podrzędny (oznaczony E: Encryption – szyfrowanie).
Konfiguracja biblioteki PGP
Wysyłanie ładunków
- Podczas podpisywania pliku należy użyć algorytmu
SHA384
. Nie używaj algorytmuSHA1
aniMD5
. - W przypadku szyfrowania użyj algorytmu szyfrowania symetrycznego
AES256
. Nie używaj algorytmuCAST5
aniIDEA
. - W przypadku szyfrowania lub podpisywania wiadomości pamiętaj, aby wybrać klucz podrzędny o odpowiednim przeznaczeniu. Użyj klucza
CAN_SIGN
do podpisywania i kluczaENCRYPT_COMMS
/ENCRYPT_STORAGE
do szyfrowania
Odbieranie ładunków
- Weryfikując ładunek, sprawdź, czy Twoja biblioteka obsługuje nowoczesne algorytmy haszujące, takie jak
SHA384
. Od 14 maja 2023 r. Google będzie używać go we wszystkich nowych kluczach. - Odszyfrowując ładunek, sprawdź, czy Twoja biblioteka obsługuje nowoczesne algorytmy szyfrowania symetrycznego, takie jak
AES256
. Od 14 maja 2023 r. Google będzie używać go we wszystkich nowych kluczach.
Przykład szyfrowania ładunku GPG
Poniżej znajdziesz przykład wyboru bezpiecznych opcji w GPG. Ta operacja powinna być przeprowadzana w zaufanym środowisku, w którym użytkownicy nie mają dostępu do kluczy prywatnych ani poufnych plików wejściowych.
gpg --output signed-and-encrypted.pgp \
--sign --digest-algo SHA384 \
--encrypt --cipher-algo AES256 \
--armor \
--recipient {key_id} \
input.txt
GPG automatycznie wybierze właściwy klucz dla pakietu w przypadku każdej operacji, którą chcesz wykonać.
Szyfrowanie JWE przy użyciu podpisywania JWS
JWE (JSON Web Encryption) to standard zdefiniowany w rfc7516 służący do szyfrowania treści na poziomie aplikacji. Podpis internetowy JSON (JWS) to standard zdefiniowany w rfc7515 na potrzeby podpisywania treści na poziomie aplikacji.
Żądania i odpowiedzi będą szyfrowane za pomocą tokenów JWE przy użyciu algorytmu asymetrycznego (klucz publiczny) i opcji „Kompaktowa serializacja”. Token JWE będzie zawierać podpisany ładunek w postaci tokena JWS. W standardzie JWS również używane są klucze asymetryczne: klucz prywatny do podpisywania i klucz publiczny do weryfikacji.
Podczas wysyłania ładunku najpierw podpisz go, a potem zaszyfruj. Po otrzymaniu ładunku najpierw odszyfruj go, a potem zweryfikuj podpis.
Partnerzy korzystający ze standardu JWE muszą obsługiwać te opcje:
- Kompaktowa serializacja.
- odszyfrowywanie ładunków z jednego z wielu kluczy JWE,
- algorytmy RSA-OAEP, RSA-OAEP-256 lub ECDH-ES do zarządzania kluczem.
- Wypełniany w nagłówku
alg
(rfc7518 sekcja 4.1).
- Wypełniany w nagłówku
- algorytm A256GCM,
A128GCM,
A128CBC-HS256 lub
A256CBC-HS512 do szyfrowania treści.
- Wypełniany w nagłówku
enc
.
- Wypełniany w nagłówku
kid
, aby zidentyfikować klucz publiczny szyfrowania.- Ładunki komunikatów, które używają szyfrowania JWE, muszą korzystać z treści typu application/jose; charset=utf-8.
Aby weryfikować ładunki przy użyciu tokena JWS, partnerzy muszą obsługiwać te opcje:
- Kompaktowa serializacja.
- weryfikowanie ładunków z jednego z wielu kluczy JWS,
- Algorytm HS256, HS384, HS512, RS256, RS384, RS512, ES256, PS256, PS384 lub PS512 do tworzenia podpisów.
- Wypełniany w nagłówku
alg
(rfc 7518 sekcja 3.1).
- Wypełniany w nagłówku
- nagłówek
kid
, aby zidentyfikować klucz prywatny do podpisywania.
Ciągi JWE/JWS są kodowane jako ciągi znaków UTF-8, a ich ładunki mogą być dowolnymi bajtami.
Klucze prywatne muszą być kluczami RSA/ECDH-ES o rocznym terminie ważności i maksymalnie dwuletnim okresie użytkowania. Wszystkie tożsamości kluczy prywatnych muszą zawsze pozostawać na serwerze partnera, a tym samym wszystkie wartości podpisu muszą być obliczane na serwerze partnera.
Przed rozpoczęciem programowania należy wymienić klucze JWE i JWS z Google. Klucze należy wymieniać w formacie JWK, zgodnie z definicją w dokumencie rfc7517. W tym celu należy wygenerować parę kluczy publiczny-prywatny, przekazać Google swój klucz publiczny i otrzymać klucz publiczny od Google. Podczas programowania wystarczy wymienić klucze piaskownicy używane do programowania i testowania poza produkcją. Przed testami produkcyjnymi i premierą musisz przeprowadzić kolejną wymianę kluczy produkcyjnych.