2026-08-18 · RESEARCH · Zespół Offensive Technology

Certificate transparency post-quantum: 43% logów static-CT już podpisuje ML-DSA-44

Certificate transparency po cichu rozpoczęło migrację postkwantową i jest już w 43% gotowe na poziomie podpisywania logów. Pobraliśmy publiczny plik checkpoint z każdego z 70 logów static-CT z publicznej listy logów, a 30 z nich (42,9%) dołącza podpis postkwantowy ML-DSA-44 do każdego checkpointu, tuż obok klasycznego podpisu ECDSA. To godne uwagi, bo żadna porównywalna powierzchnia się tak nie ruszyła: DNSSEC jest w 0% postkwantowy a handshake TLS dopiero startuje. Haczyk tkwi w drugiej połowie projektu. Warstwa świadków (witness), mechanizm, który ma wyłapać log kłamiący o własnej historii, jest wdrożona ledwie w szczątkowym stopniu: tylko 11 z 70 logów niesie jakąkolwiek kopodpis świadka, widzieliśmy zaledwie 6 odrębnych świadków w całym ekosystemie, a 0 z nich jest postkwantowych. Podpisywanie wyprzedza obserwację.

Co zmierzyliśmy i dlaczego checkpoint jest czytelny

Certificate transparency przechodzi ze starego protokołu request-response RFC 6962 na format static-ct-api, gdzie log to po prostu zbiór statycznych plików na CDN. Let's Encrypt wyłączył swoje klasyczne logi 28 lutego 2026 (ich plan end-of-life zawiera harmonogram), a model kafelkowy (tiled) jest już głównym nurtem. Ten jeden mały plik, który podsumowuje aktualny stan static loga, to jego checkpoint: nazwa logu, rozmiar drzewa, hash korzenia Merkle, a następnie blok podpisów. Jest publiczny z założenia, bo monitory na całym świecie pobierają go bez przerwy, żeby pilnować uczciwości logu. Odczyt niczego prywatnego nie narusza i nie sonduje żadnego hosta; to ten sam GET, który wykonuje monitor, odpowiednik odczytu publicznego rekordu DNS.

Wzięliśmy opublikowaną listę logów CT, wyciągnęliśmy każdy log kafelkowy i pobraliśmy checkpoint każdego z nich dokładnie raz. Odpowiedziało wszystkie 70. Następnie sparsowaliśmy blok podpisów. W formacie signed-note, w jakim występuje checkpoint, każdy podpis to osobna linia: znacznik myślnika, potem nazwa podpisującego, a następnie wartość base64 będąca czterobajtową podpowiedzią klucza, po której następuje sam podpis. Ten ostatni szczegół to cała metoda: długość podpisu w bajtach zdradza jego algorytm. Podpis Ed25519 ma 64 bajty. Zabytkowy podpis tree-head z RFC 6962 to znacznik czasu plus krótki blob ECDSA. A podpis ML-DSA-44 ma 2420 bajtów, stały rozmiar zdefiniowany przez NIST FIPS 204. Nie musieliśmy więc ufać etykiecie; policzyliśmy bajty.

Postkwantowość jest już na 43% logów static-CT

Oto cała populacja, sklasyfikowana według tego, co faktycznie znajduje się w każdym checkpoincie. Pojedynczy checkpoint zwykle niesie więcej niż jedną linię podpisu, więc to są liczby logów, nie podpisów.

Drugi wiersz to sedno sprawy. Trzydzieści logów nie tylko podpisuje checkpoint kluczem klasycznym; dokłada pełny 2420-bajtowy podpis ML-DSA-44 na wierzchu, więc każdy checkpoint jest podpisany na oba sposoby. To dokładnie to, o co prosi specyfikacja checkpointu. Cytując ją wprost, logi powinny (should) używać kopodpisów ML-DSA-44 do podpisywania checkpointu, a format kopodpisu definiuje dedykowany typ postkwantowy, opisany jako bezpieczny wobec komputerów kwantowych, umieszczony tuż obok klasycznego. Wskaźnik przyjęcia 43% dla zalecenia typu powinno, które większość operatorów mogłaby zignorować, to szybkie tempo. I jest to skoncentrowane: podpisy postkwantowe skupiają się u mniejszości operatorów prowadzących duże rodziny logów szardowanych czasowo, więc decyzja kilku zespołów pokrywa już niemal połowę populacji. Podajemy dane zbiorczo, a nie listę imienną, bo podpisywanie mocniejszą kryptografią to dobra rzecz, nie zarzut wobec kogokolwiek.

