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

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

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

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

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

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

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

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

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

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

באנדרואיד 9, עדכונים כללו:

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

מילון מונחים

הנה סקירה מהירה של רכיבי Keystore והקשרים ביניהם.

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

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

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

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

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

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

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

ארכיטקטורה

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

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

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

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

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

תאימות עם גרסאות קודמות

ה-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.

באנדרואיד 8.0, Keymaster 3 עבר מ-HAL בסגנון הישן של מבנה C לממשק C++ HAL שנוצר מהגדרה ב-Hardware Interface Definition Language (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);

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

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