رمزگذاری مبتنی بر فایل

اندروید 7.0 و بالاتر از رمزگذاری مبتنی بر فایل (FBE) پشتیبانی می کند. رمزگذاری مبتنی بر فایل اجازه می دهد تا فایل های مختلف با کلیدهای مختلف رمزگذاری شوند که می توانند به طور مستقل باز شوند.

این مقاله نحوه فعال کردن رمزگذاری مبتنی بر فایل را در دستگاه‌های جدید و نحوه استفاده از برنامه‌های سیستمی از Direct Boot API برای ارائه بهترین و ایمن‌ترین تجربه ممکن به کاربران شرح می‌دهد.

همه دستگاه‌هایی که با Android 10 و بالاتر راه‌اندازی می‌شوند باید از رمزگذاری مبتنی بر فایل استفاده کنند.

بوت مستقیم

رمزگذاری مبتنی بر فایل ویژگی جدیدی را فعال می‌کند که در اندروید ۷.۰ به نام Direct Boot معرفی شده است. راه‌اندازی مستقیم به دستگاه‌های رمزگذاری‌شده اجازه می‌دهد مستقیماً روی صفحه قفل راه‌اندازی شوند. پیش از این، در دستگاه‌های رمزگذاری‌شده با استفاده از رمزگذاری فول دیسک (FDE)، کاربران باید قبل از دسترسی به داده‌ها، اعتبارنامه‌هایی را ارائه می‌کردند که از انجام همه عملیات به جز ابتدایی‌ترین عملیات توسط تلفن جلوگیری می‌کرد. برای مثال، آلارم‌ها نمی‌توانستند کار کنند، خدمات دسترسی در دسترس نبودند، و تلفن‌ها نمی‌توانستند تماس‌ها را دریافت کنند، اما فقط به عملیات اولیه شماره‌گیر اضطراری محدود بودند.

با معرفی رمزگذاری مبتنی بر فایل (FBE) و API های جدید برای آگاه کردن برنامه ها از رمزگذاری، این امکان وجود دارد که این برنامه ها در یک زمینه محدود عمل کنند. این ممکن است قبل از اینکه کاربران اعتبار خود را ارائه دهند و در عین حال از اطلاعات خصوصی کاربر محافظت کنند، رخ دهد.

در یک دستگاه دارای FBE، هر کاربر دستگاه دارای دو مکان ذخیره سازی در دسترس برنامه ها است:

• فضای ذخیره‌سازی رمزگذاری‌شده اعتبار (CE)، که محل ذخیره‌سازی پیش‌فرض است و تنها پس از باز کردن قفل دستگاه توسط کاربر در دسترس است.
• ذخیره‌سازی رمزگذاری‌شده دستگاه (DE)، که یک مکان ذخیره‌سازی است که هم در حالت راه‌اندازی مستقیم و هم پس از باز کردن قفل دستگاه توسط کاربر در دسترس است.

این جداسازی پروفایل های کاری را ایمن تر می کند زیرا به بیش از یک کاربر اجازه می دهد در یک زمان محافظت شوند زیرا رمزگذاری دیگر صرفاً بر اساس رمز عبور زمان راه اندازی نیست.

Direct Boot API به برنامه های آگاه از رمزگذاری اجازه می دهد تا به هر یک از این مناطق دسترسی داشته باشند. تغییراتی در چرخه عمر برنامه وجود دارد تا نیاز به اطلاع دادن به برنامه‌ها را هنگام باز شدن قفل ذخیره‌سازی CE کاربر در پاسخ به اولین ورود اطلاعات کاربری در صفحه قفل یا در مورد نمایه کاری که یک چالش کاری ایجاد می‌کند، برآورده کند. دستگاه‌هایی که Android 7.0 را اجرا می‌کنند باید از این APIها و چرخه‌های عمر جدید بدون توجه به اینکه FBE را پیاده‌سازی کنند یا نه، پشتیبانی کنند. اگرچه بدون FBE، ذخیره سازی DE و CE همیشه در حالت قفل است.

اجرای کامل رمزگذاری مبتنی بر فایل در سیستم‌های فایل Ext4 و F2FS در پروژه منبع باز Android (AOSP) ارائه شده است و فقط باید در دستگاه‌هایی فعال شود که شرایط لازم را دارند. سازندگانی که استفاده از FBE را انتخاب می‌کنند می‌توانند راه‌های بهینه‌سازی ویژگی را بر اساس سیستم روی تراشه (SoC) مورد استفاده بررسی کنند.

تمام بسته های لازم در AOSP به روز شده اند تا از راه اندازی مستقیم آگاه شوند. با این حال، در جایی که سازندگان دستگاه از نسخه‌های سفارشی‌شده این برنامه‌ها استفاده می‌کنند، می‌خواهند حداقل اطمینان حاصل کنند که بسته‌های آگاه از راه‌اندازی مستقیم خدمات زیر را ارائه می‌دهند:

• خدمات تلفنی و شماره گیر
• روش ورودی برای وارد کردن رمزهای عبور در صفحه قفل

مثال ها و منبع

Android یک پیاده سازی مرجع از رمزگذاری مبتنی بر فایل ارائه می دهد که در آن vold ( system/vold ) عملکردی را برای مدیریت دستگاه های ذخیره سازی و حجم ها در Android ارائه می دهد. افزودن FBE چندین فرمان جدید را برای پشتیبانی از مدیریت کلید برای کلیدهای CE و DE چند کاربر برای ولد فراهم می کند. علاوه بر تغییرات اصلی برای استفاده از قابلیت‌های رمزگذاری مبتنی بر فایل در هسته ، بسیاری از بسته‌های سیستم از جمله صفحه قفل و SystemUI برای پشتیبانی از ویژگی‌های FBE و Direct Boot اصلاح شده‌اند. این موارد عبارتند از:

• شماره‌گیر AOSP (بسته‌ها/برنامه‌ها/شماره‌گیر)
• ساعت رومیزی (بسته ها/برنامه ها/ساعت رومیزی)
• LatinIME (بسته‌ها/روش‌های ورودی/LatinIME)*
• برنامه تنظیمات (بسته ها/برنامه ها/تنظیمات)*
• SystemUI (frameworks/base/packages/SystemUI)*

* برنامه های سیستمی که از ویژگی مانیفست defaultToDeviceProtectedStorage استفاده می کنند

با اجرای دستور mangrep directBootAware در فهرست فریمورک‌ها یا بسته‌های درخت منبع AOSP، می‌توانید نمونه‌های بیشتری از برنامه‌ها و سرویس‌هایی را که از رمزگذاری آگاه هستند، پیدا کنید.

وابستگی ها

برای استفاده ایمن از اجرای AOSP FBE، یک دستگاه باید وابستگی های زیر را برآورده کند:

• پشتیبانی از کرنل برای رمزگذاری Ext4 یا رمزگذاری F2FS.
• پشتیبانی از Keymaster با نسخه HAL 1.0 یا بالاتر. هیچ پشتیبانی از Keymaster 0.3 وجود ندارد، زیرا قابلیت های لازم را ارائه نمی دهد یا محافظت کافی برای کلیدهای رمزگذاری را تضمین نمی کند.
• Keymaster/ Keystore و Gatekeeper باید در یک محیط اجرای مورد اعتماد (TEE) پیاده سازی شوند تا از کلیدهای DE محافظت کنند تا یک سیستم عامل غیرمجاز (سیستم عامل سفارشی که روی دستگاه فلش شده است) نتواند به سادگی کلیدهای DE را درخواست کند.
• Hardware Root of Trust و Verified Boot متصل به مقداردهی اولیه Keymaster لازم است تا اطمینان حاصل شود که کلیدهای DE توسط یک سیستم عامل غیرمجاز قابل دسترسی نیستند.

پیاده سازی

اول از همه، برنامه‌هایی مانند ساعت زنگ دار، تلفن و ویژگی‌های دسترسی باید بر اساس مستندات توسعه دهنده Direct Boot Android:directBootAware ساخته شوند.

پشتیبانی از کرنل

پشتیبانی از کرنل برای رمزگذاری Ext4 و F2FS در هسته های رایج اندروید، نسخه 3.18 و بالاتر در دسترس است. برای فعال کردن آن در هسته ای که نسخه 5.1 یا بالاتر است، از:

CONFIG_FS_ENCRYPTION=y

برای هسته‌های قدیمی‌تر، اگر سیستم فایل userdata دستگاه شما Ext4 است، از CONFIG_EXT4_ENCRYPTION=y یا اگر سیستم فایل userdata دستگاهتان F2FS است، از CONFIG_F2FS_FS_ENCRYPTION=y استفاده کنید.

اگر دستگاه شما از فضای ذخیره‌سازی قابل قبول پشتیبانی می‌کند یا از رمزگذاری فراداده در حافظه داخلی استفاده می‌کند، گزینه‌های پیکربندی هسته مورد نیاز برای رمزگذاری ابرداده را نیز همانطور که در مستندات رمزگذاری فراداده توضیح داده شده، فعال کنید.

علاوه بر پشتیبانی عملکردی از رمزگذاری 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 باشد. اگر مشخص نشده باشد، اگر contents_encryption_mode aes-256-xts باشد، aes-256-cts پیش‌فرض می‌شود، یا اگر contents_encryption_mode adiantum باشد، به adiantum روی می‌دهد.
• پارامتر flags ، جدید در اندروید 11، لیستی از پرچم‌ها است که با کاراکتر + از هم جدا شده‌اند. پرچم های زیر پشتیبانی می شوند:
  • پرچم v1 سیاست های رمزگذاری نسخه 1 را انتخاب می کند. پرچم v2 خط مشی های رمزگذاری نسخه 2 را انتخاب می کند. خط‌مشی‌های رمزگذاری نسخه 2 از یک تابع مشتق کلید امن‌تر و انعطاف‌پذیرتر استفاده می‌کنند. اگر دستگاه با Android 11 یا بالاتر راه‌اندازی شده باشد، نسخه پیش‌فرض v2 است (همانطور که توسط ro.product.first_api_level تعیین شده است)، یا اگر دستگاه با Android 10 یا پایین‌تر راه‌اندازی شده باشد، v1 است.
  • پرچم inlinecrypt_optimized یک قالب رمزگذاری را انتخاب می‌کند که برای سخت‌افزار رمزگذاری درون خطی بهینه‌سازی شده است که تعداد زیادی کلید را به‌طور مؤثر مدیریت نمی‌کند. این کار را با استخراج فقط یک کلید رمزگذاری محتویات فایل در هر کلید CE یا DE انجام می دهد، نه یک کلید در هر فایل. تولید IV ها (بردارهای اولیه سازی) بر این اساس تنظیم می شود.
  • پرچم emmc_optimized مشابه inlinecrypt_optimized است، اما یک روش تولید IV را نیز انتخاب می کند که IV ها را به 32 بیت محدود می کند. این پرچم فقط باید روی سخت افزار رمزگذاری درون خطی استفاده شود که با مشخصات JEDEC eMMC v5.2 مطابقت دارد و بنابراین فقط از IV های 32 بیتی پشتیبانی می کند. در سایر سخت افزارهای رمزگذاری درون خطی، به جای آن inlinecrypt_optimized استفاده کنید. این پرچم هرگز نباید در فضای ذخیره سازی مبتنی بر UFS استفاده شود. مشخصات UFS امکان استفاده از IV های 64 بیتی را فراهم می کند.
  • در دستگاه‌هایی که از کلیدهای پیچیده‌شده با سخت‌افزار پشتیبانی می‌کنند، پرچم wrappedkey_v0 استفاده از کلیدهای سخت‌افزاری را برای FBE امکان‌پذیر می‌کند. این فقط می تواند در ترکیب با گزینه inlinecrypt mount و پرچم inlinecrypt_optimized یا emmc_optimized استفاده شود.
  • پرچم dusize_4k اندازه واحد داده های رمزگذاری را مجبور می کند تا 4096 بایت باشد حتی زمانی که اندازه بلوک سیستم فایل 4096 بایت نباشد. اندازه واحد داده‌های رمزنگاری، به صورت جزئی بودن رمزگذاری محتویات فایل است. این پرچم از Android 15 در دسترس است. این پرچم فقط باید برای فعال کردن استفاده از سخت افزار رمزگذاری درون خطی استفاده شود که از واحدهای داده بزرگتر از 4096 بایت پشتیبانی نمی کند، در دستگاهی که از اندازه صفحه بزرگتر از 4096 بایت استفاده می کند و از f2fs استفاده می کند. فایل سیستم

