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

اندروید 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-cts باشد aes-256-xts 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 استفاده شود.

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

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

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

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

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

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

از آنجایی که اندروید 9، FBE و فضای ذخیره سازی قابل قبول را می توان با هم استفاده کرد.

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

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

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

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

• ro.crypto.volume.contents_mode حالت رمزگذاری محتویات را انتخاب می کند. این معادل اولین فیلد جدا شده با کولون ro.crypto.volume.options است.
• ro.crypto.volume.filenames_mode حالت رمزگذاری نام فایل ها را انتخاب می کند. این معادل دومین فیلد جدا شده با دو نقطه ro.crypto.volume.options است، با این تفاوت که پیش‌فرض در دستگاه‌هایی که با Android 10 یا پایین‌تر راه‌اندازی می‌شوند aes-256-heh است. در اکثر دستگاه‌ها، این باید به طور صریح به aes-256-cts نادیده گرفته شود.
• ro.crypto.fde_algorithm و ro.crypto.fde_sector_size قالب رمزگذاری ابرداده را در فضای ذخیره سازی قابل قبول انتخاب کنید. به مستندات رمزگذاری فراداده مراجعه کنید.

ادغام با Keymaster

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

به استثنای دایرکتوری ها

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

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

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

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

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

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

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

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

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

آگاه سازی برنامه های کاربردی 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 تنظیم شده است

به‌علاوه، آزمایش‌کنندگان می‌توانند یک نمونه userdebug با یک صفحه قفل تنظیم شده روی کاربر اصلی راه‌اندازی کنند. سپس adb داخل دستگاه شل کنید و su استفاده کنید تا روت شوید. مطمئن شوید که /data/data حاوی نام فایل های رمزگذاری شده باشد. اگر این کار را نکرد، چیزی اشتباه است.

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

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

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

رمزگذاری fscrypt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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