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) 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:
  1. 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ć: 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.
  1. 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).

  2. 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).

  3. 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.



Pretty Good Privacy (PGP) / GNU Privacy Guard (GPG)


(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: 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 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.
  1. 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.

  2. 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.

  3. 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.

Szyfrowanie danych na dysku


(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.
  1. 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.

  2. 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.

  3. 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.



Zabezpieczanie 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.
  1. 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.

  2. 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.

  3. 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.

  4. 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.



Jak to wszystko naprawdę działa


O tym, czym są te dziwne nazwy (MD5, SHA, RSA, DSA, El-Gamal, PKCS), możecie się dowiedzieć na przykład stąd:

Spis treści off-line (klawisz dostępu 1)
Spis treści on-line (klawisz dostępu 2)
Ułatwienia dla niepełnosprawnych (klawisz dostępu 0)