מאפיינים

בדף הזה מפורט מידע על התכונות הקריפטוגרפיות של Keystore ב-Android מגרסה 6.0 ואילך.

פרימיטיבים קריפטוגרפיים

מערכת Keystore מספקת את הקטגוריות הבאות של פעולות:

  • יצירת מפתחות
  • ייבוא וייצוא של מפתחות אסימטריים (ללא גיבוב מפתחות)
  • ייבוא של מפתחות סימטריים גולמיים (ללא גיבוב מפתחות)
  • הצפנה ופענוח אסימטרים עם מצבי מילוי מתאימים
  • חתימה ואימות אסימטרים עם יצירת סיכום (digest) ושימוש במצבי מילוי (padding) מתאימים
  • הצפנה ופענוח סימטריים במצבים מתאימים, כולל מצב AEAD
  • יצירת קודי אימות סימטריים להודעות ואימות שלהם

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

בנוסף לרשימה שלמעלה, יש שירות נוסף שהטמעות של Keymaster מספקות, אבל הוא לא מוצג כ-API: יצירת מספרים אקראיים. השירות הזה משמש באופן פנימי ליצירת מפתחות, וקטורי אתחול (IV), מילוי אקראי ורכיבים אחרים של פרוטוקולים מאובטחים שדורשים רנדומיזציה.

רכיבים בסיסיים נדרשים

כל ההטמעות של Keymaster מספקות:

  • RSA
    • תמיכה במפתחות באורך 2048, 3072 ו-4096 ביט
    • תמיכה בחזקה ציבורית F4‏ (2^16+1)
    • מצבי ריבועיות לחתימה של RSA:
      • RSASSA-PSS‏ (PaddingMode::RSA_PSS)
      • RSASSA-PKCS1-v1_5‏ (PaddingMode::RSA_PKCS1_1_5_SIGN)
    • מצבי תקציר לחתימה על מודעות RSA:
      • SHA-256
    • מצבי Padding להצפנה/לפענוח של RSA:
      • ללא ריפוד
      • RSAES-OAEP‏ (PaddingMode::RSA_OAEP)
      • RSAES-PKCS1-v1_5‏ (PaddingMode::RSA_PKCS1_1_5_ENCRYPT)
  • ECDSA
    • יש תמיכה במפתחות באורך 224,‏ 256,‏ 384 ו-521 ביט, באמצעות העקומות NIST P-224,‏ P-256,‏ P-384 ו-P-521, בהתאמה
    • מצבי תקציר ל-ECDSA:
      • ללא סיכום (האפשרות הזו הוצאה משימוש ותוסר בעתיד)
      • SHA-256
  • AES
    • יש תמיכה במפתחות באורך 128 ו-256 ביטים
    • CBC,‏ CTR,‏ ECB ו-GCM. הטמעת GCM לא מאפשרת להשתמש בתגים קטנים מ-96 ביט או באורך חד-פעמי (nonce) שונה מ-96 ביט.
    • יש תמיכה במצבי התמלאוּת PaddingMode::NONE ו-PaddingMode::PKCS7 במצבים CBC ו-ECB. ללא מילוי, ההצפנה במצב CBC או ECB נכשלת אם הקלט הוא לא מכפיל של גודל הבלוק.
  • HMAC SHA-256, עם כל גודל מפתח עד ל-32 בייטים לפחות.

מומלץ מאוד להשתמש ב-SHA1 ובשאר החברים במשפחת SHA2 (SHA-224, ‏ SHA384 ו-SHA512) בהטמעות של Keymaster. אם ההטמעה של Keymaster בחומרה לא מספקת אותם, הם יסופקו בתוכנה על ידי Keystore.

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

  • גדלים קטנים יותר של מפתחות RSA
  • מעריכים ציבוריים שרירותיים ל-RSA

בקרת גישה למפתחות

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

אמצעי בקרת הגישה מוגדרים כ'רשימת הרשאות' של צמדי תג/ערך. תגי הרשאה הם מספרים שלמים של 32 ביט, והערכים הם מגוון סוגים. אפשר לחזור על חלק מהתגים כדי לציין כמה ערכים. האפשרות לחזור על תג מצוינה בממשק HAL של KeyMint‏ (לשעבר Keymaster). כשיוצרים מפתח, מבצע הקריאה מציין רשימת הרשאות. הטמעת Keymaster שמתבססת על Keystore משנה את הרשימה כדי לציין מידע נוסף, כמו אם למפתח יש הגנה על ביטול קוד, ומחזירה רשימת הרשאות "סופית", שמקודדת ב-blob של המפתח המוחזר. כל ניסיון להשתמש במפתח לפעולה קריפטוגרפית נכשל אם רשימת ההרשאות הסופית משתנה.

ב-Keymaster 2 וגרסאות קודמות, קבוצת התגים האפשריים מוגדרת בספירה keymaster_authorization_tag_t וקבועה באופן סופי (אבל אפשר להרחיב אותה). השמות קיבלו את הקידומת KM_TAG. ארבעת הביטים העליונים של מזהי התגים משמשים לציון הסוג.

ב-Keymaster 3, הקידומת KM_TAG שונתה ל-Tag::.

סוגי הנכסים האפשריים כוללים:

ENUM: ערכים של תגים רבים מוגדרים במניינים. לדוגמה, הערכים האפשריים של TAG::PURPOSE מוגדרים ב-enum keymaster_purpose_t.

ENUM_REP: זהה ל-ENUM, אלא שאפשר לחזור על התג ברשימת הרשאות. חזרה על הערך מציינת כמה ערכים מורשים. לדוגמה, סביר להניח שמפתח הצפנה מכיל את KeyPurpose::ENCRYPT ו-KeyPurpose::DECRYPT.

UINT: מספרים שלמים ללא סימן באורך 32 ביט. דוגמה: TAG::KEY_SIZE

UINT_REP: זהה ל-UINT, אלא שאפשר לחזור על התג ברשימת הרשאות. חזרה על הערך מציינת כמה ערכים מורשים.

ULONG: מספרים שלמים ללא סימן באורך 64 ביט. דוגמה: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP: זהה ל-ULONG, אלא שאפשר לחזור על התג ברשימת הרשאות. חזרה על הערך מציינת כמה ערכים מורשים.

DATE: ערכים של תאריך/שעה, שמוצגים באלפיות שנייה מאז 1 בינואר 1970. דוגמה: TAG::PRIVKEY_EXPIRE_DATETIME

BOOL: True או False. ההנחה לגבי תג מסוג BOOL היא שהוא יהיה 'false' אם הוא לא קיים, ו-'true' אם הוא קיים. דוגמה: TAG::ROLLBACK_RESISTANT

BIGNUM: מספרים שלמים באורך שרירותי, שמתבטאים כמערך בייטים בסדר big-endian. דוגמה: TAG::RSA_PUBLIC_EXPONENT

BYTES: רצף של בייטים. דוגמה: TAG::ROOT_OF_TRUST

אכיפת מדיניות באמצעות חומרה לעומת אכיפת מדיניות באמצעות תוכנה

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

בכל ההטמעות:

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

מנגנון ה-API להצהרה על הרשאות שחלות על חומרה נמצא במבנה keymaster_key_characteristics_t. הוא מחלק את רשימת ההרשאות לשתי רשימות משנה, hw_enforced ו-sw_enforced. החומרה המאובטחת אחראית להטמיע את הערכים המתאימים בכל אחת מהן, על סמך מה שהיא יכולה לאכוף.

בנוסף, ב-Keystore מופעלת אכיפה מבוססת-תוכנה של כל ההרשאות, בין שהן נאכפות על ידי החומרה המאובטחת ובין שלא.

לדוגמה, ניקח הטמעה שמבוססת על TrustZone ולא תומכת בתוקף מוגבל של מפתחות. עדיין יכול להיווצר מפתח עם תאריך תפוגה. רשימת ההרשאות של המפתח הזה כוללת את התג TAG::ORIGINATION_EXPIRE_DATETIME עם תאריך התפוגה. בקשה ל-Keystore לקבלת מאפייני המפתח מוצאת את התג הזה ברשימה sw_enforced, והחומרה המאובטחת לא אוכפת את דרישת התפוגה. עם זאת, ניסיונות להשתמש במפתח אחרי שתוקפו פג נדחים על ידי Keystore.

אם לאחר מכן המכשיר ישודרג לחומרה מאובטחת שתומכת בתוקף, בקשה למאפייני מפתח תמצא את TAG::ORIGINATION_EXPIRE_DATETIME ברשימת hw_enforced, וניסיונות להשתמש במפתח אחרי התפוגה ייכשלו גם אם מאגר המפתחות הושחת או עקף.

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

הרשאות ליצירת הודעות קריפטוגרפיות

התגים הבאים משמשים להגדרת המאפיינים הקריפטוגרפיים של פעולות באמצעות המפתח המשויך: TAG::ALGORITHM,‏ TAG::KEY_SIZE,‏ TAG::BLOCK_MODE,‏ TAG::PADDING,‏ TAG::CALLER_NONCE ו-TAG::DIGEST.

אפשר לחזור על הערכים TAG::PADDING,‏ TAG::DIGEST ו-PaddingMode::BLOCK_MODE, כלומר אפשר לשייך כמה ערכים למפתח אחד, והערך שבו נעשה שימוש מצוין בזמן הפעולה.

המטרה

למפתחות יש קבוצה משויכת של מטרות, שמתבטאות כרשומת הרשאה אחת או יותר עם התג TAG::PURPOSE, שמגדירה את האופן שבו אפשר להשתמש בהם. המטרות הן:

  • KeyPurpose::ENCRYPT
  • KeyPurpose::DECRYPT
  • KeyPurpose::SIGN
  • KeyPurpose::VERIFY

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

ייבוא וייצוא

‏Keymaster תומך בייצוא של מפתחות ציבוריים בלבד, בפורמט X.509, ובייבוא של:

  • זוגות מפתחות ציבוריים ופרטיים בפורמט PKCS#8 בקידוד DER, ללא הצפנה מבוססת-סיסמה
  • מפתחות סימטריים כבייט גולמיים

כדי להבטיח שאפשר יהיה להבדיל בין מפתחות מיובאים למפתחות שנוצרו באופן מאובטח, המשתנה TAG::ORIGIN נכלל ברשימת ההרשאות המתאימה למפתחות. לדוגמה, אם מפתח נוצר בחומרה מאובטחת, הערך TAG::ORIGIN עם הערך KeyOrigin::GENERATED נמצא ברשימה hw_enforced של מאפייני המפתח, ואילו למפתח שיובאו לחומרה מאובטחת יש את הערך KeyOrigin::IMPORTED.

אימות משתמשים

בהטמעות מאובטחות של Keymaster לא מתבצע אימות משתמשים, אלא נעשה שימוש באפליקציות מהימנות אחרות שמבצעות אימות. הממשק שהאפליקציות האלה מטמיעות מפורט בדף Gatekeeper.

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

  • הערך TAG::ALL_USERS מציין שכל המשתמשים יכולים להשתמש במפתח. אם הערך קיים, הערך של TAG::USER_ID הוא 0 והערך של TAG::USER_SECURE_ID לא קיים.
  • TAG::USER_ID מכיל ערך מספרי שמציין את המזהה של המשתמש המורשה. חשוב לזכור שזהו מזהה המשתמש ב-Android (למספר משתמשים), ולא מזהה ה-UID של האפליקציה, והוא נאכף על ידי תוכנה לא מאובטחת בלבד. אם השדה נמצא, השדה TAG::ALL_USERS לא נמצא.
  • TAG::USER_SECURE_ID הוא ערך מספרי של 64 ביט שמציין את מזהה המשתמש המאובטח שסופק באסימון אימות מאובטח כדי לבטל את הנעילה של השימוש במפתח. אם המפתח חוזר על עצמו, אפשר להשתמש בו אם אחד מהערכים מסופק באסימון אימות מאובטח.

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

  • הערך NO_AUTHENTICATION_REQUIRED מציין שאין צורך באימות משתמש, אבל עדיין אפשר להשתמש במפתח רק באפליקציות שפועלות בתור המשתמשים שצוינו ב-TAG::USER_ID.
  • TAG::AUTH_TIMEOUT הוא ערך מספרי שמציין, בשניות, את רמת העדכניות הנדרשת של אימות המשתמש כדי לאשר את השימוש במפתח. ההגבלה הזו חלה רק על פעולות עם מפתחות פרטיים/סודיים. פעולות של מפתחות ציבוריים לא מחייבות אימות. זמן הקצאת הזמן לא חל על הפעלות מחדש. אחרי הפעלה מחדש, אף פעם לא מתבצע אימות של כל המפתחות. אפשר להגדיר את הזמן הקצוב לתפוגה לערך גדול כדי לציין שהאימות נדרש פעם אחת בכל הפעלה (2^32 שניות הן כ-136 שנים, סביר להניח שמכשירי Android מופעלים מחדש בתדירות גבוהה יותר).

דרישה למכשיר לא נעול

אפשר להשתמש במפתחות עם TAG::UNLOCKED_DEVICE_REQUIRED רק כשהמכשיר לא נעול. לסמנטיקה המפורטת, ראו KeyProtection.Builder#setUnlockedDeviceRequired(boolean).

UNLOCKED_DEVICE_REQUIRED נאכף על ידי Keystore ולא על ידי Keymaster. עם זאת, ב-Android 12 ואילך, Keystore מגן באופן קריפטוגרפי על מפתחות UNLOCKED_DEVICE_REQUIRED כשהמכשיר נעול, כדי להבטיח שברוב המקרים לא ניתן להשתמש בהם גם אם Keystore נפרץ כשהמכשיר נעול.

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

לכל משתמש (כולל פרופילים) יש שני מפתחות סופר שמשויכים ל-UNLOCKED_DEVICE_REQUIRED:

  • מפתח הסופר הסימטרי UnlockedDeviceRequired. זהו מפתח AES‑256‑GCM. הוא מצפין מפתחות UNLOCKED_DEVICE_REQUIRED שיובאו או נוצרו בזמן שהמכשיר לא נעול למשתמש.
  • מפתח הסופר האסימטרי UnlockedDeviceRequired. זהו זוג מפתחות ECDH‏ P‑521. הוא מצפין מפתחות UNLOCKED_DEVICE_REQUIRED שמיובאים או נוצרים בזמן שהמכשיר נעול למשתמש. מפתחות שמאובטחים באמצעות המפתח האסימטרי הזה מוצפנים מחדש באמצעות המפתח הסימטרי בשימוש הראשון (שיכול להתרחש רק כשהמכשיר לא נעול).

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

