GPG: co poszło nie tak?

dodał 12 lipca 2019 o 21:10 w kategorii Błędy, Krypto  z tagami: • • •
GPG: co poszło nie tak?

Kochani, szanujmy idealistów. To ginący gatunek. Szanujmy ludzi, którzy zobaczyli ważny temat i postanowili poświęcić bardzo wiele, żeby go zrealizować. Idealistów nie brak również w kryptologii. Na przykład idealistów antysystemowych.

Na celowniku idealistów w kryptologii znalazł się system zaufania oparty na hierarchii, a więc kryptografia klucza publicznego (PKI). Kto ma decydować, któremu certyfikatowi mam zaufać? Czy ja ufam samemu dostawcy zaufania? Starożytny problem „quod custodet ipsos custodes” (czyli kto pilnuje tych, co pilnują) w nowej odsłonie. Korzenie PKI, podobnie jak korzenie internetu, wyznaczają mi, komu ufam, a komu nie. Oczywiście mogę sobie powołać swój system PKI, ale czynności niezbędne do tego, żeby we wszystkich przeglądarkach i klientach pocztowych zobaczyć magiczną zieloną kłódeczkę nie należą może do najtrudniejszych, ale i nie do najprostszych.

Zatem system hierarchiczny działa i pozdrawia wszystkich, poza złośliwcami w rodzaju Daniela J. Bernsteina, który publicznie demonstruje, że kryptografia kluczy asymetrycznych nie zawsze jest tak asymetryczna, jak byśmy sobie wyobrażali i że faktoryzacja klucza publicznego 184 obywateli Tajwanu nie wymaga zasobów obliczeniowych na poziomie NSA. Albo klucza GPG takiego dużego gościa, co podpisuje kod jądra Linuksa. To ostatnie nie wymagało zresztą GPU, wystarczyło podzielić przez 3, a to każdy potrafi, nawet bez komputera kwantowego, którego widmo też jest dla kryptografii klucza asymetrycznego niejakim bólem głowy. No i jak ktoś nie odróżnia liczby pierwszej od liczby drugiej (bo chyba tak można nazwać iloczyn liczb pierwszych), no, to już jego problem.

Odpowiedzią na zwycięski marsz PKI przez światowe IT był rozpoczęty przez idealistów kontrmarsz pod nazwą gatunkową: rozproszony system zaufania (web of trust). Jeśli ja znam Scotta Hansena, a Scott zna jedną Julię z accountów i za nią ręczy, bo to fajna babka, to ja podpiszę jemu, on podpisze Julii i szafa gra. Oczywiście, jak długo wiemy komu podpisujemy. I już nie będzie rząd federalny pluł nam w twarz ni dzieci nam uwierzytelniał, sami sobie uwierzytelnimy.

Aktualizacja potencji

Byt według św. Tomasza składa się z potencji i aktu (między innymi) i byt tego bytu to ciągła aktualizacja potencji. Żeby przejść do konkretu i zaktualizować swoją potencję, idealiści usiedli do klawiatur. I w idealnym akademickim świecie powstał piękny przemysłowy system PGP (pretty good privacy). Ponieważ jednak każdy musi jeść, musiał i Philip Zimmerman i po paru latach skończyło się open source i zaczęła byt rynkowy wersja własnościowa, obecnie w Symantecu. A system open source trzeba było napisać od początku, za co wzięła się ekipa GnuPG, wspierana m.in przez rząd Niemiec, który też nie lubi, jak mu wszystko czyta NSA. Za to otwarty standard OpenPGP RFC 4880 został zamrożony karbonitem, aby już każdy mógł go zmonetyzować, za to nikt przewłaszczyć.

Model zaufania w OpenPGP opiera się na koncepcji sieci zaufania (web of trust). Przypuśćmy, że chciałbym wysłać poufny mail do Julii z accountów, że strasznie mi się podoba i może się umówimy? No, ale chciałbym mieć pewność, że Julia to Julia, bo rozumiecie sami – sprawa jest delikatna.

