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

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

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

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

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

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

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

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

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

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

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

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

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

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

أمثلة ومصدر

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

• تطبيق "الهاتف" في مشروع Android المفتوح المصدر (packages/apps/Dialer)
• ساعة المكتب (packages/apps/DeskClock)
• ‫LatinIME (packages/inputmethods/LatinIME)*
• تطبيق "الإعدادات" (packages/apps/Settings)*
• SystemUI (frameworks/base/packages/SystemUI)*

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

يمكن العثور على المزيد من الأمثلة على التطبيقات والخدمات التي تتوافق مع التشفير من خلال تنفيذ الأمر mangrep directBootAware في دليل الحِزم أو الأُطر ضمن شجرة المصدر لنظام التشغيل AOSP.

التبعيات

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

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

التنفيذ

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

توافق النواة

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

CONFIG_FS_ENCRYPTION=y

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

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

بالإضافة إلى توفير الدعم الوظيفي لتشفير 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. يمكن أيضًا تركها فارغة لتحديد الخوارزمية التلقائية، وهي aes-256-xts، وذلك بدءًا من نظام التشغيل Android 11.
• تحدّد المَعلمة 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، الجديدة في نظام التشغيل Android 11، هي قائمة من العلامات مفصولة بالحرف +. تتوفّر العلامات التالية:
  • يختار الخيار v1 سياسات التشفير للإصدار 1، بينما يختار الخيار v2 سياسات التشفير للإصدار 2. تستخدم سياسات التشفير في الإصدار 2 وظيفة اشتقاق مفاتيح أكثر أمانًا ومرونة. القيمة التلقائية هي v2 إذا كان الجهاز يعمل بالإصدار 11 من نظام التشغيل Android أو إصدار أحدث (كما هو محدّد بواسطة ro.product.first_api_level)، أو v1 إذا كان الجهاز يعمل بالإصدار 10 من نظام التشغيل Android أو إصدار أقدم.
  • يختار الخيار inlinecrypt_optimized تنسيق تشفير تم تحسينه للأجهزة المضمّنة التي لا تتعامل مع أعداد كبيرة من المفاتيح بكفاءة. ويتم ذلك من خلال استخلاص مفتاح تشفير واحد فقط لمحتوى الملف لكل مفتاح CE أو DE، بدلاً من مفتاح واحد لكل ملف. ويتم تعديل عملية إنشاء متجهات التهيئة (IV) وفقًا لذلك.
  • العلامة emmc_optimized مشابهة للعلامة inlinecrypt_optimized، ولكنّها تختار أيضًا طريقة إنشاء متجهات التهيئة التي تقتصر على 32 بت. يجب استخدام هذه العلامة فقط مع أجهزة التشفير المضمّن المتوافقة مع مواصفات JEDEC eMMC الإصدار 5.2، وبالتالي لا تتوافق إلا مع أرقام IV ذات 32 بت. على أجهزة أخرى لتشفير البيانات المضمّنة، استخدِم inlinecrypt_optimized بدلاً من ذلك. يجب عدم استخدام هذا العلامة مطلقًا مع وحدات التخزين المستندة إلى UFS، لأنّ مواصفات UFS تسمح باستخدام IV‏ 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 هو الوضع المفضّل لتشفير أسماء الملفات للأجهزة التي تتضمّن تعليمات تشفير مُسرَّعة. ومع ذلك، لا تتوافق معيار AES-HCTR2 إلا نُوى Android الأحدث. في إصدار 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، يمكن استخدام ميزة "التشفير المستند إلى الملفات" ومساحة التخزين القابلة للنقل معًا.

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

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

• يؤدي الخيار 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، باستثناء أنّ القيمة التلقائية على الأجهزة التي تم إطلاقها بالإصدار 10 من نظام التشغيل Android والإصدارات الأقدم هي aes-256-heh. في معظم الأجهزة، يجب إلغاء هذا الإعداد بشكل صريح وضبطه على aes-256-cts.
• ro.crypto.fde_algorithm وro.crypto.fde_sector_size لاختيار تنسيق تشفير البيانات الوصفية على وحدة التخزين القابلة للاستخدام. يمكنك الاطّلاع على مستندات تشفير البيانات الوصفية.

الدمج مع KeyMint

يجب بدء KeyMint HAL كجزء من فئة early_hal. ويرجع ذلك إلى أنّ FBE يتطلّب أن يكون KeyMint جاهزًا للتعامل مع الطلبات بحلول مرحلة التشغيل post-fs-data، وهي المرحلة التي يضبط فيها vold المفاتيح الأولية.

استبعاد الأدلة

تطبِّق init مفتاح تشفير البيانات (DE) الخاص بالنظام على جميع الأدلة ذات المستوى الأعلى في /data، باستثناء الأدلة التي يجب أن تكون غير مشفّرة، مثل الدليل الذي يحتوي على مفتاح تشفير البيانات الخاص بالنظام نفسه والأدلة التي تحتوي على أدلة تشفير المحتوى أو تشفير البيانات الخاصة بالمستخدم. تنطبق مفاتيح التشفير بشكل متكرّر ولا يمكن إلغاؤها بواسطة الدلائل الفرعية.

