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

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

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

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

احتیاط : در اندروید 7.0 تا 8.1، FBE با فضای ذخیره‌سازی قابل قبول سازگار نیست و رسانه‌های ذخیره‌سازی خارجی (مانند کارت SD) فقط می‌توانند به عنوان حافظه سنتی استفاده شوند. در اندروید 9 و بالاتر، FBE با فضای ذخیره سازی قابل قبول سازگار است.

بوت مستقیم

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

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

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

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

توجه : در صورت امکان، فایل ها باید در فضای ذخیره سازی CE قرار گیرند.

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

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

احتیاط : از آنجایی که گزینه fileencryption قالب روی دیسک را تعریف می کند، نمی توان آن را با OTA تغییر داد.

به طور پیش فرض، رمزگذاری محتویات فایل با استفاده از 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

توجه :

• گزینه‌های inlinecrypt و fileencryption در ستون‌های مختلف قرار می‌گیرند، زیرا inlinecrypt یک گزینه نصب سیستم فایل است، در حالی که fileencryption یک پرچم برای فضای کاربران اندروید است.
• اگر سخت افزار رمزگذاری درون خطی شما درست کار می کند و پرچم wrappedkey_v0 تنظیم نشده است، گزینه inlinecrypt mount را می توان در هر زمانی بدون پاک کردن دستگاه اضافه یا حذف کرد. به عبارت دیگر، مگر اینکه کلیدهای بسته‌بندی شده با سخت‌افزار فعال باشند، inlinecrypt تنها باید بر روی پیاده‌سازی تأثیر بگذارد، نه بر روی قالب روی دیسک. شما باید حذف inlinecrypt در طول توسعه آزمایش کنید تا مطمئن شوید که سخت افزار رمزگذاری درون خطی شما به درستی کار می کند.

ذخیره سازی قابل قبول

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

احتیاط : در دستگاه‌هایی که با Android 10 یا پایین‌تر راه‌اندازی شده‌اند، حالت پیش‌فرض رمزگذاری نام فایل‌ها در فضای ذخیره‌سازی قابل قبول در اکثر دستگاه‌ها معتبر نبود و با حالت پیش‌فرض در حافظه داخلی متفاوت بود. بنابراین، در چنین دستگاه هایی باید به صراحت، معمولاً به aes-256-cts رد شود.

ادغام با 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 و دایرکتوری هایی را که محافظت می کنند با جزئیات بیشتری فهرست می کند:

کلاس ذخیره سازی	توضیحات	دایرکتوری ها
رمزگذاری نشده	دایرکتوری‌هایی در /data که نمی‌توانند توسط FBE محافظت شوند یا نیازی به محافظت ندارند. در دستگاه‌هایی که از رمزگذاری ابرداده استفاده می‌کنند، این دایرکتوری‌ها واقعاً رمزگذاری نشده نیستند، بلکه توسط کلید رمزگذاری ابرداده که معادل System DE است محافظت می‌شوند.	/data/apex ، به استثنای /data/apex/decompressed و /data/apex/ota_reserved که سیستم DE هستند /data/lost+found /data/preloads /data/unencrypted همه دایرکتوری هایی که زیرشاخه های آنها از کلیدهای مختلف FBE استفاده می کنند. به عنوان مثال، از آنجایی که هر دایرکتوری /data/user/${user_id} از یک کلید برای هر کاربر استفاده می کند، /data/user خود از هیچ کلیدی استفاده نمی کند.
سیستم DE	داده های رمزگذاری شده توسط دستگاه به کاربر خاصی مرتبط نیست	/data/apex/decompressed /data/apex/ota_reserved /data/app /data/misc /data/system /data/vendor همه زیرشاخه‌های دیگر /data که این جدول به آنها اشاره نمی‌کند دارای کلاس متفاوتی هستند
هر بوت	فایل های سیستمی زودگذر که نیازی به راه اندازی مجدد ندارند	/data/per_boot
کاربر CE (داخلی)	داده های رمزگذاری شده با اعتبار هر کاربر در حافظه داخلی	/data/data (نام مستعار /data/user/0 ) /data/media/${user_id} /data/misc_ce/${user_id} /data/system_ce/${user_id} /data/user/${user_id} /data/vendor_ce/${user_id}
کاربر DE (داخلی)	داده های رمزگذاری شده توسط هر کاربر در حافظه داخلی	/data/misc_de/${user_id} /data/system_de/${user_id} /data/user_de/${user_id} /data/vendor_de/${user_id}
کاربر CE (قابل پذیرش)	داده های رمزگذاری شده با اعتبار هر کاربر در فضای ذخیره سازی قابل قبول	/mnt/expand/${volume_uuid}/media/${user_id} /mnt/expand/${volume_uuid}/misc_ce/${user_id} /mnt/expand/${volume_uuid}/user/${user_id}
کاربر DE (قابل پذیرش)	داده های رمزگذاری شده توسط دستگاه برای هر کاربر در فضای ذخیره سازی قابل قبول	/mnt/expand/${volume_uuid}/misc_de/${user_id} /mnt/expand/${volume_uuid}/user_de/${user_id}

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

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

