podpisywanie kompilacji do publikacji,

Obrazy systemu operacyjnego Android używają podpisów kryptograficznych w 2 miejscach:

1. Każdy plik .apk w obrazie musi być podpisany. Menedżer pakietów Androida używa podpisu .apk na 2 sposoby:
   • Gdy aplikacja jest zastępowana, musi być podpisana tym samym kluczem co stara aplikacja, aby uzyskać dostęp do jej danych. Dotyczy to zarówno aktualizowania aplikacji użytkownika przez zastąpienie pliku .apk, jak i zastępowania aplikacji systemowej nowszą wersją zainstalowaną w folderze /data.
   • Jeśli co najmniej 2 aplikacje mają współdzielić identyfikator użytkownika (aby mogły udostępniać dane itp.), muszą być podpisane tym samym kluczem.
2. Pakiety aktualizacji OTA muszą być podpisane jednym z kluczy oczekiwanych przez system, w przeciwnym razie proces instalacji je odrzuci.

Klucze wersji

Drzewo Androida zawiera test-keys w katalogu build/target/product/security. Podczas tworzenia obrazu systemu operacyjnego Android za pomocą narzędzia make wszystkie pliki .apk zostaną podpisane za pomocą kluczy testowych. Klucze testowe są publicznie znane, więc każdy może podpisać własne pliki APK tymi samymi kluczami, co może umożliwić mu zastąpienie lub przejęcie aplikacji systemowych wbudowanych w obraz systemu operacyjnego. Dlatego ważne jest, aby podpisywać wszystkie publicznie udostępniane lub wdrażane obrazy systemu operacyjnego Android specjalnym zestawem kluczy wersji, do których dostęp masz tylko Ty.

Aby wygenerować własny, niepowtarzalny zestaw kluczy wersji, uruchom te polecenia w katalogu głównym drzewa Androida:

subject='/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=android@android.com'
mkdir ~/.android-certs
for x in releasekey platform shared media networkstack; do \
    ./development/tools/make_key ~/.android-certs/$x "$subject"; \
  done

$subject należy zmienić, aby odzwierciedlało informacje o Twojej organizacji. Możesz użyć dowolnego katalogu, ale wybierz lokalizację, która jest zabezpieczona i ma utworzoną kopię zapasową. Niektórzy dostawcy decydują się zaszyfrować klucz prywatny silnym hasłem i przechowywać zaszyfrowany klucz w systemie kontroli wersji, a inni przechowują klucze wersji w zupełnie innym miejscu, np. na komputerze odłączonym od sieci.

Aby wygenerować obraz wersji, użyj tego polecenia:

make dist
sign_target_files_apks \
-o \    # explained in the next section
--default_key_mappings ~/.android-certs out/dist/*-target_files-*.zip \
signed-target_files.zip

Skrypt sign_target_files_apks przyjmuje jako dane wejściowe pliki docelowe .zip i tworzy nowe pliki docelowe .zip, w których wszystkie pliki .apk zostały podpisane nowymi kluczami. Nowo podpisane obrazy znajdziesz w sekcji IMAGES/ w signed-target_files.zip.

Podpisywanie pakietów OTA

ota_from_target_files \
-k  (--package_key) 
signed-target_files.zip \
signed-ota_update.zip

Podpisy i wczytywanie z zewnątrz

Instalowanie z boku nie omija normalnego mechanizmu weryfikacji podpisu pakietu w trybie recovery – przed zainstalowaniem pakietu tryb recovery sprawdzi, czy jest on podpisany jednym z kluczy prywatnych pasujących do kluczy publicznych przechowywanych w partycji recovery, tak jak w przypadku pakietu dostarczonego drogą bezprzewodową.

Pakiety aktualizacji otrzymywane z systemu głównego są zwykle weryfikowane 2 razy: raz przez system główny za pomocą metody RecoverySystem.verifyPackage() w interfejsie API Androida, a następnie ponownie przez środowisko odzyskiwania. Interfejs RecoverySystem API sprawdza podpis na podstawie kluczy publicznych przechowywanych w systemie głównym w pliku /system/etc/security/otacerts.zip (domyślnie). Proces odzyskiwania sprawdza podpis za pomocą kluczy publicznych przechowywanych na dysku RAM partycji odzyskiwania w pliku /res/keys.

Domyślnie pliki docelowe .zip wygenerowane przez kompilację ustawiają certyfikat OTA tak, aby pasował do klucza testowego. W przypadku opublikowanego obrazu należy użyć innego certyfikatu, aby urządzenia mogły zweryfikować autentyczność pakietu aktualizacji. Przekazanie flagi -o do sign_target_files_apks, jak pokazano w poprzedniej sekcji, zastępuje certyfikat klucza testowego certyfikatem klucza wersji z katalogu certs.

Obraz systemu i obraz przywracania systemu zwykle zawierają ten sam zestaw kluczy publicznych OTA. Dodanie klucza tylko do zestawu kluczy przywracania umożliwia podpisywanie pakietów, które można zainstalować tylko przez wczytywanie z boku (zakładając, że główny mechanizm pobierania aktualizacji systemu prawidłowo weryfikuje plik otacerts.zip). Możesz określić dodatkowe klucze, które mają być uwzględniane tylko w przypadku odzyskiwania, ustawiając zmienną PRODUCT_EXTRA_RECOVERY_KEYS w definicji produktu:

vendor/yoyodyne/tardis/products/tardis.mk

 [...]

PRODUCT_EXTRA_RECOVERY_KEYS := vendor/yoyodyne/security/tardis/sideload

Obejmuje to klucz publicznyvendor/yoyodyne/security/tardis/sideload.x509.pem w pliku kluczy odzyskiwania, aby można było instalować pakiety podpisane tym kluczem. Dodatkowy klucz nie jest jednak uwzględniony w pliku otacerts.zip, więc systemy, które prawidłowo weryfikują pobrane pakiety, nie wywołują odzyskiwania w przypadku pakietów podpisanych tym kluczem.

Certyfikaty i klucze prywatne

Każdy klucz jest dostępny w 2 plikach: certyfikacie z rozszerzeniem .x509.pem i kluczu prywatnym z rozszerzeniem .pk8. Klucz prywatny należy przechowywać w tajemnicy. Jest on potrzebny do podpisania pakietu. Klucz może być chroniony hasłem. Certyfikat zawiera tylko publiczną część klucza, więc można go rozpowszechniać na szeroką skalę. Służy do weryfikowania, czy pakiet został podpisany odpowiednim kluczem prywatnym.

Standardowa kompilacja Androida używa 5 kluczy, które znajdują się w  build/target/product/security:

testkey

Ogólny klucz domyślny w przypadku pakietów, które nie określają klucza w inny sposób.

platforma

Klucz testowy dla pakietów, które są częścią podstawowej platformy.

udostępnione

Klucz testowy do elementów udostępnianych w procesie dotyczącym domu lub kontaktów.

media

Klucz testowy dla pakietów, które są częścią systemu multimediów lub pobierania.

Poszczególne pakiety określają jeden z tych kluczy, ustawiając LOCAL_CERTIFICATE w pliku Android.mk. (Jeśli ta zmienna nie jest ustawiona, używany jest klucz testowy). Możesz też określić zupełnie inny klucz, podając ścieżkę do niego, np.:

device/yoyodyne/apps/SpecialApp/Android.mk

 [...]

LOCAL_CERTIFICATE := device/yoyodyne/security/special

Teraz kompilacja używa klucza device/yoyodyne/security/special.{x509.pem,pk8} do podpisania pliku SpecialApp.apk. Kompilacja może używać tylko kluczy prywatnych, które nie są chronione hasłem.

Zaawansowane opcje podpisywania

Zastępowanie klucza podpisywania APK

Skrypt podpisywania sign_target_files_apks działa na plikach docelowych wygenerowanych na potrzeby kompilacji. Wszystkie informacje o certyfikatach i kluczach prywatnych używanych w czasie kompilacji są zawarte w plikach docelowych. Podczas uruchamiania skryptu podpisywania w celu podpisania wersji klucze podpisywania można zastąpić na podstawie nazwy klucza lub nazwy pliku APK.

Użyj flag --key_mapping i --default_key_mappings, aby określić zastępowanie kluczy na podstawie ich nazw:

• Flaga --key_mapping src_key=dest_key określa zamiennik dla jednego klawisza naraz.
• Flaga --default_key_mappings dir określa katalog z 5 kluczami, które zastąpią wszystkie klucze w build/target/product/security. Jest to odpowiednik użycia --key_mapping 5 razy do określenia mapowań.

build/target/product/security/testkey      = dir/releasekey
build/target/product/security/platform     = dir/platform
build/target/product/security/shared       = dir/shared
build/target/product/security/media        = dir/media
build/target/product/security/networkstack = dir/networkstack

Użyj flagi --extra_apks apk_name1,apk_name2,...=key, aby określić zamiany kluczy podpisywania na podstawie nazw plików APK. Jeśli pole key jest puste, skrypt traktuje określone pliki APK jako wstępnie podpisane.

W przypadku hipotetycznego produktu tardis potrzebujesz 6 kluczy chronionych hasłem: 5 do zastąpienia 5 kluczy w build/target/product/security i 1 do zastąpienia dodatkowego klucza device/yoyodyne/security/special wymaganego przez aplikację SpecialApp w powyższym przykładzie. Jeśli klucze znajdowały się w tych plikach:

vendor/yoyodyne/security/tardis/releasekey.x509.pem
vendor/yoyodyne/security/tardis/releasekey.pk8
vendor/yoyodyne/security/tardis/platform.x509.pem
vendor/yoyodyne/security/tardis/platform.pk8
vendor/yoyodyne/security/tardis/shared.x509.pem
vendor/yoyodyne/security/tardis/shared.pk8
vendor/yoyodyne/security/tardis/media.x509.pem
vendor/yoyodyne/security/tardis/media.pk8
vendor/yoyodyne/security/tardis/networkstack.x509.pem
vendor/yoyodyne/security/tardis/networkstack.pk8
vendor/yoyodyne/security/special.x509.pem
vendor/yoyodyne/security/special.pk8           # NOT password protected
vendor/yoyodyne/security/special-release.x509.pem
vendor/yoyodyne/security/special-release.pk8   # password protected

Następnie podpisz wszystkie aplikacje w ten sposób:

./build/make/tools/releasetools/sign_target_files_apks \
    --default_key_mappings vendor/yoyodyne/security/tardis \
    --key_mapping vendor/yoyodyne/security/special=vendor/yoyodyne/security/special-release \
    --extra_apks PresignedApp= \
    -o tardis-target_files.zip \
    signed-tardis-target_files.zip

Pojawią się te informacje:

Enter password for vendor/yoyodyne/security/special-release key>
Enter password for vendor/yoyodyne/security/tardis/networkstack key>
Enter password for vendor/yoyodyne/security/tardis/media key>
Enter password for vendor/yoyodyne/security/tardis/platform key>
Enter password for vendor/yoyodyne/security/tardis/releasekey key>
Enter password for vendor/yoyodyne/security/tardis/shared key>
    signing: Phone.apk (vendor/yoyodyne/security/tardis/platform)
    signing: Camera.apk (vendor/yoyodyne/security/tardis/media)
    signing: NetworkStack.apk (vendor/yoyodyne/security/tardis/networkstack)
    signing: Special.apk (vendor/yoyodyne/security/special-release)
    signing: Email.apk (vendor/yoyodyne/security/tardis/releasekey)
        [...]
    signing: ContactsProvider.apk (vendor/yoyodyne/security/tardis/shared)
    signing: Launcher.apk (vendor/yoyodyne/security/tardis/shared)
NOT signing: PresignedApp.apk
        (skipped due to special cert string)
rewriting SYSTEM/build.prop:
  replace:  ro.build.description=tardis-user Eclair ERC91 15449 test-keys
     with:  ro.build.description=tardis-user Eclair ERC91 15449 release-keys
  replace: ro.build.fingerprint=generic/tardis/tardis/tardis:Eclair/ERC91/15449:user/test-keys
     with: ro.build.fingerprint=generic/tardis/tardis/tardis:Eclair/ERC91/15449:user/release-keys
    signing: framework-res.apk (vendor/yoyodyne/security/tardis/platform)
rewriting RECOVERY/RAMDISK/default.prop:
  replace:  ro.build.description=tardis-user Eclair ERC91 15449 test-keys
     with:  ro.build.description=tardis-user Eclair ERC91 15449 release-keys
  replace: ro.build.fingerprint=generic/tardis/tardis/tardis:Eclair/ERC91/15449:user/test-keys
     with: ro.build.fingerprint=generic/tardis/tardis/tardis:Eclair/ERC91/15449:user/release-keys
using:
    vendor/yoyodyne/security/tardis/releasekey.x509.pem
for OTA package verification
done.

Po wyświetleniu użytkownikowi prośby o podanie haseł do wszystkich kluczy chronionych hasłem skrypt ponownie podpisuje wszystkie pliki APK w docelowym folderze wejściowym .zip za pomocą kluczy wersji. Przed uruchomieniem polecenia możesz też ustawić zmienną środowiskową ANDROID_PW_FILE na nazwę pliku tymczasowego. Skrypt wywoła wtedy edytor, aby umożliwić Ci wpisanie haseł do wszystkich kluczy (może to być wygodniejszy sposób wpisywania haseł).

Wymiana klucza podpisywania pakietu APEX

W Androidzie 10 wprowadzono format pliku APEX do instalowania modułów systemowych niższego poziomu. Jak wyjaśniono w sekcji Podpisywanie pakietów APEX, każdy plik APEX jest podpisywany 2 kluczami: jednym dla obrazu mini systemu plików w pakiecie APEX, a drugim dla całego pakietu APEX.

Podczas podpisywania wersji dwa klucze podpisywania pliku APEX są zastępowane kluczami wersji. Klucz ładunku systemu plików jest określany za pomocą flagi --extra_apex_payload, a cały klucz podpisywania pliku APEX jest określany za pomocą flagi --extra_apks.

W przypadku produktu tardis załóżmy, że masz taką konfigurację kluczy dla plików APEX com.android.conscrypt.apex, com.android.media.apex i com.android.runtime.release.apex.

name="com.android.conscrypt.apex" public_key="PRESIGNED" private_key="PRESIGNED" container_certificate="PRESIGNED" container_private_key="PRESIGNED"
name="com.android.media.apex" public_key="PRESIGNED" private_key="PRESIGNED" container_certificate="PRESIGNED" container_private_key="PRESIGNED"
name="com.android.runtime.release.apex" public_key="vendor/yoyodyne/security/testkeys/com.android.runtime.avbpubkey" private_key="vendor/yoyodyne/security/testkeys/com.android.runtime.pem" container_certificate="vendor/yoyodyne/security/testkeys/com.google.android.runtime.release_container.x509.pem" container_private_key="vendor/yoyodyne/security/testkeys/com.google.android.runtime.release_container.pk8"

Masz te pliki zawierające klucze wersji:

vendor/yoyodyne/security/runtime_apex_container.x509.pem
vendor/yoyodyne/security/runtime_apex_container.pk8
vendor/yoyodyne/security/runtime_apex_payload.pem

Podczas podpisywania wersji to polecenie zastępuje klucze podpisywania dla com.android.runtime.release.apex i com.android.tzdata.apex. W szczególności com.android.runtime.release.apex jest podpisany określonymi kluczami wersji (runtime_apex_container w przypadku pliku APEX i runtime_apex_payload w przypadku ładunku obrazu pliku). com.android.tzdata.apex jest traktowany jako podpisany wcześniej. Wszystkie pozostałe pliki APEX są obsługiwane przez domyślną konfigurację wymienioną w plikach docelowych.

./build/make/tools/releasetools/sign_target_files_apks \
    --default_key_mappings   vendor/yoyodyne/security/tardis \
    --extra_apks             com.android.runtime.release.apex=vendor/yoyodyne/security/runtime_apex_container \
    --extra_apex_payload_key com.android.runtime.release.apex=vendor/yoyodyne/security/runtime_apex_payload.pem \
    --extra_apks             com.android.media.apex= \
    --extra_apex_payload_key com.android.media.apex= \
    -o tardis-target_files.zip \
    signed-tardis-target_files.zip

Uruchomienie powyższego polecenia spowoduje wyświetlenie tych logów:

        [...]
    signing: com.android.runtime.release.apex                  container (vendor/yoyodyne/security/runtime_apex_container)
           : com.android.runtime.release.apex                  payload   (vendor/yoyodyne/security/runtime_apex_payload.pem)
NOT signing: com.android.conscrypt.apex
        (skipped due to special cert string)
NOT signing: com.android.media.apex
        (skipped due to special cert string)
        [...]

Inne opcje

Skrypt podpisywania sign_target_files_apks przepisuje opis kompilacji i odcisk palca w plikach właściwości kompilacji, aby odzwierciedlić fakt, że kompilacja jest podpisana. Flaga --tag_changes określa, jakie zmiany zostaną wprowadzone w odcisku palca. Uruchom skrypt z parametrem -h, aby wyświetlić dokumentację wszystkich flag.

Ręczne generowanie kluczy

Android używa 2048-bitowych kluczy RSA z wykładnikiem publicznym 3. Pary certyfikatów i kluczy prywatnych możesz wygenerować za pomocą narzędzia openssl z openssl.org:

# generate RSA key
openssl genrsa -3 -out temp.pem 2048
Generating RSA private key, 2048 bit long modulus
....+++
.....................+++
e is 3 (0x3)

# create a certificate with the public part of the key
openssl req -new -x509 -key temp.pem -out releasekey.x509.pem -days 10000 -subj '/C=US/ST=California/L=San Narciso/O=Yoyodyne, Inc./OU=Yoyodyne Mobility/CN=Yoyodyne/emailAddress=yoyodyne@example.com'

# create a PKCS#8-formatted version of the private key
openssl pkcs8 -in temp.pem -topk8 -outform DER -out releasekey.pk8 -nocrypt

# securely delete the temp.pem file
shred --remove temp.pem

Podane powyżej polecenie openssl pkcs8 tworzy plik .pk8 bez hasła, który można używać w systemie kompilacji. Aby utworzyć zabezpieczony hasłem plik .pk8 (co należy zrobić w przypadku wszystkich rzeczywistych kluczy wersji), zastąp argument -nocrypt argumentem -passout stdin. Następnie OpenSSL zaszyfruje klucz prywatny hasłem odczytanym ze standardowego wejścia. Nie jest wyświetlany żaden prompt, więc jeśli stdin jest terminalem, program będzie wyglądał na zawieszony, gdy w rzeczywistości będzie tylko czekał na wpisanie hasła. Do odczytywania hasła z innych lokalizacji można używać innych wartości argumentu -passout. Więcej informacji znajdziesz w  dokumentacji OpenSSL.

Plik pośredni temp.pem zawiera klucz prywatny bez żadnego zabezpieczenia hasłem, więc podczas generowania kluczy wersji należy go odpowiednio usunąć. W szczególności narzędzie GNUshred może nie działać skutecznie w przypadku systemów plików sieciowych lub z dziennikiem. Podczas generowania kluczy możesz używać katalogu roboczego znajdującego się na dysku RAM (np. partycji tmpfs), aby mieć pewność, że pośrednie pliki nie zostaną przypadkowo ujawnione.

Tworzenie plików obrazów

Gdy masz signed-target_files.zip, musisz utworzyć obraz, aby można go było umieścić na urządzeniu. Aby utworzyć podpisany obraz z plików docelowych, uruchom to polecenie w katalogu głównym drzewa Androida:

img_from_target_files signed-target_files.zip signed-img.zip

fastboot update signed-img.zip