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

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

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

بوت مستقیم

رمزگذاری مبتنی بر فایل ویژگی جدیدی را فعال می‌کند که در اندروید ۷.۰ به نام 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 یا 2.0. هیچ پشتیبانی برای Keymaster 0.3 وجود ندارد، زیرا این قابلیت های لازم را فراهم نمی کند یا حفاظت کافی برای کلیدهای رمزگذاری را تضمین نمی کند.
• Keymaster/ Keystore و Gatekeeper باید در یک محیط اجرای مورد اعتماد (TEE) پیاده سازی شوند تا از کلیدهای DE محافظت کنند تا یک سیستم عامل غیرمجاز (سیستم عامل سفارشی که روی دستگاه فلش شده است) نتواند به سادگی کلیدهای DE را درخواست کند.
• Hardware Root of Trust و Verified Boot متصل به راه‌اندازی اولیه keymaster برای اطمینان از عدم دسترسی به اعتبارنامه Device Encryption توسط یک سیستم عامل غیرمجاز لازم است.

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

پیاده سازی

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

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

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

CONFIG_FS_ENCRYPTION=y

برای هسته‌های قدیمی‌تر، اگر سیستم فایل داده‌های userdata دستگاه شما Ext4 است، از CONFIG_EXT4_ENCRYPTION=y یا اگر سیستم فایل داده کاربر دستگاهتان userdata است، از 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- 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 استفاده شود.

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

از Android 14 (تجربی AOSP)، 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

تولید کلیدها و مدیریت کلیدهای هسته توسط vold انجام می شود. اجرای AOSP FBE مستلزم آن است که دستگاه از Keymaster HAL نسخه 1.0 یا بالاتر پشتیبانی کند. هیچ پشتیبانی از نسخه های قبلی Keymaster HAL وجود ندارد.

در اولین بوت، کلیدهای کاربر 0 در مراحل اولیه بوت تولید و نصب می شوند. تا زمانی که مرحله on-post-fs init کامل شود، Keymaster باید برای رسیدگی به درخواست‌ها آماده باشد. در دستگاه‌های Pixel، این کار با داشتن یک بلوک اسکریپت انجام می‌شود که اطمینان حاصل شود Keymaster قبل از نصب /data راه‌اندازی شده است.

خط مشی رمزگذاری

رمزگذاری مبتنی بر فایل، خط مشی رمزگذاری را در سطح دایرکتوری اعمال می کند. هنگامی که برای اولین بار پارتیشن داده های userdata یک دستگاه ایجاد می شود، ساختارها و سیاست های اساسی توسط اسکریپت های init اعمال می شوند. این اسکریپت ها باعث ایجاد کلیدهای CE و DE اولین کاربر (کاربر 0) می شوند و همچنین مشخص می کنند که کدام دایرکتوری ها باید با این کلیدها رمزگذاری شوند. هنگامی که کاربران و پروفایل های اضافی ایجاد می شوند، کلیدهای اضافی لازم تولید و در فروشگاه کلید ذخیره می شوند. مکان‌های ذخیره‌سازی اطلاعات و دستگاه‌های آنها ایجاد می‌شود و خط‌مشی رمزگذاری این کلیدها را به آن فهرست‌ها پیوند می‌دهد.

در اندروید 11 و بالاتر، خط مشی رمزگذاری دیگر در یک مکان متمرکز کدگذاری نمی‌شود، بلکه با آرگومان‌های دستورات mkdir در اسکریپت‌های init تعریف می‌شود. دایرکتوری های رمزگذاری شده با کلید DE سیستم از encryption=Require استفاده می کنند، در حالی که دایرکتوری های رمزگذاری نشده (یا دایرکتوری هایی که زیرشاخه های آنها با کلیدهای هر کاربر رمزگذاری شده اند) از encryption=None استفاده می کنند.

در Android 10، خط مشی رمزگذاری در این مکان کدگذاری شد:

/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 قدیمی، که برای دسترسی به فایل 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، به مستندات هسته بالادستی مراجعه کنید.

مشتق کلید

کلیدهای رمزگذاری مبتنی بر فایل، که کلیدهای 512 بیتی هستند، توسط کلید دیگری (یک کلید AES-GCM 256 بیتی) که در TEE نگهداری می شود، رمزگذاری شده ذخیره می شوند. برای استفاده از این کلید TEE، سه شرط باید برآورده شود:

• نشانه تایید
• اعتبار کشیده شده
• "هش قابل حذف"

رمز تأیید یک رمز تأیید شده رمزنگاری شده است که توسط Gatekeeper هنگام ورود موفقیت آمیز کاربر ایجاد می شود. TEE از استفاده از کلید خودداری می کند مگر اینکه رمز تأیید صحیح ارائه شود. اگر کاربر هیچ اعتباری نداشته باشد، پس از آن هیچ نشانه احراز هویت استفاده نمی شود و نیازی نیست.

اعتبار کشیده شده، اعتبار کاربری پس از نمک و کشش با الگوریتم scrypt است. اعتبارنامه در واقع یک بار در سرویس تنظیمات قفل هش می شود قبل از اینکه برای ارسال به scrypt vold شود. این از نظر رمزنگاری به کلید موجود در TEE با تمام ضمانت‌های مربوط به KM_TAG_APPLICATION_ID است. اگر کاربر هیچ اعتباری نداشته باشد، پس از آن هیچ اعتبار طولانی استفاده نمی شود و نیازی نیست.

secdiscardable hash یک هش 512 بیتی از یک فایل تصادفی 16 کیلوبایتی است که در کنار سایر اطلاعات مورد استفاده برای بازسازی کلید، مانند دانه، ذخیره شده است. این فایل هنگام حذف کلید به طور ایمن حذف می شود یا به روشی جدید رمزگذاری می شود. این حفاظت افزوده تضمین می کند که مهاجم باید تک تک این فایل پاک شده را برای بازیابی کلید بازیابی کند. این از نظر رمزنگاری به کلید موجود در TEE با تمام ضمانت‌های مربوط به KM_TAG_APPLICATION_ID است.

در بیشتر موارد، کلیدهای FBE نیز تحت یک مرحله مشتق کلید اضافی در هسته قرار می گیرند تا کلیدهای فرعی که واقعاً برای انجام رمزگذاری استفاده می شوند، به عنوان مثال کلیدهای هر فایل یا هر حالت، تولید شوند. برای سیاست های رمزگذاری نسخه 2، از HKDF-SHA512 برای این کار استفاده می شود.