ترجمت واجهة Cloud Translation API‏ هذه الصفحة.
Switch to English

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

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

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

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

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

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

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

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

التبعيات

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

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

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

التنفيذ

أولاً وقبل كل شيء ، يجب جعل التطبيقات مثل المنبهات والهاتف وميزات إمكانية الوصول 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-cts إذا contents_encryption_mode هو aes-256-xts ، أو adiantum إذا contents_encryption_mode هو adiantum .
  • المعلمة flags ، الجديدة في Android 11 ، هي قائمة من الأعلام مفصولة بالحرف + . يتم دعم العلامات التالية:
    • تحدد علامة v1 سياسات تشفير الإصدار 1 ؛ تحدد علامة v2 سياسات تشفير الإصدار 2. تستخدم سياسات تشفير الإصدار 2 وظيفة اشتقاق مفتاح أكثر أمانًا ومرونة. ro.product.first_api_level الافتراضي هو v2 إذا تم تشغيل الجهاز على Android 11 أو أعلى (كما هو محدد بواسطة ro.product.first_api_level ) ، أو v1 إذا تم تشغيل الجهاز على Android 10 أو إصدار أقل.
    • inlinecrypt_optimized العلامة inlinecrypt_optimized تنسيق تشفير تم تحسينه لأجهزة التشفير المضمنة التي لا تتعامل مع عدد كبير من المفاتيح بكفاءة. يقوم بذلك عن طريق اشتقاق مفتاح تشفير واحد لمحتويات الملف لكل مفتاح CE أو DE ، بدلاً من مفتاح واحد لكل ملف. يتم تعديل توليد IVs (ناقلات التهيئة) وفقًا لذلك.
    • emmc_optimized علامة emmc_optimized مع inlinecrypt_optimized ، ولكنها تحدد أيضًا طريقة الجيل الرابع التي تحدد IVs إلى 32 بت. يجب استخدام هذه العلامة فقط على أجهزة التشفير المضمنة المتوافقة مع مواصفات JEDEC eMMC v5.2 وبالتالي فهي تدعم فقط IVs 32 بت. على أجهزة التشفير المضمنة الأخرى ، استخدم inlinecrypt_optimized بدلاً من ذلك. يجب عدم استخدام هذه العلامة مطلقًا في التخزين المستند إلى UFS ؛ تسمح مواصفات UFS باستخدام 64 بت IV.
    • تمكّن علامة wrappedkey_v0 من استخدام مفاتيح مغلفة بالأجهزة. عند التمكين ، لا يتم إنشاء مفاتيح FBE بواسطة البرنامج ، بل يتم إنشاؤها بواسطة Keymaster باستخدام علامة STORAGE_KEY . بعد ذلك ، يكون كل مفتاح FBE يتم توفيره فعليًا للنواة هو مفتاح STORAGE_KEY تم تصديره من Keymaster ، مما يؤدي إلى تغليفه بمفتاح سريع الزوال لكل عملية تمهيد. ثم توفر النواة المفاتيح المغلفة مباشرة إلى أجهزة التشفير المضمنة. عند التنفيذ بشكل صحيح ، فإن المفاتيح غير المغلفة لا توجد أبدًا في ذاكرة النظام ، ولا يمكن استخدام مفتاح ملفوف تم اختراقه بعد إعادة التشغيل. تتطلب هذه العلامة دعم الأجهزة ، ودعم Keymaster لـ STORAGE_KEY ، ودعم برنامج تشغيل kernel ، inlinecrypt التحميل 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 10 أو إصدار fileencryption=ice ، يتم أيضًا قبول تشفير الملفات fileencryption=ice لتحديد استخدام وضع تشفير محتويات ملف FSCRYPT_MODE_PRIVATE . لا يتم تنفيذ هذا الوضع بواسطة نواة Android الشائعة ، ولكن يمكن تنفيذه بواسطة البائعين باستخدام تصحيحات kernel المخصصة. كان التنسيق الموجود على القرص الذي تم إنتاجه بواسطة هذا الوضع خاصًا بالبائع. على الأجهزة التي تعمل بنظام Android 11 أو أعلى ، لم يعد هذا الوضع مسموحًا به ويجب استخدام تنسيق تشفير قياسي بدلاً من ذلك.

