LPI Security Essentials (Moduł 022.3) – OpenPGP czy S/MIME

Zanim zaczniesz

Ten artykuł jest częścią serii „Bezpłatny Kurs LPI Security Essentials”, w ramach której znajdziesz wszystko, co potrzeba, aby zdać egzamin LPI Security Essentials 020-100 już za pierwszym razem.

Każdy moduł zawiera praktyczne przykłady, wyjaśnienia i materiały pomocnicze – wszystko po polsku, zrozumiale i konkretnie.

Wybór, konfiguracja i najczęstsze problemy

Poczta elektroniczna pozostaje jednym z podstawowych narzędzi komunikacji, zarówno dla użytkowników indywidualnych, jak i organizacji. Standardowe wiadomości e-mail są jednak przesyłane otwartym tekstem (lub jedynie szyfrowane na poziomie transportu, np. TLS), co oznacza, iż ich treść może zostać odczytana lub przechwycona przez niepowołane osoby – np. administratorów serwerów pocztowych czy hakerów. Ponadto zwykły e-mail nie daje odbiorcy pewności co do tożsamości nadawcy ani integralności wiadomości (czyli tego, iż nie została zmodyfikowana w trakcie przesyłania).

Szyfrowanie end-to-end poczty e-mail rozwiązuje te problemy, zapewniając poufność korespondencji oraz możliwość cyfrowego podpisania wiadomości w celu uwierzytelnienia nadawcy. Istnieją dwa główne standardy realizujące szyfrowanie i podpisywanie e-maili: OpenPGP (otwarty standard wywodzący się z programu Pretty Good Privacy) oraz S/MIME (Secure/Multipurpose Internet Mail Extensions, oparty na certyfikatach X.509 i infrastrukturze klucza publicznego). Oba standardy funkcjonują od lat 90. i oferują podobny zakres ochrony, ale różnią się podejściem do modelu zaufania, sposobem dystrybucji kluczy oraz integracją z programami pocztowymi.

W poniższym artykule dokonamy porównania OpenPGP i S/MIME – omówimy modele zaufania (web of trust vs hierarchia CA), różnice między podpisywaniem a szyfrowaniem wiadomości, a także przedstawimy konfigurację krok po kroku: od generowania i zarządzania kluczami, przez ich import, eksport, rotację i kopie zapasowe, aż po integrację z popularnymi narzędziami (np. Mozilla Thunderbird z dodatkiem Enigmail, wbudowana obsługa OpenPGP, Microsoft Outlook). Opiszemy typowe problemy, jakie mogą napotkać użytkownicy – związane z weryfikacją tożsamości nadawcy, dystrybucją kluczy oraz interoperacyjnością między różnymi systemami – i podpowiemy, jak je rozwiązywać. Na koniec zaprezentujemy rekomendacje, kiedy warto używać którego rozwiązania, zarówno z perspektywy organizacji, jak i użytkownika prywatnego.

Zapraszamy do lektury – bezpieczeństwo poczty e-mail to temat, którym warto się zainteresować, by chronić swoją komunikację przed nieuprawnionym dostępem.

Modele zaufania: OpenPGP vs S/MIME

Jedną z kluczowych różnic między OpenPGP a S/MIME jest sposób, w jaki budowane jest zaufanie do kluczy używanych do szyfrowania i podpisywania. Oba systemy opierają się na kryptografii asymetrycznej (parze kluczy: publicznego i prywatnego), ale różnią się metodą weryfikacji tożsamości posiadacza klucza:

OpenPGP i zdecentralizowana sieć zaufania (Web of Trust)

OpenPGP korzysta z modelu zaufania zdecentralizowanego, nazywanego web of trust (siecią zaufania). W praktyce oznacza to, iż nie istnieje centralny urząd ani instytucja potwierdzająca tożsamość użytkowników. Zamiast tego użytkownicy sami weryfikują i poświadczają klucze innych osób:

• Każdy użytkownik OpenPGP generuje własną parę kluczy: publiczny (do udostępniania innym) i prywatny (do zachowania w tajemnicy). Klucz publiczny zwykle zawiera tzw. identyfikator użytkownika (User ID), na który składa się adres e-mail właściciela i opcjonalnie jego imię/nazwa.
• Gdy dwie osoby chcą się komunikować, wymieniają się nawzajem kluczami publicznymi (np. wysyłając je mailem, udostępniając na stronie internetowej lub dzięki specjalnych serwerów kluczy).
• Weryfikacja tożsamości odbywa się poprzez sprawdzenie tzw. odcisku palca (fingerprint) klucza – jest to unikalny ciąg znaków identyfikujący klucz. Najbezpieczniej jest zweryfikować fingerprint osobiście lub przez zaufany kanał (np. telefonicznie, komunikator szyfrowany), upewniając się, iż klucz faktycznie należy do danej osoby.
• Po zweryfikowaniu, użytkownik może podpisać cudzy klucz publiczny swoim kluczem prywatnym. Takie podpisanie klucza stanowi zapewnienie: „Uwierzytelniłem, iż ten klucz należy do osoby X”. Podpisy kluczy tworzą sieć powiązań – jeżeli ufam kluczowi osoby A, a ona podpisała klucz osoby B, mogę z pewnym zaufaniem przyjąć, iż klucz B jest prawidłowy (w zależności od lokalnych ustawień zaufania).
• Ten właśnie system wzajemnych podpisów i zaufania transitywnego tworzy web of trust. Każdy użytkownik samodzielnie decyduje, którym kluczom ufa i w jakim stopniu. Nie ma tu autorytetu nadrzędnego – zaufanie jest “oddolne” i anarchiczne: może Pan/Pani wierzyć dowolnym kluczom na podstawie własnego osądu lub sieci powiązań.

W praktyce model OpenPGP wymaga od użytkowników więcej świadomości i pracy. Trzeba zadbać o wymianę kluczy, ich weryfikację oraz zarządzanie zaufaniem (np. w programie GnuPG można oznaczyć poziom zaufania do kluczu lub podpisać klucz innych). Zaletą jest pełna kontrola – nie trzeba polegać na żadnej zewnętrznej instytucji. Wady to pewna złożoność UX: początkujący użytkownicy często nie rozumieją, dlaczego muszą “ufać” kluczowi lub jak potwierdzić cudzy fingerprint.

Dystrybucja kluczy OpenPGP odbywa się zwykle poprzez:

• Serwery kluczy publicznych – istnieją publiczne serwisy (tzw. keyservers), gdzie można wgrać swój klucz publiczny, aby inni mogli go łatwo znaleźć. Przykładem są servery SKS (obecnie zastępowane przez np. keys.openpgp.org). Użytkownicy mogą wyszukać klucz po adresie e-mail. Warto zaznaczyć, iż serwery kluczy nie weryfikują tożsamości – są jedynie otwartą książką adresową; w praktyce każdy może wgrać dowolny klucz ze sfałszowanym adresem e-mail. Dlatego klucze znalezione na serwerach zawsze należy weryfikować (np. kontaktując się z właścicielem innym kanałem) przed ich użyciem.
• Bezpośrednią wymianę – klucz publiczny można przekazać jako plik (np. z rozszerzeniem .asc) lub choćby w formie tekstowej (tzw. blok ASCII armored) poprzez dowolny komunikator. Popularną praktyką jest dołączenie klucza publicznego do pierwszej korespondencji lub opublikowanie go na swojej stronie WWW/GitHubie itp.
• Autocrypt – warto wspomnieć, iż nowsze implementacje OpenPGP w klientach pocztowych (np. Thunderbird, K-9 Mail) wprowadziły mechanizm Autocrypt, który automatycznie dołącza publiczny klucz do nagłówka każdej wysyłanej wiadomości i pozwala klientom na automatyczny import. Autocrypt upraszcza wymianę kluczy dla mniej zaawansowanych użytkowników, aczkolwiek zaufanie przez cały czas opiera się na tym, iż komunikujemy się z tego samego adresu e-mail (weryfikacja odcisku poza pasmem przez cały czas jest zalecana przy wysokich wymaganiach bezpieczeństwa).

Podsumowując, OpenPGP (GnuPG) daje dużą niezależność i jest darmowe oraz szeroko stosowane w społecznościach open-source, wśród administratorów i entuzjastów bezpieczeństwa. Model sieci zaufania pozwala na anonimowe lub pseudonimowe użycie (można wygenerować klucz do dowolnego adresu e-mail, choćby nieistniejącego, choć praktyczność takiego klucza jest ograniczona). Wadą jest konieczność manualnej weryfikacji i brak uniwersalnego, automatycznego uznawania czyjegoś klucza za “godny zaufania” bez własnej ingerencji.

S/MIME i hierarchiczna infrastruktura zaufania (PKI)

W przeciwieństwie do OpenPGP, standard S/MIME opiera się na scentralizowanym modelu zaufania wykorzystującym Infrastrukturę Klucza Publicznego (PKI). Tutaj rolę zaufanych pośredników pełnią urzędy certyfikacji (CA – Certificate Authority). W praktyce wygląda to następująco:

• Użytkownik, który chce korzystać z S/MIME, musi uzyskać certyfikat cyfrowy powiązany ze swoim adresem e-mail. Certyfikat to nic innego jak publiczny klucz użytkownika opatrzony podpisem cyfrowym wystawcy (CA). W certyfikacie zapisane są dane identyfikacyjne właściciela (co najmniej adres e-mail, często imię i nazwisko lub nazwa firmy) oraz okres ważności i informacje o wystawcy.
• Urząd certyfikacji (CA) działa jak notariusz: przed wydaniem certyfikatu weryfikuje tożsamość osoby lub przynajmniej weryfikuje kontrolę nad adresem e-mail. Dla podstawowych certyfikatów osobistych często wystarcza potwierdzenie mailowe (wysyłany jest link lub kod na dany adres e-mail). Bardziej zaawansowane certyfikaty (np. certyfikaty kwalifikowane lub firmowe) mogą wymagać osobistego potwierdzenia tożsamości, dokumentów, itp.
• Po pomyślnej weryfikacji CA wystawia certyfikat użytkownika, podpisując go swoim kluczem prywatnym. Tak powstaje łańcuch zaufania: skoro system/oprogramowanie ufa kluczowi publicznemu CA (a lista zaufanych urzędów jest zwykle wbudowana w system operacyjny lub program pocztowy), to będzie ufać również certyfikatowi użytkownika podpisanemu przez to CA. Innymi słowy: wiarygodność tożsamości użytkownika jest “poręczona” przez instytucję trzecią.
• S/MIME zakłada istnienie hierarchii zaufania: na górze są Root CA (najbardziej zaufane, ich certyfikaty są samopodpisane i preinstalowane w systemach), które wydają certyfikaty pośrednie (Intermediate CA), a te dopiero wystawiają certyfikaty końcowe użytkownikom. Dzięki temu można unieważnić (revoke) jedno CA pośrednie bez unieważniania całej hierarchii.
• Dystrybucja kluczy publicznych w S/MIME odbywa się zwykle automatycznie poprzez same wiadomości: gdy użytkownik A wyśle do B podpisaną cyfrowo wiadomość S/MIME, to w jej nagłówkach/załączniku znajdzie się certyfikat A (zawierający klucz publiczny A). Program pocztowy B zwykle automatycznie zapisze certyfikat A w swojej bazie (o ile jest poprawny i wystawiony przez zaufane CA). W efekcie, aby zacząć szyfrować do kogoś mail S/MIME, często wystarczy raz otrzymać od tej osoby mail podpisany cyfrowo. Nie ma potrzeby manualnego szukania kluczy po serwerach – zaufanie opiera się tu na tym, iż certyfikat został wydany przez znaną, zaufaną instytucję.
• Każdy certyfikat S/MIME ma określony okres ważności (np. rok, dwa lata). Po tym czasie musi zostać odnowiony (nowy certyfikat). Również w razie podejrzenia kompromitacji klucza prywatnego certyfikat można unieważnić (CA ogłasza certyfikat jako cofnięty, umieszczając jego numer seryjny na liście CRL – Certificate Revocation List – lub oznaczając go jako revoked w protokole OCSP). Programy pocztowe mogą sprawdzać status certyfikatu (choć bywa to zależne od konfiguracji).

Zaletą modelu S/MIME jest łatwość użycia dla końcowego użytkownika w typowych scenariuszach biznesowych: większość popularnych klientów (Outlook, Thunderbird, Apple Mail, urządzenia mobilne) posiada wbudowaną obsługę S/MIME i automatycznie ufa certyfikatom od uznanych urzędów. Użytkownik nie musi sam zarządzać zaufaniem do poszczególnych kluczy – robi to za niego lista zaufanych CA. jeżeli np. certyfikat mailowy został wystawiony przez DigiCert, a DigiCert jest na liście zaufanych głównych wystawców w systemie Windows/macOS, to podpis cyfrowy nadawcy zostanie automatycznie uznany za prawidłowy. Gdy nadawca wyśle zaszyfrowany mail, a odbiorca ma swój certyfikat w programie, odszyfrowanie nastąpi automatycznie (o ile klucz prywatny jest dostępny i hasło do niego zostało podane wcześniej lub zapisane).

Wady S/MIME wynikają z zależności od zewnętrznych podmiotów:

• Koszt i dostępność: niektóre urzędy certyfikacji pobierają opłaty za certyfikaty S/MIME (szczególnie te weryfikujące tożsamość osoby/firmy). Istnieją co prawda darmowe certyfikaty S/MIME dla użytku osobistego (np. oferowane niegdyś przez Comodo, w tej chwili Sectigo, czy przez CA Certum dla niekomercyjnych zastosowań), ale ich uzyskanie wymaga rejestracji i okresowej aktualizacji. Organizacje często uruchamiają własne wewnętrzne CA lub korzystają z korporacyjnych rozwiązań PKI, aby wydawać certyfikaty pracownikom – wiąże się to z infrastrukturą do utrzymania.
• Zaufanie do CA: użytkownik końcowy musi ufać, iż urzędy certyfikacji działają poprawnie. Istnieje (teoretyczne) ryzyko, iż jakiś złamany lub złośliwy CA wyda certyfikat do adresu e-mail, do którego nie powinien (np. na czyjeś nazwisko bez autoryzacji). W przeszłości zdarzały się incydenty z fałszywymi certyfikatami (choć dotyczyły głównie certyfikatów SSL/TLS dla domen). Model PKI zakłada jednak mechanizmy kontroli – przeglądy bezpieczeństwa CA, certyfikacje – więc dla większości zastosowań biznesowych jest to akceptowalne ryzyko. Niemniej, krytycy nazywają ten model zaufania „oligarchią” – musimy ufać ograniczonemu gronu kilkuset instytucji na świecie, iż żadna z nich nas nie zawiedzie.
• Mniejsza anonimowość: certyfikat S/MIME z definicji zawiera dane identyfikujące. jeżeli ktoś chciałby wysyłać maile anonimowo, uzyskanie certyfikatu od CA pod pseudonimem może być trudne (chyba iż CA nie weryfikuje tożsamości poza adresem e-mail – wtedy certyfikat i tak będzie zawierał ten adres). OpenPGP pozwala na pełną dowolność w nazywaniu klucza (można np. mieć klucz „Jan Kowalski jan@example.com” albo „Anon Ymous anon@nym.xyz”), natomiast S/MIME certyfikat będzie zwykle zawierał prawdziwe imię i nazwisko lub nazwę firmy (w zależności od rodzaju certyfikatu).