Dlatego nurkuję na serwery PGP takie jak pgp.mit.edu, gdzie każdy może (jeśli tylko mu serwer odpowie ;-) ) i patrzę, czy Julia nie zostawiła gdzieś swojego klucza. Znajduję klucz Julii i patrzę, kto go podpisał. I patrzę, że Scott, a Scott to mój dobry kumpel i jego certyfikatowi ufam bezwarunkowo, bo mi go sam dał (to znaczy wydrukowany odcisk klucza, zgodnie z netykietą key signing party, a ja go sobie ściągnąłem z serwera i włączyłem do swojego lokalnego repozytorium kluczy i szafa gra. No to ściągam certyfikat Julii i piszę: Cześć Julka, fajna jesteś i wszystko, co się w takich okolicznościach pisze. Jeśli od prezydenta USA dzieli mnie sześć uścisków dłoni, to zapewne również 6 certyfikatów. Jeśli ktoś wklei certyfikat, który jest zatruty, to wklei, bo mu wolno, ale nikt mu nie zaufa.

Sieć zaufania: zasada działania

Po skalowaniu ich systemów poznacie ich, jak mówi dobra księga. Ile osób może podpisać certyfikat? Tyle, ile potrzeba. Dowolna liczba. Bez ograniczeń. Każdy podpis do certyfikatu działa jak każdy podpis: szyfruję swoim kluczem prywatnym odcisk klucza Scotta, a do jego pliku certyfikatu dołącza się kolejny fragment, zawierający dane mojego klucza publicznego i mój odcisk.

Jak zwykle w kryptografii asymetrycznej, nic mnie nie chroni przed kolizją. Jeśli w zaciszu mojego peceta wygeneruję klucz, który jakimś cudem jest równoważny kluczowi prezydenta USA – to wow! mam jego klucz prywatny.

To akurat w świecie kluczy nic nowego; rozmiar przestrzeni kluczy Yale to nie więcej niż 100.000, bo jeszcze są sekwencje zabronione, a zamków typu Yale jest na świecie znacząco więcej. Czyli mam w kieszeni klucz do milionów zamków na całym świecie. Problem jedynie w tym, że nie wiem do których.

Z uwagi na liczbę podpisów, certyfikat/klucz publiczny Scotta trochę puchnie, ale za to wiem na pewno, że Scott to Scott. Nawet w internecie. Chyba że ktoś zfaktoryzował klucz publiczny umieszczony w jego certyfikacie.

Jeśli Scott postanowi upublicznić swój klucz, wybiera sobie serwer należący do dowolnej sieci zaufania (zapisuje też w certyfikacie, który to) i tam wrzuca swój certyfikat i teraz już każdy może zaszyfrować mail do Scotta. A zwłaszcza ta jędza Julia, bo skąd mogłem wiedzieć, że ona woli blondynów takich jak Scott.

Jeśli Scott utraci kontrolę nad kluczem, to nic prostszego, wysyła do tego samego serwera klucz odwołujący swój certyfikat (revoke) i serwer odtąd pokazuje, że ten klucz Scotta jest wycofany. Przy czym zasada jest taka, że nic nie usuwamy. Oznaczamy tylko jako nieważne.

Jeśli chcę być superbezpieczny albo jestem bardzo podejrzliwy, chciałbym w chwili wysyłania maila do Scotta wiedzieć, czy sam Scott nadal uważa, że jego klucz jest bezpieczny. Dlatego przed wysłaniem sprawdzam na serwerze, którego adres jest zapisany w certyfikacie, czy czasem Scott nie odwołał swojego klucza. Ajajaj, odwołał, lipa, ściągam nowy klucz Scotta, bo stary złamało NSA.

Sieć zaufania: diabeł tkwi w szczegółach

W jakich szczegółach? W dwóch. Pisze o tym Hansen, ale nie Scott, tylko Robert. I widać, że idealistów zgubił ich własny idealizm, a to poznać można po dwóch zongach. Pierwszy zong: nie ograniczamy liczby podpisów. Jeśli Julia chce mieć klucz podpisany przez – dajmy na to – 100.000 osób, bo jest niezwykle popularna i zawsze, jak się umawia z kimś na kawę, to w dowód zaufania podpisują sobie klucze, to ma takie prawo. Jeśli Julia ma ochotę wysłać swój klucz na serwer, to wysyła. Serwer taki klucz przyjmie. I tu drugi zong: z serwera nigdy przenigdy nie da się zdalnie usunąć klucza. To jest wbrew regułom. Lokalnie się da, ale nie jest to proste i wymaga fizycznego dostępu do maszyny, mocy super krowy, no i żeby nie było innych serwerów w sieci, bo można skonfigurować serwery tak, żeby się synchronizowały, bo rozproszone są bezpieczniejsze. Trzeba więc wyłączyć synchronizację, usunąć na wszystkich, a następnie włączyć synchronizację. Wiemy to od 11 lat, ale it’s not a bug, it’s a feature, co nie?

Hansen pisze o przyczynach: a co jeśli przyjdzie NSA i poprosi grzecznie (NSA zawsze prosi grzecznie), żeby zamiast klucza jakiegoś złego bandyty podstawić swój klucz tak, żeby zawsze mogli odczytać, co kto do niego pisze? No, to procedura jest taka, że usuwamy jeden i wstawiamy drugi klucz.

No i właśnie tego się nie da zrobić, a w przypadku serwerów zsieciowanych jest to trudno zrobić nawet z fizycznym dostępem do maszyn.

I teraz clue programu: GnuPG wywala się na kluczu o 100.000 podpisów. Permanentne DoS. Kto nie wierzy, niech sprawdzi tu i tu.

Jeśli trujący klucz rozprzestrzeni się po serwerach, nie da się go usunąć, a każdy, kto go załaduje, właśnie sobie zbrickował lokalny pęk kluczy, zarządzany przez GnuPG. I musi sobie zresetować sieć zaufania i zacząć zbierać od początku. Chyba że GnuPG opublikuje jakieś obejście.

W każdym razie Hansen życzy łobuzowi, który zatruł jego klucz, wszystkiego najgorszego i chyba trudno mu się dziwić. I doradza nam wszystkim wyłączenie usługi sprawdzania serwerów kluczy w lokalnych instalacjach GnuPG. Czyli wracamy do jaskini albo przesyłamy klucze kurierem.

Czy to wszystko

Niestety nie. Wątpliwości wokół GnuPG jest więcej. Technologia jest fajna, jest za darmo (choć nie jak piwo za darmo), dorobiła się rozszerzenia na smartcardy i na Yubikey.

Po pierwsze, integracja.

Integracja z systemami operacyjnymi jest trudna i wymaga mocy super krowy. Na temat tego, jak zapisać nazwę czytnika kart w GnuPG, żeby konkretna wersja Windowsa go z nim połączyła, można napisać oddzielny podręcznik. Integracja z MIME ma podatności, o czym można przeczytać tu i tu.

Po drugie, utrzymanie.

Jak coś jest za darmo, nie wypada narzekać, ale jak nie wypada narzekać, a używać się nie da, to się forkuje, a potem dyskutuje. Kod GnuPG to 480 kLOC w języku C (bez ++). O jakości kodu nie chcę się wypowiadać, bo całego nie widziałem, ale złożoność od strony potencjalnego użytkownika oraz jakość materiałów informacyjnych nie zachęca, zwłaszcza liczba opcji konfiguracyjnych opatrzonych jednozdaniową dokumentacją, bez przykładów użycia. Z kolei Hansen, pisząc o serwerze kluczy SKS, nie ukrywa, że serwer kluczy powstał jako praca doktorska w OCamlu (tak, ktoś w tym pisał!). I że jest nieutrzymywalny (można go ewentualnie cokolwiek upudrować). I wprawdzie powstaje zamiennik, dla odmiany w Ruście (TF, dzięki za link) ale jeszcze nie wyszedł z alfy. Aaaa, nawet z aaalfy.

Po trzecie, co myśli prosty użytkownik.

Ot, taka sekwencja zdarzeń, z życia wzięta. Jeśli a) próbujesz załadować do lokalnego pęku kluczy nowy klucz publiczny lub prywatny, używając linii komend i b) nie dostajesz żadnego komunikatu błędu, za to c) klucza w pęku nie ma, to może sprawdź, czy ktoś przypadkiem nie przestawił uprawnień do plików, bo jeśli twój użytkownik nie ma praw zapisu do nich, to niestety nic się tam nie zapisze. I od gpg2 na pewno się o tym nie dowiesz, bo jest w końcu interfejsem do szyfrowania i jako taki musi być niezwykle dyskretny.

