التشفير المستند إلى الملفات

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

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

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

التمهيد المباشر

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

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

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

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

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

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

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

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

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

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

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

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

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

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

التبعيات

لاستخدام تطبيق AOSP لـ FBE بشكل آمن، يحتاج الجهاز إلى تلبية التبعيات التالية:

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

تطبيق

أولاً وقبل كل شيء، يجب إنشاء تطبيقات مثل المنبهات والهاتف وميزات إمكانية الوصول بنظام Android:directBootAware وفقًا لوثائق مطور Direct Boot .

دعم النواة

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

CONFIG_FS_ENCRYPTION=y

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

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

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

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

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

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

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

في Android 10، تم ترميز إجراءات التشفير init في الموقع التالي:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

في Android 9 والإصدارات الأقدم، كان الموقع:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

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

حالة الاستخدام المقبولة الوحيدة المعروفة لهذا هي دعم قدرات OTA القديمة.

دعم التمهيد المباشر في تطبيقات النظام

جعل التطبيقات Direct Boot واعية

لتسهيل الترحيل السريع لتطبيقات النظام، هناك سمتان جديدتان يمكن تعيينهما على مستوى التطبيق. السمة defaultToDeviceProtectedStorage متاحة فقط لتطبيقات النظام. السمة directBootAware متاحة للجميع.

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

تعد سمة directBootAware على مستوى التطبيق بمثابة اختصار لوضع علامة على جميع المكونات الموجودة في التطبيق على أنها مدركة للتشفير.

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

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

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

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

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

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

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

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

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

قسم الاسترداد غير قادر على الوصول إلى وحدة التخزين المحمية بواسطة DE على قسم بيانات المستخدم. يوصى بشدة بالأجهزة التي تطبق FBE لدعم OTA باستخدام تحديثات نظام A/B . نظرًا لأنه يمكن تطبيق OTA أثناء التشغيل العادي، ليست هناك حاجة للاسترداد للوصول إلى البيانات الموجودة على محرك الأقراص المشفر.

عند استخدام حل OTA قديم، والذي يتطلب الاسترداد للوصول إلى ملف OTA الموجود على قسم userdata :

1. قم بإنشاء دليل المستوى الأعلى (على سبيل المثال misc_ne ) في قسم userdata .
2. قم بتكوين دليل المستوى الأعلى هذا ليكون غير مشفر (راجع استبعاد الدلائل ).
3. قم بإنشاء دليل داخل دليل المستوى الأعلى للاحتفاظ بحزم OTA.
4. قم بإضافة قاعدة SELinux وسياق الملف للتحكم في الوصول إلى هذا الدليل ومحتوياته. يجب أن تكون العملية أو التطبيقات التي تتلقى تحديثات OTA فقط قادرة على القراءة والكتابة في هذا الدليل. يجب ألا يكون لأي تطبيق أو عملية أخرى حق الوصول إلى هذا الدليل.

تصديق

للتأكد من أن الإصدار المطبق من الميزة يعمل على النحو المنشود، قم أولاً بتشغيل العديد من اختبارات تشفير CTS، مثل DirectBootHostTest و EncryptionTest .

إذا كان الجهاز يعمل بنظام التشغيل Android 11 أو إصدار أحدث، فقم أيضًا بتشغيل 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

بالإضافة إلى ذلك، يمكن للمختبرين تشغيل مثيل userdebug باستخدام شاشة القفل المعينة على المستخدم الأساسي. ثم قم بإدخال adb shell في الجهاز واستخدم su لتصبح جذرًا. تأكد من /data/data يحتوي على أسماء ملفات مشفرة؛ إذا لم يحدث ذلك، هناك خطأ ما.

يتم أيضًا تشجيع الشركات المصنعة للأجهزة على استكشاف تشغيل اختبارات 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 للأجهزة التي تعمل بنظام التشغيل Android 11 والإصدارات الأحدث فقط مع الإصدار 2. تستخدم سياسات التشفير الإصدار 2 HKDF-SHA512 لاشتقاق البيانات الفعلية مفاتيح التشفير من المفاتيح التي توفرها مساحة المستخدم.

لمزيد من المعلومات حول fscrypt، راجع وثائق kernel الأولية .

فئات التخزين

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

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

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

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

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

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

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

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

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

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

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