מאפיינים

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

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

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

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

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

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

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

מפתחות-על של UnlockedDeviceRequired

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

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

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

יצירה והגנה על מפתחות-על

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

1. שרת המערכת מפיק את סיסמת Keystore של המשתמש מתוך הסיסמה הסינתטית של המשתמש באמצעות KDF SP800‑108.
2. שרת המערכת מעביר את הסיסמה של מאגר המפתחות של המשתמש למאגר המפתחות.
3. מאגר המפתחות יוצר את מפתחות-העל של המשתמש.
4. לכל אחד ממפתחות הסופר של המשתמש:
   1. מאגר המפתחות יוצר מלח אקראי.
   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).

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

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

• הצפנה (ייבוא או יצירה של מפתח UNLOCKED_DEVICE_REQUIRED כשהמכשיר נעול):
  1. מאגר המפתחות יוצר זוג חדש של מפתחות ECDH P-521 זמניים.
  2. מאגר המפתחות יוצר סוד משותף על ידי ביצוע הסכם מפתחות ECDH בין המפתח הפרטי של זוג המפתחות האפימרי הזה לבין החלק הציבורי של מפתח העל האסימטרי UnlockedDeviceRequired.
  3. מאגר המפתחות יוצר מלח אקראי.
  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. הפעולה הזו לא משפיעה על מאפייני האבטחה של המפתח, אבל היא מאפשרת גישה מהירה יותר אליו בהמשך.

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

1. יוצרים מפתח AES‑256‑GCM מחוץ ל-Keystore.
2. הצפנת הנתונים באמצעות מפתח AES‑256‑GCM.
3. מייבאים את מפתח AES‑256‑GCM אל Keystore עם קבוצת ההגנה על המפתחות setUnlockedDeviceRequired(true).
4. מאפסים את העותק המקורי של המפתח.

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

מפתחות Standalone

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

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

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

הגדרה מחדש של מחולל מספרים אקראיים

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

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