Mamy problem – czyli jak CA “generował” klucze na podstawie XKCD
Indyjski urząd certyfikacji eMudhra wygenerował skrajnie słabe klucze ECDSA, co pozwala odtworzyć klucz prywatny w milisekundy i prowadzić ataki MitM.
17 października badacz Wayne zgłosił przejęcie kluczy prywatnych ośmiu pośrednich CA należących do indyjskiego dostawcy eMudhra. Jako dowód podpisał komunikat „We have a problem here – Wayne” każdym z ośmiu kluczy, potwierdzając krytyczną lukę w bezpieczeństwie infrastruktury certyfikatów.
Generowanie kluczy
30 kwietnia 2025 roku podczas ceremonii generowania kluczy doszło do błędu. Klucze ECDSA na krzywej P-384 zostały poddane operacji wrap/unwrap między HSM, co spowodowało wygenerowanie słabych kluczy o entropii zaledwie 8 bitów. Dla jednego z CA klucz prywatny wyniósł d=4.
To nie jest „hasło do certyfikatu”, atakujący nie potrzebował żadnego wycieku czy dostępu do infrastruktury CA. Do odzyskania wystarczył sam publiczny certyfikat.
Skutki luki
Słabe klucze pozwalają odtworzyć klucz prywatny w milisekundy i prowadzić ataki Man-in-the-Middle na dowolną domenę. Problem dotyczy kluczy serii B i C przeznaczonych na rynek europejski i amerykański.
Certyfikaty są blokowane przez przeglądarki i systemy operacyjne na podstawie hashy SPKI. Sectigo usunęło cross-signy, ale niektóre systemy mogą wciąż mieć dostęp do wadliwych certyfikatów.
Reakcja i naprawa
Mozilla i Chrome usunęły root emSign ECC Root CA – G3, co może spowodować problemy z działaniem niektórych certyfikatów do momentu ich podmiany. Administratorzy muszą zaktualizować trust store.
Niestety, nie wszystkie klienty HTTP jak curl czy urządzenia IoT wymuszają Certificate Transparency, co pozostaje potencjalnym zagrożeniem. Użytkownicy powinni przetestować i zaktualizować swoje przeglądarki oraz klienty.
Powiązane
