הצפנה מבוססת קבצים

אנדרואיד 7.0 ואילך תומך בהצפנה מבוססת קבצים (FBE). הצפנה מבוססת קבצים מאפשרת להצפין קבצים שונים באמצעות מפתחות שונים הניתנים לפתיחה עצמאית.

מאמר זה מתאר כיצד לאפשר הצפנה מבוססת קבצים במכשירים חדשים וכיצד יישומי מערכת יכולים להשתמש בממשקי ה-API של Boot Direct כדי להציע למשתמשים את החוויה הטובה והמאובטחת ביותר האפשרית.

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

אתחול ישיר

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

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

במכשיר התומך ב-FBE, לכל משתמש במכשיר יש שני מיקומי אחסון זמינים ליישומים:

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

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

ה-API של Direct Boot מאפשר ליישומים המודעים להצפנה לגשת לכל אחד מהתחומים הללו. ישנם שינויים במחזור החיים של האפליקציה כדי להתאים את הצורך להודיע ​​ליישומים כאשר אחסון ה-CE של משתמש אינו נעול בתגובה להזנה ראשונה של אישורים במסך הנעילה, או במקרה של פרופיל עבודה המספק אתגר עבודה . מכשירים עם אנדרואיד 7.0 חייבים לתמוך בממשקי ה-API החדשים ובמחזורי החיים האלה, ללא קשר לשאלה אם הם מיישמים FBE או לא. אמנם, ללא FBE, אחסון DE ו-CE תמיד יהיה במצב לא נעול.

הטמעה מלאה של הצפנה מבוססת קבצים במערכות הקבצים Ext4 ו-F2FS מסופקת ב-Android Open Source Project (AOSP) וצריכה להיות מופעלת רק במכשירים העומדים בדרישות. יצרנים הבוחרים להשתמש ב-FBE עשויים לרצות לבחון דרכים לייעל את התכונה בהתבסס על המערכת על השבב (SoC) בשימוש.

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

  • שירותי טלפוניה וחייגן
  • שיטת קלט להזנת סיסמאות למסך הנעילה

דוגמאות ומקור

אנדרואיד מספקת יישום ייחוס של הצפנה מבוססת קבצים, שבה vold ( system/vold ) מספקת את הפונקציונליות לניהול התקני אחסון ואמצעי אחסון באנדרואיד. התוספת של FBE מספקת ל-vold מספר פקודות חדשות לתמיכה בניהול מפתחות עבור מפתחות CE ו-DE של מספר משתמשים. בנוסף לשינויי הליבה לשימוש ביכולות ההצפנה המבוססות על קבצים בקרנל , חבילות מערכת רבות, כולל מסך הנעילה וה-SystemUI, שונו כדי לתמוך בתכונות FBE ו- Direct Boot. אלו כוללים:

  • חייגן AOSP (חבילות/אפליקציות/חייגן)
  • שעון שולחני (חבילות/אפליקציות/DeskClock)
  • LatinIME (חבילות/שיטות קלט/LatinIME)*
  • אפליקציית הגדרות (חבילות/אפליקציות/הגדרות)*
  • מערכת ממשק משתמש (מסגרות/בסיס/חבילות/משתמש מערכת)*

* יישומי מערכת המשתמשים בתכונת המניפסט defaultToDeviceProtectedStorage

דוגמאות נוספות ליישומים ושירותים שמודעים להצפנה ניתן למצוא על ידי הפעלת הפקודה mangrep directBootAware בספריית ה-framesworks או החבילות של עץ המקור של AOSP.

תלות

כדי להשתמש ביישום AOSP של FBE בצורה מאובטחת, מכשיר צריך לעמוד בהתלות הבאה:

  • תמיכת ליבה להצפנת Ext4 או הצפנת F2FS.
  • תמיכה ב-Keymaster עם גירסת HAL 1.0 ומעלה. אין תמיכה ב-Keymaster 0.3 מכיוון שהוא אינו מספק את היכולות הדרושות או מבטיח הגנה מספקת עבור מפתחות הצפנה.
  • Keymaster/ Keystore ו-Gatekeeper חייבים להיות מיושמים בסביבת ביצוע מהימנה (TEE) כדי לספק הגנה למפתחות ה-DE כך שמערכת הפעלה לא מורשית (מערכת הפעלה מותאמת אישית מהבהבת במכשיר) לא יכולה פשוט לבקש את מפתחות ה-DE.
  • שורש החומרה של אמון ואתחול מאומת הקשורים לאתחול Keymaster נדרשים כדי להבטיח שמפתחות DE אינם נגישים למערכת הפעלה לא מורשית.

