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> |
Klucz publiczny jest wyświetlony wraz z informacją o dostępności odpowiadającego mu klucza prywatnego. Każdy wiersz opisu klucza publicznego ma następujący format. Skrót
pub oznacza, że jest to główny klucz podpisujący, zaś
sub oznacza publiczną część klucza podrzędnego. Druga kolumna zawiera długość, typ i identyfikator klucza. Typ
D oznacza DSA,
g klucz ElGamala służący wyłącznie do szyfrowania, a
G klucz ElGamala służący zarówno do szyfrowania jak i podpisywania. Data utworzenia i wygaśnięcia umieszczone są w kolumnach trzeciej i czwartej. Identyfikatory użytkownika są wymienione poniżej kluczy.
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 |
Format jest taki sam, jak w przypadku klucza publicznego. Skrót
sec oznacza prywatną część głównego klucza podpisującego, a
sbb prywatne części klucza podrzędnego. Dla wygody użytkownika wyświetlane sa także identyfikatory użytkownika.
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] |
Zgodnie z intuicją kluczem podpisującym jest główny klucz o identyfikatorze
0x26B6AAE1. Autopodpisy na publicznych częściach kluczy podrzędnych nie są wyświetlane w interfejsie programu GnuPG.
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.
Jeśli Alicja ufa Blake'owi, że właściwie potwierdza poprawność podpisywanych kluczy, to może założyć, że klucze Chloe i Dharmy są poprawne i nie musi ich potwierdzać. Używa swojej kopii klucza publicznego Blake'a do sprawdzenia poprawności jego podpisu na kluczach Chloe i Dharmy. Jeśli więc Alicja całkowicie ufa innym, że sprawdzają poprawność podpisywanych kluczy, to każdy klucz podpisany poprawnym kluczem jest poprawny. W korzeniu drzewa znajduje się klucz Alicji, który automatycznie uznajemy za poprawny.
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.
Poziom zaufania jest zupełnie osobną informacją właściwą jedynie dla osoby, która go ustala. Nie jest on umieszczany w eksportowanych kluczach i nawet przechowywany jest osobno od bazy danych kluczy.
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
[...] |
Poziom zaufania wyświetlany jest po prawej stronie. Pierwsza litera oznacza zaufanie do właściciela klucza, a druga oznacza poprawność klucza. Cztery poziomy zaufania oznacza się literami: unknown (
q), none (
n), marginal (
m) i full (
f). W powyższym przykładzie klucz Blake'a oznaczony jest literą f, ponieważ Alicja go podpisała. Początkowo jej zaufanie do Blake'a jest nieznane, ale decyduje się na przyznanie mu zaufania marginalnego.
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
Długość ścieżki, liczba wymaganych użytkowników o zaufaniu marginalnym i liczba wymaganych osób o pełnym zaufaniu mogą być zmieniane. Powyżej podane wartości są domyślnie używane w GnuPG.
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.
Rysunek 3-1. Przykładowa sieć zaufania
| zaufanie | poprawność |
| marginalne | pełne | marginalna | pełna |
| |
Dharma |
|
Blake, Chloe, Dharma, Francis |
| Blake, Dharma |
|
Francis |
Blake, Chloe, Dharma |
| Chloe, Dharma |
|
Chloe, Francis |
Blake, Dharma |
| Blake, Chloe, Dharma |
|
Elena |
Blake, Chloe, Dharma, Francis |
| |
Blake, Chloe, Elena |
|
Blake, Chloe, Elena, Francis |
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) |
Jest kilka popularnych serwerów kluczy na całym świecie. Najważniejsze serwery synchronizują się, więc można wybrać znajdujący się najbliżej i regularnie z niego korzystać.
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.
Dobrze dobrany rozmiar klucza chroni użytkownika przed atakami typu brute-force. Ochrona własnego klucza prywatnego zabezpiecza przed bezpośrednim użyciem klucza do odszyfrowywania wiadomości i podpisywania dokumentów w imieniu właściciela. Odpowiedzialne zarządzanie siecią zaufania utrudnia atakującemu podszycie się pod zaufaną osobę. Odpowiednie podejście do wszystkich tych zagadnień wymaga wypośrodkowania między bezpieczeństwem i wygodą stosowania GnuPG.
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.
Menu
