الأمان

لمنع تشغيل حمولات عشوائية داخل جهاز افتراضي محمي (pVM)، يستخدم إطار عمل المحاكاة الافتراضية في Android (AVF) نهجًا أمنيًا متعدد الطبقات، حيث تضيف كل طبقة عمليات فرض إضافية. في ما يلي قائمة بطبقات الأمان في إطار عمل المحاكاة الافتراضية في Android:

  • يضمن Android السماح فقط للتطبيقات التي لديها أذونات جهاز افتراضي محمي بإنشاء أجهزة افتراضية محمية أو فحصها.

  • برنامج الإقلاع: يضمن برنامج الإقلاع السماح فقط بتشغيل صور الأجهزة الافتراضية المحمية الموقَّعة من قِبل Google أو مورّدي الأجهزة، ويراعي إجراء التشغيل المتحقّق منه في Android. تعني هذه البنية الأساسية أنّه لا يمكن للتطبيقات التي تشغّل أجهزة افتراضية محمية تجميع أنويتها الخاصة.

  • الجهاز الافتراضي المحمي يوفّر دفاعًا متعدد الطبقات، مثل SELinux، للحمولات التي يتم تشغيلها في الجهاز الافتراضي المحمي. يمنع الدفاع متعدد الطبقات ربط البيانات كبيانات قابلة للتنفيذ (neverallow execmem) ويضمن تطبيق W^X على جميع أنواع الملفات.

النموذج الأمني

يشكّل كلّ من السرية وصحة البيانات ومدى التوفّر (مثلث CIA) نموذجًا مُصمَّمًا لتوجيه سياسات أمان المعلومات:

  • السرية هي مجموعة من القواعد التي تحدّ من إمكانية الوصول إلى المعلومات.
  • صحة البيانات هي ضمان موثوقية المعلومات ودقتها.
  • مدى التوفّر هو ضمان إمكانية وصول الجهات المفوّضة إلى المعلومات بشكل موثوق.

السرية وصحة البيانات

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

تمتد القيود المفروضة للحفاظ على السرية أيضًا إلى أي جهات في النظام تجري عمليات وصول إلى الذاكرة نيابةً عن الأجهزة الافتراضية المحمية، أي الأجهزة والخدمات التي يمكنها الوصول إلى الذاكرة المباشرة (DMA) والتي يتم تشغيلها في طبقات أكثر امتيازًا. على مورّدي المنظومة على الرقاقة (SoC) استيفاء مجموعة جديدة من المتطلبات قبل أن يتمكّنوا من توفير دعم pKVM. وفي حال عدم استيفاء هذه المتطلبات، لا يمكن توفير السرية.

تنطبق صحة البيانات على البيانات في الذاكرة والحوسبة. لا يمكن للأجهزة الافتراضية المحمية تنفيذ ما يلي:

  • تعديل ذاكرة بعضها بدون موافقة.
  • التأثير في حالة وحدة المعالجة المركزية لبعضها.

يفرض برنامج Hypervisor هذه المتطلبات. مع ذلك، تنشأ أيضًا مشاكل تتعلق بصحّة البيانات مع مساحة تخزين البيانات الافتراضية عندما يجب تطبيق حلول أخرى، مثل dm-verity أو AuthFS.

لا تختلف هذه المبادئ عن عزل العمليات الذي يوفّره Linux، حيث يتم التحكّم في الوصول إلى صفحات الذاكرة باستخدام جداول الصفحات من المرحلة الأولى، ويُجري النواة عمليات تبديل السياق بين العمليات. مع ذلك، فإنّ جزء EL2 من pKVM، الذي يفرض هذه الخصائص، لديه سطح هجوم أقل بثلاثة أضعاف مقارنةً بنواة Linux بأكملها (حوالي 10 آلاف سطر من التعليمات البرمجية مقابل 20 مليون سطر من التعليمات البرمجية تقريبًا)، وبالتالي يوفّر ضمانًا أقوى لحالات الاستخدام التي تكون حساسة جدًا بحيث لا يمكن الاعتماد على عزل العمليات.

نظرًا إلى حجم pKVM، يمكن التحقّق منه رسميًا. نحن ندعم بنشاط الأبحاث الأكاديمية التي تهدف إلى إثبات هذه الخصائص رسميًا على ملف pKVM الثنائي الفعلي.