יישום

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

תמיכת ליבה

תמיכה בליבה להצפנת Ext4 ו-F2FS זמינה בקרנלים הנפוצים של אנדרואיד, גרסה 3.18 ומעלה. כדי להפעיל אותו בליבה שהיא גרסה 5.1 ומעלה, השתמש ב:

CONFIG_FS_ENCRYPTION=y

עבור ליבות ישנות יותר, השתמש CONFIG_EXT4_ENCRYPTION=y אם מערכת הקבצים userdata של המכשיר שלך היא Ext4, או השתמש ב- CONFIG_F2FS_FS_ENCRYPTION=y אם מערכת הקבצים userdata של המכשיר שלך היא F2FS.

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

בנוסף לתמיכה פונקציונלית בהצפנת Ext4 או F2FS, יצרני מכשירים צריכים לאפשר גם האצה קריפטוגרפית כדי להאיץ הצפנה מבוססת קבצים ולשפר את חווית המשתמש. לדוגמה, במכשירים מבוססי ARM64, ניתן להפעיל האצת ARMv8 CE (הרחבות קריפטוגרפיה) על ידי הגדרת אפשרויות תצורת הליבה הבאות:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

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

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

אם המכשיר שלך משתמש באחסון מבוסס UFS, הפעל גם:

CONFIG_SCSI_UFS_CRYPTO=y

אם המכשיר שלך משתמש באחסון מבוסס eMMC, הפעל גם:

CONFIG_MMC_CRYPTO=y

הפעלת הצפנה מבוססת קבצים

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

אחסון פנימי

FBE מופעל על ידי הוספת האפשרות fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] לעמודת fs_mgr_flags בשורת fstab עבור userdata . אפשרות זו מגדירה את פורמט ההצפנה באחסון הפנימי. הוא מכיל עד שלושה פרמטרים מופרדים במעי הגס:

  • הפרמטר contents_encryption_mode מגדיר באיזה אלגוריתם הצפנה נעשה שימוש להצפנת תוכן הקובץ. זה יכול להיות aes-256-xts או adiantum . מאז אנדרואיד 11 ניתן גם להשאיר אותו ריק כדי לציין את אלגוריתם ברירת המחדל, שהוא aes-256-xts .
  • הפרמטר filenames_encryption_mode מגדיר באיזה אלגוריתם הצפנה נעשה שימוש להצפנת שמות קבצים. זה יכול להיות aes-256-cts , aes-256-heh , adiantum או aes-256-hctr2 . אם לא צוין, ברירת המחדל היא aes-256-cts אם contents_encryption_mode הוא aes-256-xts , או ל- adiantum אם contents_encryption_mode הוא adiantum .
  • פרמטר flags , חדש באנדרואיד 11, הוא רשימה של דגלים המופרדים על ידי התו + . הדגלים הבאים נתמכים:
    • דגל v1 בוחר במדיניות הצפנה של גרסה 1; דגל v2 בוחר במדיניות הצפנה של גרסה 2. מדיניות ההצפנה של גרסה 2 משתמשת בפונקציית גזירת מפתח מאובטחת וגמישה יותר. ברירת המחדל היא v2 אם המכשיר הושק ב-Android 11 ומעלה (כפי שנקבע על ידי ro.product.first_api_level ), או v1 אם המכשיר הושק ב-Android 10 ומטה.
    • הדגל inlinecrypt_optimized בוחר בפורמט הצפנה המותאם עבור חומרת הצפנה מוטבעת שאינה מטפלת במספרים גדולים של מפתחות ביעילות. הוא עושה זאת על ידי גזירת מפתח הצפנה של תוכן קובץ אחד בלבד לכל מפתח CE או DE, במקום אחד לכל קובץ. הדור של IVs (וקטורי אתחול) מותאם בהתאם.
    • הדגל emmc_optimized דומה ל- inlinecrypt_optimized , אך הוא גם בוחר בשיטה ליצירת IV המגבילה IVs ל-32 סיביות. יש להשתמש בדגל זה רק בחומרת הצפנה מוטבעת התואמת למפרט JEDEC eMMC v5.2 ולכן תומכת רק ב-IV של 32 סיביות. בחומרת הצפנה מוטבעת אחרת, השתמש במקום זאת inlinecrypt_optimized . אסור להשתמש בדגל זה באחסון מבוסס UFS; מפרט UFS מאפשר שימוש ב-IV של 64 סיביות.
    • במכשירים התומכים במפתחות עטופים בחומרה , דגל wrappedkey_v0 מאפשר שימוש במפתחות עטופים בחומרה עבור FBE. ניתן להשתמש בזה רק בשילוב עם אפשרות ההרכבה inlinecrypt , ודגל inlinecrypt_optimized או emmc_optimized .

