אימות

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

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

רכיבי שומר סף, טביעת אצבע וביומטרי עובדים עם Keystore ורכיבים אחרים כדי לתמוך בשימוש באסימוני אימות מגובי חומרה (AuthTokens).

הַרשָׁמָה

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

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

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

אימות

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

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

פורמט AuthToken

כדי להבטיח שיתוף אסימונים ותאימות בין שפות ורכיבים, פורמט AuthToken מתואר ב- hw_auth_token.h . הפורמט הוא פרוטוקול סדרה פשוט עם שדות בגודל קבוע.

שדה סוּג נדרש תיאור
גרסת AuthToken 1 בייט כן תג קבוצה עבור כל השדות למטה.
אתגר מספר שלם ללא סימן של 64 סיביות לא מספר שלם אקראי למניעת התקפות שידור חוזר. בדרך כלל המזהה של פעולת קריפטו מבוקשת. משמש כעת על ידי הרשאות טביעת אצבע לעסקה. אם קיים, ה-AuthToken תקף רק עבור פעולות קריפטו המכילות את אותו אתגר.
SID של משתמש מספר שלם ללא סימן של 64 סיביות כן מזהה משתמש שאינו חוזר ונקשר באופן קריפטוגרפי לכל המפתחות המשויכים לאימות המכשיר. לפרטים, ראה שומר סף .
מזהה מאמת (ASID) מספר שלם ללא סימן של 64 סיביות בסדר רשת לא מזהה המשמש כדי לאגד למדיניות מאמת ספציפית. לכל המאמתים יש ערך משלהם של ASID שהם יכולים לשנות בהתאם לדרישות שלהם.
סוג מאמת מספר שלם ללא סימן של 32 סיביות בסדר רשת כן
  • 0x00 הוא שומר סף.
  • 0x01 היא טביעת אצבע.
חותמת זמן מספר שלם ללא סימן של 64 סיביות בסדר רשת כן זמן (במילישניות) מאז אתחול המערכת האחרון.
AuthToken HMAC (SHA-256) כתם 256 סיביות כן מפתח SHA-256 MAC של כל השדות מלבד שדה HMAC.

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

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

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

מערכת ההפעלה Trusty , הפועלת לצד אנדרואיד, היא דוגמה ל-TEE, אך ניתן להשתמש ב-TEE אחרים במקום זאת. Trusty משתמש במערכת IPC פנימית כדי לתקשר ישירות בין Keymaster ו-gatekeeper או ה-trustlet הביומטרי המתאים. מפתח HMAC נשמר אך ורק ב-Keymaster; טביעת אצבע ו-gatekeeper מבקשים את המפתח מ-Keymaster עבור כל שימוש ואינם מתמידים או מאחסנים את הערך.

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