Keystore מגובה חומרה

הזמינות של סביבת ביצוע מהימנה במערכת על שבב (SoC) מציעה הזדמנות למכשירי אנדרואיד לספק שירותי אבטחה מגובים חומרה וחזקה למערכת ההפעלה של אנדרואיד, לשירותי פלטפורמה ואפילו לאפליקציות של צד שלישי. מפתחי מבקשי הרחבות הספציפיות אנדרואיד צריכים ללכת android.security.keystore .

לפני אנדרואיד 6.0, לאנדרואיד כבר היה ממשק API של שירותי קריפטו פשוט מגובה חומרה, המסופק על ידי גרסאות 0.2 ו- 0.3 של שכבת ההפשטה של ​​Keymaster Hardware (HAL). Keystore סיפקה פעולות חתימה ואימות דיגיטליות, בתוספת ייצור וייבוא ​​של זוגות מפתח חתימה אסימטריים. זה כבר מיושם במכשירים רבים, אך ישנם יעדי אבטחה רבים שלא ניתן להשיג בקלות באמצעות ממשק API חתימה בלבד. Keystore ב- Android 6.0 מרחיב את ה- API של Keystore כדי לספק מגוון רחב יותר של יכולות.

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

בנוסף להרחבת מגוון פרימיטיבי הצפנה, Keystore ב- Android 6.0 מוסיף את הדברים הבאים:

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

ב- Android 7.0, Keymaster 2 הוסיף תמיכה באישור מפתח ובאיגוד גרסאות. עדות מפתח מספקת תעודות מפתח ציבוריות המכילות תיאור מפורט של המפתח ובקרות הגישה שלה, על מנת להפוך את קיומו של מפתח חומרה מאובטחת התצורה שלו מרחוק לאימות.

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

ב- Android 8.0 Keymaster 3 עבר משכבת ​​ההפשטה של ​​חומרה (HAL) בסגנון הישן לממשק C ++ HAL שנוצר מהגדרה בשפת ההגדרה החדשה של ממשק החומרה (HIDL). כחלק מהשינוי, רבים מסוגי הטיעונים השתנו, אם כי לסוגים ולשיטות יש התכתבויות אחד לאחד עם הסוגים הישנים ושיטות המבנה של HAL. עיין פונקציות הדף לקבלת פרטים נוספים.

בנוסף גרסת ממשק זה, אנדרואיד 8.0 מרחיב תכונת העדות של Keymaster 2 לתמיכת עדות מזהה . תעודת זהות מספקת מנגנון מוגבל ואופציונלי להעדה חזקה של מזהי חומרה, כגון מספר סידורי של המכשיר, שם המוצר ומזהה הטלפון (IMEI / MEID). כדי ליישם תוספת זו, שנה את סכימת האישור ASN.1 כדי להוסיף תעודת מזהה. יישומי Keymaster צריכים למצוא דרך בטוחה לאחזר את פריטי הנתונים הרלוונטיים, כמו גם להגדיר מנגנון להשבתה מאובטחת וקבועה של התכונה.

ב- Android 9, העדכונים כוללים:

  • עדכון Keymaster 4
  • תמיכה באלמנטים מאובטחים משובצים
  • תמיכה בייבוא ​​מפתח מאובטח
  • תמיכה בהצפנת 3DES
  • שינויים בכריכת הגרסאות כך של- boot.img ו- system.img הוגדרו גרסאות בנפרד כדי לאפשר עדכונים עצמאיים

מילון מונחים

לפניכם סקירה מהירה על רכיבי קייסטור ועל מערכות היחסים ביניהם.

AndroidKeystore הוא ה- API מסגרת אנדרואיד רכיב בשימוש על ידי אפליקציות לפונקציונליות גישה Keystore. הוא מיושם כהרחבה לממשקי ה- API הצפוניים של Java Cryptography Architecture, ומורכב מקוד Java הפועל במרחב התהליכים של האפליקציה עצמו. AndroidKeystore ממלא בקשות שיישום להתנהגות Keystore ידי העברתן daemon מאגר המפתחות.

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

