أخبار المنتجات

AAOS SDV - Secure by Design

مدّة القراءة: 5 دقائق
3 مؤلفون
Markus Vill, Sean Keys, István Nádor

في Google، نؤمن بأنّ منتجاتنا يجب أن تكون آمنة من حيث التصميم، ولهذا السبب أنشأنا نظام التشغيل Android Automotive للمركبات المحدّدة بالبرامج (AAOS SDV) على منصات حالية أثبتت كفاءتها في السوق، مع الاستفادة من تقنيات المحاكاة الافتراضية مثل Cuttlefish. في حين ركّزت إشعارات الإصدار على الميزات، توضّح مشاركة المدوّنة هذه بعض مفاهيم الأمان.

الأساسيات: عزل النطاق

المحاكاة الافتراضية لعزل النُسخ المستضافة بشكل مشترك

يؤدي الاتجاه الحالي لدمج وحدات التحكّم الإلكترونية (ECU) في شريحة واحدة إلى تقليل العزل من خلال تشغيل نطاقات متعددة جنبًا إلى جنب.

على الرغم من أنّ نُسخ SDV في نظام التشغيل Android Automotive توفّر آليات عزل داخلية، يُفضَّل غالبًا تشغيل النطاقات المنطقية بشكل مستقل. على سبيل المثال، تختلف متطلبات لوحة القيادة عن متطلبات نظام الترفيه والمعلومات. نستخدم الأجهزة الافتراضية لتشغيل نُسخ متعددة بالتوازي، ما يضمن بقاء المشاركة صريحة وأن يكون العزل هو الإعداد التلقائي.

أمان Android المكتسَب

تم تطوير AAOS SDV من Microdroid، وهو إصدار Android بسيط ومحسَّن للأجهزة الافتراضية الخاصة (pVM). ويوفّر هذا التسلسل لمهندسي نظام Android الأساسي ميزات أمان راسخة يعرفونها مسبقًا.

عزل العمليات والرفض تلقائيًا

يتبع AAOS SDV نموذج العزل المستند إلى رقم تعريف المستخدم (UID) في Android لإعداد وضع الحماية لكل تطبيق. وتعمل كل خدمة في عملية مخصّصة بمعرّف UID فريد لإدارة حقوق الوصول وأدلة البيانات والقيود الأخرى. نستخدم إمكانات واجهة نظام التشغيل المحمول (POSIX) لفرض قيود صارمة على العمليات، ونجمع بينها وبين نظام التشغيل Linux المحسّن الأمان (SELinux) لفرض وضع "الرفض تلقائيًا". يحدّ هذا النهج من وصول كل خدمة إلى الحدّ الأدنى المطلوب، ما يعني أنّ الإعدادات غير المكتملة تحظر الوصول بدلاً من إنشاء نظام يمنح أذونات مفرطة. ونطبّق هذه الاستراتيجية نفسها على نظام أذونات التواصل، كما هو موضّح لاحقًا في هذه المقالة.

إدارة الثغرات الأمنية المثبَتة

تدمج ميزة SDV في نظام التشغيل Android Automotive OS البنية الأساسية المتطورة للاستجابة الأمنية وإدارة الثغرات الأمنية في Android لتحديد نتائج الأمان وتصنيفها ومعالجتها والإفصاح عنها. تتضمّن مراحل النشاط هذه الفحص الآلي المستمر، واختبار الاختراق السنوي المتعمّق، والمعلومات المستندة إلى الشركاء من خلال عملية الإبلاغ عن الثغرات الأمنية في Android. يفرز فريق الأمان الثغرات الأمنية المكتشَفة، ويحدّد تقييمات الخطورة استنادًا إلى المخاطر، ويتتبّع عملية المعالجة حتى اكتمالها. ننسّق سياسات الإفصاح والإصدار من خلال نشرات أمان Android الشهرية، بالإضافة إلى عمليات تدقيق أمان دورية صارمة ومراجعات شاملة للبنية لضمان مرونة المنصة على المدى الطويل.

النزاهة: تسليم البرامج بشكل آمن

بالإضافة إلى ضمان عزل العمليات، يجب أن تضمن المنصة الآمنة سلامة الرموز البرمجية قبل تنفيذها. نحن نؤمّن تسليم البرامج من خلال الأساليب التالية:

تسليم البرامج التي تمت مصادقتها

توفّر مركبات SDV التي تعمل بنظام التشغيل AAOS طريقتَين للتثبيت. أولاً، نثبّت البرامج مباشرةً على أقسام النظام أو المنتج أو المورّد المخصّصة للقراءة فقط، والتي تتحقّق من التوقيعات عند كل عملية تشغيل. يؤدي ذلك إلى تأمين مكوّنات النظام الأساسية.