يتناول الجزء المتبقي من هذه الصفحة ضمانات السرية وصحة البيانات التي يوفّرها كل مكوّن حول pKVM.

برنامج Hypervisor (مراقب الأجهزة الظاهرية)

‫pKVM هو برنامج Hypervisor مستند إلى KVM يعزل الأجهزة الافتراضية المحمية وAndroid في بيئات تنفيذ لا تثق ببعضها. تظل هذه الخصائص سارية في حال حدوث اختراق داخل أي جهاز افتراضي محمي، بما في ذلك الجهاز المضيف. على برامج Hypervisor البديلة المتوافقة مع إطار عمل المحاكاة الافتراضية في Android توفير خصائص مماثلة.

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

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

  • يتم محو ذاكرة جميع الأجهزة الافتراضية المحمية والبرامج الثابتة للجهاز الافتراضي المحمي من عملية تشغيل جهاز واحدة قبل تشغيل برنامج إقلاع نظام التشغيل في عملية تشغيل الجهاز اللاحقة.

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

  • لا يتم تشغيل البرامج الثابتة للجهاز الافتراضي المحمي إذا تعذّر التحقّق من الصورة الأولية.

  • لا يتم تشغيل البرامج الثابتة للجهاز الافتراضي المحمي إذا تم اختراق سلامة instance.img.

  • لا يمكن لأي جهاز افتراضي محمي استخلاص سلسلة شهادات DICE ومعرّفات الأجهزة المركّبة (CDI) المقدّمة إليه إلا من خلال هذا الجهاز الافتراضي المحمي تحديدًا.

نظام التشغيل للضيف

Microdroid هو مثال على نظام تشغيل يتم تشغيله داخل جهاز افتراضي محمي. يتألف Microdroid من برنامج إقلاع مستند إلى U-boot ونواة GKI ومجموعة فرعية من مساحة مستخدم Android ومشغّل حمولة. تظل هذه الخصائص سارية في حال حدوث اختراق داخل أي جهاز افتراضي محمي، بما في ذلك الجهاز المضيف. على أنظمة التشغيل البديلة التي يتم تشغيلها في جهاز افتراضي محمي توفير خصائص مماثلة.

  • لن يتم تشغيل Microdroid إذا تعذّر التحقّق من boot.img أو super.img أو vbmeta.img أو vbmeta\_system.img.

  • لن يتم تشغيل Microdroid إذا تعذّر التحقّق من ملف APK.

  • لن يتم تشغيل مثيل Microdroid نفسه حتى إذا تم تعديل ملف APK.

  • لن يتم تشغيل Microdroid إذا تعذّر التحقّق من أي من ملفات APEX.

  • لن يتم تشغيل Microdroid (أو سيتم تشغيله بحالة أولية نظيفة) إذا تم تعديل instance.img خارج الجهاز الافتراضي المحمي للضيف.

  • يوفّر Microdroid شهادة إثبات لسلامة سلسلة الإقلاع.

  • يؤدي أي تعديل (غير موقَّع) على صور القرص التي تتم مشاركتها مع الجهاز الافتراضي المحمي للضيف إلى حدوث خطأ في الإدخال والإخراج على جانب الجهاز الافتراضي المحمي.

  • لا يمكن لأي جهاز افتراضي محمي استخلاص سلسلة شهادات DICE ومعرّفات الأجهزة المركّبة (CDI) المقدّمة إليه إلا من خلال هذا الجهاز الافتراضي المحمي تحديدًا.

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

Android

هذه هي الخصائص التي يحافظ عليها Android كمضيف، ولكنها لا تنطبق في حال حدوث اختراق للمضيف:

  • لا يمكن لجهاز افتراضي محمي للضيف التفاعل مباشرةً مع أجهزة افتراضية محمية أخرى للضيوف (مثل إجراء اتصال vsock).

  • لا يمكن سوى لـ VirtualizationService في الجهاز الافتراضي المحمي المضيف إنشاء قناة اتصال بجهاز افتراضي محمي.

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

  • لا تتم إعادة استخدام المعرّف، الذي يُعرف باسم معرّف السياق (CID)، والمستخدَم في إعداد vsock اتصالات بين المضيف والجهاز الافتراضي المحمي عندما يكون الجهاز الافتراضي المحمي المضيف قيد التشغيل. على سبيل المثال، لا يمكنك استبدال جهاز افتراضي محمي قيد التشغيل بجهاز آخر.