في Android 11 والإصدارات الأحدث، يمكن التحكّم في المفتاح الذي init ينطبق على الدلائل باستخدام الوسيطة encryption=<action> في الأمر mkdir ضمن نصوص البرامج الأولية. يمكن الاطّلاع على القيم المحتمَلة لـ <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 توجيه موقع التخزين التلقائي للتطبيق إلى مساحة تخزين البيانات المشفرة بدلاً من مساحة تخزين بيانات الاعتماد. يجب أن تدقّق تطبيقات النظام التي تستخدم هذا العلامة بعناية في جميع البيانات المخزَّنة في الموقع التلقائي، وأن تغيّر مسارات البيانات الحساسة لاستخدام مساحة تخزين بيانات الاعتماد (CE). على الشركات المصنّعة للأجهزة التي تستخدم هذا الخيار فحص البيانات التي تخزّنها بعناية للتأكّد من أنّها لا تحتوي على أي معلومات شخصية.

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

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

السماح لمستخدمين متعدّدين

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

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

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

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

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

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

عند استخدام حلّ قديم للتحديث عبر الهواء (OTA)، والذي يتطلّب الاسترداد للوصول إلى ملف التحديث عبر الهواء على القسم userdata:

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

التحقُّق

لضمان عمل الإصدار الذي تم تنفيذه من الميزة على النحو المنشود، عليك أولاً إجراء العديد من اختبارات التشفير في مجموعة اختبارات التوافق (CTS)، مثل DirectBootHostTest وEncryptionTest.

إذا كان الجهاز يعمل بالإصدار 11 من نظام التشغيل Android أو إصدار أحدث، شغِّل أيضًا 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

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

تشفير fscrypt

يستخدم تطبيق AOSP التشفير "fscrypt" (المتوافق مع ext4 وf2fs) في النواة، ويتم عادةً ضبطه على ما يلي:

• تشفير محتوى الملف باستخدام معيار التشفير المتقدّم (AES-256) في وضع XTS
• تشفير أسماء الملفات باستخدام AES-256 في وضع CBC-CTS

يتوافق الجهاز أيضًا مع تشفير Adiantum. عند تفعيل التشفير باستخدام Adiantum، يتم تشفير محتوى الملفات وأسماء الملفات باستخدام Adiantum.

يتوافق fscrypt مع إصدارَين من سياسات التشفير: الإصدار 1 والإصدار 2. تم إيقاف الإصدار 1 نهائيًا، ولا تتوافق متطلبات مستند تعريف التوافق (CDD) للأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android والإصدارات الأحدث إلا مع الإصدار 2. تستخدم سياسات التشفير الإصدار 2 HKDF-SHA512 لاستخلاص مفاتيح التشفير الفعلية من المفاتيح التي يوفّرها مساحة المستخدم.

لمزيد من المعلومات حول fscrypt، يُرجى الاطّلاع على مستندات kernel الأصلية.

فئات التخزين

يسرد الجدول التالي مفاتيح التشفير المستند إلى الملفات والأدلة التي تحميها بتفصيل أكبر:

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

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

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

تضيف vold أيضًا طبقة تشفير إلى جميع مفاتيح التشفير الكامل للجهاز. يتم تشفير كل مفتاح باستثناء مفاتيح CE الخاصة بوحدة التخزين الداخلية باستخدام معيار التشفير المتقدّم AES-256-GCM باستخدام مفتاح Keystore الخاص به والذي لا يتم عرضه خارج بيئة التنفيذ الموثوقة (TEE). ويضمن ذلك عدم إمكانية فتح مفاتيح التشفير المستند إلى الملفات إلا بعد تشغيل نظام تشغيل موثوق، كما هو محدّد في عملية التحقّق من صحة عملية التشغيل. يُطلب أيضًا توفير ميزة مقاومة العودة إلى الإصدار السابق على مفتاح Keystore، ما يتيح حذف مفاتيح التشفير المستند إلى الملف بشكل آمن على الأجهزة التي تتيح فيها KeyMint ميزة مقاومة العودة إلى الإصدار السابق. عندما لا تتوفّر ميزة مقاومة الرجوع إلى إصدار أقدم، يتم استخدام قيمة التجزئة SHA-512 التي تتضمّن 16384 بايت عشوائيًا والمخزَّنة في الملف secdiscardable المخزَّن بجانب المفتاح كقيمة Tag::APPLICATION_ID لمفتاح Keystore. يجب استرداد كل هذه البايتات لاسترداد مفتاح 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. ثم يتم تشفير كلمة المرور الاصطناعية مرتين: أولاً باستخدام مفتاح برنامج مشتق من LSKF الموسّع وWeaver secret، وثانيًا باستخدام مفتاح Keystore غير مرتبط بالمصادقة.LockSettingsService يوفّر ذلك تحديدًا للحدّ الأقصى لعدد التخمينات التي يمكن إجراؤها على مفتاح الخدمة المحدود الاستخدام (LSKF) من خلال الأجهزة التي تفرض قيودًا على الوصول إلى الموارد.

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

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