Wprowadzenie
W naszym życiu co chwilę podejmujemy różne decyzje na podstawie informacji, które już posiadamy.
Często, ktoś kiedyś powiedział nam coś i od tej chwili traktujemy to jako pewnik.
Chociażby to, że przez przejście dla pieszych można przechodzić jedynie, kiedy sygnalizator świeci się na zielono.
Wiemy to, bo powiedziała nam o tym mama bądź tata lub też nauczyciele w przedszkolu.
No ale skąd mamy pewność, że to prawda?
Czy próbowałeś sprawdzić tą informację?
Cześć! Ja jestem Kacper Szurek, a to podcast Szurkogadanie, w którym opowiadam o bezpieczeństwie w prosty i zrozumiały sposób.
Dzisiaj opowiem o terminie TOFU – czyli "trust on first use".
Na problem ten napotykasz częściej, niż mógłbyś się spodziewać.
Jednym z miejsc, w których on występuje są internetowe komunikatory, wykorzystujące szyfrowanie aby zabezpieczyć prywatność naszych wiadomości.
Dowiesz się co ten termin oznacza, dlaczego jest istotny i jak można rozwiązać problemy, które on generuje.
Jeżeli materiały tego rodzaju Ci się podobają, zapraszam do dołączenia do grupy „od 0 do pentestera” na Facebooku gdzie dzielimy się swoją wiedzą z zakresu bezpieczeństwa.
Podcast ten jest dostępny na YouTube, Spotify oraz Google i Apple Podcast.
A jeżeli wolisz czytać – w opisie znajdziesz link do pełnej transkrypcji nagrania.
Zapraszam do słuchania.
TOFU
TOFU (z angielskiego "Trust On First Use") tłumaczymy na język polski jako „zaufanie przy pierwszym użyciu”.
Mówiąc obrazowo: gdy pierwszy raz uzyskujemy jakąś informację, traktujemy ją jako pewnik, jako fakt - i wykorzystujemy tą wiedzę kolejnym razem.
W informatyce koronnym przykładem może być sytuacja, w której łączymy się z nowym serwerem przy użyciu protokołu SSH.
Oprogramowanie nie zna identyfikatora tego serwera – tak zwanego klucza publicznego.
Pozwala więc zalogować się na ten serwer po raz pierwszy przy użyciu naszego loginu i hasła.
Równocześnie, zapisuje otrzymany od serwera klucz w swojej pamięci.
Od tego momentu, kiedy to ponownie będziemy próbowali się zalogować do serwera – program najpierw sprawdzi, czy zapisany klucz jest identyczny z tym, który przedstawia serwer.
Jeżeli występuje różnica, nie pozwoli na kontynuowanie procedury i wyświetli nam komunikat błędu – oczekując naszej interakcji.
Oznacza to bowiem, że albo ktoś podszywa się pod nasz serwer, albo też serwer ten zmienił swoje dane identyfikacyjne.
Obie sytuacje są nietypowe i potrzebna jest nasza reakcja.
Zielone światło sygnalizatora
W życiu osobistym można to porównać do zapisania w telefonie komórkowym numeru osoby, z którą spotykamy się właśnie twarzą twarz.
Nasz mózg na podstawie obrazu i dźwięku rozpoznaje i identyfikuje daną osobę.
Mamy więc pewność co to jej tożsamości.
Ona to przekazuje nam swój numer – poświadczając, że to właśnie nim będzie się posługiwać podczas dalszych, elektronicznych kontaktów z nami.
Zapisujemy go więc w naszym telefonie i od tego momentu – gdy ta osoba do nas dzwoni, wiemy kim jest – ponieważ jej numer znajduje się w naszych kontaktach.
To podobnie jak z zielonym światłem na przejściu dla pieszych.
Ktoś powiedział nam, że oznacza ono zezwolenie na wejście i od tego momentu wykorzystujemy tą wiedzę poruszając się po ulicach naszych miast.
W tym podejściu występuje jednak jeden problem.
Skąd wiemy, że za pierwszym razem informacja którą otrzymaliśmy jest prawidłowa?
A może ktoś skłamał, żeby narazić nas na niebezpieczeństwo?
Dziennik ustaw
W przypadku sygnalizacji, traktujemy wiedzę jako pewnik – bo otrzymaliśmy ją od kogoś, komu ufamy.
Ale spróbujmy sami zweryfikować tą informację, żeby dostrzec jak poważny może to być problem.
Informacje na temat znaków i sygnałów drogowych znajdują się w Dzienniku Ustaw Rzeczypospolitej Polskiej.
Po krótkich poszukiwaniach trafiamy więc na stronę dziennikustaw.gov.pl gdzie znajdują się wszystkie akty prawne, dostępne w formie elektronicznej.
Ale tutaj napotykamy na pierwszy problem.
Skąd wiemy, że strona ta jest rządowa i znajdujące się tam informacje są prawidłowe?
Przecież nic nie stoi na przeszkodzie, aby ktokolwiek stworzył swój własny rejestr i publikował na nim różne rzeczy.
Jeżeli zajmujesz się informatyką, zapewne kojarzysz, że teoretycznie mówi nam o tym sama domena gov.pl
Abonentami nazw w domenie gov.pl mogą być tylko organy władzy publicznej.
No dobrze. Ale skąd o tym wiemy? Znowu wykorzystujemy wcześniej zdobytą wiedzę.
NASK
Aby potwierdzić tą informację, musielibyśmy sprawdzić regulamin organizacji, która odpowiedzialna jest za rejestrowanie domen w Polsce.
Możesz teraz powiedzieć, że wystarczy wejść na stronę Naukowej i Akademickiej Sieci komputerowej i sprawdzić jej regulamin, bowiem to ona jest odpowiedzialna za polskie domeny.
Tylko skąd ta pewność? Wikipedia w tym przypadku nie jest najlepszym źródłem informacji.
Należałoby potwierdzić gdzieś wyżej, kto jest odpowiedzialny za tą krajową domenę najwyższego poziomu.
Jak widzisz, problemy pojawiają się na każdym kroku.
No ale załóżmy, że rzeczywiście domeny gov.pl należą do organizacji rządowych.
Wiemy, że jesteśmy na właściwej stronie.
Ale Internet to sieć komputerowa, gdzie informacje przepływają pomiędzy różnymi urządzeniami.
HTTPS
Należałoby zatem stwierdzić, czy pobierane przez nas po drodze dane nie zostały w żaden sposób zmodyfikowane.
Służy do tego protokół HTTPS - czyli popularna zielona kłódeczka.
Dzięki niej mamy pewność, że dane pomiędzy naszą przeglądarką, a serwerem rządowym były zaszyfrowane i nie zostały zmodyfikowane.
Niestety, tą witrynę możemy odwiedzać korzystając jedynie ze starego, niebezpiecznego protokołu HTTP.
Wielka szkoda, chociaż gdyby była ona szyfrowana należałoby sobie zadać kolejne pytania.
Każda witryna posiada bowiem swój własny certyfikat.
Jest on wydawany przez urząd certyfikacji, którego zadaniem jest sprawdzenie, czy dany podmiot posiada prawa do posługiwania się daną domeną.
Wtedy to wydaje odpowiednie zaświadczenie – certyfikat – odpowiednio go podpisując.
Każda przeglądarka i system operacyjny posiadają listę głównych urzędów certyfikacji – czyli firm, którym ufają.
Nie mamy wpływu na brzmienie tej listy.
A pytań jest wiele. Skąd wiemy, że organizacja należycie sprawdza wszystkie domeny?
Czy przechodzą odpowiednie audyty bezpieczeństwa?
Kto je przeprowadza? Czy firmy przeprowadzające audyty mają do tego uprawnienia?
I tak dalej, i tak dalej.
Podpisany plik PDF
No ale na poczet tego ćwiczenia załóżmy, że w bezpieczny sposób pobraliśmy obwieszczenie ministra infrastruktury w sprawie znaków i sygnałów drogowych.
Zakładamy tutaj, że po drodze nikt nie zmodyfikował jego treści.
W tym przypadku pobrany plik pdf jest podpisany bezpiecznym podpisem elektronicznym, który pozwala na sprawdzenie tożsamości osoby, która go podpisała, a także integralności znajdujących się w pliku danych.
Na stronie internetowej znajduje się lista osób uprawnionych do podpisywania wyżej wymienionych dokumentów.
Należałoby zatem przy pomocy odpowiedniego oprogramowania zweryfikować treść podpisu.
A tutaj kolejne problemy.
Kwalifikowany podpis elektroniczny wydawany jest na osobę, po uprzednim zweryfikowaniu jej tożsamości.
W Polsce uprawnionych jest do tego kilka podmiotów.
Ich dane znajdują się na stronie Narodowego Centrum Certyfikacji.
Znów należałoby zatem przejść cały proces weryfikacji strony.
No ale załóżmy, że wszystko jest w porządku i rzeczywiście w akcie prawnym znajduje się informacja, że sygnał zielony zezwala na wjazd za sygnalizator.
Pozostaje jeszcze kwestia tego, dlaczego mam ufać rządowi – ale ją pominiemy.
Jak widzisz – na każdym kroku opieramy się na naszej wcześniejszej wiedzy.
Ale dlaczego o tym wszystkim wspominam? Wszak to podcast o bezpieczeństwie.
Klucz publiczny
Temat ten występuje podczas używania bezpiecznych internetowych komunikatorów w stylu Signal czy też WhatsApp.
Urządzenia te szyfrują wiadomości przed ich wysłaniem do Internetu.
Dzięki temu, w teorii są one bezpieczne i nie mogą zostać podsłuchane oraz treść wiadomości nie może zostać zmieniona przez zewnętrzne podmioty.
Dzieje się tak, ponieważ każde urządzenie – czyli zazwyczaj nasz telefon po instalacji generuje swój unikalny klucz prywatny oraz odpowiadający mu klucz publiczny.
Wykorzystując analogię – klucz publiczny jest znany i nie jest tajny.
To trochę tak jak nasz numer PESEL, który jednoznacznie identyfikuje naszą osobę.
Ale do podpisania umowy nie wystarczy jedynie sam PESEL.
Trzeba jeszcze wykonać odpowiedni podpis na dokumencie.
Nasz podpis jest nasz i tylko my wiemy, jak go wykonać.
Teoretycznie ktoś może próbować go podrobić, ale nie jest to takie proste.
Tak samo jak klucz prywatny jest tylko nasz i teoretycznie nigdy nie powinien opuścić naszego urządzenia.
Tylko, że każdy telefon generuje swój klucz prywatny na swoim urządzeniu.
Ale w którymś momencie dochodzi do komunikacji pomiędzy dwoma osobami.
W placówce banku podczas zakładania nowego konta, pracownik prosi nas o dowód a następnie porównuje informacje w nim zawarte z naszą twarzą.
Następnie wykonujemy wzór podpisu na karcie podpisu.
Dzięki niej bank wie, jak wygląda nasz podpis i może go weryfikować podczas kolejnych wizyt w oddziałach.
Kod zabezpieczenia
Ale jak to wygląda w przypadku czatów?
Zazwyczaj w aplikacji podajemy numer telefonu przyjaciela, a następnie rozpoczynamy rozmowę.
Cała ta kryptografia i matematyka dzieją się w tle bez naszej wiedzy.
Jeżeli jesteś jednak bardziej zaawansowanym użytkownikiem, możesz sprawdzić te dane w szczegółach kontaktu.
W przypadku Signal znajdują się one w szczegółach kontaktu pod zakładką „Pokaż kod zabezpieczenia”.
Tam to widnieje kod QR, a także długi ciąg liczb.
Jest tam również informacja: "By zweryfikować bezpieczeństwo połączenia z kontaktem należy porównać powyższy numer z numerem wyświetlanym na telefonie kontaktu".
Czyli teoretycznie należałoby się spotkać na żywo, sprawdzić swoje tożsamości i porównać numery wyświetlane przez aplikację.
Dopiero wtedy pokładając wiarę w matematykę, teoretycznie nasza komunikacja jest bezpieczna.
Tylko, że mało kto tak robi.
Reinstalacja aplikacji
Jeszcze większe zamieszanie pojawia się w momencie, kiedy to nasz przyjaciel z różnych przyczyn albo zainstalował ponownie aplikację, albo też zmienił telefon.
Wtedy to jego kod zabezpieczenia się zmienił – wszak nowy telefon to nowe urządzenie, a jak wcześniej wspominałem, ono to generuje swój własny, unikalny klucz.
W tym momencie w interfejsie aplikacji wyświetlany jest odpowiedni komunikat, z którego dowiadujemy się, że kod zabezpieczenia osoby po drugiej stronie się zmienił i aplikacja nie możne zapewnić, że komunikacja jest prywatna.
Wszak od strony programistycznej nie jest możliwe rozróżnienie, czy użytkownik zmienił telefon na nowy, a może ktoś próbuje wykonać atak „man in the middle” i podszyć się pod drugą osobę.
Aby być ponownie pewnym komunikacji, należałoby spotkać się raz jeszcze na żywo i porównać nowe identyfikatory.
Tylko, że kto tak robi?
Problem ten jest jeszcze ciekawszy jeżeli weźmiemy pod uwagę grupowe czaty, w których udział bierze kilkunastu uczestników.
Wtedy prawdopodobieństwo, że któryś z nich zmieni telefon, zgubi go lub po prostu zainstaluje aplikację na nowo - jest spore.
A teoretycznie, po każdej takiej sytuacji każdy z uczestników czatu powinien spotkać się sam na sam z osobą, której kod się zmienił i ponownie go zweryfikować.
W innym wypadku nie wiadomo, czy czasem nowy kod nie należy do kreta – czyli osoby podszywającej się pod kogoś innego.
Na nic wtedy szyfrowanie – wszak nasze wiadomości trafiają na telefon kogoś innego.
Jak zatem rozwiązać ten problem?
Siatka kontaktów
Parę lat temu jeżeli ktoś korzystał z szyfrowania w Internecie najprawdopodobniej używał GPG – wolnego oprogramowania kryptograficznego.
Wtedy to generował swój klucz i umieszczał jego część publiczną na specjalnych serwerach kluczy.
Każdy kto chciał się z nim komunikować w bezpieczny sposób, mógł odszukać jego klucz bazując na adresie email, a następnie wykorzystać go do zaszyfrowania komunikacji.
Tylko, że tutaj pojawiał się pewien problem.
Dane do serwerów kluczy może wysłać każdy.
Nikt nie weryfikuje poprawności tych danych.
Co za tym idzie, w spisie może znajdować się wielu Janów Kowalskich z tym samym adresem email.
Skąd więc wiedzieć, który z nich jest tym naszym?
Wszak nie chcemy użyć czyjegoś klucza.
Postawiono na metodę starą jak świat – czyli siatkę kontaktów.
Jak zazwyczaj poznajemy nowe osoby w świecie realnym?
Poprzez polecenie.
Podchodzimy wraz z naszym kolegą do nowej osoby, następnie zostajemy przedstawieni i rozmowa toczy się dalszym rytmem.
Nasz nowy kolega ufa nam ponieważ zostaliśmy przedstawieni przez osobę, którą on zna.
Analogicznie wygląda to z naszej strony.
Ujmując to w inne słowa: kolega naszego kolegi jest naszym kolegą.
Key signing party
Umożliwiono więc podpisywanie kluczy publicznych innych osób.
W teorii miało to wyglądać tak: różne osoby spotykają się na tak zwanych "key signing party".
Następnie weryfikują swoją tożsamość oraz odcisk klucza publicznego.
Po powrocie do swoich domów, każdy z uczestników podpisuje klucz publiczny osób z którymi się spotkał wykorzystując swoje dane.
Zaświadcza zatem, że według jego najlepszej wiedzy osoba X posługuję się kluczem Y.
Teraz sytuacja poszukiwania klucza wygląda nieco inaczej.
Jeżeli my ufamy osobie Z, a ona twierdzi, że X posługuje się kluczem Y – to wykorzystując tą relację możemy z dużą dozą prawdopodobieństwa stwierdzić, że rzeczywiście X posługuje się kluczem Y.
Im więcej naszych znajomych, którym ufamy, twierdzi tak samo – tym nasze zaufanie wzrasta.
Niestety, takie rozwiązanie słabo się skaluje i jest dość niszowe.
Ilu Twoich znajomych bowiem korzysta z GPG i było na spotkaniu, które miało służyć wymianie kluczy?
Jak zatem do tematu podchodzą nowe komunikatory?
Keybase
Keybase1, dla przykładu, wspiera wiele urządzeń równocześnie.
Kiedy korzystamy z nowego telefonu, musimy potwierdzić ten fakt przy pomocy jednego z wcześniej używanych przez nas urządzeń.
Zakłada się tu bowiem, że wszystkie nasze urządzenia nie są skompromitowane i nikt obcy nie posiada do nich dostępu.
Dzięki takiemu podejściu do tematu, sytuacja w której uczestnik konwersacji korzysta z nowego urządzenia nie prowadzi równocześnie do zmiany jego kodu bezpieczeństwa.
Potwierdził on bowiem na innym urządzeniu, że to jego telefon.
Jedyny moment gdy kod się zmieni występuje wtedy, kiedy to zgubi wszystkie swoje urządzenia.
Potencjalne rozwiązanie problemu
No dobrze, ale co zrobić, jeżeli nasz kontakt znajduje się daleko od nas i nie ma szans na kontakt na żywo?
Wszystko zależy od tego na jakie ustępstwa jesteśmy w stanie pójść.
W większości domowych zastosowań, wystarczy rozmowa telefoniczna, w której na podstawie głosu potwierdzimy naszego rozmówcę i jego kod.
Równie dobrze nada się telekonferencja przez Skype.
Można również rozpocząć rozmowę zaczynając ją od pytania, na które odpowiedzi teoretycznie zna jedynie osoba po drugiej stronie łącza.
Jak to mówią: nie zawsze trzeba strzelać z armaty do mrówki.
Warto jednak wiedzieć, jak działają aplikacje z których korzystamy na co dzień.
Tylko wtedy bowiem możemy świadomie podejmować ryzyko - wiedząc co ono tak naprawdę oznacza.