Powód, dla którego ta warstwa może się ruszyć, gdy inne nie mogą, to rozmiar. Podpis ML-DSA-44 jest w przybliżeniu 38 razy większy od podpisu ECDSA, dlatego nie mieści się w pakiecie DNS i dlatego handshake TLS podchodzi do niego z rezerwą. Ale checkpoint to niewielki plik pobierany przez kilka tysięcy monitorów, nie pole wysyłane przy miliardach handshake'ów. Warstwa transparentności ma budżet bajtowy, żeby jako pierwsza przejść na postkwant, i go wykorzystuje.

Warstwa świadków to odwrotna historia

Podpisanie checkpointu dowodzi, że log złożył oświadczenie. Nie dowodzi, że log złożył to samo oświadczenie wszystkim. Skompromitowany log może przeprowadzić atak split-view: pokazać ofiarom drzewo zawierające fałszywy certyfikat, a monitorom czyste drzewo, które go nie zawiera, tak żeby oszustwo nigdy nie trafiło tam, gdzie ktokolwiek audytuje. Rozwiązaniem jest świadkowanie (witnessing). Świadek to niezależna usługa, która pamięta ostatni checkpoint widziany od danego logu, weryfikuje, że każdy nowy jest spójnym, append-only rozszerzeniem, i dopiero wtedy zwraca kopodpis. Wymagając wystarczającej liczby niezależnych świadków na checkpoincie, log nie może już utrzymywać dwóch historii, bo żaden uczciwy świadek nie skopodpisze obu.

To właśnie ten mechanizm zmienia log z zasady „zaufaj mi” w „nie da się skłamać”. W żywym ekosystemie jest on szczątkowy:

• Tylko 11 z 70 logów (16%) niesie jakikolwiek kopodpis świadka, a każdy z tych logów należy do rodziny logów jednego operatora. Checkpointy wszystkich pozostałych operatorów są podpisywane wyłącznie przez sam log, bez żadnej niezależnej strony poświadczającej spójność.
• W całym ekosystemie występuje zaledwie 6 odrębnych świadków, a tylko 2 z nich wyglądają na usługi produkcyjne. Pozostałe cztery określają się jako świadkowie staging, dev lub proof-of-concept.
• Każdy pojedynczy kopodpis świadka jest klasycznym Ed25519. Ani jeden świadek nie używa postkwantowego typu kopodpisu ML-DSA-44 zdefiniowanego w tej samej specyfikacji. Warstwa anty-equivocation jest postkwantowa w 0%.

Tam, gdzie świadkowanie działa, działa dobrze: obserwowane przez nas kopodpisy niosły znaczniki czasu opóźnione mediana o około 5 sekund względem naszego pobrania, więc świadkowie kopodpisują niemal w czasie rzeczywistym. Problem nie leży w opóźnieniu, lecz w pokryciu. Zabezpieczenie przed split-view obejmujące jednego operatora i mające dwóch produkcyjnych uczestników to obiecujący pilotaż, jeszcze nie gwarancja na poziomie ekosystemu.

Dwa różne zakłady na przyszłość transparentności

Zestawiając obie warstwy obok siebie, wyłania się wzorzec ciekawszy niż każda liczba z osobna. Logi, które przeszły na postkwant, i logi niosące kopodpisy świadków to zbiory rozłączne, prowadzone przez różnych operatorów. Jeden obóz inwestuje wysiłek w postkwantowe podpisy logów i nie dostarcza świadkowania. Drugi obóz inwestuje wysiłek w sieć świadków i nie dostarcza podpisu postkwantowego. Nikt w tym spisie nie robi obu rzeczy naraz.