Podsumowanie porównania modeli zaufania:

• OpenPGP/Web of Trust: Zaufanie zdecentralizowane, kontrolowane przez użytkowników. Plusy: brak zależności od trzeciej strony, pełna kontrola, darmowe narzędzia. Minusy: wymaga edukacji i manualnego weryfikowania/ufania kluczom; nowi użytkownicy mogą mieć problem ze skonfigurowaniem poprawnie.
• S/MIME/PKI: Zaufanie hierarchiczne, oparte na certyfikatach od uznanych wystawców. Plusy: automatyczna weryfikacja podpisów i łatwiejsza obsługa w typowych klientach pocztowych; dobre rozwiązanie dla firm z infrastrukturą IT. Minusy: konieczność uzyskania certyfikatu (co bywa płatne lub biurokratyczne), zaufanie delegowane na zewnętrzne podmioty, certyfikaty mają ograniczony okres ważności.

W obu przypadkach klucze/kcertyfikaty są powiązane z adresem e-mail właściciela. W OpenPGP użytkownik może mieć w jednym kluczu wiele identyfikatorów (np. kilka adresów e-mail przypisanych do tej samej pary kluczy) lub generować osobne klucze dla różnych adresów. W S/MIME zwykle każdy adres e-mail wymaga osobnego certyfikatu, choć zdarzają się certyfikaty multi-domain dla kilku adresów tej samej osoby. Ważne jest, iż programy pocztowe sprawdzają zgodność adresu nadawcy z informacją w kluczu/certyfikacie: jeżeli np. spróbujemy podpisać e-mail kluczem, którego UID nie zawiera naszego adresu, albo certyfikatem wystawionym dla innego e-maila – pojawi się błąd lub ostrzeżenie.

Podpisywanie a szyfrowanie wiadomości

Szyfrowanie i podpisywanie cyfrowe to dwa odrębne mechanizmy, które często są używane łącznie, ale pełnią różne role:

• Szyfrowanie wiadomości e-mail – polega na tym, iż nadawca przekształca treść wiadomości dzięki klucza publicznego odbiorcy tak, iż staje się ona nieczytelna dla nikogo poza docelowym odbiorcą. Tylko właściciel odpowiadającego klucza prywatnego (czyli zwykle tylko zamierzony odbiorca) może odszyfrować treść i ją odczytać. Celem szyfrowania jest poufność – ochrona treści przed nieautoryzowanym dostępem. choćby jeżeli ktoś przechwyci zaszyfrowany e-mail, zobaczy jedynie ciąg pozornie losowych znaków lub zaszyfrowany załącznik, którego nie da się zrozumieć bez klucza prywatnego.
• Podpisywanie cyfrowe wiadomości – polega na dołączeniu do wiadomości unikalnego podpisu wygenerowanego kluczem prywatnym nadawcy. Ten podpis może zostać zweryfikowany przez odbiorcę przy użyciu klucza publicznego nadawcy (w OpenPGP) lub certyfikatu nadawcy (w S/MIME). Poprawny cyfrowy podpis świadczy o dwóch rzeczach: iż wiadomość rzeczywiście została wysłana przez danego nadawcę (uwierzytelnienie tożsamości) oraz iż jej treść nie została zmieniona po podpisaniu (integralność). choćby drobna zmiana w treści powoduje niezgodność podpisu i klient pocztowy ostrzeże, iż podpis jest nieprawidłowy. W skrócie: podpisanie e-maila gwarantuje “autentyczność” wiadomości – wiemy, kto ją wysłał i iż dotarła nienaruszona.

Ważne jest zrozumienie, iż podpisanie wiadomości nie szyfruje jej treści, a zaszyfrowanie wiadomości nie oznacza automatycznie jej podpisania. Są to dwie odrębne operacje kryptograficzne:

• Możemy wysłać e-mail tylko podpisany (jawny dla wszystkich, ale z dołączonym podpisem cyfrowym). Taki e-mail może przeczytać każdy, kto go przechwyci, ale odbiorca ma możliwość sprawdzenia podpisu i upewnienia się, iż np. naprawdę pochodzi od naszego adresu. Przykład zastosowania: wysyłamy oficjalne ogłoszenie lub komunikat do szerokiego grona – nie jest to tajna treść, ale chcemy, by odbiorcy mogli zweryfikować, iż wiadomość nie jest sfałszowana przez osobę podszywającą się pod nas. W klientach pocztowych podpisana wiadomość jest zwykle oznaczona ikonką „pieczęci” lub „wstążki”. jeżeli wszystko jest w porządku, zobaczymy komunikat typu „Podpis cyfrowy jest prawidłowy”. jeżeli coś jest nie tak (np. nie ufamy certyfikatowi nadawcy albo podpis się nie zgadza), pojawi się ostrzeżenie.
• Możemy wysłać e-mail tylko zaszyfrowany (bez podpisu). W takim przypadku treść będzie poufna, ale odbiorca po odszyfrowaniu nie ma gwarancji, kto dokładnie ją zaszyfrował – widzi tylko odszyfrowaną treść i wie, iż ktoś, kto miał dostęp do jego klucza publicznego, ją wysłał. W praktyce w korespondencji osobistej szyfrowanie bez podpisu występuje rzadko, bo nic nie kosztuje dołożenie podpisu, a daje dodatkową pewność. Jednak czasem ktoś może celowo nie chcieć ujawniać swojej tożsamości (np. anonimowy informator może zaszyfrować wiadomość do dziennikarza używając jego klucza publicznego, ale nie podpisywać swoim kluczem – wtedy odbiorca otrzyma anonimowy, ale poufny przekaz). W przypadku braku podpisu, programy pocztowe zwykle informują tylko, iż wiadomość została odszyfrowana; nie ma informacji o nadawcy poza polem „From:”, które przecież można sfałszować.
• Wiadomość zarówno zaszyfrowana, jak i podpisana – to najlepsza praktyka dla prywatnej korespondencji. W takim mailu najpierw treść jest podpisywana kluczem prywatnym nadawcy, a potem całość (treść + podpis) szyfrowana kluczem publicznym odbiorcy. Efekt: tylko odbiorca odczyta treść, a po odszyfrowaniu jego program sprawdzi podpis i potwierdzi tożsamość nadawcy. Zarówno OpenPGP, jak i S/MIME umożliwiają jednoczesne szyfrowanie i podpisywanie, i zwykle klienci pocztowi mają opcję “Szyfruj tę wiadomość” oraz osobno “Dołącz podpis cyfrowy”. Można włączyć obie na raz.

Technicznie, podpisywanie i szyfrowanie przebiega podobnie w OpenPGP i S/MIME, ale są inne formaty:

• W OpenPGP podpisana wiadomość (bez szyfrowania) może być np. w formie clear-sign (wiadomość w postaci czytelnego tekstu z dołączonym blokiem -----BEGIN PGP SIGNATURE-----), albo podpis może być dołączony jako osobny załącznik .sig (przy użyciu PGP/MIME). Wiadomość szyfrowana OpenPGP jest zwykle przesyłana jako zaszyfrowany blok tekstu lub załącznik .asc (PGP/MIME), a klient e-mail integruje się z GnuPG, by to odszyfrować.
• W S/MIME podpisana wiadomość dołącza podpis w postaci załącznika .p7s (Cryptographic Signature), a zaszyfrowana wiadomość staje się załącznikiem .p7m (Cryptographic Message). Dla użytkownika interfejs jest prosty: np. w Outlooku lub Thunderbirdzie pojawia się ikona podpisu lub kłódki, a cała obsługa formatu dzieje się w tle.

Jak rozpoznać podpisany lub zaszyfrowany e-mail? Z perspektywy odbiorcy:

• Jeśli e-mail jest podpisany, nasz klient (Thunderbird, Outlook itd.) zwykle wyświetli informację o cyfrowym podpisie. Np. w Thunderbirdzie w pasku nad treścią pojawi się komunikat „Podpis cyfrowy jest prawidłowy. Certyfikat nadawcy jest zaufany.” (dla S/MIME) lub „Podpis OpenPGP prawidłowy. Klucz publiczny w pierścieniu kluczy.” (dla PGP). Gdy nie mamy klucza/certyfikatu nadawcy, zobaczymy komunikat typu „Nie można zweryfikować podpisu – brak klucza” lub „Podpis jest niezaufany”.
• Jeśli e-mail jest zaszyfrowany, to jego zawartość nie będzie od razu widoczna – klient zapyta nas o hasło do naszego klucza prywatnego (o ile nie zostało już zapisane). Po poprawnym odszyfrowaniu treść zostanie ukazana, a zwykle pojawi się też informacja „Wiadomość została odszyfrowana”. jeżeli wiadomość była jednocześnie podpisana, ta informacja będzie połączona z wynikiem weryfikacji podpisu.

Podsumowując: szyfrowanie zapewnia poufność, a podpisanie autentyczność i integralność. Warto stosować oba naraz, jeżeli zależy nam na pełnym zabezpieczeniu korespondencji. Same podpisy są użyteczne, gdy chcemy potwierdzić tożsamość nadawcy bez ukrywania treści (np. newslettery, oferty handlowe – odbiorca wie na pewno, iż przyszły od adekwatnej firmy, bo podpis się zgadza). Same szyfrowanie bez podpisu bywa rzadko stosowane, chyba iż istnieje powód, by ukryć tożsamość nadawcy.

Dla początkujących istotne jest, by nie mylić podpisu cyfrowego z popularnym pojęciem „podpisu e-mail” (stopki) – podpis cyfrowy jest niewidoczny w samej treści (to zaszyfrowany skrót wiadomości dołączony jako dane), natomiast stopka e-mail to po prostu tekst/obrazek dodawany do wiadomości. Podpis cyfrowy również nie ma związku z graficznym odręcznym podpisem – nie trzeba nigdzie odręcznie podpisywać maila. Wszystko odbywa się automatycznie przez oprogramowanie kryptograficzne.

Generowanie i zarządzanie kluczami szyfrującymi

Aby zacząć korzystać z szyfrowania i podpisów, pierwszym krokiem jest wygenerowanie własnej pary kluczy (w przypadku OpenPGP) lub uzyskanie certyfikatu (w przypadku S/MIME). Następnie trzeba skonfigurować swój program pocztowy do używania tych kluczy/certyfikatów. W tej sekcji przedstawiamy kroki generowania i podstawy zarządzania kluczami, z praktycznymi przykładami wykorzystania GnuPG (najpopularniejszej implementacji OpenPGP) oraz klienta poczty Mozilla Thunderbird. Opiszemy także, jak zdobyć certyfikat S/MIME dla swojego adresu.

Generowanie kluczy OpenPGP (GnuPG, Thunderbird)

OpenPGP (PGP) to standard, a GnuPG (GPG) to konkretne darmowe narzędzie/program implementujący ten standard. GnuPG jest dostępny na większości platform (domyślnie w systemach Linux/Unix, do pobrania dla Windows i macOS). Można go używać z linii poleceń lub za pośrednictwem interfejsów graficznych/plug-inów w klientach poczty.

Generowanie klucza dzięki GnuPG (wersja tekstowa):

1. Instalacja GnuPG – na Linuksie prawdopodobnie jest już zainstalowany (gpg --version aby sprawdzić). Na Windows można zainstalować pakiet Gpg4win, a na macOS np. GPG Suite lub przez Homebrew (brew install gnupg).
2. Uruchomienie kreatora kluczy – w terminalu wydaj polecenie: gpg --full-generate-key (Polecenie --full-generate-key daje pełną kontrolę nad parametrami klucza; jest też uproszczone gpg --generate-key z domyślnymi ustawieniami).
3. Wybór parametrów klucza – kreator zapyta o typ kluczy i algorytmy. Domyślnie proponuje RSA (klucz RSA może służyć zarówno do podpisywania, jak i szyfrowania). Można wybrać np. opcję (1) RSA and RSA. Alternatywnie nowoczesnym wyborem jest klucz ECC (krzywe eliptyczne, np. Curve25519) – wtedy wybieramy opcję oznaczoną jako ECC (jeśli dostępna). W kontekście LPI i kompatybilności, RSA 3072-bit lub 4096-bit jest często wybierane.
4. Długość klucza – w przypadku RSA podajemy długość w bitach. Minimalnie 2048, zalecane 3072 lub 4096 bit. Im dłuższy, tym bezpieczniejszy, ale też wolniejszy (choć dla e-mail to nieistotne) i generowany dłużej.
5. Okres ważności klucza – warto ustawić datę wygaśnięcia klucza (np. 1 rok, 2 lata, 5 lat) lub zaznaczyć „no expiration” (bezterminowo). Klucz z terminem ważności wymusza później przedłużenie lub rotację, co jest dobrą praktyką bezpieczeństwa. Np. można ustawić 2 lata – po tym czasie klucz publiczny stanie się nieważny, chyba iż przed upływem tego czasu wydamy polecenie przedłużenia ważności.
6. Wprowadzenie identyfikatora użytkownika – kreator poprosi o imię i nazwisko (Name), adres e-mail i opcjonalnie komentarz. Te informacje zostaną zapisane jako User ID naszego klucza. Można tu wpisać np. „Jan Kowalski” i jan.kowalski@przyklad.pl. Ważne: adres e-mail powinien być takim, z którego będziemy wysyłać zaszyfrowane/podpisane maile, aby klient poczty go dopasował. (Można później dodać kolejne adresy do klucza).
7. Hasło (passphrase) do klucza prywatnego – na koniec klucz jest generowany i program poprosi o ustawienie hasła chroniącego klucz prywatny. To bardzo istotny krok: należy wybrać silne hasło, które uniemożliwi dostęp do klucza prywatnego osobom postronnym. Hasło to będzie wymagane za każdym razem, gdy użyjemy klucza prywatnego (np. do odszyfrowania maila lub podpisania czegoś), chyba iż aplikacja zapamięta hasło w swojej pamięci po wpisaniu (Thunderbird pozwala zapisać hasło klucza w tzw. menedżerze haseł systemowych, aby nie pytać za każdym razem).
8. Zakończenie i sprawdzenie – po podaniu hasła GnuPG wygeneruje losowo klucz (zazwyczaj prosząc o poruszanie myszką lub inną akcję zwiększającą entropię na komputerze). Gdy proces się zakończy, klucz zostanie zapisany w naszym pierścieniu kluczy (keyring) w katalogu domowym (np. ~/.gnupg/ na Linuksie). Możemy wyświetlić listę kluczy poleceniem: gpg --list-keys Powinien się tam pojawić nasz nowo utworzony klucz, z informacją o UID (imieniu i mailu) oraz identyfikatorze klucza (krótkim i długim). Warto od razu zanotować odcisk palca klucza (fingerprint) – pokaże go polecenie: gpg --fingerprint adres_email Fingerprint to ciąg 40 znaków szesnastkowych (dla RSA) pogrupowanych po 4, służący do weryfikacji tożsamości klucza.

Przykładowe polecenia GnuPG (podsumowanie):

