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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يوفر Android طريقة تنفيذ مرجعية للتشفير المستند إلى الملفات، vold (system/vold) وظائف لإدارة أجهزة التخزين الملفات الصوتية على Android. تؤدي إضافة FBE إلى توفير العديد من الأوامر الجديدة. لدعم إدارة المفاتيح لمفاتيح التشفير CE وDE لعدة مستخدمين. بالإضافة إلى ذلك التغييرات الأساسية من أجل استخدام واجهة برمجة التطبيقات الأساسية في الكيرنل (kernel)، والعديد من حزم النظام، بما في ذلك تم تعديل شاشة القفل وSystemUI لدعم FBE وDirect ميزات التشغيل. ومن بينها:

• AOSP Dialer (الحزم/التطبيقات/برنامج الاتصال)
• ساعة المكتب (الحزم/التطبيقات/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• تطبيق الإعدادات (الحزم/التطبيقات/الإعدادات)*
• SystemUI (أطر العمل/الأساسي/الحزم/SystemUI)*

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

يمكن الاطّلاع على مزيد من الأمثلة على التطبيقات والخدمات التي تحتاج إلى التشفير من خلال تنفيذ الأمر mangrep directBootAware في دليل أطر العمل أو الحزم الخاصة بنموذج AOSP شجرة المصادر

التبعيات

لاستخدام تنفيذ AOSP من FBE بأمان، يجب أن يستوفي الجهاز للتبعيات التالية:

• دعم النواة لتشفير Ext4 أو F2FS.
• مدير المفاتيح أن يكون متوافقًا مع الإصدار 1.0 من HAL أو إصدار أحدث لا يوجد دعم Keymaster 0.3 لأنه لا يوفر القدرات اللازمة أو يؤكد حماية كافية لمفاتيح التشفير.
• Keymaster/Keystore و يجب تنفيذ البوابة في عملية تنفيذ موثوق به. Environment (TEE) لتوفير الحماية لمفاتيح DE حتى لا يمكن لنظام التشغيل غير المصرح به (نظام التشغيل المخصص الذي تم تحميله على الجهاز) طلب مفاتيح DE.
• جذر الثقة في الأجهزة والتشغيل المتحقّق منه المرتبطة بإعداد Keymaster للتأكد من أن مفاتيح DE غير من خلال نظام تشغيل غير مصرح به.

التنفيذ

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

دعم Kernel

يتوفر دعم النواة لتشفير Ext4 وF2FS في بروتوكول Android المشترك الإصدار 3.18 والإصدارات الأحدث. لتفعيله في نواة الإصدار 5.1 أو أعلى، استخدم:

CONFIG_FS_ENCRYPTION=y

بالنسبة إلى النواة القديمة، يمكنك استخدام CONFIG_EXT4_ENCRYPTION=y إذا كان جهازك نظام الملفات userdata هو Ext4، أو استخدم CONFIG_F2FS_FS_ENCRYPTION=y إذا كان userdata في جهازك نظام الملفات هو F2FS.

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

بالإضافة إلى الدعم الوظيفي لتشفير Ext4 أو F2FS، على الشركات المصنّعة إمكانية تفعيل تسريع التشفير تشفير الملفات وتحسين تجربة المستخدم. على سبيل المثال، في يمكن أن يكون تسريع ARMv8 CE (إضافات التشفير) في الأجهزة المستندة إلى ARM64 عن طريق إعداد خيارات تهيئة النواة التالية:

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

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

يتطلب تمكين FBE على الجهاز تفعيله على وحدة التخزين الداخلية (userdata). ويؤدي ذلك أيضًا إلى تمكين FBE تلقائيًا من التخزين ومع ذلك، قد يتم إلغاء تنسيق التشفير على وحدة التخزين القابلة للاستخدام إذا لزم الأمر.

وحدة التخزين الداخلية

يتم تفعيل 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. الإصدار تستخدم سياستا التشفير وظيفة اشتقاق المفاتيح أكثر أمانًا ومرونة. يكون الإصدار التلقائي هو v2 إذا تم إطلاق الجهاز على الإصدار 11 من نظام التشغيل Android أو الإصدارات الأحدث. (كما هو محدد في ro.product.first_api_level)، أو الإصدار 1 إذا تم إطلاقه على Android 10 أو أَقَل
  • تختار العلامة inlinecrypt_optimized تشفيرًا. محسَّن لأجهزة التشفير المضمّن التي لا التعامل مع أعداد كبيرة من المفاتيح بكفاءة. تقوم بذلك عن طريق اشتقاق مفتاح تشفير واحد فقط لمحتوى الملفات لكل مفتاح CE أو DE، بدلاً من واحد لكل ملف. يُعد إنشاء متّجهات الإعداد (IV) منهجًا وتعديلها وفقًا لذلك.
  • تشبه العلامة emmc_optimized inlinecrypt_optimized، ولكنه يحدد أيضًا IV التي تحد من IV إلى 32 بت. ينبغي أن تقتصر هذه العلامة على أجهزة التشفير المضمّن المتوافقة مع مواصفات الإصدار 5.2 من JEDEC eMMC، وبالتالي فهي تتوافق مع الإصدار 32 بت فقط IVs. وعلى أجهزة التشفير المضمّن الأخرى، استخدم inlinecrypt_optimized بدلاً من ذلك. يجب عدم إرسال هذه العلامة استخدامها على التخزين المستند إلى نظام UFS تسمح مواصفات UFS باستخدام من 64 بت IV
  • على الأجهزة التي تتوافق مع الأجهزة المرتبطة بالأجهزة الرئيسية، تتيح العلامة wrappedkey_v0 استخدام مفاتيح مغلَّفة بالأجهزة لـ FBE. لا يمكن استخدام هذا إلا في مجموعة واحدة باستخدام خيار التثبيت inlinecrypt، وإما inlinecrypt_optimized أو emmc_optimized .
  • تفرض العلامة dusize_4k حجم وحدة بيانات التشفير. أن يكون حجمها 4096 بايت حتى وإن لم يكن حجم كتلة نظام الملفات 4096 بايت. حجم وحدة بيانات التشفير هو دقة الملف تشفير المحتوى. تتوفّر هذه العلامة في أجهزة Android 15- يجب استخدام هذه العلامة لتفعيل الإشعارات فقط استخدام أجهزة التشفير المضمّن التي لا تدعم البيانات وحدات أكبر من 4096 بايت على جهاز يستخدم حجم صفحة أكبر من 4096 بايت ويستخدم نظام الملفات f2fs.

إذا كنت لا تستخدم أجهزة التشفير المضمّن، فإن الإعداد الموصى به لمعظم الأجهزة هي fileencryption=aes-256-xts. إذا كنت تستخدم inline لأجهزة التشفير فإن الإعداد الموصى به لمعظم الأجهزة fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (أو ما يعادل fileencryption=::inlinecrypt_optimized). مشغَّلة في الأجهزة التي لا تحتوي على أي شكل من أشكال تسريع AES، يمكن استخدام Adiantum بدلاً من معيار AES من خلال الإعداد fileencryption=adiantum

بدءًا من نظام التشغيل Android 14، كان AES-HCTR2 هو الوضع المفضّل لتشفير أسماء الملفات. للأجهزة التي تستخدم تعليمات التشفير السريع. ومع ذلك، لا يتم دعم سوى نواة Android الأحدث AES-HCTR2. من المقرّر أن يصبح الوضع التلقائي لأسماء الملفات في إصدار لاحق من نظام التشغيل Android. تشفير البيانات. إذا كانت النواة متوافقة مع معيار AES-HCTR2، يمكن تفعيلها لتشفير أسماء الملفات عن طريق ضبط filenames_encryption_mode على aes-256-hctr2 في أبسط الحالات سيتم إجراء ذلك باستخدام fileencryption=aes-256-xts:aes-256-hctr2.

على الأجهزة التي تعمل بنظام التشغيل Android 10 أو الإصدارات الأقدم، يتم قبول fileencryption=ice أيضًا لتحديد استخدام وضع تشفير محتوى الملف FSCRYPT_MODE_PRIVATE. هذا الوضع هو عن طريق النواة الشائعة لنظام التشغيل Android، غير أنه يمكن تنفيذها من خلال البائعين الذين يستخدمون تصحيحات نواة مخصصة. تنسيق المحتوى على القرص الذي ينشئه هذا الوضع كان خاصًا بالبائعين. على الأجهزة التي تعمل بنظام التشغيل Android 11 أو أعلى، فإن هذا الوضع لم يعد مسموحًا به استخدام تنسيق التشفير القياسي بدلاً من ذلك.

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

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

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

نظرًا لاستخدام Android 9، لا يمكن لـ FBE مساحة التخزين القابلة للاستخدام معًا.

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

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

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

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

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

الدمج مع Keymaster

يجب أن يبدأ تشغيل Keymaster HAL كجزء من فئة early_hal. ويرجع ذلك إلى أنّ مكتب FBE يتطلب أن يكون Keymaster جاهزًا للتعامل مع الطلبات التي يرسلها مرحلة تشغيل "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 التوجيه إلى الإعدادات التلقائية. موقع تخزين التطبيق للإشارة إلى تخزين DE بدلاً من الإشارة إلى تخزين CE. يجب أن تدقّق تطبيقات النظام التي تستخدم هذه العلامة في جميع البيانات المخزَّنة في الإعداد التلقائي. الموقع وتغيير مسارات البيانات الحساسة لاستخدام تخزين تخزين البريد الإلكتروني. الجهاز المصنعة التي تستخدم هذا الخيار يجب أن تفحص بعناية البيانات التي تخزينها للتأكد من أنها لا تحتوي على أي معلومات شخصية.

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

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

دعم مستخدمين متعددين

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

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

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

يحصل كل معرّف مستخدم لملف شخصي للعمل أيضًا على مفتاحين: DE وCE. عندما يأتي تحدي العمل يمكن الوصول إليها، ويتم إلغاء قفل مستخدم الملف الشخصي ويمكن لـ Keymaster (في TEE) توفير مفتاح TEE الخاص بالملف الشخصي.

جارٍ التعامل مع التحديثات

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

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

• التحقق من وجود ro.crypto.state
  • تأكَّد من أنّ ro.crypto.state مشفّر.
• التحقق من وجود ro.crypto.type
  • تأكَّد من ضبط ro.crypto.type على file.

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

تشفير fscrypt

يستخدم تنفيذ AOSP الطريقة "fscrypt". التشفير (متوافق مع ext4 وf2fs) في النواة (kernel) ويتم ضبطها عادةً على:

• تشفير محتوى الملف باستخدام AES-256 في وضع XTS
• تشفير أسماء الملفات باستخدام AES-256 في وضع CBC-CTS

يُستخدم تشفير Adiantum أيضًا عند تفعيل تشفير Adiantum، يتم عرض كل من محتوى الملفات وأسماءها. مع Adiantum.

يدعم fscrypt إصدارين من سياسات التشفير: الإصدار 1 والإصدار 2. تم إيقاف الإصدار 1، ومتطلبات CDD للأجهزة التي تعمل مع لا يتوافق الإصدار 11 من Android والإصدارات الأحدث إلا مع الإصدار. 2- تستخدم سياسات التشفير في الإصدار 2 HKDF-SHA512 لاشتقاق مفاتيح التشفير الفعلية من المفاتيح المتوفرة في مساحة المستخدم.

لمزيد من المعلومات حول fscrypt، يمكنك الاطلاع على مستندات النواة الأولية.

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

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

فئة مساحة التخزين	الوصف	الأدلة
غير مُشفَّر	الأدلة في /data التي لا يمكن تضمينها أو لا محميًا من قبل FBE. على الأجهزة التي تستخدم البيانات الوصفية بتشفير، فإن هذه الأدلة ليست مشفرة بشكل فعلي ولكن محمية بواسطة مفتاح تشفير بيانات التعريف وهو ما يعادل النظام DE.	/data/apex، باستثناء /data/apex/decompressed و /data/apex/ota_reserved التي هي النظام DE /data/lost+found /data/preloads /data/unencrypted كل الأدلة التي تستخدم أدلةها الفرعية مفاتيح FBE مختلفة. بالنسبة على سبيل المثال، بما أنّ كل دليل /data/user/${user_id} تستخدم مفتاحًا لكل مستخدم، ولا يستخدم /data/user أي مفتاح نفسها.
نظام DE	البيانات المشفّرة على الجهاز غير مرتبطة بمستخدم معيّن	/data/apex/decompressed /data/apex/ota_reserved /data/app /data/misc /data/system /data/vendor كل الأدلّة الفرعية الأخرى لـ /data التي يظهر فيها هذا الجدول لا يذكر وجود فئة مختلفة
لكل تمهيد	ملفات النظام المؤقتة التي لا تحتاج إلى فترة طويلة عند إعادة التشغيل	/data/per_boot
وصف المستخدم CE (داخلي)	البيانات المشفرة باستخدام بيانات الاعتماد لكل مستخدم على وحدة التخزين الداخلية	/data/data (الاسم المستعار /data/user/0) /data/media/${user_id} /data/misc_ce/${user_id} /data/system_ce/${user_id} /data/user/${user_id} /data/vendor_ce/${user_id}
المستخدم DE (داخلي)	البيانات المشفَّرة على وحدة التخزين الداخلية لكل مستخدم	/data/misc_de/${user_id} /data/system_de/${user_id} /data/user_de/${user_id} /data/vendor_de/${user_id}
المستخدم CE (يمكن استخدامه)	البيانات المشفرة باستخدام بيانات الاعتماد لكل مستخدم في وحدة تخزين قابلة للاستخدام	/mnt/expand/${volume_uuid}/media/${user_id} /mnt/expand/${volume_uuid}/misc_ce/${user_id} /mnt/expand/${volume_uuid}/user/${user_id}
المستخدم DE (يمكن استخدامه)	البيانات المشفرة على كل جهاز لكل مستخدم على وحدة تخزين قابلة للاستخدام	/mnt/expand/${volume_uuid}/misc_de/${user_id} /mnt/expand/${volume_uuid}/user_de/${user_id}

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

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

نوع المفتاح	الموقع الجغرافي الرئيسي	فئة التخزين للموقع الجغرافي للمفتاح
مفتاح DE للنظام	/data/unencrypted	غير مُشفَّر
مفاتيح CE (الداخلية) للمستخدم	/data/misc/vold/user_keys/ce/${user_id}	نظام DE
مفاتيح DE (الداخلية) للمستخدم	/data/misc/vold/user_keys/de/${user_id}	نظام DE
مفاتيح مطابقة المستخدمين (CE) (القابلة للاستخدام)	/data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid}	وصف المستخدم CE (داخلي)
مفاتيح المستخدم DE (القابلة للاستخدام)	/data/misc_de/${user_id}/vold/volume_keys/${volume_uuid}	المستخدم DE (داخلي)

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

