eMudhra unieważnia kolejne pośrednie CA po incydencie z obsługą kluczy w HSM

Wprowadzenie do problemu / definicja

Incydent związany z eMudhra pokazuje, jak istotne dla zaufania do infrastruktury PKI są rygorystyczne procedury zarządzania kluczami prywatnymi urzędów certyfikacji. W listopadzie 2026 r. firma unieważniła osiem dodatkowych pośrednich urzędów certyfikacji po ponownej analizie procesu przenoszenia kluczy między urządzeniami HSM.

W tym przypadku problem nie polegał na bezpośrednim osłabieniu kryptografii RSA, lecz na tym, że materiał klucza prywatnego został odczytany z HSM do pamięci procesu. Taka operacja podważyła możliwość potwierdzenia zgodności z wewnętrznymi wymaganiami bezpieczeństwa oraz praktyką certyfikacji.

W skrócie

eMudhra unieważniła osiem kolejnych pośrednich CA, mimo że wcześniej uznawano je za niezagrożone w ramach wcześniejszego incydentu. Nowe działania dotyczą kluczy RSA, które nie zostały skrócone ani kryptograficznie uszkodzone, ale były przetwarzane w sposób naruszający założony model bezpieczeństwa.

Unieważnienie objęło osiem dodatkowych pośrednich urzędów certyfikacji.
Problem wynikał z procesu migracji kluczy między HSM różnych producentów.
Materiał klucza prywatnego znalazł się w pamięci komputera używanego podczas ceremonii kluczy.
Zidentyfikowano 195 certyfikatów wystawionych przez dotknięte incydentem CA, w tym TLS i code signing.

Kontekst / historia

Źródłem problemu była ceremonia generowania kluczy z 30 kwietnia 2025 r., podczas której utworzono 16 kluczy CA na urządzeniach Utimaco HSM. Klucze miały docelowo trafić na urządzenia Crypto4A HSM wykorzystywane w lokalizacjach w USA i UE.

Z uwagi na ograniczenia migracji kluczy pomiędzy HSM różnych producentów zespół operacyjny PKI przygotował własny skrypt w Pythonie. Jego zadaniem było opakowanie kluczy do transportu i ich odtworzenie po stronie docelowej. To właśnie ten element procesu stał się źródłem późniejszych problemów.

W październiku 2026 r. ujawniono, że osiem kluczy ECDSA zostało błędnie odtworzonych przez ten sam skrypt, ponieważ jedna linia kodu skróciła wartość prywatną do jednego bajtu. Późniejsza analiza wykazała, że identyczna ścieżka przetwarzania objęła również osiem kluczy RSA, które wcześniej nie były uznawane za dotknięte incydentem.

Analiza techniczna

Z technicznego punktu widzenia incydent nie dotyczy klasycznej kradzieży klucza ani słabości algorytmu kryptograficznego. Problem dotyczy naruszenia modelu zaufania wokół obsługi materiału klucza prywatnego. W poprawnie zaprojektowanym środowisku CA klucze prywatne powinny być generowane, przechowywane i wykorzystywane wyłącznie wewnątrz HSM.

W analizowanym przypadku użyto procedury pośredniej, w której skrypt odczytywał klucze z urządzenia źródłowego, przetwarzał je i odtwarzał po stronie docelowej z użyciem pamięci komputera ceremonii. Dla kluczy ECDSA skutkowało to krytycznym błędem logicznym prowadzącym do drastycznego obniżenia entropii. Dla kluczy RSA nie stwierdzono osłabienia samych podpisów, ale prywatne komponenty klucza znalazły się poza kontrolowaną granicą HSM.

To oznacza złamanie fundamentalnej zasady separacji materiału kryptograficznego od systemów ogólnego przeznaczenia. Dodatkowo procedura nie zawierała skutecznych mechanizmów walidacji, które mogłyby wykryć problem na etapie po migracji. Nie weryfikowano w wystarczający sposób siły odtworzonego klucza ani zgodności pomiędzy kluczem pierwotnie wygenerowanym a kluczem faktycznie certyfikowanym.

Konsekwencje / ryzyko

Dla organizacji korzystających z certyfikatów wydanych przez objęte incydentem pośrednie CA najważniejszą konsekwencją jest konieczność pilnej wymiany certyfikatów i sprawdzenia łańcucha zaufania. Unieważnienie pośrednich CA może skutkować utratą zaufania w przeglądarkach, systemach operacyjnych i narzędziach klienckich.

Ryzyko należy analizować w dwóch wymiarach. W poprzednim przypadku ECDSA istniała realna możliwość praktycznego odtworzenia kluczy prywatnych i nadużyć. W przypadku nowych unieważnień dotyczących RSA nie ma potwierdzenia złośliwego wykorzystania kluczy, jednak brak możliwości udowodnienia, że materiał klucza nigdy nie opuścił bezpiecznej granicy HSM, sam w sobie jest wystarczającym powodem do podważenia zaufania.

Incydent ma również szersze znaczenie dla rynku CA. Pokazuje, że nawet przy użyciu certyfikowanych HSM ryzyko może wynikać z niestandardowych narzędzi automatyzujących, wyjątków proceduralnych oraz niedostatecznych mechanizmów kontroli po ceremonii kluczy.

Rekomendacje

Organizacje wykorzystujące certyfikaty eMudhra powinny przeprowadzić pełną inwentaryzację certyfikatów TLS oraz code signing i ustalić, czy którykolwiek z nich łańcuchuje się do unieważnionych pośrednich CA. Następnie należy zaplanować ich szybką reemisję oraz wdrożenie w systemach produkcyjnych i pośrednich.

wyeliminować procedury, w których materiał klucza prywatnego opuszcza HSM, nawet tymczasowo;
zakazać używania niestandardowych skryptów do migracji kluczy bez formalnej walidacji kryptograficznej i przeglądu bezpieczeństwa;
wdrożyć kontrole porównujące klucz wygenerowany z kluczem certyfikowanym, w tym testy integralności i siły klucza;
zapewnić pełne logowanie oraz niezależny nadzór nad ceremoniami kluczy;
ograniczyć wyjątki od bezpiecznych konfiguracji i trybów zgodności HSM;
regularnie ćwiczyć scenariusze reagowania na incydenty PKI, w tym szybkie wycofanie CA i masową wymianę certyfikatów.

Dobrą praktyką pozostaje również monitorowanie logów Certificate Transparency oraz testowanie zachowania aplikacji i urządzeń, które mogą inaczej egzekwować zasady walidacji niż główne przeglądarki internetowe.

Podsumowanie

Przypadek eMudhra pokazuje, że bezpieczeństwo PKI zależy nie tylko od jakości algorytmów i sprzętu HSM, ale również od ścisłego przestrzegania procedur operacyjnych. Osiem dodatkowych unieważnień nie wynikało z bezpośredniego złamania kryptografii RSA, lecz z niemożności wykazania, że klucze były obsługiwane wyłącznie w dopuszczalnym modelu bezpieczeństwa.

Dla branży cybersecurity to ważne przypomnienie, że zaufanie do publicznej infrastruktury certyfikatów można utracić nie tylko przez techniczną kompromitację, ale także przez brak dowodów zgodności procesu z wymaganiami bezpieczeństwa.