Ten podział warto nazwać, bo obie inwestycje bronią przed innymi zagrożeniami, a trudniejsze zagrożenie to to, które można przegrać. Podpisywanie postkwantowe broni przed odległym w przyszłości scenariuszem, w którym komputer kwantowy sfałszuje podpis logu. Świadkowanie broni przed scenariuszem teraźniejszym, w którym log dziś kłamie na dwie strony. Ekosystem zbiorowo postawił z góry na zagrożenie spekulatywne, a niedoinwestował konkretne. Postkwant to widoczna, łatwa do zademonstrowania aktualizacja; świadkowanie wymaga, by inni ludzie utrzymywali infrastrukturę, a klienci żądali kworum, co jest trudniejsze organizacyjnie. Więc łatwiejsza połowa została dowieziona jako pierwsza.

Podpisy-wabiki i dlaczego to dobry znak

Jedno przypadkowe odkrycie mówi coś zdrowego o ekosystemie. W 46 z 70 logów (66%) checkpoint niesie linię podpisu pod nazwą grease.invalid, której bajty są losowe i nie weryfikują się wobec niczego. Nie jest to część specyfikacji, więc raportujemy to jako obserwację, nie regułę. Ale pasuje to dokładnie do udokumentowanego wymogu, że weryfikator musi ignorować podpisy od kluczy, których nie rozpoznaje. Ta reguła jest tym, co pozwala logowi bezpiecznie dodawać kopodpisy świadków albo nowy klucz postkwantowy bez psucia starych klientów. Emitowanie celowo nieprawidłowego podpisu, w stylu techniki GREASE z TLS, wymusza na każdym parserze faktyczne przestrzeganie tej reguły „musisz zignorować” zamiast krztuszenia się pierwszą nierozpoznaną linią. Dwie trzecie logów testujących odporność własnych konsumentów to znak ekosystemu, który spodziewa się dalszego wzrostu bloku podpisów, a dokładnie tego potrzebuje przejście postkwantowe.

Jak to zmierzyliśmy, żeby sceptyk mógł zaufać liczbom

Zbiór danych jest nasz własny, zbudowany wyłącznie z plików publicznych i raportowany zbiorczo. Nie skanowaliśmy, nie sondowaliśmy, nie wysyłaliśmy niczego do żadnego logu ani się z nim nie łączyliśmy poza pobraniem pojedynczego publicznego pliku checkpoint, który każdy z nich publikuje dokładnie w tym celu. W checkpoincie nie ma żadnych danych prywatnych; to rozmiar drzewa, hash i podpisy. Nie wskazujemy żadnego operatora jako niedostatecznego, bo żaden nim nie jest: to zrzut ekosystemu w trakcie aktualizacji.

• Populacja. Każdy log kafelkowy z publicznej listy logów CT, w sumie 70. Wszystkie 70 zwróciło parsowalny checkpoint w dniu pomiaru. Wiele z nich to szardy czasowe, więc liczba logów jest większa niż liczba operatorów.
• Klasyfikacja. Dla każdej linii podpisu zdekodowaliśmy base64, odrzuciliśmy czterobajtową podpowiedź klucza i odczytaliśmy pozostałą długość. 2420 bajtów (w kopercie ze znacznikiem czasu) to podpis ML-DSA-44 wg FIPS 204; 64 to Ed25519; krótki blob ze znacznikiem czasu to podpis tree-head z RFC 6962. Algorytm ustalany konstrukcyjnie, nie przez etykietę.
• Log kontra świadek. Podpis, którego nazwa odpowiada własnemu origin logu, to log podpisujący sam siebie. Kopodpis pod odrębną tożsamością świadka to niezależne poświadczenie. Liczyliśmy je osobno, dlatego liczba postkwantowa i liczba świadków opisują różne warstwy.
• Postkwant po rozmiarze. 30 logów postkwantowych niesie każdy podpis o dokładnie długości ML-DSA-44, w kopercie kopodpisu zdefiniowanej dla niego przez specyfikację. Klasyczny schemat nie może przypadkowo wygenerować podpisu o długości 2420 bajtów, więc liczba ta nie jest szacunkiem.