نوع کلید	مکان کلیدی	کلاس ذخیره سازی مکان کلید
کلید سیستم DE	/data/unencrypted	رمزگذاری نشده
کلیدهای CE (داخلی) کاربر	/data/misc/vold/user_keys/ce/${user_id}	سیستم DE
کلیدهای DE (داخلی) کاربر	/data/misc/vold/user_keys/de/${user_id}	سیستم DE
کلیدهای CE کاربر (قابل پذیرش).	/data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid}	کاربر CE (داخلی)
کلیدهای DE کاربر (قابل پذیرش).	/data/misc_de/${user_id}/vold/volume_keys/${volume_uuid}	کاربر DE (داخلی)

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

احتیاط : در اندروید 7.0 تا 8.1، FBE با فضای ذخیره‌سازی قابل قبول سازگار نیست و رسانه‌های ذخیره‌سازی خارجی (مانند کارت SD) فقط می‌توانند به عنوان حافظه سنتی استفاده شوند. در اندروید 9 و بالاتر، FBE با فضای ذخیره سازی قابل قبول سازگار است.

بوت مستقیم

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

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

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

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

توجه : در صورت امکان، فایل ها باید در فضای ذخیره سازی CE قرار گیرند.

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

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 ساخته شوند.

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

پشتیبانی هسته برای رمزگذاری 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 یا بالاتر راه اندازی می شوند ، این حالت دیگر مجاز نیست و به جای آن باید از قالب رمزگذاری استاندارد استفاده شود.

احتیاط : از آنجا که گزینه fileencryption فرمت روی دیسک را تعریف می کند ، توسط OTA قابل تغییر نیست.

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

توجه :

• گزینه های inlinecrypt و fileencryption در ستون های مختلف قرار می گیرند ، زیرا inlinecrypt یک گزینه Movey System Mount است در حالی که fileencryption یک پرچم برای فضای کاربری Android است.
• اگر سخت افزار رمزگذاری درون خطی شما به درستی کار می کند و پرچم wrappedkey_v0 تنظیم نشده است ، می توانید در هر زمان و بدون پاک کردن دستگاه ، گزینه نصب inlinecrypt را اضافه یا حذف کنید. به عبارت دیگر ، مگر اینکه کلیدهای بسته بندی شده با سخت افزار فعال شوند ، inlinecrypt فقط باید روی اجرای تأثیر بگذارد ، نه قالب دیسک. شما باید در طول توسعه حذف inlinecrypt را آزمایش کنید تا تأیید کنید که سخت افزار رمزگذاری درون خطی شما به درستی کار می کند.

ذخیره سازی قابل تصویب

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

