Podpisywanie aplikacji na Androida: jak to działa i dlaczego jest to ważne

Za każdym razem, gdy instalujesz aplikację na telefonie z Androidem, w tle odbywa się cicha, ale kluczowa kontrola bezpieczeństwa. Telefon weryfikuje podpis cyfrowy pakietu APK. To kryptograficzne potwierdzenie uniemożliwia hakerom wstrzykiwanie złośliwego oprogramowania do aplikacji, zapewniając jednocześnie programistom możliwość publikowania aktualizacji bez utraty tożsamości.

Jeśli piszesz aplikacje, podpisywanie jest czymś, co po prostu musisz zrobić dobrze; jeśli po prostu lubisz majstrować przy Androidzie, jest to jedna z najbardziej satysfakcjonujących części systemu do zrozumienia. Tak czy inaczej, jak działa podpisywanie aplikacji jest wart Twojego czasu. Poniżej omawiamy technologię, ewolucję schematów podpisywania i sposób korzystania z ręcznie zweryfikuj certyfikaty online.

Co to jest podpisywanie aplikacji?

Zasadniczo podpisywanie aplikacji to proces, w którym programista używa Klucz prywatny do wygenerowania bloku podpisu dla plików swojej aplikacji. Odpowiedni plik Klucz publiczny jest następnie osadzany w pliku APK w folderze META-INF. Gdy telefon próbuje zainstalować aplikację, korzysta z klucza publicznego, aby sprawdzić, czy podpis jest zgodny z zawartością pliku.

Zapewnia to dwie główne właściwości:

1. Niezmienność: Jeśli choć jeden bajt kodu aplikacji zostanie zmieniony (np. przez trojana), podpis nie będzie już zgodny z plikiem, a system Android odmówi jego instalacji.
2. Dowód tożsamości: Jeśli aplikacja próbuje zaktualizować istniejącą, jej podpisy muszą się zgadzać. Dlatego nie można zainstalować zmodyfikowanej aplikacji Facebook zamiast oficjalnej.

Ewolucja schematów podpisywania

Google stale ulepsza mechanizm podpisywania, aby poprawić zarówno szybkość, jak i bezpieczeństwo:

• V1 (podpisywanie słoików): Podpisuje pojedyncze pliki w pliku APK (ZIP). Jest to powolne, ponieważ system operacyjny musi rozpakować i sprawdzić każdy plik. Jest również podatny na pewne manipulacje ZIP.
• V2 (schemat podpisu APK): Podpisuje cały blok binarny pliku APK. Nie wymaga rozpakowywania w celu weryfikacji, dzięki czemu jest niezwykle szybki. Został wprowadzony w systemie Android 7.0 (Nougat).
• V3 (obrót klawisza): Rozszerza wersję 2, dodając „linię” kluczy. Pozwala programiście udowodnić, że nowy klucz jest autoryzowanym następcą starszego. Wprowadzono w systemie Android 9.0 (Pie).
• V4 (podpisywanie strumieniowe): Zaprojektowany specjalnie do instalacji przyrostowych, umożliwia weryfikację aplikacji w trakcie ich pobierania przez USB lub Wi-Fi.

Dlaczego certyfikaty mają znaczenie w przypadku ładowania bocznego

Gdy pobierasz plik APK z nieoficjalnego źródła, Haszowanie certyfikatu staje się Twoim najlepszym przyjacielem. Odcisk palca certyfikatu (taki jak skrót SHA-256) jednoznacznie identyfikuje klucz podpisu programisty. Każda aplikacja zachowuje ten sam klucz podpisu we wszystkich swoich aktualizacjach, dzięki czemu możesz porównać odcisk palca pliku APK z wartością opublikowaną przez programistę, aby potwierdzić, że jest on autentyczny.

Jeśli podejrzewasz, że plik APK jest fałszywy, powinieneś uruchomić go przez nasz Weryfikator pakietu APK online. Nasze narzędzie pokaże Ci:

• Numer Nazwa zwyczajowa (CN) podpisującego (np. „Android”).
• Okres ważności certyfikatu.
• Odciski palców SHA-1/SHA-256.

Jak Android weryfikuje podpis podczas instalacji

Krok „zweryfikuj certyfikat” jest tak często pomijany, że warto przyjrzeć się, co faktycznie robi system operacyjny, gdy klikniesz plik APK, a Android zdecyduje, czy go zainstalować:

