Na pewno każdemu z Was zdarzyło się kiedyś wysłać e-maila, którego treść powinna być przeczytana wyłącznie przez odbiorcę. Mógł to być list służbowy, zawierający ważne dane finansowe lub list bardzo prywatny. Na pewno nie chcielibyście, by taki list był przeczytany przez niewłaściwą osobę: szpiega przemysłowego, wścibskie rodzeństwo itd.
Tymczasem, nawet jeśli odbiorca chroni swój program pocztowy hasłem, to i tak Wasz list, zanim do niego trafi, przechodzi (w postaci jawnej) przez jakieś 20-30 serwerów.
Nie wierzycie? Wykonajcie polecenie
traceroute smtp.wasz.serwer.pocztowy.pl
(pod Windows jest tracert).
To polecenie pokazuje, jaką drogę przebywają pakiety (a więc i list), zanim dotrą do
Waszego serwera pocztowego. Potem jeszcze wasz list przechodzi od tego serwera do
serwera pocztowego odbiorcy, a potem do niego samego. Długa trasa, nieprawdaż?
A do tego na każdym skrzyżowaniu (routerze) czeka potencjalne zagrożenie.
Ten krótki artykuł uświadomi Wam, jak łatwo jest chronić swoją pocztę przed
nieodpowiednimi osobami oraz dać odbiorcy całkowitą pewność, że dany list pochodzi
właśnie od Was.
Spis treści:
Skrót S/MIME oznacza Secure Multipurpose Internet Mail Extensions. Jest to pewien standard, rozszerzający normalne MIME o możliwości szyfrowania. S/MIME opiera się na certyfikatach cyfrowych, które zawierają informacje o tym, kto jest właścicielem certyfikatu, oraz na kluczach danej osoby: prywatnym i publicznym.
Certyfikaty w standardzie PKCS, o których tu mowa, NIE są zgodne z kluczami w standardzie PGP/OpenPGP, które omówię później.
Klucz prywatny - służy do odszyfrowywania odebranych wiadomości oraz do cyfrowego podpisywania wysyłanych przez nas wiadomości. Dzięki temu odbiorca wie, że ich treść nie została zmieniona po drodze oraz że wiadomość rzeczywiście pochodzi od Was. Musi więc być dobrze chroniony!
Klucz publiczny - może być dowolnie rozdawany, gdyż to on umożliwia innym wysyłanie nam zaszyfrowanych wiadomości oraz sprawdzania cyfrowego podpisu w wiadomościach wysłanych przez nas. Musimy posiadać klucz publiczny (certyfikat publiczny) osoby, do której chcemy wysyłać zaszyfrowane wiadomości.
Aby móc wysyłać odbiorcy zaszyfrowane wiadomości, wystarczy posiadać jego certyfikat publiczny (który zawiera także klucz publiczny). Samemu teoretycznie nie trzeba mieć certyfikatu, ale większość programów pocztowych odmówi szyfrowania listów bez posiadania własnego certyfikatu, bo nie będzie ich potem można odszyfrować.
Ze względów bezpieczeństwa, nie można też szyfrować do odbiorcy, którego certyfikat stracił ważność.
A jak zdobyć dla siebie certyfikat? Jest kilka sposobów:
(przeskocz sposoby)wykupić w znanej firmie, na przykład Verisign, Comodo, Thawte, GlobalSign. W Polsce certyfikaty wydaje na przykład Unizeto Certum.
Jeśli certyfikat ma być bardzo wiarygodny (a więc i droższy), to należy podać firmie dużo szczegółów o sobie. W zamian dostajemy certyfikat oznaczony dużym zaufaniem i rozpoznawany przez większość programów pocztowych.
dostać za darmo w znanej firmie, na przykład CAcert, Comodo.
Zazwyczaj taki certyfikat będzie miał klucz średniej długości (a więc i średniej sile szyfrowania), na przykład 512 bitów, zwykle nie będzie w nim naszego imienia, tylko adres e-mail (który zawsze musi być), a certyfikat (skoro nie podaliśmy żadnych danych pozwalających na identyfikację) będzie miał niższy stopień zaufania i krótki okres ważności. Dlatego polecam Comodo, gdyż można tam wpisać swoje imię i wybrać długość klucza, a certyfikat będzie ważny przez rok (co jest dość długim okresem w porównaniu z innymi).
wyrobić sobie samemu - wystarczy dowolny system operacyjny z zainstalowanym pakietem OpenSSL na przykład Linux (ale są też wersje OpenSSL dla Windows).
Zalety takiego rozwiązania są duże:
Jedyną wadą będzie to, że nie będzie zaufany przez żadną znaną firmę, ale z tym też można sobie poradzić.
Jako że wyrobienie certyfikatu przez
WWW trwa tylko kilka minut i jest dość proste,
nie będę się tym zajmował. Firmy wydające posiadają dość dobre instrukcje, co należy wykonać.
Zamiast tego opiszę tutaj szczegółowo,
co należy zrobić, aby wyrobić go sobie samemu.
Wyrabianie certyfikatu z wykorzystaniem oprogramowania OpenSSL:
Wykonanie certyfikatu podpisanego przez samego siebie, o 2048-bitowym kluczu
RSA
(oficjalnie zalecana minimalna długość to 1024 bity), ważnego
przez około 30 lat:
(przeskocz wyrabianie certyfikatu prywatnego)
openssl req -x509 -days 10950 -newkey rsa:2048 -keyout cert1_key.pem -out cert1_cert.pem
UWAGA: podany tu czas ważności certyfikatu w dniach (10950) jest bliski górnemu limitowi (czy to limit OpenSSL, czy programów pocztowych, czy też samego standardu). Przekroczenie tej liczby może spowodować, że certyfikat będzie rozpoznawany, ale bezużyteczny!
UWAGA: domyślne ustawienia OpenSSL mogą spowodować wygenerowanie
certyfikatu, którego algorytm podpisu nie jest już bezpieczny (np. MD5) i będzie odrzucany np.
przez programy pocztowe. Aby tego uniknąć, można podać ręcznie nazwę algorytmu podpisu,
np. SHA512. Prawidłowe rozpoznanie takiego certyfikatu zależy jednak od możliwości
oprogramowania (systemów operacyjnych, programów pocztowych), które ma go używać.
Należy więc najpierw upewnić się, że dany algorytm podpisu jest obsługiwany.
Przykład wyrabiania certyfikatu z algorytmem SHA512:
(przeskocz wyrabianie certyfikatu prywatnego)
openssl req -x509 -days 10950 -newkey rsa:2048 -sha512 -keyout cert1_key.pem -out cert1_cert.pem
Należy podać tyle informacji o sobie, aby certyfikat był wiarygodny. Zalecam wpisać:
adres e-mail (bez tego w ogóle nie będzie można korzystać z certyfikatu). Jeśli posiadacie więcej niż jeden adres e-mail, to na każdy z tych adresów możecie wyrobić osobny certyfikat lub skorzystać z Subject Alternative Names (SAN).
Aby skorzystać z SAN, należy stworzyć kopię
domyślnego pliku konfiguracyjnego (OpenSSL wyświetla, gdzie on się znajduje),
po czym otworzyć plik w edytorze tekstu i pod koniec sekcji usr_cert
, a przed sekcją
v3_req
dodać listę swoich adresów e-mail:
subjectAltName = @alt_names [ alt_names ] email.1 = adres1@domena1.com email.2 = adres2@domena2.com ...oraz powiedzieć programowi
openssl
, aby skorzystał z tego pliku za pomocą opcji
-config nasza_kopia_openssl.cnf
Aby cała zabawa miała sens, nasz klucz prywatny musimy ochronić dobrym hasłem (czyli: co najmniej 8 znaków, litery duże i małe, cyfry i znaki specjalne).
Plik cert1_key.pem zawiera wasz klucz prywatny, musi więc być dobrze chroniony.
Wasz klucz prywatny nigdy nie zostanie wysłany przez żaden wiarygodny program pocztowy wbrew Waszej woli.
Wyeksportowanie naszego certyfikatu do formatu PKCS#12,
przyjmowanego przez większość programów pocztowych:
(przeskocz eksport certyfikatu)
openssl pkcs12 -export -in cert1_cert.pem -inkey cert1_key.pem -out cert1.p12 -name "Moj certyfikat"
W tracie wykonywania tego polecenia będziemy poproszeni o hasło chroniące nasz klucz prywatny (to, które wpisaliśmy w kroku 1) oraz o nowe hasło eksportowe, chroniące cały plik P12, łącznie z kluczem prywatnym. Jeśli nie zamierzacie po wszystkim skasować pliku P12 (zachowując pliki .pem), to w dalszym ciągu obowiązują powyższe reguły dobrego hasła.
Plik cert1.p12 zawiera wasz klucz prywatny i publiczny, musi więc być dobrze chroniony.
Instrukcje na temat tego, jak zainstalować i korzystać z certyfikatu w swoim programie pocztowym powinniście znaleźć w zasobach pomocy do tego programu.
Jeśli korzystacie z
Thunderbirda,
to najpierw zainstalujcie plik DER (patrz niżej).
Potem wybierzcie Edycja(Narzędzia)--> Preferencje--> Zaawansowane
(lub Prywatność i Bezpieczeństwo)-->Menedżer certyfikatów (lub Zarządzaj certyfikatami)-->
Twoje certyfikaty (lub Użytkownik)--> Importuj. Należy podać hasło chroniące plik P12 oraz hasło
Głównego Urządzenia zabezpieczającego
(Software Security Device).
To drugie będzie służyć
do obsługi wszystkich certyfikatów (abyście nie musieli pamiętać wszystkich haseł do
kluczy prywatnych).
Jeśli Thunderbird wyświetla, że hasło jest nieprawidłowe, a do wygenerowania pliku P12 użyliście
OpenSSL w wersji 3.0.0, należy do komendy eksportu dodać opcję
-legacy
:
openssl pkcs12 -legacy -export ...
Potem już tylko Edycja--> Konfiguracja kont--> pod wybranym kontem: Zabezpieczenia (lub Szyfrowanie
end-to-end
i sekcja S/MIME)-->
Wybierz certyfikat i Podpisz wiadomości cyfrowo (domyślnie)
(lub Domyślnie dodawaj mój podpis cyfrowy
).
Możemy już cyfrowo podpisywać wiadomości, ale nikt do nas nie będzie szyfrował, jeśli nie rozdamy innym naszego certyfikatu publicznego.
Niektóre programy pocztowe będą wymagać,
aby nasz certyfikat był wystawiony przez znaną im
firmę. Dlatego zainstalujemy im nasz certyfikat jako certyfikat firmy wystawiającej
(Certificate Authority, CA). Oto, co należy zrobić:
(przeskocz wyrabianie certyfikatu wystawcy)
openssl x509 -in cert1_cert.pem -outform DER -out cert1_cert.der
Otrzymany plik DER instalujemy w programie pocztowym w miejscu przeznaczonym dla wystawców certyfikatów, z pełnym zaufaniem i nasz certyfikat zdobywa zaufanie programu.
Wyrobienie certyfikatu publicznego z pliku P12 odbywa się tak:
(przeskocz wyrabianie certyfikatu publicznego)
openssl pkcs12 -in cert1.p12 -out cert1_pub.pem -nokeys -clcerts
openssl x509 -in cert1_pub.pem -outform DER -out cert1_pub.cer
openssl crl2pkcs7 -nocrl -certfile cert1_pub.pem -outform DER -out cert1_pub.p7b
Otrzymane w ten sposób pliki PEM, CER i P7B zawierają ten sam Wasz certyfikat PUBLICZNY (zawierający klucz publiczny), tylko w różnych formatach, odpowiednich dla różnych programów pocztowych.
Jest to ten sam certyfikat, który był w pliku cert1_cert.pem
.
Te pliki umieszczajcie wszędzie, gdzie to jest tylko możliwe tak, by jak najwięcej osób miało do nich dostęp (na przykład na swojej stronie WWW).
Możliwe jest, że wraz ze swoim certyfikatem publicznym będziecie musieli wysyłać też certyfikat wystawcy, utworzony punkt wcześniej.
Dla bezpieczeństwa możecie też oprócz samych plików certyfikatów, podawać też ich
skróty (odciski palców). Wyciąga się je w następujący sposób:
openssl x509 -in cert1_pub.pem -noout -fingerprint -md5
openssl x509 -in cert1_pub.pem -noout -fingerprint -sha1
w wyniku otrzymując coś postaci:
MD5 Fingerprint=76:7C:08:0C:55:3E:67:58:FF:15:88:D0:C5:D9:9D:8A
SHA1 Fingerprint=13:29:5D:79:D6:A5:B2:7A:A3:FD:A5:48:1D:E3:E0:EC:52:E0:63:0B
Możecie też w ten sposób weryfikować, czy pobraliście prawidłowo certyfikaty innych osób.
Wykonanie certyfikatu głównego do podpisywania innych.
(przeskocz wyrabianie certyfikatu głównego)
Jeśli po wykonaniu powyższych punktów działa szyfrowanie,
podpisywanie, importowanie
waszych certyfikatów u odbiorcy (czyli wszystko jest w porządku), to pomińcie ten punkt.
Może się zdarzyć że mimo zaimportowania (Waszego) certyfikatu wystawcy, program pocztowy
odbiorcy dalej uparcie nie chce zaimportować Waszego certyfikatu publicznego. W takim przypadku
nie kasujcie od razu tamtych plików, tylko czytajcie dalej (jeśli jednak skasowaliście, możecie
sobie wyrobić od nowa, według punktu 1, lub od razu jako żądanie podpisania certyfikatu,
pomijając opcję -x509
w punkcie 1).
Musicie sobie wyrobić mocny certyfikat główny
i użyć go do podpisania certyfikatów, które wyrobiliście na poszczególne adresy e-mail.
Certyfikat główny to nic innego jak samopodpisany certyfikat, więc
powtarzamy czynności z punktów 1 i 3
powyżej. Jako że certyfikatu głównego nie polecam do szyfrowania poczty, można pominąć adres
e-mail, oraz dać lepszy klucz (na przykład 4096 bitów).
Teraz certyfikaty na każdą skrzynkę, które wyrobiliście wcześniej, zamieniamy na
żądania podpisania
certyfikatu, dzięki czemu będzie je można podpisać naszym świeżym certyfikatem głównym:
openssl x509 -x509toreq -signkey cert1_klucz.pem -in cert1_cert.pem -out cert1_req.pem
Tak utworzone żądanie podpisujemy naszym certyfikatem głównym:
openssl ca -days 10000 -cert cert_glowny.pem -keyfile cert_glowny_klucz.pem -in cert1_req.pem -out cert_nowy.pem
UWAGA: podany tu czas ważności certyfikatu w dniach (10000) jest bliski górnemu limitowi (czy to limit OpenSSL, czy programów pocztowych, czy też samego standardu). Przekroczenie liczby 10950 może spowodować, że certyfikat będzie rozpoznawany, ale bezużyteczny i żadne podpisane nim certyfikaty nie będą mogły być importowane przez programy pocztowe!
UWAGA: jeśli certyfikat do podpisania zawiera inny algorytm podpisu
niż domyślny, to aby go zachować, należy powtórzyć go w poleceniu podpisania, np. dla SHA512:
openssl ca -days 10000 -cert cert_glowny.pem -keyfile cert_glowny_klucz.pem -in cert2_req.pem -md sha512 -out cert_nowy.pem
W celu zachowania Subject Alternative Names, należy ponownie użyć opcji
-config nasza_kopia_openssl.cnf
z tym samym plikiem konfiguracyjnym.
Z plików cert_nowy.pem i cert2_klucz.pem (klucz bez zmian) tworzymy plik PKCS#12 (według punktu 2) dla naszego programu pocztowego oraz certyfikaty publiczne dla odbiorców naszej poczty, według punktu 4. Odbiorcom naszej poczty dajemy swój nowy certyfikat publiczny (na przykład cert2.cer) i plik DER otrzymany z certyfikatu głównego według punktu 3, który instalujemy też u siebie jako wystawcę certyfikatów (z pełnym zaufaniem).
Większość programów pocztowych zaimportuje automatycznie Wasz certyfikat u odbiorcy, gdy po raz pierwszy otworzy on otrzymaną od Was wiadomość podpisaną cyfrowo. Do cyfrowego podpisania wiadomości używany jest klucz prywatny, ale podczas tej operacji sam klucz prywatny NIGDY nie jest wysyłany, jest bezpiecznie przechowywany przez program pocztowy.
Osoby mające Wasz certyfikat publiczny mogą do Was szyfrować. Abyście i Wy mogli to robić, musicie mieć certyfikat publiczny odbiorcy. Najprościej jest poprosić tego kogoś, aby przysłał Wam wiadomość podpisaną cyfrowo. Można też wymienić się certyfikatami publicznymi poprzez wysłanie ich jako załączników do listów lub w dowolny inny sposób.
Ważne, aby sprawdzić, czy odciski palców certyfikatów zgadzają się z tymi u nadawcy.
Od tej pory wasza korespondencja nie będzie mogła być przeczytana ani sfałszowana przez innych.
UWAGA: Najlepiej wszystkie wytworzone pliki należy zachować w kilku bezpiecznych miejscach (na przykład na płycie CD-R, którą potem starannie schowamy). Najważniejsze są cert1_key.pem i cert1_cert.pem, bo z nich da się odtworzyć resztę.
NIGDY nie należy umieszczać swoich kluczy prywatnych na żadnych publicznie dostępnych serwerach.
Jeśli chcecie do kogoś ręcznie zaszyfrować jakiś plik, niekoniecznie wysyłając e-mail, możecie to zrobić na jeden z następujących sposobów.
Szyfrowanie kluczem publicznym odbiorcy i swoim (aby móc to potem rozszyfrować),
nierozsądne bez podpisu:
(przeskocz ręczne szyfrowanie)
openssl smime -encrypt -in dane.txt -out dane.aes
-from adres@nadawcy -to adres@odbiorcy
-subject "Tajna wiadomosc" -aes256 cert_publ_odbiorcy1.pem cert_publ_odbiorcy2.pem
Powyższa komenda ma być w jednej linijce, a jako jeden z certyfikatów odbiorców podaj swój certyfikat publiczny!
Wadą tego podejścia jest to, że wynik jest w postaci części (lub całej) gotowej wiadomości e-mail, ale z tym też można sobie poradzić.
Opcja -encrypt
oczywiście włącza szyfrowanie.
Opcje -in
i -out
określają pliki, z których brać dane do
zaszyfrowania i gdzie je po zaszyfrowaniu umieścić.
Opcje -from
, -to
i -subject
określają odpowiednio:
adres nadawcy, adres odbiorcy i temat wiadomości (wynik tego polecenia można wysłać jak e-mail,
na przykład przez sendmail).
Opcja -aes256
określa typ użytego szyfru: 256-bitowy
AES.
Odszyfrowanie odbywa się tak:
openssl smime -decrypt -in dane.aes -inkey nasz_klucz_pryw.pem -recip nasz_cert_publ.pem
Opcja -recip
określa certyfikat publiczny odbiorcy (nasz).
Szyfrowanie kluczem publicznym odbiorcy i swoim oraz cyfrowe
podpisanie danych:
(przeskocz ręczne szyfrowanie z podpisem)
openssl smime -sign -in dane.txt -signer nasz_cert_publiczny.pem -inkey nasz_klucz_pryw.pem
| openssl smime -encrypt -out dane.aes
-from adres@nadawcy -to adres@odbiorcy
-subject "Tajna wiadomosc" -aes256 cert_publ_odbiorcy1.pem cert_publ_odbiorcy2.pem
Powyższa komenda ma być w jednej linijce, a jako jeden z certyfikatów odbiorców podaj swój certyfikat publiczny!
Zauważ symbol potoku |
, otrzymywany jako Shift+\.
Podobnie jak wyżej, wynik jest w postaci gotowej wiadomości e-mail.
Opcja -sign
powoduje cyfrowe podpisanie wiadomości.
Opcje -signer
i -inkey
pozwalają wybrać certyfikat i klucz podpisujący.
Odszyfrowanie i weryfikacja odbywają się tak:
(przeskocz weryfikację i odszyfrowanie)
openssl smime -decrypt -in dane.aes -inkey nasz_klucz_pryw.pem -recip nasz_cert_publ.pem |
openssl smime -verify -CAfile plik_z_CA.pem -signer cert_publ_nadawcy.pem
Opcja -CAfile
pozwala określić plik z zaufanymi certyfikatami
(czasem po prostu wystarczy cert_publ_nadawcy.pem).
Szyfrowanie na hasło (szyfrem symetrycznym)
(przeskocz szyfrowanie na hasło)
Najpierw sprawdzamy, jakie szyfry symetryczne obsługuje nasz program openssl:
openssl list-cipher-commands
Potem wybieramy jeden z nich, na przykład Blowfish (bf). Szyfrowanie odbywa się tak:
openssl enc -bf -a -salt -in dane.txt -out dane.txt.bf
Opcja -bf
włącza szyfrowanie właśnie algorytmem Blowfish.
Opcja -salt
wprowadza dodatkową losowość do klucza generowanego z hasła. Zalecane!
Opcja -a
włącza kodowanie zaszyfrowanych danych algorytmem BASE64, żeby zamiast
krzaczków
, w pliku wyjściowym były normalne znaki
ASCII.
NIE polecam szyfrów: IDEA, RC2, RC4, RC5 i dalszych RC, gdyż są one objęte patentami.
NIE polecam szyfrów: des-cbc, des, des-cfb, des-ofb, des-ecb ze względu na słabą siłę szyfrowania (klucz ma 56 bitów długości, co na dzisiejsze standardy jest o wiele za mało).
Wśród szyfrów może być wymieniony także base64
, ale
UWAGA: to nie jest szyfr! To
jest tylko rodzaj kodowania, jak alfabet Morse'a i każdy może to odczytać.
Jest to po prostu zamiana danych w postaci binarnej (z krzaczkami
) właśnie
na postać tekstową ASCII (litery i znaki drukowalne).
Odszyfrowanie odbywa się tak:
openssl enc -bf -a -in dane.txt.bf -d -out dane
Opcja -d
służy właśnie do odszyfrowywania.
Może się zdarzyć, że chcemy tylko cyfrowo podpisać jakiś plik, aby na przykład umieścić go na swojej stronie WWW i dać osobom go ściągającym możliwość weryfikacji, że rzeczywiście pochodzi od nas.
Aby utworzyć taki podpis, wystarczy sama komenda podpisywania z punktu 1 lub 2 powyżej:
openssl smime -sign -in dane.txt -inkey nasz_klucz_pryw.pem -signer nasz_cert_publ.pem -out dane.txt.sig
Weryfikacja takiego podpisu:
openssl smime -verify -in dane.txt.sig -CAfile cert_publ_podpisujacego.pem -signer cert_publ_podpisujacego.pem
Jak widać, czasem trzeba powiedzieć programowi openssl, jakim certyfikatom ufamy - w tym przypadku jest to certyfikat podpisujący, ale może być też nadrzędny.
Jeśli zamiast cyfrowego podpisu chcecie tylko otrzymać sumę kontrolną z jakiegoś pliku
(zwaną czasem odciskiem palca
), to
najpierw sprawdźcie, jakie macie dostępne funkcje skrótu w swoim openssl:
openssl list-message-digest-commands
Potem wystarczy wykonać na przykład
openssl md5 dane.txt
i dostajemy:
MD5(dane.txt)= 5bbd1174b345c17e9dac39e0da0002cd
NIE polecam funkcji skrótu
MD2,
MD4, MD5 i SHA1, gdyż
odkryto w nich pewne słabości.
Pretty Good Privacy i jego darmowy i wolny odpowiednik - GNU Privacy Guard - GPG (wersja dla Windows: gpg4win.org) również opierają się na parze kluczy: publicznym i prywatnym. Wszystkie zasady ochrony są takie same, jak wcześniej. Ale:
Wyrabianie kluczy przy użyciu PGP:
Jeśli macie program PGP dla Windows (jest też wersja całkowicie darmowa: PGP Freeware), to wszystko można zrobić przy użyciu myszy, a sam program współpracuje z większością programów pocztowych i automatycznie podpisuje, sprawdza i szyfruje wiadomości. Nie będę się więc zajmował dalszym jego opisem.
Jeśli korzystacie z różnych graficznych nakładek na gpg, to wyrobienie kluczy jest kwestią kilku kliknięć, więc nie będę się tym zajmował (tym bardziej że takich interfejsów jest wiele). Pokażę za to, jak wyrabiać klucze samym programem gpg:
Należy wydać polecenie
gpg --gen-key
,
a GPG dalej nas sam poprowadzi. W zasadzie należy wybierać to, co jest domyślne (default),
czyli ciągle wciskać Enter.
Jedynie można sobie wybrać dłuższy klucz (na przykład 2048 bitów) zamiast domyślnych 1024 bitów.
Po zakończeniu tworzenia kluczy, możemy wyświetlić ich listę:
gpg --list-keys
Klucz prywatny - służy do odszyfrowywania odebranych wiadomości oraz do cyfrowego podpisywania wysyłanych przez nas wiadomości. Dzięki temu odbiorca wie, że ich treść nie została zmieniona po drodze oraz że wiadomość rzeczywiście pochodzi od Was. Musi więc być dobrze chroniony!
Klucz publiczny - może być dowolnie rozdawany, gdyż to on umożliwia innym wysyłanie nam zaszyfrowanych wiadomości oraz sprawdzania cyfrowego podpisu w wiadomościach wysłanych przez nas. Musimy posiadać klucz publiczny osoby, do której chcemy wysyłać zaszyfrowane wiadomości.
Po wyrobieniu kluczy, należy dla bezpieczeństwa (na przykład aby móc je odzyskać w razie awarii)
wyeksportować swój klucz prywatny i publiczny:
(przeskocz eksport kluczy)
gpg --output klucz_gpg_pryw.asc --textmode --export-secret-keys --armor AABBCCDD
gpg --output klucz_gpg_publ.asc --textmode --export --armor AABBCCDD
(w miejsce
AABBCCDD należy wstawić numer swojego klucza uzyskany komendą gpg --list-keys
).
Tak przygotowany plik klucz_gpg_publ.asc, zawierający klucz publiczny, można rozsyłać pocztą i umieszczać na publicznych serwerach, stronach WWW itp., by jak najwięcej osób miało do niego dostęp.
Dla bezpieczeństwa możecie też oprócz samych plików kluczy, podawać też ich
skróty (odciski palców). Wyciąga się je w następujący sposób:
gpg --fingerprint 1C56DA1E
w wyniku otrzymując coś postaci:
pub 1024D/1C56DA1E 2004-11-06
Odcisk klucza = E91E 699F 1026 D0EF 745E EC3B 353A D368 1C56 DA1E
Możecie też w ten sposób weryfikować, czy pobraliście prawidłowo klucze innych osób.
Plik klucz_gpg_pryw.asc zawiera wasz klucz prywatny, musi więc być dobrze chroniony.
UWAGA:
Klucz prywatny należy zachować w kilku bezpiecznych miejscach (na przykład na płycie CD-R, którą potem
starannie schowamy). NIGDY nie należy umieszczać swoich kluczy prywatnych na
żadnych publicznie dostępnych serwerach.
Większość roboty (import kluczy, sprawdzanie podpisów, szyfrowanie) będą wykonywać za nas programy pocztowe. Niektóre mają wbudowaną obsługę GPG (na przykład Sylpheed lub nowy Thunderbird), do niektórych potrzebne są zewnętrzne moduły, które też będą automatycznie wykonywały robotę (na przykład pine-pgp do PINE'a, czy Enigmail do starszych wersji Thunderbirda).
Aby móc uruchomić szyfrowaną korespondencję, należy wymienić się z odbiorcą kluczami publicznymi, na przykład
gpg --import plik_z_kluczem.asc
gpg --keyserver wwwkeys.pgp.net --recv-keys AABBCCDD
Od tej pory wasza korespondencja nie będzie mogła być przeczytana ani sfałszowana przez innych.
Jeśli chcecie do kogoś ręcznie zaszyfrować jakiś plik, niekoniecznie wysyłając e-mail, możecie to zrobić na jeden z następujących sposobów. Odbiorcę możecie podać z nazwiska, numeru klucza lub adresu e-mail.
szyfrowanie kluczem publicznym odbiorcy i swoim (aby móc to potem rozszyfrować),
nierozsądne bez podpisu:
(przeskocz szyfrowanie PGP bez podpisu)
gpg -a -e -r odbiorca1 -r odbiorca2 dane.txt
(jeden z odbiorców to Wy - podajecie swój e-mail lub numer klucza).
Potem dajecie odbiorcom plik dane.txt.asc, który można rozszyfrować tak:
gpg dane.txt.asc
Opcja -a
powoduje, że w pliku wyjściowym będą tylko normalne znaki
ASCII,
żadnych krzaczków
.
Gdybyśmy nie podali -a
, program gpg utworzyłby ten sam plik, ale w postaci binarnej:
dane.txt.gpg, zawierający krzaczki
.
Opcja -e
oznacza właśnie szyfrowanie (domyślne działanie gpg to rozszyfrowywanie).
Po opcji -r
podajemy odbiorcę.
Dzięki opcji -R odbiorca2
(nie pokazanej tutaj) pozwala ukryć informację,
że wiadomość została zaszyfrowana także do innych
osób (odbiorca2
), niż główny odbiorca.
Dzięki opcji --multifile
(nie pokazanej tutaj)
można szyfrować więcej niż jeden plik na raz.
Dotyczy to także dalszych punktów.
szyfrowanie kluczem publicznym odbiorcy i swoim oraz cyfrowe podpisanie danych:
(przeskocz ręczne szyfrowanie PGP z podpisem)
gpg -a -e -s -r odbiorca1 -r odbiorca2 dane.txt
Rozszyfrowanie jak poprzednio, ale tutaj dodatkowo otrzymacie informację o podpisie.
Opcja -s
włącza cyfrowe podpisywanie danych. Upewni to odbiorcę, że
wiadomość nie została sfałszowana.
szyfrowanie na hasło (szyfrem symetrycznym)
(przeskocz szyfrowanie PGP na hasło)
Najpierw sprawdzamy, jakie szyfry symetryczne obsługuje nasz program gpg:
gpg --version
(oglądamy listę Symetryczne
lub Cipher
, w zależności od
wersji językowej programu).
Potem wybieramy jeden z nich, na przykład Blowfish. Szyfrowanie odbywa się tak:
gpg -a --cipher-algo blowfish -c dane.txt
Opcja -c
włącza szyfrowanie algorytmem symetrycznym.
Opcja --cipher-algo
pozwala wybrać algorytm szyfrowania.
Dla lepszego zabezpieczenia, można połączyć ten sposób z powyższymi.
Dostaniemy wtedy plik, który można odszyfrować zarówno hasłem, jak i kluczem.
Często widać na stronach WWW, że obok różnych plików do ściągnięcia,
są ich podpisy cyfrowe w osobnych plikach. Zrobienie takiego pliku nie jest trudne:
gpg -a -b dane.txt
Opcja -b
powoduje właśnie utworzenie takiego oddzielnego pliku dane.txt.asc
z podpisem dla pliku dane.txt.
Sam plik dane.txt nie jest szyfrowany!
Gdybyśmy nie podali -a
, program gpg utworzyłby ten sam plik z podpisem, ale w
postaci binarnej: dane.txt.sig, zawierający krzaczki.
Sprawdzenie takich podpisów jest też łatwe:
(przeskocz weryfikację dobrego podpisu)
gpg --verify dane.txt.asc gpg: Signature made sob 25 mar 2006 14:27:21 CET using DSA key ID 1C56DA1E gpg: Good signature fromBogdan Drozdowski <xxxx@yy.pl>
Tutaj podpis
jest prawidłowy (słowo Good
). Oznacza to, że plik nie uległ zmianom
od chwili jego podpisania.
Gdyby ktoś go specjalnie zmienił (lub na przykład wystąpił błąd w transmisji), podpis będzie
nieprawidłowy (słowo BAD
):
(przeskocz weryfikację złego podpisu)
gpg --verify dane.txt.asc gpg: Signature made sob 25 mar 2006 14:27:21 CET using DSA key ID 1C56DA1E gpg: BAD signature fromBogdan Drozdowski <xxxx@yy.pl>
Jeśli
zamiast cyfrowego podpisu chcecie tylko otrzymać sumę kontrolną z jakiegoś pliku
(zwaną czasem odciskiem palca
), to
najpierw sprawdźcie, jakie macie dostępne funkcje skrótu w swoim gpg:
gpg --version
(oglądamy listę Skrótów
lub Hash
, w zależności od wersji
językowej programu).
Potem wystarczy wykonać na przykład
gpg --print-md sha512 dane.txt
i dostajemy:
(przeskocz przykład sumy kontrolnej)
dane.txt: DB1B46EE C66D6574 ABE6FC48 7EA40F63 B148DAB8 9F9F7142 BDC5E9F6 55B2924B 71D5C017 04945C48 0EEC28CC E0A7F41B 2BBAEB5A 7DADC7FD E0B47FCE 3529F58B
NIE polecam funkcji skrótu MD5 i SHA1, gdyż odkryto w nich pewne słabości.
Nawet jeśli nie musicie szyfrować poczty, to często jest potrzeba zaszyfrowania samych danych na dysku (informacji poufnych, ściągniętej niezaszyfrowanej poczty, historii przeglądanych stron internetowych, treści prowadzonych rozmów). Jest na to wiele sposobów.
Szyfrowanie na hasło.
Powyżej podałem dwa
sposoby szyfrowania na hasło. Niestety, jeśli chcemy szyfrować w ten sposób wiele
plików, to te czynności stają się nudne, czasochłonne i łatwo się pomylić. Najwygodniej
jest na przykład spakować wszystkie poufne pliki w jedno archiwum. Jeśli wybierzemy format ZIP
lub 7zip,
szyfrowanie można włączyć już w czasie pakowania. Inne spakowane archiwa można ręcznie
zaszyfrować na hasło jednym z podanych sposobów. Dzięki temu hasło jest wpisywane tylko raz.
Ma to jednak pewną wadę: po skorzystaniu z plików należy je ponownie spakować i usunąć z
dysku. Jak wiemy, samo usunięcie pliku nie wystarcza, gdyż tak naprawdę jest usuwana informacja
o samym istnieniu pliku, zaś jego zawartość nadal pozostaje na dysku.
Taką zawartość można
odzyskać nawet po 2-3 zamazaniach. Dlatego niezbędne jest bezpieczne usuwanie
plików (jednym z wielu dostępnych darmowych programów, na przykład shred
w Linuksie)
i zamazanie wolnego miejsca na dysku raz na jakiś czas.
Szyfrowanie partycji, całego dysku twardego lub urządzeń wymiennych.
Zamiast ciągle pakować i rozpakowywać archiwum z tajnymi plikami, wygodniejsze może być założenie sobie szyfrowanej partycji dysku twardego (lub nawet całego dysku) lub całego urządzenia przenośnego (na przykład dysk wymienny na USB). Po podaniu hasła takie urządzenie byłoby widoczne w systemie jak normalny dysk twardy, z pełną możliwością kopiowania, zapisywania i usuwania danych.
Pod Linuksem są co najmniej dwa narzędzia oferujące taką funkcjonalność: losetup
oraz
cryptsetup-luks
, ale ja zalecam otwarty program VeraCrypt (następcę programu TrueCrypt), który działa pod Linuksem i Windows, a jest dość
łatwy w obsłudze - pod Windows ma nawet interfejs graficzny, pod Linuksem wystarczy
uruchomić veracrypt --create
, a program dalej poprowadzi użytkownika.
Pod Linuksem stworzone
pliki VeraCrypt montować należy poprzez veracrypt -u plikTrueCrypt katalogMontowania
,
zaś sam program truecrypt powinien móc być uruchamiany z prawami administratora przez
zwykłego użytkownika. W starszych wersjach programu wystarczyło ustawić bit suid komendami
wydanymi jako root:
chown root.root /ścieżka/do/veracrypt
chmod +s /ścieżka/do/veracrypt
chmod o+x /ścieżka/do/veracrypt
Nowsze wersje jednak bardziej dbają o bezpieczeństwo i bit suid już jest zabroniony. Zamiast tego,
VeraCrypt powinien móc sam się uruchomić używając komendy suid. Aby na to zezwolić,
jako root wydajemy komendę visudo
. Otwiera ona plik
/etc/sudoers w trybie edycji i sprawdzania składni przy wyjściu (bardzo ważne).
Należy dodać następujące linijki:
User_Alias VeraCrypt = nazwa_uzytkownika1, nazwa_uzytkownika2, ... Defaults:VeraCrypt !authenticate VeraCrypt localhost = (root) /usr/bin/veracrypt
Wpisując oczywiście prawidłowe nazwy użytkowników i ścieżkę do VeraCrypt.
Po skończeniu pracy szyfrowaną partycję w Linuksie należy odmontować poleceniem
veracrypt -d katalogMontowania
Jeszcze jedna uwaga: nie wolno normalnie przenosić plików na zaszyfrowaną partycję. Przeniesienie plików może spowodować ich skopiowanie, po czym normalne usunięcie na dysku źródłowym (dzięki czemu można byłoby je odzyskać). Należy zamiast tego skopiować te pliki, po czym bezpiecznie je usunąć z dysku źródłowego.
Trochę informacji o szyfrowaniu partycji jest też w dokumencie o zabezpieczaniu serwera Tor. O samym programie Tor czytaj poniżej, w sekcji o zabezpieczaniu transmisji.
Szyfrowanie pliku lub partycji wymiany (swap).
Moglibyście spytać, po co to. Załóżmy, że właśnie macie uruchomiony program pracujący na którymś z poufnych plików. Za chwilę uruchomicie inny duży program (pakiet biurowy, przeglądarkę, ...). Spowoduje to, że na wszystkie uruchomione programy nie wystarczy pamięci w komputerze. System operacyjny w takiej sytuacji przeniesie część waszego ważnego programu (a pewnie i część owych poufnych danych) na dysk, do pliku wymiany, co jest zupełnie normalnym działaniem. Teraz poufne dane leżą niezaszyfrowane na dysku i każdy może je odczytać. Za jakiś czas te dane zostaną stamtąd usunięte (może dopiero po kolejnym włączeniu komputera?), ale nie jest to usuwanie bezpieczne. Oryginalne dane dalej mogą sobie być na szyfrowanej partycji, ale w niezaszyfrowanej postaci można je odzyskać z dysku.
Jak się przed tym bronić? Założyć szyfrowaną pamięć wymiany.
Windows: przeczytaj odpowiednią sekcję dokumentu o zabezpieczaniu serwera Tor. O samym programie Tor czytaj poniżej, w sekcji o zabezpieczaniu transmisji.
OS X: przeczytaj odpowiednią sekcję dokumentu o zabezpieczaniu serwera Tor. O samym programie Tor czytaj poniżej, w sekcji o zabezpieczaniu transmisji.
OpenBSD: w opcjach systemowych /etc/sysctl.conf ustaw
vm.swapencrypt.enable=1
.
Przeczytaj też odpowiednią sekcję dokumentu o
zabezpieczaniu serwera Tor. O samym programie Tor czytaj poniżej, w sekcji o
zabezpieczaniu transmisji.
Szyfrowana pamięć wymiany we FreeBSD. Przeczytaj też odpowiednią sekcję dokumentu o zabezpieczaniu serwera Tor. O samym programie Tor czytaj poniżej, w sekcji o zabezpieczaniu transmisji.
Linux: skorzystać z programu losetup
, cryptsetup-luks
lub ze
skryptów CryptoSwap.
Przykładowe wykorzystanie cryptsetup: w pliku startowym
zawierającym uruchamianie pamięci wymiany (na przykład /etc/rc.sysinit), tuż PRZED linią uruchamiającą
pamięć wymiany (linia z komendą swapon), dopiszcie:
cryptsetup -c blowfish -d /dev/urandom create swap /dev/hdXY
mkswap /dev/mapper/swap > /dev/null
zamieniając, rzecz jasna, /dev/hdXY na Waszą partycję wymiany lub nazwę pliku wymiany.
Po tych zmianach należy otworzyć plik /etc/fstab i zmienić urządzenie wymiany, na przykład z
/dev/hdXY swap swap defaults 0 0
na
/dev/mapper/swap swap swap defaults 0 0
W pliku uruchamianym przy zamykaniu systemu i odpowiedzialnym za wyłączenie pamięci wymiany
(na przykład /etc/rc.d/init.d/halt), tuż PO linii wyłączającej pamięć wymiany (linia z komendą
swapoff) należy dopisać:
cryptsetup remove swap
Po ponownym uruchomieniu systemu pamięć wymiany będzie szyfrowana wybranym algorytmem i za
każdym razem innym, losowym kluczem.
Dla bezpieczeństwa można aktualną partycję wymiany zamazać poleceniem shred
(najlepiej robić to, gdy jest nieużywana, na przykład gdy system został uruchomiony tylko w trybie
tekstowym lub po komendzie telinit 3):
swapoff /dev/hdXY
shred /dev/hdXY
Oczywiście, po tej operacji nie ma już partycji wymiany, więc najlepiej wykonać ją już po
powyższych zmianach w plikach systemowych, po czym ponownie uruchomić system.
Przeczytaj też odpowiednią sekcję dokumentu o zabezpieczaniu serwera Tor. O samym programie Tor czytaj poniżej, w sekcji o zabezpieczaniu transmisji.
Szyfrowanie danych na dysku nic nie da, jeśli są one wysyłane przez sieć w postaci jawnej. Nie mówię tutaj o poczcie, którą po lekturze poprzednich sekcji umiemy już szyfrować. Mówię tu o takich sprawach jak: hasła do poczty i na inne strony WWW, rozmowy w komunikatorze, oraz same odwiedzane strony internetowe. Jeśli połączenie jest nieszyfrowane, każdy może zobaczyć Wasze hasła, przeczytać treść rozmów i dowiedzieć się, jakie strony oglądacie. Jak się przed tym bronić? Należy szyfrować wszelkie wysyłane dane. Zobaczmy, co można zrobić w tej kwestii.
Przeglądanie WWW (w tym poczty).
Jeśli serwer, z którym się łączycie, ma obsługę SSL/ TLS, to od tej pory używajcie bezpiecznych połączeń, wpisując HTTPS zamiast HTTP w pasku adresu w przeglądarce. Protokołu SSL/TLS należy bezwzględnie korzystać w czasie korzystania z bankowości elektronicznej oraz (jeśli możliwe) poczty.
Aby sprawdzić, czy serwer to obsługuje, wpisz HTTPS zamiast HTTP w polu adresu i sprawdź, czy przeglądarka się połączy normalnie.
Poczta w programach pocztowych
Dobre skrzynki pocztowe oferują połączenia szyfrowane POP3+SSL/TLS (port 995/110)
i SMTP+SSL/TLS (port 25). Należy bezwzględnie włączyć je w swoim programie pocztowym. Połączenie
SSL jest czasami nazywane bezpiecznym połączeniem
, a TLS bezpiecznym uwierzytelnianiem
(hasła)
.
Jeśli serwer pocztowy tego nie obsługuje, można rozważyć przesiadkę na inny. Jeśli skrzynka to obsługuje, a program nie, należy koniecznie zmienić program na bardziej bezpieczny. Polecam Thunderbirda.
Komunikator
Jeśli używasz popularnego słoneczka
, to wiedz, że wprowadzenie szyfrowania
jest w trakcie... już od dłuższego czasu.
Stan wprowadzenia ani stopień zabezpieczenia są nieznane. Szyfrowanie od odbiorcy do nadawcy
można wprowadzić, ale jest to sprzeczne z regulaminem. Pomyśl o zmianie komunikatora i czytaj dalej.
Jeśli używasz Tlenu, możesz czuć się połowicznie bezpieczny. Twoje rozmowy są szyfrowane na
drodze od Ciebie do serwera i od serwera do odbiorcy wiadomości. Na serwerze można je jednak
zobaczyć w postaci jawnej. Ale i tak znacznie lepiej niż słonko
. Tlen jest z rodziny Jabbera
(czytaj niżej), ale właściciel zdecydował się samolubnie go zamknąć i rozszerzać,
nie dzieląc się osiągnięciami ze społecznością, od której otrzymał Jabbera. Zamknięcie protokołu
zawsze wprowadza pewną niepewność.
Jeśli używasz Jabbera , możesz czuć się jeszcze bezpieczniejszy. Protokół Jabbera jest międzynarodowy, otwarty i ma wbudowane zabezpieczenia. Twoje rozmowy są szyfrowane na drodze od Ciebie do serwera i od serwera do odbiorcy wiadomości. Na serwerze można je jednak zobaczyć w postaci jawnej.
Jabber ma jednak wspaniałą cechę: wbudowaną obsługę PGP - tego samego, którego wcześniej się uczyliśmy w celu zabezpieczenia poczty. Po włączeniu SSL i PGP Twoje rozmowy są szyfrowane na drodze do serwera jednym kluczem, na drodze od serwera do odbiorcy - innym i na drodze od nadawcy do odbiorcy - kluczem PGP. Jeśli wiadomość musi być przechowana na serwerze, to jest tam zaszyfrowana kluczem PGP i niemożliwa do odczytania.
Jabber z włączonymi SSL i PGP gwarantuje największe bezpieczeństwo rozmów.
Anonimowość
Czasem samo szyfrowanie przesyłanych treści nie wystarcza. Przeglądarka i tak zdradzi, z jakim serwerem chcemy się połączyć oraz nasz adres IP, a komunikator zdradzi nasz adres IP. Czasem sama wiedza o tym, z jakimi stronami WWW się łączymy pozwala wyciągnąć o nas wnioski (w którym banku mamy konto, na którym serwerze skrzynkę, na które forum piszemy). Na szczęście i przed tym można się bronić.
Rozwiązaniem są różne programy anonimizujące nasze działania w sieci. Jednym z takich programów jest darmowy i otwarty Tor (torproject.org), wspierany przez Electronic Frontier Foundation, która broni praw człowieka w sieci. Zasada działania jest prosta: zamiast łączyć się bezpośrednio z serwerem docelowym, nasze programy najpierw łączą się z zainstalowanym u nas Torem, a ten przez sieć serwerów na całym świecie przekierowuje nasz ruch do serwera docelowego. Cały ruch, aż od ostatniego węzła do serwera docelowego, jest szyfrowany (jeśli łączysz się przez SSL lub TLS, cały ruch jest szyfrowany). Serwerowi docelowemu wydaje się, że łączysz się z innego adresu niż naprawdę. I o to chodzi. Instalacja Tora jest prosta, konfiguracja programów, by go używały - też. Polecam.
O tym, czym są te dziwne nazwy (MD5, SHA, RSA, DSA, El-Gamal, PKCS), możecie się dowiedzieć na przykład stąd: