Απαιτείται προστασία επαναφοράς του Android Oreo σε τηλέφωνα που κυκλοφορούν με Android Pie

Android Pie (Android 9) μόλις βγήκε ζωντανά σήμερα για το Google Pixel, το Google Pixel 2 και ακόμα και το Απαραίτητο τηλέφωνο. Μαθαίνουμε όσα περισσότερα μπορούμε για την κυκλοφορία από συνεντεύξεις (το Google Pixel 3 θα έχει μόνο πλοήγηση με χειρονομίες!), ο Απόπτωση κώδικα AOSP, και τέλος το Έγγραφο Ορισμού Συμβατότητας (CDD). Δημοσιεύσαμε για α νέα δυνατότητα για εφαρμογές "βαρέων βαρών". νωρίτερα σήμερα, αλλά τώρα ανακαλύψαμε ότι η Google άλλαξε τη διατύπωσή της σε μια λειτουργία που εισήχθη στο Android Oreo: προστασία ανατροπής. Η δυνατότητα καθίσταται δυνατή από Android Verified Boot 2.0 (γνωστό και απλώς ως Verified Boot), ωστόσο, οι OEM δεν ήταν υποχρεωμένοι να εφαρμόσουν το AVB 2.0 στην έκδοση Oreo. Τώρα, η Google επιβάλλει όλες τις συσκευές που κυκλοφορούν με Android Pie να υποστηρίζουν το Verified Boot και κατ' επέκταση την προστασία επαναφοράς.

Προστασία επαναφοράς στο Android Oreo

Η ουσία της δυνατότητας είναι ότι θα αποτρέψει την εκκίνηση του τηλεφώνου σας εάν εντοπίσει ότι η συσκευή έχει υποβαθμιστεί σε μια παλαιότερη, πλέον μη εγκεκριμένη έκδοση λογισμικού που έχει κριθεί ανασφαλής λόγω ασφάλειας τρωτό. Μια ελαφρώς πιο τεχνική εξήγηση είναι ότι η δομή δεδομένων VBMeta, η οποία κρατά τον κατακερματισμό για το διαμέρισμα εκκίνησης και μεταδεδομένα κατακερματισμού για κατατμήσεις συστήματος και προμηθευτών, χρησιμοποιεί ένα ευρετήριο επαναφοράς για να απορρίψει εικόνες που έχουν παλαιότερη επαναφορά δείκτης.

Αυτή η δυνατότητα είναι παρούσα σε συσκευές όπως το Google Pixel 2, το Razer Phone και το OnePlus 6, αλλά δεν υπάρχει σε πολλές άλλες συσκευές όπως το Samsung Galaxy S9 (αν και η Samsung προσφέρει τη δική της μορφή Προστασία ανατροπής στο Knox.) Τώρα, η Google καθιστά υποχρεωτική τη λειτουργία για κάθε συσκευή που εκκινείται με Android Pie.

Επαληθευμένη εκκίνηση στο Android Pie

Σύμφωνα με την ενημερωμένη διατύπωση στην ενότητα "Ακεραιότητα συσκευής" στο Έγγραφο ορισμού συμβατότητας, οι συσκευές που ξεκινούν με Android 9 πρέπει να υποστηρίζουν Επαληθευμένη εκκίνηση.

9.10. Ακεραιότητα συσκευής

Οι ακόλουθες απαιτήσεις διασφαλίζουν ότι υπάρχει διαφάνεια ως προς την κατάσταση της ακεραιότητας της συσκευής. Υλοποιήσεις συσκευής:

• [C-0-1] ΠΡΕΠΕΙ να αναφέρει σωστά μέσω της μεθόδου System API PersistentDataBlockManager.getFlashLockState() εάν η κατάσταση του bootloader τους επιτρέπει να αναβοσβήνει η εικόνα του συστήματος. Η κατάσταση FLASH_LOCK_UNKNOWN προορίζεται για εφαρμογές αναβάθμισης συσκευών από παλαιότερη έκδοση του Android όπου δεν υπήρχε αυτή η νέα μέθοδος API συστήματος.
• [C-0-2] ΠΡΕΠΕΙ να υποστηρίζει το Verified Boot για την ακεραιότητα της συσκευής.

Εάν οι υλοποιήσεις συσκευών έχουν ήδη ξεκινήσει χωρίς να υποστηρίζεται η επαληθευμένη εκκίνηση σε παλαιότερη έκδοση του Android και δεν μπορούν να προσθέσουν υποστήριξη για αυτήν τη δυνατότητα με μια ενημέρωση λογισμικού συστήματος, ΜΠΟΡΕΙ να εξαιρεθούν από το απαίτηση.

...

• [C-1-10] ΠΡΕΠΕΙ να εφαρμόσει προστασία επαναφοράς για διαμερίσματα που χρησιμοποιούνται από το Android (π.χ. εκκίνηση, διαμερίσματα συστήματος) και χρησιμοποιήστε χώρο αποθήκευσης με προφανή παραβίαση για την αποθήκευση των μεταδεδομένων που χρησιμοποιούνται για τον προσδιορισμό του ελάχιστου επιτρεπόμενου λειτουργικού συστήματος εκδοχή.
• ΠΡΕΠΕΙ να εφαρμόζει προστασία επαναφοράς για οποιοδήποτε στοιχείο με μόνιμο υλικολογισμικό (π.χ. μόντεμ, κάμερα) και ΠΡΕΠΕΙ να χρησιμοποιεί αποθηκευτικό χώρο με εμφανή παραβίαση για την αποθήκευση των μεταδεδομένων που χρησιμοποιούνται για τον καθορισμό του ελάχιστου επιτρεπόμενου εκδοχή.

