מפתחות עטופים בחומרה

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

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

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

הערה : מנוע קריפטו מוטבע (או חומרת הצפנה מוטבעת ) מתייחס לחומרה שמצפינה/מפענחת נתונים בזמן שהיא בדרכה אל/מן התקן האחסון. בדרך כלל זהו בקר מארח UFS או eMMC שמיישם את הרחבות ההצפנה שהוגדרו על ידי מפרט JEDEC המתאים.

לְעַצֵב

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

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

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

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

היררכיית מפתח

ניתן לגזור מפתחות ממפתחות אחרים באמצעות KDF (פונקציית גזירת מפתח) כגון HKDF , וכתוצאה מכך היררכיית מפתח .

התרשים הבא מתאר היררכיית מפתח טיפוסית עבור FBE כאשר לא נעשה שימוש במפתחות עטופים בחומרה:

היררכיית מפתחות FBE (סטנדרטית)
איור 1. היררכיית מפתחות FBE (סטנדרטית)

מפתח המחלקה FBE הוא מפתח ההצפנה הגולמי ש-Android מעבירה לליבת לינוקס כדי לפתוח קבוצה מסוימת של ספריות מוצפנות, כגון אחסון מוצפן אישורים עבור משתמש אנדרואיד מסוים. (בליבה, מפתח זה נקרא מפתח ראשי fscrypt .) מהמפתח הזה, הליבה שואבת את מפתחות המשנה הבאים:

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

לעומת זאת, התרשים הבא מתאר את היררכיית המפתחות עבור FBE כאשר משתמשים במפתחות עטופים בחומרה:

היררכיית מפתחות FBE (עם מפתח עטוף בחומרה)
איור 2. היררכיית מפתחות FBE (עם מפתח עטוף בחומרה)

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

  • ממשק אחד לגזור inline_encryption_key ולתכנת אותו ישירות לתוך חריץ מפתח של מנוע ההצפנה המוטבע. זה מאפשר להצפין/פענח את תוכן הקבצים מבלי שלתוכנה תהיה גישה למפתח הגולמי. בקרנלים הנפוצים של אנדרואיד, ממשק זה מתאים לפעולת blk_crypto_ll_ops::keyslot_program , אשר חייבת להיות מיושמת על ידי מנהל התקן האחסון.
  • ממשק אחד לגזירה והחזרה sw_secret ("סוד תוכנה" - נקרא גם "סוד גולמי" במקומות מסוימים), שהוא המפתח שבו לינוקס משתמשת כדי לגזור את מפתחות המשנה לכל דבר מלבד הצפנת תוכן הקבצים. בקרנלים הנפוצים של אנדרואיד, ממשק זה מתאים לפעולת blk_crypto_ll_ops::derive_sw_secret , אותה יש ליישם על ידי מנהל האחסון.

כדי לגזור inline_encryption_key ו- sw_secret ממפתח האחסון הגולמי, החומרה חייבת להשתמש ב-KDF חזק מבחינה קריפטוגרפית. KDF זה חייב לפעול לפי שיטות עבודה מומלצות להצפנה; הוא חייב להיות בעל חוזק אבטחה של לפחות 256 סיביות, כלומר מספיק עבור כל אלגוריתם בשימוש מאוחר יותר. כמו כן, עליו להשתמש בתווית, בהקשר ו/או במחרוזת מידע ספציפית ליישום בעת גזירת כל סוג של מפתח משנה על מנת להבטיח שמפתחות המשנה המתקבלים מבודדים מבחינה קריפטוגרפית, כלומר ידע על אחד מהם אינו מגלה כל סוג אחר. אין צורך במתיחת מפתח, מכיוון שמפתח האחסון הגולמי הוא כבר מפתח אקראי באופן אחיד.

מבחינה טכנית, ניתן להשתמש בכל KDF שעומד בדרישות האבטחה. עם זאת, למטרות בדיקה, יש צורך להטמיע מחדש את אותו KDF בקוד הבדיקה. נכון לעכשיו, KDF אחד נבדק ויושם; ניתן למצוא אותו בקוד המקור של vts_kernel_encryption_test . מומלץ לחומרה להשתמש ב-KDF זה, המשתמש ב- NIST SP 800-108 "KDF במצב Counter" עם AES-256-CMAC בתור PRF. שימו לב שכדי להיות תואם, כל חלקי האלגוריתם חייבים להיות זהים, כולל הבחירה של הקשרים ותוויות KDF עבור כל מפתח משנה.

עטיפת מפתחות

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

  • עטיפה ארעית : החומרה מצפינה את המפתח הגולמי באמצעות מפתח שנוצר באופן אקראי בכל אתחול ואינו חשוף ישירות מחוץ לחומרה.
  • עטיפה לטווח ארוך : החומרה מצפינה את המפתח הגולמי באמצעות מפתח ייחודי ומתמשך המובנה בחומרה שאינו חשוף ישירות מחוץ לחומרה.

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

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