אם אינך משתמש בחומרת הצפנה מוטבעת, ההגדרה המומלצת עבור רוב המכשירים היא fileencryption=aes-256-xts . אם אתה משתמש בחומרת הצפנה מוטבעת, ההגדרה המומלצת עבור רוב המכשירים היא fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (או באופן שווה ערך fileencryption=::inlinecrypt_optimized ). במכשירים ללא כל צורה של האצת AES, ניתן להשתמש באדיאנטום במקום ב-AES על ידי הגדרת fileencryption=adiantum .

מאז Android 14, AES-HCTR2 הוא המצב המועדף של הצפנת שמות קבצים עבור מכשירים עם הוראות הצפנה מואצות. עם זאת, רק ליבות אנדרואיד חדשות יותר תומכות ב-AES-HCTR2. במהדורת אנדרואיד עתידית, זה מתוכנן להפוך למצב ברירת המחדל להצפנת שמות קבצים. אם הליבה שלך תומך ב-AES-HCTR2, ניתן להפעיל אותו להצפנת שמות קבצים על ידי הגדרת filenames_encryption_mode ל- aes-256-hctr2 . במקרה הפשוט ביותר זה ייעשה עם fileencryption=aes-256-xts:aes-256-hctr2 .

במכשירים שהושקו עם אנדרואיד 10 ומטה, fileencryption=ice מתקבל גם כדי לציין את השימוש במצב הצפנת תוכן הקובץ FSCRYPT_MODE_PRIVATE . מצב זה אינו מיושם על ידי הגרעינים הנפוצים של אנדרואיד, אך ניתן ליישם אותו על ידי ספקים באמצעות תיקוני ליבה מותאמים אישית. הפורמט בדיסק שנוצר על ידי מצב זה היה ספציפי לספק. במכשירים המופעלים עם אנדרואיד 11 ומעלה, מצב זה אינו מותר עוד ויש להשתמש בפורמט הצפנה סטנדרטי במקום זאת.

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

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

אחסון ניתן לאימוץ

מאז אנדרואיד 9, FBE ואחסון ניתן לאמץ ניתן להשתמש יחד.

ציון האפשרות fstab של fileencryption עבור userdata מאפשרת גם באופן אוטומטי גם הצפנת FBE וגם הצפנת מטא נתונים באחסון שניתן לאמץ. עם זאת, תוכל לעקוף את הפורמטים של הצפנת FBE ו/או מטא נתונים באחסון הניתן לאימוץ על ידי הגדרת מאפיינים ב- PRODUCT_PROPERTY_OVERRIDES .

במכשירים שהושקו עם Android 11 ומעלה, השתמש במאפיינים הבאים:

  • ro.crypto.volume.options (חדש באנדרואיד 11) בוחר בפורמט ההצפנה FBE באחסון שניתן לאמץ. יש לו את אותו תחביר כמו הארגומנט לאפשרות fstab fileencryption , והוא משתמש באותן ברירות מחדל. עיין בהמלצות להצפנת fileencryption לעיל במה להשתמש כאן.
  • ro.crypto.volume.metadata.encryption בוחר את פורמט הצפנת המטא נתונים באחסון שניתן לאמץ. עיין בתיעוד של הצפנת מטא נתונים .

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

  • ro.crypto.volume.contents_mode בוחר את מצב הצפנת התוכן. זה שווה ערך לשדה הראשון המופרד בנקודתיים של ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode בוחר את מצב הצפנת שמות הקבצים. זה שווה ערך לשדה השני המופרד בנקודתיים של ro.crypto.volume.options , אלא שברירת המחדל במכשירים שהושקו עם אנדרואיד 10 ומטה היא aes-256-heh . ברוב המכשירים, יש לעקוף זאת במפורש ל- aes-256-cts .
  • ro.crypto.fde_algorithm ו- ro.crypto.fde_sector_size בחרו את פורמט הצפנת המטא נתונים באחסון הניתן לאימוץ. עיין בתיעוד של הצפנת מטא נתונים .