ثانيًا، نستخدم حزم Android Pony EXpress‏ (APEX) للخدمات. يغلّف كل ملف APEX البرنامج والتبعيات الخاصة به، ويتعامل مع الحزمة كقسم يتطلب التحقّق من التوقيع. في مركبات SDV التي تعمل بنظام التشغيل AAOS، يتعامل APEX مع توقيع الرموز البرمجية كعقد مستمر يتم فرضه من خلال الأجهزة. يضمن APEX الحدّ من تنفيذ الرموز البرمجية الضارة من خلال أربع ركائز أساسية: 

1. مساحة تخزين غير قابلة للتغيير

  • الآلية: تنشئ نواة Android حلقة لملف apex_payload.img مباشرةً كجهاز تخزين أولي باستخدام الاسترجاع للقراءة فقط، وتثبّته باستخدام العلامة MS_RDONLY الصارمة.
  • ما الذي يجعل هذه الطريقة أكثر أمانًا؟ لا تتيح هذه الطريقة مسار كتابة لنظام التشغيل لأنّه لا يتم فك حزمة الملفات في مساحة تخزين المركبة. حتى إذا حصل المهاجم على امتيازات الجذر، لن يتمكّن من تعديل رمز APEX قيد التشغيل لأنّ طبقة نظام الملفات ترفض جميع أوامر الكتابة.

2. صحة التشفير

  • الآلية: يتحقّق توقيع التشفير من صحة شجرة ميركل لصورة نظام الملفات بالكامل.
  • سبب زيادة الأمان: تستخدم النواة ميزة dm-verity لكل كتلة بيانات للتحقّق من توقيع كل كتلة بيانات بحجم 4 كيلوبايت بشكل فوري. إذا عدّل المهاجم كتلة أولية في ذاكرة الفلاش، ترصد النواة عدم تطابق التجزئة وتوقف التنفيذ على الفور.

3- عزل صارم

  • الآلية: يتم تطبيق قواعد عزل العمليات كما هو موضّح في قسم "عزل العمليات" لإنشاء وضع حماية، مع تثبيت APEX كقسم مخصّص ضمن ‎/apex.
  • لماذا يُعدّ هذا الإجراء أكثر أمانًا؟ لأنّ كل خدمة تحصل على دليل مستخدمين وبيانات خاص بها، ما يقيّد الوصول إليها ما لم تتم مشاركتها بشكل صريح. من خلال إنشاء قسم مخصّص، ينشئ Android مساحة اسم مخصّصة للرابط، ما يضمن عدم إمكانية الوصول إلا إلى المكتبات التي تم الكشف عنها صراحةً من برامج النظام الخفية غير المميّزة، وبالتالي تقليل فرص الهجوم.

4. Atomic Recovery

  • الآلية: تستخدم APEX تصميم "نشط/احتياطي" لتفعيل عمليات العودة إلى إصدار سابق المخزَّنة مؤقتًا بشكل مزدوج. يظل ملف APEX الذي تم تثبيته في المصنع على قسم /system غير القابل للتغيير، بينما تظل التحديثات على قسم /data القابل للتغيير.
  • سبب زيادة الأمان: في حال تعذّر التحديث أو بدا ضارًا، يضع برنامج apexd daemon علامة "تعذّر" عليه أثناء عملية التشغيل المبكر. يستبدل النظام على الفور الروابط الرمزية مرة أخرى بقسم /system. تساعد عملية الاسترداد الذرية هذه في ضمان عدم بقاء النظام في حالة معطّلة.

المرونة: التطوير الآمن للذاكرة

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

‫Rust كلغة أساسية

يستهدف نظام AAOS SDV الأنظمة الصغيرة التي تتطلّب توفّرًا سريعًا، ما يمنع إنشاء حزمة Android الكاملة، لذا حصرنا نطاقنا في إطار العمل الأصلي. لإنشاء البنية الأساسية المطلوبة لنظام موزَّع، طوّرنا مكوّنات متعددة بالإضافة إلى البنية الأساسية الحالية واعتمدنا لغة Rust كلغة أساسية. نستخدم أيضًا Rust لتطوير منطق الأعمال للخدمات، ما يساعد الشركاء في كتابة برامج آمنة. تم تصميم Rust للاستفادة من ميزات أمان الذاكرة للمساعدة في منع الفئات الشائعة من ثغرات أمان الذاكرة، مع دعم إنتاجية الفريق عند كتابة رموز برمجية أصلية.

الثقة الموزّعة: الشبكة والتحكّم في الوصول

تتطلّب المركبات المحدّدة بالبرامج تفاعلات آمنة بين النطاقات المعزولة. تعالج بنية توفير شبكة SDV في AAOS هذا التعقيد من خلال التحقّق من إصدار كل نقطة نهاية اتصال ومؤلفها باستخدام التشفير.

إعداد الجهاز والشبكة المتداخلة

