Podpisywanie aplikacji pozwala programistom zidentyfikować autora aplikacji i zaktualizować swoją aplikację bez tworzenia skomplikowanych interfejsów i uprawnień. Każda aplikacja działająca na platformie Android musi być podpisana przez programistę . Aplikacje próbujące zainstalować bez podpisu zostaną odrzucone przez Google Play lub instalatora pakietu na urządzeniu z Androidem.
W Google Play podpisywanie aplikacji łączy zaufanie, jakim Google darzy programistę, oraz zaufanie, jakim programista darzy swoją aplikację. Programiści wiedzą, że ich aplikacja jest dostarczana w stanie niezmodyfikowanym na urządzenia z systemem Android; i programiści mogą zostać pociągnięci do odpowiedzialności za zachowanie swoich aplikacji.
W systemie Android podpisanie aplikacji jest pierwszym krokiem do umieszczenia aplikacji w piaskownicy aplikacji. Podpisany certyfikat aplikacji określa, który identyfikator użytkownika jest powiązany z daną aplikacją; różne aplikacje działają pod różnymi identyfikatorami użytkowników. Podpisywanie aplikacji gwarantuje, że jedna aplikacja nie będzie mogła uzyskać dostępu do żadnej innej aplikacji inaczej niż za pośrednictwem dobrze zdefiniowanego IPC.
Po zainstalowaniu aplikacji (pliku APK) na urządzeniu z systemem Android Menedżer pakietów sprawdza, czy plik APK został poprawnie podpisany certyfikatem zawartym w tym pliku APK. Jeśli certyfikat (a dokładniej klucz publiczny w certyfikacie) jest zgodny z kluczem używanym do podpisywania dowolnego innego pliku APK na urządzeniu, nowy plik APK ma opcję określenia w manifeście, że w podobny sposób będzie dzielić UID z innym -podpisane pliki APK.
Aplikacje mogą być podpisane przez stronę trzecią (OEM, operator, rynek alternatywny) lub z podpisem własnym. Android umożliwia podpisywanie kodu przy użyciu certyfikatów z podpisem własnym, które programiści mogą generować bez pomocy i pozwolenia z zewnątrz. Wnioski nie muszą być podpisane przez organ centralny. Android obecnie nie przeprowadza weryfikacji certyfikatów aplikacji przez urząd certyfikacji.
Aplikacje mogą również deklarować uprawnienia bezpieczeństwa na poziomie ochrony podpisu, ograniczając dostęp tylko do aplikacji podpisanych tym samym kluczem, zachowując jednocześnie odrębne UID i piaskownice aplikacji. Bliższa relacja ze współdzieloną piaskownicą aplikacji jest dozwolona przy użyciu funkcji współdzielonego UID , w której dwie lub więcej aplikacji podpisanych tym samym kluczem programisty może zadeklarować w swoim manifeście współdzielony UID.
Schematy podpisywania plików APK
Android obsługuje trzy schematy podpisywania aplikacji:
- schemat v1: oparty na podpisie JAR
- schemat v2: Schemat podpisu APK v2 , który został wprowadzony w systemie Android 7.0.
- schemat v3: Schemat podpisu APK v3 , który został wprowadzony w systemie Android 9.
Aby uzyskać maksymalną kompatybilność, podpisuj aplikacje wszystkimi schematami, najpierw v1, następnie v2, a następnie v3. Urządzenia z Androidem 7.0 lub nowszym instalują aplikacje podpisane schematami v2+ szybciej niż te podpisane tylko schematem v1. Starsze platformy Android ignorują podpisy v2+ i dlatego aplikacje muszą zawierać podpisy v1.
Podpisywanie JAR (schemat v1)
Podpisywanie plików APK było częścią Androida od samego początku. Opiera się na podpisanym formacie JAR . Aby uzyskać szczegółowe informacje na temat korzystania z tego schematu, zobacz dokumentację Android Studio dotyczącą podpisywania aplikacji .
Podpisy v1 nie chronią niektórych części pliku APK, takich jak metadane ZIP. Weryfikator APK musi przetworzyć wiele niezaufanych (jeszcze nie zweryfikowanych) struktur danych, a następnie odrzucić dane nieobjęte podpisami. Zapewnia to znaczną powierzchnię ataku. Co więcej, weryfikator APK musi zdekompresować wszystkie skompresowane wpisy, co zajmuje więcej czasu i pamięci. Aby rozwiązać te problemy, w systemie Android 7.0 wprowadzono schemat podpisu APK v2.
Schemat podpisu APK v2 i v3 (schemat v2+)
Urządzenia z systemem Android 7.0 i nowszym obsługują schemat podpisu APK w wersji 2 (schemat v2) i nowsze. (Schemat wersji 2 został zaktualizowany do wersji 3 w systemie Android 9, aby uwzględnić dodatkowe informacje w bloku podpisywania, ale poza tym działa tak samo). Zawartość pliku APK jest szyfrowana i podpisana, a następnie powstały blok podpisywania pliku APK jest wstawiany do pliku APK. Aby uzyskać szczegółowe informacje na temat stosowania schematu v2+ do aplikacji, zobacz Schemat podpisu APK v2 .
Podczas sprawdzania poprawności schemat v2+ traktuje plik APK jako obiekt typu blob i sprawdza podpis w całym pliku. Wszelkie modyfikacje pliku APK, w tym modyfikacje metadanych ZIP, unieważniają podpis APK. Ta forma weryfikacji APK jest znacznie szybsza i umożliwia wykrycie większej liczby klas nieautoryzowanych modyfikacji.
Nowy format jest kompatybilny wstecz, więc pliki APK podpisane w nowym formacie podpisu można zainstalować na starszych urządzeniach z Androidem (które po prostu ignorują dodatkowe dane dodawane do pliku APK), o ile te pliki APK są również podpisane w wersji 1.
Rysunek 1. Proces weryfikacji podpisu APK
Skrót całego pliku APK jest weryfikowany na podstawie podpisu v2+ przechowywanego w bloku podpisywania APK. Hash obejmuje wszystko z wyjątkiem bloku podpisywania APK, który zawiera podpis v2+. Jakakolwiek modyfikacja pliku APK poza blokiem podpisywania pliku APK unieważnia podpis pliku APK w wersji 2+. Pliki APK z pozbawionym podpisu v2+ są również odrzucane, ponieważ ich podpis w wersji 1 określa, że plik APK był podpisany w wersji 2, co powoduje, że Android 7.0 i nowsze wersje odmawiają weryfikacji plików APK przy użyciu podpisów w wersji 1.
Aby uzyskać szczegółowe informacje na temat procesu weryfikacji podpisu APK, zobacz sekcję Weryfikacja w schemacie podpisu APK v2.