مدى التوفّر

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

تشمل مسؤوليات المضيف جدولة وحدات المعالجة المركزية الافتراضية للجهاز الافتراضي المحمي. على عكس برامج Hypervisor التقليدية من النوع الأول (مثل Xen)، يتخذ KVM قرار التصميم الصريح بتفويض جدولة أحمال العمل إلى نواة المضيف. نظرًا إلى حجم الجدولة وتعقيدها في الوقت الحالي، يقلّل قرار التصميم هذا بشكل كبير من حجم قاعدة الحوسبة الموثوق بها (TCB) ويتيح للمضيف اتخاذ قرارات جدولة أكثر استنارة لتحسين الأداء. مع ذلك، يمكن لمضيف ضار اختيار عدم جدولة جهاز ضيف مطلقًا.

وبالمثل، يفوّض pKVM أيضًا معالجة المقاطعات الفعلية إلى نواة المضيف لتقليل تعقيد برنامج Hypervisor وترك المضيف مسؤولاً عن الجدولة. يتم بذل جهد لضمان ألا يؤدي إعادة توجيه مقاطعات الضيوف إلا إلى رفض الخدمة (عدد قليل جدًا أو كبير جدًا أو مقاطعات تم توجيهها بشكل خاطئ).

أخيرًا، يكون برنامج مراقبة الجهاز الافتراضي (VMM) للمضيف مسؤولاً عن تخصيص الذاكرة وتوفير الأجهزة الافتراضية، مثل بطاقة الشبكة. يمكن لبرنامج مراقبة الجهاز الافتراضي الضار حجب الموارد عن الضيف.

على الرغم من أنّ pKVM لا يوفّر مدى التوفّر للضيوف، فإنّ التصميم يحمي مدى توفّر المضيف من الضيوف الضارين لأنّه يمكن للمضيف دائمًا إيقاف جهاز ضيف أو إنهاءه واستعادة موارده.

بروتوكول التشغيل الآمن

ترتبط البيانات بمثيلات جهاز افتراضي محمي، ويضمن بروتوكول التشغيل الآمن إمكانية التحكّم في الوصول إلى بيانات المثيل. تؤدي عملية التشغيل الأولى للمثيل إلى توفيره من خلال إنشاء ملح عشوائي سري للجهاز الافتراضي المحمي واستخراج التفاصيل، مثل مفاتيح التشفير العامة وعمليات التجزئة، من الصور المحمَّلة. تُستخدَم هذه المعلومات للتحقّق من عمليات التشغيل اللاحقة لمثيل الجهاز الافتراضي المحمي وضمان عدم إصدار أسرار المثيل إلا للصور التي تجتاز عملية التحقّق. تحدث هذه العملية لكل مرحلة تحميل داخل الجهاز الافتراضي المحمي: البرامج الثابتة للجهاز الافتراضي المحمي وABL للجهاز الافتراضي المحمي وMicrodroid وما إلى ذلك.

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

تسلّم كل مرحلة كائن CBOR مشفّرًا بشكل محدّد إلى الـ مرحلة التالية. يحتوي هذا الكائن على أسرار وسلسلة شهادات DICE، التي تحتوي على معلومات الحالة المتراكمة، مثل ما إذا كانت المرحلة الأخيرة قد تم تحميلها بشكل آمن.

الأجهزة غير المُقفلة

عند فتح قفل جهاز باستخدام fastboot oem unlock، يتم محو بيانات المستخدم. تحمي هذه العملية بيانات المستخدم من الوصول غير المصرّح به. يتم أيضًا إبطال البيانات الخاصة بجهاز افتراضي محمي عند فتح قفل جهاز.

بعد فتح القفل، يمكن لمالك الجهاز إعادة تحميل الأقسام المحمية عادةً من خلال "التشغيل المعتمَد"، بما في ذلك الأقسام التي تحتوي على pvmfw وتنفيذ pKVM. لذلك، لا يمكن الوثوق بجهاز غير مُقفل في الحفاظ على النموذج الأمني لجهاز افتراضي محمي.

يمكن للجهات الخارجية ملاحظة هذه الحالة التي قد تكون غير آمنة من خلال فحص حالة الجهاز التشغيل المعتمَد في شهادة إثبات المفتاح.