Powiązanie wersji

W programie Keymaster 1 wszystkie klucze Keymastery były powiązane kryptograficznie z urządzeniem. Źródło zaufania lub klucz zweryfikowany podczas uruchamiania. W Keymasterach 2 i 3 wszystkie są też powiązane z systemem operacyjnym i poziomem poprawek obrazu systemu. Zapewnia to, że atakujący, który odkrywa słabość w starym interfejsie systemu lub oprogramowania TEE nie można przywrócić urządzenia z powrotem i używać kluczy utworzonych w nowszej wersji. Ponadto, gdy klucz z określoną wersją i poziomem poprawek na urządzeniu, które zostało uaktualnione do nowszej wersji lub na poziomie poprawek, klucz jest uaktualniany, zanim będzie można go użyć. a poprzednia wersja klucza została unieważniona. Dzięki temu, gdy urządzenie po uaktualnieniu klucze będą „zawierać się” wraz z urządzeniem, ale każdy przywrócenie na urządzeniu poprzedniej wersji spowoduje, że klucze bezużyteczne.

Aby obsługiwać modułową strukturę Treble i przełamać powiązanie system.img z Boot.img, Keymaster 4 zmienił model wiązania wersji klucza tak, aby wprowadzał oddzielne poziomów poprawek dla każdej partycji. Dzięki temu każda partycja może być zaktualizowana niezależnie od siebie, a jednocześnie zapewnia ochronę przed wycofaniem.

