Keystore מגובה חומרה

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

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

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

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

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

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

מילון מונחים

להלן סקירה מהירה של רכיבי Keystore ומערכות היחסים ביניהם.

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

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

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

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

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

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

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

ארכיטקטורה

ה- API של אנדרואיד Keystore ו- 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 בכיתה ויישום שיטות וירטואלית טהורה. כחלק מהשינוי, רבים מסוגי הטיעונים השתנו, אם כי לסוגים ולשיטות יש התאמה של אחד לאחד עם הסוגים הישנים ושיטות ה- struct HAL.

סקירת HIDL

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

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

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

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

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

דגמי Keystore

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

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

  • DOMAIN_APP : תחום האפליקציה מכסה את ההתנהגות הקודמת. ה- Java Keystore SPI משתמש בדומיין זה כברירת מחדל. כאשר משתמשים בדומיין זה, הארגומנט של מרחב השמות מתעלם ומשתמשים במקום זאת ב- UID של המתקשר. הגישה לתחום זה נשלט על ידי התווית Keystore לכיתה keystore_key במדיניות SELinux.
  • DOMAIN_SELINUX : תחום זה מצביע כי המרחב בעל תווית מדיניות SELinux. הפרמטר המרחב הוא הרים את מבטו מתורגם בהקשר יעד, ואת מחאת רשות מבוצעת עבור בהקשר SELinux הקוראות keystore_key בכיתה. כאשר נקבעה ההרשאה לפעולה הנתונה, החבילה המלאה משמשת לחיפוש המפתחות.
  • DOMAIN_GRANT : תחום המענק עולה כי הפרמטר המרחב הוא מזהה מענק. התעלמות מפרמטר הכינוי. בדיקות SELinux מבוצעות בעת יצירת המענק. בקרת כניסה נוספת בודקת רק אם UID המתקשר תואם את מזהה המענק של המענק המבוקש.
  • DOMAIN_KEY_ID : תחום זה מצביע כי הפרמטר המרחב הוא מזהה מפתח ייחודי. המפתח עצמו עשוי נוצר עם DOMAIN_APP או DOMAIN_SELINUX . בדיקת הרשות מתבצעת לאחר domain ואת namespace הוטענו ממסד נתון מפתח באותו אופן כאילו הבועה נטענה על ידי התחום, מרחב, ו tuple הכינוי. הרציונל לדומיין מזהה המפתח הוא המשכיות. כאשר ניגשים למפתח על שם כינוי, שיחות עוקבות עשויות לפעול על מקשים שונים, מכיוון שמפתח חדש עשוי או מיובא ונקשר לכינוי זה. עם זאת, מזהה המפתח לעולם אינו משתנה. כך שכאשר אתה משתמש במפתח לפי מפתח מזהה לאחר שהוא נטען ממסד הנתונים של Keystore באמצעות הכינוי פעם אחת, אפשר להיות בטוח שזה אותו מפתח כל עוד מזהה המפתח עדיין קיים. פונקציונליות זו אינה חשופה למפתחי אפליקציות. במקום זאת, הוא משמש בתוך ה- Android Keystore SPI כדי לספק חוויה עקבית יותר גם כאשר נעשה בו זמנית שימוש בצורה לא בטוחה.
  • DOMAIN_BLOB : התחום בועה מציין כי המתקשר מנהלת בועה בפני עצמה. זה משמש ללקוחות שצריכים לגשת ל- Keystore לפני התקנת מחיצת הנתונים. בועת המפתח כלול 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, מזהה 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);

ניתן להשתמש בקבצי ההקשר הבאים להגדרת מרחבי שמות של 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 N/A מפתח משתמש סופר. משמש רק לבדיקה על userdebug ו- build builds. לא רלוונטי לגבי בניית משתמשים.
1 shell_key N/A מרחב שמות זמין למעטפת. משמש בעיקר לבדיקה, אך ניתן להשתמש בו גם על בניית משתמשים משורת הפקודה.
100 vold_key N/A מיועד לשימוש על ידי vold.
101 odsing_key N/A משמש את שד החתימה במכשיר.
102 wifi_key AID_WIFI (1010) משמש על ידי מערכת Wifi של אנדרואיד כולל wpa_supplicant.
120 resume_on_reboot_key AID_SYSTEM (1000) משמש על ידי שרת המערכת של אנדרואיד כדי לתמוך בקורות חיים באתחול מחדש.

וקטורי גישה

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

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

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

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