כריכת גרסה

ב-Keymaster 1, כל מפתחות ה-keymaster היו קשורים קריפטוגרפית ל- Root of Trust של המכשיר, או למפתח האתחול המאומת. ב-Keymaster 2 ו-3, כל המפתחות קשורים גם לרמת מערכת ההפעלה ורמת התיקון של תמונת המערכת. זה מבטיח שתוקף שמגלה חולשה בגרסה ישנה של מערכת או תוכנת TEE לא יוכל להחזיר מכשיר לגרסה הפגיעה ולהשתמש במפתחות שנוצרו עם הגרסה החדשה יותר. בנוסף, כאשר נעשה שימוש במפתח עם גרסה ורמת תיקון נתונות במכשיר ששודרג לגרסה חדשה יותר או לרמת תיקון, המפתח משודרג לפני שניתן להשתמש בו, והגרסה הקודמת של המפתח בטלה. באופן זה, עם השדרוג של המכשיר, המקשים "יצרטו" קדימה יחד עם המכשיר, אך כל החזרה של המכשיר למהדורה קודמת תגרום לכך שהמפתחות יהיו בלתי שמישים.

כדי לתמוך במבנה המודולרי של Treble ולשבור את הקישור של system.img ל-boot.img, Keymaster 4 שינה את מודל הקישור של גרסת המפתח כך שיהיו לו רמות תיקון נפרדות עבור כל מחיצה. זה מאפשר לעדכן כל מחיצה באופן עצמאי, תוך מתן הגנה לאחור.

באנדרואיד 9 למחיצות boot , system vendor יש רמת תיקון משלהם.

• מכשירים עם Android Verified Boot (AVB) יכולים לשים את כל רמות התיקון ואת גרסת המערכת ב-vbmeta, כך שמטען האתחול יכול לספק אותם ל-Keymaster. עבור מחיצות משורשרות, פרטי הגרסה עבור המחיצה יהיו ב-vbmeta המשורשר. באופן כללי, מידע על הגרסה צריך להיות vbmeta struct שמכיל את נתוני האימות (hash או hashtree) עבור מחיצה נתונה.
• במכשירים ללא AVB:
  • יישומי אתחול מאומתים צריכים לספק גיבוב של מטא נתונים של הגרסה למטען האתחול, כך שמטען האתחול יוכל לספק את הגיבוב ל-Keymaster.
  • boot.img יכול להמשיך לאחסן את רמת התיקון בכותרת
  • system.img יכול להמשיך לאחסן את רמת התיקון וגרסת מערכת ההפעלה במאפיינים לקריאה בלבד
  • vendor.img מאחסן את רמת התיקון במאפיין הקריאה בלבד ro.vendor.build.version.security_patch .
  • טוען האתחול יכול לספק hash של כל הנתונים שאומתו על ידי אתחול מאומת ל-keymaster.
