التشفير على مستوى الملفات

يتيح الإصدار 7.0 من نظام التشغيل Android والإصدارات الأحدث ميزة "التشفير على مستوى الملفات". يتيح التشفير المستند إلى الملفات تشفير الملفات المختلفة باستخدام مفاتيح مختلفة يمكن فتحها بشكل مستقل.

توضّح هذه المقالة كيفية تفعيل التشفير المستند إلى الملفات على الأجهزة الجديدة، وكيفية استخدام تطبيقات النظام لواجهات برمجة التطبيقات Direct Boot API لتقديم أفضل تجربة ممكنة وأكثرها أمانًا للمستخدمين.

يجب استخدام التشفير المستنِد إلى الملفات على جميع الأجهزة التي تعمل بالإصدار 10 من نظام التشغيل Android والإصدارات الأحدث.

التشغيل المباشر

يتيح التشفير المستند إلى الملفات ميزة جديدة تم تقديمها في Android 7.0 تُعرف باسم Direct Boot. يتيح "التشغيل المباشر" للأجهزة المشفرة بالتمهيد مباشرةً إلى شاشة القفل. في السابق، على الأجهزة المشفَّرة التي تستخدم تشفير القرص بالكامل (FDE)، كان على المستخدمين تقديم بيانات الاعتماد قبل التمكّن من الوصول إلى أي بيانات، ما يمنع الهاتف من تنفيذ جميع العمليات إلا أبسطها. على سبيل المثال، تعذّر تشغيل أجهزة الإنذار، وعدم توفّر خدمات تسهيل الاستخدام، وعدم قدرة الهواتف على استقبال المكالمات، ولكنّها كانت تقتصر على العمليات الأساسية لبرامج الاتصال في حالات الطوارئ.

مع إدخال التشفير المستند إلى الملفات (FBE) وواجهات برمجة التطبيقات الجديدة لإعلام التطبيقات بالتشفير، من الممكن أن تعمل هذه التطبيقات في سياق محدود. ويمكن أن يحدث ذلك قبل أن يقدّم المستخدمون بيانات الاعتماد الخاصة بهم مع الحفاظ على حماية معلومات المستخدمين الخاصة.

على جهاز مزوّد بميزة "التشفير من جهة العميل"، يحصل كل مستخدم على مساحة تخزين في مكانين متاحَين للتطبيقات:

• مساحة تخزين بيانات الاعتماد المشفَّرة (CE)، وهي موقع التخزين التلقائي ولا تتوفّر إلا بعد أن يفتح المستخدم قفل الجهاز.
• مساحة التخزين المشفَّرة على الجهاز (DE)، وهي موقع تخزين متاح أثناء وضع "التشغيل المباشر" وبعد أن يفتح المستخدم قفل الجهاز

يجعل هذا الفصل الملفات الشخصية للعمل أكثر أمانًا لأنه يسمح بحماية أكثر من مستخدم في وقت واحد، حيث لم يعد التشفير يعتمد فقط على كلمة مرور وقت التشغيل.

تسمح واجهة برمجة التطبيقات Direct Boot API للتطبيقات المتوافقة مع التشفير بالوصول إلى كلٍّ من هذه المناطق. هناك تغييرات في دورة حياة التطبيق لاستيعاب الحاجة إلى إرسال إشعارات إلى التطبيقات عند فتح قفل وحدة تخزين CE لدى المستخدم استجابةً لإدخال بيانات الاعتماد لأول مرة على شاشة القفل أو عند تقديم ملف العمل تحدى عمل. يجب أن تتوافق الأجهزة التي تعمل بنظام التشغيل Android 7.0 مع واجهات برمجة التطبيقات الجديدة هذه ومراحل التطوير المختلفة بغض النظر عمّا إذا كانت توفّر ميزة "التشفير من جهة العميل" أم لا. ومع ذلك، بدون FBE، تكون سعة تخزين DE وCE دائمًا في حالة فتح القفل.

يتوفّر في "المشروع المفتوح المصدر لنظام Android" (AOSP) التنفيذ الكامل للتشفير المستند إلى الملفات على نظامي الملفات Ext4 وF2FS، ولا يجب تفعيله إلا على الأجهزة التي تستوفي المتطلبات. يمكن للمصنعين الذين يختارون استخدام FBE استكشاف طرق تحسين الميزة استنادًا إلى المنظومة على الرقاقة (SoC) المستخدَمة.

تم تعديل جميع الحِزم اللازمة في AOSP لتكون على دراية مباشرة بالتمهيد. ومع ذلك، عندما تستخدم الشركات المصنّعة للأجهزة إصدارات مخصّصة من هذه التطبيقات، فإنّها تريد ضمان توفّر حِزم جاهزة للتشغيل المباشر على الأقل توفّر الخدمات التالية:

• خدمات الاتصال الهاتفي وتطبيق "برنامج الاتصال"
• طريقة إدخال كلمات المرور في شاشة القفل

الأمثلة والمصدر

يوفّر Android طريقة تنفيذ مرجعية للتشفير المستند إلى الملفات، حيث توفّر شركة vold (system/vold) وظيفة إدارة أجهزة التخزين والأحجام على Android. توفّر إضافة FBE لنظام vold عدة أوامر جديدة لتفعيل إدارة مفاتيح التشفير لمفتاحَي التشفير وفك التشفير لمستخدمين متعدّدين. بالإضافة إلى التغييرات الأساسية لاستخدام إمكانات التشفير المبرمَجة في ملف الترميز في kernel، تم تعديل العديد من حِزم النظام، بما في ذلك شاشة القفل وSystemUI، لتتوافق مع ميزتَي FBE وDirect Boot. ومن بينها:

• AOSP Dialer (الحزم/التطبيقات/برنامج الاتصال)
• Desk Clock (packages/apps/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• تطبيق الإعدادات (الحزم/التطبيقات/الإعدادات)*
• SystemUI (أطر العمل/الأساسية/الحزم/SystemUI)*

* تطبيقات النظام التي تستخدم defaultToDeviceProtectedStorageسمة manifest

يمكن العثور على مزيد من الأمثلة على التطبيقات والخدمات التي تتضمّن ميزة التشفير من خلال تنفيذ الأمر mangrep directBootAware في directory frameworks أو packages ضمن شجرة المصدر AOSP .

التبعيات

لاستخدام تنفيذ AOSP من FBE بأمان، يجب أن يستوفي الجهاز التبعيات التالية:

• توافق مع النواة لتشفير Ext4 أو تشفير F2FS
• دعم Keymaster مع الإصدار 1.0 من HAL أو إصدار أحدث. لا يتوفر الإصدار 0.3 من Keymaster لأنه لا يوفر الإمكانات اللازمة أو يضمن حماية كافية لمفاتيح التشفير.
• يجب تنفيذ Keymaster/Keystore و Gatekeeper في بيئة تنفيذ موثوق بها (TEE) لتوفير الحماية لمفاتيح DE كي لا يتمكّن نظام التشغيل غير المصرّح به (نظام التشغيل المخصّص الذي تم تثبيته على الجهاز) من طلب مفاتيح DE بكل بساطة.
• يجب أن يكون جذر الثقة في الأجهزة والتشغيل المتحقّق منه مرتبطَين بإعداد Keymaster لضمان عدم وصول نظام تشغيل غير مصرَّح به إلى مفاتيح DE.

أولاً وقبل كل شيء، يجب أن تكون التطبيقات، مثل المنبّهات والهاتف وميزات تسهيل الاستخدام، مزوّدة بالعلامة android:directBootAware وفقًا لمستندات المطوّرين حول Direct Boot.

دعم Kernel

يتوفّر دعم النواة لتشفير Ext4 وF2FS في نواة Android الشائعة (الإصدار 3.18 والإصدارات الأحدث). لتفعيلها في نواة بإصدار 5.1 أو أعلى، استخدِم:

CONFIG_FS_ENCRYPTION=y

بالنسبة إلى النوى القديمة، استخدِم CONFIG_EXT4_ENCRYPTION=y إذا كان نظام ملفاتك في userdata الجهاز هو Ext4، أو استخدِم CONFIG_F2FS_FS_ENCRYPTION=y إذا كان نظام ملفاتك في userdata الجهاز هو F2FS.

إذا كان جهازك متوافقًا مع ميزة التخزين القابل للتخصيص أو يستخدم ميزة تشفير البيانات الوصفية في مساحة التخزين الداخلية، عليك أيضًا تفعيل خيارات ضبط kernel اللازمة لتشفير البيانات الوصفية كما هو موضّح في مستندات تشفير البيانات الوصفية.

بالإضافة إلى التوافق الوظيفي لتشفير Ext4 أو F2FS، على الشركات المصنّعة للأجهزة أيضًا تفعيل تسريع التشفير لتسريع التشفير المستند إلى الملفات وتحسين تجربة المستخدم. على سبيل المثال، على الأجهزة المستندة إلى ARM64، يمكن تفعيل تسريع ARMv8 CE (إضافات التشفير) من خلال ضبط خيارات ضبط kernel التالية:

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

تفعيل التشفير على مستوى الملفات

يتطلب تفعيل ميزة "التشفير من جهة العميل" على جهاز ما تفعيلها على مساحة التخزين الداخلية (userdata). يؤدي ذلك أيضًا إلى تفعيل ميزة "التشفير من جهة العميل" تلقائيًا على مساحة التخزين القابلة للتخصيص، ولكن يمكن إلغاء تنسيق التشفير على مساحة التخزين القابلة للتخصيص إذا لزم الأمر.

وحدة التخزين الداخلية

يتم تفعيل FBE من خلال إضافة الخيار fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] إلى عمود fs_mgr_flags في سطر fstab لملف ‎userdata. يحدّد هذا الخيار تنسيق التشفير على وحدة التخزين الداخلية. يحتوي على ما يصل إلى ثلاث معلمات مفصولة بنقطتين:

• تحدِّد المعلَمة contents_encryption_mode خوارزمية التشفير المستخدمة لتشفير محتوى الملف. ويمكن أن تكون إما aes-256-xts أو adiantum. وبما أنّه نظام التشغيل Android 11، يمكن أيضًا ترك هذا الحقل فارغًا لتحديد الخوارزمية التلقائية، وهي aes-256-xts.
• تحدِّد المعلَمة filenames_encryption_mode خوارزمية التشفير المستخدمة لتشفير أسماء الملفات. يمكن أن يكون إما aes-256-cts أو aes-256-heh أو adiantum أو aes-256-hctr2. إذا لم يتم تحديده، يتم ضبطه تلقائيًا على aes-256-cts إذا كان contents_encryption_mode هو aes-256-xts، أو على adiantum إذا كان contents_encryption_mode هو adiantum.
• أمّا المعلمة flags، وهي الجديدة في الإصدار 11 من نظام Android، فهي قائمة بالعلامات مفصولة بالحرف +. يمكن استخدام العلامات التالية:
  • تختار العلامة v1 سياسات التشفير للإصدار 1، وتختار العلامة v2 سياسات التشفير للإصدار 2. تستخدم سياسات التشفير في الإصدار 2 وظيفة اشتقاق مفاتيح أكثر أمانًا ومرونة. ويكون الإصدار التلقائي هو الإصدار 2 إذا كان الجهاز يعمل بالإصدار 11 من نظام التشغيل Android أو الإصدارات الأحدث (وفقًا لما يحدّده تطبيق ro.product.first_api_level)، أو الإصدار 1 إذا تم تشغيل الجهاز بنظام 10 Android أو إصدار أقدم.
  • تختار العلامة inlinecrypt_optimized تنسيق تشفير مُحسَّنًا لأجهزة التشفير المضمّنة التي لا تتمكّن من معالجة أعداد كبيرة من المفاتيح بكفاءة. ويتم ذلك من خلال اشتقاق مفتاح تشفير محتوى ملف واحد فقط لكل مفتاح تشفير أو فك تشفير، بدلاً من مفتاح واحد لكل ملف. ويتم تعديل عمليات إنشاء IVs (متّجهات الإعداد) وفقًا لذلك.
  • تشبه علامة emmc_optimized العلامة inlinecrypt_optimized، ولكنّها تختار أيضًا طريقة الجيل الرابع الذي يحدّ من الإحالات الناجحة الناتجة عن IV إلى 32 بت. يجب استخدام هذه العلامة فقط على أجهزة التشفير المضمّنة المتوافقة مع مواصفات JEDEC eMMC v5.2، وبالتالي لا تتوافق إلا مع أرقام البدء التي تبلغ 32 بت. على أجهزة التشفير المضمّن الأخرى، استخدِم inlinecrypt_optimized بدلاً من ذلك. يجب عدم استخدام هذا الإعداد أبدًا في مساحة التخزين المستندة إلى UFS، لأنّ مواصفات UFS تسمح باستخدام قيم البدء التي تبلغ 64 بت.
  • بالنسبة إلى الأجهزة المتوافقة مع المفاتيح الملفوفة للأجهزة، تتيح العلامة wrappedkey_v0 استخدام مفاتيح ملفوفة للأجهزة من أجل FBE. لا يمكن استخدام هذا الخيار إلا مع خيار التركيب inlinecrypt وعلامة inlinecrypt_optimized أو emmc_optimized .
  • تفرض العلامة dusize_4k حجم وحدة بيانات التشفير على أن يكون 4096 بايت حتى إذا لم يكن حجم كتلة نظام الملفات 4096 بايت. حجم وحدة بيانات التشفير هو مدى الدقة في تشفير محتوى الملف. تتوفّر هذه العلامة منذ الإصدار 15 من Android. يجب عدم استخدام هذه العلامة إلا لإتاحة استخدام أجهزة التشفير المضمّن التي لا تتوافق مع وحدات البيانات التي يزيد حجمها عن 4096 بايت، على جهاز يستخدم حجم صفحة أكبر من 4096 بايت ويستخدِم نظام الملفات f2fs.

