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

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

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

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

אתחול ישיר

הצפנה מבוססת קבצים מאפשרת תכונה חדשה שהוצגה באנדרואיד 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 או החבילות של עץ המקור של AOSP.

תלות

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

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

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

יישום

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

תמיכת ליבה

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

CONFIG_FS_ENCRYPTION=y

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

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

בנוסף לתמיכה פונקציונלית בהצפנת 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 xts או adiantum . מאז אנדרואיד 11 ניתן גם להשאיר אותו ריק כדי לציין את אלגוריתם ברירת המחדל, שהוא aes-256-xts .
  • הפרמטר filenames_encryption_mode מגדיר באיזה אלגוריתם הצפנה נעשה שימוש להצפנת שמות קבצים. זה יכול להיות aes-256-cts , aes-256-heh או adiantum . אם לא צוין, ברירת המחדל היא 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_optimized של inlinecrypt , ודגל emmc_optimized .

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

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

ציון אפשרות userdata של fileencryption עבור נתוני משתמש מאפשרת גם באופן אוטומטי גם הצפנת 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

יצירת המפתחות וניהול מחזיק המפתחות של הליבה מטופל על ידי vold . הטמעת AOSP של FBE דורשת שהמכשיר יתמוך ב-Keymaster HAL גרסה 1.0 ואילך. אין תמיכה בגרסאות קודמות של Keymaster HAL.

באתחול הראשון, מפתחות משתמש 0 נוצרים ומותקנים בשלב מוקדם בתהליך האתחול. עד להשלמת שלב on-post-fs של init , ה-Keymaster חייב להיות מוכן לטפל בבקשות. במכשירי Pixel, זה מטופל על ידי חסימת סקריפט שמבטיחה שה-Keymaster מופעל לפני הטעינה /data .

מדיניות הצפנה

הצפנה מבוססת קבצים מיישמת את מדיניות ההצפנה ברמת הספרייה. כאשר נוצרת לראשונה userdata נתוני משתמש של מכשיר, המבנים והמדיניות הבסיסיים מיושמים על ידי סקריפטים של init . סקריפטים אלו יפעילו את יצירת מפתחות ה-CE וה-DE של המשתמש הראשון (משתמש 0) וכן יגדירו אילו ספריות יש להצפין במפתחות אלו. כאשר משתמשים ופרופילים נוספים נוצרים, המפתחות הנוספים הדרושים נוצרים ומאוחסנים במאגר המפתחות; מיקומי האחסון של האישורים והמכשירים שלהם נוצרים ומדיניות ההצפנה מקשרת את המפתחות האלה לספריות האלה.

באנדרואיד 11 ומעלה, מדיניות ההצפנה כבר לא מקודדת למיקום מרכזי, אלא מוגדרת על ידי ארגומנטים לפקודות mkdir בסקריפטים של init. ספריות מוצפנות עם מפתח DE של המערכת משתמשות encryption=Require , בעוד ספריות לא מוצפנות (או ספריות שספריות המשנה שלהן מוצפנות עם מפתחות לכל משתמש) משתמשות encryption=None .

באנדרואיד 10, מדיניות ההצפנה קודדה במיקום זה:

/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 מדור קודם, הדורש שחזור כדי לגשת לקובץ 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, עיין בתיעוד הליבה במעלה הזרם .

גזירת מפתח

מפתחות הצפנה מבוססי קבצים, שהם מפתחות של 512 סיביות, מאוחסנים מוצפנים על ידי מפתח אחר (מפתח AES-GCM של 256 סיביות) המוחזק ב-TEE. כדי להשתמש במפתח TEE זה, יש לעמוד בשלוש דרישות:

  • אסימון ההסמכה
  • האישור המתוח
  • "האש הניתן לביטול"

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

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

ה- secdiscardable hash הוא 512 סיביות של קובץ אקראי בגודל 16 KB המאוחסן לצד מידע אחר המשמש לשחזור המפתח, כגון ה-Seed. קובץ זה נמחק בצורה מאובטחת כאשר המפתח נמחק, או שהוא מוצפן בצורה חדשה; הגנה נוספת זו מבטיחה שתוקף חייב לשחזר כל חלק מהקובץ שנמחק בצורה מאובטחת כדי לשחזר את המפתח. זה קשור קריפטוגרפית למפתח ב-TEE עם כל הערבויות החלות על KM_TAG_APPLICATION_ID .

ברוב המקרים מפתחות FBE עוברים גם שלב גזירת מפתח נוסף בקרנל על מנת ליצור את מפתחות המשנה המשמשים בפועל לביצוע ההצפנה, למשל מפתחות לפי קובץ או לפי מצב. עבור מדיניות הצפנה של גרסה 2, נעשה שימוש ב-HKDF-SHA512.