این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

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

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

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

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

بوت مستقیم

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

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

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

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

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

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

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

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

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

مثال ها و منبع

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

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

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

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

وابستگی ها

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

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

پیاده سازی

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

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

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

CONFIG_FS_ENCRYPTION=y

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

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

علاوه بر پشتیبانی عملکردی از رمزگذاری Ext4 یا F2FS، سازندگان دستگاه باید شتاب رمزنگاری را برای سرعت بخشیدن به رمزگذاری مبتنی بر فایل و بهبود تجربه کاربر فعال کنند. برای مثال، در دستگاه‌های مبتنی بر ARM64، شتاب ARMv8 CE (افزونه‌های رمزنگاری) را می‌توان با تنظیم گزینه‌های پیکربندی هسته زیر فعال کرد:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

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

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

اگر دستگاه شما از فضای ذخیره سازی مبتنی بر UFS استفاده می کند، این موارد را نیز فعال کنید:

CONFIG_SCSI_UFS_CRYPTO=y

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

CONFIG_MMC_CRYPTO=y

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

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

حافظه داخلی

FBE با افزودن گزینه fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] به ستون fs_mgr_flags خط fstab برای userdata فعال می‌شود. این گزینه فرمت رمزگذاری را در حافظه داخلی تعریف می کند. این شامل حداکثر سه پارامتر جدا شده با کولون است:

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

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

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

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

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

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

توجه :

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

ادغام با 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 نیاز به بازیابی دارد:

یک دایرکتوری سطح بالا (به عنوان مثال misc_ne ) در پارتیشن userdata ایجاد کنید.
این دایرکتوری سطح بالا را طوری پیکربندی کنید که رمزگذاری نشده باشد (به حذف دایرکتوری ها مراجعه کنید).
یک دایرکتوری در دایرکتوری سطح بالا برای نگهداری بسته های OTA ایجاد کنید.
برای کنترل دسترسی به این دایرکتوری و محتویات آن، یک قانون 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 ندارد اعمال می شود.