بشكل افتراضي ، يتم تشفير محتويات الملف باستخدام واجهة برمجة تطبيقات تشفير Linux kernel. إذا كنت ترغب في استخدام جهاز تشفير مضمن بدلاً من ذلك ، inlinecrypt أيضًا بإضافة خيار تثبيت 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 والتخزين القابل للتبني معًا.

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

على الأجهزة التي تعمل بنظام Android 11 أو أعلى ، استخدم الخصائص التالية:

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

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

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

التكامل مع Keymaster

يتم التعامل مع vold المفاتيح وإدارة حلقة مفاتيح kernel بواسطة vold . يتطلب تطبيق AOSP لـ FBE أن يدعم الجهاز Keymaster HAL الإصدار 1.0 أو أحدث. لا يوجد دعم للإصدارات السابقة من Keymaster HAL.

في التمهيد الأول ، يتم إنشاء مفاتيح المستخدم 0 وتثبيتها في وقت مبكر من عملية التمهيد. بحلول الوقت الذي تكتمل فيه مرحلة on-post-fs من init ، يجب أن يكون Keymaster جاهزًا للتعامل مع الطلبات. على أجهزة Pixel ، يتم التعامل مع ذلك من خلال وجود كتلة نصية تضمن بدء Keymaster قبل /data تحميل /data .

سياسة التشفير

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

في Android 11 والإصدارات الأحدث ، لم تعد سياسة التشفير مشفرة بشكل ثابت في موقع مركزي ، بل يتم تحديدها من خلال وسيطات لأوامر mkdir في نصوص init النصية. تستخدم الدلائل المشفرة باستخدام مفتاح DE الخاص بالنظام encryption=Require ، بينما تستخدم الدلائل غير المشفرة (أو الدلائل التي تم تشفير أدلةها الفرعية باستخدام مفاتيح لكل مستخدم) encryption=None .

في Android 10 ، تم تشفير سياسة التشفير في هذا الموقع:

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

defaultToDeviceProtectedStorage السمة 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 خلال تعيين 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 ، راجع وثائق upstream kernel .

الاشتقاق الرئيسي

يتم تخزين مفاتيح التشفير القائمة على الملفات ، وهي مفاتيح 512 بت ، مشفرة بواسطة مفتاح آخر (مفتاح 256 بت AES-GCM) موجود في TEE. لاستخدام مفتاح TEE هذا ، يجب استيفاء ثلاثة متطلبات:

  • رمز المصادقة
  • الاعتماد الممتد
  • "التجزئة القابلة للتجاهل"

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

بيانات الاعتماد الممتدة هي بيانات اعتماد المستخدم بعد التمليح scrypt خوارزمية scrypt . يتم تجزئة بيانات الاعتماد بالفعل مرة واحدة في خدمة إعدادات القفل قبل تمريرها إلى vold scrypt . هذا مرتبط بشكل مشفر بالمفتاح في TEE مع جميع الضمانات التي تنطبق على KM_TAG_APPLICATION_ID . إذا لم يكن لدى المستخدم بيانات اعتماد ، فلن يتم استخدام بيانات الاعتماد الممتدة ولا حاجة إليها.

secdiscardable hash هي secdiscardable hash 512 بت لملف عشوائي 16 كيلوبايت مخزّن جنبًا إلى جنب مع المعلومات الأخرى المستخدمة لإعادة بناء المفتاح ، مثل المصدر. يتم حذف هذا الملف بشكل آمن عند حذف المفتاح ، أو يتم تشفيره بطريقة جديدة ؛ تضمن هذه الحماية الإضافية أنه يجب على المهاجم استعادة كل جزء من هذا الملف المحذوف بشكل آمن لاستعادة المفتاح. هذا مرتبط بشكل مشفر بالمفتاح في TEE مع جميع الضمانات التي تنطبق على KM_TAG_APPLICATION_ID .

في معظم الحالات ، تخضع مفاتيح FBE أيضًا لخطوة اشتقاق مفاتيح إضافية في النواة من أجل إنشاء المفاتيح الفرعية المستخدمة بالفعل لإجراء التشفير ، على سبيل المثال لكل ملف أو لكل وضع. بالنسبة لسياسات تشفير الإصدار 2 ، يتم استخدام HKDF-SHA512 لهذا الغرض.