إذا كنت لا تستخدم أجهزة التشفير المضمّن، يكون الإعداد المُقترَح لمعظم الأجهزة هو 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 هو الوضع المفضّل لتشفير أسماء الملفات في الأجهزة التي تستخدم تعليمات التشفير السريع. ومع ذلك، لا تتيح سوى نواة Android الأحدث استخدام ملف ‎AES-HCTR2. وفي إصدار Android مستقبلي، من المخطّط أن يصبح هذا الوضع هو الوضع التلقائي لتشفير أسماء الملفات. إذا كانت النواة متوافقة مع معيار AES-HCTR2، يمكن تفعيلها لتشفير أسماء الملفات من خلال ضبط filenames_encryption_mode على aes-256-hctr2. في أبسط الحالات، يمكن إجراء ذلك باستخدام fileencryption=aes-256-xts:aes-256-hctr2.

على الأجهزة التي تعمل بنظام التشغيل Android 10 أو الإصدارات الأقدم، يُقبل fileencryption=ice أيضًا لتحديد طريقة استخدام وضع تشفير محتوى ملفات FSCRYPT_MODE_PRIVATE. لا يتم تنفيذ هذا الوضع بواسطة نواة Android الشائعة، لكن يمكن للبائعين تنفيذه باستخدام تصحيحات نواة مخصصة. كان التنسيق على القرص الذي أنتجه هذا الوضع خاصًا بالبائعين. على الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android أو الإصدارات الأحدث، لم يعُد هذا الوضع مسموحًا به ويجب استخدام تنسيق تشفير عادي بدلاً منه.

يتم بشكل تلقائي تشفير محتوى الملفات باستخدام واجهة برمجة تطبيقات التشفير في Linux kernel. إذا كنت تريد استخدام أجهزة التشفير المضمّنة بدلاً من ذلك، أضِف أيضًا خيار 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 من نظام Android، يمكن استخدام FBE و مساحة التخزين القابلة للتخصيص معًا.

يؤدي تحديد خيار fstab fileencryption لـ userdata أيضًا إلى تفعيل كل من FBE وتشفير البيانات الوصفية تلقائيًا على مساحة التخزين القابلة للاستخدام. ويمكنك إلغاء تنسيق FBE أو تنسيق تشفير البيانات الوصفية على مساحة التخزين القابلة للاستخدام من خلال ضبط السمات في PRODUCT_PROPERTY_OVERRIDES.

على الأجهزة التي تم تشغيلها باستخدام Android 11 أو إصدار أحدث، استخدِم السمات التالية:

• ‫ro.crypto.volume.options (ميزة جديدة في Android 11) لاختيار تنسيق تشفير FBE على وحدة التخزين القابلة للاستخدام وهي تستخدم بنية الوسيطة إلى خيار fstab fileencryption وتستخدم الإعدادات التلقائية نفسها. اطّلِع على اقتراحات fileencryption أعلاه لمعرفة ما يمكن استخدامه هنا.
• يختار ro.crypto.volume.metadata.encryption تنسيق تشفير البيانات الوصفية على مساحة تخزين قابلة للاستخدام. اطّلِع على مستندات تشفير البيانات الوصفية.

