AAOS SDV - Secure by Design

في 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 التي تعمل بنظام التشغيل 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 هذا التعقيد من خلال التحقّق من إصدار كل نقطة نهاية اتصال ومؤلفها باستخدام التشفير.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الخاتمة

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

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