שילוב עם Keymaster

יש להתחיל את ה-Keymaster HAL כחלק מהשיעור early_hal . הסיבה לכך היא ש-FBE דורש ש-Keymaster יהיה מוכן לטפל בבקשות בשלב האתחול post-fs-data , כלומר כאשר vold מגדיר את המפתחות הראשוניים.

לא כולל ספריות

init מחיל את מפתח DE של המערכת על כל הספריות ברמה העליונה של /data , למעט ספריות שחייבות להיות לא מוצפנות: הספרייה המכילה את מפתח DE המערכת עצמה, וספריות המכילות ספריות CE או DE של המשתמש. מפתחות הצפנה חלים רקורסיבית ולא ניתן לעקוף אותם על ידי ספריות משנה.

באנדרואיד 11 ומעלה, ניתן לשלוט במפתח ש- init חל על ספריות על ידי ארגומנט encryption=<action> לפקודת mkdir בסקריפטים של init. הערכים האפשריים של <action> מתועדים ב- README עבור שפת ה-Init של Android .

ב-Android 10, פעולות ההצפנה init קוידו בקשיחים למיקום הבא:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

באנדרואיד 9 ואילך, המיקום היה:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

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

מקרה השימוש היחיד הידוע המקובל לכך הוא תמיכה ביכולות OTA מדור קודם.

תמיכה באתחול ישיר ביישומי מערכת

הפיכת יישומים למודעים לאתחול ישיר

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

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

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

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

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

  • Context.createCredentialProtectedStorageContext()
  • Context.isCredentialProtectedStorage()

תמיכה במספר משתמשים

כל משתמש בסביבה מרובת משתמשים מקבל מפתח הצפנה נפרד. כל משתמש מקבל שני מפתחות: מפתח DE ומפתח CE. משתמש 0 חייב להיכנס תחילה למכשיר מכיוון שהוא משתמש מיוחד. זה רלוונטי לשימושים בניהול התקנים .

יישומים המודעים לקריפטו מקיימים אינטראקציה בין משתמשים באופן זה: INTERACT_ACROSS_USERS ו- INTERACT_ACROSS_USERS_FULL מאפשרים לאפליקציה לפעול מול כל המשתמשים במכשיר. עם זאת, אפליקציות אלה יוכלו לגשת רק לספריות מוצפנות CE עבור משתמשים שכבר לא נעולים.

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

כל מזהה משתמש של פרופיל עבודה מקבל גם שני מפתחות: DE ו-CE. כאשר אתגר העבודה מתקיים, משתמש הפרופיל אינו נעול וה-Keymaster (ב-TEE) יכול לספק את מפתח ה-TEE של הפרופיל.

טיפול בעדכונים

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

בעת שימוש בפתרון OTA מדור קודם, הדורש שחזור כדי לגשת לקובץ OTA במחיצת userdata :

  1. צור ספרייה ברמה העליונה (לדוגמה misc_ne ) במחיצת userdata .
  2. הגדר את הספרייה ברמה העליונה כך שלא תהיה מוצפנת (ראה אי הכללת ספריות ).
  3. צור ספרייה בתוך הספרייה ברמה העליונה כדי להחזיק חבילות OTA.
  4. הוסף כלל SELinux והקשרי קובץ כדי לשלוט בגישה לספרייה זו ולתוכן שלה. רק התהליך או היישומים המקבלים עדכוני OTA אמורים להיות מסוגלים לקרוא ולכתוב לספרייה זו. לאף יישום או תהליך אחר לא אמורה להיות גישה לספרייה זו.

מַתַן תוֹקֵף

כדי להבטיח שהגרסה המיושמת של התכונה פועלת כמתוכנן, הפעל תחילה את מבחני ההצפנה הרבים של CTS, כגון DirectBootHostTest ו- EncryptionTest .

