Obok informacji jawnych istnieją jednak informacje o mniejszym lub większym stopniu tajności. Nie muszą to być od razu dane wywiadowcze o rozmieszczeniu rakiet strategicznych - np. listy miłosne od ukochanej(-ego) zwykle traktujemy jako tajemnicę i nie mamy ochoty pozwalać komukolwiek na ich czytanie. Z przesyłaniem informacji tajnych możemy mieć do czynienia także w przypadku innych usług sieciowych niż e-mail - klasycznym przykładem jest tu dokonywanie zakupów za pośrednictwem WWW, gdzie aby zapłacić, musimy zwykle w przedstawionym przez serwer formularzu wpisać (tajny) numer naszej karty kredytowej. Jako informację prywatną, a nawet tajną możemy też traktować np. cały przebieg połączenia telnetowego z naszym kontem na jakimś odległym komputerze. Tajną, gdyż w trakcie tego połączenia przesyłane jest przez sieć "otwartym tekstem" m.in. nasze hasło!
Popularne jest przekonanie o całkowitym braku bezpieczeństwa informacji w Internecie. Mówi się, że nie powinno się przesyłać przez Internet żadnych takich treści, których nie chciałoby się zobaczyć na najbliższym słupie ogłoszeniowym - czyli, innymi słowy, wysłanie czegokolwiek "w sieć" jest równoznaczne z natychmiastowym udostępnieniem tej informacji każdemu, kto tylko będzie chciał. Tradycyjny telefon czy faks uważany jest przez wiele firm za medium bezpieczniejsze - stąd np. niektóre firmy umożliwiające zamawianie towarów za pośrednictwem WWW wymagają jednak podania najważniejszej informacji - czyli numeru karty kredytowej - środkami tradycyjnymi.
Pogląd ten zdaje się być przesadzony. Podsłuch w Internecie jest mniej więcej tak samo trudny (albo nietrudny...), jak podsłuch zwykłego telefonu. Jedno i drugie nie jest całkowicie trywialne i wymaga od "podsłuchiwacza" pewnych umiejętności i wyposażenia - rzecz jasna jednak, że jedno i drugie nierzadko się zdarza. Pewnym argumentem na rzecz przekonania o większym niebezpieczeństwie Internetu może być natomiast fakt, że tutaj podsłuchiwać można o wiele skuteczniej (czyli przechwytywać większą ilość informacji i łatwiej je analizować), przy tym praktycznie bez pozostawiania żadnych śladów. Całkowicie natomiast nieodporny jest Internet - ze względu na brak jakichkolwiek mechanizmów tzw. autentykacji użytkownika (czyli potwierdzenia jego tożsamości) - na próby podszywania się pod inne osoby: wysłanie np. listu elektronicznego w czyimś imieniu, z fałszywym adresem zwrotnym, nie stanowi żadnego problemu.
W "prawdziwych" współczesnych szyfrach oczywiście nie koduje się informacji ręcznie - w zetknięciu z profesjonalną kryptoanalizą nie miałyby żadnych szans. To skomplikowane algorytmy komputerowe, przekształcające szyfrowany tekst w ciąg bajtów pozornie bez żadnego sensu, wyglądających na zupełnie przypadkowe i nie wykazujących żadnego uchwytnego podobieństwa do tekstu w postaci jawnej - przynajmniej na pierwszy rzut oka. Ich złamanie jest niezwykle trudne, a w przypadku najlepszych szyfrów wydaje się być wręcz niemożliwe przy współczesnym stanie techniki - nawet dla agencji wywiadowczych. (Zainteresowanych "na poważnie" szyframi warto w tym miejscu zaprosić do grupy newsowej sci.crypt, a zwłaszcza do przeczytania jej FAQ, dostępnego pod adresem ftp://ftp.cyf-kr.edu.pl/pub/mirror/usenet/news.answers/cryptography-faq/)
Zastosowanie takich szyfrów do ochrony poczty elektronicznej, czy innych informacji przesyłanych przez Internet, wydawałoby się zatem oczywiste. Jest jednakże jeden problem: wszystkie tradycyjne systemy szyfrowania, od starożytności do dnia dzisiejszego, opierają się na jednej podstawowej zasadzie - istnienia wspólnego, tajnego klucza do szyfru, który musi być używany przez obie porozumiewające się strony - z jednej strony do zaszyfrowania wiadomości, z drugiej do jej odszyfrowania. Ogranicza to w sposób istotny możliwość stosowania takiego szyfru do osób bądź instytucji, które nawzajem się znają i mają możliwość przekazania sobie w sposób bezpieczny (najlepiej "z ręki do ręki" przy osobistym spotkaniu) klucza do szyfru. O powszechnym korzystaniu z szyfrów w Internecie nie ma w takiej sytuacji nawet co marzyć - w jaki sposób mam uzgadniać ze wszystkimi, z którymi się będę kontaktował, klucze do szyfru? Mogą oni wszak znajdować się na innym kontynencie (i bardzo często się znajdują), a Internet może być moją jedyną drogą komunikacji z nimi.
Algorytm szyfrowania z kluczem publicznym skonstruowany jest tak, że to, co zostanie zaszyfrowane kluczem publicznym, może być odszyfrowane jedynie kluczem prywatnym z tej samej pary. Zatem każdy, kto zna mój klucz publiczny, może wysłać do mnie zaszyfrowany list - i listu tego nie będzie mógł odczytać nikt poza mną. Udało się zatem uzyskać bezpieczną metodę komunikacji, bez problemów z przekazywaniem tajnego klucza.
Algorytm działa również w odwrotną stronę: to, co zostanie zaszyfrowane moim kluczem prywatnym, może być odszyfrowane przez każdego, kto zna mój klucz publiczny. Na co jednak przydać się może taki szyfr, który każdy może odczytać? Otóż fakt, że wiadomość daje się odszyfrować moim kluczem publicznym, stanowi dowód, że w istocie musi ona pochodzić ode mnie - gdyż tylko ja posiadam klucz prywatny, niezbędny do jej zaszyfrowania (zakładając, że nikt mi go nie ukradł...), wyklucza więc możliwość podszycia się pode mnie kogokolwiek. "Odwrócone" szyfrowanie staje się zatem elektronicznym podpisem - w odróżnieniu od zwykłego podpisu na papierowym dokumencie niemal całkowicie niepodrabialnym.
W praktyce jednak szyfrowanie całej przesyłanej wiadomości algorytmem RSA nie jest stosowane w żadnym z tych programów - algorytmem ten jest bowiem zbyt powolny. Faktycznie za pomocą RSA szyfruje się jedynie... klucz dla innej, tradycyjnej (czyli wykorzystującej pojedynczy klucz) metody szyfrowania. Klucz ten, zwany kluczem sesji, jest losowo generowany dla każdego połączenia i w bezpieczny sposób (bo z wykorzystaniem RSA) przekazywany drugiej stronie. Cała dalsza transmisja jest już szyfrowana tradycyjnie przy pomocy tego klucza. Do tradycyjnych szyfrów najczęściej stosowanych w oprogramowaniu Internetowym należą: amerykański federalny standard ochrony danych DES (Data Encryption Standard), uważany za praktycznie "niełamalny" szwajcarski algorytm IDEA (International Data Encryption Algorithm), napisany w ETH w Zurychu (ten właśnie algorytm wykorzystywany jest w PGP *) oraz szyfry RC2 i RC4, zaprojektowane przez Rona Rivesta - jednego z twórców RSA - już dla nowej firmy RSA Data Security Inc. (te z kolei stosowane są w przeglądarkach WWW).
Program PGP (Pretty Good Privacy), napisany na początku lat dziewięćdziesiątych przez Phila Zimmermanna, był programem, który wprowadził kryptografię "pod strzechy". Do chwili jego powstania dostęp do zaawansowanych technik szyfrowania miały tylko służby specjalne oraz bogate firmy. PGP udostępniło je każdemu użytkownikowi Internetu. Wobec wykorzystania dwóch bardzo wysokiej klasy algorytmów szyfrujących - RSA i IDEA - nazwa "całkiem niezła prywatność", którą "ochrzcił" swoje dzieło Phil Zimmermann, wydaje się być nadmierną skromnością, albo... świadomą złośliwością pod adresem potencjalnych "podsłuchiwaczy" wiadomości zakodowanych przez PGP. Ochrona zapewniana przez użycie tego programu jest bowiem daleko lepsza niż tylko "niezła".
Po pierwsze, algorytm RSA jest w USA opatentowany. Właścicielem patentu jest firma RSA Data Security Inc. (wcześniej Public Key Partners), założona przez twórców algorytmu wkrótce po jego opublikowaniu. Nikt zatem nie ma prawa używać tego algorytmu bez zgody wspomnianej firmy. Firma RSA Inc. zezwala jednak na bezpłatne używanie algorytmu do celów niekomercyjnych, pod warunkiem że wykorzystywane będą wyłącznie oryginalne procedury firmy RSA, udostępniane specjalnie na ten cel w postaci biblioteki o nazwie RSAREF. Wcześniejsze wersje PGP nie używały biblioteki RSAREF, lecz procedur napisanych własnoręcznie przez Phila Zimmermanna, w istocie łamały więc prawa patentowe RSA Inc. Po porozumieniu autora programu z firmą RSA obecna wersja PGP używa już biblioteki RSAREF.
Patent firmy RSA nie obowiązuje poza USA, tak więc wersja "międzynarodowa" PGP, przeznaczona do użytku poza USA, może swobodnie używać (i w istocie używa) własnych procedur Phila Zimmermanna. Tu jednak pod adresem autora pojawiło się oskarżenie o wiele poważniejsze: złamanie amerykańskich ograniczeń dotyczących eksportu broni (ITAR), za co grożą bardzo wysokie kary - do 10 lat więzienia oraz miliona dolarów grzywny. Co ma oprogramowanie szyfrujące do eksportu broni? Otóż prawo amerykańskie traktuje każde urządzenie, bądź program komputerowy, zawierające funkcje szyfrowania, analogicznie jak broń, i zakazuje ich eksportu bez specjalnego pozwolenia. O oczywistym bezsensie tego przepisu świadczy fakt, że np. kod źródłowy tego samego programu szyfrującego wydrukowany w książce - i to do tego specjalną czcionką pozwalającą na łatwe wczytanie go do komputera przy pomocy skanera - analogicznym restrykcjom eksportowym nie podlega i książka taka może być swobodnie sprzedawana poza USA. Inną "ciekawostką" jest to, że przepis ten stosuje się on także do oprogramowania pochodzącego spoza USA, które zostało do USA sprowadzone, a następnie ktoś chciałby je wysłać z powrotem za granicę!
Faktem jest jednakże, że taki przepis istnieje i program Phila Zimmermanna niewątpliwie mu podlega. Faktem było także, że w jakiś sposób program zawędrował poza USA - a bo to trudno, gdy dostępny jest w Internecie? Nie da się ustalić, kto pierwszy "wyeksportował" PGP - najprawdopodobniej ktoś z zagranicy "ściągnął go" z jakiegoś amerykańskiego serwera, niemniej jednak oskarżono o to jego autora (po długim dochodzeniu sprawę wreszcie umorzono w styczniu 1996 r.) Jednak niezależnie od ewentualnej nielegalności czynu, jakim jest eksport programu poza granice USA, późniejsze używanie wyeksportowanego w ten sposób programu jest już czynnością całkowicie legalną - zatem używając PGP otrzymanego ze źródła znajdującego się poza USA nie łamie się żadnego prawa.
W efekcie istnieją obecnie trzy wersje PGP *:
Pierwszą czynnością, którą musimy wykonać po zainstalowaniu PGP, jest wygenerowanie naszej pary kluczy - prywatnego i publicznego. Dokonujemy tego, wydając komendę (jednakowo w DOS-ie i w Unixie):
pgp -kgPo wydaniu tej komendy, program pyta o długość klucza. Im dłuższy klucz, tym wyższy poziom bezpieczeństwa zapewniany przez szyfr. Można wybrać jedną ze standardowych długości (512 bitów - "niski poziom komercyjny", 768 - "wysoki poziom komercyjny", 1024 - "poziom wojskowy") lub własną, z przedziału 504-2048 bitów. Firma RSA Inc. uważa, że szyfr o długości klucza 512 bitów jest już obecnie niezbyt bezpieczny; zaleca używanie klucza co najmniej 768-bitowego, która to długość powinna zapewniać bezpieczeństwo do około roku 2004.
Po podaniu długości klucza pojawia się pytanie o identyfikator użytkownika, który powinien jednoznacznie określać właściciela klucza. Zwykle podaje się go w postaci imienia i nazwiska oraz adresu e-mail, zapisanych w sposób podobny do poniższego:
Jan Kowalski <kowalski@gdzies.w.sieci.pl>Klucz prywatny może być chroniony hasłem, co uniemożliwi skorzystanie z niego osobom postronnym, nawet gdyby dostał się on w ich ręce. Hasła należy używać zawsze wtedy, gdy istnieje niebezpieczeństwo, że do naszego klucza prywatnego może mieć dostęp ktoś inny (np. gdy przechowujemy go na naszym koncie w systemie wielodostępnym, takim jak Unix, wówczas ma do niego dostęp administrator systemu - w zasadzie jednak nie jest to najlepsze miejsce do przechowywania swojego klucza prywatnego). Kolejne pytanie zadawane przez program odnosi się właśnie do tego hasła. Wpisywane hasło - jak to zwykle bywa w takich przypadkach - nie pojawia się oczywiście na ekranie, i należy wpisać je dwukrotnie w celu weryfikacji. Nie wolno go rzecz jasna zapomnieć - nie ma żadnej możliwości jego odtworzenia, a klucz prywatny bez hasła jest bezużyteczny. Ponieważ PGP nie dysponuje praktycznie żadnym skutecznym mechanizmem unieważniania kluczy (jest to jedna z nielicznych wad tego programu), sytuacja taka jest niezwykle nieprzyjemna, gdyż nasi korespondenci wciąż będą mogli pisać do nas listy szyfrując je naszym kluczem publicznym, a my (ani nikt inny) nie będziemy w stanie ich odczytać. Jeżeli nie chcemy hasła (wskazane jedynie w przypadku, gdy klucz przechowujemy na prywatnym komputerze, do którego nikt poza nami nie ma dostępu), przyciskamy sam klawisz ENTER.
Następnie program prosi o wpisanie kilkudziesięciu znaków dowolnego tekstu. Istotny tu jest nie sam tekst, ale odstępy czasowe między naciśnięciami klawiszy, które służą jako źródło liczby losowej, użytej następnie do tworzenia klucza. W ten sposób PGP uzyskuje praktyczną niepowtarzalność kluczy. Wygenerowanie klucza - w zależności od jego długości i od szybkości komputera - może trwać od kilku-kilkunastu sekund nawet do kilku minut. Po zakończeniu tego procesu utworzone zostaną dwie bazy kluczy (key rings), zawierające na razie tylko nasze własne klucze: baza kluczy publicznych znajdzie się w pliku o nazwie pubring.pgp, zaś baza kluczy prywatnych - w pliku secring.pgp. Ta druga baza zwykle zawierać będzie zawsze tylko jeden klucz - nasz własny (aczkolwiek możliwe jest posiadanie kilku kluczy prywatnych - np. jednego do użytku prywatnego, drugiego służbowego, albo jednego 512-bitowego do korespondencji o mniejszym znaczeniu, a drugiego 2048-bitowego do korespondencji ściśle tajnej), do pierwszej natomiast - w miarę korzystania z programu - dodawać będziemy klucze publiczne naszych korespondentów.
Warto tu jeszcze raz podkreślić, że korzystanie z PGP nie zapewni nam żadnego bezpieczeństwa, jeżeli nie zadbamy o należytą ochronę naszego klucza prywatnego. Zdecydowanie niewłaściwym miejscem do jego przechowywania byłby niezabezpieczony niczym dysk twardy komputera klasy PC, do którego dostęp ma jeszcze ktoś poza nami! (np. w pracy). Nieco lepsze jest konto w systemie Unix czy podobnym, choć - jak już powiedziano wyżej - w tym przypadku dostęp do naszego klucza ma (przynajmniej) administrator systemu. Teoretycznie najbardziej wskazanym sposobem przechowywania klucza prywatnego jest dyskietka, noszona przy sobie lub trzymana w zamknięciu, ewentualnie dysk twardy komputera dostępnego tylko właścicielowi.
Klucz publiczny należy natomiast jak najszerzej rozpropagować. W tym celu z reguły będzie nam potrzebna jego postać tekstowa, "wyciągnięta" z pliku pubring.pgp. Dokonujemy tego komendą
pgp -kxa użytkownik plik.txtgdzie "użytkownik" jest dowolnym fragmentem identyfikatora użytkownika, którego klucz chcemy uzyskać (a więc w naszym przykładzie może to być np. "kowalski"), a "plik.txt" - nazwą pliku, do którego ma być zapisany klucz. Przekształcony do postaci tekstowej klucz naszego Jana Kowalskiego wyglądać może następująco:
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQBNAzNyFhEAAAECAL33pur76v7YLJXpOFd5XG0GpeqJKF9OWlVW5Rb0/tFaSUu5 2MB7vPyU9Ls8HHdSjc3pdeRMhI7KV2u8rc4/tAUABRG0KUphbiBLb3dhbHNraSA8 a293YWxza2lAZ2R6aWVzLncuc2llY2kucGw+iQBVAwUQM3IWEldrvK3OP7QFAQGZ cQIAg8vgTWdut8AvjR1tzNXhGIjfPB7uqlqvIQz4loSE56lFxcZnq1fW3V58uVgc hHdc+m5aCi5sTzKHBuTbdIs2Zw== =eQ8+ -----END PGP PUBLIC KEY BLOCK-----Taki klucz możemy umieścić np. na swojej stronie WWW, w treści informacji o naszym koncie wyświetlanej przez komendę "finger" (na kontach Unixowych jest to plik .plan w prywatnym katalogu użytkownika), czy też rozesłać go wszystkim znajomym e-mailem.
pgp -ka plik.txt(plik.txt jest oczywiście nazwą pliku zawierającego klucz). W tym momencie program pokaże nam identyfikator użytkownika, do którego należy wprowadzany klucz, a następnie zada nam jakieś niezbyt zrozumiałe pytania na temat wiarygodności tego użytkownika i naszej chęci podpisania jego klucza - zajmiemy się tym jeszcze dalej, a na razie na wszelki wypadek odpowiedzmy "nie".
Gdy mamy już klucz publiczny adresata w swojej bazie kluczy, możemy przystąpić do zaszyfrowania listu. Piszemy jego treść w jakimkolwiek edytorze ASCII (np. tym zawartym w Norton Commanderze), i po zapisaniu pliku na dysku wydajemy komendę
pgp -ea plik.txt użytkownikna przykład "pgp -ea tajne.txt Malinowski", czego efekt będzie następujący:
Pretty Good Privacy(tm) 2.6.3i -- Kryptografia publiczna dla mas. (c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18 Wersja miedzynarodowa - do uzytku poza USA. Nie wykorzystuje RSAREF. Aktualny czas: 1997/05/08 18:57 GMT Do szyfrowania zostanie uzyty klucz(e) publiczny odbiorcy. Uzytkownik: Antoni Malinowski <malin@gdzie.indziej.pl> Klucz 512-bitowy numer 7CCA4E71, stworzony 1997/05/08 . Szyfrogram w opakowaniu ASCII: tajne.ascJak widać, utworzony zostanie plik o takiej samej części głównej nazwy, co oryginalny list, i rozszerzeniu .asc. Teraz ten plik możemy wczytać do naszego programu pocztowego (większość programów ma taką możliwość) i wysłać do adresata. Zaszyfrowany list wyglądać może w taki oto sposób:
-----BEGIN PGP MESSAGE----- Version: 2.6.3i hEwDTi8VD3zKTnEBAf97rXWRGbfQJMOWKAAmuFxl0jw1NaA0riumPIrH2FaDwTFV ezrYuavaehFWqAUbvnDcVVw7HsOauX17GDnuhncypgAAAMdvm7lmazIk3TXiJWiN oBOTJo6r0QIX3PS62BIPe/ur1krk5gNkKRs/j4Vk3UJPevspyt7xvC5RZbDZKYIj Cnn5gdNUh4Ke5VpNrv8pOHs+/kCUn9bp3s11TznR/9/8iH0gwi9JjEqBwLm8RNiB +eAu2V/ggyin03QrmWLia181a7p74VEs3l1h+6aZt0DYUinjZ1X4SX2N0rixLJs1 zds6rCKCjHxzIGLLLCNmGbdMxL61STUnDOvc0wjHH0wlLCSHtQofauwm =vDWq -----END PGP MESSAGE-----Odbiorca takiego listu wydaje - po zapisaniu go do pliku - po prostu komendę pgp nazwa_pliku, a program sam rozpozna, co w tym pliku się znajduje, odszuka w naszej bazie kluczy odpowiedni klucz prywatny i zdekoduje list:
Pretty Good Privacy(tm) 2.6.3i -- Kryptografia publiczna dla mas. (c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18 Wersja miedzynarodowa - do uzytku poza USA. Nie wykorzystuje RSAREF. Aktualny czas: 1997/05/08 18:58 GMT Plik jest zaszyfrowany. Do rozszyfrowania potrzebny jest tajny klucz. Uzytkownik: Antoni Malinowski <malin@gdzie.indziej.pl> Klucz 512-bitowy numer 7CCA4E71, stworzony 1997/05/08 Uwaga: Twoj tajny klucz nie jest chroniony przez haslo! Chwileczke...... Nazwa wynikowego pliku jawnego: listZgodnie z tym, co mówiliśmy na wstępie, "odwrócone" szyfrowanie - tzn. kluczem prywatnym zamiast publicznego - daje w wyniku podpis elektroniczny. Wiadomość wprost zaszyfrowana naszym kluczem prywatnym będzie jednak wyglądać równie niezrozumiale, co ta powyżej, choć oczywiście za pomocą PGP da się odczytać bez trudu. W sytuacjach, w których potrzebny jest podpis elektroniczny, bardziej wskazane jest jednak, aby podpisywany list zapisany był tekstem jawnym, czytelnym bez stosowania dodatkowych programów, a PGP niezbędne było tylko do weryfikacji podpisu, a nie do odczytania samej wiadomości (choć oczywiście, jeżeli istnieje taka potrzeba, list może być zarówno podpisany - kluczem prywatnym nadawcy, jak i zaszyfrowany - kluczem publicznym odbiorcy). List taki wygląda podobnie do poniższego (uzyskuje się to komendą pgp -sta plik.txt):
-----BEGIN PGP SIGNED MESSAGE----- Jan Kowalski ul. Niczyja 7 Krakow Niniejszym zamawiam i prosze o przyslanie na moj adres 10 sztuk dyskow twardych Maxtor 7020A. Naleznosc zobowiazuje sie uregulowac przelewem z mojego konta do 7 dni po otrzymaniu faktury. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQBVAwUBM3IbiFdrvK3OP7QFAQGUHgH/QIXAoJjEEsuW9AUTMNNSNhAs8EOd5zeE OeLY0Pe13VqJmb/GvucQVFhLOqV/F3VYq3goz2xlcpuJ/aMPMW8tpw== =OiNw -----END PGP SIGNATURE-----Aby uzyskać tego rodzaju elektroniczny podpis, szyfrowaniu kluczem prywatnym nie podlega cała wiadomość, lecz jej tzw. skrót (message digest) - kilku-kilkunastobajtowa wartość, obliczona na podstawie treści wiadomości (od linii "BEGIN PGP SIGNED MESSAGE" do "BEGIN PGP SIGNATURE") za pomocą specjalnej tzw. funkcji mieszającej (hash function). Funkcje takie mają tę właściwość (w podobny sposób liczone są tzw. sumy kontrolne, używane do weryfikacji nienaruszalności plików w programach antywirusowych lub w programach kompresujących takich jak PKZIP), że praktycznie niemożliwe jest skonstruowanie dwóch wiadomości, które dawałyby identyczny wynik funkcji mieszającej - stąd nadrobniejsza nawet zmiana w treści listu daje inną wartość skrótu, a zatem i inny elektroniczny podpis. Sprawdzenie podpisu w takim liście (podobnie jak w przypadku rozszyfrowywania, komendą pgp nazwa_pliku) spowoduje wyświetlenie następującej informacji:
Pretty Good Privacy(tm) 2.6.3i -- Kryptografia publiczna dla mas. (c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18 Wersja miedzynarodowa - do uzytku poza USA. Nie wykorzystuje RSAREF. Aktualny czas: 1997/05/08 18:58 GMT Plik jest opatrzony sygnatura. Do jej sprawdzenia wymagany jest klucz publiczny autora tej sygnatury . . Dobra sygnatura: "Jan Kowalski <kowalski@gdzies.w.sieci.pl>". Sygnatura stworzona 1997/05/08 18:29 GMT, 512-bitowym kluczem numer CE3FB405 Nazwa wynikowego pliku jawnego: zamkowalMamy zatem niemożliwy do podrobienia (i do wyparcia się) dowód, że autorem tego listu jest Jan Kowalski. Niestety, podpisy elektroniczne (nie tylko stworzone przez PGP, ale i jakiekolwiek inne oprogramowanie) nie są w chwili obecnej w Polsce uznawane prawnie, aczkolwiek mimo to istnieją np. firmy, które honorują je w kontaktach handlowych. Najwyższy czas na zmianę przepisów...
Sęk w tym, że identyfikator związany z kluczem, podawany przez użytkownika w chwili jego tworzenia, może być zupełnie dowolny! Nic nie stoi na przeszkodzie, aby ktokolwiek np. wygenerował klucz publiczny (i tym samym posiadał odpowiadający mu klucz prywatny) o identyfikatorze:
Bill Clinton <president@whitehouse.gov>Jeżeli ktoś da się nabrać i będzie używał fałszywego klucza (akurat w powyższym przypadku jest dość powszechnie wiadome, że właściciel tego konta nie używa PGP), będzie weryfikował sfałszowane listy jako poprawne. Próba zaś użycia tego klucza do zaszyfrowania listu spowoduje, że prawowity adresat nie będzie mógł go odczytać (będzie go mógł odczytać natomiast właściciel fałszywego klucza, gdyby jakimś sposobem list ten dostał się w jego ręce). Po co zatem ten cały raban z kluczami publicznymi, skoro i tak nadal nie wiadomo, czy wskazana na kluczu osoba jest faktycznie tą, za którą się podaje? Abyśmy mogli być tego pewni, musimy uzyskać jej klucz publiczny z wiarygodnego źródła. Najlepiej byłoby oczywiście otrzymać go bezpośrednio od tej osoby, ale raczej nie e-mailem - pamiętajmy, jak łatwo jest sfałszować adres zwrotny elektronicznego listu! Nieprzypadkowo do udostępniania kluczy publicznych wykorzystuje się najczęściej komendę "finger". Pomimo jej prostoty (a może właśnie dzięki temu) jest ją raczej trudno "ogłupić" tak, aby pobrała informację z niewłaściwego miejsca. Jeżeli zatem znamy adres e-mail, z którego interesująca nas osoba zwykle pisze listy, i po sięgnięciu pod ten adres komendą "finger" odnajdujemy klucz publiczny, to z dużym prawdopodobieństwem możemy sądzić, że jest on autentyczny. Z kluczami umieszczonymi na stronach WWW może być już gorzej, bo adres strony WWW może być czasami bardzo różny od adresu pocztowego użytkownika, i wcale nie musimy mieć pewności, czy zamiast prawdziwej strony WWW danej osoby nie oglądamy "podstawionej" strony należącej rzekomo do niej, której adres (fałszywy) został nam podany w sfałszowanym e-mailu (ejże, czy to aby nie brzmi jak lekka paranoja?)
Tego typu wątpliwościom zaradzić ma certyfikowanie kluczy. Certyfikowanie klucza to po prostu potwierdzenie jego autentyczności (czyli tego, że klucz faktycznie należy do osoby, której nazwisko na nim widnieje) przez inną osobę, do której (a właściwie do której klucza) mamy zaufanie. Tutaj mamy do czynienia z diametralną różnicą pomiędzy PGP i wspomnianym wcześniej systemem PEM. W PEM certyfikowanie kluczy jest wybitnie sformalizowane: system ten zakłada całą hierarchię tzw. urzędów certyfikacyjnych (certification authorities - CA), poczynając od najwyższego w hierarchii, poprzez kolejne niższe stopnie, aż do tych wystawiających bezpośrednio certyfikaty użytkownikom (identycznie zresztą zorganizowany jest system certyfikatów używanych przez SSL w przeglądarkach WWW). Trudności w stworzeniu takiej sieci CA są też zapewne jedną z przyczyn małej popularności tego standardu. W przeciwieństwie do PEM, w PGP nie ma żadnych urzędów certyfikacyjnych - każdy może certyfikować klucz publiczny każdego. Każdy może również wedle własnej woli uznawać lub nie uznawać certyfikatów wystawionych przez określonych użytkowników. Kiedy dodajemy nowy klucz publiczny do swojej bazy kluczy, program sprawdza posiadane przez ten klucz certyfikaty. Jeżeli klucz nie posiada żadnego wiarygodnego certyfikatu - tzn. albo nie posiada certyfikatu w ogóle, albo certyfikat został wystawiony przez użytkownika(ów), którego nie ma w naszej bazie kluczy, bądź też jest, ale uznaliśmy go za niewiarygodnego - program pyta się, czy chcemy sami certyfikować ten klucz. Zróbmy to tylko wtedy, jeżeli naprawdę jesteśmy pewni, że jest to autentyczny klucz należący do danej osoby!
Jeżeli zdecydujemy się certyfikować czyjś klucz, musimy jeszcze odpowiedzieć na pytanie, jak będziemy traktować certyfikaty wystawione innym użytkownikom przez posiadacza tego właśnie klucza - do wyboru są cztery stopnie zaufania, od całkowicie niewiarygodnego do całkowicie wiarygodnego. Brzmi to wszystko dosyć skomplikowanie i wymaga pewnego "oswojenia się", jednakże na początek, przy wprawianiu się w używaniu PGP, można się problemem certyfikatów nie przejmować - ustawiony poziom zaufania do danego użytkownika można zawsze potem zmienić przy pomocy odpowiednich opcji programu.
W niniejszym tekście omówiono oczywiście tylko najbardziej podstawowe funkcje programu PGP. Chcący poznać więcej możliwości mogą sięgnąć do dostępnego w sieci tekstu Szymona Sokoła [1], bądź - najlepiej - od razu do samej dokumentacji programu (jest dostępna również w języku polskim!).
Aby rozszyfrować zakodowaną wiadomość, nie trzeba jednak koniecznie łamać RSA! Treść wiadomości jest przecież w istocie szyfrowana - jak wiemy - "klasycznym" szyfrem z tajnym kluczem. "Wystarczy" złamać ten klucz... Tu sytuacja wydaje się jednakże jeszcze gorsza (rzecz jasna, dla osoby chcącej złamać szyfr, nie dla jego użytkownika) - współczesne algorytmy szyfrowania "tradycyjnego" osiągnęły taki poziom doskonałości, że praktycznie nie poddają się żadnym typowym metodom kryptoanalizy - porównaniu z tekstem jawnym itp. Jedyną szansą ich złamania - realną dzięki znacznemu wzrostowi mocy obliczeniowej komputerów - pozostaje atak typu "brute force" (czyli "na siłę"), tzn. wypróbowanie po kolei wszystkich możliwych kluczy. Najistotniejszą rolę odgrywa w tym przypadku rzecz jasna długość klucza - im jest on dłuższy, tym więcej możliwości do wypróbowania, a zatem tym bezpieczniejszy szyfr. Na początku 1996 r. ukazał się ciekawy raport opracowany przez grupę kryptologów dla Business Software Alliance [6], podający przybliżone czasy łamania szyfrów o różnych długościach klucza przez różne kategorie atakujących. Okazuje się, że szyfry o kluczach 40-bitowych, stosowane w "eksportowych" wersjach np. przeglądarek WWW (jest to obecnie w praktyce największa długość klucza, jaka uzyskuje licencję eksportową USA), nie zapewniają praktycznie żadnej ochrony - nawet pojedynczy hacker, wykorzystujący do obliczeń "jałowy" czas kilku komputerów, np. na uczelni (gdy nie wykonują one żadnych użytecznych prac użytkowników), może złamać ten szyfr w przeciągu ok. tygodnia. Jeżeli ten sam hacker jest w stanie zainwestować 400 dolarów w komputer z kartą FPGA (pozwalającą wykonywać pewne specyficzne rodzaje obliczeń ok. 1000 razy szybciej niż na zwykłym PC), wynik otrzyma po pięciu godzinach. W przypadku dużych firm, mogących zainwestować znacznie większe sumy w specjalizowane komputery, czasy łamania szyfru 40-bitowego mierzy się już w sekundach, a nawet ich ułamkach - w przypadku agencji wywiadowczej, którą zdaniem autorów raportu stać na zainwestowanie 300 milionów dolarów w sprzęt do łamania szyfrów, czas ten wynosi 0,0002 sekundy! Zastosowanie szyfru DES, z 56-bitowym kluczem, niewiele poprawia bezpieczeństwo: złamanie szyfru jest teraz wprawdzie raczej poza zasięgiem indywidualnego hackera (38 lat), a nawet małej firmy (ok. 1,5 roku), ale już średniej wielkości firmie (sprzęt za 300 tys. dolarów) zajmie to 3 godziny, a agencji wywiadowczej - zaledwie 12 sekund.
O złamaniu tą metodą szyfru 128-bitowego, jakim jest IDEA, nie ma jednak co marzyć - trwałoby to 272 razy dłużej niż dla szyfru 56-bitowego, a więc nawet agencji wywiadowczej zajęłoby... 100 bilionów lat! (obecny wiek Wszechświata szacuje się na "zaledwie" ok. 10 miliardów lat). Ciekawe natomiast może być obliczenie na podstawie tych danych przewidywanych czasów łamania (faktoryzacji) klucza RSA. Wg danych z [5], faktoryzacja 512-bitowego klucza RSA wymaga mniej więcej tyle czasu, co łamanie 64-bitowego klucza "zwykłego" szyfru metodą brute force. Można zatem obliczyć, że średnia firma jest w stanie złamać taki klucz w ciągu miesiąca, duża firma - w ciągu jednego dnia, a agencja wywiadowcza - w 59 minut. W przypadku klucza 768-bitowego (równoważnego 80-bitowemu kluczowi "zwykłego" szyfru) jakieś szanse ma jedynie agencja wywiadowcza: 6,5 roku. Klucz 1024-bitowy - przy założeniu, iż nie nastąpią jakieś przełomowe, jakościowe zmiany w teorii liczb albo w technologii komputerowej - powinien zapewniać nam absolutne bezpieczeństwo: jego faktoryzacja wymaga od agencji wywiadowczej poświęcenia 6,5 miliona lat.
Cały ten przydługi wywód wskazuje na to, że póki co możemy spokojnie używać PGP do ochrony naszej poczty. Chyba, że jakieś władze zechcą "zrobić z tym porządek" i zakażą stosowania szyfrowania, bądź też zezwolą na nie jedynie pod warunkiem udostępnienia służbom specjalnym wszystkich kluczy prywatnych - jak to już wielokrotnie w wielu krajach próbowano uczynić, a w niektórych nawet doprowadzono do skutku. Wówczas tylko przestępcy będą mogli swobodnie korzystać z PGP...
1. Szymon Sokół, Opis systemu PGP dla laika,
http://galaxy.uci.agh.edu.pl/~szymon/pgp_opis.html
2. Adam Back, PGP Timeline, http://www.cypherspace.org/~adam/timeline/
3. Stale Schumacher, International PGP FAQ,
http://www.pgpi.org/doc/faq/pgpi/
4. RSA Labs FAQ on Cryptography, http://www.rsasecurity.com/rsalabs/faq/
5. PGP Attack FAQ, http://axion.physics.ubc.ca/pgp-attack.html
6. Matt Blaze et al., Minimal Key Lengths for Symmetric Ciphers...,
http://theory.lcs.mit.edu/~rivest/bsa-final-report.ascii
Powrót do wykazu artykułów o Internecie | Statystyka |