• gpg --full-generate-key – interaktywne wygenerowanie nowej pary kluczy OpenPGP.
• gpg --list-keys – wyświetlenie listy posiadanych publicznych kluczy w lokalnej bazie (naszych i cudzych, jeżeli importowaliśmy).
• gpg --list-secret-keys – wyświetlenie posiadanych kluczy prywatnych (sekretnych) – powinniśmy widzieć tu nasz nowy klucz.
• gpg --edit-key "UID" – edycja klucza (np. by dodać kolejny adres e-mail jako UID, zmienić hasło, zmienić datę ważności, oznaczyć zaufanie do innego klucza itp.).
• gpg --armor --export adres_email > mykey_public.asc – eksport klucza publicznego do pliku ASCII (wysyłamy go znajomym, publikujemy).
• gpg --armor --export-secret-keys adres_email > mykey_private.asc – eksport klucza prywatnego (zaszyfrowanego hasłem) do pliku ASCII – tylko do kopii zapasowej, nie udostępniamy nikomu.
• gpg --armor --export-secret-subkeys adres_email > subkey.asc – eksport samych kluczy podrzędnych (bez głównego klucza certyfikującego) – bardziej zaawansowane zastosowanie, np. gdy chcemy używać subkluczy na innym urządzeniu.
• gpg --recv-keys KEYID – pobranie (import) klucza publicznego z serwera kluczy po identyfikatorze.
• gpg --send-keys KEYID – wysłanie naszego klucza publicznego na serwer kluczy.
• gpg --gen-revoke KEYID – wygenerowanie certyfikatu unieważnienia dla naszego klucza (o tym w sekcji o rotacji kluczy).

Generowanie klucza OpenPGP w kliencie pocztowym (na przykładzie Thunderbird):

Jeśli nie chcemy używać konsoli, wiele programów oferuje graficzne kreatory. Mozilla Thunderbird (od wersji 78+ posiada wbudowaną obsługę OpenPGP, wcześniej wymagał dodatku Enigmail) umożliwia wygenerowanie klucza dla danego konta e-mail w kilku krokach:

1. Otwórz ustawienia konta w Thunderbirdzie i przejdź do sekcji End-To-End Encryption (Szyfrowanie end-to-end) dla wybranego konta e-mail. (W polskiej wersji: Ustawienia konta -> Szyfrowanie end-to-end).
2. Zobaczysz informację, czy masz klucz OpenPGP przypisany do tego konta. jeżeli nie, kliknij przycisk “Dodaj klucz…”.
   (Uwaga: jeżeli używasz starej wersji TB z Enigmail, kreator może wyglądać inaczej – Enigmail miał własne menu “Klucze” -> “Generuj nową parę kluczy”. Poniższe dotyczy natywnej funkcji TB 78+.)
3. Thunderbird zapyta, czy utworzyć nowy klucz czy zaimportować istniejący. Wybieramy Utwórz nowy klucz i kontynuujemy.
4. Pojawi się okno z ustawieniami klucza: wybieramy dla którego adresu (tożsamości) generujemy klucz (powinien być wypełniony nasz adres e-mail konta), następnie algorytm i rozmiar klucza oraz datę wygaśnięcia. Thunderbird domyślnie może proponować nowoczesny algorytm ECC (Curve25519) lub RSA. jeżeli zależy nam na kompatybilności, można wybrać RSA 3072 lub 4096-bit. Ustawiamy np. ważność: 3 lata i rozmiar: 4096 bit.
5. Klikamy “Wygeneruj klucz”. Pojawi się ostrzeżenie, iż proces może potrwać (kilka do kilkudziesięciu sekund, w zależności od rozmiaru klucza i mocy CPU). Potwierdzamy.
6. Ustawienie hasła do klucza: Thunderbird zapyta o hasło (fraza szyfrująca) do zabezpieczenia klucza prywatnego. Podajemy silne hasło i zapisujemy je (lub zapamiętujemy – Thunderbird może zaoferować zapisanie w menedżerze haseł systemowych dla wygody).
7. Po zakończeniu generowania zobaczymy komunikat o sukcesie. Nowy klucz automatycznie zostanie przypisany do naszego konta – w ustawieniach End-to-End Encryption powinna być informacja o ID klucza i data ważności. Thunderbird zaznaczy też opcję, by domyślnie używać tego klucza do szyfrowania/podpisywania (możemy to zmienić, ale zwykle chcemy to zostawić).
8. Weryfikacja: Możemy otworzyć Menedżer kluczy OpenPGP w Thunderbirdzie (Menu -> Narzędzia -> OpenPGP -> Zarządzaj kluczami OpenPGP). Powinien tam widnieć nasz nowy klucz (ze statusami Ultimate trust dla własnego klucza). Tam też można wykonać dodatkowe czynności, jak eksport klucza publicznego, utworzenie certyfikatu unieważnienia, zmiana daty ważności itp.

Po tych krokach mamy wygenerowany klucz PGP i możemy zacząć podpisywać oraz odszyfrowywać wiadomości w Thunderbirdzie. Podczas tworzenia nowej wiadomości pojawiły nam się opcje w oknie komponowania: ikona kłódki (szyfrowanie) i ikona stempla (podpis cyfrowy). Możemy je załączać wedle potrzeb. Thunderbird może także automatycznie podpisywać wszystkie wysyłane wiadomości (to ustawienie w preferencjach konta).

Uwaga: jeżeli używasz starszej wersji Thunderbirda (np. ESR 68) z dodatkiem Enigmail – proces wygląda nieco inaczej:

• Należy najpierw zainstalować dodatek Enigmail, potem w jego kreatorze wskazać, czy instalujemy GnuPG (na Windows) i utworzyć klucz podobnie jak wyżej (Enigmail Guide prowadzi przez generowanie RSA 4096).
• Enigmail w starszych TB dodawał własne menu do komponowania wiadomości i zarządzania kluczami. W TB 78+ Enigmail już nie działa – funkcjonalność jest wbudowana.

Podsumowując, wygenerowanie klucza OpenPGP sprowadza się do kilku kroków i podania podstawowych danych. Po wygenerowaniu nasz klucz publiczny jest gotowy do rozdania znajomym/współpracownikom, a klucz prywatny należy chronić hasłem i nigdzie nie udostępniać.

Uzyskanie certyfikatu S/MIME (X.509)

Dla S/MIME musimy uzyskać certyfikat przypisany do naszego adresu e-mail od zaufanego urzędu certyfikacji (CA). W przeciwieństwie do OpenPGP, gdzie klucze generujemy sami i od razu możemy używać, w S/MIME potrzebujemy pośrednictwa zewnętrznego – aczkolwiek proces podstawowy również nie jest skomplikowany:

1. Wybór urzędu certyfikacji: jeżeli działasz w organizacji, możliwe iż firma posiada własną infrastrukturę certyfikatów i wystawi Ci certyfikat służbowy. W innym przypadku możesz skorzystać z usług komercyjnych lub darmowych:
   • Przykładowi dostawcy oferujący darmowe certyfikaty e-mail (klasy podstawowej, Domain Validation) to m.in. Sectigo (dawniej Comodo) czy Actalis. Zwykle darmowe certyfikaty są ważne rok i trzeba je co rok odnawiać.
   • Polski urząd Certum oferował niedrogi certyfikat e-mail kwalifikowany (rozpoznawany przez programy, ale wymagał weryfikacji tożsamości przez e-dowód lub osobiście).
   • Można też poszukać opcji trial lub wydać niewielką kwotę na certyfikat klasy Basic u różnych dostawców SSL (często certyfikat S/MIME bywa dodawany jako opcja).
2. Wygenerowanie żądania i klucza: Certyfikat X.509 wymaga posiadania klucza prywatnego i żądania certyfikacyjnego (CSR). Często odbywa się to automatycznie przez przeglądarkę – np. rejestrując się na stronie CA, podajesz swój email i ewentualnie imię/nazwisko, a przeglądarka (np. poprzez wtyczkę ActiveX, w przypadku Windows/IE) sama wygeneruje klucz i wyśle CSR. Uwaga: W takim przypadku klucz prywatny może zostać wygenerowany w magazynie systemowym przeglądarki.
   • Alternatywnie, można samemu wygenerować klucz i CSR np. dzięki OpenSSL lub certutil, i wysłać CSR do CA. To podejście bardziej techniczne – większość użytkowników użyje raczej metody automatycznej.
   • Przykład generowania klucza i CSR OpenSSL (tylko dla zaawansowanych ciekawostka): openssl req -newkey rsa:2048 -nodes -keyout mail.key -out mail.csr -subj "/CN=Jan Kowalski/emailAddress=jan.kowalski@przyklad.pl" To wygeneruje plik mail.key (klucz prywatny) i mail.csr (żądanie zawierające klucz publiczny i dane).
3. Weryfikacja e-maila: CA przed wydaniem certyfikatu zweryfikuje, czy masz kontrolę nad adresem e-mail. Najczęściej wysyłają na ten adres wiadomość z unikalnym linkiem lub kodem weryfikacyjnym. Musisz kliknąć link lub wpisać kod na stronie CA, potwierdzając tym samym, iż odbierasz pocztę pod danym adresem. (Jeśli proces inicjowałeś z otrzymanej promocji/wiadomości, może to być już zintegrowane).
4. Odebranie certyfikatu: po pomyślnej weryfikacji, CA wystawia certyfikat. Zwykle otrzymasz e-mail z załączonym certyfikatem (.cer, .pem, .p7s lub link do pobrania). Czasem, jeżeli generowałeś klucz przez przeglądarkę, certyfikat może automatycznie zaimportować się do magazynu certyfikatów przeglądarki/systemu – warto czytać instrukcje od CA.
   • Jeżeli otrzymałeś plik .cer/.crt – to jest certyfikat publiczny. Aby był użyteczny, musimy mieć także klucz prywatny. jeżeli generacja klucza była w przeglądarce, klucz prywatny jest w Twoim systemie (np. w Windows w magazynie osobistym certyfikatów). Wtedy można bezpośrednio eksportować certyfikat z kluczem do pliku PFX/P12.
   • Jeżeli generowałeś poza przeglądarką (np. własny CSR), to masz klucz prywatny w pliku (np. mail.key z powyższego przykładu) i otrzymany certyfikat .cer. Musisz scalić je, importując do klienta poczty lub systemu.
5. Import certyfikatu do programu pocztowego:
   • Thunderbird: Otwórz Ustawienia -> Zaawansowane -> Certyfikaty -> Pokaż certyfikaty. Przejdź na kartę Twoje certyfikaty i kliknij Importuj…. Wskaż plik .p12 lub .pfx zawierający Twój certyfikat razem z kluczem prywatnym. (Jeśli masz osobno .cer i .key, najpierw użyj narzędzia openssl aby stworzyć .pfx: openssl pkcs12 -export -inkey mail.key -in mail.cer -out mail.pfx, podając hasło eksportu). Po imporcie certyfikatu (Thunderbird zapyta o hasło, jeżeli plik .p12 był zabezpieczony) powinieneś zobaczyć go na liście. Następnie w Ustawieniach konta -> Szyfrowanie end-to-end (S/MIME) wybierz ten certyfikat jako certyfikat do podpisywania i szyfrowania dla tego konta. Od tej pory Thunderbird będzie mógł podpisywać maile S/MIME i odszyfrowywać odebrane (jeśli do nas ktoś wyśle zaszyfrowany).
   • Outlook (Windows): Outlook korzysta z magazynu certyfikatów Windows. Najpierw więc w systemie Windows zainstaluj certyfikat: kliknij dwukrotnie plik .p12/.pfx, uruchomi się kreator importu certyfikatów. Importuj go do magazynu Osobisty (Personal) bieżącego użytkownika. Podaj hasło, zaznacz opcję, by oznaczyć klucz jako eksportowalny (na wszelki wypadek) i zakończ. Potem w Outlooku wejdź w Opcje -> Centrum zaufania -> Zabezpieczenia poczty e-mail. W sekcji S/MIME lub Szyfrowanie znajdziesz przyciski Wybierz certyfikat dla podpisywania i dla szyfrowania. Wybierz swój nowo importowany certyfikat. Możesz zaznaczyć opcję, by domyślnie podpisywać wszystkie wychodzące wiadomości. Zamknij opcje. Teraz podczas pisania wiadomości w karcie Opcje powinieneś mieć przyciski Podpisz wiadomość cyfrowo i Szyfruj.
   • Inne programy: Apple Mail korzysta z pęku kluczy systemowego macOS – wystarczy dodać certyfikat do pęku (podwójny klik w .p12, import do login keychain), a Mail automatycznie go wykryje. Na iPhone/iPad można wysłać sobie .p12 i otworzyć, system zapyta o instalację profilu z certyfikatem. Klient mobilny Nine czy FairEmail na Androidzie mają swoje mechanizmy importu (.p12).
6. Test: Spróbuj wysłać do siebie samego maila, zaznaczając podpis S/MIME i szyfrowanie. jeżeli wszystko jest poprawnie skonfigurowane, uda Ci się wysłać (Outlook poprosi ewentualnie o wybranie certyfikatu odbiorcy – w tym wypadku Twojego, który już jest zainstalowany). Odbierając tę wiadomość, powinna się ona automatycznie odszyfrować i pokazać, iż podpis jest prawidłowy.

Widzimy, iż konfiguracja S/MIME jest nieco bardziej złożona na etapie uzyskania certyfikatu, ale sama integracja z klientem pocztowym bywa prostsza w użyciu (automatyczne rozpoznawanie certyfikatów nadawców, mniej ręcznych kroków przy codziennym użyciu).

Kilka dobrych praktyk przy uzyskiwaniu certyfikatu S/MIME:

• Jeśli to certyfikat prywatny, wygeneruj go z kluczem prywatnym na swoim komputerze, nie np. w chmurze. Większość CA i tak robi to po stronie klienta, ale upewnij się, iż masz kontrolę nad kluczem prywatnym. To tak samo wrażliwy klucz jak w PGP – jak ktoś go zdobędzie i hasło do niego, może Cię podszywać i odszyfrowywać Twoje maile.
• Zrób kopię zapasową .pfx i przechowuj w bezpiecznym miejscu (o kopiach niżej).
• Sprawdź, czy certyfikat obejmuje dokładnie Twój adres e-mail (często jest pole RFC822 Name w polu Subject Alternative Name certyfikatu). jeżeli tak, tylko ten adres będzie akceptowany do podpisów – nie użyjesz go do innego e-maila.
• W przyszłości, przed upływem ważności certyfikatu, odnow go lub zdobądź nowy, żeby ciągłość podpisów była zachowana (stary i tak może służyć do odszyfrowywania starych wiadomości, ale nie podpiszesz nim nowych po wygaśnięciu).

Zarządzanie kluczami i certyfikatami w praktyce

Po wygenerowaniu lub uzyskaniu kluczy przychodzi czas na faktyczne zarządzanie nimi: trzeba wymieniać się kluczami z korespondentami, importować cudze klucze/certyfikaty, regularnie aktualizować lub rotować własne klucze oraz zadbać o kopie zapasowe. Ta część bywa najtrudniejsza dla nowych użytkowników, dlatego omawiamy ją krok po kroku w następnym rozdziale.

Import, eksport, rotacja i kopie zapasowe kluczy

Skuteczne używanie OpenPGP czy S/MIME wymaga kilku czynności administracyjnych związanych z kluczami kryptograficznymi. W tej sekcji opisujemy, jak importować i eksportować klucze, na czym polega rotacja kluczy (i kiedy jest potrzebna) oraz jak tworzyć kopie zapasowe kluczy/certyfikatów, aby nie utracić dostępu do zaszyfrowanej poczty.

