Pierwsza kolizja SHA-1...i co dalej?
#1
Wczoraj (23 lutego) opublikowano ważny komunikat dotyczący powszechnie stosowanego mechanizmu sum kontrolnych SHA-1...dokonało tego Google wraz badaczami z duńskiego laboratorium CWI, a dotyczyło pierwszej udokumentowanej kolizji systemu SHA-1. System ten wykorzystywany jest powszechnie do cyfrowej weryfikacji plików, aplikacji open-sorce, dystrybucji oprogramowania, do kontroli procesów w oprogramowaniu zabezpieczającym, sprawdzania transakcji kartami płatniczymi i wielu z Was na pewno spotkało się z takimi weryfikacjami nawet nie zdając sobie z tego sprawy.
Temat opisano dość dokładnie na Z3S...cytat poniżej
Cytat:Funkcja skrótu to w skrócie algorytm, który oblicza wartość właściwą dla danego pliku czy też po prostu ciągu znaków. W założeniu wartość ta powinna być unikatowa dla danego ciągu i najmniejsza zmiana tego ciągu powinna spowodować istotną zmianę wyniku funkcji skrótu.
(...)
Funkcje skrótu umożliwiają na przykład porównywanie, czy mamy do czynienia z takimi samymi plikami bez oglądania ich znak po znaku – jeśli różnią się ich skróty, to i pliki powinny być różne. Tak samo identyczny skrót powinien oznaczać, że także plik jest identyczny. I tak z reguły jest – dopóki ktoś nie wymyśli, jak stworzyć dwa różne pliki o takim samym skrócie. Ten los właśnie spotkał funkcję SHA-1, a skutki tego wydarzenia są dość istotne.

Funkcja SHA-1 powstała w roku 1995 i już po 10 latach jej istnienia pojawiły się pierwsze prace teoretyczne opisujące, jak można doprowadzić do tzw. kolizji – czyli wygenerowania dwóch plików dających ten sam skrót. Prace teoretyczne pozostawały jednak teoretyczne przez 12 lat, choć zdawano sobie sprawę z tego, że droga od teorii do praktyki jest coraz krótsza.
(...)
Wszystko zależy od tego, o jakim zastosowaniu skrótu SHA-1 mówimy. Jednym z najważniejszych (i potencjalnie niosących największe zagrożenie) jest użycie skrótu SHA-1 w certyfikatach SSL witryn WWW. Odnalezienie kolizji oznacza, że dla certyfikatów opartych o SHA-1 ktoś znający sposób doprowadzenia do kolizji mógłby wygenerować fałszywy certyfikat, który przeglądarki uznałyby za prawdziwy. Zatem kolizja SHA-1 może dać atakującemu możliwość podsłuchania i modyfikacji zaszyfrowanego ruchu WWW. Dlaczego jednak nie powinniśmy z tego powodu panikować? Powodów jest kilka.

Po pierwsze odnalezienie kolizji nikogo nie zaskoczyło. Certyfikaty SHA-1 od paru lat są już wycofywane i uznawane za przestarzałe. Google w swojej przeglądarce Chrome od stycznia tego roku automatycznie uznaje je za niebezpieczne i ostrzega przed nimi użytkowników. Lada moment dołączy do niego Firefox.

Po drugie żadna instytucja wydająca certyfikaty SSL nie powinna już wydawać certyfikatów opartych na SHA-1. Co prawda był przypadek firmy, które spróbowała to zrobić, antydatując certyfikat, ale została szybko wykryta i jej kariera w branży się skończyła – przeglądarki przestały ufać jej certyfikatom.

Po trzecie przeprowadzenie kolizji nie jest trywialne – jak wskazuje Google, wymaga najpierw 6500 lat pracy procesora CPU, a następnie 110 lat pracy procesora GPU (oczywiście alternatywą jest np. zapędzenie do pracy 6500 CPU i 110 GPU na rok).  Wobec powszechnej dostępności technik obliczeniowych można przyjąć, że jest to atak do przeprowadzenia dla średnio zasobnego atakującego, jednak ciągle jest poza zasięgiem np. większości studentów.
(...)
Gdzie jeszcze możemy mieć potencjalny problem z kolizją SHA-1? Funkcją tą mogą posługiwać się systemy backupowe do sprawdzania, czy dany plik uległ modyfikacji, platformy podpisów cyfrowych dokumentów (tu mamy spore ryzyko dla wiarygodności podpisu, skoro można zmodyfikować podpisany dokument i dalej zachowa on prawidłowość podpisu), aktualizacje oprogramowania podpisywane cyfrowo czy wszystkie inne sumy kontrolne, gdzie ufamy funkcji SHA-1.

Gdzie problem nie jest poważny? Raczej możemy nadal podawać funkcje skrótu złośliwych plików w wersji SHA-1 (tak jak i MD5), chyba, że obawiamy się, że ktoś będzie nam chciał spłatać figla i poświęcić trochę zasobów by wyprodukować inny plik o tej samej sumie. Na podstawie samej sumy nie podejmowalibyśmy się automatycznego kasowania pliku z systemu – lecz do wyszukiwania w Google nadal będzie ona przydatna.
cytat za

[Aby zobaczyć linki, zarejestruj się tutaj]


Poniższa infografika ilustruje podstawowe fakty związane z tym odkryciem

[Aby zobaczyć linki, zarejestruj się tutaj]

źródło

[Aby zobaczyć linki, zarejestruj się tutaj]



Stworzono specjalny serwis do weryfikacji (póki co) plików PDF

[Aby zobaczyć linki, zarejestruj się tutaj]

ale Google wprowadziło takie zabezpieczenie w postaci automatycznej weryfikacji dla użytkowników Gmaila i Google Drive.
Kolejnym krokiem w tej sprawie jest również decyzja Mozilli o wyłączeniu SHA-1 w wersji 52

[Aby zobaczyć linki, zarejestruj się tutaj]


Komunikat CWI

[Aby zobaczyć linki, zarejestruj się tutaj]

Komunikat Google

[Aby zobaczyć linki, zarejestruj się tutaj]

"Bezpieczeństwo jest podróżą, a nie celem samym w sobie - to nie jest problem, który można rozwiązać raz na zawsze"
"Zaufanie nie stanowi kontroli, a nadzieja nie jest strategią"
Odpowiedz
#2
Cytuje: Nie trzeba mieć superkomputera by stworzyć pliki PDF mające identyczne sumy kontrolne SHA1

[Aby zobaczyć linki, zarejestruj się tutaj]

Odpowiedz
#3
Dzień dobry, wszyscy umrzemy.

Bo to są tego skutki.
1. Zawsze mam rację.
2. Jeśli nie mam racji, patrz pkt 1.
Odpowiedz


Skocz do:


Użytkownicy przeglądający ten wątek: 1 gości