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

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

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

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

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

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

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

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

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

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

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

מילון מונחים

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

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

הדימון של Keystore הוא דימון מערכת של Android שמספק גישה לכל הפונקציונליות של Keystore באמצעות Binder API. הוא אחראי לאחסון 'blobs של מפתחות', שמכילים את חומר המפתח הסודי בפועל, מוצפנים כך ש-Keystore יכול לאחסן אותם אבל לא להשתמש בהם או לחשוף אותם.

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

Keymaster TA (אפליקציה מהימנה) היא התוכנה שפועלת בהקשר מאובטח, בדרך כלל ב-TrustZone ב-ARM SoC, שמספקת את כל הפעולות המאובטחות של Keystore, יש לה גישה לחומר המפתח הגולמי, היא מאמתת את כל התנאים של בקרת הגישה למפתחות וכו'.

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

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

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

ארכיטקטורה

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

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

איור 1. גישה ל-Keymaster

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

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

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

ממשק ה-HAL של Keymaster 1 לא תואם לחלוטין לממשקי ה-HAL שפורסמו בעבר, למשל Keymaster 0.2 ו-0.3. כדי לאפשר יכולת פעולה הדדית במכשירים עם Android מגרסה 5.0 ואילך, שהושקו עם ממשקי ה-HAL הקודמים של Keymaster, ‏Keystore מספק מתאם שמטמיע את ה-HAL של Keymaster 1 באמצעות קריאות לספריית החומרה הקיימת. התוצאה לא יכולה לספק את מגוון הפונקציונליות המלא של HAL של Keymaster 1. באופן ספציפי, הוא תומך רק באלגוריתמים RSA ו-ECDSA, וכל אכיפת ההרשאות למפתחות מתבצעת על ידי המתאם, בעולם הלא מאובטח.

ב-Keymaster 2, ממשק ה-HAL פשוט יותר, כי הוסרו השיטות get_supported_* והשיטה finish() יכולה לקבל קלט. כך מפחיתים את מספר הנסיעות הלוך ושוב ל-TEE במקרים שבהם הקלט זמין בבת אחת, ומפשטים את ההטמעה של פענוח AEAD.

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

סקירה כללית על HIDL

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

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

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

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

דוגמה לשיטה מ-Keymaster 3 IKeymasterDevice.hal:

generateKey(vec<KeyParameter> keyParams)
        generates(ErrorCode error, vec<uint8_t> keyBlob,
                  KeyCharacteristics keyCharacteristics);

זהו המקבילה לקוד הבא מ-HAL של keymaster2:

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 הוא כבר לא מבנה שמכיל ‎pointer שמפנה למערך של אובייקטים מסוג key_parameter_t, אלא vec (וקטור) שמכיל אובייקטים מסוג KeyParameter. ערכי ההחזרה מפורטים בפסקה generates, כולל וקטור של ערכים של uint8_t עבור blob המפתח.

השיטה הווירטואלית ב-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 היא פונקציה שמקבלת את ערכי ההחזרה שמפורטים בפסקת ה-generate. מחלקת ההטמעה של HAL מבטלת את השיטה generateKey ומפעילה את הפונקציה generateKey_cb כדי להחזיר את התוצאה של הפעולה למבצע הקריאה. חשוב לזכור שהקריאה למצביע הפונקציה היא סינכרונית. מבצע הקריאה קורא ל-generateKey ו-generateKey קורא למצביע הפונקציה שסופק, שמתבצע עד הסוף ומחזיר את השליטה להטמעה של generateKey, שמחזירה את השליטה למבצע הקריאה.

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

בקרת גישה

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

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

דומיינים של מאגרי מפתחות

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

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

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

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

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

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

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