Schemat podpisu APK v3

9 obsługuje Android apk obrót klucza , co daje aplikacjom możliwość zmiany swojego klucza podpisu jako część aktualizacji APK. Aby rotacja była praktyczna, pakiety APK muszą wskazywać poziomy zaufania między nowym a starym kluczem podpisywania. Aby wspierać obrót klucza, zaktualizowaliśmy schematu podpisu APK z v2 do v3, aby umożliwić nowe i stare klucze do użycia. Wersja 3 dodaje informacje o obsługiwanych wersjach SDK i strukturę dowodu rotacji do bloku podpisywania APK.

Blok podpisywania APK

Aby zachować zgodność wsteczną z formatem v1 APK, sygnatury APK v2 i v3 są przechowywane w bloku podpisywania APK, znajdującym się bezpośrednio przed katalogiem centralnym ZIP.

V3 APK Podpisanie formatu bloku jest taka sama jak v2 . Sygnatura v3 APK jest przechowywana jako para identyfikator-wartość o identyfikatorze 0xf05368c0.

Blok schematu podpisu APK v3

Schemat v3 ma być bardzo podobny do programu v2 . Ma ten sam format ogólny i obsługuje te same sygnatur identyfikatory algorytm , kluczowe rozmiary i krzywe EC.

Jednak schemat v3 dodaje informacje o obsługiwanych wersjach zestawu SDK i strukturze dowodu rotacji.

Format

APK Podpis v3 Schemat blokowy jest przechowywany wewnątrz APK podpis w polu pod ID 0xf05368c0 .

Format bloku APK Signature Scheme v3 jest zgodny z formatem v2:

  • Sekwencja długość przedrostkiem o długości przedrostkiem signer :
    • długość-prefiksem signed data :
      • Sekwencja długość przedrostkiem o długości przedrostkiem digests :
        • signature algorithm ID (4 bajty)
        • digest (długość przedrostkiem)
      • Sekwencja o długości prefiksem X.509 certificates :
        • Długość przedrostkiem X.509 certificate (ASN.1 postać DER)
      • minSDK (uint32) - to osoba podpisująca powinna być ignorowana, jeśli wersja platformy jest poniżej tej liczby.
      • maxSDK (uint32) - to osoba podpisująca powinna być ignorowana, jeśli wersja platformy jest powyżej tej liczby.
      • Sekwencja długość przedrostkiem o długości przedrostkiem additional attributes :
        • ID (UInt32)
        • value (wartość długości: długość dodatkowego atrybutu - 4 bajty)
        • ID - 0x3ba06f8c
        • value - para-obrotu można struct
    • minSDK (uint32) - duplikat wartości minSDK podpisanej w sekcji danych - służy do pominięcia weryfikacji tego podpisu, jeśli bieżąca platforma nie jest w zasięgu. Musi pasować do podpisanej wartości danych.
    • maxSDK (uint32) - duplikat wartości maxSDK podpisanej w sekcji danych - służy do pominięcia weryfikacji tego podpisu, jeśli bieżąca platforma nie jest w zasięgu. Musi pasować do podpisanej wartości danych.
    • Sekwencja długość przedrostkiem o długości przedrostkiem signatures :
      • signature algorithm ID (UInt32)
      • długość-prefiksem signature nad signed data
    • długość-prefiksem public key (subjectPublicKeyInfo, forma ASN.1 DER)

Dowód rotacji i zaufane stare struktury certyfikatów

Struktura dowód rotacji umożliwia aplikacjom obracanie certyfikatu podpisywania bez blokowania w innych aplikacjach, z którymi się komunikują. Aby to osiągnąć, podpisy aplikacji zawierają dwie nowe porcje danych:

  • zapewnienie stronom trzecim, że certyfikat podpisywania aplikacji może być zaufany wszędzie tam, gdzie ufają jego poprzednicy
  • starsze certyfikaty podpisywania aplikacji, którym sama aplikacja nadal ufa

