Jak nauczyć się szyfrowania
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:
S/MIME (certyfikaty cyfrowe, identyfikatory cyfrowe)
(przeskocz do PGP)
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 klucze: prywatny i publiczny danej osoby.
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ć chroniony za wszelką cenę!
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:
- można wybrać klucz dowolnej długości (na przykład 4096 bitów!)
- certyfikat będzie zawierał nasze imię i wszystkie dane, które chcemy umieścić
- może być ważny nawet przez 30 lat!
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żnosci 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 niestety musicie wyrobić osobny certyfikat.
- swoje pełne imię i nazwisko
- miasto zamieszkania, region, kraj
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.
Możecie wejść na
strony z dokumentacją Certum
lub na
strony Signet
po instrukcje, jak zainstalować i korzystać z certyfikatu w swoim programie pocztowym
(wystarczy go zainstalować w dziale certyfikaty osobiste
lub podobnym).
Jeśli korzystacie z
Mozilli Thunderbirda,
to najpierw zainstalujcie plik DER (patrz niżej).
Potem wybierzcie Edycja(Narzędzia)--> Preferencje--> Zaawansowane-->Menadżer certyfikatów-->
Twoje certyfikaty--> 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).
Potem już tylko Edycja--> Konfiguracja kont--> Zabezpieczenia (pod jakimś kontem)-->
Wybierz certyfikat i
Podpisz wiadomości cyfrowo (domyślnie)
.
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 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.
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 cert2_klucz.pem -in cert2_cert.pem -out cert2_req.pem
Tak utworzone żądanie podpisujemy naszym certyfikatem głównym:
openssl ca -days 10000 -cert cert_glowny.pem -keyfile cert_glowny_klucz.pem -in cert2_req.pem -out cert_nowy.pem
UWAGA: podany tu czas ważnosci 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
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 na dyskietkach/płytach lub wysłać jako załączniki do listów.
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 (normalne litery i znaki).
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.
(przeskocz do szyfrowania plików)
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:
- Różni się sposób wyrabiania kluczy.
- Klucze wyrobione w standardzie PGP/OpenPGP NIE
są zgodne z certyfikatami
PKCS,
omówionymi wcześniej (z żadnym ich rodzajem, mimo iż na przykład tu i tu są klucze
RSA)
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ć chroniony za wszelką cenę!
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), 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
Mozilli Thunderbirda).
Aby móc uruchomić szyfrowaną korespondencję, należy wymienić się z odbiorcą kluczami publicznymi, na przykład
- dostać osobiście od tej osoby (na dyskietce, płycie, ...)
- poprosić go o wysłanie nam wiadomości z załącznikiem w postaci klucza w pliku .asc,
który sami zaimportujemy.
- ściągnąć ze strony WWW tej osoby i zaimportować ręcznie:
gpg --import plik_z_kluczem.asc
- ściągnąć z jednego z serwerów kluczy (jeśli znamy numer klucza, a właściciel umieścił go na serwerze):
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 from Bogdan 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 from Bogdan 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.
(przeskocz do zabezpieczania transmisji)
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 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ć truecrypt --create
, a program dalej poprowadzi użytkownika.
Pod Linuksem stworzone
pliki TrueCrypt montować należy poprzez truecrypt -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/truecrypt
chmod +s /ścieżka/do/truecrypt
chmod o+x /ścieżka/do/truecrypt
Nowsze wersje jednak bardziej dbają o bezpieczeństwo i bit suid już jest zabroniony. Zamiast tego,
TrueCrypt 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 TrueCrypt = nazwa_uzytkownika1, nazwa_uzytkownika2, ...
Defaults:TrueCrypt !authenticate
TrueCrypt localhost = (root) /usr/bin/truecrypt
Wpisując oczywiście prawidłowe nazwy użytkowników i ścieżkę do TrueCrypt.
Niestety, moduł jądra musi być w /usr/share/truecrypt/kernel, chyba że zmienimy to w kodzie programu.
Na szczęście zawsze można zrobić z tego dowiązanie symboliczne do innego katalogu, więc to nie
jest duży problem.
Po skończeniu pracy szyfrowaną partycję w Linuksie należy odmontować poleceniem
truecrypt -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.
(przeskocz do odnośników do algorytmów)
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 przeglądania stron swojego banku 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 (na przykład o2.pl) 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 często 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
Mozilla Thunderbird.
- 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 portal o2.pl 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; strona
projektu jest po polsku.
O tym, czym są te dziwne nazwy (MD5, SHA, RSA, DSA, El-Gamal, PKCS), możecie się dowiedzieć
na przykład stąd: