Skrytí přístupu root v Magisku bude mnohem obtížnější díky nedávné změně v SafetyNet, která přináší atestaci hardwaru.
V březnu několik uživatelů s nainstalovaným Magisk všiml že jejich zařízení nesplňovala atestaci SafetyNet. Tato zpráva znepokojovala komunitu na XDA, protože to znamená, že mnoho klíčových bankovních/finančních aplikací a populárních her jako Pokémon Go a Fate/Grand Order odmítalo běžet na rootovaných zařízeních. Nějakou dobu se zdálo, že zpřísněná omezení v SafetyNet byla stažena, aby se v posledních několika týdnech znovu objevila pro hrstku uživatelů. Google však začátkem května tiše potvrdil, že testuje atestaci podporovanou hardwarem Odpovědi SafetyNet, což je důvod, proč Magisk nedokázal skrýt stav odemknutí bootloaderu zpět Březen. Pokud se tato změna široce rozšíří, bude to znamenat, že si uživatelé budou muset vybrat mezi přístupem k root/vlastním ROM/kernelům/atd. nebo jejich preferované bankovní aplikace a hry. Jedna z největších atrakcí Androidu pro náročné uživatele by mohla být brzy pryč.
Abychom rekapitulovali tuto sérii událostí, měli bychom nejprve mluvit o samotné SafetyNet. SafetyNet je sada rozhraní API ve Službách Google Play. SafetyNet Attestation API je jedním z těchto API a mohou jej volat aplikace třetích stran, aby zkontrolovaly, zda nebylo nějakým způsobem manipulováno se softwarovým prostředím zařízení. Rozhraní API kontroluje různé věci, jako jsou známky binárních souborů superuživatele, stav odemknutí zavaděče a další. Když rootnete zařízení pomocí Magisk, „[vytvoří] izolované ‚bezpečné prostředí‘ pro proces detekce [SafetyNet] a projde rozhraním Google API k vytvoření legitimní Výsledek SafetyNet, který neodráží skutečný stav zařízení,“ uvádí XDA Senior Recognized Developer topjohnwu. To umožňuje uživateli rootovat svůj telefon a zároveň zajistit, že API vždy vrátí "false" pro všechny kontroly odemknutí bootloaderu. Tato metoda obcházení detekce odemykání bootloaderu SafetyNet funguje pro Magisk již několik posledních let, ale to jen proto, že Google otálel s ověřováním integrity spouštěcího obrazu pomocí hardwaru atestace. V březnu se zdálo, že Google konečně začal používat hardwarovou atestaci v SafetyNet k ověření spouštěcí obrázek, ale nikdy jsme nedostali oficiální prohlášení od společnosti Google potvrzující změnu a bylo to jen několik uživatelů postižený. Jak si všiml Senior Member XDA DisplaxGoogle však 5. května 2020 potvrdil, že odpovědi SafetyNet Attestation API z některých zařízení nyní zahrnují kontroly podporované hardwarem.
Ve Skupině Google pro „klienty rozhraní SafetyNet API“ Google podrobně popsal novou funkci pro rozhraní Attestation API: assessmentType. Odpověď JSON Web Signature (JWS) z některých zařízení bude mít pole s názvem „evaluationType“, které „poskytne vývojářům přehled do typů signálů/měření, které přispěly ke každé jednotlivé odpovědi SafetyNet Attestation API." Jeden z podporovaných tokenů v tomto poli je "HARDWARE_BACKED", což znamená, že API "[použilo] dostupné hardwarově podporované bezpečnostní funkce vzdáleného zařízení (např. hardwarově zabezpečená atestace klíče), aby ovlivnili [jeho] hodnocení.“ Google říká, že „v současné době vyhodnocují a upravují kritéria způsobilosti pro zařízení, kde se budeme spoléhat na hardwarově bezpečnostní funkce." To znamená, že na některých zařízeních Služby Google Play nyní používají atestaci podporovanou hardwarem, aby zjistily, že software zařízení nebyl manipulováno s. Google tuto změnu oficiálně nezdokumentoval mimo oznámení ve skupině Google, takže někteří vývojáři, kteří používají SafetyNet, mohou neuvědomují si tuto změnu (a tedy ještě nekontrolují pole „HARDWARE_BACKED“ v odpovědích JWS.) Nicméně pro ty aplikace, které vyhledávají toto pole, není nyní žádný způsob, jak před nimi skrýt přístup root, pokud je vaše zařízení součástí testu, který Google běh.
Podle topjohnwu atestace podporovaná hardwarem znamená, že Služby Google Play nyní „[zasílají] neupravený certifikát úložiště klíčů na servery SafetyNet, [ověřují] jeho legitimitu a [zkontroluje] data rozšíření certifikátu, aby zjistil, zda vaše zařízení [má] ověřené spouštění povoleno (stav bootloaderu).“ Vzhledem k tomu, že soukromé klíče, ze kterých jsou odvozeny certifikáty úložiště klíčů jsou podporovány izolovaným bezpečným prostředím telefonu, jejich načtení by znamenalo zmaření zabezpečení TEE (Trusted Execution Environment) nebo vyhrazeného hardwarového zabezpečení modul (HSM). Pokud by byl nějakým způsobem schopen uniknout soukromý klíč, klíče by byly rychle zrušeny jakmile to Google zjistil. Google nabízí odměny ve výši stovek tisíc dolarů za jakékoli kritické bezpečnostní chyby ovlivňující TEE v telefonech Pixel, což jen ukazuje, že je neuvěřitelně nepravděpodobné, že by to byla potenciální cesta k obejití detekce odemknutí bootloaderu jakkoliv.
Dalším potenciálním způsobem, jak by Magisk mohl pokračovat v falšování stavu odemknutí bootloaderu, je úprava kódu na straně klienta SafetyNet tak, aby vždy používal vyhodnocení BASIC. Tak jako topjohnwu poznámkyTo by však vyžadovalo vložení vlastního kódu do Služeb Google Play prostřednictvím spojovacího rámce, jako je Xposed Framework. To je nejen obtížné, protože služby Google Play jsou velmi zatemněné, ale také je to nemožné skrýt, protože „některá analýza paměťového prostoru odhalí manipulaci s kódem velmi Kromě toho by to také fungovalo pouze v případě, že servery Google budou nadále přijímat hodnocení BASIC a pokud hodnocení HARDWARE_BACKED nebudou vynucována na zařízeních, která podporují jim. (Odpovědi SafetyNet „[pocházejí] ze serverů Google a jsou podepsány soukromým klíčem Google,“ podle topjohnwu, takže skutečné odpovědi nelze zfalšovat.)
Od Androidu 7 Nougat Google vyžaduje, aby všechna zařízení měla izolované zabezpečené prostředí, což znamená, že tato změna způsobu, jakým SafetyNet ověřuje odemknutí bootloaderu, ovlivní většinu zařízení, která jsou mimo provoz tam. Vzhledem k tomu, že starší zařízení bez izolovaného zabezpečeného prostředí zjevně nemohou provádět hardwarově podporovanou atestaci, Magisk bude stále schopen skrýt přístup root na těchto zařízeních. Pokud se však tato změna široce rozšíří, všichni ostatní budou muset udělat těžkou volbu mezi root přístupem a bankovními aplikacemi.
Bohužel existuje pravděpodobně mnoho aplikací, které používají kontroly SafetyNet, když to ve skutečnosti nepotřebují. Jedním z příkladů, které uvádí topjohnwu, je oficiální aplikace McDonald's, která zdánlivě odmítá běžet na zařízení odemknutém bootloaderem. Na Twitteru topjohnwu nazývá aplikace, které nadměrně využívají API, jako vytváření nepřátelského prostředí pro pokročilé uživatele. XDA uznávaný vývojář Quinny899 připojuje se anekdotou o tom, jak jeho tým zvažoval použití SafetyNet ke kontrole stavu zabezpečení zařízení. Nakonec se rozhodli, že to neprovedou, protože aplikace jeho týmu šifruje všechna citlivá data, se kterými pracuje. Tvrdí, že SafetyNet by se neměl používat namísto řádného zabezpečení a postupů nakládání s daty, zejména při zvažování možnost zneužití superuživatele.
Další informace o tom, jak nová změna SafetyNet ovlivňuje Magisk, najdete v topjohnwu's vynikající FAQ na Twitteru. Pokud si jen chcete ověřit, zda je vaše zařízení součástí nového testu společnosti Google SafetyNet, můžete jej sledovat tohoto průvodce od XDA Senior Member Displax nebo si stáhněte nejnovější verzi Magisk Manager.
Tento článek byl aktualizován v 10:46 EST dne 30. června 2020, aby bylo opraveno, že Google vyplácí odměny pouze za zranitelnosti TEE nalezené v telefonech Pixel. Kromě toho byly přidány podrobnosti týkající se nejnovější verze Magisk Manager, která nyní zobrazuje pole evaluaceType ve vestavěné kontrole SafetyNet.