Dlaczego to ma znaczenie i uczciwe ograniczenia

Certificate transparency to fundament, na którym opierają się inne mechanizmy obronne. Dzięki niemu świat zauważa błędnie wystawiony certyfikat dla banku czy dostawcy poczty, i wspiera on kontrole takie jak gwarancje, które można odczytać z certyfikatu oraz ograniczenia wystawiania, takie jak CAA. Podobnie jak DNSSEC, CT podpisuje, a nie szyfruje, więc ryzyko kwantowe to przyszłe fałszerstwo, nie harvest-now-decrypt-later. To oznacza, że wynik 43% postkwantowości faktycznie wyprzedza zagrożenie, co jest dobrą i rzadką wiadomością. Ale druga strona medalu to część, która powinna przyciągnąć więcej uwagi: mechanizm czyniący log wiarygodnym wobec dzisiejszego, niekwantowego atakującego, czyli niezależne świadkowanie, jest właśnie tym, co pozostaje szczątkowe i klasyczne. Jeśli liczysz na transparentność, że wyłapie kolejne błędne wystawienie certyfikatu, to sieć świadków jest liczbą, którą warto obserwować, nie algorytm podpisu.

Wynik bez podania jego ograniczeń to marketing, więc oto granice.

• Jedna lista, jeden dzień. To publiczna lista logów z jednej konkretnej daty. Szardy są dodawane i rotowane, a świadkowanie jest aktywnie wdrażane, więc dokładne liczby będą się zmieniać. Ustalenie strukturalne, że podpisywanie wyprzedziło świadkowanie, jest częścią trwałą.
• Tylko serwowane checkpointy. Odczytaliśmy to, co każdy log serwuje na własnym endpoincie checkpointu. Świadek, który kopodpisuje log, ale dystrybuuje kopodpisy gdzie indziej, nie pojawiłby się tutaj, więc rzeczywisty poziom aktywności świadkowania to dolna granica, nie górna. Wniosek pozostaje ważny: checkpointy faktycznie pobierane przez klientów są w większości pozbawione świadków.
• Obecność, nie weryfikacja. Klasyfikowaliśmy podpisy według algorytmu i tożsamości, nie poprzez kryptograficzną weryfikację każdego z nich względem klucza. Obecny podpis ML-DSA-44 o prawidłowym rozmiarze to mocny dowód podpisywania postkwantowego; potwierdzenie, że każdy podpis się waliduje, to osobne ćwiczenie.
• Linia GREASE jest wywnioskowana. Wabik grease.invalid to nasza interpretacja nieudokumentowanego, lecz spójnego zachowania, nie cechy narzuconej przez specyfikację.

Najczęściej zadawane pytania

Czym jest static CT log?

Static CT log to log certificate transparency serwowany jako pliki statyczne, zwane kafelkami (tiles), z object storage lub CDN, zgodnie ze specyfikacją C2SP static-ct-api. Zamiast API request-response z RFC 6962, publikuje append-only kafelki po 256 wpisów plus mały podpisany checkpoint podający aktualny rozmiar drzewa i hash korzenia. Monitory czytają te pliki bezpośrednio, co czyni prowadzenie i mirrorowanie logów tanim. Ten projekt, początkowo nazywany Sunlight API, stał się głównym nurtem wśród operatorów CT w 2025 i 2026 roku.

Czy logi certificate transparency są już postkwantowe?

Częściowo i szybciej, niż większość ludzi zakłada. W naszym spisie wszystkich 70 logów static-CT 30 z nich (43%) dołącza już podpis ML-DSA-44 do każdego checkpointu, obok swojego klasycznego podpisu. ML-DSA-44 to schemat kratowy FIPS 204, odporny na ataki kwantowe, i jest dokładnie tym, co zaleca specyfikacja checkpointu. Warstwa podpisywania logów jest więc dobrze zaawansowana w migracji postkwantowej. Warstwa świadków kopodpisujących te checkpointy nadal jest postkwantowa w 0%; każdy widziany przez nas kopodpis świadka był klasycznym Ed25519.

