Od redakcji: zapraszamy do zapoznania się z obszernym tekstem, tłumaczącym jak w praktyce zastosować chyba najpopularniejsze obecnie uniksowe oprogramowanie do kryptografii — GnuPG. Oryginał jest dostępny na stronie securenet.pl. Życzymy miłej lektury.

Architektura klucza publicznego w Gnu Privacy Guard (GPG)

Wysyłanie poufnych informacji poprzez sieć internet staje się w dzisiejszych czasach coraz powszechniejszą praktyką. Często otrzymując wiadomość nawet się nie zastanawiamy, czy rzeczywiście została ona wysłana przez osobę która widnieje w jej nagłówku jako nadawca. Nie myślimy nawet nad tym, że ktoś po drodze mógł zapoznać się z jej treścią, a nawet ją zmienić. Niestety, gdy trochę bardziej przyjrzymy się broadcastowej sieci ethernet, dostrzeżemy w niej wiele wad stwarzających możliwości do nadużyć, szczególnie do podsłuchu. Stosując przełączniki sieciowe teoretycznie uniemożliwiamy podsłuchanie naszych pakietów, jednak często w praktyce okazuje się, że nie jest to do końca prawdą. Coraz powszechniejsze sieci bezprzewodowe jeszcze bardziej pogarszają sprawę w tym względzie. Likwidują one konieczność fizycznego podłączenia (kablem) do urządzenia sieciowego stwarzając możliwość podsłuchu każdej osobie do której dociera sygnał naszej sieci.

Wyobraźmy sobie teraz sytuację w której chcemy przelać na konto znajomego większą sumę pieniędzy.  Sami nie dysponujemy taką kwotą, więc prosimy o pomoc kolegę (nazwijmy go Łukasz). Wysyłamy do niego drogą mailową list w którym prosimy o dokonanie przelewu. Chłopak jednak, po coraz częściej nagłaśnianych przez media przypadkach oszustw dokonywanych drogą internetową, nabiera podejrzeń co do otrzymanej przed chwilą korespondencji. Słyszał bowiem, że dla komputerowych przestępców, zmiana adresu nadawcy w wiadomości pocztowej nie stanowi większego problemu.
Pojawia się więc problem z weryfikacją tożsamości nadawcy. Czy istnieje obecnie rozwiązanie, które by pozwalało w niemal pewny i prosty sposób potwierdzić prawdziwość otrzymanego listu?!
Oczywiście, że tak! Dzięki technice klucza publicznego możemy elektronicznie podpisywać oraz wysyłać poufne wiadomości, bez obawy, że ktoś niepowołany je w jawnej postaci przeczyta lub zmodyfikuje.  
Cała filozofia tej technologii polega  na posiadaniu specjalnej pary kluczy, prywatnego oraz publicznego. Klucz prywatny powinien być przez nas pilnie strzeżony i nie rozpowszechniany. Klucz publiczny natomiast powinien być ogólne dostępny i powinien go posiadać każdy, kto chce wysłać do nas zaszyfrowaną wiadomość, bądź sprawdzić nasz podpis cyfrowy.  Najczęściej jest on umieszczany na specjalnych, przeznaczonych do tego celu serwerach, np. wwwkeys.pgp.net, czy certserver.pgp.com.


Podstawowe pojęcia przydatne podczas lektury artykułu:
Szyfrowanie symetryczne – nazywane również szyfrowaniem z zastosowaniem klucza poufnego. Wymaga wykorzystania tego     samego klucza (hasła) zarówno do szyfrowania, jak i odszyfrowywania wiadomości. Wykonywane jest szybko, więc zwykle jest używane wówczas, gdy istnieje potrzeba zaszyfrowania dużej ilości danych.

Szyfrowanie asymetryczne – polega na tym, że użytkownicy systemu posługują się dwoma kluczami (publicznym i prywatnym). Klucz publiczny jest dostępny dla innych, klucza prywatnego należy natomiast strzec. Dane szyfrowane są jednym kluczem z pary i aby je odszyfrować należy użyć drugiego klucza. Wadą szyfrowania asymetrycznego jest jego powolność. Szyfrowanie to jest stosowane w bankowości internetowej.

