Authentication

ב-Android יש מושג שנקרא 'אמצעי אימות של משתמשים' שמשמשים לביטול הנעילה של המכשיר ולשליטה בגישה למפתחות קריפטוגרפיים. התהליך הזה כולל את הרכיבים הבאים:

  • ספק שירותים ואחסון של מפתחות קריפטוגרפיים. מאחסן מפתחות הצפנה ומספק שגרות הצפנה רגילות על גבי המפתחות האלה. ‫Android תומך ב-Keystore עם גיבוי חומרה וב-KeyMint (לשעבר Keymaster) לשירותי קריפטוגרפיה, כולל קריפטוגרפיה עם גיבוי חומרה לאחסון מפתחות, שעשויה לכלול סביבת מחשוב אמינה (TEE) או רכיב מאובטח (SE), כמו StrongBox.
  • אמצעי אימות של משתמשים. לאשר את הנוכחות של המשתמש ו/או את האימות המוצלח שלו. ‫Android תומך ב-Gatekeeper לאימות באמצעות קוד אימות, קו ביטול נעילה או סיסמה, וב-Fingerprint לאימות באמצעות טביעת אצבע. במכשירים עם Android מגרסה 9 ואילך אפשר להשתמש ב-BiometricPrompt כנקודת שילוב יחידה לטביעת אצבע ולנתונים ביומטריים נוספים. הרכיבים האלה מעבירים את מצב האימות שלהם לשירות מאגר המפתחות דרך ערוץ מאומת. (גם מערכת מאגר המפתחות של Android ברמת המסגרת מגובה על ידי שירות מאגר המפתחות).

כל אחד מהרכיבים האלה הוא ספציפי לספק, אבל ההטמעה של הספק נדרשת כדי לעמוד במפרט של ממשק Hardware Abstraction Layer (HAL) ולעבור את הבדיקות המתאימות של חבילת הבדיקות של הספק (VTS).

ההטמעות של הספקים מחולקות בדרך כלל לשני חלקים, שמחוברים באמצעות מנגנון תקשורת ספציפי לספק :

  • שירות HAL פועל כתהליך של מערכת Android ומקבל בקשות Binder ממערכת Android.
  • אפליקציה מהימנה (TA) פועלת בסביבה המאובטחת ומבצעת את הפעולות המאובטחות בפועל.

הרשמה

בהפעלה הראשונה של המכשיר אחרי איפוס להגדרות המקוריות, כל אמצעי האימות מוכנים לקבל הרשמות של פרטי כניסה מהמשתמש. משתמש צריך לרשום קוד אימות, קו ביטול נעילה או סיסמה ב-Gatekeeper (או ב-Weaver, אם הוא זמין). במהלך ההרשמה הראשונית נוצר מזהה משתמש מאובטח (SID) בן 64 ביט שנוצר באופן אקראי. המזהה הזה משמש כמזהה של המשתמש וכטוקן מחייב לחומר הקריפטוגרפי של המשתמש. מזהה האבטחה של המשתמש קשור באופן מוצפן לסיסמה של המשתמש. אימותים מוצלחים ל-Gatekeeper יוצרים AuthTokens שמכילים את מזהה האבטחה של המשתמש עבור הסיסמה הזו.

משתמש שרוצה לשנות אישור קיים צריך להציג את האישור הזה. אם פרטי כניסה קיימים מאומתים בהצלחה, ה-SID של המשתמש שמשויך לפרטי הכניסה הקיימים מועבר לפרטי הכניסה החדשים, וכך המשתמש יכול להמשיך לגשת למפתחות אחרי שינוי פרטי הכניסה.

במקרים מסוימים, אדמין של מכשיר יכול לבצע הרשמה לא מהימנה כדי לרשום פרטי כניסה חדשים בלי להציג פרטי כניסה קיימים. המשתמש יוכל לגשת למכשיר, אבל המפתחות שנוצרו תחת SID המשתמש הישן יאבדו לתמיד.

אימות

בקטע הזה מתואר תהליך אימות טיפוסי, שכולל אינטראקציות בין כמה רכיבים גם ב-Android וגם בסביבה המאובטחת. חשוב לציין שלכל הרכיבים המאובטחים יש מפתח HMAC סודי (לכל אתחול) שמשמש אותם לאימות ההודעות אחד של השני.

אחרי שמשתמש מגדיר פרטי כניסה ומקבל SID של משתמש, הוא יכול להתחיל באימות. האימות מתחיל כשהמשתמש מספק קוד אימות, קו פתיחת נעילה, סיסמה, טביעת אצבע או נתונים ביומטריים חזקים אחרים. תהליך האימות

איור 1. תהליך האימות

  1. משתמש מספק שיטת אימות, והשירות המשויך מבצע בקשה לשירות HAL.
    • אם משתמשים בקוד אימות, בקו ביטול נעילה או בסיסמה, LockSettingsService שולחת בקשה אל gatekeeperd.
    • תהליכי אימות שמבוססים על נתונים ביומטריים תלויים בגרסת Android. במכשירים עם Android 8.x ומטה, FingerprintService שולח בקשה אל fingerprintd). במכשירים עם Android 9 ומעלה, BiometricPrompt שולח בקשה אל דמון הביומטריה המתאים (לדוגמה, fingerprintd לטביעות אצבע או faced לזיהוי פנים) באמצעות המחלקה המתאימה BiometricManager, כמו FingerprintManager או FaceManager. לא משנה איזו גרסה, האימות הביומטרי מתבצע באופן אסינכרוני אחרי שליחת הבקשה.
  2. שירות ה-HAL שולח נתונים ל-TA המקביל, שיוצר AuthToken:
    • באימות באמצעות קוד אימות, קו ביטול נעילה או סיסמה, gatekeeperd שולח את הגיבוב של קוד האימות, קו ביטול הנעילה או הסיסמה אל Gatekeeper TA ב-TEE, דרך שירות Gatekeeper HAL. אם האימות ב-TEE מצליח, Gatekeeper TA פולט AuthToken שמכיל את ה-SID של המשתמש (חתום באמצעות מפתח ה-HMAC המשותף).
    • באימות באמצעות טביעת אצבע, fingerprintd מקשיב לאירועים של טביעות אצבע ושולח את הנתונים ל-Fingerprint TA ב-TEE, דרך Fingerprint HAL. אם האימות ב-TEE מצליח, ה-TA של טביעת האצבע פולט AuthToken (חתום באמצעות מפתח ה-HMAC של AuthToken).
    • במקרה של אימות ביומטרי אחר, רשימת הדמונים הביומטריים המתאימה מאזינה לאירוע הביומטרי ושולחת אותו לשירות הביומטרי המתאים של HAL ול-TA.
  3. הדמון מקבל AuthToken חתום ומעביר אותו לשירות מאגר המפתחות דרך תוסף לממשק Binder של שירות מאגר המפתחות. (gatekeeperd גם שולח הודעה לשירות של מאגר המפתחות כשהמכשיר ננעל מחדש וכשהסיסמה של המכשיר משתנה).
  4. שירות Keystore מעביר את אסימוני האימות ל-KeyMint ומאמת אותם באמצעות המפתח שמשותף עם Gatekeeper ועם רכיב TEE ביומטרי נתמך. מערכת KeyMint מסתמכת על חותמת הזמן בטוקן כזמן האימות האחרון, ועל סמך חותמת הזמן היא מחליטה אם לשחרר מפתח (כדי לאפשר לאפליקציה להשתמש במפתח).

תהליך האימות לא דורש תקשורת ישירה בין TAs בסביבה המאובטחת: AuthTokens עוברים מ-TA של מאמת לשירות keystore2 ב-Android, שמעביר אותם בתורו ל-TA של KeyMint. בנוסף, השירות keystore2 יכול לדחות במהירות בקשות שלא יצליחו, כי הוא יודע אילו AuthToken זמינים במערכת. כך נחסכת תקשורת IPC יקרה פוטנציאלית ל-TEE.

הפורמט של AuthToken

הפורמט של AuthToken מוגדר במפרט AIDL בכתובת HardwareAuthToken.aidl.

תהליך האתחול של המכשיר

בכל אתחול של מכשיר, צריך ליצור את מפתח ה-HMAC של AuthToken ולשתף אותו עם כל רכיבי ה-TEE (Gatekeeper,‏ KeyMint ורכיבי biometrics trustlet נתמכים). לכן, כדי להוסיף הגנה מפני מתקפות שידור חוזר, צריך ליצור מפתח HMAC באופן אקראי בכל פעם שהמכשיר מופעל מחדש.

יש שתי דרכים נפוצות שבהן ספקי TA מקבלים גישה למפתח HMAC משותף:

  • הסכם סוד משותף: שירות keystore2 מבצע פרוטוקול הסכם מפתח רב-כיווני בהפעלת המכשיר, שמאפשר נגזרת מאובטחת של מפתח ה-HMAC בין סביבות הביצוע המהימנות שמשתתפות. עם זאת, למשתתפי ה-TA צריכה להיות גישה לסוד משותף שהוגדר מראש.
  • גישה ישירה: כלי TA שפועלים באותה סביבה מאובטחת יכולים להשתמש במנגנון פנימי לתקשורת בין תהליכים (שמשתנה בהתאם לפלטפורמה) כדי לשתף את מפתח ה-HMAC.

בכל מקרה, אסור בשום אופן לאפשר גישה למפתח ה-HMAC מחוץ ל-TEE.

מערכת ההפעלה Trusty, שפועלת לצד Android, היא דוגמה ל-TEE, אבל אפשר להשתמש גם ב-TEE אחרים. מערכת Trusty משתמשת במערכת IPC פנימית כדי לתקשר ישירות בין KeyMint לבין Gatekeeper או בין Trustlet הביומטרי המתאים. מפתח ה-HMAC נשמר רק ב-KeyMint. מערכות Fingerprint ו-Gatekeeper מבקשות את המפתח מ-KeyMint לכל שימוש, והן לא שומרות את הערך באופן קבוע או במטמון.

מכיוון שלחלק מה-TEE אין תשתית IPC, לא מתבצעת תקשורת בין אפלטים ב-TEE. כך שירות ה-Keystore יכול גם לדחות במהירות בקשות שלא יצליחו, כי הוא מכיר את טבלת האימות במערכת, וכך נמנעת פעולת IPC יקרה פוטנציאלית ב-TEE.