على الأجهزة التي تم تشغيلها باستخدام الإصدار 10 من نظام التشغيل Android أو إصدار أقدم، استخدِم الخصائص التالية:

• 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 مفتاح التشفير/فك التشفير للنظام على جميع الأدلة ذات المستوى الأعلى في /data، باستثناء الأدلة التي يجب عدم تشفيرها، مثل الدليل الذي يحتوي على مفتاح التشفير/فك التشفير للنظام نفسه والأدلة التي تحتوي على أدلة التشفير/فك التشفير للمستخدم. تنطبق مفاتيح التشفير بشكل متكرر ولا يمكن تجاوزها بواسطة الأدلة الفرعية.

في Android 11 والإصدارات الأحدث، يمكن التحكّم في المفتاح الذي يطبّقه init على الدلائل باستخدام الوسيطة encryption=<action> للcommandmkdir في نصوص التشغيل. وقد تم توثيق قيم <action> المحتملة في README للغة Android.

في نظام التشغيل Android 10، تم ترميز إجراءات تشفير init بشكل ثابت في الموقع التالي:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

في الإصدار 9 من نظام Android والإصدارات الأقدم، كان الموقع الجغرافي:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

من الممكن إضافة استثناءات لمنع تشفير أدلة معيّنة على الإطلاق. في حال إجراء تعديلات من هذا النوع، يجب أن تتضمّن الشركة المصنّعة للجهاز سياسات SELinux التي تمنح فقط إذن الوصول إلى التطبيقات التي تحتاج إلى استخدام الدليل غير المشفّر. ومن المفترض أن يستبعد ذلك جميع التطبيقات غير الموثوق بها.

إنّ حالة الاستخدام المقبولة الوحيدة المعروفة لهذا هي توفير إمكانات OTA القديمة.

إتاحة ميزة "التشغيل المباشر" في تطبيقات النظام

إتاحة ميزة "التشغيل المباشر" للتطبيقات

لتسهيل النقل السريع لتطبيقات النظام، هناك سمتان جديدتان يمكن ضبطهما على مستوى التطبيق. تتوفّر السمة defaultToDeviceProtectedStorage لتطبيقات النظام فقط. السمة directBootAware متاحة للجميع.

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

إنّ السمة directBootAware على مستوى التطبيق هي اختصار لوضع علامة على جميع مكونات التطبيق بأنّها معنيّة بالتشفير.

تعيد السمة defaultToDeviceProtectedStorage توجيه موقع تخزين التطبيق التلقائي للإشارة إلى مساحة تخزين DE بدلاً من الإشارة إلى مساحة تخزين CE. على تطبيقات النظام التي تستخدم هذه العلامة مراجعة جميع البيانات المخزّنة في التلقائي الموقع بعناية، وتغيير مسارات البيانات الحسّاسة لاستخدام مساحة التخزين في Trusted Execution. على المصنّعين الأجهزة الذين يستخدمون هذا الخيار فحص البيانات التي يتم تخزينها بعناية للتأكّد من أنّها لا تحتوي على أي معلومات شخصية.

عند التشغيل في هذا الوضع، تتوفر واجهات برمجة تطبيقات النظام التالية لإدارة السياق بشكل صريح من خلال وحدة تخزين CE عند الحاجة، والتي تعادل وظائفها المماثلة في الأجهزة المحمية.

• Context.createCredentialProtectedStorageContext()
• Context.isCredentialProtectedStorage()

دعم مستخدمين متعددين

يحصل كل مستخدم في بيئة متعددة المستخدمين على مفتاح تشفير منفصل. يحصل كل مستخدم على مفتاحَين: مفتاح DE ومفتاح CE. يجب أن يسجّل المستخدم 0 الدخول إلى الجهاز أولاً لأنّه مستخدم خاص. ينطبق ذلك على استخدامات إدارة الأجهزة.

