Tym razem nie chodzi o teoretyczne rozważania. Znaleziono prawdopodobnie pierwszą rzeczywistą kolizję funkcji skrótu SHA-1.

Za wykonaną pracę brawa należą się pracownikom holenderskiego instytutu badawczego oraz Google.

Dwa różne PDFy, ten sam skrót

Przechodząc z miejsca do konkretów. Tutaj macie dwa różne dokumenty PDF

PDF numer 1

PDF numer 2

a wartość skrótu SHA-1 dla nich jest identyczna:

openssl dgst -sha1 shattered-1.pdf

  SHA1(shattered-1.pdf)= 38762cf7f55934b34d179ae6a4c80cadccbb7f0a

openssl dgst -sha1 shattered-2.pdf

  SHA1(shattered-2.pdf)= 38762cf7f55934b34d179ae6a4c80cadccbb7f0a

To, że dokumenty są różne potwierdza skrót SHA-256:

openssl dgst -sha256 shattered-1.pdf

  SHA256(shattered-1.pdf)= 2bb787a73e37352f92383abe7e2902936d1059ad9f1ba6daaa9c1e58ee6970d0

openssl dgst -sha256 shattered-2.pdf

  SHA256(shattered-2.pdf)= d4488775d29bdef7993367d541064dbdda50d383f89f0aa13a6ff2e0894ba5ff

Sprawdźcie sami.

Źródło: security.googleblog.com

Co to oznacza?

Funkcje skrótu wykorzystywane są w wielu miejscach. Ich chyba najpopularniejsze zastosowanie to tworzenie podpisu cyfrowego wykorzystywanego chociażby w podpisie elektronicznym (rozumianym jako odpowiednik podpisu odręcznego) i certyfikatach SSL. Zanim podpisywana wiadomość zostanie poddana przekształceniom przy użyciu klucza prywatnego generowany jest z niej skrót – tak w skrócie realizowany jest podpis cyfrowy.

Co grozi nam więc w przypadku gdy mamy dwa różne dokumenty dające ten sam skrót i w konsekwencji ten sam podpis? Na przykładzie podpisu elektronicznego: załóżmy, że mamy umowę na której zarobimy 1 milion złotych i taki też dokument podpisujemy elektronicznie. Nasz (nieuczciwy) zleceniodawca mający możliwość wygenerowania kolizji tworzy nowy dokument (o takim samym skrócie jak dokument właściwy) na dużą niższą kwotę  100 000 złotych. I teraz uwaga, podpis pod takim dokumentem zostanie zweryfikowany tak samo prawidłowo jak pod właściwą umową. Innymi słowy, podpisaliśmy umowę, której nie nawet widzieliśmy.

Jak wygląda pod tym kątem sytuacja w polskim podpisie elektronicznym? Mówiąc delikatnie: nienajlepiej. Do momentu obowiązywania starej ustawy o podpisie elektronicznym (od września 2001 do czerwca 2016) SHA-1 był właściwie jedyną opcją stosowaną przez wszystkich i wszędzie. Niestety, ale dokumentów oraz certyfikatów narażonych na kolizję funkcji skrótu SHA-1 znajdziemy w polskich urzędach i firmach bez liku.

W przypadku certyfikatów SSL podpisanych cyfrowo za pomocą funkcji skrótu SHA-1 ryzyko jest analogiczne. Na przykład, gdy komuś uda się znaleźć kolizję dla certyfikatu zainstalowanego w domenie google.com to będzie on w stanie wygenerować taki certyfikat, który przez przeglądarki będzie weryfikowany w identyczny sposób jak oryginalny. W konsekwencji atakujący będzie w stanie odczytać szyfrowaną komunikację.

Jak się chronić?

Tam gdzie to tylko możliwe korzystać z bezpieczniejszych funkcji skrótu tj. z rodziny SHA-2 (SHA-256, SHA-384, SHA-512).

W przypadku podpisu elektronicznego po wejściu w życie rozporządzenia eIDAS sytuacja powinna się stopniowo poprawiać, ponieważ korzystanie z SHA-1 nie jest już dozwolone. Nie zmienia to jednak faktu, że wciąż wiele nowych podpisów (a nawet certyfikatów) zostanie wygenerowanych przy użyciu SHA-1. Gdy tylko nadarzy się okazja należy je zastępować nowymi, bezpieczniejszymi.

Przeglądarki także dużo wcześniej rozpoczęły wycofywanie certyfikatów SSL SHA-1 z powszechnego użycia, a urzędy certyfikacji od dawna takich certyfikatów SSL nie wystawiają. Obecnie już tylko ułamek stron WWW nie korzysta z certyfikatów opartych na SHA-256. Jeżeli więc gdzieś wykorzystywane są certyfikaty SSL SHA-1 to jest to najwyższy czas na aktualizację.

Na koniec słowo otuchy. Badacze określili, że do znalezienia kolizji konieczne jest wykonanie ponad 9,223,372,036,854,775,808 prób co wymaga najpierw 6500 lat pracy pojedynczego procesora CPU i następnie (jako druga faza) 110 lat procesora GPU. I tutaj jednak trzeba jednak mieć na uwadzę to, że wykorzystanie dużych klastrów obliczeniowych znacznie ten czas skróci i sprawi, że fałszowanie podpisów cyfrowych nie będzie już tak niepraktyczne jak mogłoby się wydawać na pierwszy rzut oka.

Dla zainteresowanych, Google podzieli się kodem źródłowym dzięki któremu znaleziono kolizję za około 3 miesiące.