RSA – Opracowany w 1977 roku przez Rona Rivesta, Adi Shamira i Leonarda Adlemana system kryptograficzny oparty na kluczu niesymetrycznym.
Fundamentem RSA jest algorytm służący do generowania unikalnych i bezpiecznych (odpornych na próby odgadnięcia) par kluczy. Mnoży on dwie duże liczby pierwsze (podzielne tylko przez 1 i przez siebie) i z otrzymanego wyniku poprzez kilka innych dodatkowych operacji ustala klucz publiczny i zależny od niego klucz prywatny.  
Przyjmując odpowiednio duże liczby pierwsze otrzymujemy szyfr odporny na złamanie. Odczytanie zakodowanej wiadomości wymagałoby bowiem rozłożenia bardzo dużej liczby na czynniki pierwsze – co przy dzisiejszym stanie nauk matematycznych jest niezwykle trudne.
Poważną wadą algorytmu RSA jest jego wolne działanie. Z tego powodu stosuje się go zazwyczaj w połączeniu z innymi algorytmami, np. DES, który operacje szyfrowania przeprowadza 1000 razy szybciej.

Algorytm ElGamala – stworzony przez Taher Elgamal’a wykorzystuje trudność obliczania tzw. logarytmów dyskretnych. Może być on użyty do szyfrowania, jak i deszyfrowania wiadomości oraz dodatkowo przy tworzeniu podpisów cyfrowych (DSA pochodzi właśnie od tego algorytmu i jest w zasadzie bardzo podobny). Każdorazowe szyfrowanie wykorzystuje losowo wygenerowaną liczbę. Dzięki temu za każdym razem ten sam tekst jawny może być zaszyfrowany w inny sposób. Niestety, kryptogramy Elgamala są dwukrotnie dłuższe niż teksty jawne (co np. w RSA nie ma miejsca).

Digital Signature Algorithm (DSA) – jest algorytmem, który generuje i weryfikuje cyfrowy podpis odcisku wiadomości. Należy zauważyć, że może być używany jedynie do tworzenia podpisów cyfrowych (nie można nim szyfrować wiadomości). Do tego celu wykorzystywana jest funkcja haszująca SHA-1 będąca (zarówno jak DSA) standardem w USA. Tak jak w przypadku algorytmu Elgamala, bezpieczeństwo DSA zależy od trudności obliczenia dyskretnych logarytmów. Tak więc bezpieczeństwo stosowanych podpisów stoi w ścisłej zależności z wielkością liczb, dla których obecnie potrafimy obliczać dyskretne logarytmy.

Funkcja Haszująca – w ogólnym ujęciu jest to funkcja dokonująca jednostronnego przekształcenia wiadomości do postaci tzw. ciągu przemieszanego (odcisku palca). Cechą charakterystyczną ciągu przemieszanego jest to, że nie ma praktycznie możliwości uzyskania z niego pierwotnej informacji. Inną podstawową własnością tej funkcji jest to, że po zmianie choćby jednego bitu w oryginalnej wiadomości, otrzymamy kompletnie inny ciąg przemieszany. Przykładowe i powszechnie stosowane dzisiaj funkcje haszujące to MD5 oraz SHA-1.



Wysyłanie cyfrowo podpisanej wiadomości:

Łukasz chcąc mieć pewność, że otrzymana korespondencja jest autentyczna oraz, że nikt po drodze np. nie zmienił kwoty przelewu, prosi nas o ponowne przesłanie wiadomości, tym razem opatrzonej naszym podpisem cyfrowym. Musimy więc posiadać jakiś program, który nam w tym może pomóc.
Obecnie najpopularniejsze aplikacje realizujące zagadnienia związane z architekturą klucza publicznego, to PGP Philipa Zimmermana oraz Gnu Privacy Guard (GPG) z Free Software Foundation.
Ze względu na ograniczenia patentowe związane np. z algorytmem IDEA występującym w Preety Good Privacy (PGP), wybieramy wolną od restrykcji patentowych (kompatybilną z PGP) aplikację z projektu GNU. Jest ona standardowo obecna w większości linuksowych dystrybucji.
Jeśli jednak dziwnym trafem nasz system nie zawiera wspomnianej aplikacji, to pomocny może się okazać poniższa tabelka :-)


Instalacja GPG – linux:
Podczas pisania artykułu korzystałem z wersji 1.2.6, którą możemy ściągnąć z poniższej lokacji:
ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.2.6.tar.gz

Po rozpakowaniu archiwum utworzony zostanie katalog gnupg-1.2.6. Instalacja przebiega w sposób standardowy. Po wejściu do nowego katalogu najpierw odpalamy skrypt konfigu
racyjny:
#./configure
Następnie kompilujemy całość:
#make
Na koniec instalujemy nasze nowe GnuPG w systemie:
#make install


—-> Krok 1 – generowanie kluczy:
Pierwszą czynnością podjętą przez nas w celu wysłania cyfrowo podpisanego listu będzie wygenerowanie własnej pary kluczy,  prywatnego (do podpisywania własnej korespondencji) oraz publicznego (dostępnego dla wszystkich i potrzebnego odbiorcy przy weryfikacji naszych wiadomości). Zrealizujemy to za pomocą polecenia:

[user@host]$ gpg --gen-key

Na samym początku zostaniemy poproszeni o rodzaj klucza, jaki mamy zamiar utworzyć:

Please select what kind of key you want:
   (1) DSA and ElGamal (default)
   (2) DSA (sign only)
   (4) RSA (sign only)
Your selection?

Wybierzmy pierwszą opcję. Algorytmów DSA(2) oraz RSA(4) możemy użyć jedynie do tworzenia podpisów cyfrowych, więc nie damy rady zaszyfrować nimi naszej wiadomości za przy pomocy klucza publicznego nadawcy. Domyślne ustawienie wykorzystuje również algorytm ElGamala, który oprócz tworzenia sygnatur, potrafi również za pomocą dowolnego klucza publicznego zaszyfrować wysyłaną przez nas wiadomość.

W kolejnym kroku zostaniemy zapytani o długość naszego klucza:

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) 1024

Domyślne ustawienie powinno w większości przypadków być wystarczające. Jeśli jednak bezpieczeństwo to absolutnie krytyczny dla nas element i mamy podejrzenia, że ktoś będzie próbował złamać nasz klucz, to możemy dla większego spokoju wybrać długość 2048 bitów.  
Obecnie największa długość wspierana przez GPG wynosi 4096 bitów, jednak nie jest to zalecana wielkość klucza.
Pamiętajmy, że im dłuższy klucz, tym czas procesora potrzebny na wygenerowanie początkowych kluczy ulega wydłużeniu. Sytuacja przedstawia się podobnie przy późniejszym podpisywaniu oraz szyfrowaniu naszych wiadomości, im dłuższy klucz, tym więcej czasu potrzeba na wykonanie niezbędnych operacji arytmetycznych.

Następny etap to określenie terminu ważności naszego klucza:

Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0)

Większość użytkowników nie określa terminu ważności dla swoich kluczy. Jeśli jednak obawiamy się, że ktoś mógłby wykraść nasz klucz prywatny, bądź po prostu go złamać (chociaż metodą brute-force jest to bardzo mało prawdopodobne), możemy określić czas, po jakim nasz klucz straci ważność.
Pamiętajmy jednak, że kiedy ustawimy termin ważności i rozpowszechnimy innym użytkownikom nasz klucz publiczny, mogą pojawić się problemy po jego wygaśnięciu.

Ostatnim krokiem przed wygenerowaniem naszych kluczy jest podanie naszych danych identyfikacyjnych oraz hasła. To, co teraz podamy jako nasze imię, nazwiska, komentarz i adres poczty, będzie wyświetlane innym użytkownikom po zaimportowaniu naszego klucza.
Po wpisaniu wszystkich danych program zapyta się o ich ewentualne poprawienie. Jeśli wszystko wygląda już tak jak powinno, zostaniemy ostatecznie poproszeni o podanie hasła chroniącego nasz klucz prywatny. Jest to bardzo ważny element, nie może to być prosty, słownikowy wyraz, łatwy do odgadnięcia.
Po jego wpisaniu i następnie potwierdzeniu zostaną wreszcie wygenerowane nasze nowe klucze. Ilość czasu potrzebna do ich utworzenia jest zależna od szybkości procesora, wybranej długości klucza oraz entropii podanych informacji (hasło, dane identyfikacyjne). Dodatkowo zostaniemy poproszeni o pomoc przy generowaniu liczb pierwszych. Polegać będzie ona na wykonywaniu jak największej ilości operacji podczas procesu tworzenia naszych kluczy. Gdy wszystko zakończy się pomyślnie, powinniśmy ujrzeć komunikat finalizujący całe zadanie:

public and secret key created and signed.
key marked as ultimately trusted.

pub  1024D/C6F389DF 2004-09-15 Jan Nowak (manager)
     Key fingerprint = 1759 24E8 70D7 4FA7 0E59  1EC2 F994 EFDD C6F3 89DF
sub  1024g/46DBD192 2004-09-15


—-> Krok 2 – Podpisywanie wiadomości:

Mając już wygenerowane klucze, możemy podpisać naszą korespondencję. Załóżmy, że wiadomość mamy zapisaną w katalogu bieżącym w pliku msg.txt. Aby opatrzyć ją naszym podpisem cyfrowym, wydajemy polecenie:

[user@host]$ gpg --clearsign ./msg.txt

