Coś bardzo dziwnego stało się z kluczami podpisującymi DNSSEC. Czy są powody do obaw?

Organizacja ICANN, zajmująca się lekceważeniem niezbędnej opieki nad top-domeną .org oraz kilkoma innymi kwestiami, jak alokacja IP i obsługa rdzennej strefy DNS, natrafiła na osobliwy problem. Trudności techniczne wymusiły opóźnienie czterdziestej Ceremonii Podpisywania Kluczy Rdzennych (Root Key Signing Ceremony). Jak podano, otwarcie sejfu zawierającego klucz prywatny podpisu dla DNSSEC okazało się niemożliwe.

Takie informacje zawsze są niepokojące. Zaniedbania w utrzymaniu ciągłości ścieżki certyfikacji mają tendencję do wywoływania katastrofalnych awarii i przestojów, a w tym przypadku efekty byłyby bardzo dotkliwe dla usługi DNS. Wyjaśnijmy pokrótce, na czym polega Ceremonia i po co się odbywa.

DNSSEC to rozszerzenie usługi DNS, zapewniające wiarygodność delegacji serwerów nazw, co pozwala utrzymać hierarchię między nimi. Ma utrudniać możliwość fałszowania wpisów DNS: jeżeli rekord DNS jest podpisany, to znaczy że pochodzi od zaufanego serwera, na którym też znalazły się wpisy nadrzędne z zaufanego serwera, i tak dalej aż do serwera rdzennego (DNS Root), obdarzonego "nieskończonym zaufaniem".

Reguły są tu podobne do tych w certyfikatach SSL: podpisanie treści certyfikatem podpisanym przez certyfikat nadrzędny przenosi zaufanie na tę treść. Urząd dysponujący nadrzędnym certyfikatem nie musi podpisywać wszystkiego, co wpadnie mu w ręce, więc podpisuje certyfikaty innym urzędom, które mogą podpisywać treść tak, jakby robił to główny urząd.

Gdzieś istnieją super-certyfikaty gwarantujące wiarygodność niższych. Jeżeli ktoś przejmie niższe, główny urząd je unieważni. Jeżeli ktoś przejmie główny, całe drzewko się sypie. Rdzennych certyfikatów SSL jest kilka. Rdzenny klucz DNS jest jeden, bo usługa jest z definicji drzewem pojedynczym.

Skodyfikowany i wysoce formalny proces otwierania sejfów z poświadczeniami kryptograficznymi odbywa się raz na trzy miesiące. Poświadczenia wydobyte z sejfu są używane do połączenia z dedykowanym urządzeniem, zwanym HSM, za pomocą laptopa. Oba urządzenia spoczywają w drugim sejfie. Laptop, jak wyjaśnia Cloudflare, nie przechowuje stanu. Innymi słowy, nie ma nośników pamięci zapisywalnej, nie ma akumulatora ani baterii CMOS.

HSM przechowuje klucz zdolny do podpisywania klucza głównej strefy DNS. Istnieje w dwóch kopiach, w Kaliforni i Vancouver. Procedura ma swoje implikacje filozoficzne: nie ufamy tu samej matematyce ani procesowi. Ufamy ludziom zaangażowanym w przedsięwzięcie. Dlatego podważanie zaufania do IANA/ICANN jest tak niebezpieczne, ale mało kto poza EFF wydaje się tym szczególnie przejmować.

Co oznacza problem z sejfem? Trwały – brak dostępu do urządzeń operujących kluczem głównym. IANA w przypadku ryzyka utraty ważności klucza ma procedurę uprawnionego włamania do sejfu, ale każde takie wydarzenie podważa rzetelność procesu.

No dobrze, może więc awaria sejfu jest poszlaką, wskazującą na kradzież (celem duplikacji) kluczy do HSM lub samego HSM (w zależności od sejfu)? Po pierwsze, jeden sejf nic nie da. Po drugie, włamanie do niego wymagałoby fizycznej obecności w ściśle kontrolowanym budynku z nagrywanym ruchem. Gdyby popsuty sejf był efektem włamania, oznaczałoby to naruszenie/zdyskredytowanie ("compromise") bezpieczeństwa operacyjnego siedziby IANA. Co więcej, ponieważ sprawa dotyczy jednego sejfu, wskazywałoby to na istnienie nieuregulowanej kopii urządzenia generującego klucz.

To dyskusyjna teoria spiskowa wagi ciężkiej. Gdyby tak było, mielibyśmy olbrzymi, światowy problem z internetem i bezpieczeństwem połączeń. Nie byłby to koniec świat, niemniej świat stałby się zauważalnie bardziej nieznośny. Wydarzenia, jak odroczenie podpisywania strefy DNS, wystawiają wyobraźnię na próbę. Nikt nie chce okazać się naiwniakiem, który przeoczył oczywiste zwiastuny katastrofy. Podobnie nikt nie lubi wychodzić na panikarza...

Naprawę sejfu zaplanowano na piątek, a podpisanie stref nastąpi w sobotę 15 lutego, o 18:00 UTC.