אורג

‫Hardware Abstraction Layer (HAL) של Weaver‏ (IWeaver.aidl), שהוצג ב-Android 8.1, מספק ממשק מאובטח לאימות משתמשים באמצעות גורם ידע של מסך הנעילה (LSKF), כמו קוד אימות, דפוס וסיסמה.

‫Weaver מחליף את פונקציונליות האימות של LSKF ב-Gatekeeper. עם זאת, עדיין נעשה שימוש ב-Gatekeeper כדי ליצור טוקנים לאימות חומרה.

ב-Android מגרסה 9 ואילך, CDD 9.11.2 מחייב שמכשירים שתומכים ב-StrongBox יספקו חומרה מאובטחת ייעודית שתומכת באימות מאובטח של משתמשים. הטמעה של Weaver HAL באמצעות החומרה המאובטחת הזו עומדת בדרישה של 'אימות מאובטח של משתמשים'.

במכשירים ללא רכיב מאובטח (SE) ייעודי, עדיין אפשר להטמיע את Weaver בסביבת מחשוב אמינה (TEE) כמו Trusty.

ב-Android מגרסה 17 ואילך, מומלץ מאוד להטמיע את Weaver גם במכשירים ללא רכיב אבטחה ייעודי.

רכיבים

‫Weaver מורכב משלושה רכיבים:

  • ממשק Weaver AIDL‏ (IWeaver): המפרט הרשמי של HAL. ב-Android מגרסה 13 ומטה נעשה שימוש ב-HIDL במקום ב-AIDL.
  • שירות Weaver Hardware Abstraction Layer (HAL): תהליך ספציפי לספק ב-Android שמטמיע את הממשק IWeaver.
  • ‫Weaver Trusted Application (TA): הלוגיקה המרכזית שפועלת בסביבה מאובטחת. הוא מבצע אימות של LSKF ומחיל הגבלת קצב. שירות ה-HAL מתקשר עם ה-TA באמצעות ערוץ מאובטח שספציפי להטמעה.

ממשק

הממשק של Weaver מציג מערך בגודל קבוע של משבצות קבועות, שכל אחת מהן מכילה מפתח בגודל קבוע וערך בגודל קבוע. כל מיקום מודעה מזוהה באמצעות המזהה שלו, שהוא מספר שלם בטווח [0, numSlots - 1]. אפשר לגשת לערך של משבצת רק אם מספקים מפתח שתואם למפתח המאוחסן.

הממשק של Weaver מורכב בעיקר מהרכיבים הבאים:

  • ‫getConfig(): מחזירה את מספר המשבצות, גודל המפתח וגודל הערך שההטמעה תומכת בהם.
  • ‫write(): מחליפה את המשבצת שצוינה בזוג חדש של מפתח וערך. המחיקה הזו היא אטומית וגורמת לכך שאי אפשר לשחזר את הנתונים הקודמים (מחיקה מאובטחת).
  • ‫read(): מנסה לאחזר את הערך של המשבצת שצוינה. הפעולה הזו מצליחה רק אם זמן קצוב לתפוגה של הגבלת הקצב (שנאכפת על ידי ה-TA) לא פעיל והמפתח שסופק זהה בדיוק למפתח המאוחסן.
  • ‫warmUp(): ב-Android מגרסה 17 ואילך, ההגדרה הזו מציינת שייתכן שפעולת קריאה או כתיבה תתרחש בקרוב.

למפרט המלא של הממשק: IWeaver.aidl

שימוש ב-Android

כשזמינה הטמעה של Weaver, LockSettingsService בשרת של מערכת Android נעשה שימוש בה כדי להגן על נתוני המשתמשים. לכל משתמש במכשיר, LockSettingsService מנהל משבצת Weaver:

  • מפתח חריץ (weaverKey): גיבוב של ה-LSKF של המשתמש. אם למשתמש אין נעילת מסך, המערכת משתמשת במחרוזת ברירת מחדל.
  • ערך משבצת (weaverSecret): סוד קריפטוגרפי בעל אנטרופיה גבוהה שנוצר באופן אקראי.