يطبِّق vold أيضًا طبقة تشفير على جميع مفاتيح FBE. كل مفتاح إلى جانب مفاتيح CE لتخزين البيانات الداخلية باستخدام AES-256-GCM مفتاح تخزين المفاتيح غير مكشوفة خارج TEE. ويضمن ذلك عدم إمكانية فتح قفل مفاتيح FBE ما لم تم تشغيل نظام تشغيل موثوق به، وتم فرضه بواسطة التشغيل المتحقّق منه. عودة كما يتم طلب المقاومة على مفتاح ملف تخزين المفاتيح، ما يتيح لمفاتيح FBE أن يتم حذفه بأمان على الأجهزة التي يتيح فيها تطبيق Keymaster مقاومة العودة إلى الحالة السابقة. بالنسبة كإجراء احتياطي لأفضل جهد عند عدم توفر مقاومة التراجع، يتم استخدام خوارزمية SHA-512 تجزئة تبلغ 16384 بايت عشوائيًا مخزّنًا في ملف secdiscardable المخزّن إلى جانب المفتاح كـ معرّف التطبيق لمفتاح تخزين المفاتيح. يجب استرداد جميع وحدات البايت هذه لاسترداد مفتاح 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. يشفِّر LockSettingsService بعد ذلك استخدام كلمة المرور الاصطناعية مرتين: أولاً باستخدام مفتاح برنامج مشتق من وامتداد LSKF وسر Weaver، والثاني باستخدام ملف تخزين مفاتيح غير مرتبط بالمصادقة المفتاح. يوفّر ذلك حدودًا تفرضها شريحة العنصر الآمن (SE) على تخمينات LSKF.

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

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