בנוסף, Keystore מאחסן את מפתחות הסופר האלה במטמון בזיכרון, ומאפשר לפעול על מפתחות UNLOCKED_DEVICE_REQUIRED. עם זאת, המערכת מנסה לשמור במטמון את החלקים הסודיים של המפתחות האלה רק כשהמכשיר לא נעול למשתמש. כשהמכשיר נעול למשתמש, אם אפשר, המערכת של Keystore מאפסת את העותק ששמור במטמון של החלקים הסודיים של מפתחות הסופר האלה. באופן ספציפי, כשהמכשיר נעול למשתמש, מערכת Keystore בוחרת ומחילה אחת משלוש רמות ההגנה על מפתחות הסופר של UnlockedDeviceRequired של המשתמש:

  • אם המשתמש הפעיל רק קוד אימות, קו ביטול נעילה או סיסמה, המערכת של Keystore ממירה לאפס את החלקים הסודיים של מפתחות הסופר שנשמרו במטמון. כך אפשר לשחזר את המפתחות הסופר רק באמצעות העותק המוצפן במסד הנתונים, שאפשר לפענח רק באמצעות קוד אימות, קו ביטול נעילה או סיסמה מקבילים.
  • אם למשתמש יש רק מידע ביומטרי מסוג 3 ('חזק') וקוד אימות, קו ביטול נעילה או סיסמה מופעלים, המערכת של Keystore תסדיר את שחזור מפתחות הסופר באמצעות כל אחד מהמאפיינים הביומטריים של המשתמש שנרשמו כמידע מסוג 3 (בדרך כלל טביעת אצבע), כחלופה לקוד אימות, לקו ביטול נעילה או לסיסמה מקבילים. כדי לעשות זאת, המערכת יוצרת מפתח AES‑256‑GCM חדש, מצפינה באמצעותו את החלקים הסודיים של מפתחות הסופר, מייבאת את מפתח ה-AES‑256‑GCM ל-Keymaster כמפתח שמקושר לנתונים ביומטריים, שבו נדרש אימות ביומטרי שהצליח ב-15 השניות האחרונות, ומאפסת את העותק של הטקסט ללא הצפנה של כל המפתחות האלה.
  • אם למשתמש יש מאגר אמון פעיל לביטול נעילה, או אם הוא הגדיר מאפיין ביומטרי מסוג 1 ('נוחות') או מסוג 2 ('חלש'), מפתחות הסופר נשמרים במטמון של Keystore כטקסט ללא הצפנה. במקרה כזה, לא קיימת אבטחה קריפטוגרפית למפתחות UNLOCKED_DEVICE_REQUIRED. כדי למנוע את האפשרות הזו, שהיא פחות מאובטחת, המשתמשים יכולים לא להפעיל את שיטות הנעילה האלה. שיטות הביטול הנפוצות ביותר של נעילת המכשיר בקטגוריות האלה הן ביטול נעילה באמצעות זיהוי הפנים במכשירים רבים וביטול נעילה באמצעות שעון חכם מותאם.

כשהמכשיר נעול למשתמש, אם אפשר, Keystore משחזר את מפתחות הסופר של UnlockedDeviceRequired של המשתמש. כדי לבטל את הנעילה באמצעות קוד אימות, קו ביטול נעילה או סיסמה, המערכת מפענחת את העותק של המפתחות האלה שנשמר במסד הנתונים. אחרת, היא בודקת אם נשמר עותק של המפתחות האלה שהוצפנו באמצעות מפתח שמקושר לנתונים ביומטריים, ואם כן, היא מנסה לפענח אותו. הפעולה הזו תצליח רק אם המשתמש ביצע אימות באמצעות נתונים ביומטריים ברמה 3 ב-15 השניות האחרונות, באישור של Keymaster (ולא של Keystore).

כבילת לקוח

קישור לקוח, כלומר שיוך של מפתח לאפליקציית לקוח מסוימת, מתבצע באמצעות מזהה לקוח אופציונלי ונתוני לקוח אופציונליים מסוימים (TAG::APPLICATION_ID ו-TAG::APPLICATION_DATA, בהתאמה). מערכת Keystore מתייחסת לערכים האלה כ-blobs אטומים, ומוודאת רק שאותם blobs שמוצגים במהלך יצירת המפתח או הייבוא שלו מוצגים בכל שימוש, ושהם זהים בייט אחרי בייט. נתוני הקישור של הלקוח לא מוחזרים על ידי Keymaster. מבצע הקריאה החוזרת צריך לדעת אותו כדי להשתמש במפתח.

התכונה הזו לא חשופה לאפליקציות.

תפוגה

ב-Keystore יש תמיכה בהגבלת השימוש במפתחות לפי תאריך. אפשר לשייך למפתח את תאריך ההתחלה והתאריך הסופי של התוקף שלו, ו-Keymaster לא מבצע פעולות על המפתח אם התאריך/השעה הנוכחיים נמצאים מחוץ לטווח התוקף. טווח התוקף של המפתח מצוין באמצעות התגים TAG::ACTIVE_DATETIME,‏ TAG::ORIGINATION_EXPIRE_DATETIME ו-TAG::USAGE_EXPIRE_DATETIME. ההבחנה בין 'יצירה' לבין 'שימוש' מבוססת על השימוש במפתח: 'יצירה' של טקסט מוצפן/חתימה/וכו' חדשים או 'שימוש' בטקסט מוצפן/חתימה/וכו' קיימים. שימו לב שההבחנה הזו לא מוצגת לאפליקציות.

