ב-Verified Boot נדרש אימות קריפטוגרפי של כל הקוד והנתונים שניתנים להרצה, שהם חלק מגרסת Android שמבוצעת בה אתחול, לפני השימוש בהם. זה כולל את ליבת המערכת (שנטענת ממחיצת boot), את עץ המכשיר (שנטען ממחיצת dtbo), מחיצת system, מחיצת vendor וכן הלאה.
מחיצות קטנות, כמו boot ו-dtbo, שנקראות רק פעם אחת, בדרך כלל מאומתות על ידי טעינת כל התוכן לזיכרון ואז חישוב הגיבוב שלו. ערך ה-Hash המחושב מושווה לערך ה-Hash הצפוי. אם הערך לא תואם, מערכת Android לא תיטען.
פרטים נוספים זמינים במאמר בנושא תהליך האתחול.
במחיצות גדולות שלא נכנסות לזיכרון (למשל, מערכות קבצים), יכול להיות שנעשה שימוש בעץ גיבוב שבו האימות הוא תהליך רציף שמתבצע בזמן שהנתונים נטענים לזיכרון. במקרה הזה, גיבוב השורש של עץ הגיבוב מחושב במהלך זמן הריצה ונבדק מול ערך גיבוב השורש הצפוי. Android כולל את dm-verity driver כדי לאמת מחיצות גדולות יותר. אם בשלב מסוים הגיבוב (hash) של השורש המחושב לא תואם לערך הגיבוב (hash) של השורש הצפוי, המערכת לא משתמשת בנתונים ו-Android עובר למצב שגיאה. פרטים נוספים זמינים במאמר בנושא שחיתות ב-dm-verity.
הגיבובים הצפויים מאוחסנים בדרך כלל בסוף או בהתחלה של כל מחיצה מאומתת, במחיצה ייעודית או בשניהם. חשוב לציין שהגיבובים האלה חתומים (באופן ישיר או עקיף) על ידי ה-Root of Trust. לדוגמה, ההטמעה של AVB תומכת בשתי הגישות. פרטים נוספים זמינים במאמר בנושא הפעלה מאומתת של Android.
הגנה מפני רולבק
גם אם תהליך העדכון מאובטח לחלוטין, יכול להיות שפרצת אבטחה בקרנל של Android שאינה קבועה תאפשר להתקין באופן ידני גרסה ישנה יותר של Android שפגיעה יותר, להפעיל מחדש את המכשיר לגרסה הפגיעה ואז להשתמש בגרסת Android הזו כדי להתקין פרצת אבטחה קבועה. משם התוקף הופך לבעלים של המכשיר באופן קבוע ויכול לעשות כל דבר, כולל השבתת העדכונים.
ההגנה מפני סוג ההתקפות הזה נקראת הגנה מפני חזרה לגרסה קודמת. הגנה מפני חזרה לגרסה קודמת מיושמת בדרך כלל באמצעות אחסון שמונע שינויים לא רצויים, כדי לתעד את הגרסה העדכנית ביותר של Android, ודחיית האתחול של Android אם היא נמוכה מהגרסה המתועדת. בדרך כלל, המעקב אחר הגרסאות מתבצע ברמת המחיצה.
לפרטים נוספים על האופן שבו AVB מטפל בהגנות מפני חזרה לגרסה קודמת, אפשר לעיין בקובץ ה-README של AVB.
טיפול בשגיאות אימות
האימות עלול להיכשל בזמן האתחול (לדוגמה, אם הגיבוב המחושב במחיצה boot לא תואם לגיבוב הצפוי) או בזמן הריצה (לדוגמה, אם dm-verity נתקל בשגיאת אימות במחיצה boot).system אם האימות נכשל בזמן ההפעלה, אי אפשר להפעיל את המכשיר והמשתמש צריך לבצע שלבים כדי לשחזר את המכשיר.
אם האימות נכשל בזמן הריצה, התהליך קצת יותר מורכב. אם המכשיר משתמש ב-dm-verity, צריך להגדיר אותו במצב restart. במצב restart, אם מתגלה שגיאת אימות, המכשיר מופעל מחדש באופן מיידי עם הגדרה של דגל ספציפי שמציין את הסיבה. טוען האתחול אמור לזהות את הדגל הזה ולעבור למצב שגיאת קלט/פלט (eio) ב-dm-verity, ולהישאר במצב הזה עד להתקנת עדכון חדש.
כשמפעילים את המכשיר במצב eio, מוצג למשתמש מסך שגיאה עם הודעה על כך שהמערכת זיהתה נתונים פגומים, ושהמכשיר עלול לא לפעול בצורה תקינה. המסך מוצג עד שהמשתמש סוגר אותו. במצב eio, מנהל ההתקן dm-verity לא יפעיל מחדש את המכשיר אם תתגלה שגיאת אימות. במקום זאת, תוחזר שגיאת EIO והאפליקציה תצטרך לטפל בשגיאה.
המטרה היא שמערכת העדכון תפעל (כדי שאפשר יהיה להתקין מערכת הפעלה חדשה ללא שגיאות השחתה) או שהמשתמש יוכל להעביר מהמכשיר כמה שיותר נתונים. אחרי שמערכת ההפעלה החדשה מותקנת, טוען האתחול מזהה את מערכת ההפעלה החדשה שהותקנה ועובר חזרה למצב restart.