כדי לתמוך בניהול מפתחות עטופים בשתי דרכים שונות אלה, החומרה חייבת ליישם את הממשקים הבאים:

  • ממשקים ליצירה ויבוא של מפתחות אחסון, החזרתם בצורה עטופה לטווח ארוך. ממשקים אלה נגישים בעקיפין דרך KeyMint, והם תואמים לתג KeyMint TAG_STORAGE_KEY . יכולת ה"יצירת" משמשת את vold ליצירת מפתחות אחסון חדשים לשימוש אנדרואיד, בעוד יכולת ה"ייבוא" משמשת את vts_kernel_encryption_test לייבוא ​​מפתחות בדיקה.
  • ממשק להמרת מפתח אחסון עטוף לטווח ארוך למפתח אחסון עטוף ארעית. זה מתאים לשיטת convertStorageKeyToEphemeral KeyMint. שיטה זו משמשת גם vold וגם vts_kernel_encryption_test על מנת לבטל את נעילת האחסון.

אלגוריתם גלישת המפתח הוא פרט יישום, אך עליו להשתמש ב-AEAD חזק כגון AES-256-GCM עם IVs אקראיים.

נדרשים שינויים בתוכנה

ל-AOSP כבר יש מסגרת בסיסית לתמיכה במפתחות עטופים בחומרה. זה כולל את התמיכה ברכיבי מרחב משתמש כגון vold , כמו גם את תמיכת ליבת לינוקס ב- blk-crypto , fscrypt ו- dm-default-key .

עם זאת, נדרשים כמה שינויים ספציפיים ליישום.

KeyMint שינויים

יש לשנות את יישום KeyMint של המכשיר כדי לתמוך TAG_STORAGE_KEY ולהטמיע את שיטת convertStorageKeyToEphemeral .

ב-Keymaster, נעשה שימוש exportKey במקום convertStorageKeyToEphemeral .

שינויים בקרנל לינוקס

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

עבור גרעיני android14 ומעלה, הגדר את BLK_CRYPTO_KEY_TYPE_HW_WRAPPED ב- blk_crypto_profile::key_types_supported , הפוך blk_crypto_ll_ops::keyslot_program ו- blk_crypto_ll_ops::keyslot_evict תמיכה בתכנות/מפתחות:_crypto_ll_evicting blk_crypto_ll_ops::derive_sw_secret .

עבור ליבות android12 ו- android13 , הגדר את BLK_CRYPTO_FEATURE_WRAPPED_KEYS ב- blk_keyslot_manager::features , צור blk_ksm_ll_ops::keyslot_program ו- blk_ksm_ll_ops::keyslot_evict תמיכה בתכנות/הדחה של keyslots blk_ksm_ll_ops::derive_raw_secret .

עבור ליבות android11 , הגדר BLK_CRYPTO_FEATURE_WRAPPED_KEYS ב- keyslot_manager::features , צור keyslot_mgmt_ll_ops::keyslot_program ו- keyslot_mgmt_ll_ops::keyslot_evict תמיכה בתכנות/פינוי חומרה_ ו-implement_mgmt_ll_ops keyslot_mgmt_ll_ops::derive_raw_secret . .

בדיקה

למרות שהצפנה עם מפתחות עטופים בחומרה קשה יותר לבדיקה מאשר הצפנה עם מפתחות סטנדרטיים, עדיין אפשר לבדוק על ידי ייבוא ​​מפתח בדיקה ויישום מחדש של גזירת המפתח שהחומרה עושה. זה מיושם ב- vts_kernel_encryption_test . כדי להפעיל את הבדיקה הזו, הרץ:

atest -v vts_kernel_encryption_test

קרא את יומן הבדיקה וודא שמקרי הבדיקה של המפתח העטוף בחומרה (למשל FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy ו- DmDefaultKeyTest.TestHwWrappedKey ) לא דילגו עקב תמיכה במפתחות עטופים בחומרה שלא זוהו, מכיוון שתוצאות הבדיקה עדיין יהיו "עוברות" המקרה הזה.

מפעיל

לאחר שתמיכת המפתח העטוף בחומרה של המכשיר פועלת כהלכה, תוכל לבצע את השינויים הבאים בקובץ fstab של המכשיר כדי לגרום לאנדרואיד להשתמש בו להצפנת FBE ומטא נתונים:

  • FBE: הוסף את דגל wrappedkey_v0 לפרמטר fileencryption . לדוגמה, השתמש fileencryption=::inlinecrypt_optimized+wrappedkey_v0 . לפרטים נוספים, עיין בתיעוד של ה-FBE .
  • הצפנת מטא נתונים: הוסף את דגל wrappedkey_v0 לפרמטר metadata_encryption . לדוגמה, השתמש metadata_encryption=:wrappedkey_v0 . לפרטים נוספים, עיין בתיעוד של הצפנת מטא נתונים .