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

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

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

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

راه‌اندازی مستقیم

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

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

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

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

این جداسازی باعث می‌شود نمایه‌های کاری ایمن‌تر شوند زیرا اجازه می‌دهد بیش‌از یک کاربر به‌طور هم‌زمان محافظت شوند، چون رمزگذاری دیگر صرفاً براساس گذرواژه زمان راه‌اندازی نیست.

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

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

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

• سرویس‌های تلفنی و شماره‌گیر
• روش ورودی برای وارد کردن گذرواژه‌ها در صفحه قفل

نمونه‌ها و منبع

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

• AOSP Dialer (packages/apps/Dialer)
• ساعت رومیزی (packages/apps/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• برنامه تنظیمات (packages/apps/Settings)*
• SystemUI (frameworks/base/packages/SystemUI)*

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

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

وابستگی‌ها

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

• پشتیبانی هسته برای رمزگذاری Ext4 یا رمزگذاری F2FS.
• پشتیبانی از KeyMint (یا Keymaster نسخه ۱.۰ یا بالاتر). از Keymaster 0.3 پشتیبانی نمی‌شود زیرا قابلیت‌های لازم را ارائه نمی‌دهد یا محافظت کافی برای کلیدهای رمزگذاری را تضمین نمی‌کند.
• KeyMint/Keymaster و Gatekeeper باید در محیط اجرای امن (TEE) پیاده‌سازی شوند تا از کلیدهای DE محافظت کنند تا سیستم‌عامل غیرمجاز (سیستم‌عامل سفارشی که روی دستگاه فلش شده است) نتواند به‌راحتی کلیدهای DE را درخواست کند.
• ریشه اعتماد سخت‌افزاری و راه‌اندازی درستی‌سنجی‌شده محدود به مقداردهی اولیه KeyMint برای اطمینان از اینکه کلیدهای DE توسط سیستم‌عامل غیرمجاز قابل‌دسترسی نیستند لازم است.

پیاده‌سازی

اول و مهم‌تر از همه، برنامه‌هایی مانند ساعت زنگ‌دار، تلفن، و ویژگی‌های دسترس‌پذیری باید مطابق با مستندات توسعه‌دهنده راه‌اندازی مستقیم، android:directBootAware شوند.

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

پشتیبانی هسته برای رمزگذاری Ext4 و F2FS در هسته‌های مشترک Android، نسخه ۳.۱۸ و بالاتر، دردسترس است. برای فعال کردن آن در هسته‌ای که نسخه ۵.۱ یا بالاتر است، از این دستور استفاده کنید:

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

برای بهبود بیشتر عملکرد و کاهش مصرف برق، سازندگان دستگاه ممکن است سخت‌افزار رمزگذاری درون‌خطی را نیز پیاده‌سازی کنند که داده‌ها را هنگام انتقال به/از دستگاه ذخیره‌سازی رمزگذاری/رمزگشایی می‌کند. هسته‌های مشترک Android (نسخه ۴.۱۴ و بالاتر) حاوی چارچوبی هستند که امکان استفاده از رمزگذاری درون‌خطی را درصورت دردسترس بودن پشتیبانی سخت‌افزار و درایور فروشنده فراهم می‌کند. چارچوب رمزگذاری درون‌خطی را می‌توان با تنظیم گزینه‌های پیکربندی هسته زیر فعال کرد:

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 نسخه ۱۱، این فیلد می‌تواند خالی هم بماند تا الگوریتم پیش‌فرض که aes-256-xts است مشخص شود.
• پارامتر filenames_encryption_mode مشخص می‌کند که از کدام الگوریتم رمزنگاری برای رمزگذاری نام فایل‌ها استفاده می‌شود. می‌تواند یکی از این موارد باشد: aes-256-cts، aes-256-heh، adiantum، یا aes-256-hctr2. اگر مشخص نشده باشد، به‌طور پیش‌فرض روی aes-256-cts تنظیم می‌شود اگر contents_encryption_mode aes-256-xts باشد، یا روی adiantum تنظیم می‌شود اگر contents_encryption_mode adiantum باشد.
• پارامتر flags که در Android 11 جدید است، فهرستی از پرچم‌ها است که با نویسه + از هم جدا شده‌اند. پرچم‌های زیر پشتیبانی می‌شوند:
  • پرچم v1 خط‌مشی‌های رمزگذاری نسخه ۱ را انتخاب می‌کند؛ پرچم v2 خط‌مشی‌های رمزگذاری نسخه ۲ را انتخاب می‌کند. خط‌مشی‌های رمزگذاری نسخه ۲ از تابع استخراج کلید امن‌تر و انعطاف‌پذیرتری استفاده می‌کنند. اگر دستگاه با Android نسخه ۱۱ یا بالاتر راه‌اندازی شده باشد (همان‌طور که توسط ro.product.first_api_level تعیین شده است)، پیش‌فرض نسخه ۲ است، و اگر دستگاه با Android نسخه ۱۰ یا پایین‌تر راه‌اندازی شده باشد، پیش‌فرض نسخه ۱ است.
  • پرچم inlinecrypt_optimized قالب رمزگذاری‌ای را انتخاب می‌کند که برای سخت‌افزار رمزگذاری درون‌خطی بهینه‌سازی شده است و تعداد زیادی کلید را به‌طور کارآمد مدیریت نمی‌کند. این کار را با مشتق کردن فقط یک کلید رمزگذاری محتوای فایل برای هر کلید CE یا DE انجام می‌دهد، نه یک کلید برای هر فایل. تولید IV (بردار مقداردهی اولیه) بر این اساس تنظیم می‌شود.
  • پرچم emmc_optimized شبیه به inlinecrypt_optimized است، اما روش تولید IV را نیز انتخاب می‌کند که IV را به ۳۲ بیت محدود می‌کند. این پرچم فقط باید در سخت‌افزار رمزگذاری درون‌خطی استفاده شود که با مشخصات JEDEC eMMC v5.2 مطابقت دارد و بنابراین فقط از IVهای ۳۲ بیتی پشتیبانی می‌کند. در سایر سخت‌افزارهای رمزگذاری درون‌خطی، از inlinecrypt_optimized استفاده کنید. این پرچم هرگز نباید در فضای ذخیره‌سازی مبتنی بر UFS استفاده شود؛ مشخصات UFS اجازه استفاده از IVهای ۶۴ بیتی را می‌دهد.
  • در دستگاه‌هایی که از کلیدهای رمزگذاری درون‌خطی با پوشش سخت‌افزاری پشتیبانی می‌کنند، کلیدهای FBE را می‌توان با افزودن پرچم wrappedkey یا wrappedkey_v0 به‌صورت پوشش سخت‌افزاری درآورد. wrappedkey نسخه مدرن است؛ wrappedkey_v0 باید فقط در دستگاه‌هایی استفاده شود که از wrappedkey پشتیبانی نمی‌کنند یا قبلاً با wrappedkey_v0 راه‌اندازی شده‌اند. برای اطلاعات بیشتر، به فعال کردن کلیدهای پیچیده مراجعه کنید.
  • پرچم dusize_4k اندازه واحد داده رمزگذاری را مجبور می‌کند ۴۰۹۶ بایت باشد، حتی زمانی که اندازه بلوک سیستم فایل ۴۰۹۶ بایت نباشد. اندازه واحد داده رمزگذاری، دانه‌بندی رمزگذاری محتوای فایل است. این پرچم از Android 15 دردسترس است. این پرچم فقط باید برای فعال کردن استفاده از سخت‌افزار رمزگذاری درون‌خطی که از واحدهای داده بزرگ‌تر از ۴۰۹۶ بایت پشتیبانی نمی‌کند، در دستگاهی که از اندازه صفحه بزرگ‌تر از ۴۰۹۶ بایت استفاده می‌کند و از سیستم فایل f2fs استفاده می‌کند، استفاده شود.

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

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

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

به‌طور پیش‌فرض، رمزگذاری محتوای فایل بااستفاده از میانای برنامه‌سازی کاربردی رمزنگاری هسته Linux انجام می‌شود. اگر می‌خواهید به‌جای آن از سخت‌افزار رمزگذاری درون‌خطی استفاده کنید، گزینه سوار کردن inlinecrypt را نیز اضافه کنید. برای مثال، یک خط کامل fstab ممکن است به‌این‌صورت باشد:

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

حافظه قابل‌پذیرش

از Android 9، می‌توان از FBE و حافظه قابل‌پذیرش باهم استفاده کرد.

مشخص کردن گزینه fileencryption fstab برای userdata همچنین به‌طور خودکار هم FBE و هم رمزگذاری فراداده را در حافظه قابل‌پذیرش فعال می‌کند. بااین‌حال، می‌توانید قالب‌های رمزگذاری FBE یا فراداده را در حافظه قابل‌پذیرش با تنظیم ویژگی‌ها در PRODUCT_PROPERTY_OVERRIDES لغو کنید.

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

• ro.crypto.volume.options (جدید در Android 11) قالب رمزگذاری FBE را در فضای ذخیره‌سازی قابل‌انطباق انتخاب می‌کند. این گزینه همان نحو آرگومان گزینه fileencryption fstab را دارد و از همان پیش‌فرض‌ها استفاده می‌کند. توصیه‌های مربوط به fileencryption را در بالا ببینید تا بدانید چه چیزی را باید در اینجا استفاده کنید.
• ro.crypto.volume.metadata.encryption قالب رمزگذاری فراداده را در فضای ذخیره‌سازی قابل‌انطباق انتخاب می‌کند. سند رمزگذاری فراداده را ببینید.

در دستگاه‌هایی که با Android نسخه ۱۰ و پایین‌تر عرضه شده‌اند، از ویژگی‌های زیر استفاده کنید:

• 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 قالب رمزگذاری فراداده را در فضای ذخیره‌سازی قابل‌انطباق انتخاب کنید. سند رمزگذاری فراداده را ببینید.

ادغام کردن با KeyMint

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

مستثنی کردن فهرست‌های راهنما

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

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

در Android 10، کنش‌های رمزگذاری init در مکان زیر کدگذاری شده‌اند:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

در Android 9 و نسخه‌های قدیمی‌تر، مکان عبارت بود از:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

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

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

پشتیبانی از «راه‌اندازی مستقیم» در برنامه‌های سیستم

آگاه کردن برنامه‌ها از «راه‌اندازی مستقیم»

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

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

مشخصه directBootAware در سطح برنامه، علامت اختصاری برای علامت‌گذاری همه مؤلفه‌های برنامه به‌عنوان آگاه از رمزگذاری است.

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

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

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

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

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

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

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

هر شناسه کاربر نمایه کاری نیز دو کلید دریافت می‌کند: DE و CE. وقتی چالش کاری برآورده شود، قفل کاربر نمایه باز می‌شود و KeyMint (در TEE) می‌تواند کلید TEE نمایه را ارائه دهد.

به‌روزرسانی‌های شناسه مجازی

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

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

1. یک دایرکتوری سطح بالا (برای مثال misc_ne) در بخش userdata ایجاد کنید.
2. این دایرکتوری سطح بالا را طوری پیکربندی کنید که رمزگذاری نشود (به مستثنی کردن دایرکتوری‌ها مراجعه کنید).
3. یک دایرکتوری در دایرکتوری سطح بالا برای نگهداری بسته‌های OTA ایجاد کنید.
4. یک قانون SELinux و زمینه‌های فایل برای کنترل دسترسی به این دایرکتوری و محتویات آن اضافه کنید. فقط فرایند یا برنامه‌هایی که به‌روزرسانی‌های OTA را دریافت می‌کنند باید بتوانند در این دایرکتوری بخوانند و بنویسند. هیچ برنامه یا فرایند دیگری نباید به این دایرکتوری دسترسی داشته باشد.

اعتبارسنجی

برای اطمینان از اینکه نسخه پیاده‌سازی‌شده ویژگی طبق انتظار کار می‌کند، ابتدا بسیاری از آزمایش‌های رمزگذاری CTS را اجرا کنید، مانند DirectBootHostTest و EncryptionTest.

اگر دستگاه Android 11 یا بالاتر را اجرا می‌کند، vts_kernel_encryption_test را نیز اجرا کنید:

atest vts_kernel_encryption_test

یا:

vts-tradefed run vts -m vts_kernel_encryption_test

علاوه‌براین، سازندگان دستگاه می‌توانند آزمایش‌های دستی زیر را انجام دهند. در دستگاهی که FBE در آن فعال است:

• بررسی کنید که ro.crypto.state وجود داشته باشد
  • مطمئن شوید ro.crypto.state رمزگذاری شده باشد
• بررسی کنید که ro.crypto.type وجود داشته باشد
  • مطمئن شوید ro.crypto.type روی file تنظیم شده باشد

علاوه‌براین، آزمایش‌کنندگان می‌توانند تأیید کنند که فضای ذخیره‌سازی CE قبل‌از اینکه قفل دستگاه برای اولین‌بار پس‌از راه‌اندازی باز شود، قفل است. برای انجام این کار، از ساخت userdebug یا eng استفاده کنید، پین، الگو، یا گذرواژه‌ای برای کاربر اصلی تنظیم کنید، و دستگاه را بازراه‌اندازی کنید. قبل‌از باز کردن قفل دستگاه، فرمان زیر را برای بررسی فضای ذخیره‌سازی CE کاربر اصلی اجرا کنید. اگر دستگاه از حالت کاربر سیستم بی‌سر (اکثر دستگاه‌های Automotive) استفاده می‌کند، کاربر اصلی کاربر ۱۰ است، بنابراین این دستور را اجرا کنید:

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

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

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

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

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

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

این بخش جزئیاتی درباره پیاده‌سازی AOSP ارائه می‌دهد و نحوه عملکرد رمزگذاری مبتنی بر فایل را شرح می‌دهد. سازندگان دستگاه برای استفاده از FBE و «راه‌اندازی مستقیم» در دستگاه‌هایشان نیازی به ایجاد تغییر در اینجا ندارند.

رمزگذاری fscrypt

پیاده‌سازی AOSP از رمزگذاری «fscrypt» (پشتیبانی‌شده توسط ext4 و f2fs) در هسته استفاده می‌کند و معمولاً برای موارد زیر پیکربندی می‌شود:

• رمزگذاری محتوای فایل با AES-256 در حالت XTS
• رمزگذاری نام فایل‌ها با AES-256 در حالت CBC-CTS

رمزگذاری Adiantum نیز پشتیبانی می‌شود. وقتی رمزگذاری Adiantum فعال باشد، هم محتوای فایل و هم نام فایل با Adiantum رمزگذاری می‌شود.

fscrypt از دو نسخه خط‌مشی رمزگذاری پشتیبانی می‌کند: نسخه ۱ و نسخه ۲. نسخه ۱ منسوخ شده است و الزامات CDD برای دستگاه‌هایی که با Android 11 و بالاتر عرضه می‌شوند فقط با نسخه ۲ سازگار است. خط‌مشی‌های رمزگذاری نسخه ۲ از HKDF-SHA512 برای مشتق کردن کلیدهای رمزگذاری واقعی از کلیدهای ارائه‌شده توسط فضای کاربر استفاده می‌کنند.

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

کلاس‌های فضای ذخیره‌سازی

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

ذخیره‌سازی و محافظت از کلید

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

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

vold همچنین لایه‌ای از رمزگذاری را بر همه کلیدهای FBE اعمال می‌کند. همه کلیدها به‌جز کلیدهای CE برای فضای ذخیره‌سازی داخلی با AES-256-GCM بااستفاده از کلید Keystore خودشان رمزگذاری می‌شوند که خارج از TEE افشا نمی‌شود. این کار تضمین می‌کند که کلیدهای FBE باز نمی‌شوند مگراینکه سیستم‌عامل مورداعتمادی راه‌اندازی شده باشد، همان‌طور که توسط راه‌اندازی درستی‌سنجی‌شده اعمال می‌شود. مقاومت دربرابر بازگشت به نسخه قبلی نیز در کلید Keystore درخواست می‌شود که به کلیدهای FBE اجازه می‌دهد به‌طور ایمن در دستگاه‌هایی که KeyMint از مقاومت دربرابر بازگشت به نسخه قبلی پشتیبانی می‌کند حذف شوند. به‌عنوان یک راهکار جایگزین با بهترین تلاش برای زمانی که مقاومت دربرابر بازگشت به نسخه قبلی دردسترس نیست، درهم‌سازی SHA-512 از ۱۶۳۸۴ بایت تصادفی ذخیره‌شده در فایل secdiscardable ذخیره‌شده در کنار کلید به‌عنوان Tag::APPLICATION_ID کلید Keystore استفاده می‌شود. برای بازیابی کلید FBE، همه این بایت‌ها باید بازیابی شوند.

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

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

برای محافظت از گذرواژه مصنوعی با LSKF، LockSettingsService ابتدا LSKF را با عبور دادن آن از scrypt گسترش می‌دهد، با هدف‌گذاری زمان حدود ۲۵ میلی‌ثانیه و استفاده از حافظه حدود ۲ مبی‌بایت. ازآنجایی‌که «دانسته‌های قفل صفحه» معمولاً کوتاه هستند، این مرحله معمولاً امنیت زیادی ایجاد نمی‌کند. لایه اصلی امنیت عنصر امن (SE) یا محدودیت نرخ اعمال‌شده توسط TEE است که در زیر شرح داده شده است.

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

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

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