ב-Android יש מושג שנקרא 'אמצעי אימות של משתמשים' שמשמשים לביטול הנעילה של המכשיר ולשליטה בגישה למפתחות הצפנה. התהליך הזה כולל את הרכיבים הבאים:
- ספק שירותים ואחסון של מפתחות קריפטוגרפיים. מאחסן מפתחות הצפנה ומספק שגרות הצפנה רגילות על גבי המפתחות האלה. Android תומך ב-Keystore עם גיבוי חומרה וב-KeyMint (לשעבר Keymaster) לשירותי הצפנה, כולל הצפנה עם גיבוי חומרה לאחסון מפתחות, שעשויה לכלול סביבת מחשוב אמינה (TEE) או רכיב מאובטח (SE), כמו StrongBox.
- אמצעי אימות של משתמשים. לאשר את הנוכחות של המשתמש ו/או את האימות המוצלח שלו. Android תומך ב-Gatekeeper לאימות באמצעות קוד אימות, קו ביטול נעילה או סיסמה, וב-Fingerprint לאימות באמצעות טביעת אצבע. במכשירים עם Android מגרסה 9 ואילך אפשר להשתמש ב-
BiometricPrompt
כנקודת שילוב יחידה לטביעת אצבע ולנתונים ביומטריים נוספים. הרכיבים האלה מעבירים את מצב האימות שלהם לשירות מאגר המפתחות דרך ערוץ מאומת. (גם מערכת Android Keystore ברמת המסגרת מגובה על ידי שירות Keystore).
כל אחד מהרכיבים האלה הוא ספציפי לספק, אבל ההטמעה של הספק נדרשת כדי לעמוד במפרט של ממשק Hardware Abstraction Layer (HAL) ולעבור את הבדיקות המתאימות של חבילת הבדיקות של הספק (VTS).
ההטמעות של הספקים מחולקות בדרך כלל לשני חלקים, שמחוברים באמצעות מנגנון תקשורת ספציפי לספק :
- שירות HAL פועל כתהליך של מערכת Android ומקבל בקשות Binder ממערכת Android.
- אפליקציה מהימנה (TA) פועלת בסביבה המאובטחת ומבצעת את הפעולות המאובטחות בפועל.
הרשמה
בהפעלה הראשונה של המכשיר אחרי איפוס להגדרות היצרן, כל אמצעי האימות מוכנים לקבל הרשמות של פרטי כניסה מהמשתמש. משתמש צריך להגדיר בהתחלה קוד אימות, קו ביטול נעילה או סיסמה באמצעות Gatekeeper (או Weaver, אם הוא זמין). ההרשמה הראשונית הזו יוצרת מזהה מאובטח (SID) של משתמש בן 64 ביט שנוצר באופן אקראי, ומשמש כמזהה של המשתמש וכאסימון קשירה לחומר ההצפנה של המשתמש. מזהה האבטחה של המשתמש קשור באופן מוצפן לסיסמה של המשתמש. אימותים מוצלחים ל-Gatekeeper יוצרים AuthTokens שמכילים את מזהה האבטחה של המשתמש עבור הסיסמה הזו.
משתמש שרוצה לשנות אישור קיים צריך להציג את האישור הזה. אם פרטי כניסה קיימים מאומתים בהצלחה, מזהה האבטחה של המשתמש שמשויך לפרטי הכניסה הקיימים מועבר לפרטי הכניסה החדשים, וכך המשתמש יכול להמשיך לגשת למפתחות אחרי שינוי פרטי הכניסה.
במקרים מסוימים, אדמין של מכשיר יכול לבצע הרשמה לא מהימנה כדי לרשום פרטי כניסה חדשים בלי להציג פרטי כניסה קיימים. המשתמש יוכל לגשת למכשיר, אבל המפתחות שנוצרו תחת SID המשתמש הישן יאבדו לתמיד.
אימות
בקטע הזה מתואר תהליך אימות טיפוסי, שכולל אינטראקציות בין כמה רכיבים גם ב-Android וגם בסביבה המאובטחת. חשוב לציין שלכל הרכיבים המאובטחים יש מפתח HMAC סודי (לכל אתחול) שמשמש אותם לאימות ההודעות אחד של השני.
אחרי שמשתמש מגדיר פרטי כניסה ומקבל SID של משתמש, הוא יכול להתחיל באימות. האימות מתחיל כשהמשתמש מספק קוד אימות, קו פתיחת נעילה, סיסמה, טביעת אצבע או נתונים ביומטריים חזקים אחרים.
איור 1. תהליך האימות
- משתמש מספק שיטת אימות והשירות המשויך שולח בקשה לשירות HAL.
- במקרה של קוד אימות, קו ביטול נעילה או סיסמה,
LockSettingsService
שולחת בקשה אלgatekeeperd
. - תהליכי אימות שמבוססים על ביומטריה תלויים בגרסת Android.
במכשירים עם Android 8.x ומטה,
FingerprintService
שולח בקשה אלfingerprintd
). במכשירים עם Android 9 ומעלה,BiometricPrompt
שולח בקשה אל הדמון הביומטרי המתאים (לדוגמה,fingerprintd
לטביעות אצבע אוfaced
לזיהוי פנים) באמצעות המחלקה המתאימהBiometricManager
, כמוFingerprintManager
אוFaceManager
. בכל הגרסאות, האימות הביומטרי מתבצע באופן אסינכרוני אחרי שליחת הבקשה.
- במקרה של קוד אימות, קו ביטול נעילה או סיסמה,
- שירות ה-HAL שולח נתונים ל-TA המקביל, שיוצר AuthToken:
- לאימות באמצעות קוד אימות, קו ביטול נעילה או סיסמה,
gatekeeperd
שולח את הגיבוב של קוד האימות, קו ביטול הנעילה או הסיסמה אל Gatekeeper TA ב-TEE, דרך שירות Gatekeeper HAL. אם האימות ב-TEE מצליח, ה-TA של Gatekeeper פולט AuthToken שמכיל את ה-SID של המשתמש המתאים (חתום באמצעות מפתח ה-HMAC המשותף). - באימות באמצעות טביעת אצבע,
fingerprintd
מאזין לאירועים של טביעות אצבע ושולח את הנתונים ל-Fingerprint TA ב-TEE, דרך Fingerprint HAL. אם האימות ב-TEE מצליח, ה-TA של טביעת האצבע פולט AuthToken (שחתום באמצעות מפתח ה-HMAC של AuthToken). - במקרה של אימות ביומטרי אחר, רשימת הדמונים הביומטריים המתאימה מאזינה לאירוע הביומטרי ושולחת אותו לשירות ה-HAL הביומטרי ול-TA המתאימים.
- לאימות באמצעות קוד אימות, קו ביטול נעילה או סיסמה,
- הדמון מקבל AuthToken חתום ומעביר אותו לשירות של מאגר המפתחות דרך תוסף לממשק Binder של שירות מאגר המפתחות.
(
gatekeeperd
גם שולח הודעה לשירות של מאגר המפתחות כשהמכשיר ננעל מחדש וכשהסיסמה של המכשיר משתנה). - שירות 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 צריך להיווצר באופן אקראי בכל פעם שהמכשיר מופעל מחדש.
יש שתי דרכים נפוצות שבהן עוזרי ההוראה מקבלים גישה למפתח ה-HMAC המשותף הזה:
- הסכם סוד משותף: שירות
keystore2
מבצע פרוטוקול הסכם מפתח רב-כיווני בהפעלת המכשיר, שמאפשר נגזרת מאובטחת של מפתח ה-HMAC בין סביבות ה-TA שמשתתפות. עם זאת, למשתתפי ה-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.