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

يتيح الإصدار 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 في AOSP بشكل آمن، يجب أن يستوفي الجهاز الاعتمادات التالية:

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

التنفيذ

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

دعم النواة

تتوفّر إمكانية تشفير 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. بدءًا من نظام التشغيل 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، وهي مَعلمة جديدة في 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 v5.2، وبالتالي لا تتيح سوى استخدام متجهات الإعداد (IV) ذات 32 بت. على أجهزة التشفير المضمّن الأخرى، استخدِم inlinecrypt_optimized بدلاً من ذلك. يجب عدم استخدام هذه العلامة مطلقًا على وحدة تخزين مستندة إلى UFS، لأنّ مواصفات UFS تسمح باستخدام متجهات الإعداد (IV) ذات 64 بت.
  • على الأجهزة التي تتيح مفاتيح التشفير المضمّنة والمغلفة بالأجهزة، يمكن تغليف مفاتيح FBE بالأجهزة من خلال إضافة العلامة 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.

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

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

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

في 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 (في بيئة التنفيذ الموثوق بها) توفير مفتاح بيئة التنفيذ الموثوق بها للملف الشخصي.

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

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

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

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

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

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

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

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

كما هو موضّح في الجدول السابق، يتم تخزين معظم مفاتيح FBE في أدلة يتم تشفيرها باستخدام مفتاح 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 secret، والثانية باستخدام مفتاح Keystore غير مرتبط بالمصادقة. يوفّر هذا الإجراء حدًا لمعدّل تخمينات بيانات LSKF، ويتم فرض هذا الحدّ من خلال SE أو TEE.

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

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