اگر از سخت افزار رمزگذاری درون خطی استفاده نمی کنید، تنظیم توصیه شده برای اکثر دستگاه ها fileencryption=aes-256-xts است. اگر از سخت‌افزار رمزگذاری درون خطی استفاده می‌کنید، تنظیمات توصیه‌شده برای اکثر دستگاه‌ها fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (یا معادل fileencryption=::inlinecrypt_optimized ) است. در دستگاه‌های بدون هیچ گونه شتاب AES، با تنظیم fileencryption=adiantum می‌توان از Adiantum به جای AES استفاده کرد.

از Android 14، AES-HCTR2 حالت ترجیحی رمزگذاری نام فایل برای دستگاه‌هایی است که دستورالعمل‌های رمزنگاری سریع دارند. با این حال، فقط هسته های جدیدتر اندروید از AES-HCTR2 پشتیبانی می کنند. در نسخه آینده اندروید، برنامه ریزی شده است که به حالت پیش فرض برای رمزگذاری نام فایل ها تبدیل شود. اگر هسته شما از AES-HCTR2 پشتیبانی می کند، می توان آن را برای رمزگذاری نام فایل ها با تنظیم filenames_encryption_mode روی aes-256-hctr2 فعال کرد. در ساده‌ترین حالت، این کار با fileencryption=aes-256-xts:aes-256-hctr2 انجام می‌شود.

در دستگاه‌هایی که با Android 10 یا پایین‌تر راه‌اندازی شده‌اند، fileencryption=ice نیز برای مشخص کردن استفاده از حالت رمزگذاری محتوای فایل FSCRYPT_MODE_PRIVATE پذیرفته می‌شود. این حالت توسط هسته‌های رایج اندروید اجرا نمی‌شود، اما می‌توان آن را توسط فروشندگان با استفاده از وصله‌های هسته سفارشی پیاده‌سازی کرد. قالب روی دیسک تولید شده توسط این حالت مخصوص فروشنده بود. در دستگاه‌هایی که با Android 11 یا بالاتر راه‌اندازی می‌شوند، این حالت دیگر مجاز نیست و باید به جای آن از قالب رمزگذاری استاندارد استفاده شود.

به طور پیش فرض، رمزگذاری محتویات فایل با استفاده از API رمزنگاری هسته لینوکس انجام می شود. اگر می خواهید به جای آن از سخت افزار رمزگذاری داخلی استفاده کنید، گزینه inlinecrypt mount را نیز اضافه کنید. به عنوان مثال، یک خط کامل 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 و ابرداده را در فضای ذخیره‌سازی قابل پذیرش فعال می‌کند. با این حال، می‌توانید با تنظیم ویژگی‌ها در PRODUCT_PROPERTY_OVERRIDES ، فرمت‌های رمزگذاری FBE یا فراداده را در فضای ذخیره‌سازی قابل قبول لغو کنید.

در دستگاه‌هایی که با Android 11 یا بالاتر راه‌اندازی شده‌اند، از ویژگی‌های زیر استفاده کنید:

• ro.crypto.volume.options (جدید در Android 11) قالب رمزگذاری FBE را در فضای ذخیره سازی قابل قبول انتخاب می کند. این سینتکس مشابه آرگومان گزینه fileencryption fstab دارد و از همان پیش‌فرض‌ها استفاده می‌کند. توصیه‌های مربوط به 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

Keymaster HAL باید به عنوان بخشی از کلاس early_hal راه اندازی شود. این به این دلیل است که FBE نیاز دارد که Keymaster آماده رسیدگی به درخواست‌ها در مرحله بوت post-fs-data باشد، که زمانی است که vold کلیدهای اولیه را تنظیم می‌کند.

فهرست ها را حذف کنید

init کلید سیستم DE را برای همه دایرکتوری های سطح بالای /data اعمال می کند، به جز دایرکتوری هایی که باید رمزگذاری نشده باشند، مانند دایرکتوری که حاوی خود کلید سیستم DE است و دایرکتوری هایی که حاوی دایرکتوری های CE یا DE کاربر هستند. کلیدهای رمزگذاری به صورت بازگشتی اعمال می‌شوند و نمی‌توانند توسط زیر شاخه‌ها لغو شوند.

در اندروید 11 و بالاتر، کلیدی که init برای دایرکتوری ها اعمال می شود را می توان با آرگومان encryption=<action> دستور mkdir در اسکریپت های init کنترل کرد. مقادیر ممکن <action> در README برای زبان Android init مستند شده است.

در اندروید 10، اقدامات رمزگذاری init در مکان زیر کدگذاری شد:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

در اندروید 9 و قبل از آن، مکان این بود:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

برای جلوگیری از رمزگذاری برخی دایرکتوری ها می توان استثناهایی اضافه کرد. اگر تغییراتی از این نوع انجام شود، سازنده دستگاه باید خط‌مشی‌های SELinux را لحاظ کند که فقط به برنامه‌هایی که نیاز به استفاده از دایرکتوری رمزگذاری نشده دارند، دسترسی می‌دهد. این باید همه برنامه‌های غیرقابل اعتماد را حذف کند.

تنها مورد استفاده قابل قبول شناخته شده برای این، پشتیبانی از قابلیت های OTA قدیمی است.

پشتیبانی از Direct Boot در برنامه های سیستم

برنامه ها را مستقیم بوت کنید

برای تسهیل مهاجرت سریع برنامه های سیستم، دو ویژگی جدید وجود دارد که می توانند در سطح برنامه تنظیم شوند. ویژگی defaultToDeviceProtectedStorage فقط برای برنامه های سیستم در دسترس است. ویژگی directBootAware برای همه در دسترس است.

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

ویژگی directBootAware در سطح برنامه مختصر برای علامت گذاری تمام اجزای برنامه به عنوان آگاه به رمزگذاری است.

ویژگی defaultToDeviceProtectedStorage مکان ذخیره سازی پیش فرض برنامه را به جای اشاره به حافظه CE به سمت ذخیره سازی DE هدایت می کند. برنامه‌های سیستمی که از این پرچم استفاده می‌کنند باید تمام داده‌های ذخیره‌شده در مکان پیش‌فرض را به دقت بررسی کنند و مسیرهای داده‌های حساس را برای استفاده از ذخیره‌سازی CE تغییر دهند. سازندگان دستگاه‌هایی که از این گزینه استفاده می‌کنند باید داده‌هایی را که ذخیره می‌کنند به دقت بررسی کنند تا مطمئن شوند که حاوی اطلاعات شخصی نیستند.

هنگام اجرا در این حالت، APIهای سیستم زیر برای مدیریت صریح یک Context با پشتوانه فضای ذخیره‌سازی CE در صورت نیاز در دسترس هستند که معادل مشابه‌های Device Protected خود هستند.

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

پشتیبانی از چندین کاربر

هر کاربر در یک محیط چند کاربره یک کلید رمزگذاری جداگانه دریافت می کند. هر کاربر دو کلید دریافت می کند: یک کلید DE و یک کلید CE. کاربر 0 باید ابتدا وارد دستگاه شود زیرا یک کاربر خاص است. این برای استفاده های مدیریت دستگاه مناسب است.

برنامه‌های Crypto-Aware بین کاربران به این شکل تعامل دارند: 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 را اجرا کنید.

اگر دستگاه دارای 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 build استفاده کنید، یک پین، الگو یا رمز عبور را روی کاربر اصلی تنظیم کنید و دستگاه را راه اندازی مجدد کنید. قبل از باز کردن قفل دستگاه، دستور زیر را اجرا کنید تا فضای ذخیره سازی CE کاربر اصلی را بررسی کنید. اگر دستگاه از حالت کاربر سیستم هدلس (اکثر دستگاه‌های خودرو) استفاده می‌کند، کاربر اصلی کاربر 10 است، بنابراین اجرا کنید:

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

در دستگاه‌های دیگر (اکثر دستگاه‌های غیرخودرو)، کاربر اصلی کاربر 0 است، بنابراین اجرا کنید:

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

بررسی کنید که نام فایل های فهرست شده با Base64 کدگذاری شده باشند، که نشان می دهد نام فایل ها رمزگذاری شده اند و کلید رمزگشایی آنها هنوز در دسترس نیست. اگر نام فایل ها در متن ساده فهرست شده باشند، مشکلی وجود دارد.

همچنین تولیدکنندگان دستگاه تشویق می‌شوند تا اجرای آزمایش‌های لینوکس بالادستی را برای fscrypt در دستگاه‌ها یا هسته‌های خود بررسی کنند. این تست ها بخشی از مجموعه تست فایل سیستم xfstests هستند. با این حال، این تست های بالادستی به طور رسمی توسط اندروید پشتیبانی نمی شوند.

جزئیات پیاده سازی AOSP

این بخش جزئیات پیاده سازی AOSP را ارائه می دهد و نحوه کار رمزگذاری مبتنی بر فایل را توضیح می دهد. برای استفاده از FBE و Direct Boot در دستگاه های خود، لازم نیست سازندگان دستگاه در اینجا تغییراتی ایجاد کنند.

رمزگذاری 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، به مستندات هسته بالادستی مراجعه کنید.

کلاس های ذخیره سازی

جدول زیر کلیدهای FBE و دایرکتوری هایی را که محافظت می کنند با جزئیات بیشتری فهرست می کند:

ذخیره و حفاظت کلید

تمام کلیدهای FBE توسط vold مدیریت می شوند و به صورت رمزگذاری شده روی دیسک ذخیره می شوند، به جز کلید هر بوت که اصلاً ذخیره نمی شود. جدول زیر مکان هایی را که کلیدهای مختلف FBE در آنها ذخیره می شود فهرست می کند:

همانطور که در جدول قبل نشان داده شده است، اکثر کلیدهای FBE در دایرکتوری هایی ذخیره می شوند که توسط یک کلید FBE دیگر رمزگذاری شده اند. قفل کلیدها تا زمانی که کلاس ذخیره سازی حاوی آنها باز نشده باشد، باز نمی شوند.

vold همچنین یک لایه رمزگذاری را برای همه کلیدهای FBE اعمال می کند. هر کلید علاوه بر کلیدهای CE برای حافظه داخلی با استفاده از کلید Keystore خودش که خارج از TEE قرار نمی گیرد، با AES-256-GCM رمزگذاری می شود. این تضمین می کند که کلیدهای FBE نمی توانند باز شوند مگر اینکه یک سیستم عامل قابل اعتماد بوت شده باشد، همانطور که توسط Verified Boot اعمال شده است. مقاومت برگشتی نیز در کلید Keystore درخواست می‌شود، که به کلیدهای FBE اجازه می‌دهد تا به طور ایمن در دستگاه‌هایی که Keymaster از مقاومت برگشتی پشتیبانی می‌کند حذف شوند. به عنوان بهترین تلاش برای زمانی که مقاومت برگشتی در دسترس نیست، هش SHA-512 از 16384 بایت تصادفی ذخیره شده در فایل secdiscardable ذخیره شده در کنار کلید به عنوان برچسب شناسه برنامه کلید Keystore استفاده می شود. همه این بایت ها برای بازیابی یک کلید FBE باید بازیابی شوند.

