מאפיינים

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

‫Keymaster 3 שינה את הקידומת KM_TAG ל-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 נפגעה בזמן שהמכשיר נעול.

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

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

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

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

בנוסף, 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).

כבילת לקוח

הקישור של הלקוח, כלומר השיוך של מפתח לאפליקציית לקוח מסוימת, מתבצע באמצעות מזהה לקוח אופציונלי ונתוני לקוח אופציונליים (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 לא צפוי.