אם במכשיר פועל אנדרואיד 11 ומעלה, הפעל גם את vts_kernel_encryption_test :

atest vts_kernel_encryption_test

אוֹ:

vts-tradefed run vts -m vts_kernel_encryption_test

בנוסף, יצרני המכשירים עשויים לבצע את הבדיקות הידניות הבאות. במכשיר עם FBE מופעל:

  • בדוק ש- ro.crypto.state קיים
    • ודא ro.crypto.state מוצפן
  • בדוק ש- ro.crypto.type קיים
    • ודא ro.crypto.type מוגדר file

בנוסף, בודקים יכולים לאתחל מופע userdebug עם מסך נעילה שהוגדר על המשתמש הראשי. לאחר מכן adb מעטפת לתוך המכשיר והשתמש su כדי להפוך לשורש. ודא ש- /data/data מכיל שמות קבצים מוצפנים; אם לא, משהו לא בסדר.

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

פרטי הטמעת AOSP

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

הצפנת fscrypt

הטמעת AOSP משתמשת בהצפנה "fscrypt" (נתמכת על ידי ext4 ו-f2fs) בליבה ובדרך כלל מוגדרת ל:

  • הצפנת תוכן הקובץ עם AES-256 במצב XTS
  • הצפנת שמות קבצים עם AES-256 במצב CBC-CTS

גם הצפנת Adiantum נתמכת. כאשר הצפנת Adiantum מופעלת, גם תוכן הקבצים וגם שמות הקבצים מוצפנים באמצעות Adiantum.

fscrypt תומך בשתי גרסאות של מדיניות הצפנה: גרסה 1 וגרסה 2. גרסה 1 הוצאה משימוש, ודרישות ה-CDD עבור מכשירים המופעלים עם אנדרואיד 11 ומעלה תואמות רק לגרסה 2. מדיניות ההצפנה של גרסה 2 משתמשת ב-HKDF-SHA512 כדי לגזור את המציאות בפועל מפתחות הצפנה מהמפתחות שסופקו על ידי מרחב המשתמש.

למידע נוסף על fscrypt, עיין בתיעוד הליבה במעלה הזרם .

שיעורי אחסון

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

שיעור אחסון תיאור מדריכים
מערכת DE נתונים מוצפנים במכשיר אינם קשורים למשתמש מסוים /data/system , /data/app ותת-ספריות שונות אחרות של /data
לכל אתחול קבצי מערכת ארעיים שאינם צריכים לשרוד אתחול מחדש /data/per_boot
משתמש CE (פנימי) נתונים מוצפנים לכל משתמש באחסון פנימי
  • /data/data (כינוי של /data/user/0 )
  • /data/media/${user_id}
  • /data/misc_ce/${user_id}
  • /data/system_ce/${user_id}
  • /data/user/${user_id}
  • /data/vendor_ce/${user_id}
משתמש DE (פנימי) נתונים מוצפנים לכל משתמש באחסון פנימי
  • /data/misc_de/${user_id}
  • /data/system_de/${user_id}
  • /data/user_de/${user_id}
  • /data/vendor_de/${user_id}
משתמש CE (ניתן לאמץ) נתונים מוצפנים לכל משתמש באחסון הניתן לאימוץ
  • /mnt/expand/${volume_uuid}/media/${user_id}
  • /mnt/expand/${volume_uuid}/misc_ce/${user_id}
  • /mnt/expand/${volume_uuid}/user/${user_id}
משתמש DE (ניתן לאמץ) נתונים מוצפנים לכל משתמש באחסון שניתן לאמץ
  • /mnt/expand/${volume_uuid}/misc_de/${user_id}
  • /mnt/expand/${volume_uuid}/user_de/${user_id}

אחסון מפתח והגנה

כל מפתחות ה-FBE מנוהלים על ידי vold ומאוחסנים מוצפנים בדיסק, פרט למפתח לכל אתחול שאינו מאוחסן כלל. הטבלה הבאה מפרטת את המיקומים שבהם מאוחסנים מפתחות FBE השונים:

