Narodziła się nowa świecka tradycja – „ceremonia klucza”

„Dzisiaj w godzinach popołudniowych w Warszawie narodziła się nowa, świecka, tradycja – Dzień Pieszego Pasażera, który to dzień z pewnością wejdzie na stałe do naszego kalendarza”. Pamiętacie Państwo tę scenę z filmu „Miś” Bareji? Otóż nowa świecka tradycja narodzi się (też) w Stanach Zjednoczonych 16 czerwca 2010, kiedy to ICANN organizuje nową świecką ceremonię – „ceremonię klucza dla strefy root” („Key Ceremony for the Root Zone”). Skrót DNSSEC pochodzi od nazwy „DNS Security Extensions”, a celem DNSSEC jest zabezpieczenie infrastruktury DNS przed pewną grupą niebezpiecznych ataków, pośród których najbardziej niebezpieczny to „cache poisoning”.

DNSSEC zapewnia bezpieczeństwo w trzech kluczowych obszarach:

• gwarancję autentyczności pochodzenia danych,
• spójność danych oraz
• autentyczność informacji o braku domeny w DNS.

To czego nie zapewnia DNSSEC to przede wszystkim:

• nie zapewnia poufności (odpowiedzi są podpisane ale nie zaszyfrowane) oraz
• nie chroni przed atakami DDoS (Distributed Denial of Service).

Zanim wrócimy do tematu „ceremonii klucza” opiszę na czym polega DNSSEC i skąd się wzięło tak duże zainteresowanie DNSSEC przez wiele rządów i instytucji odpowiedzialnych za bezpieczeństwo.

Działanie DNSSEC

Istotą działania DNSSEC jest podpisywanie cyfrowo odpowiedzi DNS. Te cyfrowe podpisy opierają się na idei Public Key Cryptography. Każda podpisana cyfrowo odpowiedź DNS oprócz oczywiście samej odpowiedzi (z rekordami A, AAAA, SOA… czyli jak ma to miejsce obecnie) zawiera rekord tzw. RRSIG. RRSIG to cyfrowa sygnatura (podpis) rekordu zasobów. Podpis ten można zweryfikować dzięki dostępnej części pary dwóch kluczy – kluczowi publicznemu w rekordzie DNSKEY. Na podstawie sprawdzenia sygnatury, tzw. resolver DNS może stwierdzić czy otrzymana odpowiedź jest poprawna czy nie, oczywiście pod warunkiem, że autorytatywny serwer nazw (Authoritative Name Server) wspiera DNSSEC. Innymi słowy, dzięki DNSSEC jesteśmy w stanie stwierdzić, że odpowiedź z serwerów DNS jest prawdziwa czy nie. Czemu taka weryfikacja miałaby służyć? Otóż może się zdarzyć, że ktoś będzie próbował podszyć się pod inną instytucję, fałszując odpowiedzi DNS. Taka metoda pozwoliłaby przestępcom na wprowadzenie w błąd np. klienta banku i „podstawienie” mu fałszywej strony.

Obecnie stosuje się kilka sposobów wykradania informacji służących do przeprowadzania transakcji bankowych:

1. Haker może przełamać zabezpieczenia w banku (bezpośrednio na serwerze w banku) i podmienić stronę służącą do dokonywania transakcji on-line (przelewów). Nasze przelewy, zamiast trafiać na docelowe konta, trafiałyby na ukraińskie konto naszego hakera.
2. Haker może przełamać zabezpieczenia w naszym komputerze. W efekcie, odwołując się do strony banku, trafialibyśmy na podstawioną stronę, gdzie nasze hasła jednorazowe byłyby zbierane i później wykorzystywane do transferu pieniędzy na Ukrainę.
3. Można przekierować domenę z poziomu Rejestru (poprzez włamanie do systemu Rejestru, Rejestratora albo poprzez tzw. social engineering) na całkowicie inne serwery na których znajdują są fałszywe strony banku.
4. Modyfikować odpowiedzi DNS tak, aby komputer użytkownika uzyskiwał informację o fałszywej lokalizacji serwerów i dalej wykorzystać model z punktów 3.

I tak, włamanie metodą opisaną w punkcie 1 jest dość trudno zrealizować (banki poczyniły inwestycję w bezpieczeństwo), punkt 2 jest łatwiejszy (wykorzystanie botnetów), ale wymaga zainfekowania bezpośrednio komputerów użytkowników. Zostaje punkt 3 i 4 – rozwiązania trudniejsze do realizacji, ale dające fenomenalny zasięg (szczególnie punkt 3, gdzie każde zapytanie do DNS zwraca fałszywą odpowiedź). Włamanie w modelu punktu 3 są dość często praktykowane, najbardziej znane przykłady z ostatnich miesięcy to przekierowanie domeny baidu.com na inne serwery w styczniu tego roku, czy przekierowanie domeny hotmail.co.il (Hotmail w Izrealu) na stronę terrorystów (na początku czerwca). Natomiast czwarty model włamania nie był dotychczas stosowany często, aczkolwiek narażone na nie są np. sieci WiFi. Ewentualne „podmienianie” odpowiedzi DNS w sieci WiFi jest dziecinnie proste, niemniej jednak ewentualny zasięg takiego działania jest relatywnie niewielki i wymaga umieszczenia (fizycznie) własnego sprzętu (np. laptopa) w zasięgu sieci WiFi. Oprócz rozgłaszania fałszywych odpowiedzi w sieci WiFi można też wykorzystać wspomniany „cache poisoning”, włamując się na serwer np. dostawcy ISP. I tutaj z pomocą przychodzi DNSSEC.