• באנדרואיד 9, השתמש בתגיות הבאות כדי לספק מידע על גרסה עבור המחיצות הבאות:
  • VENDOR_PATCH_LEVEL : מחיצת vendor
  • BOOT_PATCH_LEVEL : מחיצת boot
  • OS_PATCH_LEVEL ו- OS_VERSION : מחיצת system . ( OS_VERSION הוסר מהכותרת boot.img .
• יישומי Keymaster צריכים להתייחס לכל רמות התיקון באופן עצמאי. ניתן להשתמש במפתחות אם כל פרטי הגרסה תואמים לערכים המשויכים למפתח, ו- IKeymaster::upgradeDevice() מתגלגל לרמת תיקון גבוהה יותר במידת הצורך.

שינויים HAL

כדי לתמוך בקשירת גרסה ובאישור גרסה, אנדרואיד 7.1 הוסיפה את התגים Tag::OS_VERSION ו- Tag::OS_PATCHLEVEL ואת השיטות configure ושדרוג upgradeKey . תגי הגרסה מתווספים אוטומטית על ידי יישומי Keymaster 2+ לכל המפתחות החדשים שנוצרו (או המעודכנים). יתר על כן, כל ניסיון להשתמש במפתח שאין לו גרסת מערכת הפעלה או רמת תיקון התואמת את גירסת מערכת ההפעלה הנוכחית או רמת התיקון הנוכחית של המערכת, בהתאמה, נדחה עם ErrorCode::KEY_REQUIRES_UPGRADE .

Tag::OS_VERSION הוא ערך UINT המייצג את החלקים הראשיים, המינורים והתת-מינורים של גרסת מערכת אנדרואיד כ-MMmmss, כאשר MM היא הגרסה הראשית, mm היא הגרסה המשנית ו-ss היא הגרסה המשנית. לדוגמה, 6.1.2 יוצג כ-060102.

Tag::OS_PATCHLEVEL הוא ערך UINT המייצג את השנה והחודש של העדכון האחרון למערכת בתור YYYYMM, כאשר YYYY היא השנה בת ארבע הספרות ו-MM היא החודש הדו ספרתי. לדוגמה, מרץ 2016 יוצג כ-201603.

UpgradeKey

כדי לאפשר שדרוג מפתחות לגרסת מערכת ההפעלה החדשה ולרמת התיקון של תמונת המערכת, אנדרואיד 7.1 הוסיפה את שיטת upgradeKey ל-HAL:

Keymaster 3

    upgradeKey(vec keyBlobToUpgrade, vec upgradeParams)
        generates(ErrorCode error, vec upgradedKeyBlob);

Keymaster 2

keymaster_error_t (*upgrade_key)(const struct keymaster2_device* dev,
    const keymaster_key_blob_t* key_to_upgrade,
    const keymaster_key_param_set_t* upgrade_params,
    keymaster_key_blob_t* upgraded_key);

• dev הוא מבנה המכשיר
• keyBlobToUpgrade הוא המפתח שצריך לשדרג
• upgradeParams הם פרמטרים הדרושים לשדרוג המפתח. אלה יכללו Tag::APPLICATION_ID ו- Tag::APPLICATION_DATA , הנחוצים כדי לפענח את גוש המפתח, אם הם סופקו במהלך היצירה.
• upgradedKeyBlob הוא פרמטר הפלט, המשמש להחזרת המפתח החדש.

אם upgradeKey נקרא עם בלוק מפתח שלא ניתן לנתח או שהוא לא חוקי בדרך אחרת, הוא מחזיר ErrorCode::INVALID_KEY_BLOB . אם הוא נקרא עם מפתח שרמת התיקון שלו גדולה מערך המערכת הנוכחי, הוא מחזיר ErrorCode::INVALID_ARGUMENT . אם הוא נקרא עם מפתח שגרסת מערכת ההפעלה שלו גדולה מערך המערכת הנוכחי, וערך המערכת אינו אפס, הוא מחזיר ErrorCode::INVALID_ARGUMENT . מותרים שדרוגי גרסת מערכת ההפעלה מאפס לאפס. במקרה של שגיאות בתקשורת עם העולם המאובטח, הוא מחזיר ערך שגיאה מתאים (למשל ErrorCode::SECURE_HW_ACCESS_DENIED , ErrorCode::SECURE_HW_BUSY ). אחרת, הוא מחזיר את ErrorCode::OK ומחזיר כתם מפתח חדש ב- upgradedKeyBlob .

keyBlobToUpgrade נשאר תקף לאחר שיחת upgradeKey , ותיאורטית ניתן יהיה להשתמש בו שוב אם המכשיר היה משודרג לאחור. בפועל, מאגר המפתחות קורא בדרך כלל deleteKey ב- keyBlobToUpgrade בלוק זמן קצר לאחר הקריאה ל- upgradeKey . אם keyBlobToUpgrade היה תג Tag::ROLLBACK_RESISTANT , אז upgradedKeyBlob אמור לכלול אותו גם כן (וצריך להיות עמיד בפני החזרה).

תצורה מאובטחת

הערה: Keymaster 3 הסיר את configure שיטת Keymaster 2 . המידע שסופק בעבר ל-Keymaster HALs דרך configure זמין בקבצי מאפייני המערכת, והטמעות של היצרן קוראים קבצים אלה במהלך האתחול.

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

כדי לתמוך באספקה ​​מאובטחת של מידע גרסה ל-TA, שדה OS_VERSION נוסף לכותרת של תמונת האתחול. סקריפט בניית תמונת האתחול מאכלס שדה זה באופן אוטומטי. יצרני OEM ומיישמי keymaster TA צריכים לעבוד יחד כדי לשנות את מטעני האתחול של המכשיר כדי לחלץ את מידע הגרסה מתמונת האתחול ולהעביר אותו ל-TA לפני אתחול המערכת הלא מאובטחת. זה מבטיח שתוקפים לא יכולים להפריע לאספקת מידע גרסה ל-TA.

כמו כן, יש לוודא שלתמונת המערכת יש מידע גרסה זהה לתמונת האתחול. לשם כך, שיטת התצורה נוספה ל-keymaster HAL:

keymaster_error_t (*configure)(const struct keymaster2_device* dev,
  const keymaster_key_param_set_t* params);

הארגומנט params מכיל Tag::OS_VERSION ותג Tag::OS_PATCHLEVEL . שיטה זו נקראת על ידי לקוחות keymaster2 לאחר פתיחת ה-HAL, אך לפני קריאה לשיטות אחרות. אם כל שיטה אחרת נקראת לפני ההגדרה, ה-TA מחזיר ErrorCode::KEYMASTER_NOT_CONFIGURED .

בפעם הראשונה configure נקראת לאחר אתחול המכשיר, היא צריכה לוודא שמידע הגרסה שסופק תואם למה שסופק על ידי טוען האתחול. אם פרטי הגרסה אינם תואמים, configure מחזירה את ErrorCode::INVALID_ARGUMENT , וכל שיטות המפתח האחרות ממשיכות להחזיר את ErrorCode::KEYMASTER_NOT_CONFIGURED . אם המידע תואם, configure מחזירה ErrorCode::OK , ושיטות keymaster אחרות מתחילות לפעול כרגיל.

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

מכיוון configure תיקרא על ידי המערכת שאת תוכנה היא נועדה לאמת, יש חלון הזדמנויות צר לתוקף לסכן את תמונת המערכת ולאלץ אותה לספק מידע גרסה התואם לתמונת האתחול, אך שאינה תמונת המערכת בפועל. גרסה של המערכת. השילוב של אימות תמונת אתחול, אימות dm-verity של תוכן תמונת המערכת, והעובדה configure נקראת מוקדם מאוד באתחול המערכת אמורים להקשות על ניצול חלון ההזדמנויות הזה.