1. Otwórz plik APK w formacie ZIP i zlokalizuj blok podpisu. Dla podpisów v2/v3 jest to blok strukturalny bezpośrednio przed katalogiem centralnym; dla starszego schematu v1 jest to zawartość META-INF/*.RSA, *.DSA lub *.EC.
2. Oblicz skróty SHA-256 co drugiego bajtu pliku APK. Blok podpisu jest wykluczony z własnego podsumowania; wszystko inne jest mieszane w określonych fragmentach.
3. Sprawdź podsumowanie każdego fragmentu względem podsumowań zapisanych w bloku podpisu. Jeśli od czasu podpisania pliku przez programistę zmieniono choćby jeden bajt, skróty nie będą zgodne, a instalacja zostanie odrzucona i wyświetli się ogólny błąd „Aplikacja nie została zainstalowana”.
4. Sprawdź, czy sam blok podpisu został utworzony przy użyciu klucza prywatnego certyfikatu. Klucz publiczny certyfikatu służy do sprawdzenia podpisu kryptograficznego w bloku. Pomyślne sprawdzenie oznacza, że ​​osoba podpisująca plik posiadała klucz prywatny powiązany z tym certyfikatem.
5. Porównaj odcisk palca certyfikatu z dowolną istniejącą instalacją o tej samej nazwie pakietu. Jeśli pakiet jest już zainstalowany, a nowy plik APK jest podpisany innym certyfikatem, instalacja zostanie odrzucona za pomocą INSTALL_FAILED_UPDATE_INCOMPATIBLE. Jest to główna obrona systemu operacyjnego przed podszywaniem się pod inne osoby: złośliwy aktor nie może zastąpić aplikacji bankowej własną kopią, chyba że ukradnie również klucz podpisywania banku.

Nic z tego nie dowodzi, że programista jest godny zaufania, a jedynie to, że plik, który masz zamiar zainstalować, jest identyczny pod względem bajtów z tym, co podpisali i że żadna inna strona nie majstrowała przy nim. Zaufanie do programisty to osobna decyzja, którą podejmujesz, decydując, z jakich źródeł instalujesz.

Co naprawdę oznacza „niezgodność podpisu”

Najczęstszą niespodzianką, jaką spotykają się ludzie podczas ładowania bocznego, jest błąd „niezgodność podpisu” podczas aktualizacji. Oto, co się właściwie dzieje:

• Masz zainstalowany Aplikacja X w wersji 1.0 ze Sklepu Play.
• Pobierasz Aplikacja X w wersji 1.1 ze źródła innego niż Play.
• System operacyjny widzi tę samą nazwę pakietu (com.example.app), ale plik APK jest podpisany innym certyfikatem (kluczem podpisu pobocznego źródła, a nie oryginalnego wydawcy). Odmawia instalacji.

W praktyce dzieje się to na dwa sposoby:

1. Plik APK innej firmy to rzeczywiście od innego wydawcy, na przykład kopia „zmodyfikowana” lub „poprawiona”. Odmowa instalacji jest właściwym zachowaniem; zainstalowanie go oznaczałoby powierzenie nieznajomemu tych samych danych, z których korzystała już aplikacja Twojego banku.
2. Plik APK innej firmy to ponowne przesłanie oficjalnego pakietu APK, ale system podpisywania aplikacji Google Play podpisuje pliki pobierane przez każdego użytkownika za pomocą opakowania prześlij klucz użytkownika. Czasami dwa urządzenia mogą widzieć nieco inne dane podpisu dla tej samej koncepcyjnej wersji aplikacji. W takim przypadku odcisk palca certyfikatu w katalogu głównym nadal będzie zgodny; możesz to sprawdzić za pomocą naszego Weryfikator APK.

Jeśli odcisk palca certyfikatu naprawdę różni się od istniejącej instalacji, jedynym rozwiązaniem jest najpierw odinstalowanie bieżącej kopii (utrata danych) przed załadowaniem zamiennika, nigdy nie wyłączając weryfikacji podpisu.

Generowanie własnego klucza podpisywania (dla programistów)

Jeśli tworzysz aplikacje na Androida, w końcu będziesz musiał podpisać własne kompilacje. Standardowe polecenie jednowierszowe wykorzystujące keytool z pakietu Java SDK to:

keytool -genkeypair -v \
        -keystore my-release.keystore \
        -alias my-app -keyalg RSA -keysize 2048 \
        -validity 10000

Warto wiedzieć dwie rzeczy:

• ważność ma znaczenie: 10000 dni (około 27 lat) to wartość konwencjonalna, ponieważ system operacyjny traktuje aktualizacje podpisane kluczem, który wkrótce wygasł lub wygasł, jako zagrożone. Wygeneruj raz klucz o długiej żywotności i chroń go.
• Po opublikowaniu nie można łatwo przełączać kluczy. Schemat podpisywania wersji 3 dodaje klucz obrót jako wyraźną funkcję: stary certyfikat „błogosławi” nowy poprzez przechowywany dowód, umożliwiając systemowi operacyjnemu akceptowanie aktualizacji z nowego klucza, zachowując jednocześnie ciągłość tożsamości. Bez wersji 3 utrata oryginalnego klucza oznacza osierocenie wszystkich istniejących instalacji.

W przypadku ładowanych z boku kompilacji testowych niepodpisany magazyn kluczy debugowania jest w porządku; do celów produkcyjnych użyj chronionego hasłem magazynu kluczy o długim okresie ważności, przechowywanego w kopii zapasowej offline.

Typowe pułapki związane z podpisywaniem

1. Certyfikaty z podpisem własnym: Większość aplikacji na Androida ma podpis własny. W przeciwieństwie do protokołu SSL w przypadku witryn internetowych nie ma centralnego organu odpowiedzialnego za podpisywanie aplikacji na Androida. Musisz bezpośrednio zaufać programiście.
2. Certyfikaty debugowania: Aplikacje stworzone do testowania używają ogólnego klucza „debugowania”. Te aplikacje nigdy nie powinny być udostępniane publicznie, ponieważ są blokowane przez wiele filtrów bezpieczeństwa.
3. Utrata klucza: Jeśli programista utraci swój prywatny magazyn kluczy, może nigdy ponownie zaktualizować swoją aplikację. Musieliby wypuścić „nową” aplikację z inną nazwą pakietu.

Wybór odpowiedniego schematu podpisywania dla docelowego zestawu SDK

Podpisywanie aplikacji po cichu stanowi podstawę dużej części bezpieczeństwa Androida. Po kliknięciu relacji klucza prywatnego/publicznego możesz ocenić pobraną aplikację pod kątem jej zalet i potwierdzić, że to, co instalujesz, nie zostało zmienione od czasu podpisania jej przez programistę. Więcej informacji na temat wewnętrznych elementów systemu Android można znaleźć w naszym przewodnik po formacie XAPK.