DNSSEC gwarantuje nam, że otrzymana odpowiedź DNS jest prawdziwa, czyli, że nie ma pomiędzy nami a autorytatywnym serwerem DNS kogoś, kto chciałby dokonać fałszerstwa. Warto jednak dodać, że najbardziej rozpowszechnione obecnie mechanizmy kradzieży / wyłudzeń oparte na włamaniach na stronę np. banku (model 1) czy poprzez zainfekowanie komputera użytkownika (model 2) nadal będą groźne, a DNSSEC nie stanowi tutaj panaceum.

Wracając do samego mechanizmu DNSSEC… otrzymaliśmy odpowiedź z DNS i musimy w jakiś sposób zweryfikować, że dane zawarte w otrzymanym rekordzie, w szczególności DNSKEY jest faktycznie umieszczony przez właściwą osobę (czyli chcemy wyeliminować model „4” włamania). Tej weryfikacji dokonujemy dzięki rekordom DS (Delegation Signer) znajdującym się w domenie nadrzędnej (jak sprawdzamy domenę AZ.PL to będziemy szukali rekordu DS w domenie .PL – oczywiście pod warunkiem, że kiedyś w Polsce nastąpi jednak wdrożenie projektu DNSSEC).

I tak idąc od domeny najwyższego poziomu (root), aż do poziomu najniższego i weryfikując za pomocą rekordów DS kolejne rekordy DNSKEY (w domenach podrzędnych), możemy upewnić się, że otrzymana odpowiedź jest poprawna. W tym rozumowaniu pojawia się istotny problem – w jaki sposób zaufać odpowiedzi z „root”? Ostatecznie musimy komuś zaufać. Takie zaufane miejsce nazywane jest „trust anchor” i przyjmowanym a-priori miejscem, gdzie można jednoznacznie stwierdzić, że dana odpowiedź (w tym przypadku na poziomie „root”) jest autentyczna.

Podpisanie strefy „root”

I tutaj pojawia się kwestia, kto powinien podpisywać strefę „root”. Pierwotne idee zakładały udział rządów (oczywiście rządu USA) albo Międzynarodowej Unii Telekomunikacyjnej (jedna z organizacji ONZ). Ostatecznie wybór padł na społeczne podejście do nadzorowania tego procesu, stąd poniekąd idea publicznej ceremonii podpisywania kluczy. Warto jednak podkreślić to, o czym nie pisze się publicznie, że wszystko sprowadza się do tego że to ICANN sam generuje i podpisuje klucze, czyli jednym słowem sam potwierdza sobie, że jest uprawniony do podpisywania plików stref. Nie twierdzę że jest to złe podejście. Jest to bardzo pragmatyczne podejście, gdzie pewien proces techniczny zostaje dokonany pod nadzorem zaufanych osób – „mistrzów tej ceremonii” zwanych przez ICANN „Trusted Community Representatives” czyli zaufany reprezentant społeczności (cóż, strasznie głupio to brzmi).

W trakcie tej ceremonii pierwszy klucz KSK (Key Signing Key) zostanie wygenerowany i zostanie podpisany tzw. Root Zone Zone Signing Key (RZ ZSK). Teoretycznie klucz KSK powinien generować i podpisywać ktoś nadrzędny do ICANN, ale ponieważ „wyższa” polityka nie pozwoliła na wybranie jednego, jedynego zaufanego na tym świecie, to ICANN bierze w swoje ręce zarówno generowanie KSK i podpisywanie ZSK (dokładniej RZ ZSK). Analogią może być sytuacja kiedy to notariusz sam poświadcza sobie notarialnie swój podpis, albo wystawiamy sami sobie upoważnienie do reprezentowania samego siebie. Zadaniem ICANN będzie zarówno bezpieczne przechowywanie części prywatnej klucza, podpisywanie RZ ZSK jak i publikowanie części publicznej klucza KSK. Dzięki temu, będzie można weryfikować, czy odpowiedzi ze strefy root są godne zaufania czy nie.

Zainteresowanych tym, w jaki sposób ICANN będzie zarządzał kluczami DNSSEC, odsyłam do pasjonującego 45-stronicowego dokumentu „DNSSEC Practice Statement for the Root Zone KSK Operator” oraz równie ciekawego 41-stronicowego dokumentu „DNSSEC Practice Statement for the Root Zone ZSK operator”.

Kolejne kroki po „ceremonii”

Podpisanie strefy „root” jest tylko pierwszym etapem we wdrożeniu DNSSEC. Kolejnym etapem jest wdrożenie DNSSEC w rejestrach narodowych (ccTLD) oraz rejestrach gTLD. Dotychczas jedynie kilka rejestrów odważyło się na wdrożenie DNSSEC. W Europie jest to rejestr szwedzki (.SE), czeski (.CZ), szwajcarski (.CH) oraz bułgarski (.BG). Pewne nieśmiałe wdrożenia poczynił rejestr holenderski (.NL) w postaci samego posiania strefy .NL ale bez możliwości wykorzystania tego przez Abonentów domen.

Wdrożenie DNSSEC na poziomie ccTLD czy gTLD jest zadaniem skomplikowanym, ponieważ wymusza stworzenie mechanizmów, kiedy to Abonenci sami generują klucze, podpisują swoją strefę i przekazują skrót do Rejestru poprzez swoich Registrarów (Partnerów). Wdrożenie DNSSEC na poziomie krajowym wymaga przeprowadzenia prawdziwych konsultacji, gdzie głosy Partnerów i Abonentów zostają faktycznie wysłuchane. Proces ten musi być w 100% transparentny i uczciwy. Takie prawdziwe konsultacje przeprowadził ICANN, przeprowadziły też rejestry, które wdrożyły DNSSEC’a czyli Szwecja i Czechy, co powoduje też, że w krajach tych jest obecnie najwyższy poziom adopcji tego rozwiązania.

Grafika: kadr z filmu „Miś”, reż. Stanisław Bareja