تُنشئ شبكة SDV Mesh في نظام التشغيل Android Automotive OS المصادقة من خلال ربط هوية الشبكة لكل مكوّن رياضيًا بحالة التنفيذ الثنائي الفعلية. يستبدل هذا النموذج الثقة الضمنية في البرامج بالتحقّق المستند إلى الأجهزة.

تم تصميم مصادقة Mesh لتكون مستمرة ومشفرة. يمنع ذلك حدوث سيناريوهات، مثل أن تثق خدمة مثل بوابة المركبة بجهاز افتراضي مخترَق لنظام المعلومات والترفيه لمجرد أنّه يملك عنوان IP الصحيح.

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

بروتوكول أمان طبقة النقل (TLS) المستنِد إلى DICE لتأمين الاتصال بين الأجهزة الافتراضية

تأكيد هوية المضيف في الواقع

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

يتكامل DICE وبروتوكول أمان طبقة النقل (TLS) لحلّ التحدي الأساسي المتمثّل في بنية الثقة المعدومة: مصادقة الجهاز مع التحقّق في الوقت نفسه من سلامة برامجه.

يتيح الجمع بين عملية تحديد الهوية المستندة إلى الأجهزة في DICE والمصافحة المشفّرة في بروتوكول TLS للجهاز المستلِم التحقّق من هوية المتصل وحالة برنامجه بدقة.

تثبت الشهادات التقليدية فقط حيازة مفتاح سري، ولا يمكنها رصد التلاعب بالبرامج الثابتة. يعالج محرّك DICE هذه المشكلة من خلال طبقات التشغيل المُقاس:

  • المفتاح السرّي الفريد للجهاز (UDS): هو مفتاح تشفير عشوائي يتم إنشاؤه أثناء التصنيع. يمكن فقط لبرنامج الإقلاع في المرحلة الأولى الوصول إلى UDS، ولا يمكن لأي برامج أخرى أو واجهات خارجية الوصول إليه.
  • القياسات المتعدّدة الطبقات (معرّف الجهاز المركّب): تبدأ ذاكرة القراءة فقط (ROM) للأجهزة السلسلة من خلال تجزئة UDS باستخدام الرمز الدقيق وإعدادات طبقة البرامج الثابتة التالية. يؤدي ذلك إلى إنشاء معرّف CDI، والذي يتم ربطه بعد ذلك بالتسلسل عند تشغيل كل طبقة لاحقة.

تتحكّم عناصر التحكّم الصارمة في الوصول إلى تفاعلات الخدمات ضمن شبكة SDV في نظام التشغيل Android Automotive. وكما هو الحال مع جميع برامج SDV في نظام التشغيل AAOS، تتم مصادقة عناصر التحكّم في الوصول هذه، وتتم حماية سلامتها على مستوى الجهاز وعبر الأجهزة في الشبكة من خلال المصادقة المستندة إلى DICE.

التحكّم في الوصول إلى البيانات على مستويات متعددة

يستخدم نظام SDV في AAOS استراتيجية الدفاع في العمق لإتاحة تحديثات المركبات الديناميكية بدون التأثير في آليات الوصول. يعتمد هذا النموذج على طبقتَي ثقة أساسيتَين:

  1. الأذونات على مستوى الخدمة: يمكنك تحديد الموارد المحدّدة التي يمكن لخدمة على جهاز افتراضي معيّن الوصول إليها أو عرضها على مستوى الشبكة.
  2. الأذونات على مستوى الجهاز الافتراضي: يمكنك تحديد حدود الاتصال بين الأجهزة الافتراضية لجميع الخدمات المستضافة على جهاز افتراضي معيّن.

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

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

الخاتمة

image.png

يوسّع AAOS SDV بنية أمان Android لتلبية متطلبات معيّنة في مجال السيارات من خلال نهج "الأمان حسب التصميم". من خلال الاستفادة من المحاكاة الافتراضية لعزل النطاقات وفرض سياسات الوصول التي تمنع الوصول تلقائيًا، توفّر المنصة بيئة مرنة للمركبات المحدّدة بالبرامج. يتم الحفاظ على سلامة التشفير من خلال التحقّق الفوري من الرموز البرمجية التي يتم تنفيذها، وذلك باستخدام الأجهزة.

تدمج المنصة دورات حياة أمان مستمرة، بدءًا من الإدارة الاستباقية للثغرات الأمنية وحتى إثبات الهوية المستند إلى الأجهزة من خلال DICE. تتيح هذه الدفاعات المتعدّدة الطبقات للمصنّعين الأصليين للأجهزة تحقيق التوازن بين إمكانية تحديث الميزات المتقدّمة والأمان القوي اللازم لبيئات السيارات الحديثة. تتوفّر المواصفات الفنية وتفاصيل التنفيذ في صفحة "نظرة عامة على SDV في نظام التشغيل Android Automotive".

من كتابة:
متابعة القراءة