احتیاط : در دستگاه هایی که با Android 10 یا Lower راه اندازی شده اند ، حالت رمزگذاری نام های پیش فرض نام خانوادگی در ذخیره سازی قابل قبول در اکثر دستگاه ها معتبر نبود و با حالت پیش فرض در حافظه داخلی متفاوت بود. بنابراین ، در چنین دستگاه هایی باید صریحاً نادیده گرفته شود ، معمولاً برای aes-256-cts .

ادغام با 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 و دایرکتوری که آنها با جزئیات بیشتری از آنها محافظت می کنند ذکر شده است:

کلاس ذخیره سازی	توضیحات	دایرکتوری ها
عود	دایرکتوری ها در /data که نمی توانند توسط FBE محافظت شوند یا نیازی به محافظت نباشند. در دستگاه هایی که از رمزگذاری ابرداده استفاده می کنند ، این دایرکتوری ها واقعاً رمزگذاری نشده اند بلکه توسط کلید رمزگذاری ابرداده که معادل System DE است ، محافظت می شوند.	/data/apex ، به استثنای /data/apex/decompressed و /data/apex/ota_reserved که سیستم DE هستند /data/lost+found /data/preloads /data/unencrypted تمام دایرکتوری هایی که زیر مجموعه های آنها از کلیدهای مختلف FBE استفاده می کنند. به عنوان مثال ، از آنجا که هر /data/user/${user_id} دایرکتوری از یک کلید برای هر کاربر استفاده می کند ، /data/user از خود کلید استفاده نمی کند.
سیستم	داده های رمزگذاری شده توسط دستگاه به یک کاربر خاص گره خورده است	/data/apex/decompressed /data/apex/ota_reserved /data/app /data/misc /data/system /data/vendor تمام زیر مجموعه های دیگر /data که این جدول به عنوان داشتن یک کلاس متفاوت ذکر نمی کند
هر بوت	پرونده های سیستم زودگذر که نیازی به زنده ماندن از راه اندازی مجدد ندارند	/data/per_boot
کاربر CE (داخلی)	داده های رمزگذاری شده برای هر کاربر در مورد ذخیره داخلی	/data/data (نام مستعار /data/user/0 ) /data/media/${user_id} /data/misc_ce/${user_id} /data/system_ce/${user_id} /data/user/${user_id} /data/vendor_ce/${user_id}
کاربر د (داخلی)	داده های رمزگذاری شده توسط دستگاه برای هر کاربر در حافظه داخلی	/data/misc_de/${user_id} /data/system_de/${user_id} /data/user_de/${user_id} /data/vendor_de/${user_id}
کاربر CE (قابل قبول)	داده های رمزگذاری شده برای هر کاربر در مورد ذخیره قابل قبول	/mnt/expand/${volume_uuid}/media/${user_id} /mnt/expand/${volume_uuid}/misc_ce/${user_id} /mnt/expand/${volume_uuid}/user/${user_id}
کاربر د (قابل قبول)	داده های رمزگذاری شده برای هر کاربر در ذخیره سازی قابل استفاده	/mnt/expand/${volume_uuid}/misc_de/${user_id} /mnt/expand/${volume_uuid}/user_de/${user_id}

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

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

نوع کلیدی	محل اصلی	کلاس ذخیره سازی مکان کلیدی
سیستم دن	/data/unencrypted	عود
کلیدهای کاربر (داخلی)	/data/misc/vold/user_keys/ce/${user_id}	سیستم
کلیدهای کاربر (داخلی)	/data/misc/vold/user_keys/de/${user_id}	سیستم
کلیدهای کاربر CE (قابل قبول)	/data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid}	کاربر CE (داخلی)
کلیدهای کاربر DE (قابل قبول)	/data/misc_de/${user_id}/vold/volume_keys/${volume_uuid}	کاربر د (داخلی)

