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

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

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

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

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

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

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

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

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

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

• يؤدي الخيار ro.crypto.volume.options (جديد في Android 11) إلى اختيار تنسيق تشفير FBE على وحدة التخزين القابلة للاستخدام. ولها بنية الجملة نفسها الخاصة بالوسيطة في خيار fileencryption fstab، وتستخدم القيم التلقائية نفسها. راجِع الاقتراحات الخاصة بـ fileencryption أعلاه لمعرفة ما يجب استخدامه هنا.
• يختار ro.crypto.volume.metadata.encryption تنسيق تشفير البيانات الوصفية على وحدة التخزين القابلة للاستخدام. يمكنك الاطّلاع على مستندات تشفير البيانات الوصفية.

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

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

الدمج مع KeyMint

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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