يدعم 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
:
- قم بإنشاء دليل المستوى الأعلى (على سبيل المثال
misc_ne
) في قسمuserdata
. - قم بتكوين دليل المستوى الأعلى هذا ليكون غير مشفر (راجع استبعاد الدلائل ).
- قم بإنشاء دليل داخل دليل المستوى الأعلى للاحتفاظ بحزم OTA.
- قم بإضافة قاعدة 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 والأدلة التي تحميها بمزيد من التفاصيل:
فئة التخزين | وصف | الدلائل |
---|---|---|
نظام دي | البيانات المشفرة على الجهاز غير مرتبطة بمستخدم معين | /data/system و /data/app ومختلف الدلائل الفرعية الأخرى لـ /data |
لكل تمهيد | ملفات النظام المؤقتة التي لا تحتاج إلى البقاء على قيد الحياة بعد إعادة التشغيل | /data/per_boot |
المستخدم CE (داخلي) | بيانات مشفرة ببيانات اعتماد لكل مستخدم على وحدة التخزين الداخلية |
|
المستخدم DE (داخلي) | بيانات مشفرة لكل جهاز على وحدة التخزين الداخلية |
|
المستخدم CE (قابل للتبني) | بيانات مشفرة ببيانات اعتماد لكل مستخدم على وحدة تخزين قابلة للتبني |
|
المستخدم DE (قابل للتبني) | بيانات مشفرة على جهاز لكل مستخدم على وحدة تخزين قابلة للتبني |
|
تخزين المفاتيح وحمايتها
تتم إدارة جميع مفاتيح FBE بواسطة vold
ويتم تخزينها مشفرة على القرص، باستثناء مفتاح التمهيد الذي لا يتم تخزينه على الإطلاق. يسرد الجدول التالي المواقع التي يتم فيها تخزين مفاتيح FBE المختلفة:
نوع المفتاح | الموقع الرئيسي | فئة التخزين للموقع الرئيسي |
---|---|---|
مفتاح النظام DE | /data/unencrypted | غير مشفرة |
مفاتيح المستخدم CE (الداخلية). | /data/misc/vold/user_keys/ce/${user_id} | نظام دي |
مفاتيح المستخدم DE (الداخلية). | /data/misc/vold/user_keys/de/${user_id} | نظام دي |
مفاتيح المستخدم 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 باستخدام مفتاح 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.