Wstęp
Internet traktujemy jako coś oczywistego.
Żeby z niego korzystać nie musimy znać się na wszystkich protokołach, algorytmach i technologiach w nim wykorzystywanych.
Pamiętajmy jednak, że za tym wszystkim stoją ludzie i często ciekawe historie.
Dzisiaj opowieść o kilku osobach, które posiadają klucz do Internetu.
Nie chodzi tutaj o fizyczne klucze do zamków, a klucz prywatny, który wykorzystywany jest w protokole DNSSEC.
W tym odcinku wyjaśnię co to jest DNS a także dlaczego powstało jego rozszerzenie - DNSSEC.
Później spróbuje na przykładzie analogi do podpisywania umowy wyjaśnić na czym polega i jaka jest jego istota.
Na końcu, opis spotkań grupy osób "trzymających władzę" nad Internetem.
O tym jak wygląda ceremonia podpisywania kluczy, która odbywa się raz na kilka miesięcy.
Czemu ona służy, jak wygląda a także kto bierze w niej udział.
Materiał ten podzielony jest na 2 części.
Pierwsza techniczna, druga fabularna.
Adres IP
Żeby zrozumieć dzisiejszy temat musimy zacząć od początku.
Na świecie jest wiele komputerów podłączonych do Internetu.
Należało zatem wymyślić metodę, która umożliwiała by dokładną ich identyfikację.
Wymyślono coś podobnego do adresów ulic i numerów domów i mieszkań.
Każdy komputer podłączony do sieci posiada swój unikalny adres IP.
To właśnie na jego podstawie urządzenia sieciowe wiedzą, gdzie wysłać nasze żądanie aby trafiło one do odpowiedniego miejsca.
Adres IP jest liczbą.
Nie od dzisiaj jednak wiadomo, że my jako ludzie zdecydowanie lepiej zapamiętujemy wyrazy niż niepowiązane ze sobą cyfry.
Tak narodził się DNS.
On to zamienia zrozumiałą dla nas nazwę domeny - dla przykładu szurek.pl na adres IP, który jest z nią powiązany.
Dzięki takiemu rozwiązaniu wszyscy są szczęśliwi.
Ludzie - łatwiej zapamiętują adresy a komputery otrzymują odpowiedni numer, z którym mogą się połączyć.
ICANN
No ale, żeby to wszystko działało musi istnieć jakiś organ nadzorczy, który sprawuje piecze nad przyznawaniem nazw.
Tak jak w normalnym życiu.
Nie powinniśmy bowiem dopuścić do sytuacji, w której dwa różne budynki mają ten sam numer i nazwę ulicy.
Podobnie tutaj - konkretna domena powinna należeć tylko do jednej osoby, bądź organizacji.
Tak powstał ICANN czyli Internetowa Korporacja ds. Nadanych Nazw i Numerów.
Jest to instytucja odpowiedzialna obecnie za przyznawanie nazw domen internetowych, ustalanie ich struktury oraz za ogólny nadzór nad działaniem serwerów DNS na całym świecie.
Domena najwyższego poziomu
DNS jest bowiem hierarchicznym systemem.
Co to oznacza?
Różne podmioty są odpowiedzialne, za różne poziomy domeny.
Rozpatrzmy to na przykładzie domeny security.szurek.pl
PL to domena najwyższego poziomu.
Zazwyczaj jest to kod kraju - na przykład pl dla Polski czy też de dla Niemiec.
Może to być również domena funkcjonalna.
edu oznacza zatem jakąś instytucje oświatową a gov stronę należącą do agencji rządowych.
Za domeny najwyższego poziomu (w tym tworzenie nowych końcówek) odpowiedzialny jest ICANN.
Ale już za wszystkie domeny z końcówką .pl odpowiedzialny jest NASK.
Wszystko co znajduje się po nazwie domeny, czyli po szurek.pl odpowiedzialny jest jej właściciel.
To właśnie dzięki temu w obrębie jednej domeny mamy do czynienia z wieloma subdomenami.
No dobrze, wiemy jak wygląda nazwa domenowa.
DNS
Ale jak działa wyszukiwanie adresu IP serwera?
Wpisując w oknie przeglądarki naszą nazwę - system przesyła nasze zapytanie do serwera DNS, zapisanego w naszym systemie.
Może to być serwer DNS naszego dostawcy Internetu lub też jeden z generycznych serwerów - 1.1.1.1 należący do Cloudflare czy też 8.8.8.8 należący do Google.
No ale skąd taki serwer ma wiedzieć, jaki adres IP ma każdy komputer w Internecie?
Odpowiedź jest prosta.
Nie wie - musi o to zapytać inne serwery.
Zaczyna więc dopytywać o naszą domenę.
Najpierw wysyła żądanie do jednego z serwerów głównych, odpowiedzialnych za obsługę domen najwyższego poziomu.
W przypadku security.szurek.pl - serwer ten zwróci adres adres IP serwera, odpowiedzialnego za domenę pl.
Serwer DNS wyśle zatem kolejne zapytanie, tym razem do serwera odpowiedzialnego za domeny pl.
Otrzyma kolejny adres IP, na którym znajdują się informację na temat domeny szurek.pl
W ostatnim żądaniu - serwer wysyła zapytanie do autoratywnego serwera - w którym znajdują się wszystkie informacje na temat subdomen domeny szurek.pl
W taki oto sposób, uzyskaliśmy adres serwera IP odpowiedzialnego za obsługę konkretnej domeny.
Ten to adres jest przesyłany do przeglądarki, która to wysyła swoje żądanie w odpowiednie miejsce.
Cache
Z tego prostego przykładu widać, że sprawdzenie jednego, konkretnego adresu nie jest takie proste jak mogło by się wydawać.
Dlatego też, wszyscy więksi usługodawcy przetrzymują informacje na temat domen w pamięci podręcznej.
Możemy bowiem spokojnie założyć, że sporo osób dziennie potrzebuje znaleźć adres IP serwera google.pl
Serwer DNS - za każdym razem musiał by wysłać żądania do kilku serwerów - aby otrzymać odpowiedź.
Jest to nieefektywne, dlatego też dane te są przetrzymywane w pamięci cache.
O tym jak długo serwer przechowuje informację o adresie IP bez ponownego ich sprawdzania odpowiedzialny jest parametr TTL.
Również sam system operacyjny przechowuje te informacje w pamięci naszego komputera.
Dzięki temu jeżeli tego samego dnia ponownie będziemy chcieli wejść na tą samą stronę, nie musimy wykonywać całej czynności od nowa.
Man in the middle
No dobrze, podstawy mamy za sobą.
Tylko, że DNS ma jeden problem.
Jest on podatny na atak "man in the middle".
Polega on na tym, że ktoś podszywa się pod nasz serwer DNS i zwraca nam fałszywe odpowiedzi na nasze prośby.
Przykład?
Wyobraź sobie, że korzystać z sieci wifi na lotnisku.
Wtedy to potencjalny atakujący, może podszyć się pod serwer DNS i zwrócić adres IP należący do niego.
Jeżeli nie korzystamy z protokołu https - nasz ruch zostanie przekierowany do złego, potencjalnie złośliwego serwera.
Dzieje się tak - ponieważ serwer DNS zwraca jedynie informacje na temat adresu IP komputera.
Ale te informację nie są w żaden sposób podpisane i nie możemy zweryfikować ich poprawności.
DNSSEC
I właśnie ten problem doprowadził do powstania DNSSEC.
Teraz, każda odpowiedź z serwera jest podpisana.
Możemy zatem sprawdzić, czy zwracane wartości są prawidłowe.
Ale jak to działa?
Wcześniej wspominałem, że DNS jest hierarchiczny.
Kto zatem jest odpowiedzialny za podpisywanie tych informacji?
Prześledźmy, jak wygląda implementacja protokołu.
DNSSEC to rozszerzenie systemu DNS.
Chodziło o to, aby nie wprowadzać zupełnie nowego protokołu, ponieważ istniała spora szansa, że by się nie przyjął.
Zamiast tego rozszerzono stary o nowe możliwości.
Jeżeli Twój komputer obsługuje DNSSEC - będziesz z niego korzystał.
Jeżeli nie, wszystko pozostaje po staremu.
Rekordy
DNS opiera się na rekordach.
Każdy rekord ma odpowiedni typ oraz wartość.
Najpopularniejszy typ to rekord A - określający adres IPv4 serwera.
Dalej możemy mieć rekord MX - wskazujący nazwę serwera obsługującego pocztę elektroniczną.
Dlaczego o tym wspominam?
W normalnym życiu, gdy chcemy być czegoś pewni - tworzymy umowę - czyli zespół kartek a następnie ją podpisujemy.
Podobnie tutaj.
Rekordy tego samego typu grupujemy w RRsets i taki ciąg danych podpisujemy.
Nie chcemy podpisywać pojedynczych rekordów - było by to po prostu nie optymalne.
Ten podpis znajduje się w nowym typie zwanym RRSIG.
Ale sam podpis nie wystarczy do jego zweryfikowania.
Nie wszyscy z nas podpisują się imieniem i nazwiskiem.
Niektóre podpisy są bardzo dziwne i ciężko doczytać się do kogo tak naprawdę należą.
Dlatego też w umowach, zazwyczaj nad podpisem drukuje się imię i nazwisko osoby.
W cyfrowym świecie taką funkcję pełni publiczna część klucza, która musi być dostępna dla wszystkich.
Klucz bowiem składa się z dwóch części - prywatnej i publicznej.
Podobnie jak w normalnym życiu.
Każdy z nas może zobaczyć wykonany podpis - czyli jego publiczną część.
Ale tylko właściciel podpisu ma wyrobioną odpowiednia pamięć mięśniową, która pozwala mu na wykonanie tego zadania.
Możemy próbować podszyć się pod właściciela, ale zazwyczaj takie próby kończą się mizernym efektem.
Mamy zatem część prywatną - znaną tylko serwerowi oraz część publiczną przechowywaną w kolejnym rekordzie DNSKEY.
Dzięki temu możemy sprawdzić, czy podpis został wykonany przy pomocy odpowiedniego klucza.
Co więcej, w przypadku DNS-ów posługujemy się dwoma, różnymi kluczami.
Jednym - krótszym nazywanym zone-signing key oraz dłuższym key-signing key.
Przy użyciu tego pierwszego - podpisujemy wygenerowane wcześniej rekordy RRSET a wynik przechowujemy w RRSIG.
Jest to więc taka szybka parafka na każdej stronie naszej umowy.
Ten klucz może się bowiem często zmieniać.
Jest także szybki do wykonania.
Drugi klucz podpisuje część publiczna klucza zone signing key oraz część publiczna swojego klucza.
Jest to zatem podpis na końcu umowy, który to potwierdza nasze parafki na poprzednich stronach.
Teoretycznie, mamy zatem wszystkie części układanki pozwalające na sprawdzenie poprawności rekordu.
Jak zatem przebiega taki proces?
Serwer DNS wysyła zapytanie o daną domenę.
W odpowiedzi zwracany jest rekord RRSET, w którym znajduje się adres IP serwera a także RRSIG - który zawiera podpis tego rekordu.
Teraz należy sprawdzić czy podpis jest prawidłowy - wykorzystując do tego celu publiczną część klucza zone signing key znajdującą się w rekordzie DNSKEY.
Jeżeli wszystko się zgadza - odpowiedź z serwera jest prawidłowa.
Ale musimy jeszcze sprawdzić, czy klucz sam w sobie jest prawidłowy.
Pobieramy zatem rekord DNSKEY, który zawiera dwa klucze publiczne.
Pierwszy - key signing key, którym to podpisany jest ten rekord.
Przy jego pomocy sprawdzamy, czy podpis tego rekordu znajdują się w RRSIG jest prawidłowy.
Następnie, możemy więc upewnić się, że drugi klucz publiczny - zone signing key, jest identyczny z tym, którego wcześniej używaliśmy.
Trochę to zagmatwane.
Prześledźmy proces sprawdzania jeszcze raz opierając się na naszej analogii.
Musimy przygotować dwa dokumenty.
Pierwszy - umowę.
Drugi - pismo, w którym osoba podpisująca daną umowę poświadcza, że jej podpis i parafka wyglądają tak i tak.
Teraz, bazując na tym poświadczeniu sprawdzamy parafki w dokumencie.
Jest to równoznaczne ze sprawdzeniem czy rekordy zgrupowane w RRSET są podpisane przy użyciu zone-signing key.
Następnie - ponownie bazując na poświadczeniu, sprawdzamy czy umowa jest podpisana przez daną osobę.
Czyli uzywając key-signing-key weryfikujemy, że posługiwano się prawidłowym zone-signing-key do podpisywania wcześniejszych rekordów.
Jest tylko jedno ale.
Wszystkie te dane zwracane są przez ten sam, jeden serwer.
W przypadku umowy - weryfikowaliśmy ją na podstawie poświadczenia samego tylko autora tego dokumentu.
A taki dokument może stworzyć każdy z nas.
Tylko notarialne poświadczenie daje nam gwarancję autentyczności.
Nic zatem nie stoi na przeszkodzie, aby złośliwy serwer stworzył swój własny klucz prywatny, w rekordzie DNSKEY umieścił jego publiczną część a następnie użył go do podpisania danych.
Wszystko dalej by się zgadzało, po prostu podpis był by inny.
Podsumowując: jak na razie te dodatkowe rekordy nie zwiększyły naszego bezpieczeństwa.
Dalej ktoś może zwrócić nam zafałszowanego informację.
Musimy mieć jakąś metodę weryfikacji klucza Key-signing key.
W tym celu dnssec wprowadza kolejny typ rekordu - Delegation Signer.
On to przechowuje hash części publicznej klucza KSK.
Tylko ,że rekord ten przechowywany jest w nadrzędnej strukturze DNS.
Czyli, gdybym ustawiał DNSSEC dla szurek.pl, mój hash części publicznej mojego klucza KSK został by wysłany do serwera DNS obsługującego domeny PL.
I to właśnie tam byłby przechowywany w rekordzie DS.
Stąd też cały ten ambaras z dwoma kluczami.
Ten krótszy - ZSK może sie częściej zmieniać, ponieważ jest wykorzystywany tylko w obrębie jednego serwera DNS.
Za każdym razem gdy zmieniamy ten dłuższy - KSK - musimy go wysłać do serwera nadrzędnego, aby został tam umieszczony.
A to może potrwać, ponieważ to nie my kontrolujemy serwer nadrzędny.
Podobnie w życiu - może się zdarzyć, że parafka z czasem się zmieni, lekko ewoluuje.
Nasz normalny podpis jednak rzadko ulega zmianie.
Rekord DS to zatem podpis notariusza na naszej umowie
To dzięki niemu wiemy, że osoby, które ją podpisały są tymi, za kogo się podają.
Tylko, że teraz pojawia się kolejne pytanie.
Skąd mamy pewność, że notariusz, rzeczywiście jest notariuszem a nie przebierańcem?
Możemy sprawdzić czy jego dane znajdują się na liście Izby Notarialnej.
W przypadku DNS również sprawdzamy poprawność wyżej w hierarchii.
Wiemy, że rekord DNS poniżej jest poprawny, ponieważ hash klucza KSK znajduje się w rekordzie DS serwera nadrzędnego.
Teraz, musimy sprawdzić czy rekordy znajdujące się na serwerze nadrzędnym, są prawidłowo podpisane.
Rekordy DS są bowiem podpisywane w dokładnie taki sam sposób jak wszystkie inne typy rekordów.
Ponawiamy więc opisana wcześniej procedurę, tym razem wykorzystując klucze tego serwera.
Tak kontynuujemy sprawdzanie danych przechodząc coraz wyżej w hierarchii aż dochodzimy do serwerów root.
Ponad nimi nie ma już nic.
Nie mamy zatem gdzie umieścić kolejnego rekordu DS, który pozwolił by nam na weryfikacje danych.
Jak zatem rozwiązano ten problem?
Musimy coś przyjąć za fakt.
Podobnie jak z rządem.
Wybieramy go w wyborach i wszyscy respektujemy wole narodu.
Uznano zatem, że zostanie wygenerowany klucz główny - tak zwany root key.
Pierwszy taki klucz został wygenerowany w 2010 roku.
Ta wartość jest zaszyta w oprogramowaniu, które weryfikuje poprawność DNSSEC.
Sprawdzając poprawność rekordów, weryfikujemy wszystkie węzły w hierarchii dochodząc do serwerów root.
Na samym końcu klucz musi zgadzać się z tym zapisanym w oprogramowaniu.
Jak zatem widzisz ten klucz jest kluczem do całego Internetu.
Posiadając do niego dostęp możemy popisać dowolny rekord, który to zostanie uznany przez oprogramowanie za prawidłowy.
Z tego też powodu klucz ten nie powinien być w posiadaniu tylko jednej osoby.
Stanowiło by to zbyt duże niebezpieczeństwo.
Tak wymyślono ceremonię podpisywania kluczy.
Podczas niej podpisywany jest zestaw kilku kluczy ZSK, które to następnie będą wykorzystywane w serwerach root DNS.
Zazwyczaj, ceremonia odbywa się 4 razy do roku.
Całość jest transmitowana w Internecie.
Do jej przeprowadzenia wymagana jest obecność kilku osób.
Prześledźmy bliżej jak wygląda takie zebranie.
To co teraz opisze, może wydawać się dziwne.
Takie rozdrobnienie na różne role, przypisane do różnych osób wydaje się być na wyrost.
Jest w tym jednak głębszy sens.
Taka dystrybucja zadań pozwala na zminimalizowanie szansy, że grupa osób z odpowiednimi uprawnieniami była by w stanie skompromitować klucz prywatny.
Obecnie szansa taka wynosi 1 do miliona.
Klucz, przechowywany jest w dwóch fizycznie oddzielonych od siebie lokalizacjach.
Spotkania odbywają się naprzemiennie raz w jednej raz w drugiej z nich.
Do przeprowadzenia podpisywania konieczna jest obecność co najmniej 7 osób.
Jednego administratora ceremonii, jednego wewnętrznego świadka, jednego operatora sejfu, jednego operatora sprzętu a także 3 krypto oficerów.
Brzmi dziwacznie, prawda?
Klucz (który został wygenerowany dawno temu na jednej z takich ceremonii) jest przechowywany w specjalnym urządzeniu zwanym HSM.
Jest to sprzętowy moduł bezpieczeństwa, który pozwala na wykonywanie pewnych operacji na przechowywanym w nim kluczu.
Nie pozwala jednak na proste jego wyeksportowanie.
Mówiąc ogólnie - klucz jest w urządzeniu i nie można go w prosty sposób zapisać do pliku czy też wydrukować.
Dzięki temu nawet jeżeli ktoś ukradnie takie urządzenie, bezpieczeństwo nie jest zagrożone dopóki nie posiadamy odpowiednich uprawnień do jego odblokowania.
Na świecie jest tylko 14 krypto oficerów.
Pierwsza część to takie ustalenie ich kalendarzy, aby co najmniej 3 z nich pojawiło się w jednej lokalizacji w tym samym momencie.
Następnie, sprawdza się ich tożsamość, skan linii papilarnych a także siatkówek.
Teraz mogą wejść do specjalnie przygotowanego pomieszczenia.
Operator sejfu otwiera pierwszy sejf, w którym znajduje się kilkanaście skrzynek depozytowych, z których każda do otwarcia wymaga dwóch fizycznych kluczy.
Pierwszy z nich - jest w posiadania administratora ceremonii.
Drugi - należy do krypto oficerów.
Każdy z nich ma swoją własną skrzynkę depozytową, do której posiada odpowiedni klucz.
W obecności wewnętrznego świadka otwierane są 3 skrzynki.
W każdej z nich znajduje się karta operatora a także druga karta, używana podczas przenoszenia certyfikatu.
Obie z nich są przechowywane w plastikowych opakowaniach, które mają zabezpieczać przed manipulacją.
3 karty operatorów są potrzebne, aby odblokować dostęp do HSM.
Ten to sprzęt jest przechowywany w drugim sejfie.
Znajduje się tam również specjalny laptop, który służy do przesyłania komend do urządzenia.
Ten komputer nie ma baterii, dysku twardego ani także bateryjnego podtrzymywania zegara systemowego.
Wszystko po to aby zminimalizować ryzyko jakiegokolwiek wycieku klucza poza urządzenie HSM.
Rozpoczyna się oficjalna część ceremonii.
Cały potrzebny sprzętu jest rozstawiony na stole.
Całość jest nagrywana i transmitowana przez Internet.
Każdy z krypto oficerów jest przywoływany do stołu.
Tam to weryfikują czy karta nie była w jakikolwiek sposób manipulowana.
Następnie, przekazują ją administratorowi ceremonii.
On to uruchamia laptopa z płyty DVD a także inicjalizuje pendrive USB, który zapisze log z całego zajścia.
Musi także ustawić zegar systemowy w systemie operacyjnym.
Teraz, można odblokować moduł HSM wkładając do niego 3 karty operatorów.
Całość jest połączona z komputerem przy pomocy kabla Ethernet.
Teraz, możliwe jest wykonywanie operacji na kluczu prywatnym.
Podpisuje się zatem wcześniej przygotowane klucze, porównując wcześniej ich hashe z tymi, które znajdują się w dokumentacji.
Każdy bowiem krok wykonywany podczas tej skomplikowanej procedury, jest wcześniej opisany w specjalnym dokumencie.
Tam to też zapisuje się czas wykonania konkretnej komendy oraz wszystkie problemy.
Po dokonaniu podpisu, log z całego zajścia jest drukowany i rozdawany uczestnikom.
Verisign - czyli operator serwerów root DNS otrzymuje podpisane klucze na pendrive.
Będą one używane przez następny kwartał roku, aż do kolejnej ceremonii.
Wszystkie wykorzystane przedmioty trafiają z powrotem do plastikowych toreb a następnie do sejfu.
I to już.
Niektórzy mogą stwierdzić, że to przyrost formy nad treścią, że to pewnego rodzaju przedstawienie teatralne.
A jednak, spotkanie to sprawia, że Internet jest bezpieczniejszym miejscem.
Możesz sobie zadać pytanie: a co w przypadku, gdy oba sprzętowe moduły zostaną zniszczone.
Co z kluczem?
I taką sytuacje starano się przewidzieć.
Klucz bowiem podzielono na 7 części i zapisano na kartach kryptograficznych.
Każdą z nich przydzielono jednej osobie, która powinna ją przechowywać w bezpiecznym miejscu.
W przypadku katastrofy, możliwe jest odzyskanie klucza jeśli zbierze się odpowiednia liczba osób, które posiadają jego części.
Można do tego celu wykorzystać algorytm Shamir's Secret Sharing.
Ustalamy w nim na ile części dzielimy klucz a także ile części potrzebnych jest do jego odzyskania.
Dzięki takiemu rozwiązaniu jedna osoba nie za wiele zdziała równocześnie nie wszystkie z nich muszą się spotkać aby przywrócić klucz.
Ot taka ciekawostka.
