Skrytie prístupu root v Magisku bude oveľa ťažšie vďaka nedávnej zmene v SafetyNet, ktorá prináša osvedčenie hardvéru.
V marci malo niekoľko používateľov nainštalovaný Magisk všimol že ich zariadenia neprešli atestáciou SafetyNet. Táto správa znepokojovala komunitu v XDA, pretože to znamená, že mnohé kľúčové bankové/finančné aplikácie a populárne hry ako Pokémon Go a Fate/Grand Order odmietli bežať na rootnutých zariadeniach. Nejaký čas sa zdalo, že sprísnené obmedzenia v SafetyNet boli stiahnuté, aby sa v posledných týždňoch opäť spustili pre hŕstku používateľov. Google však začiatkom mája potichu potvrdil, že testuje hardvérom podporovanú atestáciu Odpovede SafetyNet, čo spôsobilo, že Magisk nedokázal skryť stav odomknutia zavádzača späť marca. Ak sa táto zmena široko rozšíri, bude to znamenať, že používatelia si budú musieť vybrať medzi prístupom k root/vlastným ROM/jadrám/atď. alebo ich preferované bankové aplikácie a hry. Jedna z najväčších apelácií Androidu pre náročných používateľov by mohla byť čoskoro preč.
Aby sme zhrnuli túto sériu udalostí, mali by sme najprv hovoriť o samotnej SafetyNet. SafetyNet je sada rozhraní API v službách Google Play. SafetyNet Attestation API je jedným z týchto rozhraní API a môžu ho volať aplikácie tretích strán, aby skontrolovali, či sa nejakým spôsobom nemanipulovalo so softvérovým prostredím zariadenia. Rozhranie API kontroluje rôzne veci, ako sú znaky binárnych súborov superužívateľa, stav odomknutia zavádzača a ďalšie. Keď rootujete zariadenie pomocou Magisk, „[vytvorí] izolované ‚bezpečné prostredie‘ pre proces detekcie [SafetyNet] a prejde cez API Google, aby vytvoril utiecť Výsledok SafetyNet, ktorý neodráža skutočný stav zariadenia,“ uvádza XDA Senior Recognized Developer topjohnwu. To umožňuje používateľovi rootovať svoj telefón a zároveň zabezpečiť, aby API vždy vrátilo hodnotu „false“ pre všetky kontroly odomknutia zavádzača. Tento spôsob obchádzania detekcie odomknutia bootloaderu SafetyNet funguje pre Magisk už niekoľko posledných rokov rokov, ale to len preto, že Google odložil overenie integrity bootovacieho obrazu pomocou hardvéru atestácia. V marci sa zdalo, že Google konečne začal používať hardvérovú atestáciu v SafetyNet na overenie boot image, ale nikdy sme nedostali oficiálne vyhlásenie od Google, ktoré by túto zmenu potvrdilo a bolo to len pár používateľov postihnutých. Ako si všimol senior člen XDA DisplaxGoogle však 5. mája 2020 potvrdil, že odpovede SafetyNet Attestation API z niektorých zariadení teraz zahŕňajú kontroly podporované hardvérom.
V skupine Google pre „klientov rozhrania SafetyNet API“ spoločnosť Google podrobne opísala novú funkciu pre rozhranie Attestation API: assessmentType. Odpoveď JSON Web Signature (JWS) z niektorých zariadení bude mať pole s názvom „evaluationType“, ktoré „poskytne vývojárom prehľad do typov signálov/meraní, ktoré prispeli ku každej jednotlivej odozve SafetyNet Attestation API." Jeden z podporovaných tokenov v tomto poli je "HARDWARE_BACKED", čo znamená, že API "[použilo] dostupné hardvérom podporované bezpečnostné funkcie vzdialeného zariadenia (napr. atestácia kľúča podporovaná hardvérom), aby ovplyvnili [jeho] hodnotenie.“ Google hovorí, že „v súčasnosti vyhodnocujú a upravujú kritériá oprávnenosti pre zariadenia, kde sa budeme spoliehať na hardvér bezpečnostné funkcie." To znamená, že na niektorých zariadeniach Služby Google Play teraz používajú atestáciu podporovanú hardvérom na zistenie, že softvér zariadenia nebol manipulované s. Google túto zmenu oficiálne nezdokumentoval mimo oznámenia v skupine Google, takže niektorí vývojári, ktorí používajú SafetyNet, môžu neuvedomujete si túto zmenu (a teda ešte nekontrolujete pole „HARDWARE_BACKED“ v odpovediach JWS.) Avšak pre tie aplikácie, ktoré kontrolujú toto pole, teraz neexistuje spôsob, ako pred nimi skryť prístup root za predpokladu, že vaše zariadenie je súčasťou testu, ktorý Google beh.
Podľa topjohnwu atestácia podporovaná hardvérom znamená, že Služby Google Play teraz „[posielajú] neupravený certifikát úložiska kľúčov na servery SafetyNet, [overujú] jeho legitimitu a [skontroluje] údaje rozšírenia certifikátu, aby zistil, či vaše zariadenie [má] overené spustenie (stav zavádzača).“ Od súkromných kľúčov, z ktorých sú odvodené certifikáty skladu kľúčov sú podporované izolovaným bezpečným prostredím telefónu, ich načítanie by znamenalo zmarenie zabezpečenia dôveryhodného prostredia spustenia telefónu (TEE) alebo vyhradeného hardvérového zabezpečenia modul (HSM). Ak by bol nejakým spôsobom schopný uniknúť súkromný kľúč, kľúče by boli rýchlo zrušené keď to Google zistil. Google ponúka odmeny v stovkách tisíc dolárov za akékoľvek kritické bezpečnostné chyby ovplyvňujúce TEE v telefónoch Pixel, čo len dokazuje, že je neuveriteľne nepravdepodobné, že by to bol potenciálny spôsob, ako obísť detekciu odomknutia zavádzača tak ako tak.
Ďalším možným spôsobom, ako by Magisk mohol pokračovať v falšovaní stavu odomknutia zavádzača, je úprava kódu na strane klienta SafetyNet tak, aby vždy používal hodnotenie BASIC. Ako topjohnwu poznámkyTo by si však vyžadovalo vloženie vlastného kódu do Služieb Google Play prostredníctvom hákového rámca, ako je Xposed Framework. Nie je to len ťažké, pretože služby Google Play sú veľmi zahmlené, ale je to tiež nemožné skryť, pretože „nejaká analýza pamäťového priestoru odhalí manipuláciu s kódom veľmi Okrem toho by to fungovalo iba vtedy, ak by servery Google naďalej prijímali hodnotenia BASIC a ak by sa hodnotenia HARDWARE_BACKED nevynucovali na zariadeniach, ktoré podporujú ich. (Odpovede SafetyNet „[prichádzajú] zo serverov Google a sú podpísané súkromným kľúčom Google,“ podľa topjohnwu, takže skutočné odpovede nemožno sfalšovať.)
Od verzie Android 7 Nougat spoločnosť Google vyžaduje, aby všetky zariadenia mali izolované bezpečné prostredie, čo znamená, že táto zmena spôsobu, akým SafetyNet overuje odomknutie zavádzača, ovplyvní väčšinu zariadení, ktoré sú mimo prevádzky tam. Keďže staršie zariadenia bez izolovaného bezpečného prostredia očividne nemôžu vykonávať hardvérovo podporovanú atestáciu, Magisk bude stále môcť skryť prístup root na týchto zariadeniach. Ak sa však táto zmena rozšíri do šírky, všetci ostatní budú musieť urobiť ťažkú voľbu medzi root prístupom a bankovými aplikáciami.
Bohužiaľ, pravdepodobne existuje veľa aplikácií, ktoré používajú kontroly SafetyNet, keď to v skutočnosti nepotrebujú. Jedným príkladom, ktorý uviedol topjohnwu, je oficiálna aplikácia McDonald's, ktorá zdanlivo odmieta bežať na zariadení odomknutom bootloaderom. Na Twitteri topjohnwu označuje aplikácie, ktoré nadmerne využívajú API, za vytváranie nepriateľského prostredia pre náročných používateľov. XDA uznávaný vývojár Quinny899 sa pripája anekdotou o tom, ako jeho tím zvažoval použitie SafetyNet na kontrolu stavu zabezpečenia zariadenia. Nakoniec sa rozhodli, že to nebudú robiť, pretože aplikácia jeho tímu šifruje všetky citlivé údaje, s ktorými pracuje. Tvrdí, že SafetyNet by sa nemal používať namiesto riadnej bezpečnosti a praktík nakladania s údajmi, najmä pokiaľ ide o možnosť zneužitia superužívateľa.
Viac informácií o tom, ako nová zmena SafetyNet ovplyvňuje Magisk, nájdete v topjohnwu's vynikajúce časté otázky na Twitteri. Ak chcete len skontrolovať, či je vaše zariadenie súčasťou nového testu SafetyNet od spoločnosti Google, môžete ho sledovať tento návod od XDA Senior Member Displax alebo si stiahnite najnovšiu verziu Magisk Manager.
Tento článok bol aktualizovaný 30. júna 2020 o 10:46 EST, aby bolo opravené, že Google vypláca odmeny iba za chyby zabezpečenia TEE nájdené v telefónoch Pixel. Okrem toho boli pridané podrobnosti týkajúce sa najnovšej verzie Magisk Manager, ktorá teraz zobrazuje pole evaluationType vo vstavanom kontrolore SafetyNet.