همانطور که در جدول قبلی نشان داده شده است ، بیشتر کلیدهای 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 تا 8.1 ، FBE با ذخیره سازی قابل قبول سازگار نیست و رسانه های ذخیره سازی خارجی (مانند کارت SD) فقط به عنوان ذخیره سازی سنتی قابل استفاده است. در Android 9 و بالاتر ، FBE با ذخیره سازی قابل قبول سازگار است.

چکمه مستقیم

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

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

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

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

توجه : هر زمان ممکن است ، پرونده ها باید در CE ذخیره سازی ساکن شوند.

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

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 ). در دستگاه های بدون هیچ نوع شتاب AES ، می توان به جای AES با تنظیم fileencryption=adiantum Adiantum به جای AES استفاده کرد.

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

Caution : Since the fileencryption option defines the on-disk format, it cannot be changed by an OTA.

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

توجه :

• The inlinecrypt and fileencryption options go in different columns, since inlinecrypt is a filesystem mount option whereas fileencryption is a flag for Android userspace.
• If your inline encryption hardware works correctly and the wrappedkey_v0 flag isn't set, the inlinecrypt mount option can be added or removed at any time without wiping the device. In other words, unless hardware-wrapped keys are enabled, inlinecrypt should only affect the implementation, not the on-disk format. You should test removing inlinecrypt during development to verify that your inline encryption hardware is working correctly.

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 .

Caution : On devices that launched with Android 10 or lower, the default filenames encryption mode on adoptable storage was not valid on most devices, and it differed from the default mode on internal storage. Therefore, on such devices it must be explicitly overridden, usually to aes-256-cts .

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:

Storage class	توضیحات	دایرکتوری ها
Unencrypted	Directories in /data that can't be or don't need to be protected by FBE. On devices that use metadata encryption , these directories aren't truly unencrypted but rather are protected by the metadata encryption key which is equivalent to System DE.	/data/apex , excluding /data/apex/decompressed and /data/apex/ota_reserved which are system DE /data/lost+found /data/preloads /data/unencrypted All directories whose subdirectories use different FBE keys. For example, since each /data/user/${user_id} directory uses a per-user key, /data/user uses no key itself.
System DE	Device-encrypted data not tied to a particular user	/data/apex/decompressed /data/apex/ota_reserved /data/app /data/misc /data/system /data/vendor All other subdirectories of /data that this table doesn't mention as having a different class
Per-boot	Ephemeral system files that don't need to survive a reboot	/data/per_boot
User CE (internal)	Per-user credential-encrypted data on internal storage	/data/data (alias of /data/user/0 ) /data/media/${user_id} /data/misc_ce/${user_id} /data/system_ce/${user_id} /data/user/${user_id} /data/vendor_ce/${user_id}
User DE (internal)	Per-user device-encrypted data on internal storage	/data/misc_de/${user_id} /data/system_de/${user_id} /data/user_de/${user_id} /data/vendor_de/${user_id}
User CE (adoptable)	Per-user credential-encrypted data on adoptable storage	/mnt/expand/${volume_uuid}/media/${user_id} /mnt/expand/${volume_uuid}/misc_ce/${user_id} /mnt/expand/${volume_uuid}/user/${user_id}
User DE (adoptable)	Per-user device-encrypted data on adoptable storage	/mnt/expand/${volume_uuid}/misc_de/${user_id} /mnt/expand/${volume_uuid}/user_de/${user_id}

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:

Key type	Key location	Storage class of key location
System DE key	/data/unencrypted	Unencrypted
User CE (internal) keys	/data/misc/vold/user_keys/ce/${user_id}	System DE
User DE (internal) keys	/data/misc/vold/user_keys/de/${user_id}	System DE
User CE (adoptable) keys	/data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid}	User CE (internal)
User DE (adoptable) keys	/data/misc_de/${user_id}/vold/volume_keys/${volume_uuid}	User DE (internal)

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.