GNU Privacy Handbook
Copyright © 1999 The Free Software Foundation
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".
Pytania, sugestie i informacje o błędach prosimy przesyłać do opiekuna niniejszego podręcznika -- Mike'a Ashley'a (<jashley@acm.org>). W korespondencji prosimy zaznaczyć, o którą wersję podręcznika chodzi. Niniejszy tekst oznaczony jest numerem: $Name: v1_1 $.
Matthew Copeland, Joergen Grahn oraz David A. Wheeler wnieśli duży wkład w powstanie niniejszego podręcznika. Autorem polskiego tłumaczenia jest Jacek Śliwerski.
- Spis rysunków
- 3-1. Przykładowa sieć zaufania
Rozdział 1. Rozpoczynamy
Ten rozdział zawiera informacje o podstawowej funkcjonalności programu GnuPG. Omówiono tu generację, rozpowszechnianie i weryfikację kluczy, szyfrowanie i odszyfrowywanie tekstów oraz cyfrowe podpisywanie dokumentów. Niniejszy rozdział nie zawiera szczegółów dotyczących systemów kryptograficznych z kluczem publicznym ani zasad działania podpisów elektronicznych. Informacje te można znaleźć w rozdziale 2. Nie ma tu również mowy o tym, jak w sposób świadomy i bezpieczny używać GnuPG, ponieważ informacje te czytelnik może znaleźć w rozdziałach 3 oraz 4.
Bezpieczeństwo stosowania GnuPG oparte jest na algorytmach z kluczem publicznym. W systemie takim każdy użytkownik posiada parę kluczy: prywatny i publiczny. Klucz prywatny musi pozostać utajniony i nie może zostać w żadnym przypadku ujawniony innym osobom. Klucz publiczny można przekazać każdemu, z kim chce się porozumiewać. W GnuPG zastosowano bardziej wyszukany schemat, w którym użytkownik posiada główną parę kluczy oraz zbiór podrzędnych par (który może być pusty). Cały zbiór jest ściśle związany, aby ułatwić zarządzanie kluczami i może być traktowany jak pojedyncza para kluczy. Dalej w tym dokumencie będę się posługiwać terminem klucz do określania pary kluczy (ang. keypair). Jeśli będzie chodziło o pojedynczy element pary (klucz prywatny bądź publiczny) to będę to wyraźnie podkreślać. Takiej konwencji użyto również przy tłumaczeniu na język polski komunikatów programu GnuPG.
Generowanie nowego klucza
Przełącznik --gen-key służy do generowania nowego klucza głównego.
alicja% gpg --gen-key gpg (GnuPG) 1.0.6; Copyright (C) 2001 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Proszę wybrać rodzaj klucza: (1) Para kluczy dla algorytmów DSA i ElGamala (domyślne) (2) DSA (tylko do podpisywania) (4) Klucz dla algorytmu ElGamala (do szyfrowania i podpisywania) Twój wybór? |
Teraz należy wybrać rozmiar klucza. Rozmiar klucza DSA musi zawierać się między 512 a 1024 bitami, a klucz ElGamal może być dowolnego rozmiaru. GnuPG wymaga, aby klucz był conajmniej 768 bitowy. Dlatego jeśli użytkownik wybierze opcję 1, a następnie poda rozmiar klucza przekraczający 1024 bitów, to wygenerowany zostanie klucz ElGamal podanego rozmiaru i 1024-bitowy klucz DSA.
Nastąpi generacja nowej pary kluczy dla algorytmu(ów) ELG-E.
minimalny rozmiar klucza wynosi 768 bitów
domyślny rozmiar klucza wynosi 1024 bity
największy sugerowany rozmiar klucza wynosi 2048 bitów
Jakiej długości klucz wygenerować? (1024) |
Pozostaje już tylko wybór okresu ważności. W przypadku wyboru opcji 1, limit będzie dotyczyć obydwu kluczy (ElGamal i DSA).
Okres ważności klucza.
0 = klucz nie ma określonego okresu ważności
<n> = termin ważności klucza upływa za n dni
<n>w = termin ważności klucza upływa za n tygodni
<n>m = termin ważności klucza upływa za n miesięcy
<n>y = termin ważności klucza upływa za n lat
Okres ważności klucza ? (0) |
Jako parametr klucza należy podać identyfikator użytkownika. Służy on do jednoznacznego związania klucza z jego właścicielem.
Musisz określić identyfikator użytkownika aby można było rozpoznać twój
klucz; program złoży go z twojego imienia i nazwiska, komentarza i adresu
poczty elektronicznej. Będzie on miał taką postać:
"Tadeusz Żeleński (Boy) <tzb@domena.pl>"
Imię i nazwisko: |
GnuPG wymaga podania hasła, które będzie chroniło klucze prywatne użytkownika. Osoba tłumacząca komunikaty GnuPG na język polski zbyt dosłownie potraktowała angielski zwrot "pass phrase", dlatego program prosi o "wyrażenie przejściowe". Przejściowość tego wyrażenia nie oznacza jego tymczasowości. Chodziło o to, że znajomość tego wyrażenia jest wymagana do przejścia dalej.
Musisz podać wyrażenie przejściowe (hasło) aby ochronić swój klucz tajny. Wyrażenie przejściowe: |
Generowanie certyfikatu unieważniającego
Zaraz po wygenerowaniu klucza należy stworzyć certyfikat unieważniający dla głównego klucza publicznego. Używa się do tego przełącznika --gen-revoke. W przypadku zapomnienia hasła, zagubienia lub złamania klucza publicznego certyfikat ten może zostać rozpowszechniony w celu poinformowania innych, że ten klucz nie powinien być już nigdy więcej używany. Unieważniony klucz publiczny nadaje się nadal do potwierdzania podpisów wykonanych w przeszłości, ale nie będzie nim można podpisać dokumentów w imieniu jego właściciela. Nadal będzie można odszyfrowywać stare wiadomości przy pomocy odpowiadającego mu klucza prywatnego.
alicja% gpg --output revoke.asc --gen-revoke klucz [...] |
Rozpowszechnianie kluczy
Aby móc porozumiewać się z innymi trzeba uprzednio wymienić swoje klucze publiczne. Aby wyświetlić listę dostępnych kluczy publicznych należy użyć przełącznika --list-keys.
alicja% gpg --list-keys /users/alicja/.gnupg/pubring.gpg --------------------------------------- pub 1024D/BB7576AC 1999-06-04 Alicja (Sędzia) <alicja@cyb.org> sub 1024g/78E9A8FA 1999-06-04 |
Eksportowanie klucza publicznego
Aby przesłać znajomemu swój klucz publiczny trzeba go najpierw wyeksportować. Służy do tego przełącznik --export. Jako parametr bierze on ciąg znaków jednoznacznie identyfikujący klucz. Tak jak w przypadku parametru --gen-revoke może to być zarówno cały identyfikator klucza jak i jego dowolna część, jeśli jest właściwa dla dokładnie jednego klucza.
alicja% gpg --output alicja.gpg --export alicja@cyb.org |
Powyższe polecenie spowoduje eksport klucza do pliku binarnego, co może być niepożądane jeśli ma on być wysłany pocztą lub umieszczony na stronie www. Do tego celu GnuPG udostępnia przełącznik --armor[2], który powoduje utworzenie pliku w formacie ASCII, podobnym do tego co generuje program uuencode. Właściwie każdy wynik działania GnuPG (jak np. klucze, zaszyfrowane teksty, czy podpisy) może mieć postać czystego tekstu ASCII. Wystarczy użyć opcji --armor.
alicja% gpg --armor --export alicja@cyb.org -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Dalsze informacje znajdują się na http://www.gnupg.org/ [...] -----END PGP PUBLIC KEY BLOCK----- |
Importowanie klucza publicznego
Zbiór kluczy publicznych można rozszerzyć o nowy klucz przy pomocy przełącznika --import.
alicja% gpg --import blake.gpg gpg: klucz 9E98BC16: klucz publiczny wczytany do zbioru gpg: Ogółem przetworzonych kluczy: 1 gpg: dołączono do zbioru: 1 alicja% gpg --list-keys /users/alicja/.gnupg/pubring.gpg --------------------------------------- pub 1024D/BB7576AC 1999-06-04 Alicja (Sędzia) <alicja@cyb.org> sub 1024g/78E9A8FA 1999-06-04 pub 1024D/9E98BC16 1999-06-04 Blake (Egzekutor) <blake@cyb.org> sub 1024g/5C8CBD41 1999-06-04 |
Po zaimportowaniu klucz powinien zostać zweryfikowany. GnuPG używa bardzo wygodnego modelu wiarygodności, który nie wymaga aby użytkownik własnoręcznie weryfikował każdy importowany klucz, choć niektóre klucze mogą wymagać takiego potwierdzenia. Aby zatwierdzić klucz należy obliczyć, czy zawarty w nim odcisk jest prawidłowy i (w przypadku powodzenia) oznaczyć go jako zatwierdzony. Odcisk swojego klucza można obejrzeć przy pomocy przełącznika --fingerprint. Zatwierdzenie klucza wymaga ingerencji użytkownika.
alicja% gpg --edit-key blake@cyb.org
gpg (GnuPG) 1.0.6; Copyright (C) 2001 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
pub 1024D/9E98BC16 utworzony: 1999-06-04 wygasa never zaufanie: -/q
sub 1024g/5C8CBD41 utworzony: 1999-06-04 wygasa never
(1) Blake (Egzekutor) <blake@cyb.org>
Polecenie> fpr
pub 1024D/9E98BC16 1999-06-04 Blake (Egzekutor) <blake@cyb.org>
Odcisk: 268F 448F CCD7 AF34 183E 52D8 9BDE 1A08 9E98 BC16 |
Po sprawdzeniu odcisku można podpisać klucz własnym kluczem. Weryfikacja klucza jest słabym punktem systemów kryptograficznych z kluczem publicznym. Z tego powodu użytkownicy powinni być szczególnie ostrożni i zawsze sprawdzać odcisk klucza z jego właścicielem przed podpisaniem.
Polecenie> sign
pub 1024D/9E98BC16 utworzony: 1999-06-04 wygasa never zaufanie: -/q
Odcisk: 268F 448F CCD7 AF34 183E 52D8 9BDE 1A08 9E98 BC16
Blake (Egzekutor) <blake@cyb.org>
Czy jesteś naprawdę pewien że chcesz podpisać ten klucz
swoim kluczem: "Alicja (Sędzia) <alicja@cyb.org>"
Na pewno podpisać? |
Po podpisaniu można obejrzeć listę podpisów pod kluczem, w tym własny podpis. Każdy identyfikator użytkownika związany z kluczem będzie miał conajmniej jeden podpis właściciela oraz podpisy użytkowników, którzy weryfikowali ten klucz.
Polecenie> check uid Blake (Egzekutor) <blake@cyb.org> sig! 9E98BC16 1999-06-04 [podpis klucza nim samym] sig! BB7576AC 1999-06-04 Alicja (Sędzia) <alicja@cyb.org> |
Szyfrowanie i odszyfrowywanie dokumentów
Klucz prywatny i publiczny mają różne zastosowania przy szyfrowaniu i odszyfrowywaniu dokumentów. O kluczu publicznym można myśleć jak o otwartym sejfie. Kiedy korespondent szyfruje dokument kluczem publicznym, wkłada go do sejfu, zamyka i kilkukrotnie przekręca zapadkę. Odpowiedni klucz prywatny jest kombinacją przy pomocy której można otworzyć zamknięty sejf i odzyskać dokument. Innymi słowy, tylko osoba posiadająca klucz prywatny może odczytać dokument zaszyfrowany odpowiednim kluczem publicznym.
Procedura szyfrowania i odszyfrowywania dokumentu jest zgodna z następującym schematem. Aby zaszyfrować wiadomość do Alicji, należy go zakodować kluczem publicznym Alicji, a ona odkoduje go swoim kluczem prywatnym. Jeśli Alicja zechce wysłać zakodowaną wiadomość użytkownikowi, zaszyfruje ją jego kluczem publicznym, by mógł odszyfrować tekst przy pomocy swojego klucza prywatnego.
Przełącznik --encrypt służy do szyfrowania. Trzeba uprzednio posiadać klucz publiczny odbiorcy. Program zakłada, że zostanie mu podany plik do zaszyfrowania. Jeśli nie zostanie podana nazwa żadnego pliku, to program będzie czytał ze standardowego wejścia. Wynik szyfrowania zostanie wysłany na standardowe wyjście, chyba że dodany zostanie przełącznik --output. Dokument jest kompresowany po zaszyfrowaniu, co powinno dodatkowo zwiększyć bezpieczeństwo.
alicja% gpg --output doc.gpg --encrypt --recipient blake@cyb.org doc |
Przełącznik --decrypt służy do odszyfrowywania wiadomości. Aby to zrobić trzeba posiadać klucz prywatny, dla którego zaszyfrowano tę wiadomość. Podobnie jak przy szyfrowaniu, wejściem dla programu jest zakodowany dokument, a wyjściem jego jawna wersja.
blake% gpg --output doc --decrypt doc.gpg Musisz podać wyrażenie przejściowe (hasło) aby uaktywnić klucz tajny dla użytkownika: "Blake (Egzekutor) <blake@cyb.org>" długość 1024 bitów, typ ELG-E, klucz 5C8CBD41, stworzony 1999-06-04 Wyrażenie przejściowe: |
Dokumenty mogą być również szyfrowane bez używania kryptografii z kluczem publicznym. Zamiast tego używa się szyfru symetrycznego. Kluczem zastosowanym do zakodowania dokumentu jest hasło podane przez użytkownika w trakcie szyfrowania. Aby zapewnić bezpieczeństwo hasło to powinno być różne od chroniącego klucz prywatny. Szyfrowanie symetryczne jest szczególnie przydatne do zabezpieczania dokumentów, do których nikt więcej nie musi mieć dostępu. Realizowane jest przy pomocy przełącznika --symmetric.
alicja% gpg --output doc.gpg --symmetric doc Wyrażenie przejściowe: |
Podpisywanie i sprawdzanie podpisów
Podpis cyfrowy poświadcza istnienie dokumentu w określonym czasie. Jeśli podpisany dokument zostanie w jakikolwiek sposób zmodyfikowany, sprawdzenie podpisu nie powiedzie się. Podpis cyfrowy ma zasadniczo takie samo zastosowanie jak podpis ręczny, z tą różnicą, że dokumentu podpisanego elektronicznie nie można zmienić bez ponownego podpisania. Dystrybucja źródłowa programu GnuPG jest podpisana, aby każdy użytkownik mógł sprawdzić, że kod źródłowy nie został zmodyfikowany od czasu umieszczenia go w archiwum.
Podpisy sporządza się i sprawdza odwrotnie niż w przypadku szyfrowania i odszyfrowywania. Dokument podpisuje się kluczem prywatnym, a sprawdza podpis przy pomocy odpowiedniego klucza publicznego. Alicja mogłaby na przykład podpisać artykuł do Miesięcznika Chemii Nieorganicznej swoim kluczem prywatnym. Redaktor przyjmujący jej zgłoszenie mógłby użyć publicznego klucza Alicji, aby sprawdzić, czy praca ta została rzeczywiście napisana przez Alicję i czy jej treść nie została zmieniona od czasu wysłania. W konsekwencji trudno jest wyprzeć się podpisanego dokumentu, ponieważ oznaczałoby to, że klucz prywatny jest znany osobom do tego nieupoważnionym.
Przełącznik --sign służy do podpisywania. Wejściem dla programu jest podpisywany dokument, a wyjściem ten sam dokument, podpisany.
alicja% gpg --output doc.sig --sign doc Musisz podać wyrażenie przejściowe (hasło) aby uaktywnić klucz tajny dla użytkownika: "Alicja (Sędzia) <alicja@cyb.org>" długość 1024 bitów, typ DSA, klucz BB7576AC, stworzony 1999-06-04 Wyrażenie przejściowe: |
Oprócz sprawdzenia prawdziwości podpisu można również odzyskać oryginalny dokument. Do samego sprawdzenia służy przełącznik --verify. Aby dodatkowo odzyskać dokument należy użyć przełącznika --decrypt. Podpisany dokument jest wejściem dla programu, a odtworzony oryginał wyjściem.
blake% gpg --output doc --decrypt doc.sig gpg: Podpis złożony pią 4 sty 1999 12:02:38 CET za pomocą DSA, z użyciem klucza o identyfikatorze BB7576AC gpg: Poprawny podpis złożony przez "Alicja (Sędzia) <alicja@cyb.org>" |
Bezingerencyjne podpisywanie dokumentów
Powszechnym zastosowaniem podpisu cyfrowego jest poczta elektroniczna. To zastosowanie wyklucza kompresję podpisywanej wiadomości. Przełącznik --clearsign spowoduje otoczenie niezmienionego dokumentu nagłówkiem oraz podpisem. Wynik będzie składał się wyłącznie ze znaków ASCII.
alicja% gpg --clearsign doc Musisz podać wyrażenie przejściowe (hasło) aby uaktywnić klucz tajny dla użytkownika "Alicja (Sędzia) <alicja@cyb.org>" długość 1024 bitów, typ DSA, klucz BB7576AC, stworzony 1999-06-04 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [...] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Dalsze informacje znajdują się na http://www.gnupg.org iEYEARECAAYFAjdYCQoACgkQJ9S6ULt1dqz6IwCfQ7wP6i/i8HhbcOSKF4ELyQB1 oCoAoOuqpRqEzr4kOkQqHRLE/b8/Rw2k =y6kj -----END PGP SIGNATURE----- |
Samodzielne podpisy
Podpisany dokument ma kilka wad. Każdy użytkownik, który chce go odczytać zmuszony jest nawet w przypadku bezingerencyjnego podpisu oddzielić treść od podpisu. Dlatego jest jeszcze trzecia metoda podpisywania dokumentów, która tworzy samodzielny podpis i umieszcza go w osobnym pliku. Służy do tego przełącznik --detach-sig.
alicja% gpg --output doc.sig --detach-sig doc Musisz podać wyrażenie przejściowe (hasło) aby uaktywnić klucz tajny dla użytkownika "Alicja (Sędzia) <alicja@cyb.org>" długość 1024 bitów, typ DSA, klucz BB7576AC, stworzony 1999-06-04 Wyrażenie przejściowe: |
Do sprawdzenia podpisu potrzebne są oba pliki. Przełącznik --verify służy również do potwierdzania samodzielnego podpisu.
blake% gpg --verify doc.sig doc gpg: Podpis złożony pią 4 sty 1999 12:38:46 CET za pomocą DSA, z użyciem klucza o identyfikatorze BB7576AC gpg: Poprawny podpis złożony przez "Alicja (Sędzia) <alicja@cyb.org>" |
Rozdział 2. Techniki
GnuPG korzysta z kilku technik kryptograficznych w tym: szyfrowania symetrycznego, algorytmów z kluczem publicznym (asymetrycznych) i jednokierunkowych funkcji hashujących[3]. Nie trzeba rozumieć wszystkich szczegółów ukrytych za tymi terminami, aby korzystać z GnuPG. Bezpieczeństwo stosowania tych rozwiązań jest jednak w dużym stopniu związane ze zrozumieniem ich podstaw.
W tym rozdziale wprowadzone zostaną podstawowe techniki kryptograficzne stosowane w GnuPG. Więcej szczegółów można znaleźć w książkach dotyczących kryptografii. Godną polecenia pozycją jest podręcznik Bruce'a Shneiera pod tytułem ,,Applied Cryptography''.
Szyfrowanie symetryczne
System kryptograficzny nazywamy symetrycznym, jeśli ten sam klucz służy do szyfrowania i deszyfrowania. Strony komunikujące się przy pomocy tego schematu muszą uprzednio uzgodnić klucz, którym będą szyfrować dane. Nadawca może wtedy zaszyfrować wiadomość ustalonym kluczem, a odbiorca odtworzy przy pomocy tego klucza oryginalną treść. Przykładem systemu symetrycznego może być niemiecka Enigma, do której klucze (codziennie inny) rozprowadzane były w postaci książek kodowych. Operator radia sprawdzał w książce kod na bieżący dzień i szyfrował nim całą transmisję. 3DES, Blowfish i IDEA to współczesne szyfry symetryczne.
W dobrym systemie kryptograficznym bezpieczeństwo zależy wyłącznie od tajności klucza. Znajomość algorytmu nie powinna w żaden sposób pomagać osobom trzecim. Szyfry stosowane w GnuPG mają tę własność, że wiedza o stosowanym algorytmie jest bezużyteczna bez znajomości klucza zastosowanego do szyfrowania.
Ponieważ całe bezpieczeństwo stosowania szyfru leży w tajności klucza, musi być bardzo trudno zgadnąć, jaki jest ten klucz. Innymi słowy zbiór wszystkich możliwych kluczy powinien być jak największy. Richard Feynman słynął w Los Alamos ze swojej umiejętności otwierania sejfów. Aby zwiększyć wiarę innych w swoje nieludzkie możliwości nosił ze sobą zestaw narzędzi, w tym stary stetoskop. W rzeczywistości stosował różne sztuczki do zmniejszenia ilości kombinacji do niewielkiej liczby, po czym sprawdzał je wszystkie. Jednym słowem zmniejszał przestrzeń kluczy.
Podczas 2 Wojny Światowej Anglicy posługiwali się specjalnymi maszynami, które łamały klucze. Niemiecka Enigma miała bardzo dużą przestrzeń kluczy, ale specjalne urządzenie Bombes mechanicznie wypróbowywało wszystkie kombinacje aż do napotkania właściwej (tzn. klucza dziennego). Oznaczało to, że raz klucz był odnajdywany w przeciągu kilku godzin, a innym razem nie został znaleziony wcale. Maszyny Bombes nie nadawały się do przeprowadzania obliczeń w pełnej ogólności, ale można je uznać za prekursorów współczesnych komputerów.
Dziś komputery potrafią liczyć bardzo szybko i dlatego wielkość klucza jest tak istotna we współczesnych kryptosystemach. W algorytmie DES używa się kluczy 56 bitowych, co oznacza że istnieje 256 różnych kluczy. 256 wynosi 72,057,594,037,927,936. To całkiem sporo, ale przeszukanie całej tej przestrzeni zajęłoby zwykłemu komputerowi zaledwie kilka dni. Specjalnie przystosowana maszyna dokonałaby tego w ciągu paru godzin. Z drugiej jednak strony istnieją szyfry takie jak np. 3DES, Blowfish, czy IDEA, które operują kluczami 128 bitowymi. W takim przypadku istnieje 2128 różnych kluczy. To jest znacznie więcej i nawet gdyby wszystkie komputery na naszej planecie współpracowały przy przeszukaniu tej przestrzeni, to mogłoby to im zająć więcej czasu niż upłynęło od powstania wszechświata.
Szyfrowanie z kluczem publicznym (asymetryczne)
Największą wadą szyfrowania symetrycznego nie jest jego bezpieczeństwo, ale kwestie związane z wymiana kluczy. Gdy nadawca i odbiorca uzgodnią klucze, mogą się swobodnie porozumiewać. Ale w jaki sposób mogą przekazać sobie sam klucz? Potencjalnemu adwersarzowi łatwiej byłoby zatem w jakiś sposób przechwycić sam klucz niż wypróbowywać wszystkie możliwe. Kolejnym problemem jest ilość kluczy jakie musi mieć każdy użytkownik. W każdej grupie n-osobowej potrzebnych jest n(n-1)/2 kluczy, aby każda para osób mogła swobodnie rozmawiać. Liczba ta może być znośna dla niewielkich grup ludzi, ale przestaje być dla większych.
Szyfrowanie asymetryczne zostało wymyślone w celu całkowitego uniknięcia problemu wymiany kluczy. W kryptosystemie z kluczem publicznym stosuje się parę kluczy do wysyłania wiadomości. Oba należą do odbiorcy wiadomości. Klucz publiczny może być przekazany każdemu podczas gdy klucz prywatny powinien zostać utrzymany w ścisłej tajemnicy. Nadawca szyfruje wiadomość przy pomocy klucza publicznego. Kryptogram można odszyfrować jedynie znając klucz prywatny.
Taki protokół rozwiązuje nieodłączny problem szyfrów symetrycznych. Zbędne staje się uzgadnianie kluczy między nadawcą i odbiorcą. Jedynym warunkiem jest to, że nadawca będzie posiadał klucz publiczny odbiorcy zanim rozpoczną tajną konwersację. Ponadto ten sam klucz publiczny może być używany przez wszystkich potencjalnych nadawców. A zatem tylko n par kluczy jest potrzebnych, aby n osób mogło się bezpiecznie porozumiewać.
Kryptosystemy z kluczem publicznym oparte są na funkcjach jednokierunkowych (aby być zgodnym z oryginalnym 'one-way trapdoor function' trzeba wspomnieć, że chodzi o takie funkcje jednokierunkowe, których odwrotności są łatwo obliczalne przy danej "wskazówce"). Funkcja jednokierunkowa charakteryzuje się tym, że jest łatwo obliczalna, ale jej odwrotność nie. Na przykład łatwo jest otrzymać liczbę złożoną z mnożenia dwóch liczb pierwszych, ale trudno jest rozłożyć ją z powrotem na czynniki, jeśli ich nie znamy. Wskazówka w funkcjach jednokierunkowych polega na tym, że dysponujemy pewną porcją informacji, która pozwala nam odwrotność danej funkcji obliczyć w sposób efektywny. Załóżmy na przykład, że mamy dany iloczyn dwóch liczb pierwszych. Jeśli będziemy znać jeden z czynników, to w prosty sposób obliczymy drugi. W systemie opartym na faktoryzacji kluczem publicznym jest wynik mnożenia dwóch liczb pierwszych. Do szyfrowania wiadomości używa się właśnie tej liczby. Algorytm odszyfrowujący wymaga znajomości czynników, więc jest bardzo prosty, kiedy zna się jeden z nich, ale wyjątkowo trudny bez tej wiedzy.
Podobnie jak w przypadku szyfrów symetrycznych jakość systemu z kluczem publicznym zależy wyłącznie od klucza. Jednak nie można w żaden sposób porównać siły algorytmu symetrycznego i asymetrycznego porównując wielkości ich kluczy. W ataku typu brute-force na szyfr symetryczny adwersarz musi sprawdzić do 280 kluczy aby znaleźć właściwy. W tego samego typu ataku na szyfr asymetryczny z 512 bitowym kluczem adwersarz musi rozłożyć na czynniki pierwsze liczbę zapisaną na 512 bitach (do 155 cyfr dziesiętnych). Koszt jest znacząco różny i zależy od zastosowanego szyfru. Podczas, gdy 128 bitowe klucze wystarczają w szyfrowaniu symetrycznym, to zaleca się stosowanie 1024 bitowych kluczy publicznych.
Szyfry hybrydowe
Szyfrowanie z kluczem publicznym nie jest lekarstwem na wszystkie bolączki. Wiele szyfrów symetrycznych jest silniejszych, a procedury szyfrujące i deszyfrujące w algorytmach asymetrycznych są mniej efektywne. Systemy z kluczem publicznym są jednak bardzo wygodnym narzędziem do rozpowszechniania kluczy symetrycznych i tak właśnie są używane w systemach hybrydowych.
W systemie hybrydowym klucz do szyfrowania symetrycznego jest przekazywany jako wiadomość zakodowana kluczem publicznym. Właściwa wiadomość może być później zaszyfrowana przy pomocy klucza symetrycznego. To rozwiązanie pozwala na ustalanie nowego klucza symetrycznego do każdej transmisji. Klucz taki nazywa się czasami kluczem sesyjnym.
Zarówno PGP jak i GnuPG stosują szyfry hybrydowe. Klucz sesyjny szyfrowany jest kluczem publicznym, a wiadomość zakodowanym kluczem. Złączone razem tworzą kryptogram. Odbiorca używa swojego klucza prywatnego do odkodowania klucza sesyjnego, przy pomocy którego może odczytać wiadomość.
Szyfr hybrydowy jest tak bezpieczny jak jego najsłabsze ogniwo. W PGP i GnuPG szyfrowanie asymetryczne jest prawdopodobnie tą słabszą częścią. Tak się szczęśliwie składa, że jeśli komuś uda się odszyfrować klucz sesyjny, to będzie mógł za jego pomocą odczytać tylko tę jedną wiadomość. W celu odszyfrowania następnej wiadomości będzie musiał powtórzyć całą procedurę odkodowania nowego klucza sesyjnego.
Podpisy cyfrowe
Funkcja hashująca jest funkcją zawężającą, która przyporządkowuje swoim argumentom elementy skończonego zbioru. Zbiorem wartości jest na ogół pewien podzbiór zbioru liczb naturalnych. Wynik funkcji hashującej nazywamy hashem. Prostym przykładem funkcji hashującej jest f(x) = 0 dla wszystkich x ze zbioru liczb całkowitych. Znacznie ciekawszą funkcją hashującą jest f(x) = x mod 37, która liczbie x przyporządkowuje jej resztę z dzielenia przez 37.
Podpisem cyfrowym dla dokumentu jest wynik funkcji hashującej obliczony dla tego dokumentu (czyli hash tego dokumentu). Szczególnie pożądane są funkcje hashujące posiadające następujące dwie własności. Po pierwsze, trudno powinno być znaleźć dwa różne dokumenty, dla których wynik funkcji hashującej będzie ten sam. Po drugie, trudne powinno być odzyskanie dokumentu, który dał określony wynik.
Niektóre szyfry asymetryczne[4] nadają się również do podpisywania dokumentów. Podpisujący szyfruje dokument swoim kluczem prywatnym. Każdy, kto zechce sprawdzić prawdziwość podpisu może użyć klucza publicznego podpisującego, aby odszyfrować dokument. Ten algorytm posiada obydwie pożądane właściwości dobrej funkcji hashującej, ale w praktyce jest zbyt wolny.
Alternatywnie można używać funkcji hashujących specjalnie do tego zaprojektowanych. Przykładami takich algorytmów są SHA i MD5. Wartość funkcji obliczonej dla zadanego dokumentu jest jego podpisem. Osoba chcąca zweryfikować poprawność podpisu oblicza tę samą funkcję dla dokumentu i porównuje z wartością uzyskaną dla oryginału. Jeśli obie są takie same to z prawie stuprocentową pewnością można powiedzieć, że oba te dokumenty są identyczne.
Problemem tkwi w tym, jak używać funkcji hashujących, aby uniemożliwić osobom trzecim wpływ na weryfikację podpisu. Jeśli dokument i jego podpis wyślemy niezaszyfrowane, to ktoś mógłby zmienić dokument i wygenerować do niego podpis bez wiedzy odbiorcy. Jeśli zaszyfrujemy tylko dokument, to adwersarz może zmienić podpis powodując, że nie powiedzie się weryfikacja podpisu. Trzecią możliwością jest użycie szyfrowania hybrydowego do zakodowania dokumentu i podpisu. Podpisujący używa w tym celu swojego prywatnego klucza, a każdy może potem przy pomocy klucza publicznego zweryfikować poprawność dokumentu i podpisu. Pomysł wydaje się niezły, ale jest kompletnie chybiony. Gdyby ten algorytm zabezpieczył dokument, ochroniłby go również przed wszelkimi innymi zmianami, więc mógłby służyć zamiast podpisu.
Sprawę załatwia zaszyfrowanie kluczem prywatnym samego podpisu. Obliczony dla dokumentu hash jest szyfrowany i każdy może przy pomocy klucza publicznego sprawdzić podpis. Podpisany dokument może być zaszyfrowany dowolnym innym algorytmem, lub nie być szyfrowany w ogóle jeśli jest otwarty. Sprawdzenie poprawności podpisu dla zmienionego dokumentu zawiedzie, ale to jest właśnie to, czego oczekujemy od podpisu elektronicznego. DSA (Digital Signature Algorithm) jest podpisem z kluczem publicznym, który działa zgodnie z opisanym powyżej schematem. GnuPG używa DSA jako podstawowego algorytmu do podpisywania dokumentów.
Rozdział 3. Zarządzanie kluczami
Najsłabszym ogniwem ktryptosystemów z kluczem publicznym są kwestie związane z ingerencją w klucze. Podsłuchujący może spróbować zmienić wartość klucza użytkownika lub rozpowszechnić fałszywy wśród jego korespondentów. Załóżmy, że Chloe chce przechwytywać korespondencję wysyłaną przez Alicję do Blake'a. Ustanowi w tym celu atak zwany man in the middle. Polega on na tym, że Chloe tworzy zupełnie nowy klucz. Przekazuje Alicji publiczną część sfałszowanego klucza. Następnie przechwytuje każdą wiadomość od Alicji do Blake'a. Treść wiadomości odszyfrowuje prywatną częścią wygenerowanego klucza, szyfruje prawdziwym kluczem publicznym Blake'a i przekazuje mu wynik. Od tej pory Chloe może czytać wszystkie wiadomości od Alicji do Blake'a.
Odpowiedzialne zarządzanie kluczami jest warunkiem na zapewnienie spójności kluczy swoich i innych użytkowników. Centralnym pojęciem związanym z zarządzaniem kluczami jest podpisywanie klucza. Podpisywanie klucza służy dwóm celom: ułatwia wykrycie ingerencji w kolekcję kluczy oraz pozwala wiązać żywe osoby z identyfikatorami ich kluczy. Podpis klucza jest również przydatny w tak zwanej sieci zaufania do rozszerzania zasięgu poprawności na klucze, które nie zostały podpisane przez użytkownika, ale przez osobę zaufaną. Odpowiedzialni użytkownicy unikną zagrożeń związanych z ingerencją w ich kolekcję kluczy.
Zarządzanie własnym kluczem
Klucz składa się z dwóch części: publicznej i prywatnej. Klucz publiczny składa się z publicznej części podstawowego klucza podpisującego, publicznych części kluczy podrzędnych (podpisujących i szyfrujących) i zbioru identyfikatorów użytkownika będących pomostem między kluczem, a żywą osobą. Każda część opatrzona jest pewnymi danymi. Klucze zawierają swój identyfikator, czas utworzenia, czas wygaśnięcia itd. Identyfikatory użytkownika opisane są nazwiskiem właściciela, opcjonalnym komentarzem oraz adresem poczty elektronicznej. Struktura klucza prywatnego jest podobna, z tym że zawiera jedynie prywatną część klucza i nie posiada żadnej informacji o użytkowniku.
Przełącznik --edit-key służy do oglądania klucza.
chloe% gpg --edit-key chloe@cyb.org gpg (GnuPG) 1.0.6; Copyright (C) 2001 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Dostępny jest klucz tajny. pub 1024D/26B6AAE1 utworzony: 1999-06-15 wygasa never zaufanie: -/u sub 2048g/0CF8CB7A utworzony: 1999-06-15 wygasa never sub 1792G/08224617 utworzony: 1999-06-15 wygasa 2002-06-14 sub 960D/B1F423E7 utworzony: 1999-06-15 wygasa 2002-06-14 (1) Chloe (Jester) <chloe@cyb.org> (2) Chloe (Plebian) <chloe@tel.net> Polecenie> |
Pozostałe dane klucza można wydobyć przy pomocy odpowiednich poleceń. Instrukcja toggle służy do przełączania się między częścią publiczną i prywatną o ile ta jest dostępna.
Polecenie> toggle sec 1024D/26B6AAE1 utworzony: 1999-06-15 wygasa never sbb 2048g/0CF8CB7A utworzony: 1999-06-15 wygasa never sbb 1792G/08224617 utworzony: 1999-06-15 wygasa 2002-06-14 sbb 960D/B1F423E7 utworzony: 1999-06-15 wygasa 2002-06-14 (1) Chloe (Jester) <chloe@cyb.org> (2) Chloe (Plebian) <chloe@tel.net> |
Spójność kluczy
Wraz z kluczem publicznym rozpowszechnia się publiczne części wszystkich kluczy podrzędnych oraz identyfikatory użytkownika. Rozpowszechnianie tych informacji osobno jest ryzykowne ponieważ istnieje możliwość ingerencji. Klucz publiczny może być modyfikowany poprzez dodawanie i zmienianie kluczy, a także poprzez dodawanie i zmienianie identyfikatorów użytkownika. Gdyby ktoś mógł zmienić identyfikator użytkownika, zmiana adresu email spowodowałaby przekierowanie do niego poczty. Gdyby zmienił jeden z kluczy szyfrujących, mógłby również odszyfrowywać te wiadomości.
Wyjściem z tej sytuacji jest użycie podpisu cyfrowego. Klucz publiczny jest nierozerwalnie związany z każdą porcją danych podpisanych kluczem prywatnym i tylko on może być wykorzystany do weryfikacji poprawności podpisu i spójności podpisanych danych. Klucz publiczny może być zabezpieczony przed obcą ingerencją przez podpisanie kluczem prywatnym wszystkich elementów klucza publicznego (razem z identyfikatorami użytkownika). Podpisywanie publicznej części klucza odpowiadającą jej częścią prywatną nazywa się autopodpisaniem, a klucz publiczny, którego identyfikatory użytkownika są autopodpisane nazywa się certyfikatem.
Rozważmy przykład, w którym Chloe ma dwa identyfikatory użytkownika i trzy klucze podrzędne. Podpisy na identyfikatorach użytkownika można sprawdzić poleceniem check w menu edycji klucza.
chloe% gpg --edit-key chloe gpg (GnuPG) 1.0.6; Copyright (C) 2001 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Dostępny jest klucz tajny. pub 1024D/26B6AAE1 utworzony: 1999-06-15 wygasa never zaufanie: -/u sub 2048g/0CF8CB7A utworzony: 1999-06-15 wygasa never sub 1792G/08224617 utworzony: 1999-06-15 wygasa 2002-06-14 sub 960D/B1F423E7 utworzony: 1999-06-15 wygasa 2002-06-14 (1) Chloe (Jester) <chloe@cyb.org> (2) Chloe (Plebian) <chloe@tel.net> Polecenie> check uid Chloe (Jester) <chloe@cyb.org> sig! 26B6AAE1 1999-06-15 [podpis klucza nim samym] uid Chloe (Plebian) <chloe@tel.net> sig! 26B6AAE1 1999-06-15 [podpis klucza nim samym] |
Dodawanie i usuwanie części klucza
Nowe podklucze i identyfikatory użytkownika mogą być dodawane do klucza nawet po jego utworzeniu. Identyfikator użytkownika dodaje się przy pomocy polecenia adduid. Należy podać nazwisko, adres poczty elektronicznej i komentarz. Postępuje się przy tym dokładnie, jak w przypadku tworzenia nowego klucza. Nowy klucz podrzędny dodaje się przy pomocy polecenia addkey. I tutaj interfejs programu działa podobnie jak przy tworzeniu nowego klucza. Kluczem podrzędnym może być klucz podpisujący DSA, klucz szyfrujący ElGamal, lub klucz podpisujący/szyfrujący ElGamal. Każdy nowo dodany element klucza (identyfikator użytkownika lub klucz podrzędny) jest automatycznie podpisywany głównym kluczem podpisującym. Dlatego program prosi o hasło, którym zabezpieczony jest klucz prywatny.
Dodatkowe identyfikatory użytkownika są przydatne osobom, które potrzebują kilku "osobowości". Użytkownik może chcieć używać swojego klucza publicznego w pracy oraz w działalności społecznej. Współpracownicy będą znali go jako osobę używającą innego identyfikatora (np. ze względu na adres email) niż działacze. Te dwie grupy nie muszą się pokrywać, a jej członkowie nie mają powodów, aby ufać w poprawność drugiego identyfikatora. Stąd pomysł posiadania dwóch identyfikatorów.
Klucze podrzędne są również użyteczne. Identyfikatory użytkownika związane z podstawowym kluczem publicznym są weryfikowane przez korespondentów i znajomych. Zmiana klucza wymaga, aby wszyscy oni ponownie podpisali ten klucz. Może się to okazać trudne i czasochłonne. Z drugiej strony dobrą praktyką jest zmienianie klucza co jakiś czas. Dane zakodowane "spalonym" kluczem można traktować, jakby nie były zaszyfrowane w ogóle. Dzięki zmianie klucza narażone sa jedynie te dane, które były nim zaszyfrowane.
Klucze podrzędne i identyfikatory użytkownika mogą być usuwane. Aby tego dokonać należy najpierw wybrać odpowiedni element klucza przy pomocy polecenia key lub uid. Działają one jak przełączniki. Wywołanie key 2 zaznaczy drugi klucz, a ponowne wywołanie key 2 odwoła to zaznaczenie. Bezargumentowe wywołanie odznaczy wszystkie klucze (w przypadku polecenia key) lub identyfikatory użytkownika (uid). Polecenie deluid usuwa zaznaczone identyfikatory użytkownika, a delkey zaznaczone fragmenty klucza wraz z odpowiadającymi im częściami prywatnymi.
Usuwanie nieużywanych części klucza wydaje się być naturalne. Niestety operacja ta znacznie komplikuje proces dystrybucji klucza. W trakcie importu nowego klucza jest on bowiem scalany ze starą wersją, jeśli taka istnieje. W ten sposób wszystkie nieaktualne części klucza zostaną przywrócone. Aby temu zapobiec należałoby najpierw usunąć stary klucz, a dopiero później zaimportować go od nowa. Takie postępowanie jest dodatkowym obciążeniem dla wszystkich korespondentów. Poza tym jest ono nie możliwe do przeprowadzenia, jeśli przechowujemy swoje klucze publiczne na serwerze kluczy. Wysłanie nowej wersji klucza spowoduje bowiem automatyczne scalenie nowej wersji ze starą. Dlatego lepiej jest unieważnić wybraną składową klucza zamiast ją usuwać.
Unieważnianie składowych klucza
Zaznaczone podklucze unieważnia się przy pomocy polecenia revkey. Do klucza dołączony zostanie podpis unieważniający. W przeciwieństwie do przełącznika --gen-revoke efekt unieważnienia klucza jest natychmiastowy.
Polecenie> revkey Czy na pewno chcesz unieważnić ten klucz? t Please select the reason for the revocation 1 = Klucz został skompromitowany 2 = Klucz został zastąpiony 3 = Klucz nie jest już używany 0 = Cancel Twoja decyzja? 3 Enter an optional description; end it with an empty line: > Reason for revocation: Klucz nie jest już używany (No description given) Is this okay? t Musisz podać wyrażenie przejściowe (hasło) aby uaktywnić klucz tajny dla użytkownika: "Chloe (Jester) <chloe@cyb.org>" długość 1024 bitów, typ DSA, klucz B87DBA93, stworzony 1999-06-28 pub 1024D/B87DBA93 utworzony: 1999-06-28 wygasa never zaufanie: -/u sub 2048g/B7934539 utworzony: 1999-06-28 wygasa never sub 1792G/4E3160AD utworzony: 1999-06-29 wygasa 2000-06-28 podklucz został unieważniony: 1999-06-29 sub 960D/E1F56448 utworzony: 1999-06-29 wygasa 2000-06-28 (1) Chloe (Jester) <chloe@cyb.org> (2) Chloe (Plebian) <chloe@tel.net> |
Identyfikator użytkownika unieważnia się w inny sposób. Zawiera on bowiem listę podpisów, które potwierdzają przynależność danego klucza do prawdziwej osoby. Teoretycznie identyfikator użytkownika jest niezbywalny. W praktyce elementy identyfikatora użytkownika (jak np. adres email lub komentarz) mogą się zmieniać z czasem, sprawiając że identyfikator przestaje być poprawny.
Standard OpenPGP nie opisuje unieważniania identyfikatorów użytkownika, ale można to zrobić unieważniając autopodpis pod danym identyfikatorem. Z powodów opisanych wcześniej korespondenci nie będą mogli ufać identyfikatorowi użytkownika, który nie ma poprawnego autopodpisu.
Podpis unieważnia się przy pomocy polecenia revsig. Interfejs programu zapyta użytkownika o każdy z podpisów.
Command> revsig
Te identyfikatory użytkowników są podpisane przez Ciebie:
Chloe (Jester) <chloe@cyb.org>
podpisany przez 28FB39F1 w 2003-01-07
Chloe (Plebian) <chloe@tel.net>
podpisany przez 28FB39F1 w 2003-01-07
Identyfikator użytkownika: Chloe (Jester) <chloe@cyb.org>
podpisano Twoim kluczem 28FB39F1 w 2003-01-07
Stworzyć certyfikat unieważnienia tego podpisu? (t/N)n
Identyfikator użytkownika: Chloe (Plebian) <chloe@tel.net>
podpisano Twoim kluczem 28FB39F1 w 2003-01-07
Stworzyć certyfikat unieważnienia tego podpisu? (t/N)t
Czy na pewno chcesz unieważnić te podpisy:
Chloe (Plebian) <chloe@tel.net>
podpisany przez 28FB39F1 w 2003-01-07
Na pewno utworzyć certyfikaty unieważnienia ? (t/N)t
Please select the reason for the revocation:
4 = Identyfikator użytkownika przestał być poprawny
0 = Cancel
Twoja decyzja? 4
Enter an optional description; end it with an empty line:
>
Reason for revocation: Identyfikator użytkownika przestał być poprawny
(No description given)
Is this okay? t
Musisz podać wyrażenie przejściowe (hasło) aby uaktywnić klucz tajny
dla użytkownika: "Chloe (Jester) <chloe@cyb.org>"
długość 1024 bitów, typ DSA, klucz B87DBA93, stworzony 1999-06-28
pub 1024D/B87DBA93 utworzony: 1999-06-28 wygasa never zaufanie: -/u
sub 2048g/B7934539 utworzony: 1999-06-28 wygasa never
sub 1792G/4E3160AD utworzony: 1999-06-29 wygasa 2000-06-28
podklucz został unieważniony: 1999-06-29
sub 960D/E1F56448 utworzony: 1999-06-29 wygasa 2000-06-28
(1) Chloe (Jester) <chloe@cyb.org>
(2) Chloe (Plebian) <chloe@tel.net> |
Unieważnienie identyfikatora użytkownika można zaobserwować na liście podpisów pod danym identyfikatorem.
Polecenie> check uid Chloe (Jester) <chloe@cyb.org> sig! B87DBA93 1999-06-28 [podpis klucza nim samym] uid Chloe (Plebian) <chloe@tel.net> rev! B87DBA93 1999-06-29 [unieważnienie] sig! B87DBA93 1999-06-28 [podpis klucza nim samym] |
Unieważnienie części klucza dodaje do niego podpis unieważniający. Dzięki temu proces scalania starej i nowej wersji klucza nie przejdzie niezauważony przez nikogo. Unieważnienie gwarantuje, że każdy użytkownik będzie posiadał spójną kopię klucza publicznego.
Aktualizacja okresu ważności
Okres ważności klucza zmienia się przy pomocy polecenia expire z menu edycji klucza. Jeśli żaden z kluczy nie jest wybrany to zmieniony zostanie okres ważności klucza głównego.
Okres ważności klucza związany jest z jego autopodpisem. Zmiana okresu ważności polega na usunięciu starego autopodpisu i dodanie nowego. Ponieważ korespondenci nie usuną poprzednich wersji podpisu, będą widzieli drugi autopodpis. Ważny jest jednak zawsze ostatni podpis, więc każdy użytkownik będzie mógł jednoznacznie określić okres ważności każdego klucza.
Potwierdzanie poprawności kluczy publicznych
W rozdziale 1 opisana została procedura potwierdzania poprawności klucza publicznego, w której odcisk klucza publicznego musi być osobiście sprawdzony przez jego właściciela. Tak zweryfikowany klucz podpisuje się następnie swoim kluczem prywatnym. Tylko w ten sposób można być pewnym, że klucz rzeczywiście należy do właściwego korespondenta, a dzięki własnemu podpisowi można zawsze sprawdzić, czy ktoś nie próbował zmieniać tego klucza już po zaimportowaniu. Niestety procedura powyższa jest niezbyt wygodna, jeśli trzeba potwierdzać dużą liczbę kluczy, bądź nie zna się osobiście danego korespondenta.
GnuPG rozwiązuje ten problem przy pomocy mechanizmu popularnie zwanego siecią zaufania. W modelu sieci zaufania odpowiedzialność za potwierdzenie poprawności klucza publicznego przenosi się na osoby, którym się ufa. Załóżmy na przykład, że
Alicja podpisała klucz Blake'a, a
Blake podpisał klucze Chloe i Dharmy.
Ufanie właścicielom kluczy
W rzeczywistości zaufanie jest czymś subiektywnym. Załóżmy, że Alicja podpisała klucz Blake'a, ale nie wierzy w rzetelność weryfikacji podpisywanych przez niego kluczy. W takim przypadku nie powinna opierać swojego przekonania o poprawności tych kluczy jedynie na podpisie Blake'a. W modelu sieci zaufania z kluczem każdego użytkownika związana jest wartość określająca wiarę w rzetelność jego właściciela. Są cztery możliwe poziomy zaufania.
- unknown
Nic nie wiadomo o rzetelności właściciela klucza. Początkowo każdy importowany klucz publiczny otrzymuje tę wartość.
- none
Wiadomo, że właściciel klucza podpisuje niepoprawne klucze.
- marginal
Właściciel klucza rozumie zasady podpisywania kluczy i sprawdza ich poprawność przed podpisaniem.
- full
Właściciel klucza jest ekspertem w sprawach podpisywania kluczy i jego podpis na czyimś kluczu jest najlepszym świadectwem poprawności tego klucza.
Edytor kluczy programu GnuPG może być wykorzystany do zmiany poziomu zaufania przypisanego do klucza. Służy do tego polecenie trust. W poniższym przykładzie Alicja zmienia poziom zaufania do Blake'a po czym odświeża wartości poprawności kluczy na podstawie nowego poziomu zaufania do Blake'a.
alicja% gpg --edit-key blake pub 1024D/8B927C8A stworzony: 1999-07-02 wygasa: never zaufanie: q/f sub 1024g/C19EA233 stworzony: 1999-07-02 wygasa: never (1) Blake (Egzekutor) <blake@cyb.org> Polecenie> trust pub 1024D/8B927C8A stworzony: 1999-07-02 wygasa: never zaufanie: q/f sub 1024g/C19EA233 stworzony: 1999-07-02 wygasa: never (1) Blake (Egzekutor) <blake@cyb.org> Zastanów się jak bardzo ufasz temu użytkownikowi w kwestii sprawdzania tożsamości innych właścicieli kluczy (czy sprawdzi on odciski klucza pobrane z różnych źródeł, dokumenty potwierdzające tożsamość, itd.)? 1 = nie wiem 2 = NIE ufam mu 3 = mam ograniczone zaufanie 4 = mam pełne zaufanie 5 = ufam absolutnie m = powrót do głównego menu Twoja decyzja? 3 pub 1024D/8B927C8A stworzony: 1999-07-02 wygasa: never zaufanie: m/f sub 1024g/C19EA233 stworzony: 1999-07-02 wygasa: never (1) Blake (Egzekutor) <blake@cyb.org> Polecenie> quit [...] |
Wykorzystywanie zaufania do weryfikacji kluczy
Sieć zaufania daje możliwość skorzystania z bardziej wyrafinowanego algorytmu, do potwierdzania poprawności kluczy. Dotychczas klucz uznawaliśmy za poprawny jedynie, jeśli został osobiście podpisany przez użytkownika. W nowym algorytmie klucz K uznamy za poprawny, jeśli spełnia dwa warunki:
jest podpisany przez dostateczną liczbę poprawnych kluczy, tzn.
został osobiście podpisany przez użytkownika,
został podpisany przez osobę z pełnym zaufaniem lub
został podpisany przez trzy osoby z marginalnym zaufaniem; i
ścieżka podpisów od klucza K do korzenia jest nie dłuższa niż 5 krawędzi
Rysunek Rysunek 3-1 przedstawia przykładową sieć zaufania z korzeniem w węźle Alicja. Krawędź w grafie oznacza, że użytkownik podpisał klucz. W tabeli zastawione są klucze, które Alicja uważa za poprawne na podstawie jej zaufania do pozostałych członków sieci. Poniższy przykład zakłada, że wystarczą dwie osoby o marginalnym bądź jedna o pełnym zaufaniu do potwierdzenia poprawności klucza. Maksymalna długość ścieżki wynosi trzy.
Przy obliczaniu poprawności kluczy Blake i Dharma są zawsze uznawani za poprawnych ponieważ ich klucze zostały podpisane przez Alicję. Poprawność pozostałych kluczy zależy od zaufania. W pierwszej sytuacji Dharma jest osobą w pełni zaufaną wobec czego klucze Chloe i Francisa są uznane za poprawne. W drugim przypadku Blake i Dharma są obdarzeni marginalnym zaufaniem. Ponieważ dokładnie tylu użytkowników potrzeba do weryfikacji klucza, klucz Chloe zostanie uznany za całkowicie poprawny, ale klucz Francisa zostanie uznany za poprawny jedynie marginalnie. W kolejnym przykładzie Chloe i Dharma są obdarzone marginalnym zaufaniem. Klucz Chloe uznany jest za poprawny marginalnie ponieważ Dharma jest jedynym użytkownikiem o marginalnym zaufaniu, który ten klucz podpisał. Klucz Francisa będzie również marginalnie poprawny ponieważ Dharma jest jedynym zaufanym użytkownikiem, który go podpisał. Dodanie marginalnego zaufania Blake'owi sprawi, że klucz Chloe stanie się całkowicie poprawny, a przez to uwiarygodni klucz Francisa oraz marginalnie klucz Eleny. W ostatnim przypadku pełne zaufanie do Blake'a, Chloe i Eleny nie wystarcza do uwiarygodnienia klucza Geoffa ponieważ długość ścieżki przekracza dozwoloną liczbę 3.
Model sieci zaufania jest wygodnym rozwiązaniem problemu bezpiecznego rozpowszechniania kluczy publicznych. Pozwala dostroić GnuPG tak, by odzwierciedlało podejście użytkownika. Z jednej strony można zmusić program do akceptowania jedynie krótkich i wielokrotnych ścieżek od korzenia do badanego klucza. Z drugiej strony można być zadowolonym z niewielu długich ścieżek. Pierwszy model znacznie silniej gwarantuje, że klucz należy do właściwej osoby. Ceną jest oczywiście znaczne utrudnienie w potwierdzaniu poprawności kluczy, ponieważ wymaga bezpośredniego podpisania większej ilości kluczy.
Dystrybucja kluczy
Najlepiej byłoby, gdyby można było wręczać klucze osobiście swoim korespondentom. W rzeczywistości klucze są bardzo często przekazywane pocztą elektroniczną lub innymi kanałami komunikacyjnymi. Przekazywanie kluczy przez email jest powszechnie praktykowane w przypadku niewielkiej liczby korespondentów. W przypadku dużej liczby znajomych umieszcza się swój klucz publiczny na swojej domowej stronie www. Ostatnie rozwiązanie jest jednak niedopuszczalne, jeśli osoba potrzebująca klucz publiczny nie zna adresu strony jego właściciela.
Rozwiązaniem tego problemu są serwery kluczy, które gromadzą i rozprowadzają klucze publiczne. Klucz publiczny wysłany do serwera zostanie dodany do bazy danych lub scalony z poprzednią wersją klucza, jeśli taka istnieje. Po nadejściu zapytania serwer przegląda swoją bazę i zwraca odpowiedni klucz publiczny, jeśli taki znajduje się w bazie.
Serwer kluczy może się również okazać bardzo cennym narzędziem dla ludzi, którzy często podpisują klucze swoich znajomych. Gdyby Blake podpisał klucz Alicji, to powinien odesłać jej podpisaną kopię, tę zaś mogłaby Alicja rozesłać wszystkim swoim znajomym. Dzięki niewielkiemu wysiłkowi Alicji i odpowiedzialności Blake'a można zbudować dużą i ciasną sieć zaufania. To prowadzi zaś do zwiększenia bezpieczeństwa PGP. Jeśli klucze trzeba podpisywać często, może to być dużą niedogodnością.
Używanie serwera kluczy upraszcza ten proces. Blake może wysłać podpisany klucz Alicji do serwera kluczy. Serwer doda podpis Blake'a do swojej kopii klucza Alicji. Każdy, kto będzie zainteresowany w aktualizacji klucza Alicji, będzie mógł pobrać z serwera klucz zawierający podpis Blake'a. Dzięki temu Alicja nie musi uczestniczyć w dalszym rozpowszechnianiu swojego klucza, a dodatkowo może również otrzymać swój klucz z podpisami swoich korespondentów.
Klucze wysyła się do serwera przy pomocy przełącznika --send-keys. Wymaga on wyspecyfikowania kluczy, które będą wysłane do serwera. Adres serwera podaje się w formie argumentu do przełącznika --keyserver. Analogicznie przełącznik --recv-keys służy do pobierania klucza z serwera. Jednak argumentem tego przełącznika musi być identyfikator klucza. W poniższym przykładzie Alicja pobiera uaktualnienie swojego klucza publicznego z nowym podpisem z serwera certserver.pgp.com i wysyła swoją kopię klucza publicznego Blake'a do tego samego serwera w celu rozpowszechnienia swojego podpisu na nim.
alicja% gpg --keyserver certserver.pgp.com --recv-key 0xBB7576AC gpg: requesting key BB7576AC from certserver.pgp.com ... gpg: key BB7576AC: 1 new signature gpg: Total number processed: 1 gpg: new signatures: 1 alicja% gpg --keyserver certserver.pgp.com --send-key blake@cyb.org gpg: success sending to 'certserver.pgp.com' (status=200) |
Rozdział 4. GnuPG w codziennym zastosowaniu
GnuPG jest złożonym narzędziem, z którym związane są liczne kwestie techniczne, społeczne i prawne. Technicznie program został zaprojektowany aby spełniał swoje obowiązki w stosunku do różnych wymagań związanych z bezpieczeństwem. Komplikuje to zarządzanie kluczami. Ze społecznego punktu widzenia używanie GnuPG nie jest decyzją dotyczącą jednostki. Efektywne używanie GnuPG wymaga aby obie komunikujące się strony stosowały to rozwiązanie. Wreszcie prawa dotyczące szyfrowania danych cyfrowych, a w szczególności tego, czy używanie GnuPG jest legalne, różnią się w zależności od kraju, a w niektórych krajach kwestia ta nie jest jeszcze rozstrzygnięta.
Ten rozdział omawia powyższe kwestie. Czytelnik dowie się jak używać GnuPG w sytuacjach wymagających różnych podejść do szyfrowania. Sugerowane są również rozwiązania pozwalające na stosowanie GnuPG, kiedy korespondenci używają innego oprogramowania. Zarysowany będzie również bieżący status prawny GnuPG w niektórych krajach.
Definiowanie potrzeb utrzymania bezpieczeństwa
GnuPG jest narzędziem, które zabezpiecza prywatność użytkownika. O ochronie prywatności mówimy, gdy żadna niepowołana osoba nie może odczytać wiadomości do niej nie zaadresowanej.
Sposób stosowania GnuPG zależy od determinacji i zasobności ludzi, którym może zależeć na odczytaniu zaszyfrowanych wiadomości. Podsłuchiwać może pozbawiony skrupułów administrator sieci skanujący całą pocztę, szpieg przemysłowy szukający tajnych danych wewnątrz obcej firmy, bądź ścigający użytkownika komornik. Używanie GnuPG do ochrony przed przypadkowym podsłuchiwaczem różni się znacznie od stosowanie tego samego programu przeciwko zdeterminowanemu przeciwnikowi. Podstawowym celem użytkownika jest zwiększenie kosztu odzyskania zaszyfrowanych danych powyżej ich wartości.
Dostosowanie GnuPG koncentruje się wokół czterech kwestii:
wyboru rozmiaru klucza,
ochrony klucza prywatnego,
doboru okresu ważności i stosowania kluczy podrzędnych oraz
zarządzania siecią zaufania.
Wybór rozmiaru klucza
Wybór rozmiaru klucza zależy od rodzaju klucza. W OpenPGP klucz składa się na ogół z kilku różnych składowych. Musi on zawierać główny klucz podpisujący oraz jeden lub więcej dodatkowych kluczy do szyfrowania. Wybranie domyślnego klucza podczas generacji programem GnuPG spowoduje utworzenie klucza DSA jako podstawowego do podpisywania oraz dodatkowe klucze ElGamala.
DSA nie zezwala na klucze przekraczające 1024 bity. Nie jest to specjalnie wiele jeśli wziąć pod uwagę dzisiejsze możliwości faktoryzacji liczb, ale tak właśnie określono w standardzie. Należy używać 1024-bitowych kluczy DSA.
Klucze ElGamala mogą być dowolnego rozmiaru. Ponieważ GnuPG stosuje szyfrowanie hybrydowe, klucz publiczny służy do zaszyfrowania 128-bitowego klucza sesyjnego, a odpowiadający mu klucz prywatny do odszyfrowania go. Mimo to rozmiar klucza wpływa znacząco na szybkość szyfrowania i odszyfrowywania ponieważ koszt algorytmu jest wykładniczy ze względu na rozmiar klucza. Większe klucze generowane są dłużej i zajmują więcej przestrzeni dyskowej. Tymczasem rosnący rozmiar klucza nie rekompensuje tych strat w równych proporcjach. Jeśli nawet klucz będzie dostatecznie duży do oparcia się atakowi to osoba chcąca przechwycić dane zastosuje zupełnie inną metodę ich zdobycia nie wyłączając włamania do domu czy biura, albo wręcz obrabowania użytkownika. Zaleca się stosowanie kluczy 1024-bitowych. Jeśli jakimś cudem wiesz, że potrzebujesz większego rozmiaru klucza, to prawdopodobnie nie potrzebujesz tego czytać, a powinieneś skonsultować się ze specjalistą w dziedzinie ochrony danych.
Ochrona klucza prywatnego
Ochrona klucza prywatnego jest najważniejszym zadaniem użytkownika GnuPG. Jeśli komuś uda się zdobyć klucz prywatny, to będzie mógł odczytać wszelkie zaszyfrowane dane, a nawet złożyć podpis w imieniu właściciela klucza. Zgubienie klucza prywatnego oznacza utratę możliwości odczytania wszystkich zaszyfrowanych wiadomości bez względu na to, kiedy powstały, a także uniemożliwia składanie podpisów. Całkowita utrata klucza prywatnego to katastrofa.
Bez względu na to, w jakim celu stosuje się GnuPG należy zachować certyfikat unieważniający oraz kopię klucza prywatnego na zabezpieczonym przed zapisem nośniku i schować w bezpiecznym miejscu. Można na przykład wypalić je na płycie kompaktowej i złożyć w depozycie bankowym, w zapieczętowanej kopercie. Innym sposobem jest zachowanie tych danych na dyskietce i schowanie jej w domu. Cokolwiek by to nie było, dane te muszą znajdować się w bezpiecznym miejscu tak długo, jak długo oczekuje się używać tego klucza. Kopia ta powinna być staranniej chroniona niż ta, której używa się na codzień.
W celu zagwarantowania bezpieczeństwa GnuPG trzyma te dane zaszyfrowane przy pomocy szyfru symetrycznego. Dlatego każde użycie klucza prywatnego wymaga podania hasła. W ten sposób tworzy się dwie bariery dla potencjalnego agresora: (1) musi on zdobyć klucz i (2) musi umieć ten klucz odszyfrować.
Bezpieczne przechowywanie klucza prywatnego jest bardzo ważne, ale zarazem dość kosztowne. Najlepiej byłoby trzymać klucz prywatny na nośniku zabezpieczonym przed zapisem jak np. dyskietka i używać go jedynie na jednostanowiskowym komputerze, nie podłączonym do żadnej sieci. To może być niewygodne, a czasami nawet niemożliwe. Zdarzyć się może, że użytkownik korzysta z komputera w szkole lub zmuszony by był do odłączania kabla modemowego ilekroć chciałby skorzystać z GnuPG.
Nie wyklucza to stosowania GnuPG. Jeśli użytkownik uważa, że jego dane są na tyle istotne, żeby je zaszyfrować, ale nie na tyle, żeby podejmować dalsze środki ostrożności, to jest to wyłącznie jego świadoma decyzja.
Dobre hasło jest absolutnie niezbędne przy stosowaniu GnuPG. Każda niepowołana osoba, która zdobędzie dostęp do klucza prywatnego musi pokonać szyfr chroniący go. Zamiast stosować atak typu brute-force, z pewnością będzie próbować odgadnąć hasło.
Przyczyną tego jest fakt, że większość ludzi wybiera hasła, które można łatwiej odgadnąć niż ciąg 128 losowych bitów. Jeśli hasło jest słowem, to dużo taniej będzie wypróbować wszystkie słowa z ludzkich języków. Nawet jeśli litery słowa są poprzestawiane jak np. w k3wldood, to nadal opłaca się spróbować ataku słownikowego z grupą permutacji. Ten sam problem dotyczy cytatów. Ogólnie rzecz biorąc hasła oparte na wyrażeniach z języka naturalnego są kiepskie, ponieważ zawierają małą ilość losowości i dużą nadmiarowość. Należy unikać takich haseł.
Dobre hasło to takie, które łatwo zapamiętać, ale trudno zgadnąć. Powinno składać się z jak największej liczby znaków alfanumerycznych w tym: wielkich liter, cyfr i znaków interpunkcyjnych jak np. } lub |. Warto spędzić odrobinę czasu na wymyśleniu dobrego hasła, bo jest ono bardzo ważnym ogniwem ochrony prywatności.
Wybieranie okresu ważności i stosowanie kluczy podrzędnych
Domyślnie generowany jest główny klucz podpisujący DSA i klucz ElGamala do szyfrowania danych. Jest to wygodne, ponieważ ich zastosowania są różne i użytkownik może chcieć ich używać przez inny okres czasu. Główny klucz podpisujący służy do składania cyfrowych podpisów i gromadzi podpisy osób potwierdzających tożsamość jego właściciela. Klucz szyfrujący służy do kodowania informacji wysyłanych do użytkownika. Na ogół klucz podpisujący ma dość długi okres ważności, np. wieczny, choćby dlatego, że ciężko jest później odzyskać podpisy na swoim kluczu. Z drugiej strony klucz szyfrujący może być zmieniany co jakiś czas, żeby zapewnić dodatkowy poziom bezpieczeństwa. Jeśli bowiem komuś uda się złamać ten klucz, to będzie mógł nim odszyfrować wszystkie do tej pory zaszyfrowane wiadomości.
Nie zdarza się, żeby ktoś chciał, aby jego główny klucz kiedykolwiek wygasł. Są dwa przypadki, w których można rozważyć taką ewentualność. Pierwszy jest taki, że klucz będzie miał ograniczony okres użytku. Na przykład polityk mógłby chcieć, aby jego klucz był ważny jedynie przez okres kampanii wyborczej. Drugi dotyczy sytuacji, w której użytkownik traci kontrolę nad swoim kluczem, ale nie posiada certyfikatu unieważniającego. Klucz przestanie być użyteczny po wygaśnięciu okresu ważności.
Zmiana klucza szyfrującego jest dość prosta, ale może przyspożyć odrobinę kłopotu. Praktykuje się generowanie kluczy nowych kluczy szyfrujących na krótko przed wygaśnięciem poprzedniego. Każdy kto będzie chciał zaszyfrować wiadomość po wygaśnięciu ważności klucza będzie musiał odnaleźć aktualną wersję klucza. Wygoda tego rozwiązania zależy w dużej mierze od sposobu dystrybucji klucza. Na szczęście nie potrzeba zbierać podpisów pod nowym kluczem szyfrującym, jako że automatycznie jest on podpisany głównym kluczem podpisującym. Ten zaś został już zapewne niejednokrotnie podpisany przez znajomych użytkownika.
Zwiększenie bezpieczeństwa może nie być warte poświęcenia. Atakujący może nadal czytać wszystkie dokumenty zaszyfrowane starym kluczem. Zmiana klucza wpływa jedynie na przyszłe dokumenty. Aby je odkodować atakujący musiałby ponownie złamać nowy klucz.
Posiadanie dwóch lub większej ilości kluczy szyfrujących mija się z celem i nie wpływa na poziom bezpieczeństwa. Oczywiście można posiadać wiele starych kluczy, przy pomocy których można odkodowywać stare dokumenty, ale tylko jeden klucz powinien być w bieżącym użyciu.
Utrzymywanie sieci zaufania
Podobnie jak w przypadku ochrony klucza prywatnego, również zarządzanie własną siecią zaufania jest aspektem stosowania GnuPG, który wymaga od użytkownika zrównoważenia bezpieczeństwa i kosztów, jakie się w związku z jego utrzymywaniem ponosi. Użytkownik może sobie pozwolić na dość dużą dozę zaufania, jeśli chce się tylko ochronić przed przypadkowym podsłuchem. W przypadku uzasadnionego podejrzenia, że istnieją osoby, którym mogłoby zależeć na zakłóceniu prywatności użytkownika, należy poświęcić więcej uwagi sprawdzaniu poprawności podpisów swoich korespondentów.
Podczas podpisywania innych kluczy należy zawsze zachować maksimum ostrożności. Własne poczucie bezpieczeństwa nie usprawiedliwia beztroskiego podpisywania. Od tego bowiem zależy również bezpieczeństwo pozostałych użytkowników. Osoba nie dbająca o względy bezpieczeństwa z powodu własnej wygody, osłabia sieć zaufania innych użytkowników i utrudnia im bezpieczną komunikację. Zawsze należy się zastanowić, czy wszyscy znajomi mogliby być zadowoleni z troski przedsięwziętej do potwierdzenia tożsamości właściciela podpisywanego klucza.
W praktyce zarządzanie siecią zaufania ogranicza się jedynie do przypisywania innym poziomu zaufania i ustawienia wartości opcji --marginals-needed i --completes-needed. Każdy klucz podpisany osobiście będzie uznany za poprawny, ale jedynie w małych grupach użytkowników praktyczne okaże się podpisywanie kluczy wszystkich osób, z którymi się komunikuje. W pozostałych przypadkach nie obejdzie się bez okazania innym zaufania.
Dobrze byłoby mieć dokładne wyczucie odnośnie zaufania, jakim można obdarzyć innych użytkowników i tylko dostroić GnuPG do swoich potrzeb w zakresie poczucia bezpieczeństwa. Dobrym sposobem jest ustawienie pełnego zaufania kilku najbliższym znajomym, którzy będą ostrożnie podchodzić do podpisywania kluczy, a następnie przypisywać marginalne zaufanie wszystkim pozostałym. Można wtedy ustawić --completes-needed na 1, a --marginals-needed na 2. W przypadku większej ostrożności można wybrać wartości 1 i 3 lub nawet 2 i 3. Osoby mniej dbałe o ochronę własnej prywatności mogą wybrać 1 i 1. Ogólna zasada jest następująca: wyższe numery oznaczają, że większa liczba osób będzie musiała uczestniczyć w spisku, aby użytkownik uwierzył, że podany mu klucz nie należy do rzeczonej osoby.
Tworzenie sieci zaufania
GnuPG nie da się używać w pojedynkę. Sieć zaufania jest niezbędnym elementem bezpiecznej komunikacji. Na pierwszy rzut oka tworzenie sieci zaufania wydaje się być trudnym zadaniem. Korespondenci muszą również używać GnuPG[5], a na domiar złego grupa użytkowników powinna być na tyle duża, aby sieć miała jakiekolwiek zastosowanie. To są problemy społeczne, nie techniczne. Nie mniej trzeba sobie jakoś z nimi poradzić.
Początkujący użytkownik GnuPG musi zdać sobie sprawę z tego, że nie cała jego korespondencja musi być zabezpieczona przed osobami trzecimi. Warto rozpocząć od niewielkiej, być może zaledwie dwu lub trzyosobowej, grupy znajomych. Wszyscy powinni wygenerować swoje klucze i podpisać je sobie wzajemnie. Będzie to początkowa sieć zaufania. Użytkownik z pewnością doceni jej niewielki rozmiar i prostotę, a także nabierze ostrożności, która będzie mu potrzebna przy przyszłym jej poszerzaniu.
Potrzeba ochrony swojej korespondencji kierowanej do użytkowników GnuPG spoza początkowej sieci zaufania napotka dwa poważne problemy: (1) nie wiadomo, kto używa GnuPG i (2) trudno jest zweryfikować poprawność klucza obcej osoby. Pierwsza trudność nie istniałaby, gdyby ludzie chwalili się tym, że używają GnuPG. Są przynajmniej trzy sposoby poinformowania innych, że korzysta się z rozwiązań kryptograficznych. Po pierwsze można podpisywać swoje listy. Po drugie można umieścić swój klucz publiczny na swojej stronie domowej. Po trzecie można wysłać swój klucz do serwera kluczy, a do sygnaturki[6] dopisać identyfikator swojego klucza. Ogłaszając swój klucz ośmiela się innych użytkowników do zrobienia tego samego. Poza tym ułatwia to innym rozpoczęcie bezpiecznej wymiany informacji. Dzięki inicjatywie podjętej przez użytkownika mogą od razu rozpocząć bezpieczną wymianę informacji.
Weryfikacja poprawności klucza jest dużo trudniejsza. Nie jest możliwe podpisanie klucza osoby, której się nie zna osobiście. Można tylko polegać na cudzych podpisach i liczyć na to, że znajdzie się ścieżkę podpisów prowadzących do własnego. Aby zwiększyć swoje szanse należy przejąć inicjatywę i przekonać jak największą liczbę osób do podpisania swojego klucza publicznego. Dobrym sposobem jest uczestnictwo w tzw. key signing party. Imprezy takie coraz powszechniej są częściami różnych konferencji również w Polsce. Każdy chętny może również zorganizować tego typu spotkanie. Osoby o biernym usposobieniu mogą nosić ze sobą odcisk klucza na wypadek okazji wymiany kluczy. Druga strona może wówczas zabrać odcisk do domu, sprawdzić jego poprawność i podpisać klucz.
To wszystko jest oczywiście jedynie propozycją. Nikt nie może czuć się zobowiązany do rozpowszechniania swojego klucza lub podpisywania kluczy innych osób. Potęga GnuPG tkwi w możliwości dostosowania się do różnego zapotrzebowania na ochronę prywatności. Wykazanie się inicjatywą jest jednak najbardziej praktycznym rozwiązaniem prowadzącym do powiększenia swojej sieci zaufania, a w efekcie do bardziej powszechnego i codziennego stosowania GnuPG.
Stosowanie GnuPG zgodnie z prawem
Przepisy dotyczące oprogramowania kryptograficznego różnią się w zależności od kraju i zmieniają się dosyć często. Bert-Japp Koops napisał przewodnik Crypto Law Survey. Jest to stale aktualizowany zbiór przepisów zebranych z całego świata.
Rozdział 5. Pozostałe tematy
Poniższy rozdział zawiera kwestie, które nie pasowały do żadnego z poprzednich. Wraz z rozrostem treści, poszczególne tematy będą grupowane w nowe rozdziały. Czekamy na sugestie o nie poruszanych jeszcze sprawach. Chętnych namawiamy nawet do napisania wstępnej wersji omówienia.
Tworzenie interfejsu użytkownika
Alma Whitten i Doug Tygar opracowali studium nad interfejsem programu NAI PGP 5.0, w którym doszli do wniosku, że jest on nieprzyjazny i niejasny dla początkującego użytkownika. Wyniki wskazywały na to, że zaledwie czworo z dwunastu testowanych osób potrafiło poprawnie wysłać zaszyfrowany list, podczas gdy trzy inne wysłały tajne dane całkowicie nie zaszyfrowane. Połowa tematów wziętych pod uwagę ma podłoże techniczne.
Wyniki te nie są zaskakujące. Dla zaawansowanego użytkownika, który dobrze rozumie ideę szyfrowania asymetrycznego i sieci zaufania, interfejs programu PGP 5.0 będzie przejrzysty i wygodny. Niestety początkujący użytkownicy nie mają zielonego pojęcia o szyfrowaniu kluczem publicznym i zarządzaniu kluczami. Taki interfejs sprawia, że czują się tylko bardziej zagubieni.
Przed stworzeniem interfejsu do GnuPG należy bezwzględnie zapoznać się z raportem Whittena i Tygara. Zawiera on wskazówki dotyczące każdego z omawianego doświadczenia. Spostrzeżenia te są bardzo pouczające. Okazało się na przykład, że wiele testowanych osób było przekonanych, że wysyłane dane szyfruje się własnym kluczem publicznym. Jeśli się nad tym chwilę zastanowić, to faktycznie istnieje ryzyko popełnienia takiej pomyłki. Początkujący użytkownicy rzadko kiedy rozumieją kiedy używa się klucza publicznego, a kiedy klucza prywatnego. Interfejs użytkownika powinien zawsze jednoznacznie wskazywać, którego klucza należy użyć w konkretnej sytuacji. Dobrym pomysłem jest zastosowanie różnego rodzaju kreatorów, które poprowadzą użytkownika przez proces najczęściej wykonywanych zadań. Podczas generacji klucza można wprowadzić dodatkowe kroki, które stworzą certyfikat unieważniający albo kopię zapasową. A oto pozostałe wskazówki z wyżej wymienionego tekstu:
Bezpieczeństwo jest na ogół sprawą podrzędną. Ludzie chcą przede wszystkim wysyłać i odczytywać pocztę. Nie można zakładać, że użytkownik przeczyta podręcznik albo sam znajdzie opcje dostrajające program do jego potrzeb bezpieczeństwa.
W przypadku komputerów połączonych w sieć obowiązuje zasada najsłabszego ogniwa w łańcuchu. Użytkownik musi zostać poprowadzony przez wszystkie aspekty ochrony prywatności. GnuPG to nie edytor tekstu, albo arkusz kalkulacyjny, w którym na istotne usprawnienia można wpaść przez przypadek.
Terminologia musi być stosowana w sposób konsekwentny. Należy unikać sytuacji, w których raz używane jest słowo ,,szyfrować'', a innym razem ,,kodować''.
Początkujący użytkownicy nie chcą widzieć zbyt wiele. W gąszczu informacji gubią te najważniejsze. Domyślna konfiguracja może się koncentrować na przedstawieniu użytkownikowi właściwego związku między kluczem publicznym i prywatnym. Ponadto potrzebne są elementy umożliwiające pobieranie i wysyłanie kluczy.
Trudniejszym zadaniem jest zaprojektowanie interfejsu służącego do zarządzania kluczami. Model sieci zaufania jest bardzo ściśle wyspecyfikowany. Standard OpenPGP narzuca trzy poziomy zaufania do użytkownika: brak, marginalne i całkowite. Użytkownik nie może sobie dowolnie stopniować zaufania. Algorytm weryfikacji klucza jest również dość skomplikowany dla osób niezwiązanych z informatyką. Wszelka terminologia związana z modelem sieci zaufania jest dla nich niezrozumiała. Dlatego należy wybrać inny sposób prezentacji tych wartości oraz inną metodę ich modyfikacji. Program mógłby przykładowo wyświetlać diagram obrazujący zależność poziomu zaufania kluczy, który zmieniałby się przy każdej zmianie. Wśród innych istotnych spostrzeżeń znalazły się również następujące:
Użytkownicy rzadko wiedzą w jaki sposób bezpiecznie współdzielić sekretne dane. Nie mają również pojęcia, kiedy jest to konieczne.
Bardzo istotne jest aby użytkownik dobrze rozumiał gdzie tkwi sedno jego bezpieczeństwa. Zapobiegnie to dużym stratom wynikającym z drobnych pomyłek. Zaliczyć do nich możemy przypadkowe usunięcie lub zdradzenie klucza prywatnego, unieważnienie własnego klucza, zapomnienie hasła chroniącego klucz lub jego niepoprawne zabezpieczenie.
Dodatek A. GNU Free Documentation License
Version 1.1, March 2000
Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other written document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you".
A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.
A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five).
State on the Title page the name of the publisher of the Modified Version, as the publisher.
Preserve all the copyright notices of the Document.
Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.
Include an unaltered copy of this License.
Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version.
Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.
You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections entitled "History" in the various original documents, forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sections entitled "Dedications". You must delete all sections entitled "Endorsements."
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
How to use this License for your documents
To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:
Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled "GNU Free Documentation License".
If you have no Invariant Sections, write "with no Invariant Sections" instead of saying which ones are invariant. If you have no Front-Cover Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being LIST"; likewise for Back-Cover Texts.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.