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

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

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

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

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

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

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

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

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

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

«میانای برنامه‌سازی کاربردی بوت مستقیم» به برنامه‌های آگاه از رمزگذاری اجازه می‌دهد به هریک از این حوزه‌ها دسترسی داشته باشند. تغییراتی در چرخه حیات برنامه ایجاد شده است تا نیاز به اطلاع‌رسانی به برنامه‌ها در زمانی که فضای ذخیره‌سازی CE کاربر در پاسخ به اولین ورود اطلاعات کاربری در صفحه قفل باز می‌شود، یا در مورد نمایه کاری که یک چالش کاری ارائه می‌دهد، برآورده شود. دستگاه‌های دارای Android 7.0 باید از این APIهای جدید و چرخه‌های حیات پشتیبانی کنند، صرف‌نظر از اینکه 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 11 می‌تواند خالی بماند تا الگوریتم پیش‌فرض، که aes-256-xts است، مشخص شود.
• پارامتر filenames_encryption_mode مشخص می‌کند که از کدام الگوریتم رمزنگاری برای رمزگذاری نام فایل‌ها استفاده می‌شود. می‌تواند یکی از این موارد باشد: aes-256-cts، aes-256-heh، adiantum، یا aes-256-hctr2. اگر مشخص نشده باشد، به‌طور پیش‌فرض روی aes-256-cts تنظیم می‌شود اگر contents_encryption_mode aes-256-xts باشد، یا روی adiantum تنظیم می‌شود اگر contents_encryption_mode adiantum باشد.
• پارامتر flags که در Android 11 جدید است، فهرستی از پرچم‌ها است که با نویسه + از هم جدا شده‌اند. پرچم‌های زیر پشتیبانی می‌شوند:
  • پرچم v1 خط‌مشی‌های رمزگذاری نسخه ۱ را انتخاب می‌کند؛ پرچم 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های ۶۴ بیتی را می‌دهد.
  • در دستگاه‌هایی که از کلیدهای رمزگذاری درون‌خطی با بسته‌بندی سخت‌افزاری پشتیبانی می‌کنند، با افزودن پرچم wrappedkey یا wrappedkey_v0، کلیدهای FBE می‌توانند با بسته‌بندی سخت‌افزاری ساخته شوند. 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 از Adiantum به‌جای AES استفاده کرد.

از 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 11 یا بالاتر عرضه شده‌اند، از ویژگی‌های زیر استفاده کنید:

• ro.crypto.volume.options (جدید در Android نسخه ۱۱) قالب رمزگذاری 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 قالب رمزگذاری فراداده را در فضای ذخیره‌سازی قابل‌انطباق انتخاب کنید. سند رمزگذاری فراداده را ببینید.

ادغام با KeyMint

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

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

‫init کلید DE سیستم را روی همه فهرست‌های راهنمای سطح بالای /data اعمال می‌کند، به‌جز فهرست‌های راهنمایی که باید رمزگذاری‌نشده باشند، مثل فهرست راهنمایی که خود کلید DE سیستم را دربرمی‌گیرد و فهرست‌های راهنمایی که فهرست‌های راهنمای 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 تغییر دهند. تولیدکنندگان دستگاه که از این گزینه استفاده می‌کنند باید داده‌هایی را که ذخیره می‌کنند به‌دقت بررسی کنند تا مطمئن شوند حاوی اطلاعات شخصی نباشد.

هنگام اجرا در این حالت، میاناهای برنامه‌سازی کاربردی سیستم زیر برای مدیریت صریح «زمینه» پشتیبانی‌شده توسط فضای ذخیره‌سازی 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 در پارتیشن 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

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

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

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

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

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

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

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

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

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