Android 9: boot, system i vendor każda partycja ma własny poziom poprawek.

  • Urządzenia z weryfikacją podczas uruchamiania systemu Android (AVB) mogą stosować wszystkie poziomy poprawek oraz wersję systemu w vbmeta, dzięki czemu program rozruchowy może udostępnić Mistrz kluczy. W przypadku partycji łańcuchowej informacje o wersji będą w łańcuchowym vbmeta. Ogólnie informacje o wersji powinny znajdować się w pliku vbmeta struct, który zawiera dane weryfikacyjne (zaszyfrowane lub hashtree) danej partycji.
  • Na urządzeniach bez AVB:
    • Implementacje weryfikacji podczas uruchamiania muszą podawać hasz wersji metadanych do programu rozruchowego, tak aby program rozruchowy mógł przekazać hasz do Keymastera.
    • boot.img może nadal przechowywać poziom poprawek w nagłówku
    • system.img może nadal przechowywać informacje o poziomie poprawek i wersji systemu operacyjnego w trybie tylko do odczytu usługi
    • vendor.img przechowuje poziom poprawki we właściwości tylko do odczytu ro.vendor.build.version.security_patch
    • Program rozruchowy może dostarczyć hasz wszystkich danych zweryfikowanych przez weryfikację rozruchu do Keymastera.
  • W Androidzie 9 należy używać tych tagów do podawania informacji o wersji na tych partycjach:
    • VENDOR_PATCH_LEVEL: vendor partycja
    • BOOT_PATCH_LEVEL: boot partycja
    • OS_PATCH_LEVEL i OS_VERSION: system partycja. (OS_VERSION został usunięty z w nagłówku boot.img.
  • Implementacje Keymaster powinny traktować wszystkie poziomy poprawek niezależnie. Klucze są użyte, jeśli wszystkie informacje o wersji są zgodne z wartościami powiązanymi z kluczem; IKeymaster::upgradeDevice() zmienia poziom na wyższy, jeśli niezbędną.

Zmiany HAL

Aby obsługiwać wiązanie wersji i atestację wersji, w Androidzie 7.1 dodano funkcję tagi Tag::OS_VERSION i Tag::OS_PATCHLEVEL oraz tag metody configure i upgradeKey. Tagi wersji są automatycznie dodawane przez implementacje Keymaster 2 lub nowsze do wszystkich nowo generowanych (lub zaktualizowanych). Ponadto każda próba użycia klucza, który nie ma systemu operacyjnego wersja lub poziom poprawek pasujący do bieżącej wersji systemu operacyjnego lub poziomu poprawek; jest odrzucana odpowiednio przez ErrorCode::KEY_REQUIRES_UPGRADE.

Tag::OS_VERSION to wartość UINT, która reprezentuje głównych, podrzędnych i podrzędnych elementach wersji systemu Android w formacie MMMM. gdzie MM to wersja główna, mm to wersja podrzędna, a ss to wersja podrzędna. wersji. Na przykład adres 6.1.2 będzie zapisany jako 060102.

Tag::OS_PATCHLEVEL to wartość UINT, która reprezentuje rok i miesiąc ostatniej aktualizacji systemu w formacie RRRRMM, gdzie RRRR oznacza czterocyfrowym rokiem, a MM oznacza miesiącem. Na przykład marzec 2016 r. będzie wyglądał tak: w postaci 201603.

Klucz uaktualniania

Aby umożliwić uaktualnianie kluczy do nowej wersji systemu operacyjnego i poziomu poprawek systemu , Android 7.1 dodał metodę upgradeKey do listy HAL:

Keymaster 3

    upgradeKey(vec keyBlobToUpgrade, vec upgradeParams)
        generates(ErrorCode error, vec upgradedKeyBlob);

Keymaster 2

keymaster_error_t (*upgrade_key)(const struct keymaster2_device* dev,
    const keymaster_key_blob_t* key_to_upgrade,
    const keymaster_key_param_set_t* upgrade_params,
    keymaster_key_blob_t* upgraded_key);
  • dev to struktura urządzenia
  • keyBlobToUpgrade to klucz, który należy uaktualnić
  • upgradeParams to parametry niezbędne do uaktualnienia klucza. Te będą obejmować Tag::APPLICATION_ID i Tag::APPLICATION_DATA, które są niezbędne do odszyfrowania klucza. blob, jeśli zostały dostarczone podczas generowania.
  • upgradedKeyBlob to parametr wyjściowy używany do zwracania nowego klucza blob.

Jeśli funkcja upgradeKey jest wywoływana za pomocą klucza blob, którego nie można przeanalizować, lub jest nieprawidłowy, zwraca wartość ErrorCode::INVALID_KEY_BLOB. Jeśli jest wywoływana za pomocą klucza, którego poziom poprawki jest większy niż bieżąca wartość systemowa, zwraca ErrorCode::INVALID_ARGUMENT. Jeśli jest wywoływane za pomocą klucza której wersja systemu operacyjnego jest nowsza niż bieżąca wartość systemowa oraz wartość systemowa ma wartość inną niż zero, zwraca ErrorCode::INVALID_ARGUMENT. Wersja systemu operacyjnego uaktualnienia z wartości innej niż 0 do 0 są dozwolone. W przypadku błędów komunikuje się z bezpiecznym światem, zwraca odpowiednią wartość błędu (np. ErrorCode::SECURE_HW_ACCESS_DENIED, ErrorCode::SECURE_HW_BUSY). W przeciwnym razie zwraca ErrorCode::OK i zwraca nowy klucz blob w upgradedKeyBlob

keyBlobToUpgrade pozostaje ważny po upgradeKey i teoretycznie można go użyć ponownie po przejściu na starszą wersję. W ćwiczenie, magazyn kluczy zwykle wywołuje deleteKey na keyBlobToUpgrade blob wkrótce po wywołaniu upgradeKey Jeśli keyBlobToUpgrade miał(a) tag Tag::ROLLBACK_RESISTANT, a potem upgradedKeyBlob powinny i powinny być odporne na wycofanie.

Bezpieczna konfiguracja

Aby można było wdrożyć wiązanie wersji, asystent pomocy technicznej klucza musi mieć sposób bezpiecznego odbierania obecną wersję systemu operacyjnego i poziom poprawek (informacje o wersji) oraz upewnij się, że otrzymywane informacje są silnie zgodne z informacjami o uruchamianiu systemu.

Aby zapewnić bezpieczne przesyłanie informacji o wersji do doradcy klienta, OS_VERSION Pole zostało dodane do nagłówka obrazu rozruchowego. Kompilacja obrazu rozruchowego skrypt automatycznie wypełnia to pole. OEM i specjaliści ds. wdrażania rozwiązań technicznych muszą współpracować przy modyfikacji programów rozruchowych urządzenia w celu wyodrębnienia wersji z obrazu rozruchowego i przekazać je do asystenta przed niezabezpieczonym jest uruchamiany. Dzięki temu osoby przeprowadzające atak nie będą mogły zakłócać obsługi administracyjnej i przekazywaniu informacji o wersji.

Trzeba też dopilnować, aby obraz systemu miał tę samą wersję jako obrazu rozruchowego. W związku z tym dodaliśmy metodę konfigurowania do klucza HAL: 

keymaster_error_t (*configure)(const struct keymaster2_device* dev,
  const keymaster_key_param_set_t* params);

Argument params zawiera Tag::OS_VERSION i Tag::OS_PATCHLEVEL Ta metoda jest wywoływana przez klienty keymaster2 po otwarciu listy HAL, ale przed wywołaniem jakichkolwiek innych metod. Jeśli jakakolwiek inna metoda jest wywoływana przed konfiguracją, funkcja TA zwraca ErrorCode::KEYMASTER_NOT_CONFIGURED

Przy pierwszym wywołaniu funkcji configure po uruchomieniu urządzenia powinien sprawdzić, czy podane informacje o wersji są zgodne z informacjami podanymi przez programu rozruchowego. Jeśli informacje o wersji nie są zgodne, configure zwraca wartość ErrorCode::INVALID_ARGUMENT i wszystkie inne metody Keymaster są nadal zwracane ErrorCode::KEYMASTER_NOT_CONFIGURED Jeśli informacje będą się zgadzać, configure zwraca wartość ErrorCode::OK i inną kombinację kluczy zaczynają działać normalnie.

Kolejne wywołania funkcji configure zwracają tę samą wartość zwracaną przez funkcję bez zmiany stanu klucza Keymaster. Pamiętaj, że ten proces wymaga, aby wszystkie aktualizacje OTA aktualizowały zarówno obraz systemu, jak i obrazu rozruchowego; Nie można ich zaktualizować oddzielnie, aby aktualizować informacje o wersji.

Ponieważ system, w której znajduje się zawartość, zostanie wywołany przez system configure ma na celu zweryfikowanie, że atakujący ma ograniczone możliwości, zostały naruszone w obrazie systemu i wymusić na nim dostarczenie informacji o wersji, pasuje do obrazu rozruchowego, ale nie jest to rzeczywista wersja systemu. połączenie weryfikacji obrazu rozruchowego i weryfikacji DM-verity obrazu systemu oraz fakt, że configure jest wywoływany bardzo wcześnie system uruchamiania systemu powinien utrudnić wykorzystanie tego okna możliwości.