שׁוֹעֵר

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

כאשר משתמשים מאמתים את הסיסמאות שלהם, Gatekeeper משתמש בסוד המשותף שמקורו ב-TEE כדי לחתום על אישור אימות לשליחה לחנות המפתחות המגובה בחומרה . כלומר, אישור Gatekeeper מודיע ל-Keystore שניתן לשחרר מפתחות הקשורים לאימות (לדוגמה, מפתחות שיישומים יצרו) לשימוש על ידי אפליקציות.

ארכיטקטורה

שומר הסף כולל שלושה מרכיבים עיקריים:

• gatekeeperd (דמון שומר הסף). שירות קלסר C++ המכיל לוגיקה בלתי תלויה בפלטפורמה ומתאים לממשק GateKeeperService Java.
• שכבת אבסטרקציית חומרת שומר סף (HAL) . ממשק HAL ב- hardware/libhardware/include/hardware/gatekeeper.h , ומודול היישום.
• שומר סף (TEE) . המקבילה TEE של gatekeeperd . יישום מבוסס TEE של Gatekeeper.

Gatekeeper דורש הטמעה של Gatekeeper HAL (במיוחד הפונקציות ב- hardware/libhardware/include/hardware/gatekeeper.h ) ואת רכיב ה-gatekeeper הספציפי ל-TEE (מבוסס בחלקו על קובץ הכותרת system/gatekeeper/include/gatekeeper/gatekeeper.h הכולל פונקציות וירטואליות טהורות ליצירה/גישה למפתחות וחתימות מחשוב).

LockSettingsService מגיש בקשה (דרך Binder) שמגיעה לדמון gatekeeperd במערכת ההפעלה אנדרואיד. הדמון gatekeeperd מגיש בקשה שמגיעה למקבילו (שומר הסף) ב-TEE:

איור 1. זרימת נתונים ברמה גבוהה לאימות על ידי GateKeeper

הדמון gatekeeperd נותן לממשקי API של מסגרת אנדרואיד גישה ל-HAL, ומשתתף בדיווח על אימות מכשירים ל-Keystore. gatekeeperd פועל בתהליך משלו ונפרד משרת המערכת.

יישום HAL

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

הטמעות של קובץ הכותרת hardware/libhardware/include/hardware/gatekeeper.h חייבות ליישם את הפונקציות enroll verify :

• פונקציית enroll לוקחת כתם סיסמה, חותמת עליה ומחזירה את החתימה כנקודת אחיזה. הבלוק המוחזר (מקריאה enroll ) חייב להיות בעל המבנה המוצג ב- system/gatekeeper/include/gatekeeper/password_handle.h .
• פונקציית verify חייבת להשוות את החתימה המופקת מהסיסמה שסופקה ולוודא שהיא תואמת את ידית הסיסמה הרשומה.

אסור שהמפתח המשמש לרישום ואימות לא ישתנה, ואמור להיות ניתן לגזירה מחדש בכל אתחול המכשיר.

מימושים אמינים ואחרים

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

Trusty משתמש במערכת IPC פנימית כדי להעביר סוד משותף ישירות בין Keymaster והיישום של Trusty של Gatekeeper ( שומר הסף הנאמן ). הסוד המשותף הזה משמש לחתימה על AuthTokens שנשלחו ל-Keystore כדי לספק אישורים של אימות סיסמה. Trusty Gatekeeper מבקש את המפתח מ-Keymaster עבור כל שימוש ואינו ממשיך או מאחסן את הערך. מימושים חופשיים לשתף את הסוד הזה בכל דרך שאינה מתפשרת על אבטחה.

מפתח ה-HMAC המשמש לרישום ואימות סיסמאות נגזר ונשמר אך ורק ב-GateKeeper.

אנדרואיד מספקת יישום C++ גנרי של GateKeeper הדורש רק הוספת שגרות ספציפיות למכשיר כדי להשלים. כדי ליישם TEE Gatekeeper עם קוד ספציפי למכשיר עבור ה-TEE שלך, עיין בפונקציות וההערות ב- system/gatekeeper/include/gatekeeper/gatekeeper.h . עבור TEE GateKeeper, האחריות העיקרית של יישום תואם כוללות:

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

מזהי משתמש מאובטח (SID)

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

ה-SID של המשתמש נרשם ב-HMAC יחד עם הסיסמה בידית הסיסמה כאשר הסיסמה נרשמה.

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

בקש מצערת

GateKeeper חייב להיות מסוגל למנוע בצורה מאובטחת ניסיונות של כוח גס על אישור משתמש. כפי שמוצג ב- hardware/libhardware/include/hardware/gatekeeper.h , ה-HAL מספק החזרת פסק זמן באלפיות שניות. פסק הזמן מודיע ללקוח שלא להתקשר שוב ל-GateKeeper עד לאחר שהפסקה חלפה; GateKeeper לא אמור לתת שירות בבקשות אם יש פסק זמן בהמתנה.

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

אם המכשיר נתמך, מומלץ מאוד שמונה הכשלים ייכתב לאחסון מאובטח. אם המכשיר אינו תומך בהצפנה מבוססת קבצים, או אם אחסון מאובטח איטי מדי, הטמעות עשויות להשתמש ישירות ב-Replay Protected Memory Block (RPMB).