Authentication

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

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

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

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

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

הרשמה

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

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

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

אימות

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

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

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

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

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

פורמט AuthToken

הפורמט של AuthToken נקבע לפי מפרט AIDL ב-HardwareAuthToken.aidl.

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

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

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

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

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

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

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