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

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

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

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

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

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

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

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

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

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

تسمح واجهة برمجة التطبيقات Direct Boot API للتطبيقات المتوافقة مع التشفير بالوصول إلى كلٍّ من هذه المناطق. تم إجراء تغييرات على دورة حياة التطبيق لتلبية الحاجة إلى إعلام التطبيقات عند فتح قفل مساحة التخزين في "التخزين المؤقت للتطبيقات" للمستخدم استجابةً لإدخال بيانات الاعتماد أولاً على شاشة القفل، أو في حال تقديم تحدّي في ملف العمل. يجب أن تتوافق الأجهزة التي تعمل بنظام التشغيل 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 (packages/apps/Dialer)
• Desk Clock (packages/apps/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• تطبيق "الإعدادات" (الحِزم/التطبيقات/الإعدادات)*
• SystemUI (frameworks/base/packages/SystemUI)*

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

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

التبعيات

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

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

التنفيذ

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

دعم النواة

تتوفّر ميزة توفُّر نظام التشغيل لتشفير Ext4 وF2FS في أنظمة التشغيل المشترَكة لنظام Android، الإصدار 3.18 والإصدارات الأحدث. لتفعيل هذه الميزة في نواة الإصدار 5.1 أو الإصدارات الأحدث، استخدِم:

CONFIG_FS_ENCRYPTION=y

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

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

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

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

لتحسين الأداء بشكلٍ أكبر وخفض استهلاك الطاقة، قد يُفكّر المصنّعون أيضًا في استخدام أجهزة التشفير المضمّنة التي تشفِّر البيانات أو فكّ تشفيرها أثناء نقلها إلى جهاز التخزين أو من جهاز التخزين. تحتوي نواة Android الشائعة (الإصدار 4.14 والإصدارات الأحدث) على إطار عمل يسمح باستخدام التشفير المضمّن عند توفّر دعم للأجهزة وبرامج تشغيل المورّدين. يمكن تفعيل إطار عمل التشفير المضمّن من خلال ضبط خيارات ضبط النواة التالية:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

إذا كان جهازك يستخدم وحدة تخزين مستندة إلى UFS، فعِّل أيضًا ما يلي:

CONFIG_SCSI_UFS_CRYPTO=y

إذا كان جهازك يستخدم مساحة تخزين مستندة إلى شريحة eMMC، عليك أيضًا تفعيل ما يلي:

CONFIG_MMC_CRYPTO=y

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

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

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

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

• تحدِّد المَعلمة contents_encryption_mode خوارزمية التشفير المستخدَمة لتشفير محتوى الملف. يمكن أن يكون إما aes-256-xts أو adiantum. وبدءًا من الإصدار 11 من Android، يمكن أيضًا تركها فارغة لتحديد algorithmic التلقائية، وهي 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 تنسيق تشفير مُحسَّنًا لأجهزة التشفير المضمّنة التي لا تتمكّن من معالجة أعداد كبيرة من المفاتيح بكفاءة. ويتم ذلك من خلال اشتقاق مفتاح تشفير محتوى ملف واحد فقط لكل مفتاح تشفير أو فك تشفير، بدلاً من مفتاح واحد لكل ملف. ويتم تعديل عملية إنشاء وحدات IV (المتجهات الأولية) وفقًا لذلك.
  • يشبه الرمز emmc_optimized الرمز inlinecrypt_optimized، ولكنه يختار أيضًا طريقة توليد ملف تعريف الارتباط التي تحدّ من ملفات تعريف الارتباط إلى 32 بت. يجب استخدام هذه العلامة فقط على أجهزة التشفير المضمّنة المتوافقة مع مواصفات JEDEC eMMC v5.2، وبالتالي لا تتوافق إلا مع أرقام البدء التي تبلغ 32 بت. في أجهزة التشفير المضمّنة الأخرى، استخدِم inlinecrypt_optimized بدلاً من ذلك. يجب عدم استخدام هذا الإعداد أبدًا في مساحة التخزين المستندة إلى UFS، لأنّ مواصفات UFS تسمح باستخدام قيم البدء التي تبلغ 64 بت.
  • على الأجهزة التي تتيح استخدام مفاتيح ملف التمهيد المشفَّر المُغلقة بجهاز، تتيح العلامة wrappedkey_v0 استخدام مفاتيح ملف التمهيد المشفَّر المُغلقة بجهاز لميزة "التشفير من جهة العميل". لا يمكن استخدام هذا الخيار إلا مع خيار التركيب 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.

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

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

مساحة تخزين قابلة للاستخدام

منذ الإصدار 9 من نظام Android، يمكن استخدام FBE و مساحة التخزين القابلة للتخصيص معًا.

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

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

• ‫ro.crypto.volume.options (ميزة جديدة في Android 11) لاختيار تنسيق تشفير FBE على وحدة التخزين القابلة للاستخدام وتتضمّن البنية نفسها التي تتضمّنها الوسيطة الخاصة بأحد خيارات fileencryption fstab، وتستخدم الإعدادات التلقائية نفسها. اطّلِع على الاقتراحات الخاصة بـ 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، باستثناء أنّ الإعداد التلقائي على الأجهزة التي تم تشغيلها باستخدام الإصدار 10 من نظام التشغيل Android أو إصدار أقدم هو 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> للسماح بتنفيذ الأمر mkdir في نصوص التشغيل. يمكنك الاطّلاع على القيم المحتمَلة للمَعلمة <action> في مستند README الخاص بلغة Android init.

في الإصدار 10 من نظام التشغيل Android، تم تضمين إجراءات التشفير 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 يسمحان للتطبيق بالتصرّف مع جميع المستخدمين على الجهاز. ومع ذلك، لا يمكن لهذه التطبيقات الوصول إلا إلى الأدلة المشفَّرة بتقنية "التشفير من جهة العميل" للمستخدمين الذين سبق أن تم فتح قفل حساباتهم.

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

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

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

يتعذّر على قسم الاسترداد الوصول إلى مساحة التخزين المحمية بميزة "التشفير من جهة العميل" في قسم userdata. ننصح بشدة بأن تتيح الأجهزة التي تستخدم FBE إمكانية التحديث عبرالشبكة بدون إنترنت باستخدام تحديثات نظام A/B. بما أنّه يمكن تطبيق التحديثات من خلال الهواء أثناء التشغيل العادي، لا حاجة إلى الاسترداد لأجل الوصول إلى البيانات على محرك الأقراص المشفَّر.

عند استخدام حلّ OTA قديم يتطلّب الاسترداد للوصول إلى ملف OTA في قسم userdata:

1. أنشئ دليلاً أعلى مستوى (مثل misc_ne) في القسم userdata.
2. اضبط هذا الدليل من المستوى الأعلى ليكون غير مشفَّر (راجِع استبعاد الدلائل).
3. أنشئ دليلاً ضمن الدليل ذي المستوى الأعلى لتخزين حِزم OTA.
4. أضِف قاعدة SELinux وسياقات الملفات للتحكّم في الوصول إلى هذا الدليل و محتوياته. يجب أن تكون العملية أو التطبيقات التي تتلقّى تحديثات عبر شبكة غير سلكية فقط هي التي يمكنها القراءة والكتابة في هذا الدليل. يجب ألا يتمكن أي تطبيق أو عملية أخرى من الوصول إلى هذا الدليل.

التحقُّق

لضمان عمل الإصدار المُنفَّذ من الميزة على النحو المطلوب، عليك أولاً تنفيذ العديد من اختبارات التشفير في CTS، مثل DirectBootHostTest وEncryptionTest.

إذا كان الجهاز يعمل بنظام التشغيل Android 11 أو إصدار أحدث، عليك أيضًا تنفيذ اختبار vts_kernel_encryption_test:

atest vts_kernel_encryption_test

أو:

vts-tradefed run vts -m vts_kernel_encryption_test

بالإضافة إلى ذلك، يمكن لصنّاع الأجهزة إجراء الاختبارات اليدوية التالية. على جهاز تم تفعيل ميزة "التشفير من جهة العميل" عليه:

• تأكَّد من توفّر ro.crypto.state
  • التأكّد من تشفير ro.crypto.state
• تأكَّد من توفّر ro.crypto.type
  • تأكَّد من ضبط السمة ro.crypto.type على file.

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

• تشفير محتوى الملف باستخدام معيار 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 ما لم يتم تشغيل نظام تشغيل موثوق به، كما تفرض ميزة التشغيل المُتحقّق منه. يُطلب أيضًا منع الترجيع في مفتاح Keystore، ما يسمح بحذف مفاتيح FBE بأمان على الأجهزة التي يتيح فيها Keymaster منع الترجيع. كأحد البدائل التي تُستخدَم عند عدم توفّر ميزة مقاومة التراجع، يتم استخدام التجزئة SHA-512 لـ 16384 بايت عشوائي مخزّن في ملف secdiscardable بجانب المفتاح كTag::APPLICATION_ID لمفتاح "متجر المفاتيح" . يجب استرداد كل هذه البايتات لاسترداد مفتاح FBE.

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

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

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

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

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

عند تغيير مفتاح LSKF، تحذف LockSettingsService كل المعلومات المرتبطة بربط كلمة المرور الاصطناعية بمفتاح LSKF القديم. على الأجهزة التي تتيح استخدام مفاتيح Keystore المقاومة لعمليات التراجع أو Weaver، يضمن ذلك حذف عملية الربط القديمة بأمان. لهذا السبب، يتم تطبيق وسائل الحماية описанَة هنا حتى إذا لم يكن لدى المستخدم مفتاح LSKF.