|
wersja 1.20 |
|
Spis treści |
ChangeLog Wstęp O programie GnuPG O kryptografii słów kilka O instalacji Start - generowanie kluczy, konfiguracja Eksportowanie klucza publicznego Importowanie klucza publicznego Szyfrowanie informacji Deszyfrowanie plików Szyfrowanie symetryczne Podpisy cyfrowe: -- zwykłe --clearsign --detach Program pgp4pine mutt - konfiguracja Instalacja oprogramowania a gpg Posłowie |
| ChangeLog |
Zmiany od wersji 1.11: - dodano opis sprawdzania wiarygodności instalowanego oprogramowania Zmiany od wersji 1.0: - dodano opis konfiguracji dla programu mutt Serdeczne podziękowania dla Pawła O. - 'Paszy' Zmiany od wersji 1.0a: - dodano opis instalacji pgp4pine (program do automatycznego szyfrowania i deszyfrowania wiadomości dla programu pocztowego pine). Podziękowania dla W. Kotwicy za dziesiątki porawek językowych. |
| Wstęp |
Tekst ten ma za zadanie zapoznać użytkownika z programem GnuPG. Zostaną omówione jego podstawowe funkcje oraz zastosowania. Pojęcia dotyczące kryptografii zostaną przedstawione powierzchownie, ale wystarczająco aby wiedzieć, co się dzieje oraz co do czego służy. I jeszcze jedno: do napisania poniższego tekstu wykorzystywałem wersję 1.0.4 GnuPG działającą oczywiście pod Linuxem (Slackware 7.0). Tak więc, zaczynamy! |
| O programie |
GnuPG oznacza GNU Privacy Guard i jest narzędziem przeznaczonym do bezpiecznej komunikacji i przechowywania danych. Generalnie program jest kompatybilny z powszechnie(?) stosowanym programem PGP firmy NAI Inc. Nie wykorzystuje on (GnuPG) algorytmów IDEA oraz RSA (patenty i takie tam) i dlatego nie jest on objęty żadnymi ograniczeniami. GnuPG dostępny jest na platformy Unixowe oraz systemy firmy M$: Win9x oraz WinNT. Program możemy pobrać spod adresu www.gnupg.org . Znajduje się tam również obszerna dokumentacja, FAQ itp. |
| O kryptografii słów kilka(set) |
Teraz trochę o szyfrowaniu "asymetrycznym". Polega ono na tym, iż posiadamy dwa klucze: jeden z nich jest dostępny publicznie, dla wszystkich. Jest to klucz publiczny (logiczne). Drugi klucz, nazywany prywatnym, posiadamy tylko my i nikt więcej. Cechą charakterystyczną jest fakt, iż opublikowanie jednego z kluczy, występującego w parze, nie zdradza drugiego klucza, nawet przy złożonych obliczeniach. Idea wykorzystania szyfrowania asymetrycznego jest następująca: a) Aby zaszyfrować list do kolegi, np. Heńka, musimy być w posiadaniu jego klucza publicznego. Z tym nie powinno być problemów, ponieważ może być on publicznie udostępniany. Wiadomość jest więc szyfrowana kluczem publicznym Heńka. Po zaszyfrowaniu, może ona być odszyfrowana tylko i wyłącznie kluczem prywatnym. W jego posiadaniu jest oczywiście Heniek. My wysyłając zaszyfrowaną wiadomość możemy być pewni, że nawet jeśli wpadnie ona w niepowołane ręce, nie zostanie ona odszyfrowana. Wiadomość odczyta tylko osoba mająca pasujący do klucza publicznego klucz prywatny: w tym wypadku Heniek. To jest właśnie szyfrowanie. Podsumowując: aby zaszyfrować list do Heńka, musimy użyć jego klucza publicznego! b) A co się stanie, gdy wiadomość "zaszyfrujemy" naszym kluczem prywatnym? Klucz publiczny, potrzebny do odczytania wiadomości jest publicznie dostępny. Odczyta ją nie tylko Heniek. Czy ma to sens? Ano ma, taki, że osoba, która ten list odczyta może być pewna , że my i tylko my mogliśmy go napisać. Nikt nie może zmienić naszego listu po drodze, podrobić go, zamienić, ponieważ aby to zrobić potrzebny jest klucz prywatny (który tylko my posiadamy). W ten sposób dochodzimy do pojęcia "podpisu cyfrowego", Każda modyfikacja tak "podpisanego" dokumentu, bez klucza prywatnego, nie uda się, ponieważ wtedy nie będzie można kluczem publicznym odszyfrować wiadomości. Pamiętaj: każdy klucz publiczny ma tylko jeden pasujący do niego klucz prywatny. Prawda, że proste? Podsumowując: Aby podpisać się pod jakimś dokumentem, żeby odbiorca wiedział, że my i tylko my go napisaliśmy, używamy naszego klucza prywatnego! Należy jeszcze wspomnieć, że istnieją algorytmy szyfrowania asymetrycznego, które mogą być użyte jedynie do obsługi podpisu cyfrowego ( czyli deszyfrują kluczem publicznym wiadomość zaszyfrowaną kluczem prywatnym). Przykładem może być DSA, które jest amerykańskim standardem podpisów cyfrowych. Istnieją również algorytmy, które potrafią obsługiwać zarówno podpis cyfrowy (szyfrowanie kluczem prywatnym), jak i szyfrować wiadomości ( szyfrowanie k. publicznym - odczyt tylko prywatnym ). Przykładem takiego algorytmu jest algorytm ElGamala. Podsumowując: Algorytm DSA służy jedynie składaniu podpisów cyfrowych - każdy taką wiadomość może odczytać, ale jest pewien, że Ty jesteś autorem. Algorytm ElGamala można wykorzystać natomiast zarówno do szyfrowania wiadomości, jak i do składania podpisów elektronicznych. Dobra, trochę dużo zrobiło się tej teorii. Wróćmy do programu GnuPG, aby zobaczyć, jak to się sprawdza w praniu. |
| O instalacji |
Instalacja programu nie powinna stworzyć większych (czytaj: żadnych) kłopotów, dlatego zakładam, że wszystko zostało pomyślnie skompilowane i zainstalowane. Dwie uwagi: * prawdopodobnie przy każdym wywołaniu programu 'gpg' będziesz widział komunikat: "Warning: using insecure memory!" (w wolnym tłumaczeniu: używam niezabezpieczonej pamięci). Aby temu zapobiec, jako root (superużytkownik) musimy nadać suida programowi (chown +s gpg). Z grubsza rzecz biorąc chodzi o to, że ktoś mógłby podejrzeć stronę pamięci, w której chwilowo przechowywane są ważne informacje ( ale jest to wyższa szkoła jazdy, i raczej nikt nie bierze tego pod uwagę). Dokładne info znajduje się w dokumentacji programu. * Teraz coś, co nie powinno się zdarzyć: przy generacji par kluczy (o tym zaraz) wyskoczył mi komunikat o błędzie, że w domowym katalogu nie może utworzyć, lub że nie istnieje plik '.gnupg/random_seed'. Ja zrobiłem to ręcznie - po prostu wydałem polecenia 'touch .gnupg/random_seed' i 'chmod 600 .gnupg/random_seed'. Oczywiście katalog '.gnupg' w katalogu domowym istnieje i ma 'chmod 700'. Pewnie jest to moja wina, bo niezbyt dokładnie przeczytałem instrukcje dot. instalacji :) |
| Start - generowanie kluczy,konfiguracja |
Na początek musimy wygenerować dla siebie parę kluczy: klucz publiczny i pasujący tylko do niego klucz prywatny, oczywista. Wydajemy więc polecenie gpg --gen-key . Efekt jest taki: [........bla bla bla.....] Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (4) ElGamal (sign and encrypt) Your selection? GnuPG potrafi stworzyć różne rodzaje kluczy, jednak nasz klucz główny (primary key) musi potrafić generować podpisy cyfrowe (signatures). Jak napisałem wcześniej, DSA może służyć jedynie podpisom cyfrowym, natomiast ElGamal podpisom i szyfrowaniu. Zaleca się wybranie opcji (1), w wyniku czego wygenerowane zostaną dwie pary kluczy: para k. publiczny - k. prywatny dla DSA oraz tak para kluczy dla ElGamala. Piszemy 1 lub naciskamy 'Enter' aby zaakceptować pierwszą opcję. Widzimy: DSA keypair will have 1024 bits. About to generate a new ELG-E keypair. minimum keysize is 768 bits default keysize is 1024 bits highest suggested keysize is 2048 bits What keysize do you want? (1024) Musimy teraz wybrać długość naszego klucza. Im większy on jest, tym większą mamy pewność, że metodą prób i błędów nikt nie "zgadnie" naszego klucza prywatnego. Długość 768 bitów nie jest zalecana, choć prawdopodobieństwo jego złamania jest niewielkie. Pełne bezpieczeństwo gwarantuje nam klucz długości 1024 bitów. Długość 2048 bitów przeznaczona jest dla maniaków i wariatów ;). Osobiście używam klucza długości 1024 bitów. Dla DSA automatycznie zostanie wygenerowany klucz długości 1024 bitów, w algorytmie ElGamala możemy ją sobie wybrać. Proponuje zaakceptować długość domyślną - 1024 bity. Naciskamy więc 'Enter', lub wpisujemy 1024. Następnie musimy wybrać okres ważności naszego klucza: Please specify how long the key should be valid. 0 = key does not expire domyślną: 0. Jeśli nie mamy ważnego powodu, aby nasz klucz stracił wartość za jakiś czas, ponownie akceptujemy wartość domyślną: 0. Jeśli jednak chcemy, żeby nasz klucz przestał być ważny np. za 5 miesięcy, wpisujemy 5m i naciskamy 'Enter'. Następnie program pyta, czy wygenerować klucze z powyższymi ustawieniami. Is this correct (y/n)? Jeśli wszystko jest o.k. wpisujemy y i naciskamy 'Enter'. Następnie użytkownik musi wprowadzić swoje dane, aby np. osoba która będzie importowała jego klucz publiczny, wiedziała do kogo on należy. Program prosi o to, w taki sposób: You need a User-ID to identify your key; the software constructs the user id from Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) Real name: a następnie naciskamy 'Enter'. Uwaga: minimalna długość: 5 znaków Email address: Tutaj wpisujemy nasz adres e-mailowy. Comment: W tym miejscu wpisujemy dodatkowe informacje o nas, komentarz, np. Prezes klubu sportowego Tecza a następnie naciskamy 'Enter'. Następnie program pyta nas, czy wprowadzone przed chwilą informacje dotyczące imienia i nazwiska, komentarza, adresu emaliowego są prawidłowe. Daje nam on szansę zmiany tych danych, jeśli zrobiliśmy jakiś błąd wprowadzając te dane. Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? Wpisując n lub N możemy poprawić nasze imię lub/i nazwisko. Wpisując c lub C możemy zmienić komentarz, uwagi dodatkowe. Wpisując e lub E możemy poprawić nasze adres e-mailowy. Jeśli wszystkie dane się zgadzają, piszemy o lub O i stukamy w 'Enter'. Jeśli zmieniliśmy jed nak nasze zdanie i chcemy żeby program przerwał pracę i nic nie generował, wpisujemy q lub Q. Uwaga, teraz najważniejsze! You need a Passphrase to protect your secret key. Enter passphrase: Znów trochę teorii: nasz klucz prywatny, najważniejszy element programu i całej filozofii szyfrowania musi być gdzieś zapisany. Jest on oczywiście zapisany na dysku. Oznacza to, że ktoś mógłby go odczytać, np. wścibski administrator naszego systemu itp., a wówczas wszystkie zabezpieczenia biorą w łeb. Dlatego też GnuPG przechowuje nasz klucz prywatny (na dysku) w postaci zaszyfrowanej. Jest to szyfrowanie symetryczne - takie, przy którym do szyfrowania jak i do deszyfrowania używa się tego samego klucza, hasła. Nasz klucz prywatny jest więc zaszyfrowany i nawet, gdy ktoś będzie miał dostęp do niego, nic mu z tego :) GnuPG w tym właśnie miejscu prosi nas o wpisanie hasła chroniącego nasz klucz prywatny. Jest to jedyne i najważniejsze hasło, które powinniśmy pamiętać. Można to ująć krótko: program GnuPG gwarantuje nam 99,99...%-owe bezpieczeństwo, jeśli jednak nasze hasło jest proste, możemy sobie darować "zabawę" w szyfrowanie. Wiele już napisano o tzw. "bezpiecznych hasłach". Za minimalne hasło spełniające warunki bezpieczeństwa należy przyjąć hasło mające długość przynajmniej 7 znaków, wśród których muszą się znaleźć małe i duże litery oraz cyfry. Przykład: Has34lO. Oczywiście, nie muszę pisać, że należy je zapamiętać i nigdzie go nie zapisywać. Bezpieczeństwo naszych informacji zależy jedynie od nas. Hmm... ale mnie wzięło na kazania. Jeszcze raz: You need a Passphrase to protect your secret key. Enter passphrase: Wpisujemy nasze hasło, jednak w trakcie wpisywania nie pojawia się ono na ekranie monitora (Wielki Brat patrzy :). Oczywiście musimy je wpisać dwa razy, żeby się upewnić, że nie doszło do pomyłki. To już (prawie) wszystko z naszej strony, co musimy zrobić. Teraz program zacznie generować pary naszych kluczy. Potrzebuje on naszej pomocy, w postaci: chaotycznego stukania w klawiaturę, ruszania myszką, przełączania ekranów, mielenia dyskiem itp. Popuśćcie wodzę fantazji... We need to generate a lot of random bytes. It is a good idea...... [...bla......bla.......bla....] +++++++...+>++++++++><++++++++...>+.+.>+>+>++>+++++++++++++.... O co tu chodzi? Aby wygenerować nasze klucze, potrzebne jest trochę losowych danych, za pomocą których klucze te zostaną wygenerowane. Wszystkie nasze działania w tym czasie są własnie do tego wykorzystywane. Nie bójmy się walić w klawiaturę jak nam się podoba (nie chodzi o siłę, ale o częstość :). Tak więc przy naszej pomocy, w końcu otrzymamy wymarzone klucze : Public and secret key created and signed. Teraz możemy zabrać się do roboty. Do komunikacji z innymi użytkownikami, potrzebujemy ich kluczy publicznych. Do określenia, konkretnego użytkownika wykorzystujemy jego ares e-mailowy. Aby zobaczyć klucze posiadane przez nas w chwili obecnej, używamy polecenia gpg --list-keys . Na początku w naszej bazie danych jest tylko nasz klucz, co widać w wyniku wklepania powyższego polecenia. |
| Eksportowanie klucza publicznego |
Chcąc udostępnić innym nasz klucz publiczny, musimy go najpierw "wyeksportować". Do pliku, oczywista. Składnia polecenia jest następująca: gpg --output [nazwa_pliku] --export [email-osoby]. np. gpg --output linio.gpg --export linio@terramail.pl spowoduje zapisanie w pliku linio.gpg klucza publicznego osoby posiadającej e-mail linio@terramail.pl. Możemy wyeksportować klucz publiczny każdej osoby, której klucz posiadamy w naszej bazie danych kluczy (polecenie gpg --list-keys). Np. załóżmy, że to polecenie wypisze coś takiego: pub [................bla................] teofil@polska.pl sub [....bla................bla.........] Możemy wyeksportować klucz publiczny Teofila do pliku poleceniem: gpg --output teofil.gpg --export teofil@polska.pl Dobra. Jeśli spróbujemy obejrzeć (np. poleceniem 'cat') tak wygenerowany plik, nie oczekujmy zbyt wiele. Standardowo jest on bowiem zapisany w postaci "binarnej". Jeśli chcemy nasz klucz umieścić np. na stronie WWW, musimy dodać do polecenia opcję, która każe programowi zapisać klucz w kodzie ASCII. Taką opcją jest -a lub --armor, czyli: gpg --armor --output teofil.gpg --export teofil@polska.pl Najczęściej będziemy stosować eksportowanie naszego klucza publicznego. Mając nasz klucz publiczny, możemy go spokojnie wysyłać pocztą jako załącznik lub umieścić na stronie WWW. |
| Importowanie (czyjegoś) klucza publicznego |
Chcąc wysłać do kogoś zaszyfrowaną wiadomość, potrzebujemy klucz publiczny tej osoby. Musimy następnie ten klucz wprowadzić do naszej bazy danych kluczy programu GnuPG. Załóżmy, że otrzymaliśmy list od teofil@polska.pl, a w załączniku umieszczony został jego klucz publiczny w pliku teofil.gpg Importowanie, czyli dodanie jego klucza do naszej bazy danych jest proste i może ograniczyć się do polecenia, którego składnia jest następująca: gpg --import [nazwa_pliku_z_kluczem]. W naszym przypadku będzie to: gpg --import teofil.gpg gpg: key 34CC05EB: public key imported gpg: Total number processed: 1 gpg: imported: 1 Oznacza to, że udało nam się zaimportować czyjś klucz publiczny. Z tym kimś możemy teraz komunikować się w bezpieczny sposób. Listę osób, których klucz posiadamy, możemy obejrzeć poleceniem: gpg --list-keys . Istnieje prawdopodobieństwo, że ktoś trzeci podrzucił nam swój klucz publiczny, podszywając się pod inną osobę. Jak to sprawdzić? GnuPG udostępnia ciekawą opcję, pozwalającą sprawdzić, czy klucz który zaimportowaliśmy naprawdę pochodzi od tej osoby. Jest to nazwane "odciskiem palca" (ang. fingerprint). Najogólniej rzecz biorąc: fingerprint to kilka znaków, które generowane są na podstawie klucza publicznego. Jeśli zmienimy choćby jeden znak w kluczu publicznym, fingerprint pokaże inną wartość. W jaki sposób można to wykorzystać? Załóżmy, że przed chwilą zaimportowaliśmy klucz od teofil@polska.pl. Wydajemy polecenie: gpg --edit-key teofil@polska.pl This program comes..... [....bla......bla......bla....] Command> Wpisujemy teraz polecenie: fpr . Spowoduje to wygenerowanie "odcisku palca" na podstawie klucza publicznego teofila. pub 1024D/.......bla.......bla........bla..... teofil@polska.pl Fingerprint: 7684 6EA5 ................05EB Teraz chwytamy za telefon i dzwonimy do Teofila. Dyktujemy mu przez telefon jaki odcisk palca posiada jego klucz publiczny. Jeśli Teofil go potwierdzi, możemy być pewni na 99,99...%, iż wszystko jest o.k. Oczywiście sprawdzenie odcisku palca nie jest obowiązkowe, jednak zalecane. Dobra, gdy mamy pewność, że nowy klucz publiczny pochodzi naprawdę od danej osoby, powinniśmy go podpisać, w przeciwnym razie program będzie nas ostrzegał, że coś jest nie tak. To "podpisanie" jest wykorzystywane w innym celu, ale jest to trochę bardziej złożony temat, dlatego o tym może później (jak nie zapomnę). W każdym razie podpisujemy cudzy klucz publiczny tylko wtedy, gdy mamy pewność, że pochodzi on od danej osoby. Dobra, wydajemy teraz komendę sign, czyli: Command> sign. Program pyta o nasze główne, tajne hasło, po czym klucz zostaje podpisany. Przypomnę, że cały czas jesteśmy w programie, po wywołaniu: gpg --edit-key teofil@polska.pl. Aby wyjść stąd należy napisać q lub quit. Dobra, mamy swoje klucze, potrafimy importować i eksportować cudze, możemy przejść do sedna sprawy. |
| Szyfrowanie informacji |
Składnia do szyfrowania plików jest następująca: gpg --output zaszyfr.plik --encrypt --recipient adres@odbiorcy plik.jakis Polecenie to szyfruje 'plik.jakis' kluczem publicznym adres@odbiorcy a wynikowy, zaszyfrowany plik nazywa się 'zaszyfr.plik'. Załóżmy, że jesteśmy w posiadaniu klucza publicznego osoby teofil@polska.pl. Jego klucz zaimportowaliśmy, sprawdziliśmy odcisk palca i podpisaliśmy. Załóżmy także, że chcemy zaszyfrować plik 'tajne.txt' a zaszyfrowany plik nazwać 'tajne.gpg'. Zgodnie z podanym wyżej schematem, polecenie będzie wyglądać następująco: gpg --output tajne.gpg --encrypt --recipient teofil@polska.pl tajne.txt Jeśli nie popełniliśmy błędu przy wpisywaniu polecenia (przy okazji: ja przeważnie zapominam dopisać na końcu polecenia nazwę pliku, który chcę zaszyfrować), otrzymaliśmy plik 'tajne.gpg'. Jeśli masz jakieś wątpliwości, wydaj polecenie 'cat tajne.gpg' :). Dobra, teraz ten plik możemy np. wysłać jako załącznik do teofil@polska.pl i tylko on będzie mógł go odczytać. W ten oto sposób, dotarliśmy do kolejnego zagadnienia, czyli... |
| Deszyfrowanie plików |
Załóżmy, że otrzymaliśmy w załączniku zaszyfrowany plik 'tajne.gpg'. Nie muszę chyba pisać, że został on zaszyfrowany naszym kluczem publicznym. Do odszyfrowania, będziemy więc potrzebować naszego klucza prywatnego. Przypomnę tylko, że jest on przechowywany na dysku w postaci zaszyfrowanej (co za ludzie, wszystko tajne). W każdym razie składnia do odszyfrowania jest następująca: gpg --output odszyfrowany.plik --decrypt zaszyfrowany.plik Czyli w naszym przypadku, musimy wydać polecenie: gpg --output tajne.txt --decrypt tajne.gpg You need a passphrase to unlock the secret key for...... Enter passphrase: W tym miejscu musimy podać nasze główne hasło, założone w czasie generowania kluczy, aby odblokować (dokł. odszyfrować) nasz klucz prywatny. Jak napisałem wiele razy, tylko on może odszyfrować wiadomość. Wpisanie poprawnego hasła spowoduje odszyfrowanie pliku 'tajne.gpg' i zapisanie go w pliku 'tajne.txt'. Jeśli nie użyjemy opcji '--output nazwa.pliku', po odszyfrowaniu zawartość pliku zaszyfrowanego zostanie od razu wyrzucona na ekran naszego monitora (nie zalecane :). |
| Szyfrowanie symetryczne |
Załóżmy, że chcemy przesyłać zaszyfrowane wiadomości między kilkoma osobami, ale nie chcemy się bawić w klucze publiczne i prywatne. Szyfrowanie symetryczne to nic innego, jak szyfrowanie dokumentu pewnym hasłem. To samo hasło jest jednak używane zarówno do szyfrowania, jak i do deszyfrowania dokumentów, więc tylko osoby zainteresowane powinny je znać. Innym zastosowaniem tego szyfrowania, jest szyfrowanie pewnych dokumentów tylko dla siebie. Jeśli nie chcemy przechowywać np. naszego pamiętnika na dysku w postaci jawnej, możemy go po prostu zaszyfrować. My zakładamy hasło i tylko my je znamy. Dobra, przejdźmy do konkretów. Składnia polecenia jest banalnie prosta: gpg --output zaszyfrowany.plik --symmetric plik.txt Polecenie to spowoduje zaszyfrowanie pliku 'plik.txt' i zapisanie go jako 'zaszyfrowany.plik'. Załóżmy dla przykładu, że chcemy w taki sposób zaszyfrować plik 'pamietnik.txt' i zapisać go jako 'pam.gpg'. W tym celu: gpg --output pam.gpg --symmetric pamietnik.txt Enter passphrase: [tu wpisujemy hasło] Repeat passphrase: [i jeszcze raz] Musimy hało wpisać 2 razy, aby mieć pewność, że nie popełniliśmy błędu. W wyniku tego powstanie plik 'pam.gpg' będący zaszyfrowaną wersją pliku 'pamietnik.txt'. Uwagi: 1) należy wiedzieć, że plik 'pamietnik.txt' nie zostaje automatycznie usunięty. Jeśli więc coś zaszyfrowaliśmy, musimy pamiętać aby oryginał usunąć (tu: `rm pamietnik.txt`). 2) Pamiętajmy, że plik zaszyfrowany zabezpieczony jest tylko naszym hasłem, dlatego nie może być ono zbyt proste, itd. na temat bezpiecznych haseł. Dobra, mamy plik zaszyfrowany zabezpieczony hasłem. Jak je odszyfrować? gpg --output odszyfrowany.plik --decrypt zaszyfrowany.plik Spowoduje to odszyfrowanie pliku 'zaszyfrowany.plik' i zapisanie go jako 'odszyfrowany.plik'. Oczywiście będziemy proszeni o wpisanie hasła służącego do odblokowania tego pliku. W naszym przypadku: gpg --output pamietnik.txt --decrypt pam.gpg Enter passphrase: [tu wpisujemy hasło] I to wszystko na ten temat. Program sam rozpoznaje, że dany plik został zaszyfrowany algorytmem symetrycznym i jedyne, czego od nas oczekuje, to (poprawne) hasło. |
| Podpisy cyfrowe |
Czym one są i do czego służą, wyjaśniłem na początku. Przypomnę tylko, że mogą one służyć do potwierdzenia, że tylko dana osoba mogła napisać wiadomość, i że nie została ona "po drodze" zmieniona przez kogoś, sfałszowana. Podpis cyfrowy tworzymy za pomocą klucza prywatnego, a do sprawdzenia autentyczności potrzebny jest klucz publiczny. Podpisywanie "zwykłe" (a) Załóżmy, że użytkownik linio@terramail.pl podpisze się pod wiadomością do teofil@polska.pl. Podpisze on dokładnie plik 'tekst.txt' a wyniku tego niech otrzyma 'tekst.sig'. Użytkownik linio@terramail.pl wykonuje dokładnie polecenie: gpg --output tekst.sig --sign tekst.txt You need a passphrase....... Enter passphrase: [tutaj hasło linia do jego klucza prywatnego] Hasło jest potrzebne, ponieważ podpisywanie wiadomości odbywa się za pomocą klucza prywatnego osoby, która podpisuje plik. Powstaje w wyniku tego plik binarny, nie nadający się do odczytu. Sprawdzenie podpisu cyfrowego odbywa się przy pomocy klucza publicznego. W naszym przykładzie: linio podpisał plik, przy pomocy swojego klucza prywatnego, oczywista, i dlatego potrzebne było hasło. Następnie tak utworzony plik 'tekst.sig' zostaje wysłany, np. w załączniku. Odbiera go teofil@polska.pl. Oczywiście mógłby go odebrać, sprawdzić i odczytać każdy, kto jest w posiadaniu klucza publicznego linia. Przypominam jeszcze raz, że tutaj nie szyfrujemy, ale podpisujemy. Co teofil@polska.pl (lub każdy inny, kto ma klucz publiczny linia) może zrobić z plikiem 'tekst.sig'? Otóż może on: *** sprawdzić, czy wiadomość rzeczywiście pochodzi od linio@polska.pl: gpg --verify tekst.sig Signature made [tu jest data i godzina] using DSA key ID [id klucza dsa] Good signature from ........... Widzimy także datę i godzinę dokonania tego. Jeśli nie wierzysz czytelniku w to, że to działa, spróbuj zmodyfikować podpisany plik i jeszcze raz go sprawdzić. *** sprawdzić, czy wiadomość pochodzi od linio@terramail.pl i od razu ją odkodować, jako że nie jest ona zaszyfrowana w ścisłym tego słowa znaczeniu. gpg --output tekst.txt --decrypt tekst.sig Podobnie jak wcześniej, nie jesteśmy pytani o hasło, ale zapewnieni, że to właśnie linio@terramail.pl napisał wiadomość i podpisał ją o określonej godzinie i w określony dzień. Wiadomość odkodowana trafia od razu do pliku 'tekst.txt'. Przypominam, że do sprawdzenia/odkodowania pliku potrzebny jest klucz publiczny nadawcy. Przypominam, że jeśli przy importowaniu klucza publicznego danej osoby nie podpiszemy go (sign), program będzie nas ostrzegał i wypisywał dodatkowe komunikaty, że choć wszystko się zgadza, nie potwierdziliśmy autentyczności importowanego klucza publicznego (np. poprzez fpr). Podpisy "clearsign" (b) Jak zapewne zauważyliście, w wyniku zwykłego podpisywania, plik wynikowy jest zakodowany. Nie nadaje się on do odczytania - ot tak sobie. Należy mieć klucz publiczny nadawcy, dopiero wtedy coś z tego wyjdzie. Może być to problemem np. przy wysyłaniu wiadomości na grupy dyskusyjne. Byłoby nieporozumieniem, gdyby każdy musiał być w posiadaniu klucza publicznego każdej innej osoby. Czy nie da się tego zrobić inaczej? Ano da. Podpis "clearsign" polega na tym, że podpis cyfrowy dorzucany jest na samym końcu pliku podpisywanego. Po prostu plik można normalnie odczytać, a jeśli ktoś nie wierzy w wiarygodność nadawcy może go sprawdzić. Inaczej: treść pliku pozostaje bez zmian, z tą różnicą, że na jego końcu zostaje dopisane kilka linijek mogących służyć do weryfikacji nadawcy. Załóżmy, że linio@polska.pl chce podpisać w stylu "clearsign" plik o nazwie 'plik.txt'. Wydaje on w tym celu polecenie: gpg --clearsign plik.txt Enter passphrase: Po wpisaniu hasła chroniącego jego tajny klucz, powstanie plik o nazwie 'plik.txt.asc'. Przyjęło się bowiem rozszerzenie .asc dla plików tego typu. Zawartość tego pliku można normalnie przejrzeć (np. `cat plik.txt.asc`). Jeśli chcemy dodatkowo sprawdzić, czy autorem pliku jest rzeczywiście jego nadawca wykonujemy: gpg --verify plik.txt.asc Oczywiście musimy być w posiadaniu klucza publicznego autora pliku. Jeśli nie wierzysz w te cudowne właściwości programu, spróbuj zmodyfikować coś w podpisanym pliku a następnie go zweryfikować :) Podpisy "detach" (c) Istnieje jeszcze jeden sposób na podpisanie dokumentów. Polega on na tym, że plik główny, który chcemy podpisać pozostaje bez zmian, natomiast program tworzy dodatkowy plik, służący do weryfikacji tego pierwszego. Przykład: użytkownik linio@terramail.pl podpisuje plik 'tekst.txt', chce go pozostawić bez zmian, a info dotyczące weryfikacji pliku chce wrzucić do pliku 'tekst.sig'. Przyjęło się, że pliki z podpisem mają takie właśnie rozszerzenie (.sig). gpg --output tekst.sig --detach-sig tekst.txt You need a passphrase to unlock........ Enter passphrase: [tutaj hasło do klucza prywatnego] Mamy więc plik 'tekst.txt' i plik 'tekst.sig'. Aby doszło do weryfikacji tego pierwszego, te dwa pliki muszą być przesłane razem. Weryfikacja odbywa się w następujący sposób (warunek: posiadanie klucza publicznego nadawcy): gpg --verify tekst.sig tekst.txt Dobra, teraz mamy pewność, że tekst.txt naprawdę napisał nadawca i że jego treść nie została zmieniona. I jeszcze raz: nie wierzysz - spróbuj zmodyfikować. Uwaga: podpisy cyfrowe opisane w punktach (b) i (c) mają, moim zdaniem, tę przewagę nad (a), iż do odczytania pliku nie potrzeba żadnej zabawy z kluczami itp. Po prostu można plik normalnie przeczytać. Jeśli natomiast ktoś ma wątpliwości co do nadawcy/treści i wolałby się upewnić, może to po prostu sprawdzić. Wystarczy zaimportować w tym celu klucz publiczny nadawcy, znajdujący się np. na jego stronie WWW. |
| Program pgp4pine |
Należy zadać sobie pytanie: czy istnieje jakiś sposób, aby zautomatyzować szyfrowanie i deszyfrowanie poczty? W ten sposób, aby treści listu nie trzeba było przesyłać w załączniku? Ano istnieje. Prawdę mówiąc wszystko zależy od naszego programu - klienta pocztowego. Niektóre z nich mają standardowo wbudowane elementy (de)szyfrowania, inne ich nie mają a do jeszcze innych należy je dołączyć. W tym poradniku zajmiemy się programem pine. Aby automatycznie potrafił on (de)szyfrować listy, należy: - ze strony http://pgp4pine.flatline.de ściągnąć ostatnią wersję programu. - odpowiednio skonfigurować program Tutaj zajmiemy się oczywiście drugim punktem i na początku musisz wiedzieć, że nie jest to skomplikowane. Po rozpakowaniu pliku robimy: ./configure, następnie make i w końcu make install. Program domyślnie ląduje w /usr/local/bin. Dobra, teraz właściwa konfiguracja. Z katalogu: /usr/local/doc/pgp4pine/ kopiujemy plik example.pgp4pinerc do naszego katalogu domowego i zmieniamy jego nazwę na .pgp4pinerc cp /usr/local/doc/pgp4pine/example.pgp4pinerc ~/.pgp4pinerc W taki czy inny sposób, w katalogu domowym mamy plik .pgp4pinerc. Teraz wrzucamy ten plik do jakiegoś edytora tekstów i odpowiednio go przerabiamy. Idziemy do sekcji PROFILE STUFF. Zmienną profile_list ustawiamy na profile_list=gpg. Następnie idziemy niżej i z 4 linijek profile_xxx_version=x zostawiamy tylko tą: profile_gpg_version=1 Teraz idziemy w dół pliku i wszystkie wystąpienia profile_pgp5_...... zmieniamy na profile_gpg_......., czyli konkretnie mamy: profile_list=gpg profile_gpg_version=1 profile_gpg_autosign=0 profile_gpg_autoencrypt=0 ..... itd....... Każda z tych opcji jest dobrze opisana. Pozostało skonfigurować pine. W tym celu uruchamiamy program, a następnie wchodzimy do: Setup-->Config. Pod koniec opcji konfiguracyjnych, (u mnie 20-ste od dołu) znajduje się zmienna display-filters. Wpisujemy tam, dokładnie jak poniżej, następującą linijkę: _BEGINNING("-----BEGIN PGP")_ /usr/local/bin/pgp4pine -d -i _TMPFILE_ Musi to zostać wpisane dokładnie jak powyżej, pięć znaków minus, nie zapomnij o znakach podkreślenia _ i spacjach tam gdzie trzeba, ścieżkę dostępu zmień odpowiednio, jeśli program masz gdzieś indziej . Jedziemy dalej - pozostało ustawić wartość zmiennej sending-filters, u mnie jest ona następna, 19-ta od dołu. Wpisujemy tam dokładnie tak: /usr/local/bin/pgp4pine -e -i _TMPFILE_ -r _RECIPIENTS_ Dobra, to już wszystko, zapisujemy zmiany do Setupu i możemy wysyłać listy. Program pine jest gotowy do wysyłania/odbierania zaszyfrowanej poczty. Po napisaniu nowego listu, po naciśnięciu Ctrl+X, czyli Send, program pyta: Send message unfiltered?. Znaczy to, że domyślnie chce wysłać wiadomość niezaszyfrowaną. My naciskamy Ctrl+N lub Ctrl+P, aż pojawi się "filtered thru pgp4pine" i dopiero wtedy wysyłamy. Musimy oczywiście mieć klucz publiczny kolesia, do którego zaszyfrowany list chcemy wysłać. Pine z obsługą gpg jest naprawdę prosty w użyciu, dlatego nie rozwodzę się dalej nad innymi jego pytaniami przed wysłaniem listu. Do tego wystarczy naprawdę podstawowa znajomość angielskiego. Omówiłem tutaj to, co najważniejsze przy pine z obsługą gpg. |
| mutt - konfiguracja |
Autorem niniejszego punktu jest Paweł 'Pasza' O. (THX!) ------------ Ustawienie gpg pod mutt`em jest bardzo proste. Podobnie jak w przypadku pine, kopiujemy przykładowy plik konfiguracyjny do katalogu domowego. Ten plik to: /usr/share/doc/mutt/mutt-1.4.1/gpg.rc.gz, w PLD (tu trzeba rozpakować) /usr/share/doc/mutt/gpg.rc, w redhacie /usr/share/doc/mutt/examles/gpg.rc, w debianie Zawiera on ustawienia wewnętrznych poleceń mutt`a na odpowiednio owinięte polecenia gpg. Kopiujemy ten plik do ~/.mutt_gpgrc i dodajemy linijkę: source "~/.mutt_gpgrc" do pliku .muttrc i.. to już właściwie wszystko. Teraz, żeby użyć szyfrowania piszemy normalnie list, zapisujemy i przed wysłaniem możemy skorzystać z możliwości gpg po naciśnięciu p. Dostępne są następujące opcje: (e)ncrypt, (s)ign, sign (a)s, (b)oth, or (f)orget it? których tłumaczyć już chyba nie trzeba. Jeśli mutt nie umie znaleźć klucza publicznego adresata w naszym key-ringu, to zapyta o keyId, jest to nic innego jak adres e-mail związany z kluczem publicznym którym będziemy szyfrować. Jeśli bardzo obawiamy się, że ktoś może podejrzeć nasze hasło do klucza prywatnego znajdujące się w pamięci, to funkcja mutt`a forget-passphrase (domyślnie Ctrl-f), wymazuje hasło z pamięci komputera. Żeby sprawdzić czy wszystko działa, można zaszyfrować i wysłać list do samego siebie. Zaszyfrowane listy mają flagę P przy statusie listu, a listy kryptograficznie podpisane flagę s. Mutt automatycznie spróbuje sprawdzić czy podpis pasuje do wiadomości i powiadomi o tym czy mu się udało. ----------------- |
| Instalacja oprogramowania a gpg |
Ta część pracy skierowana jest do administratorów systemów *xowych, którzy mogą wykorzystać GnuPG do sprawdzenia wiarygodności instalowanych pakietów, kodów źródłowych itp. Metoda ta jest pewniejsza od prostego sprawdzania sum kontrolnych (tak jest i już). Do pełnego, poprawnego sprawdzenia wiarygodności softu potrzebne są następujące elementy: - pakiet instalowanego softu - plik z podpisem tego softu - klucz publiczny osoby tworzącej plik z podpisem pakietu - "odcisk palca" jej klucza publicznego Dobrze jest, gdy wszystkie ww. są rozmieszczone na przynajmniej dwóch różnych serwerach. W teorii wygląda to tak: pobieramy plik z softem, który chcemy instalować (np. xxx.tar.gz) oraz plik z jego podpisem (xxx.tar.gz.sig). Następnie pobieramy ze strony www danego oprogramowania klucz publiczny (*.asc) użyty do wygenerowania podpisu (dostępny najczęściej w dziale "PGP, GPG, signatures" itp.). Do pobrania tego klucza możemy też wykorzystać któryś z ogólniedostępnych serwerów kluczy, np. ten. Następnie importujemy uzyskany klucz publiczny, sprawdzamy jego "odcisk palca" i jeśli jest o.k. - podpisujemy go. Reszta to jedno krótkie polecenie przedstawione niżej - w przykładzie. Przykład Załóżmy że czynimy przygotowania do zainstalowania sobie nowej wersji... GnuPG. Gdy powstaje ten fragment dokumentu, jest nią wersja 1.40. Z linii poleceń robię tak: wget ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.0.tar.bz2 wget ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.0.tar.bz2.sig Latając po stronie naszego softu trafiam na "Integrity check" a następnie na "signing key". Co widzę? Klucz publiczny, który "wklejam" sobie do pliku np. gnupg.asc. Jest tam podany także jego "odcisk palca". Kolejne polecenie: gpg --import gnupg.asc wczyta z pliku .asc klucz publiczny, dla którego wypadałoby sprawdzić "odcisk". Uwaga: bardzo często nie jest on podawany na stronie i musimy zrezygnować z tego kroku. W ogóle czasami trzeba się nieźle nabiegać żeby trafić na zwykły klucz publiczny. Szkoda słów... Interesujący nas fragment wyniku powyższego polecenia wygląda tak: gpg: key 57548DCD: public key "Werner Koch (gnupg sig) Mamy więc ID klucza publicznego (można go też wyczaić przy pomocy gpg --list-keys) i robimy tak: gpg --fingerprint 57548DCD W rezultacie gpg poda nam "odcisk" zaimportowanego klucza. Porównujemy go z tym na stronie www naszego softu i jeśli się zgadza - idziemy dalej. Jeśli nie, lepiej pozyskać nasz soft z innego źródła, ew. poszukać gdzie popełniliśmy błąd i powtórzyć czynności. Jeśli wszystko się zgadza (powtarzam się) - a powinno - podpisujemy świeżo zaimportowany klucz: gpg --sign-key 57548DCD ...i po paru standardowych pytaniach i podaniu hasła do naszego klucza prywatnego pozostanie już tylko sprawdzenie sygnaturki dla pobranego pliku z instalowanym oprogramowaniem. Jedziemy: gpg --verify gnupg-1.4.0.tar.bz2.sig Nie trzeba podawać nazwy pliku z softem (tego do sprawdzenia) jeśli plik .sig różni się w nazwie od niego tylko wspomnianym rozszerzeniem. Program sprawdzi czy pobrane wgetem pliki pasują do siebie. I to... chyba wszystko :) Nie muszę oczywiście pisać, że cała ta szopka z kluczami i odciskami odbywa się tylko raz. Gdy ukaże się nowa wersja naszego softu, wystarczy pobrać ją z plikiem .sig a następnie wydać ostatnie polecenie. O ile sprawdzanie sum kontrolnych przy pomocy MD5 jest proste jak drut, to w przypadku z GnuPG problemem jest... odnalezie na stronach producenta instalowanego softu kluczy publicznych i ich odcisków palców - każdy trzyma to gdzieś indziej, każdy nazywa pliki inaczej i jest z tym niezłe zamieszanie. Na szczęście czynność tą wykonujemy tylko raz. |
| Posłowie |
Jest to druga wersja dokumentu i zawiera pewnie jakieś błędy/niedoróbki/potknięcia itp. Będę bardzo wdzięczny za wszelkie uwagi, komentarze, poprawki, wyrazy wdzięczności. Z góry przepraszam za powyższe i mam nadzieję, że będziecie mnie informować w których miejscach coś nie gra. Jako (częściowe) wytłumaczenie przedstawiam fakt, że większość tej pracy powstawała w późnych godzinach nocnych. Ostatnia wersja tego dokumentu znajduje się pod niżej wymienionym adresem. Kontakt ze mną: linio@terramail.pl Wesprzyj finansowo autora - kliknij tutaj |
|
=============================== Henryk Liniowski, Poznań 2004 http://linio.terramail.pl =============================== |