To nie jest jedyny przykład, a wszystkie opiszę kiedyś w książce, już nawet wymyśliłem tytuł, będzie się nazywać Mein Kampf. Muszę tylko sprawdzić, czy domena jest wolna.

Zresztą wystarczy zobaczyć, ile ostrzeżeń zawierają strony przeznaczone dla tych, którzy GPG biorą na poważnie – i takich tutoriali jest w sieci wiele.

Po czwarte, podatności.

O kilku już wspomniałem przy okazji integracji. Problemy na styku z MIME są raczej problemami w sposobie wyświetlania zawartości MIME i tu nie byłoby uczciwie wszystkie psy powiesić akurat na PGP, ale to nie wszystko. Jeśli chcesz ograniczyć liczbę podatności, zrób audyt kodu. O audycie kodu GnuPG rzeczywiście była mowa, ostatnio w 2013. Nie znalazłem w sieci śladów po tym, że taki audyt został zrobiony, chyba że przez Bundesamt fuer Sicherheit in der Informationstechnik. Bo to droga impreza przy takiej skali. O raczej niezbędnych dla zwykłego użytkownika dodatkach sami autorzy inicjatywy OpenPGP piszą, że ich nie autoryzują, więc każdy audytuje się na własną rękę.

Podatności generuje także model użycia. W certyfikacie można dodawać ID po jego wygenerowaniu. Dodać kolejny adres mailowy, dzięki czemu można nim obsłużyć kolejne konto. Można też zmienić datę ważności, nawet jeśli ona już minęła. Ten klucz żyje w czasie i takie było jego założenie projektowe.  Jakby tego było mało, krótkie odciski klucza (32 bity) umożliwiają kolizje. Jakby tego było mało, domyślna opcja to słabe krypto. Jeśli ktoś ustawi w kluczu kombinację MD5 + 3DES: proszę bardzo. Taki 3DES jest domyślnie dopuszczony (jakby ktoś zapomniał, rok mamy 2019). Jest tego więcej, jeśli ktoś chciałby się zagłębić.