keymasterd הוא שרת HIDL המספק גישה Keymaster ת"א. (שם זה אינו סטנדרטי והוא נועד למטרות רעיוניות.)

Keymaster ת"א (יישום מהימן) היא התוכנה הפועלת בהקשר מאובטח, לרוב TrustZone על SoC של ARM, המספק את כול פעולות Keystore המאובטחות, יש גישה לחומר מפתח הגלם, מאמתת את כול תנאי בקרת גישה על מקשים , וכו.

LockSettingsService הוא מרכיב מערכת אנדרואיד אחראי אימות משתמש, הוא סיסמא טביעת אצבע. זה לא חלק מקיסטור, אלא רלוונטי מכיוון שפעולות מפתח רבות של קייסטור דורשות אימות משתמש. LockSettingsService אינטראקציה עם TA Gatekeeper ו- טביעות האצבע ת"א להשיג אסימוני אימות, אשר הוא מספק לדמון מאגר המפתחות, ואשר בסופו של דבר שנצרכים על ידי יישום Keymaster ת"א.

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

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

ארכיטקטורה

ממשק ה- API של אנדרואיד קייסטור ו- Keymaster HAL הבסיסי מספקים סט בסיסי אך הולם של פרימיטיבים קריפטוגרפיים המאפשרים יישום פרוטוקולים באמצעות מפתחות נשלטים על גישת חומרה.

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

גישה ל- Keymaster

איור 1. גישה Keymaster

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

מטרת ה- Keymaster HAL אינה ליישם את האלגוריתמים הרגישים לאבטחה אלא רק בקשות מרשל ולא מרשל לעולם המאובטח. פורמט החוט מוגדר ליישום.

תאימות לגרסאות קודמות

ה- Keymaster 1 HAL אינו תואם לחלוטין ל- HALs שפורסמו בעבר, למשל Keymaster 0.2 ו- 0.3. כדי להקל על יכולת פעולה הדדית במכשירים שמריצים אנדרואיד 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 עבר ממבנה ה- HAL הישן בסגנון ה- C לממשק ה- C ++ HAL שנוצר מהגדרה בשפה החדשה (HIDL) להגדרת ממשק חומרה. יישום HAL חדש בסגנון נוצר על ידי subclassing שנוצר IKeymasterDevice בכיתה ויישום שיטות וירטואלית טהורה. כחלק מהשינוי, רבים מסוגי הטיעונים השתנו, אם כי לסוגים ולשיטות יש התכתבויות אחד לאחד עם הסוגים הישנים ושיטות המבנה של HAL.

סקירת HIDL

שפת הגדרת ממשק החומרה (HIDL) מספקת מנגנון בלתי תלוי בשפה לציון ממשקי חומרה. כלי ה- HIDL תומך כיום בייצור ממשקי C ++ ו- Java. זה צפוי שרוב מיישמי סביבת הביצוע המהימן (TEE) ימצאו את הכלים C ++ נוחים יותר, ולכן מסמך זה דן רק בייצוג C ++.

ממשקי HIDL מורכבים ממכלול שיטות, המתבטאות כ:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

ישנם סוגים שונים שהוגדרו מראש, ו- HAL יכולים להגדיר סוגים חדשים ומנויים חדשים ומבנים. לפרטים נוספים על HIDL, לראות את קטע Reference .

שיטת דוגמה מן Keymaster 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 הטיעון הוא כבר לא struct המכיל מצביע התייחסות מערך של key_parameter_t חפצים, אלא vec (וקטור) המכיל KeyParameter חפצים. ערכי ההחזרה מפורטים " generates סעיף", כוללים וקטור של uint8_t ערכים עבור בועת המפתח.

השיטה הווירטואלית C ++ שנוצרה על ידי מהדר HIDL היא:

Return<void> generateKey(const hidl_vec<KeyParameter>& keyParams,
                         generateKey_cb _hidl_cb) override;

