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

يتيح الإصدار 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، لتتوافق مع ميزتَي "التشفير المستند إلى الملفات" و"التشغيل المباشر". ومن بينها:

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

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

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

إذا كان الجهاز يحتوي على عنصر آمن (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.