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

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

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

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

הפעלה ישירה

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

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

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

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

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

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

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

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

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

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

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

• חייגן AOSP (חבילות/אפליקציות/חייגן)
• שעון שולחני (חבילות/אפליקציות/DeskClock)
• לטיניתIME (חבילות/שיטות קלט/שיטות לטיניות)*
• אפליקציית ההגדרות (חבילות/אפליקציות/הגדרות)*
• SystemUI (frameworks/base/packages/SystemUI)*

* אפליקציות מערכת שמשתמשות ברכיב defaultToDeviceProtectedStorage מאפיין מניפסט

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

יחסי תלות

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

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

הטמעה

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

תמיכה בליבה

תמיכה בליבה (kernel) להצפנה של Ext4 ו-F2FS זמינה בגרסה המשותפת של Android kernels, גרסה 3.18 ואילך. כדי להפעיל אותו בליבה (kernel) שבגרסה 5.1 ומעלה, יש להשתמש ב:

CONFIG_FS_ENCRYPTION=y

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

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

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

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

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

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. מאז Android 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, חדש ב-Android 11 הוא רשימה של דגלים שמופרדים באמצעות תו אחד (+). הדגלים הבאים נתמכים:
  • הדגל v1 בוחר מדיניות הצפנה בגרסה 1. ה הדגל v2 בוחר במדיניות ההצפנה בגרסה 2. גרסה 2 כללי מדיניות הצפנה משתמשים בפונקציה נגזרת מפתחות מאובטחת וגמישה יותר. ברירת המחדל היא גרסה 2 אם המכשיר הושק ב-Android מגרסה 11 ואילך (כפי שנקבע על ידי ro.product.first_api_level), או גרסה 1 אם במכשיר שהושק ב-Android 10 או נמוכה יותר.
  • הדגל inlinecrypt_optimized בוחר הצפנה שמותאם לחומרה של הצפנה מוטבעת, לטפל ביעילות במספר גדול של מפתחות. היא עושה זאת באמצעות רק מפתח אחד להצפנת תוכן של קבצים לכל מפתח CE או DE, במקום אחת לכל קובץ. היצירה של IVs (וקטורים של אתחול) היא תותאם בהתאם.
  • הדגל emmc_optimized דומה ל- inlinecrypt_optimized, אבל הוא גם בוחר IV שמגבילה את ה-IV ל-32 ביטים. הדגל הזה צריך רק בחומרת הצפנה מוטבעת שתואמת ל מפרט JEDEC eMMC גרסה 5.2 ולכן תומך רק ב-32 סיביות עיריות. בחומרה אחרת להצפנה מוטבעת, משתמשים יש גם אפשרות inlinecrypt_optimized. הסימון הזה לעולם לא לשימוש באחסון מבוסס-UFS. מפרט UFS מאפשר להשתמש של קלטות IV 64 ביט.
  • במכשירים שתומכים באריזה של חומרה מפתחות, הדגל wrappedkey_v0 מאפשר את השימוש מפתחות עטופים בחומרה ל-FBE. אפשר להשתמש באפשרות הזו רק בשילוב עם אפשרות הטעינה inlinecrypt, וגם inlinecrypt_optimized או emmc_optimized לסמן.
  • הדגל dusize_4k אוכף את גודל יחידת הנתונים של ההצפנה להיות 4096 בייטים גם כשגודל הבלוק של מערכת הקבצים הוא לא 4096 בייטים. הגודל של יחידת הנתונים להצפנה הוא רמת הפירוט של הקובץ הצפנת תוכן. הסימון הזה זמין החל מ-Android 15 (AOSP ניסיוני). יש להשתמש בסימון הזה רק כדי להפעיל שימוש בחומרת הצפנה מוטבעת שאינה תומכת בנתונים יחידות גדולות מ-4,096 בייטים, במכשיר שמשתמש בגודל דף גדול מ-4,096 בייטים ומשתמש במערכת הקבצים f2fs.

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

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

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

כברירת מחדל, הצפנת תוכן הקבצים מתבצעת באמצעות ליבה (kernel) של Linux cryptography 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

אחסון מותאם

מאז Android 9, FBE ו- אפשר להשתמש בנפח אחסון מותאם ביחד.

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

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

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

במכשירים עם Android מגרסה 10 ומטה, משתמשים המאפיינים הבאים:

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

שילוב עם Keymaster

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

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

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

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

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

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

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

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

תמיכה במשתמשים מרובים

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

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

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

לכל מזהה משתמש של פרופיל עבודה יש גם שני מפתחות: 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.

אם במכשיר פועלת מערכת Android מגרסה 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

בנוסף, בודקים יכולים לוודא שאחסון ה-CE נעול לפני שהמכשיר בוטלה בפעם הראשונה מאז האתחול. כדי לעשות את זה, משתמשים userdebug או eng בונים, מגדירים קוד אימות, קו ביטול נעילה או הסיסמה של המשתמש הראשי ולהפעיל מחדש את המכשיר. לפני שמבטלים את הנעילה של המכשיר, מריצים את הפקודה הבאה כדי לבדוק את אחסון ה-CE של המשתמש הראשי. אם המכשיר משתמש במערכת ללא GUI במצב משתמש (רוב המכשירים בסוכנויות רכב), המשתמש הראשי הוא משתמש 10. לכן צריך להריץ את הפקודה:

adb root; adb shell ls /data/user/10

במכשירים אחרים (רוב המכשירים שהם לא כלי רכב), המשתמש הראשי הוא משתמש 0, לכן לרוץ:

adb root; adb shell ls /data/user/0

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

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

פרטי ההטמעה של AOSP

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

הצפנת fscrypt

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

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

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

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

מידע נוסף על fscrypt זמין במסמכי הליבה של תוכנית ה-upstream.

סוגי אחסון (storage classes)

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

אחסון מפתחות והגנה עליהם

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

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

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

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

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

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

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

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

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