התגים TAG::ACTIVE_DATETIME,‏ TAG::ORIGINATION_EXPIRE_DATETIME ו-TAG::USAGE_EXPIRE_DATETIME הם אופציונליים. אם התגים לא נמצאים, ההנחה היא שאפשר תמיד להשתמש במפתח הרלוונטי כדי לפענח או לאמת הודעות.

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

קישור של Root of Trust

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

Root of Trust מורכב מהמפתח הציבורי שמשמש לאימות החתימה על קובץ האימג' לאתחול ועל מצב הנעילה של המכשיר. אם המפתח הציבורי ישתנה כדי לאפשר שימוש בקובץ אימג' אחר של מערכת, או אם מצב הנעילה ישתנה, לא ניתן יהיה להשתמש באף אחד מהמפתחות המוגנים על ידי Keymaster שנוצרו על ידי המערכת הקודמת, אלא אם יתבצע שחזור של Root of Trust הקודם ותופעל מערכת שחתמתה על ידי המפתח הזה. המטרה היא להגביר את הערך של אמצעי בקרת הגישה למפתחות שמופעלים על ידי תוכנה, על ידי כך שלא תהיה אפשרות למערכת הפעלה שהותקנה על ידי תוקף להשתמש במפתחות של Keymaster.

מפתחות עצמאיים

חלק מהחומרה המאובטחת של Keymaster יכולה לאחסן חומר מפתח באופן פנימי ולהחזיר כינויים במקום חומר מפתח מוצפן. יכול להיות גם מקרים אחרים שבהם לא ניתן להשתמש במפתחות עד שרכיב אחר של מערכת העולם, לא מאובטח או מאובטח, יהיה זמין. ‏HAL של Keymaster מאפשר למבצע הקריאה החוזרת לבקש שהמפתח יהיה 'עצמאי' באמצעות התג TAG::STANDALONE. המשמעות היא שאין צורך במשאבים אחרים מלבד ה-blob ומערכת Keymaster שפועלת. אפשר לבדוק את התגים שמשויכים למפתח כדי לראות אם המפתח הוא עצמאי. בשלב זה מוגדרים רק שני ערכים:

  • KeyBlobUsageRequirements::STANDALONE
  • KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

התכונה הזו לא חשופה לאפליקציות.

מהירות

כשיוצרים את המאפיין, אפשר לציין את מהירות השימוש המקסימלית באמצעות TAG::MIN_SECONDS_BETWEEN_OPS. הטמעות של TrustZone מסרבות לבצע פעולות קריפטוגרפיות עם המפתח הזה אם בוצעה פעולה לפני פחות מ-TAG::MIN_SECONDS_BETWEEN_OPS שניות.

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

אפשר גם להגביל את המפתחות ל-n שימושים בכל הפעלה באמצעות TAG::MAX_USES_PER_BOOT. לשם כך, צריך גם טבלת מעקב שיכולה להכיל לפחות ארבעה מפתחות, וגם תכונה של 'כישלון בטוח'. חשוב לזכור שאפליקציות לא יכולות ליצור מפתחות מוגבלים לכל אתחול. התכונה הזו לא מוצגת דרך Keystore ומיועדת לפעולות מערכת.

התכונה הזו לא חשופה לאפליקציות.

יצירת מקור נתונים מחדש במחולל מספרים אקראיים

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

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

התכונה הזו לא חשופה לאפליקציות, אבל היא משמשת את המסגרת, שמספקת באופן קבוע אנטרופיה נוספת לחומרה המאובטחת, שנשלפת ממכונה של Java SecureRandom.