At skjule root-adgang i Magisk er ved at blive meget sværere at gøre takket være en nylig ændring i SafetyNet, der bringer hardware-attestering.
Tilbage i marts installerede nogle få brugere med Magisk bemærket at deres enheder ikke kunne bekræfte SafetyNet. Denne nyhed var bekymrende for fællesskabet hos XDA, fordi det betyder, at mange vigtige bank-/finansielle apps og populære spil som Pokémon Go og Fate/Grand Order nægtede at køre på rodfæstede enheder. I nogen tid virkede det, som om de skærpede restriktioner i SafetyNet blev trukket tilbage, for så at rulle ud igen for en håndfuld brugere i de sidste par uger. Google bekræftede dog stille og roligt i begyndelsen af maj, at de testede hardware-understøttet attestation for SafetyNet-svar, hvilket er det, der gjorde, at Magisk ikke var i stand til at skjule bootloaderens oplåsningsstatus igen Marts. Hvis denne ændring kommer bredt ud, vil det betyde, at brugerne skal vælge mellem at have adgang til root/brugerdefinerede ROM'er/kerner/etc. eller deres foretrukne bankapps og spil. En af Androids største appeller til superbrugere kan snart være væk.
For at opsummere denne række af begivenheder bør vi først tale om selve SafetyNet. SafetyNet er et sæt API'er i Google Play Services. SafetyNet Attestation API er en af disse API'er, og den kan kaldes af tredjepartsapplikationer for at kontrollere, om enhedens softwaremiljø er blevet manipuleret på nogen måde. API'en tjekker for forskellige ting som tegn på superbrugerbinære filer, oplåsningsstatus for bootloaderen og mere. Når du rooter en enhed med Magisk, "[skaber] den et isoleret 'sikkert miljø' til [SafetyNet]-detektionsprocessen, og det går gennem Googles API for at oprette en lovlig SafetyNet-resultat, der ikke afspejler enhedens reelle status,” ifølge XDA Senior Recognized Developer topjohnwu. Dette giver brugeren mulighed for at roote deres telefon, samtidig med at det sikres, at API'en altid returnerer "false" for eventuelle bootloader-oplåsningskontroller. Denne metode til at omgå SafetyNet's bootloader-oplåsningsdetektion har fungeret for Magisk i de sidste par år, men det er kun fordi Google har holdt ud med at verificere integriteten af opstartsbilledet ved hjælp af hardware attestation. I marts så det ud til, at Google endelig var begyndt at anvende hardware-attestering i SafetyNet for at verificere boot image, men vi fik aldrig en officiel erklæring fra Google, der bekræftede ændringen, og det var kun få brugere påvirket. Som set af XDA Senior Member AfslappetGoogle bekræftede dog den 5. maj 2020, at SafetyNet Attestation API-svar fra nogle enheder nu inkluderer hardware-understøttede kontroller.
På Google Group for "SafetyNet API Clients" beskrev Google en ny funktion til Attestation API: evaluationType. JSON Web Signature (JWS)-svaret fra nogle enheder vil have et felt med navnet "evaluationType", der "vil give udviklere indsigt ind i de typer af signaler/målinger, der har bidraget til hvert enkelt SafetyNet Attestation API-svar." Et af de understøttede tokens i dette felt er "HARDWARE_BACKED", som angiver, at API'en "[brugte] de tilgængelige hardware-understøttede sikkerhedsfunktioner på den eksterne enhed (f.eks. hardware-understøttet nøgleattestering) for at påvirke [dens] evaluering." Google siger, at de "i øjeblikket evaluerer og justerer berettigelseskriterierne for enheder, hvor vi vil stole på hardware-understøttet sikkerhedsfunktioner." Hvad dette betyder er, at på nogle enheder bruger Google Play Services nu hardware-understøttet attestering til at registrere, at enhedens software ikke er blevet pillet ved. Google har ikke officielt dokumenteret denne ændring uden for annonceringen i Google-gruppen, så nogle udviklere, der bruger SafetyNet, kan evt. ikke være opmærksom på denne ændring (og derfor søger endnu ikke efter "HARDWARE_BACKED"-feltet i JWS-svar). Men for de apps, der søger efter dette felt, er der nu ingen måde at skjule root-adgang for dem, forudsat at din enhed er en del af testen, som Google er løb.
Ifølge topjohnwu betyder hardware-understøttet attestation, at Google Play Services nu "[sender] et umodificeret nøglelagercertifikat til SafetyNet-servere, [verificerer] dets legitimitet og [kontrollerer] certifikatudvidelsesdata for at vide, om din enhed [har] bekræftet start aktiveret (bootloader-status)." Siden de private nøgler, som nøglelagercertifikaterne er afledt fra er understøttet af telefonens isolerede sikre miljø, vil hentning af dem indebære at nedkæmpe sikkerheden i telefonens Trusted Execution Environment (TEE) eller dedikeret hardwaresikkerhed modul (HSM). Hvis man på en eller anden måde var i stand til at lække en privat nøgle, nøgler ville hurtigt blive tilbagekaldt når Google fandt ud af det. Google tilbyder hundredtusindvis af dollars i belønninger for enhver kritisk sikkerhedssårbarhed, der påvirker TEE i Pixel-telefoner, hvilket bare viser, at det er utroligt usandsynligt, at dette er en potentiel mulighed for at omgå registrering af oplåsning af bootloader alligevel.
En anden potentiel måde, hvorpå Magisk kan fortsætte med at spoofe oplåsningsstatus for bootloaderen, er ved at ændre SafetyNets klientsidekode til altid at bruge BASIC-evalueringen. Som topjohnwu noter, dog ville dette kræve indsprøjtning af tilpasset kode i Google Play Services via en hooking-ramme som Xposed Framework. Dette er ikke kun svært at gøre, fordi Google Play Services er meget sløret, men det er også umuligt at skjule, da "nogle analyser af hukommelsesplads vil afsløre kodemanipulation meget nemt." Desuden vil dette også kun fungere, hvis Googles servere fortsætter med at acceptere BASIC-evalueringer, og hvis HARDWARE_BACKED-evalueringer ikke håndhæves på enheder, der understøtter dem. (SafetyNet-svar "[kommer] fra Google-servere og er signeret med Googles private nøgle," ifølge topjohnwu, så de faktiske svar kan ikke forfalskes.)
Siden Android 7 Nougat har Google krævet, at alle enheder har et isoleret sikkert miljø, hvilket betyder, at denne ændring af, hvordan SafetyNet verificerer oplåsning af bootloader, vil påvirke de fleste enheder, der er ude der. Da ældre enheder uden et isoleret sikkert miljø åbenbart ikke kan udføre hardware-understøttet attestation, vil Magisk stadig være i stand til at skjule root-adgang på disse enheder. Men hvis denne ændring ruller ud bredt, bliver alle andre nødt til at træffe et hårdt valg mellem root-adgang og bankapps.
Desværre er der sikkert mange apps derude, der bruger SafetyNet-tjek, når de faktisk ikke har brug for det. Et eksempel citeret af topjohnwu er den officielle McDonald's app, som tilsyneladende nægter at køre på en bootloader ulåst enhed. På Twitter kalder topjohnwu apps, der overbruger API'en, for at skabe et fjendtligt miljø for superbrugere. XDA anerkendt udvikler Quinny899 slutter sig til en anekdote om, hvordan hans team overvejede at bruge SafetyNet til at kontrollere enhedens sikkerhedsstatus. De besluttede i sidste ende ikke at gå igennem med det, da hans teams app krypterer alle de følsomme data, den arbejder med. SafetyNet, hævder han, bør ikke bruges i stedet for korrekt sikkerhed og datahåndteringspraksis, især når man overvejer mulighed for superbrugerudnyttelse.
For mere information om, hvordan den nye SafetyNet-ændring påvirker Magisk, tjek topjohnwu's fremragende FAQ på Twitter. Hvis du blot vil tjekke, om din enhed er en del af Googles nye SafetyNet-test, så kan du følge med denne guide af XDA Senior Member Displax eller download den seneste Magisk Manager-udgivelse.
Denne artikel blev opdateret kl. 10:46 EST den 30. juni 2020 for at rette op på, at Google kun udbetaler belønninger for TEE-sårbarheder fundet i Pixel-telefoner. Yderligere blev der tilføjet detaljer vedrørende den seneste Magisk Manager-udgivelse, som nu viser evaluationType-feltet i den indbyggede SafetyNet-kontrol.