איפה generate_cb הוא מצביע פונקציה מוגדרת כ:

std::function<void(ErrorCode error, const hidl_vec<uint8_t>& keyBlob,
                   const KeyCharacteristics& keyCharacteristics)>

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

לקבלת דוגמה מפורטת, לראות את יישום ברירת המחדל hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp . יישום ברירת המחדל מספק תאימות לאחור למכשירים עם keymaster0, keymaster1 או keymaster2 HALS בסגנון ישן.

בקרת גישה

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

על מנת להכיל רכיבי ספקים ולהכליל בקרת גישה ללא חריגים מקודדים קשים, Keystore 2.0 מציגה תחומים ומרחבי שמות של selinux.

Keystore Domains

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

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

  • DOMAIN_APP : תחום האפליקציה מכסה את ההתנהגות הקודמת. SPI של Java Keystore משתמש בתחום זה כברירת מחדל. כאשר משתמשים בדומיין זה, מתעלמים מהארגומנט מרחב השמות ובמקום משתמשים ב- uid של המתקשר. הגישה לתחום זה נשלט על ידי התווית מאגר מפתחות לכיתה keystore_key במדיניות SELinux.
  • DOMAIN_SELINUX : תחום זה מצביע כי המרחב בעל תווית מדיניות SELinux. הפרמטר המרחב הוא הרים את מבטו מתורגם בהקשר יעד, ואת מחאת רשות מבוצעת עבור בהקשר SELinux הקוראות keystore_key בכיתה. כאשר נקבעה ההרשאה לפעולה הנתונה, הכפולה המלאה משמשת לחיפוש המפתח.
  • DOMAIN_GRANT : תחום המענק עולה כי הפרמטר המרחב הוא מזהה מענק. מתעלם מפרמטר הכינוי. בדיקות סלינוקס מבוצעות בעת יצירת המענק. בקרת גישה נוספת בודקת רק אם ה- UID המתקשר תואם את ה- UD של המענקים של המענק המבוקש.
  • DOMAIN_KEY_ID : תחום זה מצביע כי הפרמטר המרחב הוא מזהה מפתח ייחודי. המפתח עצמו עשוי נוצר עם DOMAIN_APP או DOMAIN_SELINUX . בדיקת הרשות מתבצעת לאחר domain ואת namespace הוטענו ממסד נתון מפתח באותו אופן כאילו הבועה נטענה על ידי התחום, מרחב, ו tuple הכינוי. הרציונל עבור תחום מזהה המפתח הוא המשכיות. כאשר ניגשים למפתח על ידי כינוי שיחות עוקבות עשויות לפעול על מקשים שונים, מכיוון שייתכן שנוצר או יובא מפתח חדש והיה קשור לכינוי זה. מזהה המפתח עם זאת, לעולם אינו משתנה. לכן כאשר משתמשים במפתח לפי מזהה מפתח לאחר שהוא נטען ממסד הנתונים של חנות המפתחות באמצעות הכינוי פעם אחת, ניתן להיות בטוחים שזהו אותו מפתח כל עוד מזהה המפתח עדיין קיים. פונקציונליות זו אינה חשופה למפתחי אפליקציות, אלא משמשת ב- Android Keystore SPI כדי לספק חוויה עקבית יותר גם כאשר משתמשים בה במקביל בצורה לא בטוחה.
  • DOMAIN_BLOB : תחום הבועה מציין כי מתקשר מנהלת הבועה בפני עצמה. זה משמש ללקוחות שצריכים לגשת לקיסטור לפני הרכבת מחיצת הנתונים. בועת המפתח כלול blob בתחום מתאר המפתח.

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

מדיניות 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_keys:keystore2_key { get, use };

לאחר הגדרת מרחב השמות החדש ניתן להשתמש ב- AndroidKeyStore כמעט כרגיל. ההבדל היחיד הוא שיש לציין את מזהה מרחב השמות. לטעינה וייבוא המפתחות ולתוך Keystore, מזהה namespace צוין באמצעות 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);

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

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