کلیدهای CE برای حافظه داخلی سطح حفاظتی قوی‌تری دریافت می‌کنند که تضمین می‌کند بدون اطلاع از ضریب دانش صفحه قفل کاربر (LSKF) (پین، الگو یا رمز عبور)، رمز بازنشانی رمز عبور امن یا هر دو سمت کلاینت، قفل آن‌ها باز نمی‌شوند. و کلیدهای سمت سرور برای عملیات Resume-on-Reboot . کدهای بازنشانی رمز عبور فقط برای نمایه‌های کاری و دستگاه‌های کاملاً مدیریت شده مجاز هستند.

برای رسیدن به این هدف، vold با استفاده از کلید AES-256-GCM که از رمز عبور مصنوعی کاربر مشتق شده است، هر کلید CE را برای حافظه داخلی رمزگذاری می کند. رمز عبور مصنوعی یک رمز رمزنگاری غیرقابل تغییر با آنتروپی بالا است که به طور تصادفی برای هر کاربر ایجاد می شود. LockSettingsService در system_server گذرواژه مصنوعی و روش‌های محافظت از آن را مدیریت می‌کند.

برای محافظت از رمز عبور مصنوعی با LSKF، LockSettingsService ابتدا LSKF را با عبور دادن آن از scrypt عبور می کند و زمان حدود 25 میلی ثانیه و مصرف حافظه حدود 2 مگابایت را هدف قرار می دهد. از آنجایی که LSKF ها معمولا کوتاه هستند، این مرحله معمولاً امنیت زیادی را فراهم نمی کند. لایه اصلی امنیت ، Secure Element (SE) یا محدودیت نرخ اعمال شده توسط TEE است که در زیر توضیح داده شده است.

اگر دستگاه دارای یک عنصر امن (SE) باشد، LockSettingsService با استفاده از Weaver HAL، LSKF کشیده شده را به یک راز تصادفی با آنتروپی بالا که در SE ذخیره شده است، نگاشت می کند. سپس LockSettingsService رمز عبور مصنوعی را دو بار رمزگذاری می‌کند: اول با یک کلید نرم‌افزاری که از LSKF کشیده شده و راز Weaver گرفته شده است، و دوم با یک کلید Keystore غیر مجاز. این محدودیت نرخ حدس‌های LSKF را با SE ارائه می‌کند.

اگر دستگاه SE ندارد، LockSettingsService به جای آن از LSKF کشیده شده به عنوان رمز عبور Gatekeeper استفاده می کند. سپس LockSettingsService رمز عبور مصنوعی را دو بار رمزگذاری می کند: اول با یک کلید نرم افزاری مشتق شده از LSKF کشیده شده و هش یک فایل غیرقابل حذف، و دوم با یک کلید Keystore که به ثبت نام Gatekeeper متصل است. این محدودیت نرخ حدس‌های LSKF را با استفاده از TEE فراهم می‌کند.

هنگامی که LSKF تغییر می کند، LockSettingsService تمام اطلاعات مرتبط با اتصال رمز عبور مصنوعی به LSKF قدیمی را حذف می کند. در دستگاه‌هایی که از کلیدهای «Weaver» یا «کلیدهای Keystore مقاوم در برابر برگشت» پشتیبانی می‌کنند، این امر حذف امن اتصال قدیمی را تضمین می‌کند. به همین دلیل، حفاظت هایی که در اینجا توضیح داده شده است حتی زمانی که کاربر LSKF ندارد اعمال می شود.

اندروید 7.0 و بالاتر از رمزگذاری مبتنی بر فایل (FBE) پشتیبانی می کند. رمزگذاری مبتنی بر فایل اجازه می دهد تا فایل های مختلف با کلیدهای مختلف رمزگذاری شوند که می توانند به طور مستقل باز شوند.

این مقاله نحوه فعال کردن رمزگذاری مبتنی بر فایل را در دستگاه‌های جدید و نحوه استفاده از برنامه‌های سیستمی از Direct Boot API برای ارائه بهترین و ایمن‌ترین تجربه ممکن به کاربران شرح می‌دهد.

همه دستگاه‌هایی که با Android 10 و بالاتر راه‌اندازی می‌شوند باید از رمزگذاری مبتنی بر فایل استفاده کنند.

بوت مستقیم

رمزگذاری مبتنی بر فایل ویژگی جدیدی را فعال می‌کند که در اندروید ۷.۰ به نام Direct Boot معرفی شده است. راه‌اندازی مستقیم به دستگاه‌های رمزگذاری‌شده اجازه می‌دهد مستقیماً روی صفحه قفل راه‌اندازی شوند. پیش از این، در دستگاه‌های رمزگذاری‌شده با استفاده از رمزگذاری فول دیسک (FDE)، کاربران باید قبل از دسترسی به داده‌ها، اعتبارنامه‌هایی را ارائه می‌کردند که از انجام همه عملیات به جز ابتدایی‌ترین عملیات توسط تلفن جلوگیری می‌کرد. برای مثال، آلارم‌ها نمی‌توانستند کار کنند، خدمات دسترسی در دسترس نبودند، و تلفن‌ها نمی‌توانستند تماس‌ها را دریافت کنند، اما فقط به عملیات اولیه شماره‌گیر اضطراری محدود بودند.

با معرفی رمزگذاری مبتنی بر فایل (FBE) و API های جدید برای آگاه کردن برنامه ها از رمزگذاری، این امکان وجود دارد که این برنامه ها در یک زمینه محدود عمل کنند. این ممکن است قبل از اینکه کاربران اعتبار خود را ارائه دهند و در عین حال از اطلاعات خصوصی کاربر محافظت کنند، رخ دهد.

در یک دستگاه دارای FBE، هر کاربر دستگاه دارای دو مکان ذخیره سازی در دسترس برنامه ها است:

• فضای ذخیره‌سازی رمزگذاری‌شده اعتبار (CE)، که محل ذخیره‌سازی پیش‌فرض است و تنها پس از باز کردن قفل دستگاه توسط کاربر در دسترس است.
• ذخیره‌سازی رمزگذاری‌شده دستگاه (DE)، که یک مکان ذخیره‌سازی است که هم در حالت راه‌اندازی مستقیم و هم پس از باز کردن قفل دستگاه توسط کاربر در دسترس است.

این جداسازی پروفایل های کاری را ایمن تر می کند زیرا به بیش از یک کاربر اجازه می دهد در یک زمان محافظت شوند زیرا رمزگذاری دیگر صرفاً بر اساس رمز عبور زمان راه اندازی نیست.

Direct Boot API به برنامه های آگاه از رمزگذاری اجازه می دهد تا به هر یک از این مناطق دسترسی داشته باشند. تغییراتی در چرخه عمر برنامه وجود دارد تا نیاز به اطلاع دادن به برنامه‌ها را هنگام باز شدن قفل ذخیره‌سازی CE کاربر در پاسخ به اولین ورود اطلاعات کاربری در صفحه قفل یا در مورد نمایه کاری که یک چالش کاری ایجاد می‌کند، برآورده کند. دستگاه‌هایی که Android 7.0 را اجرا می‌کنند باید از این APIها و چرخه‌های عمر جدید بدون توجه به اینکه FBE را پیاده‌سازی کنند یا نه، پشتیبانی کنند. اگرچه بدون FBE، ذخیره سازی DE و CE همیشه در حالت قفل است.

اجرای کامل رمزگذاری مبتنی بر فایل در سیستم‌های فایل Ext4 و F2FS در پروژه منبع باز Android (AOSP) ارائه شده است و فقط باید در دستگاه‌هایی فعال شود که شرایط لازم را دارند. سازندگانی که استفاده از FBE را انتخاب می‌کنند می‌توانند راه‌های بهینه‌سازی ویژگی را بر اساس سیستم روی تراشه (SoC) مورد استفاده بررسی کنند.

تمام بسته های لازم در AOSP به روز شده اند تا از راه اندازی مستقیم آگاه شوند. با این حال، در جایی که سازندگان دستگاه از نسخه‌های سفارشی‌شده این برنامه‌ها استفاده می‌کنند، می‌خواهند حداقل اطمینان حاصل کنند که بسته‌های آگاه از راه‌اندازی مستقیم خدمات زیر را ارائه می‌دهند:

• خدمات تلفنی و شماره گیر
• روش ورودی برای وارد کردن رمزهای عبور در صفحه قفل

مثال ها و منبع

Android یک پیاده سازی مرجع از رمزگذاری مبتنی بر فایل ارائه می دهد که در آن vold ( system/vold ) عملکردی را برای مدیریت دستگاه های ذخیره سازی و حجم ها در Android ارائه می دهد. افزودن FBE چندین فرمان جدید را برای پشتیبانی از مدیریت کلید برای کلیدهای CE و DE چند کاربر برای ولد فراهم می کند. علاوه بر تغییرات اصلی برای استفاده از قابلیت‌های رمزگذاری مبتنی بر فایل در هسته ، بسیاری از بسته‌های سیستم از جمله صفحه قفل و SystemUI برای پشتیبانی از ویژگی‌های FBE و Direct Boot اصلاح شده‌اند. این موارد عبارتند از:

• شماره‌گیر AOSP (بسته‌ها/برنامه‌ها/شماره‌گیر)
• ساعت رومیزی (بسته ها/برنامه ها/ساعت رومیزی)
• LatinIME (بسته‌ها/روش‌های ورودی/LatinIME)*
• برنامه تنظیمات (بسته ها/برنامه ها/تنظیمات)*
• SystemUI (frameworks/base/packages/SystemUI)*

* برنامه های سیستمی که از ویژگی مانیفست defaultToDeviceProtectedStorage استفاده می کنند

با اجرای دستور mangrep directBootAware در فهرست فریمورک‌ها یا بسته‌های درخت منبع AOSP، می‌توانید نمونه‌های بیشتری از برنامه‌ها و سرویس‌هایی را که از رمزگذاری آگاه هستند، پیدا کنید.

وابستگی ها

برای استفاده ایمن از اجرای AOSP FBE، یک دستگاه باید وابستگی های زیر را برآورده کند:

• پشتیبانی از کرنل برای رمزگذاری Ext4 یا رمزگذاری F2FS.
• پشتیبانی از Keymaster با نسخه HAL 1.0 یا بالاتر. هیچ پشتیبانی از Keymaster 0.3 وجود ندارد، زیرا قابلیت های لازم را ارائه نمی دهد یا محافظت کافی برای کلیدهای رمزگذاری را تضمین نمی کند.
• Keymaster/ Keystore و Gatekeeper باید در یک محیط اجرای مورد اعتماد (TEE) پیاده سازی شوند تا از کلیدهای DE محافظت کنند تا یک سیستم عامل غیرمجاز (سیستم عامل سفارشی که روی دستگاه فلش شده است) نتواند به سادگی کلیدهای DE را درخواست کند.
• Hardware Root of Trust و Verified Boot متصل به مقداردهی اولیه Keymaster لازم است تا اطمینان حاصل شود که کلیدهای DE توسط یک سیستم عامل غیرمجاز قابل دسترسی نیستند.

پیاده سازی

اول و مهمتر از همه ، برنامه هایی مانند ساعت زنگ دار ، تلفن و ویژگی های دسترسی باید Android ساخته شوند: DirectBootaware مطابق مستندات Direct Boot Developer.

پشتیبانی هسته

پشتیبانی هسته برای رمزگذاری EXT4 و F2FS در هسته های مشترک Android ، نسخه 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