Zostaniemy zapytani o hasło do naszego klucza prywatnego, po czym w bieżącym katalogu, oprócz pliku msg.txt powinna pojawić się już podpisana elektronicznie i gotową do wysłania wiadomość msg.txt.asc. Tak przygotowaną naszą prośbę o przelew wraz z cyfrową sygnaturką potwierdzającą naszą tożsamość (całość jest zawarta w pliku msg.txt.asc) wysyłamy ponownie do Łukasza. Mając w zamiarze umieszczenie naszego klucza publicznego na jednym z ogólnodostępnych serwerów, wysyłamy mu również numer ID naszego klucza.
Każdy klucz publiczny ma swój numer identyfikacyjny, chcąc więc przesłać komuś nasz klucz, wystarczy, że podamy (np. w mailu) właśnie ten numer. Teraz nasz odbiorca bez problemu będzie mógł ściągnąć z serwera nasz cały klucz, bez potrzeby wysyłania go przez nas pocztą, czy dostarczenia innymi drogami.

—-> Krok 3 – Eksportowanie klucza publicznego
Jednak aby Łukasz mógł ściągnąć z serwera nasz klucz, musimy go najpierw tam umieścić. Zrealizujemy to za pomocą polecenia:

[user@host]$ gpg --keyserver wwwkeys.pgp.net --send-key jan@programista.pl
gpg: success sending to `wwwkeys.pgp.net' (status=200)

opcja –keyserver wskazuje serwer, na którym umieścimy nasz klucz i tutaj taka mała uwaga. Większość serwerów publicznych to maszyny odpowiednio ze sobą zsynchronizowane, nie ma więc potrzeby wysyłania swojego klucza na więcej niż jeden serwer. Opcja –send-key wskazuje, że mamy wyeksportować klucz należący do osoby identyfikującej się adresem jan@programista.pl. Oczywiście zamiast maila możemy podać numer ID naszego klucza. Po wyświetleniu komunikatu o pomyślności operacji, Łukasz może już spokojnie ściągnąć nasz klucz z serwera.  
Gdy chcemy wyeksportować nasz (lub kogokolwiek z naszej bazy) klucz publiczny do pliku, przyda się nam polecenie:

[user@host]$ gpg --output key.pgp --armor --export jan@programista.pl

W powyższym przykładzie zapiszemy w bieżącym katalogu, w pliku key.pgp, klucz publiczny osoby mającej w naszej bazie danych adres jan@programista.pl. Opcja –armor powoduje, że zostanie on zapisany w kodzie ASCII (domyślnie jest on zapisywany w postaci binarnej). Uzyskany w ten sposób klucz możemy teraz publicznie udostępnić np. umieszczając go na naszej stronie internetowej.

—-> Krok 4 – Importowanie kluczy publicznych
Łukasz po odebraniu naszej wiadomości chce sprawdzić jej autentyczność. Jednak jak wiemy, aby tego dokonać, musi on posiadać w swojej bazie danych nasz klucz publiczny.
Proces dodawania kluczy jest w GnuPG bardzo prosty i ogranicz
a się do dwóch kroków, wpisania klucza do naszej bazy oraz jego potwierdzenia (podpisania). Dodać klucz możemy na dwa sposoby, z lokalnego systemu plików, np.:

[user@host]$ gpg --import /tmp/klucz.pgp

gdzie po opcji –import podajemy ścieżkę do pliku zawierającego klucz publiczny do zaimportowania, bądź z któregoś z ogólnodostępnych serwerów przeznaczonych do przechowywania kluczy publicznych. Łukasz nie posiada naszego klucza zapisanego w pliku, więc ściąga go z publicznego serwera:

[user@host]$ gpg --keyserver wwwkeys.pgp.net --recv-keys C6F389DF
gpg: key C6F389DF: public key "Jan Nowak (manager) " imported
gpg: Total number processed: 1
gpg:               imported: 1

Jako parametr dla drugiej opcji podany zostaje numer ID naszego klucza (przesłany wraz z mailem). Wszystkie klucze publiczne obecne w naszej bazie danych oraz ich ID możemy w każdej chwili sprawdzić za pomocą polecenia:

[user@host]$ gpg --list-keys
/home/jan/.gnupg/pubring.gpg
-----------------------------
pub  1024D/3958260E 2004-09-15 Łukasz Kowalski
sub  1024g/AB0F993E 2004-09-15

pub  1024D/C6F389DF 2004-09-15 Jan Nowak (manager)
sub  1024g/46DBD192 2004-09-15

Teraz Łukasz musi sprawdzić autentyczność naszego klucza. Wydaje więc polecenie:

[user@host]$ gpg --fingerprint jan@programista.pl
pub  1024D/C6F389DF 2004-09-15 Jan Nowak (manager)
     Key fingerprint = 1759 24E8 70D7 4FA7 0E59  1EC2 F994 EFDD C6F3 89DF
sub  1024g/46DBD192 2004-09-15

Mając wyświetlony odcisk klucza powinien on go zweryfikować kontaktując się z nami innym kanałem komunikacji, np. telefonicznie lub osobiście. Jeśli wszystko się zgadza, to mając już potwierdzoną zgodność z oryginałem, można ostatecznie podpisać klucz:

[user@host$ gpg --sign-key jan@programista.pl

Po odpowiedzi na pytanie tyczące się dokładności z jaką został sprawdzony nasz klucz oraz po podaniu hasła dla swojego klucza prywatnego, nasz nowy klucz publiczny zostaje ostatecznie dodany do bazy danych. W tym momencie Łukasz może przeprowadzić pełną weryfikację otrzymanej od nas wiadomości.


—-> Krok 5 – Sprawdzanie tożsamości nadawcy

Sprawdzanie autentyczności otrzymanej przesyłki jest bardzo proste. Łukasz otrzymaną od nas wiadomość msg.txt.asc zapisuje w domowym katalogu, po czym do niego przechodzi. Teraz za pomocą jednego polecenia wykonuje on ostatnią operację, końcową weryfikację:

[user@host]$ gpg --verify ./msg.txt.asc
gpg: Signature made Wed 15 Sep 2004 09:00:34 PM CEST using DSA key ID C6F389DF
gpg: Good signature from "Jan Nowak (manager) "

Podpisy się zgadzają więc wiadomość zostaje uznana za autentyczną. Teraz nasz kolega, może ze spokojem wykonać stosowny przelew.

Dobrze, w powyższym przykładzie wysyłaliśmy list, a naszym celem była weryfikacja nadawcy oraz sprawdzenie przy tym integralności treści wiadomości. Jednak poprzednio szyfrowany był tylko sam elektroniczny skrót wiadomości. Jej treść była przesyłana przez sieć w postaci jawnej. Atakujący nie mógł co prawda niepostrzeżenie zmienić oryginalnego tekstu, ale mógł (używając np. najprostszego sniffera) go po prostu przechwycić. Pół biedy jeśli są to mało istotne informacje, ale jeśli w ten sposób dostarczamy ważne raporty finansowe, czy inne krytyczne i bardzo poufne informacje, to narażamy się na  poważne w skutkach konsekwencje.


Cyfrowe podpisywanie wiadomości:
Główna idea sprawdzania poprawności przesyłki opiera się na funkcji hashującej SHA-1, dzięki której z jawnej i gotowej do wysłania wiadomości wyliczany jest ciąg przemieszany (jest to innymi słowy długi szereg liczb wyliczony  za pomocą jednokierunkowej funkcji hashującej z tekstu oryginalnej wiadomości). Obecnie najbardziej popularnym algorytmem służącym do tworzenia elektronicznych podpisów jest DSA (Digital Signature Algorithm).  Jednak możliwe jest wykorzystanie w tym celu również algorytmów RSA oraz ElGamala.
Otrzymana w ten sposób sygnatura oryginalnej wiadomości zostaje następnie przez nas zaszyfrowana za pomocą naszego klucza prywatnego. Dopiero tak przygotowana całość (oryginalny tekst oraz jego zakodowany skrót) zostaje w naszym przykładzie wysłana do Łukasza.
Kolega odbiera wiadomość i następnie ściągą z serwera nasz klucz publiczny i przy jego pomocy rozszyfrowuje ciąg przemieszany otrzymany razem z naszą wiadomością. Posiada ona teraz jawną sygnaturę (ciąg przemieszany) oryginalnej wiadomości. Sprawdzenie tożsamości polega teraz na utworzeniu z otrzymanego od nas tekstu nowego ciągu przemieszanego (w tym celu używany jest ten sam algorytm DSA).
Teraz, jeśli wyliczony w ten sposób ciąg znaków zgadza się z tym otrzymanym od nas, to Łukasz może mieć prawie stu procentową pewność, że korespondencja jest autentyczna.
Gdyby wiadomość została po drodze zmieniona, Łukasz otrzymałby kompletnie inny podpis cyfrowy. Przyczyną błędu mogłoby być również posiadanie nieprawidłowego klucza publicznego nadawcy, bądź po prostu klucz mamy prawidłowy, a wiadomość została wysłana przez kogoś zupełnie innego. Zauważmy, że aby weryfikacja autentyczności odbyła się pomyślnie, treść wiadomości MUSI być podpisana tylko i wyłącznie kluczem prywatnym nadawcy. To właśnie dlatego tak ważne jest, abyśmy trzymali nasz klucz prywatny w tajemnicy. Gdyby ktoś go przechwycił, mógłby wysyłać listy w naszym imieniu, a weryfikacja tożsamości nadawcy przez odbiorcę zawsze by się kończyła pomyślnie. Pamiętajmy, że tylko jeden klucz prywatny pasuje do tylko jednego klucza publicznego.


Wysyłanie zaszyfrowanej wiadomości:

Wyobraźmy sobie, że stworzyliśmy Łukaszowi konto na naszym serwerze. Chłopak się ucieszył, ale my mamy poważny problem. Jak przesłać mu w bezpieczny sposób nowy login oraz hasło dostępowe?! Nierozsądne byłoby w tym momencie wysyłanie tak poufnych danych w postaci jawnej przez sieć.  
Oczywiście i tym razem z pomocą przychodzi nam GnuPG. Stajemy teraz przed potrzebą zaszyfrowania całej wiadomości. Jest to wbrew pozorom operacja bardzo prosta. Całą treść poufnej wiadomości szyfrujemy używając klucza publicznego należącego do Łukasza i dopiero tak przygotowany kryptogram wysyłamy mu przez internet. Zauważmy, że w poprzednim przykładzie znajomość klucza publicznego odbiorcy nie była konieczna.
Teraz nawet jeśli atakujący przechwyci naszą wiadomość, to bez znajomości klucza prywatnego kolegi na nic się mu ona nie przyda.

—-> Krok 1 – Importowanie klucza:
Załóżmy, że Łukasz wysłał nam wcześniej numer ID swojego klucza, teraz musimy go tylko w całości ściągnąć z serwera. Wydajemy więc polecenie:

[root@crusader root]# gpg --keyserver wwwkeys.pgp.net --recv-keys 3958260E
gpg: key 3958260E: public key "Łukasz Kowalski " imported
gpg: Total number processed: 1
gpg:               imported: 1

Klucz o identyfikatorze 3958260E został pomyślnie zaimportowany. Jak widzimy w danych identyfikacyjnych, należy on do naszego kolegi. Teraz powinniśmy dla pewności zweryfikować nowy klucz oraz podpisać wspomnianą wyżej pocją –sign-key. Jeśli wszystko przebiegło pomyślnie, możemy przystąpić do szyfrowania naszego listu.

—-> Krok 2 – Szyfrowanie
wiadomości:

Mając więc na celu zachowanie poufności, jak i integralności naszej wiadomości, wydajemy polecenie:

[user@host]$ gpg --encrypt --sign --armor --recipient lucas@programista.pl ./tekst

Teraz w naszym bieżącym katalogu powinien pojawić się zaszyfrowany (opcja –encrypt) kluczem publicznym użytkownika lucas@programista.pl (o. –recipient lucas@programista.pl), podpisany (o. –sign) oraz zapisany w postaci ASCII (o. –armor) plik tekst.asc. Pamiętajmy, że ostatnim argumentem musi być ścieżka do pliku w którym jest zapisana treść naszej wiadomości. Dopiero tak przygotowane dane o nowym koncie wysyłamy teraz ze spokojem do Łukasza.

—-> Krok 3 – Rozszyfrowanie wiadomości:
Kolega zaraz po otrzymaniu przesyłki przystępuje do jej rozszyfrowania. Wydaje więc polecenie:

[user@host]$ gpg --output wiadomość --decrypt ./tekst.asc

Po podaniu hasła odbezpieczającego klucz prywatny, GPG rozszyfruje i zweryfikuje wiadomość zapisaną w bieżącym katalogu w pliku tekst.asc (opcja –decrypt ./tekst.asc), a postać już rozkodowaną, zapisze w pliku wiadomość. Teraz Łukasz posiadając niezbędne dane może cieszyć się z nowego konta, a my mamy pewność, że zostały one dostarczone w bezpieczny sposób.


Szyfrowanie wiadomości:
Cały sekret polega na, zależności jaka istnieje między kluczami (prywatnym i publicznym), które zostały na samym początku wygenerowane. To co zaszyfrujemy przy pomocy klucza publicznego określonego użytkownika, jest możliwe do rozszyfrowania już tylko i wyłącznie przy pomocy jego klucza prywatnego. Działa to również i w odwrotną stronę, to co zakodujemy naszym kluczem prywatnym, można rozkodować przy pomocy naszego klucza publicznego. Teraz powinno strać się już jasne, dlaczego nie szyfrujemy całych wiadmości za pomocą naszego klucza prywatnego. Co z tego, że będzie ona zaszyfrowana, jak będzie ją mógł rozszyfrować każdy, kto posiada nasz ogólnodostępny klucz publiczny. Natomiast gdy zaszyfrujemy wiadomość używając klucza publicznego nadawcy, to tylko i wyłącznie on (używając swojego klucza prywatnego) będzie mógł ją rozkodować i przeczytać.


Wyszukiwanie kluczy publicznych:

Może się zdarzyć, że będziemy chcieli wysłać zaszyfrowaną wiadomość do kogoś, kto nie podał nam jeszcze numeru ID swojego klucza. Jeśli wcześniej klucz publiczny danej osoby został wyeksportowany do jednego z ogólnodostępnych serwerów, to jego zdobycie znając chociażby adres mailowy takiej osoby, nie powinno stanowić większego problemu. Załóżmy, że szukamy klucza publicznego należącego do osoby posiadającej adres j.krijthe@tiscali.nl, możemy go znaleźć za pomocą jednego polecenia:

[user@host]$ gpg --keyserver wwwkeys.pgp.net --search-keys j.krijthe@tiscali.nl
gpg: searching for "j.krijthe@tiscali.nl" from HKP server wwwkeys.pgp.net
Keys 1-1 of 1 for "j.krijthe@tiscali.nl"
(1)     Jesse Hendrik Krijthe (developer)
          1024 bit DSA key 5F1D78FA, created 2004-06-19
Enter number(s), N)ext, or Q)uit >

Jeśli uzyskane dane identyfikacyjne pasują do naszego odbiorcy, to pozostaje nam już tylko wpisać numer odnalezionej pozycji, po czym klucz zostanie automatycznie zaimportowany. Jako argument opcji –search-keys możemy podać również imię lub nazwisko szukanej osoby, generalnie, może to być dowolny wyraz jaki odbiorca wpisał w swoich danych identyfikacyjnych przy tworzeniu klucza.

Usuwanie kluczy:

Gdy posiadamy w naszej bazie nieaktualny, bądź przez pomyłkę zaimportowany klucz, możemy go w każdej chwili usunąć.  Załóżmy, że klucz użytkownika identyfikującego się w naszej bazie danych adresem user@serwer.pl stracił wczoraj ważność. Usuniemy go bez problemu używając opcji –delete-keys:

[user@host]$ gpg --delete-keys user@serwer.pl

Zostaniemy poproszeni o potwierdzenie naszej decyzji, po czym klucz zostanie ostatecznie usunięty z naszej bazy danych GPG.
W przypadku gdy chcemy usunąć swoją główną parę kluczy (publiczny / prywatny), bądź utworzyliśmy kilka takich par i np. jedna z nich nie jest już nam potrzebna, wtedy najpierw musimy użyć opcji –delete-secret-keys . Dla przykładu, załóżmy, że komuś udało się wejść w posiadanie naszego klucza prywatnego. Musimy teraz jak najszybciej wygenerować nową parę kluczy oraz rozesłać wszystkim znajomym nasz nowy klucz publiczny. Najpierw jednak musimy pozbyć się starej, nieaktualnej już pary. Usuwamy więc w pierwszej kolejności klucz prywatny:

[user@host]$ gpg --delete-secret-keys jan@programista.pl

Będziemy musieli dwukrotnie potwierdzić naszą decyzję, po czym zostanie nam jeszcze do usunięcia klucz publiczny:

[user@host]$ gpg --delete-keys jan@programista.pl

Teraz, po pozbyciu się nieaktualnych kluczy, powinniśmy utworzyć nową parę. Zrealizujemy to oczywiście za pomocą opisanej wcześniej opcji –gen-key.

Szyfrowanie symetryczne:

Ciekawą i często przydatną opcją jest możliwość symetrycznego szyfrowania plików z pomocą GnuPG. Możemy w ten sposób zakodować dowolny plik na naszym dysku. W tym przypadku nasze klucze nie są używane, a jedynie pojedyncze hasło, które jest potrzebne do zaszyfrowania i rozszyfrowania pliku. Chcąc zaszyfrować np. plik dane.txt z katalogu bieżącego, wystarczy, że wydamy polecenie:

[user@host]$ gpg --symmetric dane.txt

Po podaniu hasła szyfrującego powinniśmy teraz posiadać obok pliku jawnego dane.txt, jego zakodowaną wersję dane.gpg. Pamiętajmy, że oryginał nie jest automatycznie usuwany. Teraz, gdy będziemy chcieli rozkodować nasz plik, wydamy polecenie:

[user@host]$ gpg --output dane.txt --decrypt dane.gpg

Otrzymamy (oczywiście po podaniu odpowiedniego hasła) zapisaną w pliku dane.txt, rozszyfrowaną wiadomość z dane.gpg. Domyślnie program wyświetla wynik tej operacji na standardowym wyjściu, jednak dzięki opcji –output zapiszemy wszystko w osobnym pliku. Dzięki symetrycznemu szyfrowaniu dostęp do jawnych danych zawartych w pliku dane.gpg mają jedynie osoby znające nasze hasło. Jest to szczególnie przydatne gdy musimy ważne dane umieścić na ogólnodostępnym serwerze, a chcemy, aby ich treść mogły poznać tylko niektóre osoby.


GnuPG w Windows:
Obsługa GnuPG w wersji dla Windows nie różni się niczym od opisanej w artykule wersji linuksowej.  Jedynie inaczej wygląda procedura instalacyjna.

Aby poprawnie zainstalować GnuPG (w wydaniu dla Windows) należy najpierw ściągnąć źródła znajdujące się pod adresem:
ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.2.5.zip

Ściągnięte archiwum możemy rozpakować w dowolnym miejscu. Ważne jest, abyśmy utworzyli na dysku c: katalog gnupg. Możliwa jest inna lokalizacja naszego programu, ale dla innej niż c:gnupg będziemy musieli dokonać modyfikacji rejestru w gałęzi HKEY_CURRENT_USER->Software->GNU-> GnuPG.

Po utworzeniu katalogu kopiujemy do niego gpg.exe, gpgv.exe oraz gpgkeys_ldap.exe z rozpakowanego wcześniej archiwum. W tym momencie nasza aplikacja powinna już funkcjonować poprawnie. Jednak aby za każdym razem nie podawać pełnej ścieżki dostępu do gpg.exe, powinniśmy zmodyfikować zmienną PATH. W systemach Windows NT/2000/XP możemy tego dokonać odpowiednio w Panel sterowania-
->System–> Zaawansowane–>Zmienne środowiskowe–>Zmienne systemowe

Natomiast jeśli posiadamy systemy Windows 95/98/ME, wspomniana zmienna znajduje się w  c:autoexec.bat. Wartości podane w zmiennej PATH rozdzielone są średnikiem, należy więc na samym końcu wspomnianej zmiennej dodać średnik oraz ciąg c:gnupg. Czyli, jeśli nasza zmienna PATH wygląda tak:
c:windows;c:utils
wtedy powinniśmy ją zmienić na:
c:windows;c:utils;c:gnupg

Po powyższych zabiegach, jeśli posiadamy system Win95/98/ME powinniśmy zrestartować komputer, natomiast w przypadku WinNT/2000/XP wystarczy jedynie otworzyć nowy wiersz poleceń. Teraz GnuPG powinno działać bez zarzutów.  


GnuPG w programach pocztowych:

Obecnie większość popularnych klientów pocztowych wspiera GnuPG i nie ma już potrzeby wysyłania podpisanych bądź zaszyfrowanych wiadomości w załącznikach. Należą do nich chociażby Mutt, Evolution, Pine, VM, Kmail oraz wiele innych. Ja osobiście używam programu Evolution, w którym podpisywanie i szyfrowanie wiadomości z wykorzystaniem GnuPG jest banalnie proste (wystarczy jedynie zaznaczyć odpowiednią opcję przy pisaniu listu). Cała konfiguracja ogranicza się jedynie do podania przy konfiguracji konta, numeru ID klucza którym mają być podpisywane nasze wiadomości. Program automatycznie pobiera klucze publiczne innych użytkowników z bazy danych GnuPG, gdy zachodzi konieczność wysłania zaszyfrowanej korespondencji.  Bardzo podobnie wygląda sprawa również w programie Kmail.
Prawdę mówiąc wszystko zależy od naszego klienta pocztowego.  Niektóre z nich mają standardowo wbudowane elementy szyfrujące przy pomocy GnuPG, inne ich nie mają a do jeszcze innych należy je dołączyć.
Jednak mimo wszystko, bardzo ważna jest umiejętność obsługi Gnu Privacy Guard z poziomu wiersza poleceń. Staje ona szczególnie przydatna, gdy pojawiają się problemy z modułami obsługującymi GnuPG. Pamiętajmy, że większość klientów pocztowych obsługuje GnuPG, kierując do GPG i odbierając z niego wiadomości, używając przy tym opisanych w artykule opcji.  

Podsumowanie:

Współczesna kryptografia oferuje nam ciekawe możliwości służące ochronie naszych danych oraz tożsamości. Mam nadzieję, że po lekturze powyższego tekstu każdy zrozumiał na jakiej zasadzie działa tak popularna i powszechnie dzisiaj wykorzystywana technologia klucza publicznego. Myślę, że dzięki znajomości opisanych w artykule zagadnień oraz wspaniałej aplikacji GNU Privacy Guard, będziemy teraz w bezpieczny sposób wysyłać korespondencję oraz przechowywać poufne dane. Jest to dzisiaj, w dobie tak dynamicznie rozwijającej się sieci internet niezmiernie ważna umiejętność.

Archiwalny news dodany przez użytkownika: Krzysztof Śniadoch.
Kliknij tutaj by zobaczyć archiwalne komentarze.

Oznaczone jako → 
Share →