‫AAOS SDV - تصميم آمن

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

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

المحاكاة الافتراضية لعزل مثيلات الاستضافة المشتركة

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

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

ميزات الأمان المضمّنة في Android

تطوّرت ميزة "الأجهزة الافتراضية الآمنة" في نظام التشغيل Android Automotive من Microdroid، وهو إصدار بسيط من نظام التشغيل Android تم تحسينه للأجهزة الافتراضية المحسّنة للخصوصية (pVM). توفر هذه السلسلة لمهندسي نظام Android الأساسي ميزات أمان ثابتة يعرفونها جيدًا.

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

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

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

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

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

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

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

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

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

1. التخزين غير القابل للتغيير

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

2. سلامة التشفير

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

3- العزل الصارم

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

4. الاسترداد الذري

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

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

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

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

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

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

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

توفير المتطلبات اللازمة للأجهزة والشبكات المتداخلة

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

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

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

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

تحديد هوية المضيف استنادًا إلى معلومات حقيقية

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

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

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

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

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

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

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

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

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

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

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

الخاتمة

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

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