Wat is strikt afgedwongen geverifieerd opstarten in Android Nougat?

Als je de ontwikkelingen in Android hebt gevolgd, moet je de naam "Verified Boot" de afgelopen jaren nogal eens hebben gehoord. Google introduceerde de beveiligingsfunctie in Android 4.4 (Kitkat), op een volledig niet-opdringerige manier, en heeft de zichtbaarheid ervan langzaamaan vergroot in de nieuwere releases van zijn Android-besturingssysteem.

In de afgelopen dagen hebben we nieuws gezien over de aanwezigheid van een "Strikt afgedwongen geverifieerd opstarten”In de nieuwste versie van Google van 's werelds meest gebruikte mobiele besturingssysteem. Android Nougat gebruikt een hoger niveau van beveiligingscontrole wanneer uw apparaat opstart. Terwijl Verified Boot op Marshmallow de gebruiker alleen een waarschuwing gaf, gaat Android Nougat nog een stap verder in het geval dat er iets mis is met de systeempartitie en gebruikt wat Google een 'Strictly Enforced Verified Boot' noemt, wat zal sta het apparaat helemaal niet toe om op te starten, voor het geval het anomalieën in de partitie detecteert, wijzigingen aangebracht aan de bootloader of de aanwezigheid van "kwaadaardige" code op het apparaat. Dit roept de vraag op: "Wat betekent dit precies voor de gebruikers?", Zo blijkt, het antwoord verschilt voor de twee hoofdcategorieën Android-gebruikers (gewone en ervaren gebruikers), en we gaan het antwoord voor beiden geven.

Strikt afgedwongen geverifieerd opstarten

Eerst wat achtergrondinformatie over Verified Boot: wanneer Android een verificatietest op partities uitvoert, doet het dit meestal door de partities in 4KiB-blokken te verdelen en ze te vergelijken met een ondertekende tabel. Als alles klopt, betekent dit dat het systeem helemaal schoon is. Als er echter met sommige blokken is geknoeid of deze beschadigd zijn, informeert Android de gebruiker over de problemen en laat het aan de gebruiker over om deze op te lossen (of niet)..

Dat gaat allemaal veranderen met Android Nougat en Strictly Enforced Verified Boot. Wanneer Verified Boot wordt uitgevoerd in de gedwongen modus, it tolereert geen fouten in de partities. Als het problemen detecteert, is het zal niet toestaan ​​dat het apparaat opstart, en macht laat de gebruiker opstarten in een veilige modus, om te proberen de problemen op te lossen. Strictly Enforced Verified Boot is echter niet alleen een controle tegen slechte datablokken. Het kan meestal ook fouten in datablokken corrigeren. Dit wordt mogelijk gemaakt door de aanwezigheid van Forward Error Correcting codes, die gebruikt kunnen worden om fouten in datablokken te corrigeren. Dit kan echter niet altijd werken, en in gevallen waarin dat niet het geval is, ben je vrijwel dood in het water.

Strikt afgedwongen geverifieerde boot: The Good, The Bad and The Ugly

1. Het goede

Het afdwingen van Verified Boot op Android-apparaten zal de beveiliging verbeteren op de apparaten. In het geval dat het apparaat wordt geïnfecteerd door malware, zal Strictly Enforced Verified Boot het de volgende keer dat u uw apparaat opstart het detecteren en het repareren of u mogelijk vragen er iets aan te doen.

Deze functie zal ook controleer op gegevensbeschadiging, en in de meeste gevallen zal het dankzij de FEC-codes eventuele fouten in de gegevens kunnen corrigeren. Google gebruikt FEC-codes die dat kunnen corrigeer een onbekende bitfout in 255 bits. Natuurlijk, dat lijkt een vrij klein aantal, maar laten we dat in perspectief plaatsen, met betrekking tot een mobiel apparaat:

Opmerking: De onderstaande waarden zijn ontleend aan de blogpost van Google Engineer Sami Tolvanen op Android Developers.

Google had RS (255,223) FEC-codes kunnen gebruiken: deze codes zouden 16 onbekende bitfouten in 255 bits hebben kunnen corrigeren, maar de overheadruimte vanwege de 32 bits aan overtollige gegevens zou bijna 15% zijn geweest, en dat is veel, vooral op mobiele apparaten. Voeg dat toe aan het feit dat Android het overheersende besturingssysteem is op budget-smartphones die worden geleverd met 4-8 GB geheugen, en 15% extra ruimte lijkt zeker veel.

