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

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

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

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

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

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

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

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

التبعيات

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

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

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

تطبيق

أولا وقبل كل شيء، تطبيقات مثل منبهات، والهاتف، وينبغي بذل تجهيزات للمعاقين الروبوت: directBootAware وفقا ل التمهيد المباشر ثائق المطور.

دعم النواة

يتوفر دعم 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 ، يجب على الشركات المصنعة للأجهزة أيضًا تمكين تسريع التشفير لتسريع التشفير المستند إلى الملفات وتحسين تجربة المستخدم. على سبيل المثال ، على الأجهزة المستندة إلى 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 . منذ الروبوت 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 المعلمة الجديدة في الروبوت 11، هي قائمة الأعلام مفصولة + حرف. يتم دعم العلامات التالية:
    • و v1 العلم يختار سياسات النسخة 1 التشفير. و v2 العلم يختار سياسات التشفير الإصدار 2. سياسات التشفير الإصدار 2 تستخدم أكثر أمنا ومرونة وظيفة الاشتقاق الرئيسية . الافتراضي هو V2 إذا كان الجهاز أطلق على الروبوت 11 أو أعلى (على النحو الذي يحدده ro.product.first_api_level )، أو V1 إذا كان الجهاز أطلق على الروبوت 10 أو أقل.
    • و inlinecrypt_optimized العلم يختار شكل التشفير الذي هو الأمثل للأجهزة التشفير المضمنة أن لا يعالج أعداد كبيرة من مفاتيح بكفاءة. يقوم بذلك عن طريق اشتقاق مفتاح تشفير واحد لمحتويات الملف لكل مفتاح CE أو DE ، بدلاً من مفتاح واحد لكل ملف. يتم تعديل توليد IVs (ناقلات التهيئة) وفقًا لذلك.
    • و emmc_optimized العلم يشبه inlinecrypt_optimized ، لكنه يختار أيضا وسيلة الجيل الرابع أن حدود الحبس إلى 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، كزبرة البئر يمكن استخدامها بدلا من AES من خلال وضع fileencryption=adiantum .

على الأجهزة التي أطلقت مع الروبوت 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

التخزين المتاح

منذ الروبوت 9، FBE و تخزين تبنيهم يمكن استخدامها جنبا إلى جنب.

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

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

  • ro.crypto.volume.options (جديد في الروبوت 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 أو أقل هو aes-256-heh . في معظم الأجهزة، وهذا يحتاج إلى أن يتم تجاوز صراحة aes-256-cts .
  • ro.crypto.fde_algorithm و ro.crypto.fde_sector_size حدد تنسيق تشفير ميتاداتا على تخزين تبنيهم. اطلع على وثائق تشفير البيانات الفوقية .

التكامل مع Keymaster

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

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

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

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

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

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

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

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

تفاصيل تنفيذ AOSP

يوفر هذا القسم تفاصيل حول تنفيذ AOSP ويصف كيفية عمل التشفير المستند إلى الملفات. لا ينبغي أن يكون من الضروري لمصنعي الأجهزة إجراء أي تغييرات هنا لاستخدام FBE و Direct Boot على أجهزتهم.

تشفير fscrypt

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

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

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

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

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

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

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

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

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

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

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