Importowanie i eksportowanie kluczy publicznych oraz certyfikatów

Udostępnienie innym swojego klucza publicznego (OpenPGP):

• Po wygenerowaniu pary kluczy OpenPGP musimy przekazać nasz klucz publiczny tym, którzy mają do nas pisać szyfrowane wiadomości lub weryfikować nasze podpisy. Eksport klucza publicznego dzięki GnuPG pokazaliśmy wcześniej (gpg --export -a > plik.asc). Można też w Thunderbirdzie kliknąć na własnym kluczu -> Eksportuj klucze publiczne, aby zapisać plik .asc.
• Tak otrzymany plik (ASCII-armored, zaczynający się od -----BEGIN PGP PUBLIC KEY BLOCK-----) wysyłamy np. jako załącznik e-mail do znajomego, publikujemy na swoim profilu, stronie WWW lub wrzucamy na serwer keyserver (np. dzięki gpg --send-keys).
• Uwaga: Nigdy nie publikuj swojego klucza prywatnego! Czasem nowicjusz może pomylić pliki – upewnij się, iż plik z kluczem publicznym ma w nagłówku PUBLIC KEY BLOCK, a nie PRIVATE KEY. Klucz prywatny trzymamy tylko dla siebie (ew. robimy backupy offline).

Importowanie cudzego klucza publicznego (OpenPGP):

• Gdy otrzymasz od kogoś plik .asc z kluczem publicznym (albo znajdziesz na jego stronie czy na serwerze), musisz go dodać do swojego keyring-u, aby móc użyć. W Thunderbirdzie z włączoną obsługą OpenPGP często program sam wykryje załącznik *.asc i zaproponuje import. Możesz też manualnie: Narzędzia -> Otwórz menedżer kluczy OpenPGP -> Plik -> Importuj klucze OpenPGP i wskazać plik.
• W GnuPG: gpg --import plik.asc. Po imporcie sprawdź gpg --list-keys, czy klucz wskoczył.
• Pamiętaj, iż import klucza nie oznacza automatycznego zaufania mu. W modelu web of trust, zaimportowany klucz domyślnie ma poziom zaufania „Unknown” lub „Undefined”. jeżeli jest to klucz znajomego i potwierdziłeś odcisk palca, możesz użyć gpg --edit-key i polecenia trust aby oznaczyć go jako „I trust ultimately” (ostatecznie ufam tej osobie) lub na odpowiednim poziomie. Alternatywnie możesz podpisać jego klucz swoim (co jest lepsze, bo wtedy inni też zobaczą Twój podpis przy kluczu tej osoby).
• W kontekście e-mail, Thunderbird i tak pozwoli Ci szyfrować do niezweryfikowanego klucza (ale ostrzeże przy podpisach, jeżeli nadawca nie jest zaufany). Możesz również w Thunderbirdzie wybrać opcję Zaufaj temu kluczowi po imporcie, co ustawia najwyższy poziom zaufania.

Udostępnienie certyfikatu S/MIME:

• Tutaj sytuacja jest prostsza: tak naprawdę nie musisz manualnie wysyłać swojego certyfikatu większości odbiorców – zrobisz to wysyłając do nich pierwszą podpisaną mailowo wiadomość. Gdy oni odbiorą, ich klient poczty automatycznie doda Twój certyfikat do kontaktu/kluczy.
• Możesz jednak wysłać certyfikat manualnie: np. wyeksportuj swój cert z Thunderbirda (w managerze certyfikatów -> Eksportuj, dostaniesz .cer) i prześlij komuś. Odbiorca może dwuklikiem dodać do systemu lub do TB -> Import certyfikatów -> Inne osoby.
• W środowisku korporacyjnym czesto istnieje katalog lub lista adresów z certyfikatami (np. Active Directory może przechowywać certyfikaty S/MIME pracowników, widoczne w Outlooku globalnej książce adresowej). W takim razie dystrybucja jest automatyczna.

Import cudzego certyfikatu S/MIME:

• Jak wyżej, zwykle dzieje się to automatycznie przy odbiorze podpisanego maila. jeżeli jednak np. współpracownik podaje Ci swój certyfikat na pendrive (.cer albo .p7c zawierający ich łańcuch certyfikatów), możesz go:
  • Zainstalować w systemie (Windows: PPM na plik .cer -> Zainstaluj certyfikat -> do magazynu Osoby inne lub do folderu Kontakty).
  • W Thunderbirdzie: Ustawienia -> Certyfikaty -> Pokaż -> zakładka Osoby (Other People) -> Importuj, wskazujesz plik .cer. Trafi na listę z nazwą tej osoby.
• Po imporcie cudzego certyfikatu będziesz mógł szyfrować do tej osoby (o ile certyfikat jest prawidłowy i zaufany). jeżeli certyfikat był od nieznanego CA, może być konieczne także importowanie certyfikatu tego CA (zakładka Urząd certyfikacji w managerze certyfikatów Thunderbird, lub zainstalowanie w zaufanych głównych w systemie). Inaczej program powie „podpis niezweryfikowany – brak zaufanego wystawcy”, co jednak nie przeszkodzi w szyfrowaniu, ale pokaże ostrzeżenia przy podpisach.

Eksport własnego certyfikatu z kluczem (na inny komputer):

• Gdy zaczynamy korzystać z szyfrowania na wielu urządzeniach, np. chcemy mieć możliwość odszyfrowywania maili na laptopie i na komputerze stacjonarnym, musimy przenieść nasze klucze/certyfikaty:
  • W przypadku OpenPGP: eksportujemy klucz prywatny (gpg --export-secret-keys lub w Thunderbird: OpenPGP -> Backup Secret Key). Otrzymany plik (zwykle .asc lub .gpg) przenosimy na drugi komputer (bezpiecznie!) i tam importujemy (gpg --import dla secret keys, TB: w managerze kluczy -> Importuj klucz prywatny). Pamiętajmy, iż klucz prywatny jest chroniony hasłem, więc choćby jakby ktoś przechwycił ten plik, musi złamać hasło (dlatego hasło musi być silne).
  • W przypadku S/MIME: eksportujemy pliki .p12 (zawierające nasz certyfikat i klucz) z jednego urządzenia i importujemy na drugim. Np. w Windows: w mmc certyfikatów osobistych -> nasz cert -> Eksportuj -> zaznacz „export private key”, podaj hasło i zapisz .pfx. Potem na drugim PC import .pfx. W Thunderbird: na zakładce Twoje certyfikaty -> zaznacz cert -> Backup… (to stworzy .p12 z hasłem). Na drugim TB: Importuj w Twoje certyfikaty (podając hasło).
• Nigdy nie przenoś klucza/certyfikatu w postaci otwartej (niezaszyfrowanej) przez niezaufane kanały. Najlepiej użyć np. pendrive zaszyfrowanego, lub przesłać sobie plik .pfx e-mailem ale sam plik dodatkowo zabezpieczony mocnym hasłem i przekazanym innym kanałem.

Rotacja kluczy i unieważnianie (revocation)

Rotacja kluczy oznacza okresową lub wymuszoną zmianę kluczy kryptograficznych na nowe. Sprowadza się do wygenerowania nowej pary kluczy (lub uzyskania nowego certyfikatu) i zaprzestania używania starej, przy jednoczesnym poinformowaniu kontaktów o zmianie. Rotacja bywa zalecana z kilku powodów:

• Data ważności: jeżeli Twój klucz OpenPGP miał ustawioną datę wygaśnięcia, zbliżając się do tego terminu możesz albo wydłużyć ważność (np. poleceniem gpg --edit-key i expire ustawić nową datę – wymaga to rozesłania zaktualizowanego klucza publicznego do kontaktów/na serwer) albo wygenerować nowy klucz i zacząć go używać. Wielu użytkowników PGP przedłuża ważność istniejącego klucza, o ile nie ma powodu go zmieniać – zachowuje wtedy ciągłość identyfikatora i podpisów. Inni preferują co kilka lat tworzyć nowy klucz dla bezpieczeństwa (np. by użyć nowszego algorytmu albo ograniczyć skutki ewentualnego przyszłego złamania starego klucza).
• Kompromitacja klucza: jeżeli podejrzewasz, iż Twój klucz prywatny mógł wyciec lub zostać złamany (np. laptop został skradziony wraz z kluczami, a hasło mogło zostać złamane), należy natychmiast przestać używać starego klucza i go unieważnić. W OpenPGP robi się to poprzez certyfikat unieważnienia (revocation certificate): jest to specjalny plik wygenerowany twoim kluczem prywatnym (warto stworzyć go zawczasu i trzymać na czarną godzinę). jeżeli musisz unieważnić klucz, importujesz ten certyfikat unieważnienia do swojego keyring-u i wysyłasz go na serwery kluczy – w ten sposób wszyscy dowiedzą się, iż danemu kluczowi już nie należy ufać. Po unieważnieniu, generujesz nową parę kluczy i dystrybuujesz nowy klucz publiczny do swoich kontaktów.
• Zmiana stanowiska lub organizacji: W firmach, jeżeli pracownik odchodzi lub zmienia rolę, certyfikat S/MIME powiązany ze starym e-mailem może zostać unieważniony, a nowy wystawiony do nowego e-maila. Podobnie osoba prywatna zmieniająca adres e-mail może chcieć nowy klucz/certyfikat powiązany z nowym adresem (choć w PGP można po prostu dodać UID z nowym adresem do istniejącego klucza).
• Zalecenia bezpieczeństwa: Czasem pojawiają się zalecenia, by przejść na inny algorytm (np. RSA -> ECC) albo porzucić klucze krótsze niż X bitów. Wtedy też następuje rotacja.

Rotacja w OpenPGP:

• Jeśli tworzymy nowy klucz, warto podpisać go starym kluczem (o ile oczywiście nie był kompromitowany), żeby nasi znajomi mogli łatwiej go zaakceptować („klucz A potwierdza, iż klucz B jest moim nowym”). Można też wysłać mail do wszystkich kontaktów, podpisany starym kluczem, z załączonym nowym kluczem publicznym. Kontakty wtedy importują nowy klucz i widząc istotny podpis starego, mają dowód ciągłości.
• Stary klucz, jeżeli nie jest kompromitowany, można pozostawić jako opcję odszyfrowywania starych wiadomości (nie trzeba go unieważniać natychmiast po ogłoszeniu nowego – wystarczy zaznaczyć w preferencjach, iż nie używać go do nowych wiadomości). Oczywiście po pewnym czasie można unieważnić stary, by np. nie krążył wiecznie w obiegu.
• Pamiętaj o aktualizacji klucza np. na serwerach keyserver (wysłaniu nowego lub zaktualizowanego starego z przedłużoną datą).

Rotacja w S/MIME:

• Certyfikaty mają z góry datę ważności, więc rotacja jest wymuszona – np. co rok musimy mieć nowy. Na szczęście klienci zwykle automatycznie zaczną używać nowego certyfikatu, gdy tylko go zainstalujemy i wskażemy, a do odszyfrowywania starych wiadomości przez cały czas trzymamy stary (ważne: nie kasuj starego certyfikatu ze swojego magazynu! Mimo iż wygasł, jest potrzebny do czytania archiwalnej poczty).
• Gdy dostaniesz nowy certyfikat, wyślij ponownie podpisany mail do swoich kontaktów – ich programy zapiszą Twój nowy certyfikat i będą mogły słać do Ciebie zaszyfrowane maile (z nowym kluczem).
• Stary certyfikat: jeżeli wygasł, to i tak już nie posłuży do podpisu, ale do deszyfracji – jak wspomniano – będzie potrzebny. Nie unieważnia się certyfikatu dlatego tylko, iż wygasł (chyba iż nastąpiła kompromitacja). Unieważnienie jest raczej na wypadek zgubienia/kradzieży klucza.
• W przypadku kompromitacji klucza S/MIME, zgłaszasz się do CA z prośbą o unieważnienie (albo robisz to przez ich panel online, jeżeli oferują). CA w ciągu minut/godzin publikuje informację (CRL/OCSP), a odbiorcy Twoich maili będą widzieć, iż Twój certyfikat jest revoked (o ile ich klient sprawdza status certyfikatów – np. Outlook to robi automatycznie, Thunderbird chyba też już tak).

Kopie zapasowe kluczy i odzyskiwanie dostępu

Jedna z najgorszych sytuacji to utrata klucza prywatnego – wtedy nie tylko nie możemy podpisać nowych wiadomości, ale co gorsza nie odczytamy wiadomości zaszyfrowanych dla nas w przeszłości (bo odszyfrowanie wymaga klucza prywatnego). Dlatego absolutnie najważniejsze jest wykonanie i zabezpieczenie kopii zapasowych:

• Kopia zapasowa klucza prywatnego OpenPGP: Zaraz po wygenerowaniu klucza warto zrobić gpg --export-secret-keys do pliku i ten plik schować w bezpieczne miejsce (np. na zaszyfrowanym pendrive, do sejfu, wydrukować na papier – istnieje narzędzie paperkey, które pozwala wydrukować klucz prywatny w formie ciągu znaków). Ponieważ klucz jest zabezpieczony hasłem, sam plik .asc jest (w miarę) bezpieczny, ale i tak traktuj go jak bardzo wrażliwy – nie trzymać w chmurze (chyba iż dodatkowo zaszyfrowany). Revocation certificate: wygeneruj i również przechowaj w bezpiecznym miejscu. Ten certyfikat unieważnienia to mały plik .asc – warto też go np. wydrukować lub przynajmniej trzymać offline. jeżeli zgubisz klucz, a będziesz chcieć poinformować świat o unieważnieniu, bez posiadania tego certyfikatu (lub klucza prywatnego) nie unieważnisz go – ludzie mogą dalej uważać Twój klucz za być może ważny.
• Kopia zapasowa certyfikatu S/MIME (z kluczem): Tutaj na szczęście zawsze mamy plik .p12/.pfx przy eksporcie – upewnij się, iż taki plik jest gdzieś zapisany, zanim np. sformatujesz komputer. jeżeli certyfikat został wygenerowany i pozostał tylko w Windows Certificate Store, użyj narzędzia do eksportu (certmgr.msc) i stwórz plik .pfx (z hasłem!). Taki plik przechowuj bezpiecznie. W razie utraty komputera, przywrócisz certyfikat na nowym i dalej odszyfrujesz stare maile.
• Hasła do kluczy: jeżeli używasz silnego, unikalnego hasła do klucza, ryzyko, iż ktoś odtworzy klucz prywatny z backupu bez hasła, jest minimalne. Ale bywa i odwrotnie – niektórym użytkownikom zdarza się zapomnieć hasło do własnego klucza (zwłaszcza, jeżeli rzadko go używają). To jest tak samo zła sytuacja jak utrata klucza – bo masz klucz, ale nie możesz go użyć. Dlatego:
  • Wybierz hasło, które jesteś w stanie zapamiętać lub przechowuj je w menedżerze haseł (względnie w zamkniętej kopercie w sejfie, jeżeli to coś krytycznego).
  • Jeśli zapomnisz hasła, nie ma procedury odzyskiwania – nikt Ci go nie zresetuje jak w serwisie internetowym. Trzeba generować nowe klucze i pogodzić się ze stratą dostępu do starych zaszyfrowanych danych.
