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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الطلبات التابعة

لاستخدام تنفيذ التشفير المستند إلى الملفات (FBE) في مشروع Android المفتوح المصدر (AOSP) بأمان، يجب أن يستوفي الجهاز الاعتماديات التالية:

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

التنفيذ

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

دعم النواة

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

يتم تشفير محتوى الملفات تلقائيًا باستخدام واجهة برمجة التطبيقات الخاصة بالتشفير في نواة 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

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

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

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

على الأجهزة التي تم إطلاقها بنظام التشغيل 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 يختاران تنسيق تشفير البيانات الوصفية في وحدة التخزين القابلة للاستخدام. يُرجى الاطّلاع على مستندات تشفير البيانات الوصفية.

الدمج مع KeyMint

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

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

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

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

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

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

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

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

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

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

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

جعل التطبيقات متوافقة مع ميزة "التشغيل المباشر"

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

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

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

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

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

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

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

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

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

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

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

تعديلات على الأسماء المعرِّفة

لا يمكن لقسم الاسترداد الوصول إلى مساحة التخزين المحمية بالتشفير المباشر (DE) في قسم بيانات المستخدم. ننصح بشدة الأجهزة التي تستخدم ميزة "التشفير المستند إلى الملفات" (FBE) بإتاحة تحديثات OTA باستخدام تحديثات نظام A/B. بما أنّه يمكن تطبيق تحديث 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

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

• التحقّق من توفّر 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

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

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

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

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

تفاصيل تنفيذ "مشروع Android المفتوح المصدر" (AOSP)

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

تشفير fscrypt

يستخدم تنفيذ نظام التشغيل Android المفتوح المصدر (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، يُرجى الاطّلاع على مستندات النواة الأساسية.

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

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

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

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

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

يطبّق vold أيضًا طبقة تشفير على جميع مفاتيح FBE. يتم تشفير كل مفتاح بخلاف مفاتيح CE لوحدة التخزين الداخلية باستخدام معيار AES-256-GCM باستخدام مفتاح Keystore الخاص به والذي لا يتم عرضه خارج بيئة التنفيذ الموثوق بها (TEE). يضمن ذلك عدم إمكانية فتح قفل مفاتيح "التشفير المستند إلى الملفات" (FBE) إلا بعد تشغيل نظام تشغيل موثوق به، كما هو مفروض من خلال التشغيل المتحقّق منه. يتم أيضًا طلب مقاومة العودة إلى إصدار سابق على مفتاح Keystore، ما يسمح بحذف مفاتيح FBE بأمان على الأجهزة التي يتيح فيها 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) كما هو موضّح أدناه.

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

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

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