מזהה מרחב שמות תווית SEPolicy UID תיאור
0 su_key לא מפתח משתמש סופר. משמש רק לבדיקה על userdebug ו- eng build. לא רלוונטי לבניית משתמשים.
1 מפתח מעטפת לא מרחב שמות זמין להפגזה. משמש בעיקר לבדיקה, אך ניתן להשתמש בו גם בבניית משתמשים משורת הפקודה.
100 vold_key לא מיועד לשימוש על ידי vold.
101 odsing_key לא משמש על ידי דמון החתימה במכשיר.
102 wfi_key AID_WIFI (1010) משמש על ידי מערכת ה- Wifi של Android כולל wpa_supplicant.
120 קורות חיים_על_מפתח_מפתח AID_SYSTEM (1000) משמש את שרת המערכת של אנדרואיד לתמיכה בקורות חיים בהפעלה מחדש.

וקטורי גישה

מעמד SELinux keystore_key הזדקן לא מעט וחלק ההרשאות, כגון verify או sign אבד את משמעותם. הנה הסט החדש של הרשאות, keystore2_key , כי Keystore 2.0 יאכוף.

רְשׁוּת מַשְׁמָעוּת
delete מסומן בעת ​​הסרת מפתחות מקיסטור.
get_info נבדק כאשר מבקשים מטא נתונים של מפתח.
grant המתקשר זקוק להרשאה זו כדי ליצור מענק למפתח בהקשר היעד.
manage_blob המתקשר רשאי להשתמש DOMAIN_BLOB על מרחב SELinux נתון, ובכך לניהול כתמים על ידי עצמו. זה שימושי במיוחד עבור vold.
rebind הרשאה זו שולטת אם כינוי עלול להחזיר למפתח חדש. זה נדרש להכנסה ומשמעות הדבר שמפתח הכריכה הקודם יימחק. זה בעצם אישור הכנסה, אבל זה לוכד טוב יותר את הסמנטיקה של keystore.
req_forced_op לקוחות בעלי הרשאה זו עלולים ליצור פעולות שלא ניתנות לגימור, ויצירת הפעולה לעולם לא תיכשל אלא אם כל משבצות הפעולה נלקחות על ידי פעולות שאינן ניתנות להפעלה.
update נדרש לעדכן את רכיב המשנה של מפתח.
use נבדק בעת יצירת פעולת Keymint המשתמשת בחומר המפתח, למשל לחתימה, en / decryption.
use_dev_id נדרש בעת יצירת מידע מזהה מכשיר, כגון תעודת מזהה מכשיר.

בנוסף, אנו לפצל את ערכה של הרשאות מאגר מפתחות ספציפיים מפתח הלא בכיתת אבטחת SELinux keystore2 :

רְשׁוּת מַשְׁמָעוּת
add_auth נדרש על ידי ספק אימות כגון Gatekeeper או BiometricsManager להוספת אסימונים לאימות.
clear_ns בעבר clear_uid, הרשאה זו מאפשרת לבעלים שאינו של מרחב שמות למחוק את כל המפתחות באותו מרחב שמות.
list נדרש על ידי המערכת למניית מפתחות לפי מאפיינים שונים, כגון בעלות או מגבלות אימות. הרשאה זו אינה נדרשת על ידי המתקשרים המונים את מרחבי השמות שלהם. זה מכוסה על ידי get_info הרשות.
lock הרשאה זו מאפשרת לנעול את Keystore, כלומר לפנות את מפתח הראשי, כך שמפתחות מאוגדים יהפכו לבלתי שמישים ובלתי ניתנים ליצירה.
reset הרשאה זו מאפשרת לאפס את Keystore לברירת המחדל של היצרן, ולמחוק את כל המקשים שאינם חיוניים לתפקוד מערכת ההפעלה אנדרואיד
unlock הרשאה זו נדרשת כדי לנסות לפתוח את מפתח הראשי עבור מפתחות מאוגדים.