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

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

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

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

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

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

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

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

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

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

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

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

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

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

أمثلة ومصدر

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

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

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

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

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

لا يمكن لقسم الاسترداد الوصول إلى مساحة التخزين المحمية باستخدام ميزة "التشفير الكامل للقرص" في قسم 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

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

فئات التخزين

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

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

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

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

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

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

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

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

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

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

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