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

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

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

אתחול ישיר

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תלות

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

  • תמיכת Kernel עבור הצפנת Ext4 או הצפנת F2FS.
  • תמיכת Keymaster עם גרסת HAL 1.0 או 2.0. אין תמיכה ב- Keymaster 0.3 מכיוון שזה לא מספק את היכולות הדרושות או מבטיח הגנה מספקת על מפתחות הצפנה.
  • Keymaster / Keystore ושומר הסף חייב להיות מיושם Trusted Execution Environment (TEE) כדי לספק הגנה עבור מפתחות DE כך מערכת הפעלה לא מורשית (OS מנהג הבזיק על המכשיר) לא יכול פשוט לבקש את המפתחות DE.
  • חומרת Root of Trust וההפעלה מאומתת המאוגדים אתחול keymaster נדרש כדי להבטיח כי אישורי הצפנת מכשיר אינו נגישים על ידי מערכת הפעלה מורשה.

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

יישום

בראש ובראשונה, ליישומים כמו שעונים מעוררים, טלפון, תכונות נגישות צריכות להיעשות אנדרואיד: directBootAware פי 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-cts אם contents_encryption_mode הוא aes-256-xts , או כדי adiantum אם contents_encryption_mode הוא adiantum .
  • flags הפרמטר, חדשות 11 אנדרואיד, הוא רשימה של דגלים מופרדים על ידי + האופי. הדגלים הבאים נתמכים:
    • v1 מדיניות הצפנת גרסת 1 בוחר בדגל; v2 מדיניות הצפנה בוחר בדגל גרסה 2. מדיניות הצפנה 2 הגרסה להשתמש בטוחה וגמישה יותר פונקצית גזירת מפתח . ברירת המחדל היא v2 אם המכשיר הושק על אנדרואיד 11 ומעלה (כפי שנקבע על ידי ro.product.first_api_level ), או v1 אם המכשיר הושק על אנדרואיד 10 או להנמיך.
    • inlinecrypt_optimized הדגל בוחר בפורמט הצפנה כי הוא אופטימיזציה עבור חומרת הצפנה מוטבע כי אינו מטפל במספר גדול של מפתחות ביעילות. הוא עושה זאת על ידי הפקת מפתח הצפנה אחד של תוכן קובץ לכל מפתח CE או DE, ולא אחד לכל קובץ. הדור של IVs (וקטורי אתחול) מותאם בהתאם.
    • emmc_optimized דגל דומה inlinecrypt_optimized , אבל זה גם בוחר שיטה הדור הרביעי כי האינפוזיות גבולות 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 .

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

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

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

  • ro.crypto.volume.options (חדשות אנדרואיד 11) בוחר בפורמט הצפנה FBE על אחסון לאימוץ. יש לו את אותה תחביר כויכוח אל fileencryption אפשרות fstab, והיא משתמשת באותו המחדל. ראה המלצות 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 חייב להיות מוכן לטפל בבקשות. בהתקנים פיקסל, זה מטופל על ידי בעל בלוק תסריט להבטיח Keymaster הוא התחיל לפני /data מותקנים.

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

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

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

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

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

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

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

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

פרטי יישום AOSP

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

הצפנה fscrypt

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

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

הצפנה שֵׂעַרוֹת שׁוּלָמִית נתמכת גם. כאשר הצפנת Adiantum מופעלת, תוכן הקבצים ושמות הקבצים מוצפנים באמצעות Adiantum.

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

גזירת מפתח

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

  • אסימון האימות
  • האישור המתוח
  • "החשיש שניתן למחוק"

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

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

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

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