AAOS SDV - Secure by Design

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

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

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

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

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

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

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

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

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

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

تدمج مركبات SDV التي تعمل بنظام التشغيل AAOS البنية الأساسية المتطورة للاستجابة الأمنية وإدارة الثغرات الأمنية في 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 التي تعمل بنظام التشغيل AAOS، أعطينا الأولوية لأمان الذاكرة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الخاتمة

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

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