• Testuj backupy: Dobrą praktyką jest od czasu do czasu sprawdzić swój backup – np. zaimportować na inną maszynę lub do innego programu i zobaczyć, czy da się odszyfrować testowy stary mail. Oczywiście taki test robimy zachowawczo, by nie spowodować wycieku klucza (np. test na komputerze offline, potem usuwamy klucz stamtąd).
• Bezpieczeństwo kopii: Kopie kluczy prywatnych powinny być szyfrowane lub fizycznie chronione. jeżeli zapisujesz na dysku – zaszyfruj kontenerem (np. VeraCrypt). jeżeli na papierze – schowaj w skrytce. jeżeli ufasz sobie, iż nikt Ci domu nie przeszuka, to możesz włożyć pendrive do szuflady – ale lepiej zakodować go choćby prostym hasłem zip (coś, co ewentualnego włamywacza spowolni).
• Escrow w firmach: W środowisku organizacji praktykuje się przechowywanie kopii kluczy prywatnych pracowników przez dział IT (tzw. escrow) – tak aby firma mogła odszyfrować ważne maile choćby gdy pracownik zgubi klucz lub opuści firmę. W PGP nie ma natywnego mechanizmu escrow – trzeba by prosić pracownika o kopię lub używać współdzielonych kluczy (czego się raczej nie robi). Natomiast w S/MIME, jeżeli firma jest wystawcą certyfikatów (własne CA), może zachowywać kopie kluczy prywatnych lub stosować tzw. key recovery agent. Z punktu widzenia pracownika to może budzić mniejsze zaufanie (bo firma może odczytać Twoje maile), ale z punktu widzenia polityki – firma powinna mieć dostęp do służbowej korespondencji w razie konieczności (np. audyt, incydent). To już jednak kwestia ustaleń organizacyjnych.

Podsumowując, regularne kopie zapasowe i odpowiednia rotacja kluczy to elementy utrzymania systemu szyfrowania. Nic nie trwa wiecznie – certyfikaty się kończą, algorytmy starzeją, ludzie zapominają hasła. Zaplanuj więc cykl życia swoich kluczy: od generacji, poprzez codzienne użycie, po ewentualne wygaszenie i zastąpienie nowymi. Dzięki temu unikniesz sytuacji, w której ważne zaszyfrowane dane staną się niedostępne.

Narzędzia i konfiguracja w praktyce

Znając już teorię, przyjrzyjmy się, jak w praktyce korzystać z OpenPGP i S/MIME w popularnych środowiskach. Skupimy się na dwóch przykładach: Mozilla Thunderbird (darmowy, wieloplatformowy klient poczty, popularny wśród entuzjastów i firm) oraz Microsoft Outlook (wiodący klient pocztowy w środowiskach korporacyjnych). Wspomnimy też o specyfikach innych rozwiązań i integracji.

Mozilla Thunderbird (OpenPGP i S/MIME)

Thunderbird od wersji 78 ma wbudowaną obsługę zarówno OpenPGP, jak i S/MIME. Oznacza to, iż nie trzeba instalować żadnych dodatków, aby używać szyfrowania. Wystarczy skonfigurować odpowiednie opcje:

• Konfiguracja OpenPGP: Jak opisano wcześniej, generujemy w Thunderbirdzie klucz OpenPGP lub importujemy już posiadany (np. jeżeli wcześniej korzystaliśmy z GnuPG). Po przypisaniu klucza do konta e-mail, można w ustawieniach konta zaznaczyć, czy chcemy domyślnie podpisywać wszystkie wychodzące wiadomości (to jest często zalecane – podpisy nie szkodzą, a zwiększają wiarygodność maili) oraz czy szyfrować wszystkie, jeżeli to możliwe (to drugie raczej zostawiamy odznaczone, bo nie każdy odbiorca ma klucz – szyfrujemy manualnie per wiadomość w zależności od sytuacji).
• Wysyłanie zaszyfrowanej wiadomości OpenPGP: Aby zaszyfrować mail do kogoś, musimy posiadać jego klucz publiczny. Thunderbird ułatwia to zadanie – jeżeli np. ktoś wyśle nam e-mail z podpisem PGP (Autocrypt), program może automatycznie dodać jego klucz do naszej bazy. Możemy też skonfigurować serwery kluczy (Thunderbird domyślnie korzysta z keys.openpgp.org) – wtedy, gdy otrzymujemy podpisany mail od nowej osoby lub chcemy napisać do kogoś, możemy kliknąć “Pobierz klucze publiczne dla adresata”. Program spróbuje znaleźć klucz po adresie.
  • Gdy redagujemy nową wiadomość, w polu adresata, Thunderbird wskazuje małą ikonę klucza przy nazwisku adresata, jeżeli ma jego klucz. jeżeli nie, ikona jest przekreślona i najechanie pokaże „Brak klucza OpenPGP dla tego odbiorcy”. W takim wypadku kliknięcie przycisku szyfrowania spowoduje alert, iż nie da się zaszyfrować (i mail wyjdzie niezaszyfrowany, chyba iż przerwiemy wysyłkę).
  • Można załączyć swój klucz publiczny do wiadomości (Thunderbird ma opcję „Dołącz mój klucz publiczny OpenPGP do wiadomości”). To ułatwia odbiorcy odpowiedź szyfrowaną.
• Odbieranie zaszyfrowanego maila OpenPGP: jeżeli dostaliśmy mail .asc lub w formacie PGP/MIME, Thunderbird rozpozna, iż to zaszyfrowane. Poprosi o hasło do naszego klucza prywatnego (chyba iż jest w pamięci) i po odszyfrowaniu wyświetli treść. jeżeli mail był też podpisany, zweryfikuje podpis (o ile mamy klucz nadawcy).
  • Jeżeli nie mieliśmy klucza nadawcy wcześniej, Thunderbird może automatycznie wyciągnąć go z nagłówka Autocrypt lub z załącznika klucza. jeżeli to nastąpi, warto potem zweryfikować ten klucz (np. porównać odcisk palca) zanim uznamy go za zaufany. Thunderbird pozwala oznaczyć klucz nadawcy jako zaufany (podnieść poziom zaufania) poprzez menedżer kluczy.
• Konfiguracja S/MIME: Tutaj musimy wcześniej zaimportować nasz certyfikat i przypisać do konta (co omówiono w dziale uzyskiwania certyfikatu). Zakładamy, iż już to zrobiliśmy – w Ustawieniach konta -> Szyfrowanie end-to-end w sekcji S/MIME wybraliśmy adekwatny certyfikat do podpisu i szyfrowania.
  • Thunderbird może automatycznie podpisywać wiadomości S/MIME (jest opcja „Domyślnie podpisuj cyfrowo…”) i/lub automatycznie szyfrować, jeżeli to możliwe. Automatyczne szyfrowanie oznacza, iż jeżeli Thunderbird znajdzie certyfikat każdego z odbiorców na liście, to zaszyfruje mail. jeżeli choć jednego certyfikatu brak, wyskoczy okno z informacją kogo brakuje.
  • W praktyce, zwykle podpisuje się każdą wiadomość (aby kontakty dostały nasz cert), a szyfruje manualnie te, które mają iść do kogoś, o kim wiemy iż też ma szyfrowanie.
• Wysyłanie zaszyfrowanego maila S/MIME: W oknie redagowania wiadomości wybieramy z menu Opcje -> Zaszyfruj wiadomość (lub ikonę kłódki, zależnie od UI). Thunderbird sprawdzi, czy dla wszystkich odbiorców (TO/CC) posiada certyfikaty. jeżeli tak – kłódka zostanie zaznaczona i wiadomość będzie zaszyfrowana. jeżeli nie – pojawi się ostrzeżenie przed wysyłką.
  • Thunderbird trzyma certyfikaty S/MIME osób, od których otrzymaliśmy podpisane maile, w swoim magazynie (Osoby). jeżeli chcemy dodać czyjś certyfikat „ręcznie”, można to zrobić przed napisaniem maila: Narzędzia -> Otwórz menedżer certyfikatów -> Osoby -> Importuj (np. jeżeli ktoś nam przysłał .cer plikiem).
• Odbieranie zaszyfrowanego maila S/MIME: jeżeli ktoś wyśle do nas szyfrowany mail, a nasz certyfikat prywatny jest w Thunderbirdzie, program poprosi o hasło do klucza prywatnego (chyba iż zapamiętany) i odszyfruje treść. W pasku pokaże „Wiadomość odszyfrowana pomyślnie”. jeżeli nadawca podpisał mail, zobaczymy też wynik weryfikacji podpisu (np. „Podpis cyfrowy jest prawidłowy, ale certyfikat nadawcy jest niezaufany” – co oznacza, iż nadawca ma certyfikat od nieznanego CA lub jego CA nie jest wbudowane; albo „Podpis prawidłowy i zaufany” jeżeli wszystko gra).
  • Jeśli nasz klucz prywatny nie został zaimportowany (np. zapomnieliśmy go wgrać po formacie systemu) – wiadomości nie odszyfrujemy (pojawi się ciąg znaków lub załącznik smime.p7m). Trzeba wgrać certyfikat .pfx i spróbować ponownie (dobrze jest trzymać skrzynkę zaszyfrowanych maili nie tylko w chmurze – bo webmail ich nie odczyta – ale też lokalnie w Thunderbirdzie; w razie braku klucza możemy odłożyć odszyfrowanie aż go odzyskamy).
• Thunderbird i Enigmail (starsze): Wersje starsze (np. 68 ESR) wymagały Enigmaila do PGP i obsługi S/MIME natywnie. Ponieważ to już historyczne, tylko wspomnimy: Enigmail dodawał np. pasek nad edycją maila z wyborami „PGP/MIME vs Inline PGP”, „Szyfruj”, „Podpisz”. Było też manualne przypisywanie kluczy do tożsamości. W TB 78+ dokonano migracji automatycznie (Enigmail przy pierwszym uruchomieniu TB 78 eksportował klucze do TB i przekazał ustawienia).
• Integracja z GnuPG: Co ciekawe, Thunderbird ma własny mechanizm OpenPGP (napisany w jęz. Rust), i domyślnie nie używa zewnętrznego gpg. Można jednak w ustawieniach zaawansowanych włączyć użycie zewnętrznego GnuPG, jeżeli ktoś chce (np. by korzystać ze smartcard z GnuPG). To jednak wykracza poza standardowe użycie.

Thunderbird jest dość przyjazny dla szyfrowania, pokazuje ikony kłódki/przysłony przy wiadomościach w folderach (np. zaszyfrowana wiadomość jest oznaczana ikonką kłódki obok tematu na liście). Ogólnie dla użytkownika codzienna obsługa sprowadza się do decyzji czy kliknąć „szyfruj” przy wysyłaniu maila i ewentualnie podania hasła do klucza przy odczycie. Reszta jest transparentna.

Microsoft Outlook (S/MIME i GnuPG/GpgOL)

Microsoft Outlook (w pakiecie Office/Microsoft 365) również obsługuje szyfrowanie i podpisywanie, ale w przeciwieństwie do Thunderbirda, natywnie obsługuje tylko S/MIME. OpenPGP nie jest wspierane out-of-the-box, ale istnieją rozwiązania umożliwiające integrację.

S/MIME w Outlooku:

• Jak opisano, musimy najpierw mieć certyfikat w systemie Windows. Outlook skorzysta z niego automatycznie.
• W widoku tworzenia wiadomości w Outlook 2016/2019/365 należy wejść w zakładkę Opcje i tam kliknąć Zaszyfruj (Encrypt) lub Podpisz (Sign). W niektórych wersjach ikonki są w Opcje > Uprawnienia (Permissions).
• Można też w Centrum zaufania włączyć domyślne podpisywanie wszystkich wiadomości. Wtedy Outlook będzie dołączał podpis do każdej wysyłanej wiadomości (co jest przydatne, aby współpracownicy od razu otrzymali nasz certyfikat).
• Jeśli próbujemy wysłać zaszyfrowany e-mail do kogoś, a nie mamy jego certyfikatu w naszych kontaktach, Outlook wyświetli komunikat błędu: „Microsoft Outlook cannot sign or encrypt this message because you have no certificates which can be used to send from the email address <adres> and/or because the recipient has no certificate with an email address <adres>” (wolne tłumaczenie: brak certyfikatu własnego lub odbiorcy). To oznacza, iż albo my nie mamy własnego certyfikatu (np. nie zainstalowaliśmy), albo w książce adresowej Outlooka nie ma klucza odbiorcy.
  • W drugim przypadku, rozwiązaniem jest zdobycie certyfikatu odbiorcy. Najprościej: poprosić, by wysłał nam podpisany mail. Gdy go otrzymamy, otwieramy go, klikamy prawym na adres nadawcy -> Dodaj do kontaktów programu Outlook. Nowy kontakt utworzy się z dołączonym certyfikatem. Od tej pory możemy do tej osoby wysyłać szyfrowane maile (Outlook automatycznie użyje przechowanego certyfikatu).
  • Jeśli mamy certyfikat jako plik .cer, możemy go otworzyć i kliknąć „Zainstaluj certyfikat” do magazynu Osoby inne. Ale Outlook tak czy inaczej wymaga, by adres e-mail w certyfikacie pasował do wpisanego adresu kontaktu. Dlatego praktyczniej używać mechanizmu „Add to Contacts” z maila.
• Odbiór zaszyfrowanej poczty: Gdy dostaniemy zaszyfrowany mail, Outlook pokaże ikonkę kłódki przy nim. Po otwarciu, jeżeli nasz certyfikat jest w systemie, powinien automatycznie odszyfrować i pokazać treść. o ile klucz prywatny jest chroniony hasłem, system Windows może zapytać o hasło (można zaznaczyć, by je pamiętał). Pod podpisanymi mailami Outlook wyświetla informację „Ta wiadomość została podpisana cyfrowo przez …” i czy podpis jest OK.
  • Jeśli podpis nie jest OK (np. nadawca ma nieznane CA), będzie informacja o problemie z podpisem – użytkownik może manualnie podejrzeć szczegóły, zobaczyć certyfikat nadawcy i ewentualnie dodać jego CA do zaufanych.
• Outlook integruje się z Active Directory: w domenie firmowej, jeżeli firma dystrybuuje certyfikaty pracowników, Outlook może automatycznie w globalnej książce adresowej mieć ich certyfikaty – wtedy wysyłając mail wewnątrz firmy szyfrowanie jest bezproblemowe (Outlook sam znajdzie cert po nazwisku). To duża zaleta w korporacjach.

OpenPGP w Outlooku:

• Jako iż Outlook nie obsługuje PGP, konieczne są wtyczki. Najpopularniejszym rozwiązaniem jest wspomniany pakiet Gpg4win, który zawiera wtyczkę GpgOL integrującą GnuPG z Outlookiem.
• Po instalacji Gpg4win (który zawiera Kleopatrę – GUI do zarządzania kluczami – i GpgOL), w Outlooku powinna pojawić się karta GpgOL lub dodatkowe opcje szyfrowania. Niestety, wtyczka GpgOL nie zawsze działa ze wszystkimi wersjami Outlooka idealnie – wymaga co najmniej Outlook 2010+, a najlepiej 2016/2019 z aktualizacjami.
• W Outlook 365 nowego typu (interfejs „pobrany z chmury”) mogą być pewne problemy, ale z reguły można użyć w klasycznym oknie komponowania.
• Po poprawnej integracji, GpgOL przechwytuje maile przy otwieraniu/wyświetlaniu i próbuje je odszyfrować z użyciem kluczy GnuPG. Podobnie przy wysyłaniu – oferuje przyciski „Sign/Encrypt” (lub automatycznie wykrywa, iż odbiorca ma publiczny klucz w keyring-u GnuPG).
• Klucze PGP trzeba zarządzać w Kleopatra (graficzny manager dołączony do Gpg4win) lub w wierszu poleceń. GpgOL korzysta z tego samego magazynu kluczy co GnuPG.
• Inne wtyczki: historycznie istniał Outlook Privacy Plugin i kilka innych, ale w tej chwili Gpg4win jest najbardziej rozwijane. Komercyjnie są też rozwiązania typu Symantec Encryption Desktop (dawniej PGP Desktop) integrujące PGP z Outlook, ale to rzadziej spotykane.
• W praktyce, używanie PGP w Outlooku bywa mniej wygodne niż S/MIME – bo to doklejona funkcjonalność. Dla firm, które potrzebują PGP, czasem lepiej użyć zewnętrznego narzędzia do odszyfrowywania (np. jakiegoś klienta web PGP) albo przejść na Thunderbird.

Inne narzędzia i środowiska:

• Webmail (Gmail, Outlook.com, Yahoo): Większość webmaili nie ma natywnej obsługi PGP/S MIME. Gmail w Google Workspace (dawniej G Suite) pozwala adminom dodawać obsługę S/MIME (trzeba wgrać certyfikaty użytkowników, wtedy Gmail web może podpisywać/szyfrować automatycznie – funkcja raczej dla firm). Dla PGP w webmailu jedynym sposobem są rozszerzenia przeglądarki jak Mailvelope (uniwersalny, integruje z polami tekstowymi webmaila) lub dedykowane pluginy (FlowCrypt dla Gmaila).
• Mobilne aplikacje: Standardowe aplikacje mobilne (iOS Mail, Gmail app) nie obsługują PGP.
  • iOS Mail obsługuje S/MIME – certyfikat S/MIME można zainstalować w iPhone i maile będą podpisywane/odszyfrowywane (ikona spinacza przy zaszyfrowanych, dotknięcie pokazuje opcje).
  • Gmail app nie obsługuje S/MIME na zwykłych kontach.
  • Aplikacje firm trzecich: np. Canary Mail (iOS) obsługuje PGP i choćby ma chmurę do synchronizacji kluczy; OpenKeychain + K-9 Mail (Android) to popularny zestaw dla PGP; Nine (Android/iOS) obsługuje S/MIME.
  • ProtonMail i Tutanota – to alternatywne usługi mailowe z domyślnym szyfrowaniem end-to-end w swoich ekosystemach (niezbyt kompatybilne z PGP/S MIME poza ich światem). ProtonMail jednak umożliwia import/export kluczy PGP i interoperacyjność z PGP zewnętrznym do pewnego stopnia.
• CLI i automatyzacja: Administratorzy mogą używać narzędzi jak mutt (mail w terminalu) z integracją GPG, czy skrypty do automatycznego szyfrowania plików i wysyłki. Na serwerach można np. szyfrować załączniki PGP i wysyłać zwykłym mailem.

W skrócie, wybór narzędzia często dyktuje, którego standardu się użyje: Outlook sprzyja S/MIME, społeczność open-source – PGP. Thunderbird daje wybór obu. Ważne, by znać ograniczenia (np. brak PGP w Outlook lub Gmail bez dodatków) i planować zgodnie z tym.

Typowe problemy i najczęstsze pytania

Wdrażając szyfrowanie poczty, użytkownicy napotykają pewne powtarzające się problemy lub wątpliwości. Poniżej omawiamy najczęstsze z nich, wyjaśniamy ich przyczyny i podajemy wskazówki, jak sobie radzić.

Problem 1: „Odebrałem wiadomość z podpisem cyfrowym, ale mój program pokazuje błąd 'Podpis niezweryfikowany’ / 'Niezaufany nadawca’.”

Możliwe przyczyny (OpenPGP): Oznacza to, iż wiadomość była poprawnie podpisana kluczem PGP nadawcy, ale Twój program nie ufa temu kluczowi. Na przykład w Thunderbirdzie zobaczysz żółty komunikat „Podpis OpenPGP prawidłowy, ale klucz nie jest zaufany”. Dzieje się tak, ponieważ nie zweryfikowałeś jeszcze tożsamości nadawcy – klient informuje tylko, iż podpis matematycznie się zgadza (wiadomość nie została podrobiona), ale nie może zagwarantować, iż ten klucz faktycznie należy do danej osoby. To sedno web of trust.

Jak rozwiązać: Zweryfikuj klucz nadawcy: sprawdź jego fingerprint (np. nadawca może go publikować w stopce lub na stronie) i jeżeli się zgadza, oznacz klucz jako zaufany (w Thunderbird: w menedżerze kluczy znaleźć klucz -> PPM -> Ustaw poziom zaufania -> Ufam tego właściciela klucza). Możesz też podpisać klucz nadawcy swoim kluczem (co automatycznie czyni go zaufanym dla Ciebie). Po tym zabiegu kolejne podpisy od tej osoby będą już pokazywane jako zielone/prawidłowe bez ostrzeżeń.

Możliwe przyczyny (S/MIME): Tutaj „niezaufany podpis” zwykle oznacza problem z certyfikatem nadawcy. Najczęściej certyfikat nadawcy jest wydany przez urząd, którego Twój program nie zna lub któremu nie ufa. Np. nadawca mógł użyć darmowego certyfikatu z mało popularnego CA, którego certyfikat główny nie jest dodany do Windows/Thunderbirda. Wtedy podpis weryfikuje się technicznie (tzn. „wiadomość niezmieniona, podpis pasuje do certyfikatu X”), ale nie można sprawdzić autentyczności certyfikatu X (bo brakuje zaufanego łańcucha do Root CA).

Jak rozwiązać: Sprawdź szczegóły certyfikatu nadawcy (np. w Outlook: kliknij na ikonę podpisu -> Wyświetl certyfikat). Zobacz, kto go wystawił. jeżeli to renomowany CA (a błąd wynika np. z braku pośredniego certyfikatu), możesz pobrać brakujące certyfikaty pośrednie i zainstalować. jeżeli to jakiś prywatny CA, możesz ręcznie dodać certyfikat tego CA do zaufanych. Jednak dodawaj do zaufanych tylko CA, co do których masz pewność. W firmie problemu nie będzie, bo pewnie wszystkie komputery mają zaufanie do firmowego CA, ale prywatnie – czasem ludzie instalują np. Certum, a Twój Thunderbird może nie mieć zaktualizowanej listy (starsze wersje nie miały automatycznie Certum). Wtedy import głównego certyfikatu Certum do zaufanych rozwiąże sprawę.

Uwaga: Dopóki nie rozwiązujesz tego, wiadomości przez cały czas są bezpieczne i podpisane – ostrzeżenie dotyczy zaufania do tożsamości, nie integralności. jeżeli to jednorazowa korespondencja i nie chce Ci się grzebać z CA, możesz manualnie uznać „OK, to jest jego podpis” i zignorować ostrzeżenie. Ale przy stałej korespondencji lepiej skonfigurować zaufanie poprawnie.

Problem 2: „Wysłałem zaszyfrowanego e-maila, odbiorca mówi, iż nie może go odczytać.”

To może dotyczyć zarówno PGP, jak i S/MIME:

W kontekście OpenPGP:

• Możliwe, iż odbiorca nie miał odpowiedniego klucza prywatnego do odszyfrowania. Czyli np. zaszyfrowałeś do niewłaściwego klucza (może ma kilka kluczy i użyłeś starego) albo odbiorca nie importował swojej pary kluczy na urządzenie, na którym czyta mail. W PGP można zaszyfrować wiadomość do wielu kluczy jednocześnie – typowo do klucza odbiorcy i często także do własnego (aby móc czytać w wysłanych). jeżeli odbiorca nie znajdzie w paczce szyfrogramu odpowiadającego jego kluczowi, nie odszyfruje.
• Być może nastąpił problem z formatem: Ty użyłeś PGP/MIME, a odbiorca korzysta z klienta, który rozumie tylko inline PGP (dziś rzadkość, ale np. niektóre starsze systemy). W efekcie widzi on załącznik o nieznanej zawartości. Lub odwrotnie: użyłeś inline (wkleiłeś zaszyfrowany tekst), a u odbiorcy program to potraktował jak zwykły tekst, zamiast odszyfrować.

Rozwiązanie: Upewnij się z odbiorcą, że:

• Ma zainstalowany swój klucz prywatny i poprawnie wprowadza hasło.
• Klucz, do którego szyfrujesz, jest rzeczywiście tym, którego on używa. Najlepiej wymieńcie fingerprinty przed wysyłką. Możliwe, iż np. kolega miał dwa klucze na różne adresy e-mail, a Ty zaszyfrowałeś na ten drugi, do którego on akurat na tym urządzeniu nie miał klucza prywatnego – wtedy zobaczy komunikat typu „Nie można odszyfrować – brak odpowiedniego klucza prywatnego”.
• Co do formatu: większość nowoczesnych klientów (Thunderbird, Outlook z wtyczką, itd.) obsługuje PGP/MIME poprawnie. jeżeli jednak trafiamy na ograniczenia (np. jakiś webowy dekoder PGP nie radzi sobie z załącznikami), spróbujmy uzgodnić wspólny format: w razie czego można zaznaczyć w Enigmail lub innym narzędziu „Use Inline PGP” i wtedy mail będzie w tekście ASCII z blokami -----BEGIN PGP MESSAGE-----. Wadą inline jest brak szyfrowania załączników (załączniki muszą być manualnie szyfrowane i wklejane) – dlatego preferowany jest PGP/MIME.
• Jeśli problemem jest iż odbiorca w ogóle nie korzysta z PGP – cóż, musimy go najpierw zapoznać i wymienić klucze. PGP wymaga, by obie strony były „w grze”. Podobnie S/MIME – nie wyślemy szyfrowanego maila do kogoś, kto nie ma certyfikatu, bo nie mamy jak.

W kontekście S/MIME:

• Najczęstszą przyczyną jest, iż odbiorca nie ma zainstalowanego swojego klucza prywatnego. Np. wysłałeś zaszyfrowany mail do współpracownika, a on próbuje go czytać na telefonie, gdzie nie wgrał certyfikatu – zobaczy pustą treść lub komunikat „This message is encrypted. To view, please open on a device with your certificate” itp.
• Inna opcja: zaszyfrowałeś do niewłaściwego certyfikatu (np. kontakt ma dwa certy – stary wygasły i nowy, a Ty użyłeś starego który już wygasł lub został revoked). Wtedy program odbiorcy może krzyczeć, iż mail był zaszyfrowany kluczem, którego on już nie ma (bo np. wymienił certyfikat).
• Czasem bywa tak, iż w ogóle nie da się zaszyfrować bo nie mamy certyfikatu odbiorcy (to akurat wychwycimy przed wysyłką – błąd jak wyżej).
• Rzadko: problem interoperacyjny, np. użycie starego algorytmu. S/MIME domyślnie używa AES/Camellia, raczej kompatybilne. Gdyby ktoś miał staruteńki program obsługujący tylko 3DES, a Ty wysłałeś AES-256, może nie odczytać. To jednak mało prawdopodobne dziś.

Rozwiązanie:

• Jeśli odbiorca nie ma swojego klucza prywatnego na danym urządzeniu – musi czytać na innym, gdzie ma, lub zaimportować certyfikat. To dość powszechne – ludzie instalują certyfikat na PC, ale zapominają na telefonie, i potem mówią „na telefonie nie widzę nic w mailu”. Niestety tak to działa – trzeba wszędzie swój klucz mieć, gdzie chce się czytać szyfrowane maile.
• Sprawdź ważność i szczegóły certyfikatu, do którego szyfrowałeś (np. w Thunderbirdzie: Wysłane -> klik na ikonce kłódki przy wiadomości -> pokaż certyfikaty użyte). jeżeli widzisz, iż użyto certyfikatu odbiorcy z datą ważności do 2022, a jest 2025 – prawdopodobnie użyłeś starego wpisu z książki adresowej. Trzeba zaktualizować certyfikaty kontaktów – np. poprosić odbiorcę o aktualny podpisany mail i dodać nowy certyfikat.
• Jeśli problemem jest czytanie na webmailu (np. Outlook Web Access) – niektóre interfejsy web pozwalają na odszyfrowanie, jeżeli wgra się certyfikat przeglądarce, ale bywa z tym różnie. Generalnie lepiej czytać w programie stacjonarnym.
• Diagnostyka: W Outlooku często błąd odszyfrowania pokaże „elementy w magazynie osobistym nie pasują” – co oznacza, iż albo brak certyfikatu, albo nieprawidłowy. W Thunderbird brak klucza prywatnego do odszyfr. spowoduje, iż w ogóle nic nie pokaże (albo pokaże załącznik smime.p7m). Wtedy wiemy – okej, zapomnieliśmy wgrać cert.

Problem 3: „Mój odbiorca używa PGP, a ja S/MIME (lub odwrotnie). Czy możemy się komunikować bezpiecznie?”

OpenPGP i S/MIME to niekompatybilne standardy. PGP nie może odszyfrować maila S/MIME i odwrotnie, bo używają innego formatu danych. jeżeli Ty masz tylko klucze PGP, a Twój partner tylko certyfikaty S/MIME, to macie problem – nie da się wysłać jednego maila, który oboje odczytacie. Macie kilka opcji:

• Jedna strona dołącza drugi system: Najlepiej oboje wdrożyć ten sam standard. Np. Ty zainstaluj sobie również certyfikat S/MIME, albo partner wygeneruje klucz PGP. Można równolegle używać obu – np. do jednych kontaktów PGP, do innych S/MIME.
• Użycie zewnętrznego narzędzia i przesyłanie plików: W ostateczności możecie wymieniać się zaszyfrowanymi plikami zamiast bezpośrednio maila. Np. Ty napiszesz wiadomość, zaszyfrujesz ją kluczem PGP odbiorcy (jako plik .asc), a odbiorca dostanie normalny mail z tym .asc i zdekoduje w swoim sofcie PGP. Ale to bardzo nieeleganckie.
• Przejście na inne rozwiązanie: np. wspólne korzystanie z ProtonMaila (on używa PGP), lub jakiejś platformy wymiany plików, jeżeli nie możecie uzgodnić standardu.

Generalnie, jeżeli komunikacja ma być częsta, umówcie się na jeden standard. Bywa tak, iż instytucja może wymagać S/MIME (np. urząd administracji), a kontrahent preferuje PGP – wtedy praktycznie jedynym wyjściem jest, by jedna ze stron dostosowała się i również użyła drugiego rozwiązania. Nie ma magicznego mostu tłumaczącego S/MIME na PGP automatycznie (choć istnieją bramki mailowe, które mogłyby np. u siebie odszyfrować PGP i przeenkryptować na S/MIME korzystając z certyfikatu adresata – ale to bardzo niszowe i wymaga zaufania bramce, więc raczej nie wchodzi w grę w end-to-end).

