ב-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 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
נקראת מוקדם מאוד באתחול המערכת אמורים להקשות על ניצול חלון ההזדמנויות הזה.