CERT Polska od lat regularnie ostrzega przed falami SMS-ów podszywających się pod firmy kurierskie (InPost, DPD, DHL), które namawiają do zainstalowania rzekomej „aplikacji do śledzenia przesyłki” — w rzeczywistości złośliwego pliku APK. Ponieważ taki plik nigdy nie trafia do oficjalnego sklepu z aplikacjami, jedynym sposobem sprawdzenia, czy pobrany plik jest tym, za co się podaje, jest porównanie jego sumy kontrolnej z wartością opublikowaną przez prawdziwego nadawcę — o ile w ogóle taka istnieje.
Jak suma kontrolna wykrywa uszkodzenie lub manipulację
Z powodu efektu lawinowego funkcji skrótu, niezależnie od tego, czy zmiana wynika z uszkodzenia podczas transferu, czy z celowej modyfikacji, zmiana pojedynczego bajtu całkowicie zmienia obliczony skrót pliku. Dlatego jakakolwiek rozbieżność między oczekiwaną a obliczoną sumą kontrolną jednoznacznie oznacza, że plik różni się od oryginału — bajt po bajcie.
Czego suma kontrolna nie gwarantuje
Zgodność skrótów potwierdza jedynie, że plik jest identyczny z tym, z którego obliczono opublikowany skrót — nie to, że ten oryginał jest bezpieczny. Jeśli sam fałszywy nadawca publikuje złośliwy plik razem z „pasującą” do niego sumą kontrolną, weryfikacja niczego nie wykryje — dlatego wartość referencyjną trzeba brać z oficjalnej strony firmy, a nie z tego samego źródła, z którego pochodzi podejrzany plik.
Suma kontrolna kontra podpis cyfrowy
W przeciwieństwie do sumy kontrolnej, podpis cyfrowy jest tworzony kluczem prywatnym i można go zweryfikować tylko odpowiadającym mu kluczem publicznym. Google Play weryfikuje taki podpis automatycznie przy instalacji; przy ręcznym instalowaniu APK (sideloading) ta ochrona znika, a ręczne porównanie sumy kontrolnej pozostaje jedynym dostępnym zabezpieczeniem.
Do czego to się przydaje
- Sprawdzenie, czy plik APK pobrany spoza oficjalnego sklepu nie został zmodyfikowany.
- Szybkie porównanie dwóch dużych plików bez porównywania bajt po bajcie.
- Sprawdzenie, że kopia zapasowa pliku jest identyczna z oryginałem.
Dlaczego czasem używa się CRC32 zamiast SHA-256
CRC32 jest znacznie szybszy niż kryptograficzne funkcje skrótu, ale można go łatwo celowo sfałszować — to nie problem przy wykrywaniu przypadkowego uszkodzenia podczas transmisji, ale nieodpowiednia ochrona przed atakującym, który chce niezauważenie podmienić plik. Dlatego CRC32 wciąż spotyka się w archiwizatorach i protokołach sieciowych do kontroli błędów, a nie tam, gdzie liczy się właśnie bezpieczeństwo.