تتفاعل التطبيقات المتوافقة مع معايير التشفير مع جميع المستخدمين على النحو التالي: INTERACT_ACROSS_USERS وINTERACT_ACROSS_USERS_FULL يسمحان للتطبيق بالتصرّف مع جميع المستخدمين على الجهاز. ومع ذلك، يمكن لهذه التطبيقات الوصول فقط إلى الأدلة المشفَّرة من خلال التشفير CE للمستخدمين الذين تم فتح قفلهم مسبقًا.

قد يتمكّن التطبيق من التفاعل بحرية في مناطق DE، ولكن إذا تم فتح قفل حساب مستخدم واحد، لا يعني ذلك أنّه تم فتح قفل جميع المستخدمين على الجهاز. يجب أن يتحقق التطبيق من هذه الحالة قبل محاولة الوصول إلى هذه المناطق.

يحصل كل رقم تعريف مستخدم لملف العمل أيضًا على مفتاحَين: DE وCE. عند تلبية تحدي العمل، يتم إلغاء قفل مستخدم الملف الشخصي ويمكن لـ Keymaster (في TEE) توفير مفتاح TEE للملف الشخصي.

معالجة التعديلات

يتعذر على قسم الاسترداد الوصول إلى مساحة التخزين المحمية من خلال DE في قسم userdata. ننصح بشدة باستخدام الأجهزة التي تنفِّذ FBE لدعم التحديث عبر الهواء باستخدام تحديثات نظام 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 أو eng، واضبط رقم تعريف شخصي أو نقشًا أو كلمة مرور للمستخدم الرئيسي، ثم أعِد تشغيل الجهاز. قبل فتح قفل الجهاز، شغِّل الأمر التالي للتحقق من وحدة تخزين CE للمستخدم الرئيسي. إذا كان الجهاز يستخدم وضع مستخدم النظام بلا واجهة رسومية (معظم الأجهزة المخصّصة للسيارات)، يكون المستخدم الرئيسي هو المستخدم 10، لذا عليك تنفيذ ما يلي:

adb root; adb shell ls /data/user/10

على الأجهزة الأخرى (معظم الأجهزة غير المتعلقة بالسيارات)، يكون المستخدم الرئيسي هو المستخدم 0، لذلك عليك تشغيل:

adb root; adb shell ls /data/user/0

تأكَّد من أنّ أسماء الملفات المدرَجة بترميز Base64، ما يشير إلى أنّ أسماء الملفات مشفّرة وأنّ مفتاح فك تشفيرها غير متاح بعد. إذا كانت أسماء الملفات مدرجة بنص عادي، فهذا يعني حدوث خطأ.

ننصح أيضًا الشركات المصنّعة للأجهزة باستكشاف إمكانية إجراء اختبارات Linux الأساسية لبرنامج fscrypt على أجهزتها أو النواة. هذه الاختبارات هي جزء من مجموعة اختبار نظام الملفات xfstests. ومع ذلك، لا يتوافق Android رسميًا مع هذه الاختبارات الأولية.

تفاصيل تنفيذ 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، يُرجى الاطّلاع على مستندات kernel الأساسية.

فئات مساحة التخزين

يسرد الجدول التالي مفاتيح FBE والأدلة التي تحميها بشكلٍ أكثر تفصيلاً:

تخزين المفاتيح وحمايتها

تدير vold جميع مفاتيح FBE ويتم تخزينها مشفَّرة على القرص، باستثناء مفتاح التمهيد الذي لا يتم تخزينه على الإطلاق. يسرد الجدول التالي المواقع التي يتم فيها تخزين مفاتيح FBE المختلفة:

وكما هو موضّح في الجدول السابق، يتم تخزين معظم مفاتيح FBE في أدلة مشفّرة باستخدام مفتاح FBE آخر. لا يمكن فتح قفل المفاتيح إلا بعد فتح قفل فئة التخزين التي تحتوي عليها.