Atrybut proof-of-rotation w sekcji podpisanych danych składa się z pojedynczej połączonej listy, przy czym każdy węzeł zawiera certyfikat podpisywania używany do podpisywania poprzednich wersji aplikacji. Ten atrybut ma zawierać koncepcyjne struktury danych dowodu rotacji i zaufane-stare-certyfikaty. Lista jest uporządkowana według wersji z najstarszym certyfikatem podpisu odpowiadającym węzłowi głównemu. Struktura danych dowodu rotacji jest budowana przez to, że certyfikat w każdym węźle podpisuje następny na liście, a tym samym nasyca każdy nowy klucz dowodami, że powinien być tak samo zaufany, jak starszy klucz (klucze).

Struktura danych self-trusted-old-certs jest tworzona przez dodanie flag do każdego węzła, wskazujących jego członkostwo i właściwości w zestawie. Na przykład może być obecna flaga wskazująca, że ​​certyfikat podpisywania w danym węźle jest zaufany w zakresie uzyskiwania uprawnień do podpisu systemu Android. Ta flaga pozwala innym aplikacjom podpisanym starszym certyfikatem nadal otrzymywać uprawnienia do podpisu zdefiniowane przez aplikację podpisaną przy użyciu nowego certyfikatu do podpisywania. Ponieważ cały proof-of-rotacji rezyduje atrybutu w podpisanym sekcji danych v3 signer dziedzinie, jest chroniony przez klucz użyty do podpisania zawierający apk.

W tym formacie wyklucza wiele kluczy podpisu i zbieżność różnych certyfikatów przodka podpisywania jednym (wieloma węzłami wyjściowych do wspólnego umywalce).

Format

Prototyp tego obrotem jest przechowywany wewnątrz APK Podpis Schemat V3 zaciskowej pod ID 0x3ba06f8c . Jego format to:

  • Sekwencja długość przedrostkiem o długości przedrostkiem levels :
    • długość-prefiksem signed data (przez poprzedniego cert - jeśli istnieje)
      • Długość przedrostkiem X.509 certificate (ASN.1 postać DER)
      • signature algorithm ID (UInt32) - algorytm wykorzystywany przez cert w poprzednim poziomie
    • flags (UInt32) - flagi wskazujące, czy ten cert powinien znajdować się w struktury własny zaufany-stare-CERT, a dla których operacje.
    • signature algorithm ID (uint32) - musi pasować do jednego z podpisanym sekcji danych w następnym poziomie.
    • długość-prefiksem signature nad wyżej signed data

Wiele certyfikatów

Android obecnie traktuje plik APK podpisany wieloma certyfikatami jako posiadający unikalną tożsamość podpisywania, odrębną od certyfikatów składających się na niego. W ten sposób atrybut dowodu rotacji w sekcji danych podpisanych tworzy ukierunkowany graf acykliczny, który można lepiej postrzegać jako pojedynczo połączoną listę, w której każdy zestaw osób podpisujących dla danej wersji reprezentuje jeden węzeł. Zwiększa to dodatkową złożoność struktury dowodu rotacji (wersja z wieloma sygnatariuszami poniżej). W szczególności problemem staje się zamawianie. Co więcej, nie jest już możliwe samodzielne podpisywanie pakietów APK, ponieważ struktura dowodu rotacji musi mieć stare certyfikaty podpisywania, które podpisują nowy zestaw certyfikatów, zamiast podpisywać je pojedynczo. Na przykład plik APK podpisany kluczem A, który chce być podpisany przez dwa nowe klucze B i C, nie może wymagać, aby osoba podpisująca B zawierała tylko podpis A lub B, ponieważ jest to inna tożsamość podpisu niż B i C. oznacza, że ​​sygnatariusze muszą koordynować przed zbudowaniem takiej struktury.

