מאגר מפתחות עם גיבוי חומרה

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

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

/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts

/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts

/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts

/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

הלקוח מבקש את המפתח על ידי בקשת הדומיין SELinux ואת מרחב שמות וירטואלי, במקרה הזה "wifi_key", באמצעות המזהה המספרי שלו.

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

גישה לווקטורים

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

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