tillbaka i Mars märkte några användare med Magisk installerad att deras enheter misslyckades SafetyNet-certifiering. Den här nyheten var oroande för samhället på XDA eftersom det betyder att många viktiga Bank – /finansappar och populära spel som Pok Auclumon Go och Fate/Grand Order vägrade att köra på rotade enheter. Under en tid verkade det som om de skärpta begränsningarna i SafetyNet drogs tillbaka, bara för att rulla ut igen för en handfull användare under de senaste veckorna. Google bekräftade dock tyst i början av maj att de testade hårdvarubaserad certifiering för SafetyNet-svar, vilket gjorde att Magisk inte kunde dölja bootloader-upplåsningsstatusen tillbaka i Mars. Om denna förändring i stor utsträckning rullar ut, kommer det att innebära att användarna måste välja mellan att ha tillgång till root/custom ROM/kärnor/etc. eller deras föredragna bankappar och spel. En av Android: s största överklaganden för kraftanvändare kan snart vara borta.
för att sammanfatta denna serie händelser bör vi först prata om SafetyNet själv. SafetyNet är en uppsättning API: er i Google Play-tjänster. SafetyNet Attestation API är en av dessa API: er, och det kan anropas av tredjepartsapplikationer för att kontrollera om enhetens mjukvarumiljö har manipulerats på något sätt. API kontrollerar för olika saker som tecken på superanvändare binärer, bootloader låsa status, och mer. När du rotar en enhet med Magisk, det ”en isolerad” säker miljö ”för detekteringsprocessen, och det går igenom Googles API för att skapa ett legit SafetyNet-resultat som inte återspeglar enhetens verkliga status”, per XDA Senior erkänd Utvecklare topjohnwu. Detta gör det möjligt för användaren att rota sin telefon samtidigt som API returnerar alltid ”false” för alla bootloader upplåsning kontroller. Denna metod för att kringgå Safetynets bootloader-upplåsningsdetektering har tränat för Magisk de senaste åren, men det beror bara på att Google har hållit på att verifiera integriteten hos startbilden med hjälp av hårdvarucertifiering. I Mars verkade det som om Google äntligen började använda hårdvarucertifiering i SafetyNet för att verifiera startbilden, men vi fick aldrig ett officiellt uttalande från Google som bekräftade ändringen och endast ett fåtal användare påverkades. Som upptäckt av XDA Senior Member Displax bekräftade Google dock den 5 maj 2020 att SafetyNet Attestation API-svar från vissa enheter nu innehåller hårdvarubackade kontroller.
på Google-gruppen för ”SafetyNet API-klienter” detaljerade Google en ny funktion för Attestation API: evaluationType. JSON Web Signature (JWS) svar från vissa enheter kommer att ha ett fält som heter ”evaluationType” som ”kommer att ge utvecklare med insikt i vilka typer av signaler/mätningar som har bidragit till varje enskild SafetyNet Attestation API svar.”En av de stödda tokens i detta fält är ”HARDWARE_BACKED” vilket indikerar att API ” de tillgängliga hårdvarubaserade säkerhetsfunktionerna på fjärrenheten (t.ex. maskinvarubaserad nyckelbevis) för att påverka utvärderingen.”Google säger att de” för närvarande utvärderar och justerar behörighetskriterierna för enheter där vi kommer att förlita oss på hårdvarubackade säkerhetsfunktioner.”Vad det här betyder är att Google Play Services på vissa enheter nu använder hårdvarubaserad certifiering för att upptäcka att enhetens programvara inte har manipulerats. Google har inte officiellt dokumenterat denna förändring utanför meddelandet i Google-gruppen, så vissa utvecklare som använder SafetyNet kanske inte är medvetna om denna förändring (och kontrollerar därför ännu inte fältet ”HARDWARE_BACKED” i JWS-svar.) Men för de appar som söker efter det här fältet finns det nu inget sätt att dölja root-åtkomst från dem, förutsatt att din enhet är en del av testet som Google kör.
enligt topjohnwu innebär hårdvarubackad certifiering att Google Play Services nu” ett omodifierat keystore-certifikat till SafetyNet-servrar, dess legitimitet och certifikatförlängningsdata för att veta om din enhet verifierad start aktiverad (bootloader status).”Eftersom de privata nycklarna från vilka keystore-certifikaten härrör från stöds av telefonens isolerade säkra miljö, skulle hämtning av dem innebära att man besegrar säkerheten för telefonens Trusted Execution Environment (TEE) eller dedicated hardware security module (HSM). Om man på något sätt kunde läcka en privat nyckel skulle nycklarna snabbt återkallas när Google fick reda på det. Google erbjuder hundratusentals dollar i belöningar för eventuella kritiska säkerhetsproblem som påverkar TEE I Pixel-telefoner, vilket bara visar att det är otroligt osannolikt att detta är en potentiell väg att kringgå bootloader-upplåsningsdetektering ändå.
ett annat potentiellt sätt att Magisk kan fortsätta att förfalska bootloader-upplåsningsstatusen är att ändra Safetynets klientkod för att alltid använda den grundläggande utvärderingen. Som topjohnwu noterar, fastän, detta skulle kräva att injicera anpassad kod i Google Play-tjänster via en hooking ram som Xposed Framework. Detta är inte bara svårt att göra eftersom Google Play Services är mycket obfuscated men det är också omöjligt att dölja som ”en del minnesutrymme analys kommer att avslöja kod manipulation mycket lätt.”Dessutom skulle detta bara fungera om Googles servrar fortsätter att acceptera grundläggande utvärderingar och om HARDWARE_BACKED-utvärderingar inte verkställs på enheter som stöder dem. (SafetyNet svar” från Googles servrar och är signerade med Googles privata nyckel”, enligt topjohnwu, så de faktiska svaren kan inte förfalskas.)
sedan Android 7 Nougat har Google krävt att alla enheter har en isolerad säker miljö, vilket innebär att denna förändring av hur SafetyNet verifierar upplåsning av bootloader kommer att påverka de flesta enheter som finns där ute. Eftersom äldre enheter utan en isolerad säker miljö uppenbarligen inte kan utföra hårdvarubaserad certifiering, kommer Magisk fortfarande att kunna dölja root-åtkomst på dessa enheter. Men om denna förändring rullar ut i stor utsträckning måste alla andra göra ett svårt val mellan root-åtkomst och bankappar.
tyvärr finns det förmodligen många appar där ute som använder SafetyNet-kontroller när de inte behöver. Ett exempel som Citeras av topjohnwu är den officiella McDonalds app, som till synes vägrar att köra på en bootloader olåst enhet. På Twitter ropar topjohnwu ut appar som överanvänder API: et som att skapa en fientlig miljö för avancerade användare. XDA erkänd Utvecklare Quinny899 ansluter sig till en anekdot om hur hans team övervägde att använda SafetyNet för att kontrollera enhetens säkerhetsstatus. De bestämde sig slutligen för att inte gå igenom det eftersom hans lags app krypterar all känslig data som den fungerar med. SafetyNet, hävdar han, bör inte användas i stället för korrekt säkerhets-och datahanteringspraxis, särskilt när man överväger möjligheten till superanvändarutnyttjande.
jag förespråkar @AndroidDev för att begränsa hårdvarubaserad SafetyNet-utvärdering till ”riktiga” säkerhetskänsliga appar. Utvecklare bör gå igenom en ansökningsprocess för att kvalificera denna nivå av API-åtkomst. Det är löjligt för McDonalds att vägra att köra på en bootloader olåst enhet.
för mer information om hur den nya SafetyNet-förändringen påverkar Magisk, kolla in topjohnwus utmärkta FAQ på Twitter. Om du bara vill kontrollera om din enhet är en del av Googles nya SafetyNet-test kan du följa den här guiden av XDA Senior Member Displax eller ladda ner den senaste Magisk Manager-versionen.
uppdaterad Magisk Manager för att återspegla fältet evaluationType i SafetyNet-kontroller så att folk kan börja räkna de sista dagarna av ära
pic.twitter.com/x61tGjM7IK
den här artikeln uppdaterades klockan 10: 46 EST den 30 juni 2020 för att korrigera att Google bara betalar ut belöningar för tee-sårbarheter som finns i Pixel-telefoner. Dessutom tillkom detaljer om den senaste Magisk Manager-versionen som nu visar fältet evaluationType i den inbyggda SafetyNet-kontrollen.
- om författaren
- Läs detta nästa
- Google forms Android Ready se Alliance för att driva antagandet av digitala bilnycklar och körkort
- Fairphone 2 från 2015 får nu officiell uppdatering till Android 9 Pie
- Motorolas Moto G50 sportar ett budget 5G-chip och ett lågt pris
- ASUS släpper nya uppdateringar för ROG Phone 5, ROG Phone 3 och ROG Phone II med säkerhetsuppdateringar och buggfixar
om författaren
Mishaal Rahman
jag är chefredaktör för XDA. Förutom att bryta nyheter på Android OS och mobila enheter, hanterar jag allt redaktionellt och granskar innehåll på Portalen. Tips / media förfrågningar: [email protected].
Läs detta nästa
-
Google forms Android Ready se Alliance för att driva antagandet av digitala bilnycklar och körkort
-
Fairphone 2 från 2015 får nu officiell uppdatering till Android 9 Pie
-
Motorolas Moto G50 sportar ett budget 5G-chip och ett lågt pris
-
ASUS släpper nya uppdateringar för ROG Phone 5, ROG Phone 3 och ROG Phone II med säkerhetsuppdateringar och buggfixar