تطبِّق vold أيضًا طبقة تشفير على جميع مفاتيح FBE. يتم تشفير كل مفتاح باستثناء مفاتيح التشفير من جهة العميل لمساحة التخزين الداخلية باستخدام معيار AES-256-GCM باستخدام مفتاح متجر المفاتيح الخاص به والذي لا يتم عرضه خارج وحدة TEE. يضمن ذلك عدم إمكانية فتح قفل مفاتيح FBE ما لم يتم تشغيل نظام تشغيل موثوق به، كما يفرض ذلك التشغيل المُتحقّق منه. يُطلب أيضًا مقاومة العودة على مفتاح تخزين المفاتيح، ما يسمح بحذف مفاتيح FBE بأمان على الأجهزة التي يتيح تطبيق Keymaster مقاومة العودة إليها. كإجراء احتياطي لأفضل جهد في حال عدم توفّر مقاومة العودة إلى الحالة السابقة، يتم استخدام تجزئة SHA-512 المكوَّنة من 16384 بايت عشوائيًا ومخزَّنة في ملف secdiscardable إلى جانب المفتاح كعلامة رقم تعريف التطبيق لمفتاح تخزين المفاتيح. يجب استرداد جميع وحدات البايت هذه لاسترداد مفتاح FBE.

تتلقّى مفاتيح CE للمساحة التخزينية الداخلية مستوى حماية أقوى يضمن عدم التمكّن من فتح قفلها بدون معرفة عامل معرفة شاشة القفل (LSKF) (رقم التعريف الشخصي أو النقش أو كلمة المرور) أو رمز مميّز آمن لإعادة ضبط رمز المرور أو كل من مفاتيح جهة العميل وخادم الويب لإجراء استئناف التشغيل عند إعادة التشغيل. لا يُسمح بإنشاء الرموز المميّزة لإعادة ضبط رمز المرور إلا لملفات العمل والأجهزة المُدارة بالكامل.

لتحقيق ذلك، يعمل vold على تشفير كل مفتاح CE في وحدة التخزين الداخلية باستخدام مفتاح AES-256-GCM مشتق من كلمة المرور الاصطناعية للمستخدم. كلمة المرور الاصطناعية هي كلمة مرور مشفّرة غير قابلة للتغيير يتم إنشاؤها بشكل عشوائي لكل مستخدم. يدير LockSettingsService في system_server كلمة المرور الاصطناعية وطرق حمايتها.

لحماية كلمة المرور الاصطناعية باستخدام LSKF، تعمل ميزة "LockSettingsService" أولاً على توسيع نطاق LSKF من خلال تمريرها عبر scrypt، واستهداف مدة 25 ملي ثانية تقريبًا واستخدام للذاكرة حوالي 2 مبيبايت. وبما أنّ إطارات LSKF قصيرة عادةً، لا توفّر هذه الخطوة عادةً الكثير من الأمان. إنّ طبقة الأمان الرئيسية هي العنصر الآمن (SE) أو تقييد المعدّل الذي تفرضه منصة TEE كما هو موضّح أدناه.

إذا كان الجهاز يحتوي على عنصر آمن (SE)، يضبط LockSettingsService عنصر LSKF الممتد على سر عشوائي عالي القصور مخزّن في العنصر الآمن باستخدام Weaver HAL. بعد ذلك، يشفِّر LockSettingsService كلمة المرور التركيبية مرّتين: أولاً باستخدام مفتاح برنامج مشتق من مفتاح LSKF الموسَّع والمفتاح السري لـ Weaver، وثانيًا باستخدام مفتاح Keystore غير مرتبط بالمصادقة. يوفّر ذلك حدود معدلة تفرضها SE.

إذا كان الجهاز لا يحتوي على عنصر آمن، سيستخدم LockSettingsService بدلاً من ذلك رمز LSKF الذي تم تمديده باعتباره كلمة مرور Gatekeeper. LockSettingsService ثمّ يشفِّر كلمة المرور الاصطناعي مرّتين: أولاً باستخدام مفتاح برنامج مشتق من مفتاح LSKF الموسَّع ودرجة sha1 لملف قابل للحذف بأمان، وثانيًا باستخدام مفتاح Keystore مرتبط بالبروتوكول المصدق عليه في عملية تسجيل Gatekeeper. ويوفر ذلك حدود المعدل التي تفرضها TEE لتخمينات LSKF.

عند تغيير مفتاح LSKF، تحذف LockSettingsService كل المعلومات المرتبطة بربط كلمة المرور الاصطناعية بملف LSKF القديم. على الأجهزة التي تتيح استخدام Weaver أو مفاتيح تخزين المفاتيح المقاومة للعودة إلى الحالة السابقة، يضمن هذا حذف الربط القديم بشكل آمن. لهذا السبب، يتم تطبيق إجراءات الحماية الموضحة هنا حتى عندما لا يكون لدى المستخدم LSKF.