Przegląd
Android 13 obsługuje schemat podpisów APK w wersji 3.1, co stanowi ulepszenie istniejącego schematu podpisów APK w wersji 3 . Schemat v3.1 rozwiązuje niektóre znane problemy ze schematem podpisu APK v3 dotyczące rotacji. W szczególności schemat podpisu w wersji 3.1 obsługuje kierowanie na wersję SDK, co umożliwia rotację w celu skierowania na nowszą wersję platformy.
Schemat podpisu w wersji 3.1 wykorzystuje identyfikator bloku, który nie jest rozpoznawany w systemie Android 12 lub starszym. Dlatego platforma stosuje następujące zachowanie osoby podpisującej:
- Urządzenia z systemem Android 13 lub nowszym korzystają z obróconego podpisu w bloku v3.1.
- Urządzenia ze starszymi wersjami Androida ignorują obróconego podpisującego i zamiast tego używają oryginalnego podpisującego w bloku v3.
Aplikacje, które nie zmieniły jeszcze swojego klucza podpisu, nie wymagają żadnych dodatkowych działań. Za każdym razem, gdy te aplikacje zdecydują się na rotację, system domyślnie stosuje schemat podpisu w wersji 3.1.
Blok podpisywania wersji 3.1
Blok podpisywania w wersji 3.1 będzie miał taką samą zawartość jak blok podpisywania w wersji 3, ale dzięki nowemu identyfikatorowi bloku podpisy te będą rozpoznawane tylko na urządzeniach z systemem Android 13 i nowszym. Dzięki temu aplikacje mogą bezpiecznie zmieniać swoje klucze podpisywania bez martwienia się o wielodocelowe pliki APK, ponieważ oryginalna osoba podpisująca może zostać użyta do podpisania pliku APK w bloku podpisywania wersji 3, a obrócona osoba podpisująca w bloku podpisywania wersji 3.1. Umożliwia to również platformie ponowne wykorzystanie wszystkich istniejących kodów weryfikacyjnych dla bloku podpisywania wersji 3 podczas weryfikacji podpisu wersji 3.1.
Domyślnie biblioteka apksig będzie używać bloku podpisywania wersji 3.1 za każdym razem, gdy w konfiguracji podpisywania zostanie podany obrócony klucz i pochodzenie. Jeśli minSdkVersion aplikacji jest mniejsza niż Android 13 i używany jest klucz obrócony, należy również określić oryginalny klucz podpisywania, aby można go było użyć do podpisania pliku APK w bloku podpisywania wersji 3. Jest to podobne do obecnego zachowania, w którym wymagany jest oryginalny podpisujący, jeśli plik APK jest przeznaczony dla wersji wcześniejszej niż Android 9.
Aby obsługiwać rotację kluczy docelowych, począwszy od określonej wersji zestawu SDK, biblioteka apksig udostępni nowe interfejsy API, które pozwolą ustawić minimalną wersję zestawu SDK do rotacji. Jeśli jako minimalną wersję do obsługi rotacji określono wersję zestawu SDK w wersji starszej niż Android 13, wówczas oryginalna wersja v3 blok będzie używany. Blok podpisywania wersji 3.1 jest używany tylko w przypadku rotacji, gdy minimalna wersja pakietu SDK do rotacji jest ustawiona na Android 13 i nowsze wersje. Blok podpisywania wersji 3 będzie miał nowy atrybut zapewniający ochronę przed usuwaniem minimalnej wersji pakietu SDK w przypadku rotacji.
| APK zawiera pochodzenie | Wartość wersji-min-sdk-rotacji | blok podpisywania wersji 3 | Blok podpisywania wersji 3.1 |
|---|---|---|---|
| NIE | Wartość domyślna lub dowolna (reprezentowana przez x poniżej) | Podpisano z oryginalnym sygnatariuszem, dla systemu Android 9 i nowszych wersji | Nieobecny |
| Tak | Domyślny | Podpisano z oryginalnym sygnatariuszem, dla Androida 9–12L | Podpisano z rotacją sygnatariusza, dla Androida 13 i nowszych wersji |
| Tak | x < 33 (Android 13) | Podpisano z rotacją sygnatariusza, dla systemu Android 9 i nowszych wersji | Nieobecny |
| Tak | x >= 33 (Android 13) | Podpisano z oryginalnym sygnatariuszem, dla systemu Android 9 - ( x -1) | Podpisano z obróconym podpisującym, kierowanie na x+ |
Problemy związane z rotacją
Na platformie rozwiązano następujące problemy związane z rotacją:
Poprawki Androida 12
- Platforma przyznałaby uprawnienia do podpisu aplikacji żądającej tylko wtedy, gdyby bieżący sygnatariusz dowolnej aplikacji należał do linii podpisywania lub był bieżącym sygnatariuszem drugiej aplikacji; zapobiega to przyznaniu uprawnień do podpisu aplikacji żądającej, jeśli obie aplikacje przestrzegają najlepszych praktyk związanych z kluczami podpisywania i przełączają się na różne klucze podpisywania.
- Funkcja wycofywania pakietu APK na platformie nie mogła wycofać pliku APK, którego klucz podpisywania właśnie został zmieniony, chyba że poprzedni klucz w linii podpisywania miał możliwość wycofywania, ale ta możliwość jest sprzeczna z celem rotacji, ponieważ umożliwia podpisanie nowej aktualizacji pakietu przez osobę poprzedniego klucza podpisującego i wycofanie obróconego klucza.
- Plik APK podpisany tylko obróconym kluczem, a później zaktualizowany za pomocą pliku APK podpisany oryginalnym kluczem i obróconym kluczem w linii, będzie wyświetlał obrócony klucz w linii tylko na urządzeniach z Androidem 11 i starszym.
Poprawki Androida 11
-
PackageManager#checkSignaturesnie został poprawnie zaktualizowany w celu sprawdzenia oryginalnych kluczy podpisujących dwóch pakietów. Spowodowało to uszkodzenie oprzyrządowania dla aplikacji korzystających z obróconego klucza podpisywania w przypadku pakietu APK oprzyrządowania korzystającego z oryginalnego klucza podpisywania. - Pakiety objęte
sharedUserIdudostępniają swój rodowód podpisu. Za każdym razem, gdy aplikacja ze zaktualizowanym pochodzeniem podpisywania jest instalowana lub aktualizowana we współużytkowanym identyfikatorzesharedUiserId, pochodzenie tej aplikacji zastępuje wspólne pochodzenie dlasharedUserId(to znaczy, jeśli rodowód podpisywania aplikacji to A -> B, a aplikacja jest aktualizowana w dzielonym identyfikatorzesharedUserIdz rodowodem B -> C, wówczas rodowódsharedUserIdzostanie zastąpiony przez B -> C). Podobnie możliwości poprzedniego sygnatariusza w linii nie mogły zostać zaktualizowane, chyba że linia podpisująca została zmieniona.
integracja v4
Schemat podpisu v4 wykorzystuje konfigurację podpisywania dostarczoną do apksigner; w przypadku wielu konfiguracji podpisywania dostępnych do rotacji używana jest najnowsza zmieniona konfiguracja podpisywania. Przed wprowadzeniem wersji 3.1 wersja 3 zawierała tylko najnowszą rotowaną konfigurację podpisywania, więc wersja 4 mogła używać tej konfiguracji w niezmienionej postaci; dzięki temu schemat podpisu v4 był w stanie obsługiwać rotację, ponieważ używał obróconego klucza podpisującego w swoim SigningInfo. Chociaż informacja SigningInfo wersji 4 nie obejmuje pełnego pochodzenia podpisu, jest w stanie pobrać go z bloku podpisywania wersji 3, aby umożliwić platformie dostęp do pochodzenia w przypadku jakichkolwiek zapytań o podpis. Gdy wersja 3.1 jest używana do docelowej rotacji dla dostarczonej wersji rotacji-min-sdk, ogólna konfiguracja v3 będzie zawierać zarówno oryginalną konfigurację podpisywania, jak i najnowszą obróconą konfigurację podpisywania. Utworzono rozszerzenie schematu podpisu w wersji 4, które zawiera dodatkowe bloki informacji o podpisie dla każdej konfiguracji podpisywania z bloku w wersji 3.1.
Walidacja
Aby przetestować implementację wersji 3.1, uruchom testy CTS PkgInstallSignatureVerificationTest.java w cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ .
Więcej informacji na temat testowania można znaleźć w sekcji weryfikacji w wersji 3.