מאפיינים

בדף הזה נסביר על התכונות הקריפטוגרפיות של Android Keystore, כפי שהן מסופקות על ידי ההטמעה הבסיסית של KeyMint (או Keymaster).

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

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

• יצירת מפתחות, שמובילה לחומר מפתח פרטי או סודי שנגיש רק לסביבה המאובטחת. לקוחות יכולים ליצור מפתחות בדרכים הבאות:
  • יצירת מפתחות חדשים
  • ייבוא של חומר מפתחות לא מוצפן
  • ייבוא של חומר מפתחות מוצפן
• אימות מפתח: יצירת מפתח אסימטרי יוצרת אישור שמכיל את החלק של המפתח הציבורי בזוג המפתחות. בנוסף, האישור הזה יכול להכיל מידע על המטא-נתונים של המפתח ועל מצב המכשיר, וכל הנתונים האלה חתומים על ידי מפתח שמשורשר חזרה אל root מהימן.
• פעולות קריפטוגרפיות:
  • הצפנה ופענוח סימטריים (AES, ‏ 3DES)
  • פענוח אסימטרי (RSA)
  • חתימה אסימטרית (ECDSA, ‏ RSA)
  • חתימה ואימות סימטריים (HMAC)
  • הסכם מפתח אסימטרי (ECDH)

חשוב לזכור ש-Keystore ו-KeyMint לא מטפלים בפעולות של מפתחות ציבוריים עבור מפתחות אסימטריים.

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

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

פרימיטיבים נדרשים

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

• 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
  • מצבי ריפוד להצפנה/פענוח של 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) בהטמעות של KeyMint. אם הטמעת KeyMint בחומרה לא מספקת אותם, Keystore מספק אותם בתוכנה.

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

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

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

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

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

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

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

סוגים אפשריים:

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

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

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

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

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

השדה הזה חשוף ב-KeyMint API עם השדה securityLevel מסוג KeyCharacteristics. החומרה המאובטחת אחראית להצבת ההרשאות ב-KeyCharacteristics עם רמת האבטחה המתאימה, על סמך מה שהיא יכולה לאכוף. המידע הזה מופיע גם ברשומות האימות של מפתחות אסימטריים: מאפייני המפתח של SecurityLevel::TRUSTED_ENVIRONMENT או SecurityLevel::STRONGBOX מופיעים ברשימה hardwareEnforced, ומאפייני המפתח של SecurityLevel::SOFTWARE או SecurityLevel::KEYSTORE מופיעים ברשימה softwareEnforced.

לדוגמה, בדרך כלל לא נאכפות מגבלות על טווח התאריכים והשעות שבהן אפשר להשתמש במפתח בסביבה המאובטחת, כי אין לה גישה מהימנה למידע על תאריכים ושעות. כתוצאה מכך, הרשאות כמו Tag::ORIGINATION_EXPIRE_DATETIME נאכפות על ידי Keystore ב-Android, והן יקבלו את הערך SecurityLevel::KEYSTORE.

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

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

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

• Tag::ALGORITHM
• Tag::KEY_SIZE
• Tag::BLOCK_MODE
• Tag::PADDING
• Tag::CALLER_NONCE
• Tag::DIGEST
• Tag::MGF_DIGEST

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

• Tag::BLOCK_MODE
• Tag::PADDING
• Tag::DIGEST
• Tag::MGF_DIGEST

הערך שבו יש להשתמש מצוין בזמן הפעולה.

מטרה

למפתחות יש קבוצה משויכת של מטרות, שמבוטאות כרשומה אחת או יותר של הרשאות עם התג Tag::PURPOSE, שמגדיר איך אפשר להשתמש בהם. המטרות מוגדרות ב-KeyPurpose.aidl.

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

ייבוא מפתחות

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

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

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

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

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

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

• ‫Tag::USER_SECURE_ID הוא ערך מספרי של 64 ביט שמציין את מזהה המשתמש המאובטח שמופיע באסימון אימות מאובטח כדי לבטל את הנעילה של השימוש במפתח. אם חוזרים על הפעולה, אפשר להשתמש במפתח אם אחד מהערכים מופיע באסימון אימות מאובטח.

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

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

דרישה לביטול נעילת המכשיר

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

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

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

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

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

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

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

יצירה והגנה של מפתחות סופר

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

1. שרת המערכת מפיק את הסיסמה של Keystore של המשתמש מתוך הסיסמה הסינתטית של המשתמש באמצעות KDF SP800‑108.
2. שרת המערכת מעביר את הסיסמה של מאגר המפתחות של המשתמש למאגר המפתחות.
3. מאגר המפתחות יוצר את מפתחות הסופר של המשתמש.
4. לכל אחד מהמפתחות הראשיים של המשתמש:
   1. ‫Keystore יוצר מלח אקראי.
   2. ‫Keystore מפיק מפתח AES‑256‑GCM מסיסמת Keystore של המשתמש ומערך הנתונים באמצעות HKDF‑SHA256.
   3. ‫Keystore מצפין את החלק הסודי של מפתח הסופר באמצעות מפתח AES‑256‑GCM הזה.
   4. ב-Keystore, המפתח הראשי המוצפן והמלח שלו מאוחסנים במסד הנתונים. אם זה מפתח אסימטרי, גם החלק הציבורי של המפתח מאוחסן ללא הצפנה.

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

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

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

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

אחסון מפתחות כשהמכשיר נעול

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

• הצפנה (יצירת מפתח UNLOCKED_DEVICE_REQUIRED בזמן שהמכשיר נעול):
  1. מאגר המפתחות יוצר זוג חדש של מפתחות זמניים מסוג ECDH P‑521.
  2. מאגר המפתחות יוצר סוד משותף על ידי ביצוע הסכם מפתחות ECDH בין המפתח הפרטי של זוג המפתחות האפימרי הזה לבין החלק הציבורי של מפתח העל האסימטרי UnlockedDeviceRequired.
  3. ‫Keystore יוצר מלח אקראי.
  4. ‫Keystore מפיק מפתח AES‑256‑GCM מהסוד המשותף ומערך ה-salt באמצעות HKDF‑SHA256.
  5. ‫Keystore מצפין את המפתח של UNLOCKED_DEVICE_REQUIRED באמצעות מפתח AES‑256‑GCM הזה.
  6. מאגר המפתחות מאחסן במסד הנתונים שלו את מפתח UNLOCKED_DEVICE_REQUIRED המוצפן, את ה-salt ואת החלק הציבורי של זוג המפתחות הזמניים.
• פענוח (באמצעות מפתח UNLOCKED_DEVICE_REQUIRED שנוצר בזמן שהמכשיר לא נעול):
  1. מאגר המפתחות טוען את המפתח המוצפן UNLOCKED_DEVICE_REQUIRED, את ה-salt ואת החלק הציבורי של זוג המפתחות האפמריים מהמסד נתונים שלו.
  2. מאגר המפתחות יוצר סוד משותף על ידי ביצוע הסכם מפתחות ECDH בין החלק הציבורי של זוג המפתחות האפמריים לבין החלק הפרטי של מפתח העל האסימטרי UnlockedDeviceRequired. המפתח הפרטי זמין כי המכשיר לא נעול.
  3. ‫Keystore מפיק מפתח AES‑256‑GCM מהסוד המשותף ומערך ה-salt באמצעות HKDF‑SHA256. המפתח הזה מסוג AES‑256‑GCM זהה למפתח שהופק במהלך ההצפנה.
  4. ‫Keystore מפענח את המפתח UNLOCKED_DEVICE_REQUIRED באמצעות מפתח AES‑256‑GCM.
  5. ב-Keystore מתבצעת הצפנה מחדש של המפתח UNLOCKED_DEVICE_REQUIRED באמצעות מפתח העל הסימטרי UnlockedDeviceRequired. הפעולה הזו לא משפיעה על מאפייני האבטחה של המפתח, אבל היא מאפשרת גישה מהירה יותר אליו בהמשך.

כבילת לקוח

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

התכונה הזו לא זמינה באפליקציות.

תפוגה

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

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

מפתחות להצגה באופן עצמאי

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

• 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), ומכיוון שגנרטורים של מספרים אקראיים בחומרה לא תמיד מהימנים לחלוטין, KeyMint HAL מספק ממשק שמאפשר ללקוח לספק אנטרופיה נוספת, שמעורבבת עם המספרים האקראיים שנוצרו.

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