סוג מפתח מיקום מפתח דרגת אחסון של מיקום מפתח
מפתח DE של מערכת /data/unencrypted לא מוצפן
מפתחות CE (פנימיים) למשתמש /data/misc/vold/user_keys/ce/${user_id} מערכת DE
מפתח DE (פנימי) משתמש /data/misc/vold/user_keys/de/${user_id} מערכת DE
מפתחות CE (ניתנים לאימוץ) למשתמש /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} משתמש CE (פנימי)
מפתחות DE (ניתנים לאימוץ) משתמש /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} משתמש DE (פנימי)

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

vold גם מחיל שכבת הצפנה על כל מפתחות ה-FBE. כל מפתח מלבד מפתחות CE לאחסון פנימי מוצפן עם AES-256-GCM באמצעות מפתח Keystore משלו שאינו חשוף מחוץ ל-TEE. זה מבטיח שלא ניתן לבטל את הנעילה של מפתחות FBE אלא אם כן אותחלה מערכת הפעלה מהימנה, כפי שנאכפת על ידי Verified Boot . התנגדות לאחור מתבקשת גם במפתח Keystore, המאפשר למחוק מפתחות FBE בצורה מאובטחת במכשירים שבהם Keymaster תומך בהתנגדות לאחור. כפריסת מאמץ טובה ביותר כאשר התנגדות החזרה לא זמינה, ה-hash SHA-512 של 16384 בתים אקראיים המאוחסנים בקובץ secdiscardable המאוחסן לצד המפתח משמש כתג מזהה האפליקציה של מפתח מאגר המפתחות. יש לשחזר את כל הבתים הללו כדי לשחזר מפתח FBE.

מפתחות CE לאחסון פנימי מקבלים רמת הגנה חזקה יותר שמבטיחה שלא ניתן לפתוח אותם מבלי לדעת את גורם הידע של מסך הנעילה (LSKF) של המשתמש (PIN, דפוס או סיסמה), אסימון לאיפוס קוד סיסמה מאובטח , או גם בצד הלקוח ומפתחות בצד השרת לפעולת Resume-On-Reboot . מותר ליצור אסימוני איפוס קוד סיסמה רק עבור פרופילי עבודה ומכשירים מנוהלים במלואם .

כדי להשיג זאת, vold מצפין כל מפתח CE לאחסון פנימי באמצעות מפתח AES-256-GCM הנגזר מהסיסמה הסינתטית של המשתמש. הסיסמה הסינתטית היא סוד קריפטוגרפי בעל אנטרופיה גבוהה בלתי משתנה שנוצר באופן אקראי עבור כל משתמש. LockSettingsService ב- system_server מנהל את הסיסמה הסינתטית ואת הדרכים שבהן היא מוגנת.

כדי להגן על הסיסמה הסינתטית עם ה-LSKF, LockSettingsService מותח תחילה את ה-LSKF על-ידי העברתו דרך scrypt , מכוון לזמן של כ-25 אלפיות השנייה ושימוש בזיכרון של כ-2 MiB. מכיוון ש-LSKFs הם בדרך כלל קצרים, שלב זה בדרך כלל אינו מספק הרבה אבטחה. שכבת האבטחה העיקרית היא ה- Secure Element (SE) או הגבלת תעריפים שנאכפת על ידי TEE המתואר להלן.

אם למכשיר יש אלמנט מאובטח (SE), אז LockSettingsService ממפה את ה-LSKF המתוח לסוד אקראי בעל אנטרופיה גבוהה המאוחסן ב-SE באמצעות ה- Weaver HAL . לאחר מכן, LockSettingsService מצפין את הסיסמה הסינתטית פעמיים: ראשית עם מפתח תוכנה הנגזר מה-LSKF המתוח ומהסוד של Weaver, ושנית עם מפתח Keystore לא מאושרים. זה מספק הגבלת תעריפים שנאכפת על ידי SE של ניחושים של LSKF.

אם למכשיר אין SE, LockSettingsService במקום זאת משתמש ב-LSKF המתוח כסיסמת Gatekeeper . LockSettingsService לאחר מכן מצפין את הסיסמה הסינתטית פעמיים: ראשית עם מפתח תוכנה שמקורו ב-LSKF המתוח וה-hash של קובץ secdiscardable, ושנית עם מפתח Keystore המקושר אישור לרישום Gatekeeper. זה מספק הגבלת תעריפים שנאכפת על ידי TEE של ניחושים של LSKF.

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