يدعم Android 7.0 والإصدارات الأحدث التشفير المستند إلى الملفات (FBE). يسمح FBE بتشفير الملفات المختلفة بمفاتيح مختلفة يمكن إلغاء قفلها بشكل مستقل. تُستخدم هذه المفاتيح لتشفير محتويات الملف وأسماء الملفات. عند استخدام FBE ، لا يتم تشفير المعلومات الأخرى ، مثل تخطيطات الدليل وأحجام الملفات والأذونات وأوقات الإنشاء / التعديل. تُعرف هذه المعلومات الأخرى مجتمعة باسم البيانات الوصفية لنظام الملفات.
قدم Android 9 دعمًا لتشفير البيانات الوصفية. باستخدام تشفير البيانات الوصفية ، يقوم مفتاح واحد موجود في وقت التمهيد بتشفير أي محتوى غير مشفر بواسطة FBE. هذا المفتاح محمي بواسطة Keymaster ، والذي بدوره محمي بواسطة تمهيد تم التحقق منه.
يتم تمكين تشفير البيانات الوصفية دائمًا على التخزين القابل للتبني متى تم تمكين FBE. يمكن أيضًا تمكين تشفير البيانات الوصفية على وحدة التخزين الداخلية. يجب أن يتم تمكين تشفير البيانات الوصفية على الأجهزة التي يتم تشغيلها بنظام Android 11 أو أعلى على وحدة التخزين الداخلية.
التنفيذ على التخزين الداخلي
يمكنك إعداد تشفير البيانات الوصفية على التخزين الداخلي للأجهزة الجديدة عن طريق إعداد نظام ملفات metadata
، وتغيير تسلسل البدء ، وتمكين تشفير البيانات الوصفية في ملف fstab الخاص بالجهاز.
المتطلبات الأساسية
لا يمكن إعداد تشفير البيانات الوصفية إلا عند تهيئة قسم البيانات لأول مرة. نتيجة لذلك ، هذه الميزة للأجهزة الجديدة فقط ؛ هذا ليس شيئًا يجب على OTA تغييره.
يتطلب تشفير البيانات الوصفية تمكين وحدة dm-default-key
في النواة الخاصة بك. في Android 11 والإصدارات الأحدث ، يتم دعم dm-default-key
بواسطة نواة Android الشائعة ، الإصدار 4.14 والإصدارات الأحدث. يستخدم هذا الإصدار من dm-default-key
إطار عمل تشفير مستقل عن الأجهزة والبائع يسمى blk-crypto .
لتمكين dm-default-key
، استخدم:
CONFIG_BLK_INLINE_ENCRYPTION=y CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y CONFIG_DM_DEFAULT_KEY=y
يستخدم dm-default-key
أجهزة تشفير مضمنة (الأجهزة التي تقوم بتشفير / فك تشفير البيانات أثناء وجودها في الطريق إلى / من جهاز التخزين) عند توفرها. إذا كنت لن تستخدم جهاز تشفير مضمن ، فمن الضروري أيضًا تمكين الرجوع إلى واجهة برمجة تطبيقات التشفير الخاصة بـ kernel:
CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y
عند عدم استخدام جهاز تشفير مضمن ، يجب أيضًا تمكين أي تسريع متاح يعتمد على وحدة المعالجة المركزية كما هو موصى به في وثائق FBE .
في Android 10 والإصدارات الأقدم ، لم يكن dm-default-key
مدعومًا من قبل نواة Android الشائعة. لذلك كان الأمر متروكًا للبائعين لتنفيذ dm-default-key
.
إعداد نظام ملفات البيانات الوصفية
نظرًا لأنه لا يمكن قراءة أي شيء في قسم بيانات تعريف المستخدم حتى يتوفر مفتاح تشفير البيانات الوصفية ، يجب أن يخصص جدول القسم قسمًا منفصلاً يسمى "قسم البيانات الوصفية" لتخزين ملفات مدير البيانات الضخمة التي تحمي هذا المفتاح. يجب أن يكون حجم قسم البيانات الوصفية 16 ميغا بايت.
يجب أن تتضمن fstab.hardware
إدخالًا لنظام ملفات البيانات الوصفية الذي يعيش على هذا القسم الذي يقوم بتثبيته في /metadata
، بما في ذلك العلامة formattable
لضمان تنسيقها في وقت التمهيد. لا يعمل نظام الملفات f2fs على الأقسام الأصغر ؛ نوصي باستخدام ext4 بدلاً من ذلك. فمثلا:
/dev/block/bootdevice/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard wait,check,formattable
للتأكد من وجود نقطة تحميل /metadata
التعريف ، أضف السطر التالي إلى BoardConfig-common.mk
:
BOARD_USES_METADATA_PARTITION := true
التغييرات في تسلسل الحرف الأول
عند استخدام تشفير البيانات الوصفية ، يجب تشغيل vold
قبل /data
. للتأكد من بدء تشغيله مبكرًا بدرجة كافية ، أضف المقطع التالي إلى init.hardware.rc
:
# We need vold early for metadata encryption on early-fs start vold
يجب أن يكون Keymaster قيد التشغيل وجاهزًا قبل محاولات init لتحميل /data
.
يجب أن يحتوي init.hardware.rc
بالفعل على تعليمات mount_all
التي تقوم بتحميل /data
نفسها في مقطع on late-fs
. قبل هذا السطر ، أضف التوجيه لتنفيذ خدمة wait_for_keymaster
:
on late-fs … # Wait for keymaster exec_start wait_for_keymaster # Mount RW partitions which need run fsck mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
تشغيل تشفير البيانات الوصفية
أخيرًا أضف keydirectory=/metadata/vold/metadata_encryption
إلى عمود fs_mgr_flags لمدخل fstab
userdata
. على سبيل المثال ، قد يبدو خط fstab الكامل كما يلي:
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,inlinecrypt latemount,wait,check,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized,keydirectory=/metadata/vold/metadata_encryption,quota,formattable
بشكل افتراضي ، تكون خوارزمية تشفير البيانات الوصفية على وحدة التخزين الداخلية هي AES-256-XTS. يمكن تجاوز ذلك عن طريق تعيين خيار تشفير metadata_encryption
، أيضًا في العمود fs_mgr_flags :
- على الأجهزة التي تفتقر إلى تسريع AES ، قد يتم تمكين تشفير Adiantum عن طريق تعيين
metadata_encryption=adiantum
. - على الأجهزة التي تدعم مفاتيح مغلفة بالأجهزة ، يمكن جعل مفتاح تشفير البيانات الوصفية مغلفًا بالأجهزة عن طريق تعيين
metadata_encryption=aes-256-xts:wrappedkey_v0
(أو مكافئmetadata_encryption=:wrappedkey_v0
، لأن aesaes-256-xts
هي الخوارزمية الافتراضية).
نظرًا لتغيير واجهة kernel إلى dm-default-key
في Android 11 ، فإنك تحتاج أيضًا إلى التأكد من تعيين القيمة الصحيحة لـ PRODUCT_SHIPPING_API_LEVEL
في device.mk
. على سبيل المثال ، إذا تم تشغيل جهازك بنظام Android 11 (مستوى API 30) ، فيجب أن يحتوي device.mk
على:
PRODUCT_SHIPPING_API_LEVEL := 30
يمكنك أيضًا تعيين خاصية النظام التالية لفرض استخدام واجهة برمجة تطبيقات dm-default-key
الجديدة بغض النظر عن مستوى واجهة برمجة تطبيقات الشحن:
PRODUCT_PROPERTY_OVERRIDES += \ ro.crypto.dm_default_key.options_format.version=2
تصديق
للتحقق من تمكين تشفير البيانات الوصفية ومن أنه يعمل بشكل صحيح ، قم بإجراء الاختبارات الموضحة أدناه. ضع في اعتبارك أيضًا المشكلات الشائعة الموضحة أدناه.
الاختبارات
ابدأ بتشغيل الأمر التالي للتحقق من تمكين تشفير البيانات الوصفية على وحدة التخزين الداخلية:
adb root
adb shell dmctl table userdata
يجب أن يكون الإخراج مشابهًا لـ:
Targets in the device-mapper table for userdata: 0-4194304: default-key, aes-xts-plain64 - 0 252:2 0 3 allow_discards sector_size:4096 iv_large_sectors
إذا تجاوزت إعدادات التشفير الافتراضية عن طريق تعيين خيار metadata_encryption
في fstab
للجهاز ، فسيختلف الإخراج قليلاً عما سبق. على سبيل المثال ، إذا قمت بتمكين تشفير Adiantum ، فسيكون الحقل الثالث هو xchacha12,aes-adiantum-plain64
بدلاً من aes-xts-plain64
.
بعد ذلك ، قم بتشغيل vts_kernel_encryption_test للتحقق من صحة تشفير البيانات الوصفية و FBE:
atest vts_kernel_encryption_test
أو:
vts-tradefed run vts -m vts_kernel_encryption_test
مشاكل شائعة
أثناء استدعاء mount_all
، الذي يقوم بتحميل قسم البيانات المشفرة /data
الوصفية ، يقوم init
بتنفيذ أداة vdc. تتصل أداة vdc بـ vold
over binder
لإعداد الجهاز المشفر بالبيانات الوصفية وتركيب القسم. طوال مدة هذه المكالمة ، يتم حظر init
، وستمنع محاولات قراءة أو تعيين خصائص init
حتى ينتهي mount_all
. إذا تم ، في هذه المرحلة ، حظر أي جزء من عمل vold
بشكل مباشر أو غير مباشر من قراءة أو تعيين خاصية ، فسوف ينتج عن ذلك طريق مسدود. من المهم التأكد من أن vold
يمكنه إكمال عمل قراءة المفاتيح ، والتفاعل مع Keymaster ، وتركيب دليل البيانات دون التفاعل بشكل أكبر مع init
.
إذا لم يتم تشغيل Keymaster بالكامل عند تشغيل mount_all
، فلن يستجيب لـ vold
حتى يقرأ خصائص معينة من init
، مما يؤدي إلى حالة الجمود الموضحة تمامًا. إن وضع exec_start wait_for_keymaster
فوق استدعاء mount_all
ذي الصلة كما هو موضح يضمن أن Keymaster يعمل بشكل كامل مقدمًا وبالتالي يتجنب هذا المأزق.
التكوين على التخزين القابل للتبني
منذ Android 9 ، يتم دائمًا تمكين أحد أشكال تشفير البيانات الوصفية على التخزين القابل للتبني متى تم تمكين FBE ، حتى عندما لا يتم تمكين تشفير البيانات الوصفية على وحدة التخزين الداخلية.
في AOSP ، يوجد تطبيقان لتشفير البيانات الوصفية على التخزين القابل للتبني: واحد مهمل يعتمد على dm-crypt
، وآخر جديد يعتمد على dm-default-key
. للتأكد من تحديد التنفيذ الصحيح لجهازك ، تأكد من تعيين القيمة الصحيحة لـ PRODUCT_SHIPPING_API_LEVEL
في device.mk
. على سبيل المثال ، إذا تم تشغيل جهازك بنظام Android 11 (مستوى API 30) ، فيجب أن يحتوي device.mk
على:
PRODUCT_SHIPPING_API_LEVEL := 30
يمكنك أيضًا تعيين خصائص النظام التالية لفرض استخدام طريقة تشفير بيانات تعريف وحدة التخزين الجديدة (وإصدار سياسة FBE الافتراضي الجديد) بغض النظر عن مستوى واجهة برمجة تطبيقات الشحن:
PRODUCT_PROPERTY_OVERRIDES += \ ro.crypto.volume.metadata.method=dm-default-key \ ro.crypto.dm_default_key.options_format.version=2 \ ro.crypto.volume.options=::v2
الطريقة الحالية
على الأجهزة التي تعمل بنظام Android 11 أو أعلى ، يستخدم تشفير البيانات الوصفية على وحدة التخزين القابلة للتبني وحدة نواة dm-default-key
، تمامًا كما هو الحال في وحدة التخزين الداخلية. راجع المتطلبات الأساسية أعلاه التي سيتم تمكين خيارات تكوين kernel لها. لاحظ أن أجهزة التشفير المضمنة التي تعمل على وحدة التخزين الداخلية للجهاز قد لا تكون متاحة على وحدة التخزين القابلة للتبني ، وبالتالي قد تكون هناك حاجة إلى CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y
.
بشكل افتراضي ، تستخدم طريقة تشفير البيانات الوصفية لوحدة التخزين dm-default-key
خوارزمية تشفير AES-256-XTS مع قطاعات تشفير 4096 بايت. يمكن تجاوز الخوارزمية عن طريق تعيين خاصية نظام ro.crypto.volume.metadata.encryption
. قيمة هذه الخاصية لها نفس بناء الجملة كخيار metadata_encryption
التعريف fstab الموضح أعلاه. على سبيل المثال ، على الأجهزة التي تفتقر إلى تسريع AES ، يمكن تمكين تشفير Adiantum عن طريق تعيين ro.crypto.volume.metadata.encryption=adiantum
.
طريقة الإرث
على الأجهزة التي تعمل بنظام Android 10 أو إصدار أقل ، يستخدم تشفير البيانات الوصفية على وحدة التخزين القابلة للتبني وحدة dm-crypt
kernel بدلاً من dm-default-key
:
CONFIG_DM_CRYPT=y
على عكس طريقة dm-default-key
، تتسبب طريقة dm-crypt
في تشفير محتويات الملف مرتين: مرة باستخدام مفتاح FBE ومرة باستخدام مفتاح تشفير البيانات الوصفية. يقلل هذا التشفير المزدوج من الأداء وليس مطلوبًا لتحقيق أهداف الأمان لتشفير البيانات الوصفية ، نظرًا لأن Android يضمن أن مفاتيح FBE يصعب التنازل عنها على الأقل مثل مفتاح تشفير البيانات الوصفية. يمكن للبائعين إجراء تخصيصات kernel لتجنب التشفير المزدوج ، لا سيما من خلال تنفيذ خيار allow_encrypt_override
الذي سيمرره Android إلى dm-crypt
عند تعيين خاصية النظام ro.crypto.allow_encrypt_override
على " true
". لا يتم دعم هذه التخصيصات بواسطة نواة Android الشائعة.
بشكل افتراضي ، تستخدم طريقة تشفير البيانات الوصفية لوحدة تخزين dm-crypt
خوارزمية تشفير AES-128-CBC مع قطاعي التشفير ESSIV و 512 بايت. يمكن تجاوز ذلك عن طريق تعيين خصائص النظام التالية (والتي تُستخدم أيضًا لـ FDE):
- تحدد
ro.crypto.fde_algorithm
خوارزمية تشفير البيانات الوصفية. الخيارات هيaes-128-cbc
وadiantum
. يمكن استخدام Adiantum فقط إذا كان الجهاز يفتقر إلى تسريع AES. - يحدد
ro.crypto.fde_sector_size
حجم قطاع التشفير. الاختيارات هي 512 و 1024 و 2048 و 4096. لتشفير Adiantum ، استخدم 4096.