Problem 4: „Mam nowy komputer/telefon – nie widzę starych zaszyfrowanych e-maili.”

To dotyczy braku kluczy na nowym urządzeniu:

• Jeśli to e-maile PGP i używasz np. nowej instalacji Thunderbirda – musisz zaimportować swój klucz prywatny PGP na ten komputer (z backupu). Inaczej Thunderbird zobaczy zaszyfrowane wiadomości w twoim archiwum, ale nie odszyfruje ich (kłódka zostanie przy nich, a po kliknięciu będzie prośba o klucz prywatny którego nie ma).
• Jeśli to e-maile S/MIME i np. przeniosłeś się na nowy komputer czy telefon – analogicznie, musisz zainstalować swój certyfikat z kluczem prywatnym (.p12). Bez tego nowe urządzenie nie ma jak odczytać wcześniej odebranych zaszyfrowanych wiadomości.
• W przypadku telefonu, choćby jeżeli korzystasz z tej samej usługi (np. Outlook on iPhone do skrzynki Exchange), to szyfrowane maile będą tam niedostępne, dopóki nie wgrasz certyfikatu (otrzymasz np. komunikat, iż zaszyfrowana część niedostępna na tym urządzeniu).

Rada: Zawsze gdy zmieniasz urządzenie lub dodajesz nowe, pamiętaj o przeniesieniu kluczy. Najlepiej już na etapie generacji klucza prywatnego założyć, iż będzie używany na wielu sprzętach – i przygotować dla siebie kopie do importu. W ramach organizacji, czasem system MDM (Mobile Device Management) potrafi automatycznie wgrać certyfikat pracownika na jego służbowy telefon – co rozwiązuje problem. Prywatnie, musisz sam to zrobić.

Problem 5: „Zmieniłem/zmieniłam adres e-mail – czy muszę generować nowy klucz/certyfikat?”

• W przypadku OpenPGP: Nie ma takiej twardej konieczności, bo PGP klucz nie jest bezpośrednio zależny od adresu. Możesz do istniejącego klucza dodać nowy identyfikator użytkownika (UID) z nowym adresem. Np. miałeś klucz dla jan@firmaA.com, zmieniasz pracę i teraz masz jan.kowalski@firmaB.com. Możesz dodać ten drugi e-mail do swojego klucza (poleceniem gpg --edit-key -> adduid). Wtedy Twój klucz będzie miał dwa UID. Możesz posługiwać się nim przez cały czas – podpisy dokonane starym UID są wciąż ważne, a nowi ludzie mogą Ci szyfrować na nowy adres (bo w ich klientach Twój klucz będzie pasował też do tego maila).
  • Natomiast, czasem bywa polityka: nowa firma woli, żebyś używał innego klucza, np. wygenerowanego na jej sprzęcie. Albo Ty chcesz oddzielić tożsamości (nie chcesz, by partnerzy biznesowi z nowej firmy widzieli na Twoim kluczu też stary email). Wtedy możesz wygenerować nowy klucz tylko dla nowego adresu.
  • Oba podejścia są poprawne – zależy od sytuacji.
• W przypadku S/MIME: Certyfikat jest wystawiony na konkretny adres (i nazwisko). Zmiana adresu = stary certyfikat już nie pasuje (w sensie, możesz nim wciąż podpisywać, ale ludzie zobaczą w nim starą tożsamość; no i nie zaszyfrują na nowy adres, bo klient stwierdzi, iż nie ma takiego emaila w certyfikacie).
  • Zdecydowanie należy uzyskać nowy certyfikat na nowy adres. Stary można unieważnić, jeżeli już nie będzie używany (zwłaszcza gdy to adres firmowy w starej firmie, pewnie ich polityka i tak wymusi unieważnienie, bo nie możesz mieć ważnego certyfikatu na domenę firmy, w której nie pracujesz).
  • Pamiętaj, żeby zrobić backup starego certyfikatu jeżeli masz szyfrowane maile sprzed zmiany – bo po unieważnieniu co prawda weryfikacja podpisów nim złożonych będzie negatywna, ale do odszyfrowania starych maili przez cały czas potrzebujesz jego klucza prywatnego.

Problem 6: Błędy i problemy przy podpisywaniu/wysyłaniu: „Nie można podpisać wiadomości”, „Certyfikat nieprawidłowy”, „Adres w certyfikacie niezgodny z nadawcą”.

Takie błędy pojawiają się zwykle w sytuacjach:

• Próbujesz podpisać mail S/MIME, ale masz wybrane złe konto lub tożsamość. Np. w Outlooku masz certyfikat dla adresu jan@firma.com, ale tworzysz nową wiadomość i w polu From wybierasz alias jan.kowalski@gmail.com. Outlook wtedy powie, iż nie ma certyfikatu dla tego adresu. Rozwiązanie: upewnij się, iż używasz certyfikatu przypisanego do adekwatnego adresu. jeżeli masz wiele kont w jednym programie, skonfiguruj dla wszystkich odpowiedni certyfikat. Albo wyłącz podpisywanie, gdy wysyłasz z adresu, do którego nie masz certyfikatu.
• Podobnie w PGP: Thunderbird może mieć wiele tożsamości. jeżeli nie powiązałeś klucza PGP z daną tożsamością (np. inny alias adresu), to przy próbie podpisu powie „brak klucza prywatnego do podpisania jako ten nadawca”. Trzeba dodać adres do klucza lub wskazać w ustawieniach, żeby używał konkretnego klucza do tego aliasu.
• Certyfikat nieprawidłowy lub wygasły: przy próbie podpisu S/MIME może wyskoczyć komunikat, iż Twój certyfikat jest nieważny (np. minęła data ważności) lub został unieważniony. Wtedy oczywiście musisz odnowić certyfikat – nie ma innej drogi. Podpisywanie wygasłym certyfikatem nie ma sensu, bo odbiorcy i tak dostaną informację „Podpis nie jest istotny (certyfikat wygasł)”.
• Klucz PGP wygasł: GnuPG pozwala przez cały czas używać wygasłego klucza prywatnego do odszyfrowania czy choćby podpisu (z ostrzeżeniem), ale inne osoby zobaczą Twój podpis jako złożony przez wygasły klucz – co może budzić wątpliwości. Dlatego lepiej przed upływem ważności przedłużyć klucz i rozesłać aktualizację.
• Niezgodność algorytmów/hardware: rzadki problem może wystąpić, gdy używasz np. PGP ze smartcard (YubiKey), a program pocztowy nie potrafi z nią współpracować. Np. Thunderbird (bez external GnuPG) nie obsłuży klucza na karcie. Rozwiązanie: korzystać z gpg-agent i skonfigurować TB do użycia zewnętrznego GnuPG.
• Za duży załącznik i PGP inline: o ile ktoś próbuje wysyłać ogromny plik i użyje PGP inline (co wymaga zakodowania base64 i może spuchnąć) – to raczej nie róbcie tak, duże pliki lepiej szyfrować osobno i przekazywać inaczej, bo e-mail może nie udźwignąć. To nie tyle błąd, co kwestia wydajności.

Problem 7: UX – „To wszystko jest za trudne, moi współpracownicy/rodzina nie dają rady.”

To częsta bariera miękka: technologia istnieje, działa, ale ludzie nie chcą z niej korzystać, bo wydaje im się skomplikowana. Rzeczywiście, PGP w szczególności ma opinię trudnego dla nietechnicznych użytkowników (zarządzanie kluczami, dziwne komunikaty o zaufaniu). S/MIME w środowisku firmowym bywa bardziej przejrzyste dla użytkownika końcowego, bo integruje się z Outlookiem prawie niewidocznie. Jednak i tu pojawia się np. konieczność wpisywania hasła do klucza przy każdym starcie Outlooka, co bywa uciążliwe (niektórzy użytkownicy wtedy rezygnują z szyfrowania albo ustawiają puste hasło na klucz – co jest złym pomysłem).

Propozycje rozwiązania problemów UX:

• Szkolenia i świadomość: Poświęć czas, by wytłumaczyć współpracownikom, po co to robicie i krok po kroku pomóż im skonfigurować. Często największy opór jest przed nieznanym. Gdy ktoś raz zobaczy, iż podpisanie czy odszyfrowanie maila to w gruncie rzeczy kliknięcie jednego przycisku więcej i wpisanie hasła, oswaja się z tym.
• Automatyzacja: W miarę możliwości, zastosuj mechanizmy automatyczne. Np. w PGP – włącz Autocrypt w kliencie (Thunderbird ma domyślnie), by użytkownicy nie musieli manualnie wymieniać plików kluczy. W S/MIME – wdroż automatyczne dystrybuowanie certyfikatów (np. katalog adresów, centralny repository).
• Używaj menedżerów haseł lub integracji systemowej: Możesz np. w Thunderbirdzie skorzystać z GNOME Keyring/KWallet (Linux) lub Password Store systemu (Windows) do zapamiętania hasła klucza, by nie męczyć użytkownika co sesję. W Outlooku Windows OS może zapamiętać hasło prywatnego klucza, jeżeli tak zaznaczysz przy imporcie (acz to mniej bezpieczne, bo potem klucz działa bez PIN-u).
• Hardware tokeny: Ciekawym rozwiązaniem UX jest użycie np. YubiKeya do przechowywania klucza prywatnego. Wtedy użytkownik nie musi pamiętać skomplikowanego hasła – zamiast tego odblokowuje klucz klikiem lub krótszym PIN-em i reszta dzieje się na tokenie. Wadą jest koszt i konieczność posiadania urządzenia przy sobie, ale w firmach to czasem akceptowalne (taki token może służyć wielorako – do logowania, VPN, podpisu itd.). YubiKey może obsługiwać zarówno PGP (sloty OpenPGP Card) jak i certyfikaty (PIV). Integracja bywa nieco zaawansowana, ale docelowo user wkłada klucz USB i ma dostęp.
• Wymuszaj polityką to, co konieczne, ale nie więcej: Np. jeżeli firma wymaga szyfrowania tylko dla pewnych działów lub typów informacji – nie obarczaj całej komunikacji szyfrowaniem, bo ludzi to zniechęci. Zacznij od cyfrowego podpisywania wszystkich maili (to mały krok, a już daje wartość, np. chroni przed phishingiem wewnętrznym – ludzie widzą, iż mail od prezesa nie ma podpisu, czyli to może nie on). Gdy podpisy staną się normą, dodaj szyfrowanie tam, gdzie to naprawdę potrzebne (np. w dziale prawnym, finansowym do przesyłania wrażliwych danych).
• Wsparcie IT: Zapewnij, żeby dział IT pomógł przy problemach. Użytkownik dostaje błąd „nie można odszyfrować” – powinna być procedura wsparcia (może to byc tak proste jak checklista: masz zainstalowany cert? itp.).
• Alternatywy: jeżeli naprawdę PGP/S/MIME nie wejdzie, a potrzeba bezpieczeństwa jest, rozważ usługę, która ukryje złożoność przed userem. Np. ProtonMail dla całej grupy – wtedy logują się do webmaila i maile wewnątrz są szyfrowane automatycznie. Albo używanie komunikatorów szyfrowanych (Signal/WhatsApp) zamiast maila, jeżeli chodzi tylko o sporadyczne przekazanie poufnej info. Oczywiście to odbiega od pytania stricte, ale chodzi o osiągnięcie celu (bezpieczna komunikacja) w sposób akceptowalny dla użytkowników.

Problem 8: Interoperacyjność i zgodność (techniczne szczegóły)

Mimo standaryzacji, zdarzają się techniczne problemy zgodności:

• Np. EFAIL – głośna luka ujawniona w 2018, dotyczyła kombinacji klienci email + PGP/S MIME, gdzie niektóre klienty podatne były na wstrzyknięcie pewnych elementów HTML do zaszyfrowanej wiadomości, co w pewnych warunkach mogło ujawnić fragmenty odszyfrowanej treści atakującemu. Rozwiązanie: aktualizacja systemu (klienci załatali to, np. Thunderbird wprowadził bezpieczniejsze przetwarzanie MIME). Wniosek: zawsze trzymaj oprogramowanie do szyfrowania aktualne.
• Algorytmy: W PGP upewnij się, iż używasz algorytmów, które druga strona obsługuje. Standard RFC4880 wymaga implementacji podstawowych (3DES, SHA1, DSA/Elgamal), więc raczej każdy soft je ma. Ale jak Ty wymusisz np. szyfrowanie tylko AES-256 + Camellia, a odbiorca ma stary program obsługujący tylko 3DES, to będzie kłopot. Zostaw domyślne ustawienia – zwykle negocjowane jest najsilniejsze wspólne.
• Wielu odbiorców: Przy wysyłaniu do wielu osób, PGP i S/MIME różnie działają:
  • PGP: szyfruje oddzielnie dla wszystkich odbiorcy (generuje unikatowy klucz symetryczny dla wiadomości i ten klucz szyfruje kluczem publicznym każdego odbiorcy – do maila dołącza pakiety dla wszystkich). W praktyce działa to transparentnie, ale w niektórych klientów może spowodować np. duży wzrost rozmiaru maila (bo wielu odbiorców to dużo bloków).
  • S/MIME: podobnie – potrafi zaszyfrować dla wielu (CMS wspiera wiele recipientInfo). Outlook to obsłuży, Thunderbird też. Tylko upewnij się, iż masz certyfikat każdego – inaczej nie doda tej osoby i może mail do niej poleci niezaszyfrowany (co niektóre programy robią – np. do 2 osób z cert i 1 bez, wyśle do tej jednej czystym tekstem, co jest zagrożeniem bo ktoś może nie zauważyć). Lepiej nie mieszać – jak choć jeden nie ma certyfikatu, lepiej całość wyślij niezaszyfrowaną (albo podziel – do tych z certem osobno szyfrowane, do reszty osobno).
• Temat wiadomości: W S/MIME temat maila nie jest szyfrowany (nagłówki zawsze lecą jawnym tekstem). W OpenPGP/MIME również temat idzie osobno (chyba iż używa się jakiegoś wrappera). To znaczy, iż ktoś podsłuchujący przez cały czas widzi subject Twojego maila. Zwróć uwagę, by nie wkładać tam wrażliwych informacji. Można np. wpisać neutralny temat typu „Wiadomość zaszyfrowana” albo coś niebudzącego podejrzeń.
• Poczta wychodząca przez serwery: Czasem firmowe serwery skanujące pocztę mogą mieć problem z zaszyfrowanymi mailami (bo nie mogą ich sprawdzić pod kątem DLP, wirusów itd.). W skrajnym przypadku, polityka może blokować szyfrowane załączniki/maile. Warto zawczasu to uzgodnić z działem bezpieczeństwa – może trzeba dodać wyjątki, iż szyfrowane wolno przepuszczać. Ewentualnie integracja na bramie (są produkty, które na bramie organizacji szyfrują i deszyfrują maile – ale to już nie end-to-end, bo firma ma dostęp).
• Backupy i archiwizacja: o ile firma archiwizuje pocztę (compliance), zaszyfrowane maile mogą być problematyczne – bo system archiwizacji zapisze je w formie nieczytelnej. Chyba iż jest integracja, iż archiwum ma też klucze do odszyfrowania (co znowu łamie end-to-end). To bardziej kwestia polityczna/organizacyjna, ale warto o tym wiedzieć – np. w razie audytu ktoś poprosi Cię o odszyfrowanie archiwum, bo inaczej nie mogą czytać.