Όπως μπορείτε να δείτε στα δύο τελευταία σετ κουκκίδων, υπάρχει μια προειδοποίηση που πρέπει να σημειωθεί. Απαιτείται προστασία επαναφοράς για διαμερίσματα που χρησιμοποιούνται από το Android (εκκίνηση, σύστημα, προμηθευτής κ.λπ.) αλλά όχι για διαμερίσματα με μόνιμο υλικολογισμικό (μόντεμ, κάμερα κ.λπ.). Το προηγούμενο σύνολο κατατμήσεων είναι το σημείο όπου ανακαλύπτονται και διορθώνονται τα περισσότερα από τα τρωτά σημεία ασφαλείας, επομένως είναι ωραίο να βλέπουμε ότι η προστασία αυτών των κατατμήσεων είναι υποχρεωτική. Ωστόσο, υπήρξαν εκμεταλλεύσεις που στοχεύουν κατατμήσεις με μόνιμο υλικολογισμικό, επομένως δεν είμαστε βέβαιοι γιατί η Google δεν επιβάλλει την προστασία επαναφοράς σε αυτά.

Ανώτερο μέλος του XDA npjohnson, μέλος της ομάδας LineageOS, εικάζει ότι η απαίτηση προστασίας από επαναφορά σε διαμερίσματα με μόνιμο υλικολογισμικό θα απαιτούν συνδέσεις δευτερεύοντος φορτωτή εκκίνησης (SBL) και eXtensible Bootloader (XBL), καθώς αυτά τα διαμερίσματα έχουν τοποθετηθεί νωρίτερα στην εκκίνηση επεξεργάζομαι, διαδικασία. Θα ήταν δαπανηρό για μικρότερους OEM να εφαρμόσουν προσαρμοσμένα XBL που να ταιριάζουν με τα προσαρμοσμένα μόντεμ και άλλα μόνιμα διαμερίσματα, Επομένως, ίσως η Google να μην το κάνει αυτό ως απαίτηση για να διευκολύνει τους κατασκευαστές συσκευών να πληρούν τις πιο πρόσφατες απαιτήσεις στο CDD.

Πώς να ελέγξετε αν το τηλέφωνό σας υποστηρίζει AVB 2.0

Υπάρχουν δύο εντολές κελύφους ADB που μπορείτε να χρησιμοποιήσετε για να ελέγξετε εάν το τηλέφωνό σας υποστηρίζει AVB 2.0.

adb shell
dumpsys package | grep "verified_boot"

Ή

adb shell
getprop | grep "avb"

Εάν η έξοδος της πρώτης εντολής είναι "android.software.verified_boot", τότε υποστηρίζεται το AVB 2.0. Εάν η έξοδος της δεύτερης εντολής εμφανίζει "[ro.boot.avb_version]" και "[ro.boot.vbmeta.avb_version]" και αναφέρει έναν αριθμό έκδοσης για καθεμία, τότε υποστηρίζεται.

Επαληθευμένη εκκίνηση και προσαρμοσμένη ανάπτυξη

Το Android Verified Boot δεν επηρεάζει πραγματικά τους περισσότερους χρήστες προσαρμοσμένης ROM, αν και προσθέτει ένα επιπλέον επίπεδο ασφάλειας που πρέπει να επιλύσετε σε ορισμένες περιπτώσεις. Για παράδειγμα, αναβοσβήνει μια Γενική Εικόνα συστήματος απαιτεί απενεργοποίηση του AVB. Η τροποποίηση ορισμένων κατατμήσεων όπως ο προμηθευτής στο OnePlus 6 απαιτεί επίσης την απενεργοποίηση του AVB, όπως έμαθα πρόσφατα. Σύμφωνα με npjohnson, η σωστή εφαρμογή του AVB 2.0 καθιστά δυνατή τη λειτουργία προσαρμοσμένων εικόνων εκκίνησης με κλειδωμένο φορτωτή εκκίνησης. Θα δούμε πώς η συμπερίληψη του AVB 2.0 σε συσκευές που αποστέλλονται με Android Pie επηρεάζει το τοπίο, αλλά ελπίζουμε ότι δεν θα οδηγήσει σε καταστάσεις όπως η πρόσφατος φόβος bricking στην κοινότητα Xiaomi Redmi Note 5 Pro. Το υποχρεωτικό AVB 2.0 είναι απλώς ένας άλλος τρόπος για να το κάνει η Google βελτιώστε την ασφάλεια της πλατφόρμας Android, αλλά η μεγαλύτερη αλλαγή, κατά την άποψή μας, είναι η εκ νέου επεξεργασία των συμφωνιών OEM για την επιβολή τακτικών ενημερώσεων κώδικα ασφαλείας.