برای بهبود بیشتر عملکرد و کاهش مصرف برق ، تولید کنندگان دستگاه نیز ممکن است اجرای سخت افزار رمزگذاری درون خطی را در نظر بگیرند ، که داده ها را رمزگذاری می کند/رمزگشایی می کند در حالی که در راه/از دستگاه ذخیره سازی است. هسته های مشترک Android (نسخه 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 باشد. از آنجا که Android 11 نیز می تواند برای مشخص کردن الگوریتم پیش فرض ، که aes-256-xts است ، خالی بماند.
• پارامتر filenames_encryption_mode تعریف می کند که کدام الگوریتم رمزنگاری برای رمزگذاری نام پرونده ها استفاده می شود. این می تواند aes-256-cts ، aes-256-heh ، adiantum یا aes-256-hctr2 باشد. اگر مشخص نشده باشد ، اگر contents_encryption_mode aes-256-xts باشد ، یا به adiantum اگر contents_encryption_mode adiantum باشد ، به aes-256-cts پیش فرض می شود.
• پارامتر flags ، New in Android 11 ، لیستی از پرچم ها است که توسط شخصیت + از هم جدا شده اند. پرچم های زیر پشتیبانی می شوند:
  • پرچم v1 سیاست های رمزگذاری نسخه 1 را انتخاب می کند. پرچم v2 سیاست های رمزگذاری نسخه 2 را انتخاب می کند. خط مشی های رمزگذاری نسخه 2 از یک عملکرد مشتق کلیدی امن تر و انعطاف پذیر تر استفاده می کنند. پیش فرض V2 است اگر دستگاه در Android 11 یا بالاتر راه اندازی شود (مطابق با ro.product.first_api_level ) یا V1 در صورت راه اندازی دستگاه در Android 10 یا پایین.
  • پرچم inlinecrypt_optimized یک قالب رمزگذاری را انتخاب می کند که برای سخت افزار رمزگذاری درون خطی بهینه شده است که تعداد زیادی از کلیدها را به طور کارآمد کنترل نمی کند. این کار را با استخراج فقط یک پرونده رمزگذاری محتوای پرونده در هر کلید یا کلید DE انجام می دهد ، نه یک پرونده. تولید IV (بردارهای اولیه سازی) بر این اساس تنظیم می شود.
  • پرچم emmc_optimized شبیه به inlinecrypt_optimized است ، اما همچنین یک روش تولید IV را انتخاب می کند که IVS را به 32 بیت محدود می کند. این پرچم فقط باید در سخت افزار رمزگذاری درون خطی که مطابق با مشخصات JEDEC EMMC V5.2 است استفاده شود و بنابراین فقط IV 32 بیتی را پشتیبانی می کند. در سایر سخت افزار رمزگذاری درون خطی ، به جای آن از inlinecrypt_optimized استفاده کنید. این پرچم هرگز نباید در ذخیره سازی مبتنی بر UFS استفاده شود. مشخصات UFS امکان استفاده از IV 64 بیتی را فراهم می کند.
  • در دستگاه هایی که از کلیدهای پیچیده شده با سخت افزار پشتیبانی می کنند ، پرچم wrappedkey_v0 استفاده از کلیدهای پیچیده شده سخت افزاری برای FBE را امکان پذیر می کند. این فقط می تواند در ترکیب با گزینه inlinecrypt Mount ، و یا پرچم inlinecrypt_optimized یا emmc_optimized استفاده شود.
  • پرچم dusize_4k اندازه واحد داده رمزگذاری را مجبور می کند 4096 بایت باشد حتی اگر اندازه بلوک سیستم فایل 4096 بایت نباشد. اندازه واحد داده رمزگذاری ، دانه بندی محتوای فایل رمزگذاری است. این پرچم از Android 15 در دسترس است. این پرچم فقط باید برای استفاده از سخت افزار رمزگذاری درون خطی که از واحدهای داده بزرگتر از 4096 بایت پشتیبانی نمی کند ، استفاده شود ، بر روی دستگاهی که از اندازه صفحه بزرگتر از 4096 بایت استفاده می کند و از F2FS استفاده می کند فایل سیستم

اگر از سخت افزار رمزگذاری Inline استفاده نمی کنید ، تنظیم توصیه شده برای اکثر دستگاه ها fileencryption=aes-256-xts است. اگر از سخت افزار رمزگذاری درون خطی استفاده می کنید ، تنظیمات توصیه شده برای اکثر دستگاه ها fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (یا به طور معادل fileencryption=::inlinecrypt_optimized ). در دستگاه های بدون هیچ نوع شتاب AES ، می توان به جای AES با تنظیم fileencryption=adiantum Adiantum به جای AES استفاده کرد.

از آنجا که Android 14 ، AES-HCTR2 حالت ارجح رمزگذاری نام های پرونده برای دستگاه هایی با دستورالعمل های رمزنگاری شتاب است. با این حال ، فقط هسته های اندرویدی جدیدتر از AES-HCTR2 پشتیبانی می کنند. در نسخه آینده اندرویدی ، برنامه ریزی شده است که به حالت پیش فرض رمزگذاری نام های پرونده تبدیل شود. اگر هسته شما دارای پشتیبانی AES-HCTR2 است ، می توان با تنظیم filenames_encryption_mode به aes-256-hctr2 ، برای رمزگذاری نام پرونده ها فعال شد. در ساده ترین حالت این کار با fileencryption=aes-256-xts:aes-256-hctr2 .

در دستگاه هایی که با Android 10 یا Lower راه اندازی شده اند ، fileencryption=ice نیز پذیرفته شده است تا استفاده از حالت رمزگذاری محتوای پرونده FSCRYPT_MODE_PRIVATE را مشخص کند. این حالت توسط هسته های مشترک Android مورد بررسی قرار نمی گیرد ، اما می تواند توسط فروشندگان با استفاده از تکه های هسته سفارشی پیاده سازی شود. فرمت روی دیسک تولید شده توسط این حالت خاص فروشنده بود. در دستگاه هایی که با Android 11 یا بالاتر راه اندازی می شوند ، این حالت دیگر مجاز نیست و به جای آن باید از قالب رمزگذاری استاندارد استفاده شود.

به طور پیش فرض ، رمزگذاری محتوای پرونده با استفاده از رمزنگاری هسته لینوکس API انجام می شود. اگر می خواهید به جای آن از سخت افزار رمزگذاری درون خطی استفاده کنید ، گزینه Mount 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 و ابرداده را در ذخیره سازی قابل قبول امکان پذیر می کند. با این حال ، شما می توانید با تنظیم خواص در PRODUCT_PROPERTY_OVERRIDES قالبهای رمزگذاری FBE یا ابرداده را در ذخیره سازی قابل قبول بر روی آن نادیده بگیرید.

در دستگاه هایی که با Android 11 یا بالاتر راه اندازی شده اند ، از خواص زیر استفاده کنید:

• ro.crypto.volume.options (جدید در Android 11) قالب رمزگذاری FBE را در ذخیره سازی قابل قبول انتخاب می کند. این نحو مشابه آرگومان گزینه fileencryption FSTAB است و از همان پیش فرض استفاده می کند. توصیه های 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 است ، به جز این که پیش فرض دستگاه هایی که با اندروید 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 کلید System de de را برای کلیه دایرکتوری های سطح بالا /data اعمال می کند ، به جز دایرکتوری هایی که باید رمزگذاری نشده باشند مانند دایرکتوری که شامل خود کلید سیستم و دایرکتوری است که شامل کاربری CE یا دایرکتوری های DE هستند. کلیدهای رمزگذاری به صورت بازگشتی اعمال می شوند و نمی توانند توسط زیر مجموعه ها نادیده بگیرند.

در Android 11 و بالاتر ، کلید init که برای دایرکتوری ها اعمال می شود ، می تواند توسط آرگومان encryption=<action> به دستور mkdir در اسکریپت های INIT کنترل شود. مقادیر احتمالی <action> در README برای زبان Android Init ثبت شده است.

در 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 اشاره کند ، در ذخیره سازی DE به نقطه ذخیره شود. برنامه های سیستم با استفاده از این پرچم باید تمام داده های ذخیره شده در محل پیش فرض را با دقت حسابرسی کنند و مسیرهای داده های حساس را برای استفاده از ذخیره سازی CE تغییر دهند. تولید دستگاه ها با استفاده از این گزینه باید با دقت از داده هایی که در آن ذخیره می کنند ، برای اطمینان از عدم وجود اطلاعات شخصی استفاده کنند.

هنگام کار در این حالت ، API های سیستم زیر برای مدیریت صریح زمینه ای که در صورت نیاز توسط ذخیره سازی CE پشتیبانی می شود ، که معادل همتایان محافظت شده توسط دستگاه آنها است ، در دسترس هستند.

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

از چندین کاربر پشتیبانی کنید

هر کاربر در یک محیط چند کاربره یک کلید رمزگذاری جداگانه دریافت می کند. هر کاربر دو کلید دریافت می کند: یک کلید DE و یک CE. کاربر 0 باید ابتدا وارد دستگاه شود زیرا یک کاربر خاص است. این مربوط به کاربردهای مدیریت دستگاه است.

برنامه های Crypto-Aware به این روش در بین کاربران تعامل دارند: INTERACT_ACROSS_USERS و INTERACT_ACROSS_USERS_FULL به یک برنامه اجازه می دهد تا در تمام کاربران دستگاه عمل کند. با این حال ، این برنامه ها فقط می توانند برای کاربرانی که قبلاً قفل نشده اند ، به دایرکتوری های رمزگذاری شده CE دسترسی پیدا کنند.

یک برنامه ممکن است بتواند آزادانه در مناطق DE تعامل داشته باشد ، اما یک کاربر قفل نشده به معنای این نیست که همه کاربران دستگاه قفل نشده اند. برنامه قبل از تلاش برای دسترسی به این مناطق باید این وضعیت را بررسی کند.

هر شناسه کاربر مشخصات کار همچنین دو کلید دریافت می کند: DE و CE. هنگامی که چالش کار برآورده شد ، کاربر پروفایل قفل می شود و KeyMaster (در TEE) می تواند کلید TEE پروفایل را ارائه دهد.

به روزرسانی ها

پارتیشن بازیابی قادر به دسترسی به ذخیره سازی محافظت شده در پارتیشن UserData نیست. دستگاه های اجرای FBE به شدت توصیه می شوند OTA را با استفاده از به روزرسانی های سیستم A/B پشتیبانی کنند. از آنجا که OTA می تواند در حین کار عادی اعمال شود ، نیازی به بازیابی برای دسترسی به داده ها در درایو رمزگذاری شده نیست.

هنگام استفاده از راه حل OTA میراث ، که برای دسترسی به پرونده OTA در پارتیشن userdata نیاز به بازیابی دارد:

1. در پارتیشن userdata یک دایرکتوری سطح بالا (به عنوان مثال misc_ne ) ایجاد کنید.
2. این دایرکتوری سطح بالا را برای رمزگذاری تنظیم کنید (به دایرکتوری های استثنا مراجعه کنید).
3. برای نگه داشتن بسته های OTA یک فهرست در فهرست سطح بالا ایجاد کنید.
4. برای کنترل دسترسی به این فهرست و محتویات IT ، یک قانون 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 Build استفاده کنید ، یک پین ، الگوی یا رمز عبور را روی کاربر اصلی تنظیم کرده و دستگاه را راه اندازی مجدد کنید. قبل از باز کردن قفل دستگاه ، دستور زیر را اجرا کنید تا ذخیره CE کاربر اصلی را بررسی کنید. اگر دستگاه از حالت کاربر سیستم بدون سر (بیشتر دستگاه های خودرو) استفاده می کند ، کاربر اصلی کاربر 10 است ، بنابراین اجرا کنید:

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

در دستگاه های دیگر (بیشتر دستگاه های غیر بیاهد) ، کاربر اصلی کاربر 0 است ، بنابراین اجرا کنید:

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

تأیید کنید که نام های لیست ذکر شده دارای رمزگذاری BASE64 هستند ، نشان می دهد که نام پرونده ها رمزگذاری شده اند و کلید رمزگشایی آنها هنوز در دسترس نیست. اگر نام های پرونده در متن ساده ذکر شده باشد ، چیزی اشتباه است.

تولید کنندگان دستگاه همچنین تشویق می شوند تا آزمایشات لینوکس بالادست را برای FSCRYPT در دستگاه های خود یا هسته های خود کشف کنند. این آزمایشات بخشی از مجموعه تست سیستم XFSTESTS است. با این حال ، این تست های بالادست به طور غیرقانونی توسط Android پشتیبانی نمی شوند.

جزئیات اجرای 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 سازگار است. کلیدهای رمزگذاری از کلیدهای تهیه شده از فضای کاربری.

برای اطلاعات بیشتر در مورد FSCRYPT ، به اسناد هسته بالادست مراجعه کنید.

کلاس های ذخیره سازی

در جدول زیر کلیدهای FBE و دایرکتوری که آنها با جزئیات بیشتری از آنها محافظت می کنند ذکر شده است:

ذخیره و حفاظت کلیدی

تمام کلیدهای FBE توسط vold اداره می شوند و به جز کلید هر بوت که به هیچ وجه ذخیره نمی شود ، روی دیسک رمزگذاری شده ذخیره می شوند. در جدول زیر مکانهایی که کلیدهای مختلف FBE در آن ذخیره شده اند ، لیست شده است:

همانطور که در جدول قبلی نشان داده شده است ، بیشتر کلیدهای FBE در دایرکتوری هایی که توسط یک کلید FBE دیگر رمزگذاری می شوند ذخیره می شوند. کلیدها تا زمانی که کلاس ذخیره ای که حاوی آنها باشد قفل نشده است ، نمی توانند قفل شوند.

vold همچنین لایه ای از رمزگذاری را برای همه کلیدهای FBE اعمال می کند. هر کلید علاوه بر کلیدهای CE برای ذخیره سازی داخلی با استفاده از کلید اصلی خود با AES-256-GCM رمزگذاری می شود که در خارج از TEE قرار نگرفته است. این تضمین می کند که کلیدهای FBE نمی توانند قفل شوند ، مگر اینکه یک سیستم عامل قابل اعتماد بوت شود ، همانطور که توسط بوت تأیید شده اجرا می شود. مقاومت در برابر بازگشت نیز در کلید Keystore درخواست می شود ، که به FBE Keys اجازه می دهد تا به طور ایمن در دستگاه هایی که Keymaster از مقاومت در برابر برگشت برگشت استفاده می کند ، به طور ایمن حذف شوند. به عنوان یک بازگشت بهترین تلاش برای هنگامی که مقاومت در برابر بازگشت در دسترس نیست ، هش SHA-512 از 16384 بایت تصادفی ذخیره شده در پرونده secdiscardable ذخیره شده در کنار کلید به عنوان برچسب شناسه برنامه کلید کلید استفاده می شود. برای بازیابی یک کلید FBE ، تمام این بایت ها باید بازیابی شوند.

کلیدهای CE برای ذخیره سازی داخلی سطح محافظت قوی تری دریافت می کنند که تضمین می کند بدون دانستن فاکتور دانش صفحه قفل کاربر (LSKF) (پین ، الگوی یا رمز عبور) ، یک نشانه تنظیم مجدد رمز عبور یا هر دو طرف مشتری ، آنها را نمی توان باز کرد. و کلیدهای سمت سرور برای یک عملیات رزومه روی رزومه . نشانه های تنظیم مجدد رمز عبور فقط مجاز به ایجاد پروفایل کار و دستگاه های کاملاً مدیریت شده هستند.

برای دستیابی به این هدف ، vold هر کلید CE را برای ذخیره داخلی با استفاده از یک کلید AES-256-GCM که از رمز عبور مصنوعی کاربر گرفته شده است ، رمزگذاری می کند. گذرواژه مصنوعی یک راز رمزنگاری آنتروپی بالا غیرقابل تغییر است که به طور تصادفی برای هر کاربر تولید می شود. LockSettingsService در system_server رمز عبور مصنوعی و روش های محافظت از آن را مدیریت می کند.

برای محافظت از رمز عبور مصنوعی با LSKF ، LockSettingsService ابتدا LSKF را با عبور از آن از طریق scrypt کشیده می شود ، زمان حدود 25 میلی ثانیه و استفاده از حافظه در حدود 2 MIB را هدف قرار می دهد. از آنجا که LSKF ها معمولاً کوتاه هستند ، این مرحله معمولاً امنیت زیادی را فراهم نمی کند. لایه اصلی امنیت عنصر ایمن (SE) یا Ratelimiting تقویت شده با TEE است که در زیر شرح داده شده است.

اگر دستگاه دارای یک عنصر ایمن (SE) باشد ، سپس LockSettingsService LSKF کشیده شده را به یک راز تصادفی آنتروپی بالا که در SE با استفاده از Weaver HAL ذخیره می شود ، نقشه می کند. LockSettingsService سپس رمز عبور مصنوعی را دو بار رمزگذاری می کند: ابتدا با یک کلید نرم افزاری که از LSKF کشیده و راز بافنده گرفته شده است ، و دوم با یک کلید کلید اصلی غیرقانونی. این امر باعث می شود که موشهای صحرایی تقویت شده SE از حدس های LSKF باشد.

اگر دستگاه SE ندارد ، در عوض LockSettingsService از LSKF کشیده شده به عنوان رمز عبور دروازه بان استفاده می کند. LockSettingsService سپس رمز عبور مصنوعی را دو بار رمزگذاری می کند: ابتدا با یک کلید نرم افزاری که از LSKF کشیده شده و هش یک پرونده secDiscardable مشتق شده است ، و دوم با یک کلید کلیدی که به ثبت نام دروازه بان است. این امر باعث می شود که موشهای صحرایی تقویت شده از حدس های LSKF باشد.

هنگامی که LSKF تغییر کرد ، LockSettingsService تمام اطلاعات مرتبط با اتصال رمز عبور مصنوعی را به LSKF قدیمی حذف می کند. در دستگاه هایی که از کلیدهای کلید اصلی بافنده یا مقاوم در برابر بازپرداخت پشتیبانی می کنند ، این تضمین حذف ایمن اتصال قدیمی است. به همین دلیل ، محافظت هایی که در اینجا شرح داده شده است حتی اگر کاربر LSKF نداشته باشد ، اعمال می شود.

Android 7.0 و بالاتر از رمزگذاری مبتنی بر پرونده (FBE) پشتیبانی می کند. رمزگذاری مبتنی بر پرونده اجازه می دهد تا پرونده های مختلف با کلیدهای مختلف رمزگذاری شوند که می توانند به طور مستقل قفل شوند.

در این مقاله نحوه فعال کردن رمزگذاری مبتنی بر پرونده در دستگاه های جدید و نحوه برنامه های سیستم می توانند از API های بوت مستقیم استفاده کنند تا بهترین و امن ترین تجربه ممکن را به کاربران ارائه دهند.

کلیه دستگاه هایی که با Android 10 و بالاتر راه اندازی می شوند ، برای استفاده از رمزگذاری مبتنی بر پرونده مورد نیاز هستند.

چکمه مستقیم

رمزگذاری مبتنی بر پرونده ویژگی جدیدی را که در Android 7.0 به نام Direct Boot معرفی شده است ، امکان پذیر می کند. Boot Direct به دستگاه های رمزگذاری شده اجازه می دهد تا مستقیماً به صفحه قفل بوت شوند. پیش از این ، در دستگاه های رمزگذاری شده با استفاده از رمزگذاری تمام دیسک (FDE) ، کاربران قبل از دسترسی به هر داده ، نیاز به ارائه اعتبارنامه داشتند و مانع از انجام تلفن می شوند اما ابتدایی ترین عملیات. به عنوان مثال ، هشدارها نمی توانند کار کنند ، خدمات دسترسی در دسترس نبود و تلفن ها نمی توانند تماس دریافت کنند بلکه فقط به عملیات اصلی شماره گیری اضطراری محدود می شدند.

با معرفی رمزگذاری مبتنی بر پرونده (FBE) و API های جدید برای آگاهی از برنامه ها از رمزگذاری ، امکان پذیر است که این برنامه ها در یک زمینه محدود کار کنند. این می تواند قبل از اینکه کاربران اعتبار خود را در حالی که هنوز از اطلاعات کاربر خصوصی محافظت می کنند ، دریافت کنند.

در یک دستگاه با قابلیت FBE ، هر کاربر دستگاه دارای دو مکان ذخیره سازی در دسترس برنامه ها است:

• ذخیره سازی رمزگذاری شده (CE) ، که مکان ذخیره سازی پیش فرض است و فقط پس از قفل شدن کاربر دستگاه در دسترس است.
• ذخیره سازی دستگاه رمزگذاری شده (DE) ، که یک مکان ذخیره سازی است هم در حالت بوت مستقیم و هم پس از اینکه کاربر دستگاه را باز کرده است.

این جدایی باعث می شود پروفایل های کار ایمن تر شوند زیرا این امکان را به شما می دهد تا بیش از یک کاربر در یک زمان محافظت شود زیرا رمزگذاری دیگر فقط بر اساس رمز عبور زمان بوت نیست.

API Boot Direct به برنامه های آگاه رمزگذاری اجازه می دهد تا به هر یک از این مناطق دسترسی پیدا کنند. تغییراتی در چرخه عمر برنامه وجود دارد تا نیاز به اطلاع رسانی به برنامه ها را در هنگام بازداشت CE کاربر در پاسخ به وارد کردن اعتبارنامه برای اولین بار در صفحه قفل ، یا در مورد مشخصات کار ایجاد کند. دستگاه هایی که Android 7.0 در حال اجرا هستند ، بدون توجه به اینکه آنها FBE را پیاده سازی می کنند ، باید از این API ها و چرخه های زندگی جدید پشتیبانی کنند. اگرچه ، بدون ذخیره سازی FBE ، DE و CE همیشه در حالت باز نشده قرار دارند.

اجرای کامل رمزگذاری مبتنی بر پرونده در سیستم های پرونده EXT4 و F2FS در پروژه منبع باز اندروید (AOSP) ارائه شده است و فقط در دستگاه هایی که مطابق با الزامات هستند ، باید فعال شود. تولید کنندگان انتخاب شده برای استفاده از FBE می توانند راه های بهینه سازی ویژگی را بر اساس سیستم در تراشه (SOC) مورد استفاده کشف کنند.

تمام بسته های لازم در AOSP به روز شده اند تا مستقیماً از آن آگاه باشند. با این حال ، در جایی که تولید کنندگان دستگاه از نسخه های سفارشی این برنامه ها استفاده می کنند ، آنها می خواهند حداقل اطمینان حاصل کنند که بسته های آگاهانه با بوت مستقیم وجود دارد که خدمات زیر را ارائه می دهند:

• خدمات تلفنی و شماره گیری
• روش ورودی برای وارد کردن رمزهای عبور به صفحه قفل

مثال ها و منبع

Android اجرای مرجع رمزگذاری مبتنی بر پرونده را فراهم می کند ، که در آن ولد ( سیستم/ولد ) عملکردی را برای مدیریت دستگاه های ذخیره سازی و حجم در اندروید فراهم می کند. علاوه بر این FBE چندین دستور جدید را برای پشتیبانی از مدیریت کلید برای کلیدهای CE و DE چندین کاربر فراهم می کند. علاوه بر تغییرات اصلی برای استفاده از قابلیت های رمزگذاری مبتنی بر پرونده در هسته ، بسیاری از بسته های سیستم از جمله صفحه قفل و Systemui برای پشتیبانی از ویژگی های FBE و مستقیم بوت اصلاح شده اند. این موارد عبارتند از:

• AOSP Dialer (بسته ها/برنامه ها/شماره گیری)
• ساعت میز (بسته ها/برنامه ها/میز کار)
• لاتین (بسته ها/inputMethods/لاتینیم)*
• برنامه تنظیمات (بسته ها/برنامه ها/تنظیمات)*
• systemui (چارچوب/پایه/بسته ها/systemui)*

* برنامه های سیستم که از ویژگی های مانیفست defaultToDeviceProtectedStorage استفاده می کنند

نمونه های بیشتری از برنامه ها و خدماتی که رمزگذاری آگاه هستند را می توان با اجرای فرمان mangrep directBootAware در فهرست چارچوب ها یا بسته های درخت منبع AOSP یافت.

وابستگی ها

برای استفاده از اجرای AOSP به طور ایمن ، یک دستگاه باید وابستگی های زیر را برآورده کند:

• پشتیبانی هسته برای رمزگذاری EXT4 یا رمزگذاری F2FS.
• پشتیبانی KEYMASTER با نسخه HAL 1.0 یا بالاتر. هیچ پشتیبانی از Keymaster 0.3 وجود ندارد زیرا این امکان را فراهم نمی کند و از حفاظت کافی برای کلیدهای رمزگذاری اطمینان نمی دهد.
• KEYMASTER/ KeyStore و Gatekeeper باید در یک محیط اجرای قابل اعتماد (TEE) اجرا شوند تا از DE Keys محافظت کنند تا یک سیستم عامل غیرمجاز (سیستم عامل سفارشی روی دستگاه چشمک بزند) به سادگی نمی تواند کلیدهای DE را درخواست کند.
• ریشه سخت افزار اعتماد و بوت تأیید شده محدود به اولیه سازی KeyMaster لازم است تا اطمینان حاصل شود که کلیدهای DE توسط یک سیستم عامل غیرمجاز در دسترس نیستند.

پیاده سازی

اول و مهمتر از همه ، برنامه هایی مانند ساعت زنگ دار ، تلفن و ویژگی های دسترسی باید Android ساخته شوند: DirectBootaware مطابق مستندات Direct Boot Developer.

پشتیبانی هسته

پشتیبانی هسته برای رمزگذاری EXT4 و F2FS در هسته های مشترک Android ، نسخه 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

برای بهبود بیشتر عملکرد و کاهش مصرف برق ، تولید کنندگان دستگاه نیز ممکن است اجرای سخت افزار رمزگذاری درون خطی را در نظر بگیرند ، که داده ها را رمزگذاری می کند/رمزگشایی می کند در حالی که در راه/از دستگاه ذخیره سازی است. هسته های مشترک Android (نسخه 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 باشد. از آنجا که Android 11 نیز می تواند برای مشخص کردن الگوریتم پیش فرض ، که aes-256-xts است ، خالی بماند.
• پارامتر filenames_encryption_mode تعریف می کند که کدام الگوریتم رمزنگاری برای رمزگذاری نام پرونده ها استفاده می شود. این می تواند aes-256-cts ، aes-256-heh ، adiantum یا aes-256-hctr2 باشد. اگر مشخص نشده باشد ، اگر contents_encryption_mode aes-256-xts باشد ، یا به adiantum اگر contents_encryption_mode adiantum باشد ، به aes-256-cts پیش فرض می شود.
• پارامتر flags ، New in Android 11 ، لیستی از پرچم ها است که توسط شخصیت + از هم جدا شده اند. پرچم های زیر پشتیبانی می شوند:
  • پرچم v1 سیاست های رمزگذاری نسخه 1 را انتخاب می کند. پرچم v2 سیاست های رمزگذاری نسخه 2 را انتخاب می کند. خط مشی های رمزگذاری نسخه 2 از یک عملکرد مشتق کلیدی امن تر و انعطاف پذیر تر استفاده می کنند. پیش فرض V2 است اگر دستگاه در Android 11 یا بالاتر راه اندازی شود (مطابق با ro.product.first_api_level ) یا V1 در صورت راه اندازی دستگاه در Android 10 یا پایین.
  • پرچم inlinecrypt_optimized یک قالب رمزگذاری را انتخاب می کند که برای سخت افزار رمزگذاری درون خطی بهینه شده است که تعداد زیادی از کلیدها را به طور کارآمد کنترل نمی کند. این کار را با استخراج فقط یک پرونده رمزگذاری محتوای پرونده در هر کلید یا کلید DE انجام می دهد ، نه یک پرونده. تولید IV (بردارهای اولیه سازی) بر این اساس تنظیم می شود.
  • پرچم emmc_optimized شبیه به inlinecrypt_optimized است ، اما همچنین یک روش تولید IV را انتخاب می کند که IVS را به 32 بیت محدود می کند. این پرچم فقط باید در سخت افزار رمزگذاری درون خطی که مطابق با مشخصات JEDEC EMMC V5.2 است استفاده شود و بنابراین فقط IV 32 بیتی را پشتیبانی می کند. در سایر سخت افزار رمزگذاری درون خطی ، به جای آن از inlinecrypt_optimized استفاده کنید. این پرچم هرگز نباید در ذخیره سازی مبتنی بر UFS استفاده شود. مشخصات UFS امکان استفاده از IV 64 بیتی را فراهم می کند.
  • در دستگاه هایی که از کلیدهای پیچیده شده با سخت افزار پشتیبانی می کنند ، پرچم wrappedkey_v0 استفاده از کلیدهای پیچیده شده سخت افزاری برای FBE را امکان پذیر می کند. این فقط می تواند در ترکیب با گزینه inlinecrypt Mount ، و یا پرچم inlinecrypt_optimized یا emmc_optimized استفاده شود.
  • پرچم dusize_4k اندازه واحد داده رمزگذاری را مجبور می کند 4096 بایت باشد حتی اگر اندازه بلوک سیستم فایل 4096 بایت نباشد. اندازه واحد داده رمزگذاری ، دانه بندی محتوای فایل رمزگذاری است. این پرچم از Android 15 در دسترس است. این پرچم فقط باید برای استفاده از سخت افزار رمزگذاری درون خطی که از واحدهای داده بزرگتر از 4096 بایت پشتیبانی نمی کند ، استفاده شود ، بر روی دستگاهی که از اندازه صفحه بزرگتر از 4096 بایت استفاده می کند و از F2FS استفاده می کند فایل سیستم

اگر از سخت افزار رمزگذاری Inline استفاده نمی کنید ، تنظیم توصیه شده برای اکثر دستگاه ها fileencryption=aes-256-xts است. اگر از سخت افزار رمزگذاری درون خطی استفاده می کنید ، تنظیمات توصیه شده برای اکثر دستگاه ها fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (یا به طور معادل fileencryption=::inlinecrypt_optimized ). On devices without any form of AES acceleration, Adiantum can be used instead of AES by setting fileencryption=adiantum .

Since Android 14, AES-HCTR2 is the preferred mode of filenames encryption for devices with accelerated cryptography instructions. However, only newer Android kernels support AES-HCTR2. In a future Android release, it is planned to become the default mode for filenames encryption. If your kernel has AES-HCTR2 support, it can be enabled for filenames encryption by setting filenames_encryption_mode to aes-256-hctr2 . In the simplest case this would be done with fileencryption=aes-256-xts:aes-256-hctr2 .

On devices that launched with Android 10 or lower, fileencryption=ice is also accepted to specify the use of the FSCRYPT_MODE_PRIVATE file contents encryption mode. This mode is unimplemented by the Android common kernels, but it could be implemented by vendors using custom kernel patches. The on-disk format produced by this mode was vendor-specific. On devices launching with Android 11 or higher, this mode is no longer allowed and a standard encryption format must be used instead.

By default, file contents encryption is done using the Linux kernel's cryptography API. If you want to use inline encryption hardware instead, also add the inlinecrypt mount option. For example, a full fstab line might look like:

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

Adoptable storage

Since Android 9, FBE and adoptable storage can be used together.

Specifying the fileencryption fstab option for userdata also automatically enables both FBE and metadata encryption on adoptable storage. However, you can override the FBE or metadata encryption formats on adoptable storage by setting properties in PRODUCT_PROPERTY_OVERRIDES .

On devices that launched with Android 11 or higher, use the following properties:

• ro.crypto.volume.options (new in Android 11) selects the FBE encryption format on adoptable storage. It has the same syntax as the argument to the fileencryption fstab option, and it uses the same defaults. See the recommendations for fileencryption above for what to use here.
• ro.crypto.volume.metadata.encryption selects the metadata encryption format on adoptable storage. See the metadata encryption documentation .

On devices that launched with Android 10 or lower, use the following properties:

• ro.crypto.volume.contents_mode selects the contents encryption mode. This is equivalent to the first colon-separated field of ro.crypto.volume.options .
• ro.crypto.volume.filenames_mode selects the filenames encryption mode. This is equivalent to the second colon-separated field of ro.crypto.volume.options , except that the default on devices that launched with Android 10 or lower is aes-256-heh . On most devices, this needs to be explicitly overridden to aes-256-cts .
• ro.crypto.fde_algorithm and ro.crypto.fde_sector_size select the metadata encryption format on adoptable storage. See the metadata encryption documentation .

Integrate with Keymaster

The Keymaster HAL should be started as part of the early_hal class. This is because FBE requires that Keymaster be ready to handle requests by the post-fs-data boot phase, which is when vold sets up the initial keys.

Exclude directories

init applies the system DE key to all top-level directories of /data , except for directories that must be unencrypted such as the directory that contains the system DE key itself and directories that contain user CE or DE directories. Encryption keys apply recursively and cannot be overridden by subdirectories.

In Android 11 and higher, the key that init applies to directories can be controlled by the encryption=<action> argument to the mkdir command in init scripts. The possible values of <action> are documented in the README for the Android init language .

In Android 10, the init encryption actions were hardcoded into the following location:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

In Android 9 and earlier, the location was:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

It is possible to add exceptions to prevent certain directories from being encrypted at all. If modifications of this sort are made then the device manufacturer should include SELinux policies that only grant access to the apps that need to use the unencrypted directory. This should exclude all untrusted apps.

The only known acceptable use case for this is in support of legacy OTA capabilities.

Support Direct Boot in system apps

Make apps Direct Boot aware

To facilitate rapid migration of system apps, there are two new attributes that can be set at the app level. The defaultToDeviceProtectedStorage attribute is available only to system apps. The directBootAware attribute is available to all.

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

The directBootAware attribute at the app level is shorthand for marking all components in the app as being encryption aware.

The defaultToDeviceProtectedStorage attribute redirects the default app storage location to point at DE storage instead of pointing at CE storage. System apps using this flag must carefully audit all data stored in the default location, and change the paths of sensitive data to use CE storage. Device manufactures using this option should carefully inspect the data that they are storing to ensure that it contains no personal information.

When running in this mode, the following System APIs are available to explicitly manage a Context backed by CE storage when needed, which are equivalent to their Device Protected counterparts.

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

Support multiple users

Each user in a multi-user environment gets a separate encryption key. Every user gets two keys: a DE and a CE key. User 0 must log into the device first as it is a special user. This is pertinent for Device Administration uses.

Crypto-aware apps interact across users in this manner: INTERACT_ACROSS_USERS and INTERACT_ACROSS_USERS_FULL allow an app to act across all the users on the device. However, those apps can access only CE-encrypted directories for users that are already unlocked.

An app might be able to interact freely across the DE areas, but one user unlocked does not mean that all the users on the device are unlocked. The app should check this status before trying to access these areas.

Each work profile user ID also gets two keys: DE and CE. When the work challenge is met, the profile user is unlocked and the Keymaster (in TEE) can provide the profile's TEE key.

Handle updates

The recovery partition is unable to access the DE-protected storage on the userdata partition. Devices implementing FBE are strongly recommended to support OTA using A/B system updates . As the OTA can be applied during normal operation there is no need for recovery to access data on the encrypted drive.

When using a legacy OTA solution, which requires recovery to access the OTA file on the userdata partition:

1. Create a top-level directory (for example misc_ne ) in the userdata partition.
2. Configure this top-level directory to be unencrypted (see Excluding directories ).
3. Create a directory within the top-level directory to hold OTA packages.
4. Add an SELinux rule and file contexts to control access to this directory and it contents. Only the process or apps receiving OTA updates should be able to read and write to this directory. No other app or process should have access to this directory.

اعتبار سنجی

To ensure the implemented version of the feature works as intended, first run the many CTS encryption tests, such as DirectBootHostTest and EncryptionTest .

If the device is running Android 11 or higher, also run vts_kernel_encryption_test :

atest vts_kernel_encryption_test

یا:

vts-tradefed run vts -m vts_kernel_encryption_test

In addition, device manufacturers can perform the following manual tests. On a device with FBE enabled:

• Check that ro.crypto.state exists
  • Ensure ro.crypto.state is encrypted
• Check that ro.crypto.type exists
  • Ensure ro.crypto.type is set to file

Additionally, testers can verify that CE storage is locked before the device has been unlocked for the first time since boot. To do this, use a userdebug or eng build, set a PIN, pattern, or password on the main user, and reboot the device. Before unlocking the device, run the following command to check the CE storage of the main user. If the device uses Headless System User Mode (most Automotive devices), the main user is user 10, so run:

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

On other devices (most non-Automotive devices), the main user is user 0, so run:

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

Verify that the listed filenames are Base64-encoded, indicating that the filenames are encrypted and the key to decrypt them is not yet available. If the filenames are listed in plaintext, something is wrong.

Device manufacturers are also encouraged to explore running the upstream Linux tests for fscrypt on their devices or kernels. These tests are part of the xfstests filesystem test suite. However, these upstream tests are not offically supported by Android.

AOSP implementation details

This section provides details on the AOSP implementation and describes how file-based encryption works. It should not be necessary for device manufacturers to make any changes here to use FBE and Direct Boot on their devices.

fscrypt encryption

The AOSP implementation uses "fscrypt" encryption (supported by ext4 and f2fs) in the kernel and normally is configured to:

• Encrypt file contents with AES-256 in XTS mode
• Encrypt file names with AES-256 in CBC-CTS mode

Adiantum encryption is also supported. When Adiantum encryption is enabled, both file contents and file names are encrypted with Adiantum.

fscrypt supports two versions of encryption policies: version 1 and version 2. Version 1 is deprecated, and the CDD requirements for devices launching with Android 11 and higher are only compatible with version 2. Version 2 encryption policies use HKDF-SHA512 to derive the actual encryption keys from the userspace-supplied keys.

For more information about fscrypt, see the upstream kernel documentation .

کلاس های ذخیره سازی

The following table lists the FBE keys and the directories they protect in more detail:

Key storage and protection

All FBE keys are managed by vold and are stored encrypted on-disk, except for the per-boot key which is not stored at all. The following table lists the locations in which the various FBE keys are stored:

As shown in the preceding table, most FBE keys are stored in directories that are encrypted by another FBE key. Keys cannot be unlocked until the storage class that contains them has been unlocked.

vold also applies a layer of encryption to all FBE keys. Every key besides CE keys for internal storage is encrypted with AES-256-GCM using its own Keystore key that is not exposed outside the TEE. This ensures that FBE keys cannot be unlocked unless a trusted operating system has booted, as enforced by Verified Boot . Rollback resistance is also requested on the Keystore key, which allows FBE keys to be securely deleted on devices where Keymaster supports rollback resistance. As a best-effort fallback for when rollback resistance is unavailable, the SHA-512 hash of 16384 random bytes stored in the secdiscardable file stored alongside the key is used as the app ID tag of the Keystore key. All these bytes need to be recovered to recover an FBE key.

CE keys for internal storage receive a stronger level of protection that ensures they cannot be unlocked without knowing either the user's Lock Screen Knowledge Factor (LSKF) (PIN, pattern, or password), a secure passcode reset token , or both the client-side and server-side keys for a Resume-on-Reboot operation. Passcode reset tokens are only allowed to be created for work profiles and fully managed devices .

To achieve this, vold encrypts each CE key for internal storage using an AES-256-GCM key derived from the user's synthetic password . The synthetic password is an immutable high-entropy cryptographic secret that is randomly generated for each user. LockSettingsService in system_server manages the synthetic password and the ways in which it is protected.

To protect the synthetic password with the LSKF, LockSettingsService first stretches the LSKF by passing it through scrypt , targeting a time of about 25 ms and a memory usage of about 2 MiB. Since LSKFs are usually short, this step usually does not provide much security. The main layer of security is the Secure Element (SE) or TEE-enforced ratelimiting described below.

If the device has a Secure Element (SE), then LockSettingsService maps the stretched LSKF to a high-entropy random secret stored in the SE using the Weaver HAL . LockSettingsService then encrypts the synthetic password twice: first with a software key derived from the stretched LSKF and the Weaver secret, and second with a non-auth-bound Keystore key. This provides SE-enforced ratelimiting of LSKF guesses.

If the device doesn't have a SE, then LockSettingsService instead uses the stretched LSKF as a Gatekeeper password. LockSettingsService then encrypts the synthetic password twice: first with a software key derived from the stretched LSKF and the hash of a secdiscardable file, and second with a Keystore key that is auth-bound to the Gatekeeper enrollment. This provides TEE-enforced ratelimiting of LSKF guesses.

When the LSKF is changed, LockSettingsService deletes all information associated with the binding of the synthetic password to the old LSKF. On devices that support Weaver or rollback resistant Keystore keys, this guarantees secure deletion of the old binding. For this reason, the protections described here are applied even when the user does not have an LSKF.

Android 7.0 and higher supports file-based encryption (FBE). File-based encryption allows different files to be encrypted with different keys that can be unlocked independently.

This article describes how to enable file-based encryption on new devices and how system apps can use the Direct Boot APIs to offer users the best, most secure experience possible.

All devices launching with Android 10 and higher are required to use file-based encryption.

Direct Boot

File-based encryption enables a new feature introduced in Android 7.0 called Direct Boot . Direct Boot allows encrypted devices to boot straight to the lock screen. Previously, on encrypted devices using full-disk encryption (FDE), users needed to provide credentials before any data could be accessed, preventing the phone from performing all but the most basic of operations. For example, alarms could not operate, accessibility services were unavailable, and phones could not receive calls but were limited to only basic emergency dialer operations.

With the introduction of file-based encryption (FBE) and new APIs to make apps aware of encryption, it is possible for these apps to operate within a limited context. This can happen before users have provided their credentials while still protecting private user information.

On an FBE-enabled device, each user of the device has two storage locations available to apps:

• Credential Encrypted (CE) storage, which is the default storage location and only available after the user has unlocked the device.
• Device Encrypted (DE) storage, which is a storage location available both during Direct Boot mode and after the user has unlocked the device.

This separation makes work profiles more secure because it allows more than one user to be protected at a time as the encryption is no longer based solely on a boot time password.

The Direct Boot API allows encryption-aware apps to access each of these areas. There are changes to the app lifecycle to accommodate the need to notify apps when a user's CE storage is unlocked in response to first entering credentials at the lock screen, or in the case of work profile providing a work challenge . Devices running Android 7.0 must support these new APIs and lifecycles regardless of whether or not they implement FBE. Although, without FBE, DE and CE storage are always in the unlocked state.

A complete implementation of file-based encryption on the Ext4 and F2FS file systems is provided in the Android Open Source Project (AOSP) and needs only be enabled on devices that meet the requirements. Manufacturers electing to use FBE can explore ways of optimizing the feature based on the system on chip (SoC) used.

All the necessary packages in AOSP have been updated to be direct-boot aware. However, where device manufacturers use customized versions of these apps, they want to ensure at a minimum there are direct-boot aware packages providing the following services:

• Telephony Services and Dialer
• Input method for entering passwords into the lock screen

مثال ها و منبع

Android provides a reference implementation of file-based encryption, in which vold ( system/vold ) provides the functionality for managing storage devices and volumes on Android. The addition of FBE provides vold with several new commands to support key management for the CE and DE keys of multiple users. In addition to the core changes to use the file-based encryption capabilities in the kernel , many system packages including the lockscreen and the SystemUI have been modified to support the FBE and Direct Boot features. این موارد عبارتند از:

• AOSP Dialer (packages/apps/Dialer)
• Desk Clock (packages/apps/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• Settings App (packages/apps/Settings)*
• SystemUI (frameworks/base/packages/SystemUI)*

* System apps that use the defaultToDeviceProtectedStorage manifest attribute

More examples of apps and services that are encryption aware can be found by running the command mangrep directBootAware in the frameworks or packages directory of the AOSP source tree.

وابستگی ها

To use the AOSP implementation of FBE securely, a device needs to meet the following dependencies:

• Kernel Support for Ext4 encryption or F2FS encryption.
• Keymaster Support with HAL version 1.0 or higher. There is no support for Keymaster 0.3 as that does not provide the necessary capabilities or assure sufficient protection for encryption keys.
• Keymaster/ Keystore and Gatekeeper must be implemented in a Trusted Execution Environment (TEE) to provide protection for the DE keys so that an unauthorized OS (custom OS flashed onto the device) cannot simply request the DE keys.
• Hardware Root of Trust and Verified Boot bound to the Keymaster initialization is required to ensure that DE keys are not accessible by an unauthorized operating system.

پیاده سازی

First and foremost, apps such as alarm clocks, phone, and accessibility features should be made android:directBootAware according to the Direct Boot developer documentation.

Kernel support

Kernel support for Ext4 and F2FS encryption is available in the Android common kernels, version 3.18 and higher. To enable it in a kernel that is version 5.1 or higher, use:

CONFIG_FS_ENCRYPTION=y

For older kernels, use CONFIG_EXT4_ENCRYPTION=y if your device's userdata filesystem is Ext4, or use CONFIG_F2FS_FS_ENCRYPTION=y if your device's userdata filesystem is F2FS.

If your device supports adoptable storage or uses metadata encryption on internal storage, also enable the kernel configuration options needed for metadata encryption as described in the metadata encryption documentation .

In addition to functional support for Ext4 or F2FS encryption, device manufacturers should also enable cryptographic acceleration to speed up file-based encryption and improve the user experience. For example, on ARM64-based devices, ARMv8 CE (Cryptography Extensions) acceleration can be enabled by setting the following kernel configuration options:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

To further improve performance and reduce power usage, device manufacturers might also consider implementing inline encryption hardware , which encrypts/decrypts the data while it is on the way to/from the storage device. The Android common kernels (version 4.14 and higher) contain a framework that allows inline encryption to be used when hardware and vendor driver support is available. The inline encryption framework can be enabled by setting the following kernel configuration options:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

If your device uses UFS-based storage, also enable:

CONFIG_SCSI_UFS_CRYPTO=y

If your device uses eMMC-based storage, also enable:

CONFIG_MMC_CRYPTO=y

Enable file-based encryption

Enabling FBE on a device requires enabling it on the internal storage ( userdata ). This also automatically enables FBE on adoptable storage; however, the encryption format on adoptable storage can be overridden if necessary.

حافظه داخلی

FBE is enabled by adding the option fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] to the fs_mgr_flags column of the fstab line for userdata . This option defines the encryption format on internal storage. It contains up to three colon-separated parameters:

• The contents_encryption_mode parameter defines which cryptographic algorithm is used to encrypt file contents. It can be either aes-256-xts or adiantum . Since Android 11 it can also be left empty to specify the default algorithm, which is aes-256-xts .
• The filenames_encryption_mode parameter defines which cryptographic algorithm is used to encrypt file names. It can be either aes-256-cts , aes-256-heh , adiantum , or aes-256-hctr2 . If not specified, it defaults to aes-256-cts if contents_encryption_mode is aes-256-xts , or to adiantum if contents_encryption_mode is adiantum .
• The flags parameter, new in Android 11, is a list of flags separated by the + character. The following flags are supported:
  • The v1 flag selects version 1 encryption policies; the v2 flag selects version 2 encryption policies. Version 2 encryption policies use a more secure and flexible key derivation function . The default is v2 if the device launched on Android 11 or higher (as determined by ro.product.first_api_level ), or v1 if the device launched on Android 10 or lower.
  • The inlinecrypt_optimized flag selects an encryption format that is optimized for inline encryption hardware that doesn't handle large numbers of keys efficiently. It does this by deriving just one file contents encryption key per CE or DE key, rather than one per file. The generation of IVs (initialization vectors) is adjusted accordingly.
  • The emmc_optimized flag is similar to inlinecrypt_optimized , but it also selects an IV generation method that limits IVs to 32 bits. This flag should only be used on inline encryption hardware that is compliant with the JEDEC eMMC v5.2 specification and therefore supports only 32-bit IVs. On other inline encryption hardware, use inlinecrypt_optimized instead. This flag should never be used on UFS-based storage; the UFS specification allows the use of 64-bit IVs.
  • On devices that support hardware-wrapped keys , the wrappedkey_v0 flag enables the use of hardware-wrapped keys for FBE. This can only be used in combination with the inlinecrypt mount option, and either the inlinecrypt_optimized or emmc_optimized flag.
  • The dusize_4k flag forces the encryption data unit size to be 4096 bytes even when the filesystem block size is not 4096 bytes. The encryption data unit size is the granularity of file contents encryption. This flag is available since Android 15. This flag should only be used to enable the use of inline encryption hardware that does not support data units larger than 4096 bytes, on a device that uses a page size larger than 4096 bytes and that uses the f2fs فایل سیستم

If you aren't using inline encryption hardware the recommended setting for most devices is fileencryption=aes-256-xts . If you are using inline encryption hardware the recommended setting for most devices is fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (or equivalently fileencryption=::inlinecrypt_optimized ). On devices without any form of AES acceleration, Adiantum can be used instead of AES by setting fileencryption=adiantum .

Since Android 14, AES-HCTR2 is the preferred mode of filenames encryption for devices with accelerated cryptography instructions. However, only newer Android kernels support AES-HCTR2. In a future Android release, it is planned to become the default mode for filenames encryption. If your kernel has AES-HCTR2 support, it can be enabled for filenames encryption by setting filenames_encryption_mode to aes-256-hctr2 . In the simplest case this would be done with fileencryption=aes-256-xts:aes-256-hctr2 .

On devices that launched with Android 10 or lower, fileencryption=ice is also accepted to specify the use of the FSCRYPT_MODE_PRIVATE file contents encryption mode. This mode is unimplemented by the Android common kernels, but it could be implemented by vendors using custom kernel patches. The on-disk format produced by this mode was vendor-specific. On devices launching with Android 11 or higher, this mode is no longer allowed and a standard encryption format must be used instead.

By default, file contents encryption is done using the Linux kernel's cryptography API. If you want to use inline encryption hardware instead, also add the inlinecrypt mount option. For example, a full fstab line might look like:

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

Adoptable storage

Since Android 9, FBE and adoptable storage can be used together.

Specifying the fileencryption fstab option for userdata also automatically enables both FBE and metadata encryption on adoptable storage. However, you can override the FBE or metadata encryption formats on adoptable storage by setting properties in PRODUCT_PROPERTY_OVERRIDES .

On devices that launched with Android 11 or higher, use the following properties:

• ro.crypto.volume.options (new in Android 11) selects the FBE encryption format on adoptable storage. It has the same syntax as the argument to the fileencryption fstab option, and it uses the same defaults. See the recommendations for fileencryption above for what to use here.
• ro.crypto.volume.metadata.encryption selects the metadata encryption format on adoptable storage. See the metadata encryption documentation .

On devices that launched with Android 10 or lower, use the following properties:

• ro.crypto.volume.contents_mode selects the contents encryption mode. This is equivalent to the first colon-separated field of ro.crypto.volume.options .
• ro.crypto.volume.filenames_mode selects the filenames encryption mode. This is equivalent to the second colon-separated field of ro.crypto.volume.options , except that the default on devices that launched with Android 10 or lower is aes-256-heh . On most devices, this needs to be explicitly overridden to aes-256-cts .
• ro.crypto.fde_algorithm and ro.crypto.fde_sector_size select the metadata encryption format on adoptable storage. See the metadata encryption documentation .

Integrate with Keymaster

The Keymaster HAL should be started as part of the early_hal class. This is because FBE requires that Keymaster be ready to handle requests by the post-fs-data boot phase, which is when vold sets up the initial keys.

Exclude directories

init applies the system DE key to all top-level directories of /data , except for directories that must be unencrypted such as the directory that contains the system DE key itself and directories that contain user CE or DE directories. Encryption keys apply recursively and cannot be overridden by subdirectories.

In Android 11 and higher, the key that init applies to directories can be controlled by the encryption=<action> argument to the mkdir command in init scripts. The possible values of <action> are documented in the README for the Android init language .

In Android 10, the init encryption actions were hardcoded into the following location:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

In Android 9 and earlier, the location was:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

It is possible to add exceptions to prevent certain directories from being encrypted at all. If modifications of this sort are made then the device manufacturer should include SELinux policies that only grant access to the apps that need to use the unencrypted directory. This should exclude all untrusted apps.

The only known acceptable use case for this is in support of legacy OTA capabilities.

Support Direct Boot in system apps

Make apps Direct Boot aware

To facilitate rapid migration of system apps, there are two new attributes that can be set at the app level. The defaultToDeviceProtectedStorage attribute is available only to system apps. The directBootAware attribute is available to all.

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

The directBootAware attribute at the app level is shorthand for marking all components in the app as being encryption aware.

The defaultToDeviceProtectedStorage attribute redirects the default app storage location to point at DE storage instead of pointing at CE storage. System apps using this flag must carefully audit all data stored in the default location, and change the paths of sensitive data to use CE storage. Device manufactures using this option should carefully inspect the data that they are storing to ensure that it contains no personal information.

When running in this mode, the following System APIs are available to explicitly manage a Context backed by CE storage when needed, which are equivalent to their Device Protected counterparts.

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

Support multiple users

Each user in a multi-user environment gets a separate encryption key. Every user gets two keys: a DE and a CE key. User 0 must log into the device first as it is a special user. This is pertinent for Device Administration uses.

Crypto-aware apps interact across users in this manner: INTERACT_ACROSS_USERS and INTERACT_ACROSS_USERS_FULL allow an app to act across all the users on the device. However, those apps can access only CE-encrypted directories for users that are already unlocked.

An app might be able to interact freely across the DE areas, but one user unlocked does not mean that all the users on the device are unlocked. The app should check this status before trying to access these areas.

Each work profile user ID also gets two keys: DE and CE. When the work challenge is met, the profile user is unlocked and the Keymaster (in TEE) can provide the profile's TEE key.

Handle updates

The recovery partition is unable to access the DE-protected storage on the userdata partition. Devices implementing FBE are strongly recommended to support OTA using A/B system updates . As the OTA can be applied during normal operation there is no need for recovery to access data on the encrypted drive.

When using a legacy OTA solution, which requires recovery to access the OTA file on the userdata partition:

1. Create a top-level directory (for example misc_ne ) in the userdata partition.
2. Configure this top-level directory to be unencrypted (see Excluding directories ).
3. Create a directory within the top-level directory to hold OTA packages.
4. Add an SELinux rule and file contexts to control access to this directory and it contents. Only the process or apps receiving OTA updates should be able to read and write to this directory. No other app or process should have access to this directory.

اعتبار سنجی

To ensure the implemented version of the feature works as intended, first run the many CTS encryption tests, such as DirectBootHostTest and EncryptionTest .

If the device is running Android 11 or higher, also run vts_kernel_encryption_test :

atest vts_kernel_encryption_test

یا:

vts-tradefed run vts -m vts_kernel_encryption_test

In addition, device manufacturers can perform the following manual tests. On a device with FBE enabled:

• Check that ro.crypto.state exists
  • Ensure ro.crypto.state is encrypted
• Check that ro.crypto.type exists
  • Ensure ro.crypto.type is set to file

Additionally, testers can verify that CE storage is locked before the device has been unlocked for the first time since boot. To do this, use a userdebug or eng build, set a PIN, pattern, or password on the main user, and reboot the device. Before unlocking the device, run the following command to check the CE storage of the main user. If the device uses Headless System User Mode (most Automotive devices), the main user is user 10, so run:

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

On other devices (most non-Automotive devices), the main user is user 0, so run:

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

Verify that the listed filenames are Base64-encoded, indicating that the filenames are encrypted and the key to decrypt them is not yet available. If the filenames are listed in plaintext, something is wrong.

Device manufacturers are also encouraged to explore running the upstream Linux tests for fscrypt on their devices or kernels. These tests are part of the xfstests filesystem test suite. However, these upstream tests are not offically supported by Android.

AOSP implementation details

This section provides details on the AOSP implementation and describes how file-based encryption works. It should not be necessary for device manufacturers to make any changes here to use FBE and Direct Boot on their devices.

fscrypt encryption

The AOSP implementation uses "fscrypt" encryption (supported by ext4 and f2fs) in the kernel and normally is configured to:

• Encrypt file contents with AES-256 in XTS mode
• Encrypt file names with AES-256 in CBC-CTS mode

Adiantum encryption is also supported. When Adiantum encryption is enabled, both file contents and file names are encrypted with Adiantum.

fscrypt supports two versions of encryption policies: version 1 and version 2. Version 1 is deprecated, and the CDD requirements for devices launching with Android 11 and higher are only compatible with version 2. Version 2 encryption policies use HKDF-SHA512 to derive the actual encryption keys from the userspace-supplied keys.

For more information about fscrypt, see the upstream kernel documentation .

کلاس های ذخیره سازی

The following table lists the FBE keys and the directories they protect in more detail:

Key storage and protection

All FBE keys are managed by vold and are stored encrypted on-disk, except for the per-boot key which is not stored at all. The following table lists the locations in which the various FBE keys are stored:

As shown in the preceding table, most FBE keys are stored in directories that are encrypted by another FBE key. Keys cannot be unlocked until the storage class that contains them has been unlocked.

vold also applies a layer of encryption to all FBE keys. Every key besides CE keys for internal storage is encrypted with AES-256-GCM using its own Keystore key that is not exposed outside the TEE. This ensures that FBE keys cannot be unlocked unless a trusted operating system has booted, as enforced by Verified Boot . Rollback resistance is also requested on the Keystore key, which allows FBE keys to be securely deleted on devices where Keymaster supports rollback resistance. As a best-effort fallback for when rollback resistance is unavailable, the SHA-512 hash of 16384 random bytes stored in the secdiscardable file stored alongside the key is used as the app ID tag of the Keystore key. All these bytes need to be recovered to recover an FBE key.

CE keys for internal storage receive a stronger level of protection that ensures they cannot be unlocked without knowing either the user's Lock Screen Knowledge Factor (LSKF) (PIN, pattern, or password), a secure passcode reset token , or both the client-side and server-side keys for a Resume-on-Reboot operation. Passcode reset tokens are only allowed to be created for work profiles and fully managed devices .

To achieve this, vold encrypts each CE key for internal storage using an AES-256-GCM key derived from the user's synthetic password . The synthetic password is an immutable high-entropy cryptographic secret that is randomly generated for each user. LockSettingsService in system_server manages the synthetic password and the ways in which it is protected.

To protect the synthetic password with the LSKF, LockSettingsService first stretches the LSKF by passing it through scrypt , targeting a time of about 25 ms and a memory usage of about 2 MiB. Since LSKFs are usually short, this step usually does not provide much security. The main layer of security is the Secure Element (SE) or TEE-enforced ratelimiting described below.

If the device has a Secure Element (SE), then LockSettingsService maps the stretched LSKF to a high-entropy random secret stored in the SE using the Weaver HAL . LockSettingsService then encrypts the synthetic password twice: first with a software key derived from the stretched LSKF and the Weaver secret, and second with a non-auth-bound Keystore key. This provides SE-enforced ratelimiting of LSKF guesses.

If the device doesn't have a SE, then LockSettingsService instead uses the stretched LSKF as a Gatekeeper password. LockSettingsService then encrypts the synthetic password twice: first with a software key derived from the stretched LSKF and the hash of a secdiscardable file, and second with a Keystore key that is auth-bound to the Gatekeeper enrollment. This provides TEE-enforced ratelimiting of LSKF guesses.

When the LSKF is changed, LockSettingsService deletes all information associated with the binding of the synthetic password to the old LSKF. On devices that support Weaver or rollback resistant Keystore keys, this guarantees secure deletion of the old binding. For this reason, the protections described here are applied even when the user does not have an LSKF.