Powyższe problemy pokazują, iż bezpieczna poczta elektroniczna, choć wykonalna, wymaga trochę uwagi i wiedzy. Jednak z doświadczenia – wiele z tych zadań staje się rutyną: raz skonfigurujesz i potem działa. Kiedy pojawi się błąd, często daje się go gwałtownie zidentyfikować („aha, nowy pracownik, nie mam jego klucza jeszcze”, „o, certyfikat wygasł – czas na nowy”). Weryfikacja tożsamości i dbanie o klucze to nowy element, którego w zwykłym mailu nie było – ale to cena za zyskanie dużo wyższego poziomu bezpieczeństwa.

Rekomendacje: które rozwiązanie wybrać?

Na koniec, zastanówmy się, kiedy warto używać OpenPGP, a kiedy S/MIME. Obydwa systemy mają swoje mocne strony i ograniczenia, a wybór zależy od kontekstu.

Rekomendacje dla organizacji (firm, instytucji)

• Środowisko korporacyjne z infrastrukturą IT: jeżeli Twoja firma korzysta głównie z Outlooka/Exchange lub innego korporacyjnego ekosystemu, S/MIME będzie naturalnym wyborem. Pozwala on na integrację z istniejącą PKI (być może firma już używa certyfikatów do VPN, podpisu kodu itp.), certyfikaty można wydawać centralnie i dystrybuować pracownikom. Zarządzanie (np. unieważnienie certyfikatu po odejściu pracownika) jest scentralizowane. Outlook i większość mobilnych klientów obsłużą to out-of-the-box. Dodatkowy plus: podpisy S/MIME mogą potwierdzać tożsamość pracowników w komunikacji zewnętrznej – co bywa wymagane np. w sektorze prawnym czy finansowym (niektórzy klienci oczekują, iż ważne e-maile będą podpisane cyfrowo).
• Kontrola i compliance: Firmy często wolą S/MIME, bo mogą skorzystać z mechanizmu escrow – trzymać kopie kluczy prywatnych lub klucz główny do odszyfrowywania. W PGP jest to trudniejsze – każdy użytkownik jest „właścicielem” swojego klucza i firma nie ma do niego dostępu (co z punktu widzenia prywatności pracownika jest zaletą PGP, ale z punktu widzenia compliance – wadą).
• Współpraca z podmiotami zewnętrznymi: jeżeli większość Waszych partnerów biznesowych to profesjonalne podmioty (inne firmy, urzędy), jest spora szansa, iż S/MIME jest im bliższe. Np. administracja publiczna w wielu krajach używa certyfikatów kwalifikowanych do podpisów, prawnicy używają S/MIME do wysyłania dokumentów do sądów, itp. Wymiana certyfikatów między firmami jest dość prostym procesem (wystarczy wymienić pierwsze podpisane maile).
  • To nie znaczy, iż PGP się tu nie nadaje – w społeczności IT wielu ludzi preferuje PGP. Ale sekretarka w biurze zarządu międzynarodowej firmy raczej nie będzie umiała obchodzić się z PGP, za to jak dostanie mail „ta wiadomość została zaszyfrowana przez Certyfikat cyfrowy – kliknij, aby odszyfrować” w Outlooku, to dla niej jest to w miarę zrozumiałe.
• Koszty: Wdrożenie S/MIME może wymagać kupna certyfikatów (choć są darmowe, ale darmowe często niewspierane komercyjnie i np. nie wszystkie programy je traktują jako zaufane od razu). To zwykle nie są wielkie koszty (certyfikat osobisty można dostać za kilkadziesiąt zł rocznie od renomowanego CA), ale przy 1000 pracowników to już jest budżet do rozważenia. Alternatywą jest postawienie wewnętrznego CA – co jednak wymaga trochę wiedzy i nakładów na infrastrukturę (ale jeżeli firma już ma Active Directory CA, to dodanie e-mail do szablonów certyfikatów to drobiazg).
• Szkolenia i procesy: Bez względu na system, firmę czeka edukacja użytkowników. W mojej opinii edukacja dot. PGP jest trudniejsza (bo model zaufania jest mniej intuicyjny dla laika niż „certyfikat od zaufanej firmy”). Więc jeżeli firma nie ma w swoich szeregach grupy kryptograficznych entuzjastów, S/MIME może być łatwiejsze do przekazania: „to jak Twój elektroniczny dowód osobisty do maila – posługuj się nim”.
• Scenariusz hybrydowy: Nic nie stoi na przeszkodzie, by firma wspierała oba standardy, jeżeli jest taka potrzeba. Np. komunikacja wewnętrzna i z większością partnerów odbywa się przez S/MIME, ale dział IT czy bezpieczeństwa używa PGP do komunikacji ze społecznością open-source, CERT-ami, itp. W praktyce, można w Thunderbirdzie czy Outlooku mieć i certyfikat, i dodatek PGP – ale to dodatkowa złożoność. Lepiej wybrać jeden dominujący, a drugi ewentualnie marginalnie.

Rekomendacje dla użytkowników indywidualnych (oraz małych grup)

• Zastosowania prywatne, hobbystyczne, społecznościowe: Tutaj tradycyjnie króluje OpenPGP. GnuPG jest darmowe, generujesz klucz sam bez formalności, społeczności linuksowe, programistyczne go używają (choćby do podpisywania pakietów oprogramowania, commitów, itp.). jeżeli chcesz po prostu zadbać o prywatność swoich e-maili z przyjaciółmi – PGP jest naturalnym wyborem. Nie musisz podawać swoich danych nigdzie, nie musisz ufać żadnej instytucji. Wystarczy, iż Ty i Twoi korespondenci zainstalujecie np. Thunderbird i wygenerujecie klucze, wymienicie je między sobą.
  • Plusem jest też, iż PGP klucz możesz użyć do wielu innych rzeczy: zaszyfrowania plików, podpisania wiadomości na forum, weryfikacji tożsamości w różnych miejscach (niektóre serwisy używają PGP jako dowodu tożsamości).
• Użytkownicy mniej techniczni: o ile nie czujesz się na siłach w tematach kluczy, certyfikatów itp., a chcesz mieć szyfrowane e-maile, rozważ raczej skorzystanie z usług typu ProtonMail. ProtonMail (i podobne, jak Tutanota) ukrywają całą złożoność – po prostu piszesz maila w ich webmailu i zaznaczasz „szyfruj”. Wadą jest, iż obie strony najlepiej jakby były w tym samym systemie (ProtonMail do ProtonMail jest automatyczne; do zewnętrznego odbiorcy ProtonMail szyfruje i daje link – to inny mechanizm). ProtonMail w tle faktycznie używa PGP, ale użytkownik tego nie widzi.
  • Warto wspomnieć: ProtonMail da się też używać przez Bridge w zewnętrznym kliencie i wtedy można choćby mieszać z innymi PGP kluczami, ale to za daleko wykracza. Generalnie dla nietechnicznych – usługa w modelu „zarejestruj i używaj” może być lepsza niż samodzielne ogarnianie PGP.
• Małe firmy, grupy robocze: jeżeli nie macie dedykowanego IT i budżetu na PKI, a chcecie szyfrować, PGP będzie tańsze i prostsze we wdrożeniu (pod względem formalnym, niekoniecznie użycia). Wystarczy Wam np. jeden entuzjasta, który skonfiguruje Thundebirdy kolegom, i już możecie wymieniać szyfrowane maile. Za certyfikaty musielibyście płacić lub odnawiać darmowe co roku – to bywa uciążliwe i bywa iż ktoś zapomni, a tu mail nie wyjdzie podpisany… PGP nie wygasa jeżeli sami nie ustawicie.
• Anonimowość/poufność kontra formalne zaufanie:
  • Jeśli Waszym celem jest maksymalna anonimowość (np. kontakt z dziennikarzem, informowanie o nieprawidłowościach, działanie w opozycji w reżimie itp.), to PGP jest jedyną opcją spośród tych dwóch. Certyfikat S/MIME wymaga rejestracji maila, często podania imienia nazwiska; i choć można założyć anonimowy mail i spróbować uzyskać certyfikat tylko na adres, CA może to odnotować. PGP możesz użyć bez zostawiania śladów – wystarczy komputer offline do generacji, wymiana klucza np. poprzez OnionShare. Oczywiście ślady mogą być gdzie indziej, ale co do narzędzia – PGP tu wygrywa.
  • Z kolei jeżeli chodzi o wiarygodność dla odbiorcy: Wyobraź sobie, iż piszesz do swojej babci i chcesz jej pokazać, iż ten mail na pewno od Ciebie. Babcia raczej nie sprawdzi odcisku palca PGP Ale jak mail jest podpisany S/MIME i jej Outlook pokaże „podpisano przez Jan Kowalski, certyfikat ważny”, jest szansa iż to zrozumie bardziej („o, jest jakiś certyfikat jak w e-dowodzie”). To przykład, ale chodzi o to, iż S/MIME buduje pewien formalny klimat – bywa stosowane np. przez urzędy, bo wtedy obywatel widzi: mail z US jest podpisany cyfrowo przez urząd – czyli legitny. PGP też by to umożliwiło, ale obywatel musiałby zainstalować klucz urzędu i mu zaufać – co nie jest mainstreamowe.
• Wsparcie i społeczność: W sieci łatwiej znajdziesz pomoc do PGP/GnuPG (pełno poradników, forów, gotowych narzędzi). S/MIME jest często pomijane w blogach bo wydaje się „korpo sprawą”. Ale jeżeli używasz Outlooka, pomocą służy często dział IT lub dokumentacja MS. PGP jest bardziej „ludowe”, S/MIME „instytucjonalne”.

Podsumowując w formie listy plusów dla wszystkich (z perspektywy użytkownika końcowego):

Zalety OpenPGP (GnuPG) dla użytkownika:

• Całkowicie darmowe i dostępne dla wszystkich.
• Niezależność od stron trzecich – sam jesteś swoim „urzędem zaufania”.
• Możliwość używania jednego klucza w wielu miejscach (forum, git, e-mail itd. – spójna tożsamość kryptograficzna).
• Bogata społeczność, wiele narzędzi, rozszerzeń.
• Lepsze dla zachowania anonimowości (możesz nie ujawniać swoich danych nikomu).
• Działa również poza e-mailami (możesz szyfrować dowolne dane, pliki, komunikaty – ekosystem narzędzi PGP jest szerszy).

Zalety S/MIME dla użytkownika:

• Transparentność w codziennym użyciu – raz zainstalujesz certyfikat i potem klik w przycisk, mniej dodatkowych czynności typu wymienianie kluczy manualnie.
• Podpisy S/MIME są od razu rozpoznawane przez wiele programów jako „zaufane” (jeśli CA jest znane). Np. Adobe Reader potrafi weryfikować podpisy PDF jeżeli masz cert S/MIME – bo to to samo PKI.
• Integracja z systemem – na Windows certyfikaty S/MIME używają mechanizmów systemowych (CryptoAPI), co bywa wydajniejsze i spójniejsze z politykami systemu.
• Dla komunikacji biznesowej: częściej akceptowany/traktowany poważnie przez osoby nietechniczne („oficjalny certyfikat”).
• Często wymóg w pewnych branżach/regulacjach (np. medycyna, prawo – zachowanie poufności, audyty mogą pytać „czy e-maile są szyfrowane certyfikatem”).

Idealnie, należałoby mieć obie umiejętności w arsenale i korzystać w zależności od potrzeb. Indywidualnie jednak, jeżeli nie masz konkretnej potrzeby S/MIME, zacznij od OpenPGP – jest łatwiej spróbować, nie musisz nic kupować, najwyżej czas stracisz jak Ci się nie spodoba. jeżeli natomiast potrzebujesz komunikować się bezpiecznie z jakąś instytucją która wspiera S/MIME (np. Twój bank umożliwia wysyłanie zaszyfrowanych zgłoszeń klienta – niektóre tak robią – dostajesz ich certyfikat i możesz im słać tajne rzeczy), wtedy zrób sobie certyfikat.

Podsumowanie

Szyfrowanie poczty e-mail dzięki OpenPGP lub S/MIME znacząco podnosi bezpieczeństwo i poufność komunikacji – czyni z e-maila narzędzie znacznie bardziej odporne na podsłuch i fałszerstwo. Wybór między OpenPGP a S/MIME zależy od specyfiki użytkownika: OpenPGP oferuje niezależność i finezję kontroli (doceniane przez specjalistów IT, społeczności open-source), podczas gdy S/MIME wprowadza zaufany model certyfikatów, co ułatwia wdrożenie w środowiskach biznesowych i mieszanych (gdzie liczy się automatyzm i zgodność z istniejącymi standardami).

Pod względem bezpieczeństwa kryptograficznego oba rozwiązania są uważane za równorzędne – stosują silne algorytmy i jeżeli są poprawnie używane, obie metody skutecznie chronią treść wiadomości przed niepowołanym dostępem oraz pozwalają zweryfikować tożsamość nadawcy. Większość problemów wynika nie z samej kryptografii, a z czynnika ludzkiego i implementacji. Dlatego niezależnie, które rozwiązanie zostanie wybrane, najważniejsze jest przeszkolenie użytkowników, ustanowienie procedur wymiany kluczy/certyfikatów oraz stosowanie dobrych praktyk (regularne backupy kluczy, aktualizacja oprogramowania, weryfikacja odcisków palców, używanie silnych haseł do kluczy prywatnych, itd.).

Na koniec, warto podkreślić: najlepszym systemem szyfrowania jest ten, którego użytkownicy rzeczywiście używają. Lepiej mieć wdrożone choćby podstawowe podpisy cyfrowe w organizacji (co już eliminuje wiele ataków phishingowych), niż planować super-bezpieczne rozwiązanie, które okaże się zbyt skomplikowane i zostanie porzucone. W wielu przypadkach e-mail encryption bywa pomijane z wygody – ale patrząc na rosnące zagrożenia (przechwytywanie danych, spoofing, wycieki), inwestycja czasu w konfigurację OpenPGP czy S/MIME zwraca się w postaci spokojniejszej głowy o bezpieczeństwo naszej korespondencji.

Czy zatem OpenPGP czy S/MIME? Idealnie – jedno i drugie, zależnie od potrzeb. jeżeli jednak trzeba wybrać jedno:

• W ekosystemie otwartym, rozproszonym – sięgnij po OpenPGP.
• W środowisku zorganizowanym, formalnym – postaw na S/MIME.

Najważniejsze to zacząć używać szyfrowania tam, gdzie przesyłamy wrażliwe informacje. Pierwszy krok może wymagać wysiłku, ale później stanie się drugą naturą. Twoja poczta może być naprawdę „prywatna” i „tylko dla adresata” – wystarczy wdrożyć opisane tu rozwiązania. Powodzenia w zabezpieczaniu swojej komunikacji!

Zapisz się też na bezpłatne szkolenie VOD – LPI Security Essentials, gdzie znajdziesz egzaminy próbne, prace domowe i checklisty przygotowujące do egzaminu.