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