Atrybut potwierdzenia rotacji wielu sygnatariuszy

  • Sekwencja długość przedrostkiem o długości przedrostkiem sets :
    • signed data (przez poprzedniego zestawu - jeśli istnieje)
      • Sekwencja długość przedrostkiem z certificates
        • Długość przedrostkiem X.509 certificate (ASN.1 postać DER)
      • Sekwencja signature algorithm IDs (UInt32) - po jednym dla każdego certyfikatu z poprzedniego zestawu, w tej samej kolejności.
    • flags (UInt32) - flagi wskazujące, czy ten zestaw CERT powinien być w własnym zaufanym-old-CERT struktury, i dla których operacje.
    • Sekwencja długość przedrostkiem o długości przedrostkiem signatures :
      • signature algorithm ID (uint32) - musi pasować do jednego z podpisanym sekcji danych
      • długość-prefiksem signature nad wyżej signed data

Wielu przodków w strukturze dowodu rotacji

Schemat v3 również nie obsługuje dwóch różnych kluczy obracających się do tego samego klucza podpisywania dla tej samej aplikacji. Inaczej jest w przypadku przejęcia, w którym firma przejmująca chciałaby przenieść przejętą aplikację, aby używać jej klucza podpisu do udostępniania uprawnień. Przejęcie jest postrzegane jako obsługiwany przypadek użycia, ponieważ nowa aplikacja byłaby wyróżniana na podstawie nazwy pakietu i mogłaby zawierać własną strukturę dowodu rotacji. Nieobsługiwany przypadek tej samej aplikacji, która ma dwie różne ścieżki do tego samego certyfikatu, łamie wiele założeń przyjętych w projekcie rotacji kluczy.

Weryfikacja

W systemie Android 9 i nowszych pakiety APK można zweryfikować zgodnie ze schematem APK Signature Scheme v3, v2 lub v1. Starsze platformy ignorują podpisy v3 i próbują zweryfikować podpisy v2, a następnie v1.

Proces weryfikacji podpisu APK

Rysunek 1. Sposób weryfikacji podpisu APK

Weryfikacja schematu podpisu APK v3

  1. Znajdź blok podpisywania APK i sprawdź, czy:
    1. Dwa pola rozmiaru bloku podpisywania APK zawierają tę samą wartość.
    2. Bezpośrednio po katalogu centralnym ZIP następuje wpis Koniec katalogu centralnego ZIP.
    3. Po zakończeniu ZIP centralnego katalogu nie następuje więcej danych.
  2. Znajdź pierwszy blok schematu podpisu APK v3 w bloku podpisywania APK. Jeśli v3 bloku występuje, przejdź do kroku 3. W przeciwnym wypadku, wchodzą z powrotem do weryfikacji APK przy użyciu schematu v2 .
  3. Dla każdej signer w podpisie APK Schemat v3 bloku o minimalnej i maksymalnej wersji SDK, które jest w zasięgu bieżącego platformy:
    1. Wybierz najsilniejszy obsługiwane signature algorithm ID z signatures . Kolejność siły zależy od każdej wersji wdrożenia/platformy.
    2. Zweryfikować odpowiedni signature z signatures przeciwko signed data z wykorzystaniem public key . (To jest teraz bezpieczny do analizowania signed data ).
    3. Sprawdź, min i max w wersji SDK podpisanych danych dopasować te określone dla signer .
    4. Sprawdź, czy uporządkowana lista identyfikatorów algorytm podpisu w digests i signatures jest identyczna. (Ma to na celu zapobieganie usuwaniu/dodawaniu podpisu).
    5. Obliczyć strawić treści APK stosując ten sam algorytm jak trawić strawić algorytm wykorzystywany przez algorytm podpisu.
    6. Należy sprawdzić, czy obliczony trawienia jest identyczna z odpowiadającą digest z digests .
    7. Sprawdź, czy subjectPublicKeyInfo pierwszego certificate z certificates jest identyczny z public key .
    8. Jeśli atrybut proof-of-rotacji istnieje dla signer sprawdzić, czy struktura jest ważna i to signer to ostatni certyfikat na liście.
  4. Weryfikacja powiedzie się, jeśli dokładnie jedna signer stwierdzono w zakresie bieżącego kroku 3 platformy i zastąpił na tym signer .

Walidacja

Aby sprawdzić, czy Twoje urządzenie obsługuje v3 poprawnie, uruchom PkgInstallSignatureVerificationTest.java testy w CTS cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ .