הזמינות של סביבת הפעלה מהימנה במערכת על צ'יפ (SoC) מציע הזדמנות למכשירי Android לספק גיבוי חומרה, לשירותי אבטחה חזקים במיוחד למערכת ההפעלה Android, לשירותי פלטפורמה ואפילו אפליקציות צד שלישי. מפתחים שמחפשים את התוספים הספציפיים ל-Android צריכים להיכנס אל android.security.keystore.
לפני Android 6.0, ל-Android כבר היה קריפטו פשוט שמגובה בחומרה Services API, מסופק על ידי גרסאות 0.2 ו-0.3 של חומרת Keymaster Abstraction Layer (HAL). חתימה ואימות דיגיטליים ב-Keystore וגם יצירה וייבוא של זוגות של מפתחות חתימה אסימטריים. הדבר כבר מיושמת במכשירים רבים, אבל יש הרבה יעדי אבטחה שלא ניתן להשיג בקלות באמצעות ממשק API חתימה. מאגר מפתחות ב-Android 6.0 הרחבנו את Keystore API כדי לספק מגוון רחב יותר של יכולות.
ב-Android 6.0 הוספנו את Keystore פרימיטיבים קריפטוגרפיים סימטריים, AES ו-HMAC, ומערכת בקרת גישה למפתחות שמגובים בחומרה. בעלי הרשאת גישה אמצעי הבקרה מוגדרים במהלך יצירת המפתחות ונאכפים כל משך החיים של עיקרי אפשר להגביל את השימוש במפתחות רק אחרי שהמשתמש עשה זאת ורק למטרות ספציפיות או באמצעות נתונים קריפטוגרפיים . מידע נוסף זמין במאמר תגי הרשאות וגם דפי Functions.
בנוסף להרחבת טווח הפרמיטיבים הקריפטוגרפיים, Keystore Android 6.0 הוסיף את הפריטים הבאים:
- סכמה של בקרת שימוש שמאפשרת להגביל את השימוש במפתחות, כדי לצמצם סיכון לסיכון אבטחה כתוצאה משימוש לרעה במפתחות
- סכמה של בקרת גישה שמאפשרת הגבלה של מפתחות למשתמשים מסוימים, לקוחות וטווח זמן מוגדר
ב-Android 7.0, נוספה תמיכה ב-Keymaster 2 באימות (attestation) של מפתחות ובגרסאות מחייבת. אימות מפתחות (attestation) מספק אישורי מפתחות ציבוריים שמכילים תיאור מפורט של המפתח ואת בקרת הגישה שלו, כדי שהמפתח יימצא בחומרה מאובטחת שניתן לאמת מרחוק.
קישור גרסה מחבר מפתחות למערכת ההפעלה ולגרסה ברמת התיקון. כך אפשר להבטיח תוקף שמגלה נקודות חולשה בגרסה ישנה של המערכת תוכנת TEE לא יכולה להחזיר מכשיר לגרסה הפגיעה ולהשתמש במפתחות נוצר באמצעות הגרסה החדשה יותר. בנוסף, כאשר מפתח עם גרסה נתונה ורמת התיקון משמשת במכשיר ששודרג לגרסה חדשה יותר או רמת התיקון, המפתח משודרג לפני שניתן להשתמש בו, הגרסה של המפתח בוטלה. ככל שהמכשיר משודרג, המקשים "ratchet" קדימה עם המכשיר, אבל כל חזרה של המכשיר לגרסה קודמת גורם לכך שלא ניתן להשתמש במפתחות.
ב-Android 8.0, Keymaster 3 עבר מחומרת מבנה C בסגנון הישן Abstraction Layer (HAL) לממשק C++ HAL שנוצר מהגדרה בגרסה החדשה של Hardware Interface Definition Language (HIDL). כחלק מהשינוי, רבים מסוגי הארגומנטים השתנו, למרות שלסוגים ולשיטות יש ארגומנט אחד שתואמים לסוגים הישנים ולשיטות בניית HAL. לצפייה מידע נוסף על הדף Functions פרטים.
בנוסף לגרסה הקודמת של הממשק, מערכת Android 8.0 מורחבת ל-Keymaster 2 תכונת אימות (attestation) שתתמוך אימות (attestation) של תעודה מזהה. אימות הזהות מספק מנגנון מוגבל ואופציונלי לאימות חזק למזהי חומרה, כמו המספר הסידורי, שם המוצר וטלפון מזהה (IMEI / MEID). כדי ליישם את התוספת הזו, מערכת Android 8.0 שינתה את ה-ASN.1 סכימת אימות (attestation) כדי להוסיף אימות (attestation) של מזהה. הטמעות Keymaster צריכות למצוא דרך מאובטחת לאחזר את פריטי הנתונים הרלוונטיים, וגם להגדיר מנגנון להשבתה של התכונה באופן מאובטח וקבוע.
ב-Android 9 העדכונים כוללים:
- עדכון ל: Keymaster 4
- תמיכה ברכיבים מאובטחים מוטמעים
- תמיכה בייבוא של מפתחות מאובטחים
- תמיכה בהצפנת 3DES
- שינויים בקישור גרסאות כך שהפונקציותboot.img ו-system.img יכללו להגדיר גרסאות בנפרד כדי לאפשר עדכונים עצמאיים
מילון מונחים
זוהי סקירה כללית מהירה של רכיבי Keystore והקשרים שלהם.
AndroidKeystore הוא ה-API של מסגרת Android והרכיב שבו נעשה שימוש
על ידי אפליקציות כדי לגשת לפונקציונליות של Keystore. הוא מוטמע כהרחבה של
ממשק ה-API הסטנדרטי של Java Cryptography Architecture, מורכב מקוד Java
פועלת במרחב התהליכים עצמו. AndroidKeystore
מספקת את האפליקציה
בקשות להתנהגות של Keystore על ידי העברה שלהן לדימון (daemon) של מאגר המפתחות.
ה-keystore daemon הוא דימון (daemon) של מערכת Android שמספק גישה לכל הפונקציונליות של Keystore באמצעות Binder API. הוא אחראי לאחסן 'blobs מפתח', מכילים את החומר הסודי של המפתח, המוצפן כך ש-Keystore יוכל לאחסן אותם, לא להשתמש בהם או לחשוף אותם.
keymasterd הוא שרת HIDL שמספק גישה אל .Keymaster TA (השם הזה לא סטנדרטי והוא נועד למטרות רעיוניות).
Keymaster TA (אפליקציה מהימנה) היא התוכנה שפועלת לרוב ב-TrustZone ב-ARM SoC, שמספק את כל פעולות מאובטחות של מאגר מפתחות, גישה לחומרי מפתחות גולמיים, אימות של כל תנאי בקרת הגישה במפתחות וכו'.
LockSettingsService הוא רכיב מערכת Android שאחראי
לאימות משתמשים, גם סיסמה וגם טביעת אצבע. הוא לא חלק מ-
Keystore, אבל רלוונטי כי הרבה פעולות מפתח ב-Keystore מחייבות משתמש
אימות. LockSettingsService
באינטראקציה עם שומר השער
TA וטביעת אצבע TA כדי לקבל אסימוני אימות, שהם מספקים
דימון (daemon) של מאגר מפתחות, ושבסופו של דבר נעשה בו שימוש
תרגום מכונה.
Gatekeeper TA (אפליקציה מהימנה) הוא רכיב נוסף פועל בהקשר מאובטח, שאחראי על אימות המשתמשים סיסמאות ויצירת אסימוני אימות המשמשים להוכחה TA של Keymaster שאימות של משתמש מסוים בוצע בשלב מסוים בזמן האימון.
טביעת אצבע דיגיטלית (TA) (אפליקציה מהימנה) היא רכיב נוסף פועלות בהקשר מאובטח שאחראי על אימות המשתמש טביעות אצבע או יצירת אסימוני אימות המשמשים להוכחה ל-Keymaster הודעה על כך שבוצע אימות למשתמש מסוים בשלב מסוים בזמן.
ארכיטקטורה
Android Keystore API ו-Keymaster HAL שבבסיסו מספקת קבוצה בסיסית אבל הולמת של פרימיטיביים קריפטוגרפיים כדי לאפשר של פרוטוקולים באמצעות מפתחות עם בקרת גישה שמגובים בחומרה.
Keymaster HAL הוא ספרייה ניתנת לטעינה באופן דינמי שסופק על ידי ה-OEM (יצרן הציוד המקורי). שירות Keystore כדי לספק שירותים קריפטוגרפיים שמגובים בחומרה. כדי לשמור מה שמאובטח, הטמעות HAL לא מבצעות פעולות רגישות במרחב המשתמשים, ואפילו במרחב הליבה. פעולות רגישות ניתנות להקצאה שמגיעים אליו דרך ממשק ליבה כלשהו. הארכיטקטורה שמתקבלת נראית כך:
![גישה ל-Keymaster](https://source.android.com/static/docs/security/images/access-to-keymaster.png?authuser=0&hl=he)
איור 1. גישה ל-Keymaster
במכשיר Android, ה"לקוח" ב-Keymaster HAL, כמה שכבות (למשל אפליקציה, framework, דימון (daemon) של Keystore), אבל אפשר להתעלם מהן למטרות המסמך הזה. המשמעות היא ש-Keymaster HAL המתואר ה-API הוא ברמה נמוכה, משמש לרכיבים פנימיים של הפלטפורמה ולא חשוף לאפליקציה למפתחים. ה-API ברמה גבוהה יותר מתואר באתר למפתחי Android.
מטרתו של Keymaster HAL היא לא להטמיע את הקוד הרגישות לאבטחה ולא רק לבקשות המרשל והמלחמה לעולם המאובטח. הפורמט של חוטים מוגדר על ידי ההטמעה.
תאימות לגרסה הקודמת גרסאות
HAL של Keymaster 1 לא תואם לגמרי מוצרי HAL שהושקו בעבר, למשל Keymaster 0.2 ו-0.3. כדי לסייע יכולת פעולה הדדית במכשירים שבהם פועלת מערכת Android 5.0 וגרסאות קודמות שהושקו באמצעות ב-Keymaster HALs הישנים, יש ב-Keystore מתאם שמטמיע את Keymaster 1 HAL עם קריאות לספריית החומרה הקיימת. התוצאה לא יכולה לספק את טווח הפונקציונליות המלא ב-Keymaster 1 HAL. באופן ספציפי, הוא תומך רק באלגוריתמים RSA ו-ECDSA, והאכיפה מתבצעת על ידי המתאם, בעולם הלא מאובטח.
תהליך ה-Keymaster 2 ממשיך לפשט את ממשק ה-HAL על ידי הסרת הרכיב
get_supported_*
שיטות ומתן הרשאה לfinish()
לקבלת קלט. דבר זה מפחית את מספר הנסיעות הלוך ושוב לאזור TEE ב-
במקרים שבהם הקלט זמין בבת אחת, והוא מפשט את ההטמעה
פענוח AEAD.
ב-Android 8.0, Keymaster 3 עבר ממבנה C בסגנון הישן
HAL לממשק C++ HAL שנוצר מהגדרה
ממשק חומרה של שפת הגדרה (HIDL). HAL בסגנון חדש
נוצר על ידי סיווג משנה של
מחלקה IKeymasterDevice
והטמעה של מודל וירטואלי טהור
שיטות. כחלק מהשינוי, רבים מסוגי הארגומנטים השתנו,
אבל לסוגים ולשיטות יש התאמה אחת-לאחדת עם
והשיטות של מבנה HAL.
סקירה כללית של HIDL
The Hardware Interface Definition Language (HIDL) מספק הטמעה מנגנון בלתי תלוי-שפה לציון ממשקי חומרה. HIDL כרגע תומכים ביצירה של ממשקי C++ ו-Java. צפוי רוב המשתמשים שמטמיעים את סביבת הביצוע המהימנה (TEE) יראו את ה-C++ ולכן המסמך הזה עוסק רק בייצוג C++.
ממשקי HIDL מורכבים מקבוצה של שיטות, מבוטאת באופן הבא:
methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);
יש כמה סוגים מוגדרים מראש, ו-HAL יכול להגדיר ספירה חדשה של סוגי המבנים. פרטים נוספים על HIDL זמינים בקטע העזר.
דוגמה לשיטה מ-Keymaster 3 3 IKeymasterDevice.hal
:
generateKey(vec<KeyParameter> keyParams) generates(ErrorCode error, vec<uint8_t> keyBlob, KeyCharacteristics keyCharacteristics);
היא מקבילה להצהרה הבאה ב-keymaster2 HAL:
keymaster_error_t (*generate_key)( const struct keymaster2_device* dev, const keymaster_key_param_set_t* params, keymaster_key_blob_t* key_blob, keymaster_key_characteristics_t* characteristics);
בגרסת HIDL, הארגומנט dev
מוסר כי הוא
משתמע. הארגומנט params
כבר לא מבנה שמכיל
שמפנה למערך של אובייקטים מסוג key_parameter_t
,
vec
(וקטור) שמכיל KeyParameter
אובייקטים.
הערכים המוחזרים מפורטים בעמודה "generates
" כולל
וקטור של ערכי uint8_t
ל-blob של המפתח.
ה-method הווירטואלי של C++ שנוצרה על ידי המהדר HIDL היא:
Return<void> generateKey(const hidl_vec<KeyParameter>& keyParams, generateKey_cb _hidl_cb) override;
כאשר generateKey_cb
הוא מצביע של פונקציה שמוגדר כך:
std::function<void(ErrorCode error, const hidl_vec<uint8_t>& keyBlob, const KeyCharacteristics& keyCharacteristics)>
כלומר, generateKey_cb
היא פונקציה שמקבלת את הערכים המוחזרים
שמפורטות בסעיף היצירה. סיווג ההטמעה עם HAL מבטל את ההגדרה הזו
השיטה generateKey
וקריאה לפונקציה generateKey_cb
המצביע כדי להחזיר את תוצאת הפעולה למתקשר. שימו לב לפונקציה
הקריאה של הסמן היא סינכרונית. המתקשר/ת
generateKey
ו-generateKey
מפעילים את הפונקציה
מצביע על הפונקציה, שמבצע עד השלמה, ומחזיר את הבקרה
generateKey
, שחוזרים לביצוע הקריאה החוזרת.
לקבלת דוגמה מפורטת, ראו את הטמעת ברירת המחדל ב
hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp
הטמעת ברירת המחדל מספקת תאימות לאחור למכשירים עם
Keymaster0, keymaster1 או keymaster2 HALS בסגנון ישן.
בקרת גישה
הכלל הבסיסי ביותר בבקרת הגישה ל-Keystore הוא שלכל אפליקציה יש מרחב שמות משלו. אבל לכל כלל יש יוצא מן הכלל. ב-Keystore יש כמה מפות בקידוד קשיח שמאפשרות לרכיבי מערכת מסוימים לגשת לסוגים מסוימים של מרחבי שמות. זה כלי קהה מאוד כי הוא נותן רכיב אחד שליטה מלאה במרחב שמות אחר. ויש את העניין של הספק כלקוחות ל-Keystore. בשלב זה אין לנו דרך להקים מרחב השמות של רכיבי הספק, לדוגמה, ספק WPA.
כדי לתת מענה לרכיבי הספק ולהגדיר את בקרת הגישה באופן כללי ללא חריגים בתוך הקוד, Keystore 2.0 כולל דומיינים ו-SELinux מרחבי שמות.
דומיינים של מאגר מפתחות
בדומיינים של Keystore אנחנו יכולים להפריד בין מרחבי שמות ממזהי UID. לקוחות גישה למפתח ב-Keystore צריכה לציין את הדומיין, מרחב השמות והכינוי שהם רוצים לגשת אליהם. על סמך הסמל הזה והזהות של המתקשר, יכול לקבוע לאיזה מפתח המתקשר רוצה לגשת ואם יש לו הרשאות.
השקנו חמישה פרמטרים של דומיינים שקובעים איך אפשר לגשת למפתחות. הם שולטים בסמנטיקה של פרמטר מרחב השמות של מתאר המפתח באופן שבו מתבצעת בקרת גישה.
DOMAIN_APP
: דומיין האפליקציה מכסה את התנהגות מדור קודם. ה-SPI של Java Keystore משתמש בדומיין הזה כברירת מחדל. כשהפעולה הזו דומיין בשימוש, המערכת מתעלמת מהארגומנט של מרחב השמות וה-UID של המתקשר נעשה בו שימוש. הגישה לדומיין הזה נשלטת על ידי התווית Keystore ברמהkeystore_key
במדיניות SELinux.DOMAIN_SELINUX
: הדומיין הזה מציין למרחב השמות יש תווית במדיניות SELinux. חיפוש הפרמטר של מרחב השמות ומתורגם להקשר יעד, ומתבצעת בדיקת הרשאות ההקשר של הקריאה ל-SELinux בשביל המחלקהkeystore_key
. כאשר קיימת הרשאה לפעולה הנתונה, נעשה שימוש במכסה המלאה לחיפוש המפתח.DOMAIN_GRANT
: דומיין ההרשאה מציין הפרמטר של מרחב השמות הוא מזהה המענק. המערכת מתעלמת מהפרמטר של הכינוי. בדיקות SELinux מתבצעות בזמן יצירת המענק. בקרת גישה נוספת הפונקציה בודקת רק אם ה-UID של המתקשר תואם את ה-UID של מקבלי המענק של המענק המבוקש.DOMAIN_KEY_ID
: הדומיין הזה מציין פרמטר מרחב השמות הוא מזהה מפתח ייחודי. יכול להיות שהמפתח עצמו נוצר עםDOMAIN_APP
אוDOMAIN_SELINUX
. ההרשאה הבדיקה מתבצעת אחריdomain
וnamespace
נטענו ממסד הנתונים של המפתחות בדיוק כמו שה-blob נטען לדומיין, למרחב השמות ולכינוי tuple. הנימוקים לדומיין של מזהה המפתח הוא המשכיות. כשניגשים למפתח באמצעות כינוי, יכול להיות שהשיחות הבאות יופעלו מפתחות שונים, מכיוון שיכול להיות שנוצר או יובא מפתח חדש לכינוי הזה. עם זאת, מזהה המפתח לא משתנה אף פעם. אז כשאתם משתמשים במפתח לפי מזהה מפתח אחרי שהוא נטען ממסד הנתונים של Keystore באמצעות הכינוי פעם אחת, יכול להיות בטוח שמדובר באותו מפתח, כל עוד מזהה המפתח עדיין קיים. הזה הפונקציונליות לא חשופה למפתחי אפליקציות. במקום זאת, הוא משמש ה-SPI של Android Keystore כדי לספק חוויה עקבית יותר גם בזמן השימוש בו-זמנית באופן לא בטוח.DOMAIN_BLOB
: הדומיין blob מציין ש מבצע הקריאה החוזרת מנהל את ה-blob בעצמו. השירות הזה משמש לקוחות שצריכים לגשת ל-Keystore לפני הטעינה של מחיצת הנתונים. ה-blob של המפתח הוא כלולה בשדהblob
של מתאר המפתח.
באמצעות הדומיין SELinux, אנחנו יכולים להעניק לרכיבי הספק גישה מרחבי שמות ספציפיים ב-Keystore שרכיבי מערכת כמו תיבת הדו-שיח של ההגדרות.
מדיניות SELinux ל-keystore_key
אפשר להגדיר תוויות של מרחב שמות באמצעות keystore2_key_context
חדש.
כל שורה בקבצים האלה ממפה מזהה מרחב שמות מספרי לתווית SELinux.
לדוגמה,
# wifi_key is a keystore2_key namespace intended to be used by wpa supplicant and # Settings to share keystore keys. 102 u:object_r:wifi_key:s0
אחרי שמגדירים מרחב שמות חדש של מפתחות בצורה הזו, אנחנו יכולים לתת לו גישה
על ידי הוספת מדיניות מתאימה. לדוגמה, כדי לאפשר
wpa_supplicant
כדי לקבל מפתחות במרחב השמות החדש ולהשתמש בהם
צריך להוסיף את השורה הבאה אל hal_wifi_supplicant.te
:
allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };
אחרי שמגדירים את מרחב השמות החדש, אפשר להשתמש ב-AndroidKeyStore כמעט כמו
הרגילה. ההבדל היחיד הוא שצריך לציין את מזהה מרחב השמות. עבור
בטעינה וייבוא של מפתחות מ-Keystore ומתוכו, יש לציין את המזהה של מרחב השמות
באמצעות AndroidKeyStoreLoadStoreParameter
. לדוגמה,
import android.security.keystore2.AndroidKeyStoreLoadStoreParameter; import java.security.KeyStore; KeyStore keystore = KeyStore.getInstance("AndroidKeyStore"); keystore.load(new AndroidKeyStoreLoadStoreParameter(102));
כדי ליצור מפתח במרחב שמות נתון, יש להזין את המזהה של מרחב השמות
באמצעות KeyGenParameterSpec.Builder#setNamespace():
import android.security.keystore.KeyGenParameterSpec; KeyGenParameterSpec.Builder specBuilder = new KeyGenParameterSpec.Builder(); specBuilder.setNamespace(102);
קובצי ההקשר הבאים עשויים לשמש להגדרת Keystore 2.0 SELinux מרחבי שמות. לכל מחיצה יש טווח שמור שונה של 10,000 מרחב שמות מזהים כדי למנוע התנגשויות.
מחיצה | טווח | קובצי תצורה |
---|---|---|
מערכת | 0 ... 9,999 | /system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts |
מערכת מורחבת | 10,000 ... 19,999 | /system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts |
מוצר | 20,000 ... 29,999 | /product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts |
ספק | 30,000 ... 39,999 | /vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts |
הלקוח מבקש את המפתח על ידי בקשת הדומיין SELinux ואת
מרחב שמות וירטואלי, במקרה הזה "wifi_key"
, באמצעות המזהה המספרי שלו.
מעליו הוגדרו מרחבי השמות הבאים. אם הם מחליפים את כללים מיוחדים, הטבלה הבאה מציינת את ה-UID שבו הם השתמשו ל.
מזהה מרחב שמות | תווית SEPolicy | UID | תיאור |
---|---|---|---|
0 | su_key | לא רלוונטי | מקש משתמש-על. משמש רק לבדיקה ב-Userdebug ובגרסאות build של מעורבות. לא שרלוונטיות לגרסאות build של משתמשים. |
1 | מפתח_מעטפת | לא רלוונטי | מרחב שמות שזמין למעטפת. לרוב משמשת לבדיקה, אבל אפשר להשתמש בו משתמש נוסף משורת הפקודה. |
100 | vold_key | לא רלוונטי | מיועד לשימוש ב-vold. |
101 | odsing_key | לא רלוונטי | בשימוש על ידי הדימון (daemon) החותם במכשיר. |
102 | wifi_key | AID_WIFI(1010) | בשימוש על ידי מערכת ההפעלה של ה-Wi-Fi ב-Android, כולל wpa_supplicant. |
120 | Resume_on_reboot_key | AID_SYSTEM(1000) | משמש את שרת המערכת של Android לתמיכה בהמשך לאחר הפעלה מחדש. |
גישה לווקטורים
כיתת SELinux keystore_key
התקינה במידה מועטה וחלקה
הרשאות מסוימות, כמו verify
או sign
, איבדו
מה המשמעות שלהם. הנה קבוצת ההרשאות החדשה, keystore2_key
,
ש-Keystore 2.0 יאכוף.
הרשאה | משמעות |
---|---|
delete
|
מסומנת כשמסירים מפתחות מ-Keystore. |
get_info
|
התיבה נבדקת כשנשלחת בקשה למטא-נתונים של מפתח. |
grant
|
מבצע הקריאה החוזרת יצטרך את ההרשאה הזו כדי ליצור הרשאת גישה למפתח שביעד הקשר מסוים. |
manage_blob
|
מבצע הקריאה החוזרת עשוי להשתמש ב-DOMAIN_BLOB במרחב השמות הנתון של SELinux,
וכך לנהל blobs בפני עצמם. זה שימושי במיוחד עבור
vold. |
rebind
|
ההרשאה הזו קובעת אם כתובת אימייל חלופית מוחזרת למפתח חדש. הדבר שנדרש להכנסה, ומשתמע ממנו שהמפתח שכבר מקושר נמחק. זו בעצם הרשאת הוספה, אבל היא מייצגת את הסמנטיקה ממאגר המפתחות. |
req_forced_op
|
לקוחות שיש להם את ההרשאה הזו רשאים ליצור פעולות שלא ניתן לבטל, וכן יצירת הפעולה לעולם לא תיכשל, אלא אם כל משבצות הפעולה ננקטות על ידי פעולות שלא ניתנות להסרה. |
update
|
נדרש כדי לעדכן את רכיב המשנה של מפתח. |
use
|
נבדקת במהלך יצירה של פעולת Keymint שנעשה בה שימוש בחומר המפתח, למשל, לחתימה, הצפנה/פענוח. |
use_dev_id
|
חובה כשיוצרים פרטים מזהים של המכשיר, כמו מזהה מכשיר אימות (attestation) |
בנוסף, אנחנו מפצלים קבוצה של הרשאות שאינן ספציפיות למאגר המפתחות
סוג האבטחה של SELinux : keystore2
הרשאה | משמעות |
---|---|
add_auth
|
נדרש על ידי ספק אימות, כמו שומר סף או BimetricsManager כדי להוסיף אסימוני אימות. |
clear_ns
|
ההרשאה הזו, שנקראה בעבר clear_uid, מאפשרת למי שאינו בעלים של מרחב שמות: למחוק את כל המפתחות במרחב השמות הזה. |
list
|
נדרש על ידי המערכת לספירת מפתחות לפי מאפיינים שונים, כמו
בעלות או גבולות אימות. ההרשאה הזו לא נדרשת על ידי המתקשרים
לספור את מרחבי השמות שלהם. כולל
ההרשאה get_info . |
lock
|
ההרשאה הזו מאפשרת לנעול את Keystore, כלומר להוציא את מפתח המאסטר, שמפתחות שמקשרים אליהם את האימות הופכים לבלתי שמישים ואי אפשר לשנות אותם. |
reset
|
ההרשאה הזו מאפשרת לאפס את Keystore לברירת המחדל של היצרן, ולמחוק את כל מפתחות שאינם חיוניים לתפקוד של מערכת ההפעלה Android. |
unlock
|
ההרשאה הזו נדרשת כדי לנסות לבטל את הנעילה של מפתח המאסטר לצורך אימות מקשים קשורים. |