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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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 والإصدارات الأحدث. لتمكينه في نواة الإصدار 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 ، ولكنها تحدد أيضًا طريقة الجيل الرابع التي تحدد IVs إلى 32 بت. يجب استخدام هذه العلامة فقط على أجهزة التشفير المضمنة المتوافقة مع مواصفات JEDEC eMMC v5.2 وبالتالي فهي تدعم فقط IVs 32 بت. على أجهزة التشفير المضمنة الأخرى ، استخدم inlinecrypt_optimized بدلاً من ذلك. يجب عدم استخدام هذه العلامة مطلقًا في التخزين المستند إلى UFS ؛ تسمح مواصفات UFS باستخدام 64 بت IV.
  • على الأجهزة التي تدعم المفاتيح المغلفة بالأجهزة ، تتيح علامة 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 (AOSP تجريبي) ، AES-HCTR2 هو الوضع المفضل لتشفير أسماء الملفات للأجهزة التي تحتوي على تعليمات تشفير متسارعة. ومع ذلك ، فإن نواة Android الأحدث فقط هي التي تدعم AES-HCTR2. في إصدار Android في المستقبل ، من المخطط أن يصبح الوضع الافتراضي لتشفير أسماء الملفات. إذا كان kernel الخاص بك يحتوي على دعم 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 kernel. إذا كنت ترغب في استخدام جهاز تشفير مضمن بدلاً من ذلك ، فقم أيضًا بإضافة خيار تثبيت 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

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

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

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

تشفير fscrypt

يستخدم تطبيق AOSP تشفير "fscrypt" (مدعومًا بواسطة ext4 و f2fs) في النواة ويتم تكوينه عادةً من أجل:

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

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

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

لمزيد من المعلومات حول fscrypt ، راجع وثائق upstream 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.