A sprawę podsumowuje lista darczyńców i wpłat oraz lista deweloperów.

Najlepszy komentarz do niej wygłosił Winston Churchill (jak tylko ją przeczytał ;-) ). Powiedział mianowicie, że nigdy w historii konfliktów międzyludzkich tak wielu nie zawdzięczało tak wiele tak nielicznym.

Co robić, jak żyć

Zwięzłe wnioski. Mimo wszystko GPG jest standardem dość rozpowszechnionym. Zwłaszcza jego najbardziej rozwinięta i rozpowszechniona wolna implementacja GnuPG. Technologia OpenPGP używana jest zwłaszcza w branży security, której bardzo odpowiada zdecentralizowany model zaufania. Ale zważywszy na powszechność standardu, zbyt skromne są wysiłki społeczności open source na rzecz zapewnienia bezpieczeństwa kodu GnuPG i SKS. Może dlatego, że nikt za nie nie płaci. Tu i ówdzie pojawiają się również uwagi o problemach w komunikacji z zespołem GnuPG. Dyskusyjne są założenia projektowe (idealizm założeń doprowadził do poważnych wad projektowych), nie mówiąc już o utrzymywalności, o której piszą jawnym tekstem sami zainteresowani, a także o walorach użytkowych, o której można poczytać na forach. Bieżący problem można rozwiązać, blokując użyteczną funkcję, jaką jest kontrola kluczy przed wysłaniem (robi się to przez komendę level paranoid=off). Ale chyba warto zastanowić się, co dalej z tym standardem, bo chyba mamy problem, Houston.

Autorem artykułu jest Teodor Buchner, R&D Exatel, Wydział Fizyki Politechniki Warszawskiej, członek ISSA.

Podobne wpisy