ה-weaverSecret מיועד לאחזור רק על ידי אחת מהאפשרויות הבאות:

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

‫LockSettingsService משתמש גם ב-weaverKey וגם ב-weaverSecret כדי להצפין את הסיסמה הסינתטית של המשתמש. הסיבה לכך היא שהסיסמה הסינתטית מגנה על האחסון של פרטי הכניסה המוצפנים (CE) של המשתמשים עבור הצפנה מבוססת-קבצים (FBE) ועל המפתחות שקשורים לאימות ב-Android Keystore, ולכן הנתונים לא נגישים עד ש-Weaver משחרר את הסוד.

ב-Android מגרסה 17 ומעלה, הפונקציה LockSettingsService קוראת ל-method‏ warmUp() של Weaver כשמתחילים להזין את LSKF. הטמעות של Weaver יכולות להשתמש באות הזה כדי להעביר חומרה מאובטחת ממצב צריכת חשמל נמוכה כדי לצמצם את זמן האחזור עבור בקשת read() קרובה.

‫Weaver נגד Gatekeeper

בעבר, Gatekeeper HAL ביצע שני תפקידים שונים בהפעלה אחת של verify():

  1. אימות: בדיקת ה-LSKF, עם הגבלת קצב שמופעלת על ידי TEE.
  2. אישור: הנפקת HardwareAuthToken כדי להודיע ל-KeyMint (לשעבר Keymaster) שהאימות של LSKF הצליח.

למה אנחנו עוברים ל-Weaver?

עם ההשקה של טוקנים של איפוס סיסמה מאובטח ב-Android 8.1, הסיסמה הסינתטית הפכה לסוד הקריפטוגרפי העיקרי. שני התפקידים שמתוארים למעלה מטופלים על ידי הרשמות נפרדות ל-Gatekeeper, אחת ל-LSKF בקטע userId + 100000 ואחת לסיסמה הסינתטית בקטע userId.

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

תכונה Weaver שומרי הסף
מחיקה מאובטחת נדרש מחיקה מאובטחת, וקל להטמיע אותה כי הממשק משתמש במספר קבוע של משבצות בגודל קבוע. מחיקה מאובטחת לא נדרשת, וקשה להטמיע אותה כי הממשק תומך במספר בלתי מוגבל של הרשמות.
חומרה הוא עבר אופטימיזציה למנועי אבטחה, אבל הוא פועל גם בסביבות TEE. למעשה, רק TEE. הטמעה של התכונה הזו ב-SE לא מספקת יתרון אבטחתי בעיצוב הנוכחי.
טיפול בשגיאות קודי שגיאה ברורים יותר. קודי שגיאה לא חד-משמעיים. כתוצאה מכך, מסך הנעילה לא מבחין בין LSKF שגויים לבין כשלים לא קשורים.
אטומיות הקוד ב-LockSettingsService שמשתמש ב-Weaver מבצע שינויים ב-LSKF באופן אטומי. נתונים חדשים נכתבים במשבצת Weaver חדשה, והמשבצת הישנה נמחקת רק כשזה בטוח לעשות זאת. הקוד ב-LockSettingsService שמשתמש ב-Gatekeeper לא מבצע שינויים ב-LSKF באופן אטומי. אם משהו ישתבש בזמן שינוי ה-LSKF, יכול להיות שכל נתוני המשתמש יאבדו.

קוד הפניה

‫AOSP מכיל שתי הטמעות לדוגמה של Weaver:

  • ב-Android 17 ואילך, system/weaver/ יש הטמעה של Weaver לסביבות מאובטחות כלליות.
  • ב-Android מגרסה 8.1 ואילך, external/libese/ מכיל הטמעה של Weaver עבור רכיבים מאובטחים שתואמים ל-ISO/IEC7816-4.

בדיקה

כדי לאמת הטמעה של Weaver, משתמשים ב-VtsHalWeaverTargetTest: 

atest VtsHalWeaverTargetTest

או:

vts-tradefed run vts -m VtsHalWeaverTargetTest