Czym jest ML-DSA-44 i dlaczego jest tu używany?

ML-DSA-44 to najmniejszy zestaw parametrów ML-DSA, standardu podpisów kratowych typu module-lattice z NIST FIPS 204, wywodzącego się z CRYSTALS-Dilithium. Jego podpisy mają 2420 bajtów, a klucze 1312 bajtów, znacznie więcej niż 64-bajtowy podpis Ed25519, ale nie jest łamany przez algorytm Shora. Certificate transparency może wchłonąć ten rozmiar, bo checkpoint jest pobierany okazjonalnie przez monitory, a nie wysyłany przy każdym handshake, dlatego CT może przyjąć podpisy postkwantowe lata przed DNSSEC czy handshakem TLS.

Czym jest świadek CT i kopodpis świadka?

Świadek to niezależna usługa, identyfikowana nazwą i kluczem publicznym, która obserwuje checkpointy logu. Zanim kopodpisze nowy checkpoint, weryfikuje, że nowe drzewo jest spójne z ostatnim widzianym, czyli że log wyłącznie dopisywał, a nigdy nie przepisał historii, po czym zwraca kopodpis ze znacznikiem czasu, zdefiniowany przez specyfikacje C2SP tlog-witness i tlog-cosignature. Checkpoint niosący kopodpisy od kilku niezależnych świadków jest dla skompromitowanego logu dużo trudniejszy do sfałszowania.

Jak kopodpis świadka zapobiega atakowi split-view?

Atak split-view to sytuacja, gdy log pokazuje jedno drzewo ofiarom, a inne, uczciwe drzewo monitorom, tak że fałszywe certyfikaty nigdy nie pojawiają się tam, gdzie ktokolwiek audytuje. Ponieważ świadek kopodpisuje tylko po sprawdzeniu spójności z posiadaną już historią, log nie może uzyskać dwóch sprzecznych checkpointów skopodpisanych przez tego samego uczciwego świadka. Jeśli klienci wymagają kopodpisów od kworum niezależnych świadków, log musi pokazać wszystkim to samo append-only drzewo, co zamyka lukę, jaką pozostawia zwykłe logowanie.

Kiedy wyłączono logi certificate transparency z RFC 6962?

Migracja trwała przez 2025 i 2026 rok. Let's Encrypt ogłosił end-of-life dla swoich logów RFC 6962 w sierpniu 2025, przełączył je na tryb tylko do odczytu 30 listopada 2025, a całkowicie wyłączył 28 lutego 2026, na rzecz swoich statycznych logów Sycamore i Willow. Chrome dodał wsparcie dla static-ct-api na początku 2025 roku i wycofuje wymóg, by co najmniej jeden SCT pochodził ze starego logu RFC 6962.

Ile jest logów certificate transparency w 2026 roku?

Publiczna lista logów CT, której użyliśmy, zawiera 70 statycznych logów kafelkowych u garstki operatorów, plus pozostałe logi klasyczne. Wiele z tych 70 to szardy czasowe, z których każdy pokrywa zakres dat wygaśnięcia certyfikatów, więc jeden operator prowadzi kilka naraz. Wszystkie 70 statycznych logów zwróciło czytelny checkpoint w momencie pomiaru.

Powiązane materiały

• DNSSEC post-quantum readiness: 0% z top 30 000 domen. To samo pytanie postkwantowe na powierzchni, która jeszcze nie może się ruszyć, bo podpisy nie mieszczą się w pakiecie DNS.
• Czy FIPS wyłącza postkwantowy TLS? Przejście postkwantowe zmierzone na handshake'u TLS zamiast warstwy transparentności.
• Co udowadniają certyfikaty. Odczytywanie gwarancji kryptograficznych z rejestrów publicznych zamiast ufania etykiecie, ta sama metoda zastosowana do samych certyfikatów.
• Ile czołowych domen ogranicza wystawianie certyfikatów? Ekosystem certyfikatów zmierzony pasywnie z danych publicznych.