Door de mogelijkheden voor foutcorrectie op te offeren en ruimte te besparen, besloot Google RS (255,253) FEC-codes te gebruiken. Deze codes kunnen slechts een enkele onbekende fout in 255 bits corrigeren, maar de ruimte-overhead is slechts 0,8%.

Opmerking: RS (255, N) is een weergave van Reed-Solomon-codes, een soort foutcorrectiecodes.

2. Het slechte

Ooit gehoord van "Er zijn twee kanten aan een munt"? Natuurlijk heb je. Hoewel de bedoelingen van Google met Strictly Enforced Verified Boot ongetwijfeld puur waren als een baby-eenhoorn, hebben ze wel hun eigen problemen.

Wanneer strikt afgedwongen geverifieerd opstarten controleert op malware, het controleert ook op illegale wijzigingen naar de kernel, de bootloader en andere dingen waar ik je niet mee zal vervelen, maar dit betekent dat Android Nougat waarschijnlijk veel problemen zal ondervinden met rooten en knipperende aangepaste ROM's, omdat Verified Boot geen onderscheid kan maken tussen ongewenste malwarecode, en de code die je bootloader heeft ontgrendeld. Wat betekent dat als je apparaat werd geleverd met een vergrendelde bootloader en je OEM het ontgrendelen van de bootloader niet toestaat, je dit vrijwel niet kunt. Hopelijk zal iemand hier een exploit voor bedenken.

Gelukkig gebruiken de meeste mensen die hun apparaten rooten en aangepaste ROM's flashen voor de toegevoegde functies en functionaliteit, ontwikkelaarsvriendelijke telefoons, zoals de Nexus. Er is veel te overwegen met betrekking tot dit onderwerp, en het is zeker niet het einde van aangepaste ROM's, althans niet op apparaten die worden geleverd met een ontgrendelde bootloader of waarmee de bootloader kan worden ontgrendeld. Apparaten zoals Samsung-telefoons staan ​​het ontgrendelen van de bootloader echter officieel niet toe, en op deze apparaten wordt het ontgrendelen van je bootloader door Verified Boot zeker gezien als "een probleem", waardoor het apparaat niet kan opstarten..

Een ander probleem dat zich zal voordoen bij Strictly Enforced Verified Boot, is er een dat zelfs de gebruikers treft die er niet echt om geven root-privileges te krijgen of aangepaste ROM's te installeren. Na verloop van tijd, terwijl u uw apparaat gebruikt, is er ongetwijfeld een natuurlijke beschadiging van gegevens in het geheugen; niet vanwege de aanwezigheid van malware, maar simpelweg omdat het gebeurt. Dit is meestal geen probleem, of in ieder geval niet zo ernstig als Verified Boot het zal veranderen. Als je corrupte gegevens hebt die Strictly Enforced Verified Boot niet tijdens het opstarten kan herstellen, kan je apparaat niet opstarten. Naar mijn mening is dat een groter, meer zichtbaar probleem dan sommige corrupte gegevens op de gebruikerspartitie.

3. De lelijke

In alle voordelen van het afdwingen van Verified Boot en alle mogelijke problemen, is het meest verontrustende waarschijnlijk het feit dat OEM's dit kunnen misbruiken om hun apparaten te vergrendelen, zodat mensen Android niet kunnen gebruiken waarvoor het bedoeld was. be: open, ontwikkelaarsvriendelijk en volledig aanpasbaar. Strictly Enforced Verified Boot zal in handen van OEM's komen, de kracht om ervoor te zorgen dat mensen de bootloaders op hun apparaten niet kunnen ontgrendelen, waardoor ze geen aangepaste ROM's en functie-verbeterende tools zoals Xposed-modules kunnen installeren.

ZIE OOK: Geen Android N Custom ROM beschikbaar? Wij hebben de oplossing voor u

Android Nougat: een radicale verandering in de manier waarop Android werkt?

Hoewel we zeker weten dat het de bedoeling van Google was om potentiële problemen te vermijden voor incidentele Android-gebruikers, die niet zouden weten wat ze moesten doen als hun apparaat werd getroffen door malware, of als hun geheugen gegevensblokken had beschadigd, heeft het OEM's mogelijk overhandigd en de fabrikant is het perfecte hulpmiddel om gebruikers te laten leven met wat hen werd aangeboden, en niets meer.

Natuurlijk zal iemand een exploit of een tijdelijke oplossing voor deze situatie bedenken, en we hopen dat ze dat doen, in de ware geest van Android. Totdat iemand een oplossing bedenkt, kunnen we, als gebruikers, alleen zorgen dat we onze apparaten kopen bij ontwikkelaarsvriendelijke fabrikanten.

Uitgelichte afbeelding met dank aan: Flickr