‫AAOS SDV - طراحی ایمن

در Google، معتقدیم محصولات ما باید ازطریق طراحی ایمن باشند، به همین دلیل «سیستم‌عامل Android Automotive برای خودروهای نرم‌افزارمحور» (AAOS SDV) را در پلاتفرم‌های اثبات‌شده در بازار موجود ساختیم و از فناوری‌های مجازی‌سازی مانند Cuttlefish استفاده کردیم. درحالی‌که اعلان‌های انتشار ما بر ویژگی‌ها تمرکز داشت، این پست وبلاگ برخی‌از مفاهیم امنیتی را شرح می‌دهد.

پایه: جداسازی دامنه

مجازی‌سازی برای جداسازی نمونه‌های میزبانی مشترک

روند کنونی ادغام «واحدهای کنترل الکترونیکی» (ECU) در یک تراشه واحد، با اجرای چند دامنه در کنار هم، جداسازی را کاهش می‌دهد.

اگرچه نمونه‌های AAOS SDV سازوکارهای جداسازی داخلی را ارائه می‌دهند، اما اغلب ترجیح داده می‌شود که دامنه‌های منطقی به‌طور مستقل اجرا شوند. برای مثال، یک خوشه و یک سیستم اطلاعات و سرگرمی الزامات متفاوتی دارند. ما از ماشین‌های مجازی برای اجرای هم‌زمان چندین نمونه استفاده می‌کنیم و اطمینان می‌دهیم که هم‌رسانی صریح باقی می‌ماند و جداسازی رفتار پیش‌فرض است.

امنیت Android موروثی

‫AAOS SDV از Microdroid، نسخه حداقلی Android که برای ماشین‌های مجازی حریم خصوصی (pVM) بهینه‌سازی شده است، تکامل یافته است. این نسب به مهندسان پلاتفرم Android ویژگی‌های امنیتی تثبیت‌شده‌ای را ارائه می‌دهد که ازقبل با آن‌ها آشنا هستند.

جداسازی پردازش و رد کردن به‌طور پیش‌فرض

‫AAOS SDV از مدل جداسازی مبتنی بر «شناسه کاربر» (UID) Android برای راه‌اندازی جعبه شنی برای هر برنامه پیروی می‌کند. هر سرویس در فرایندی اختصاصی با UID منحصربه‌فردی اجرا می‌شود تا حقوق دسترسی، دایرکتوری‌های داده، و دیگر محدودیت‌ها را مدیریت کند. از قابلیت‌های «میانای سیستم‌عامل قابل‌حمل» (POSIX) استفاده می‌کنیم تا عملیات را به‌شدت محدود کنیم و این قابلیت را با «لینوکس با امنیت بهبودیافته» (SELinux) جفت می‌کنیم تا وضعیت «رد کردن پیش‌فرض» را اعمال کنیم. این رویکرد هر سرویس را به حداقل مطلق موردنیاز محدود می‌کند، به این معنی که پیکربندی‌های ازدست‌رفته دسترسی را مسدود می‌کنند، نه اینکه سیستم بیش‌ازحد مجاز ایجاد کنند. ما همین استراتژی را برای سیستم اجازه ارتباط خود اعمال می‌کنیم، همان‌طور که در ادامه این مقاله توضیح داده شده است.

مدیریت آسیب‌پذیری اثبات‌شده

‫AAOS SDV زیرساخت مدیریت آسیب‌پذیری و پاسخ امنیتی بالغ Android را برای شناسایی، اولویت‌بندی، اصلاح، و افشای یافته‌های امنیتی یکپارچه می‌کند. این چرخه حیات شامل اسکن خودکار پیوسته، آزمایش نفوذ عمیق سالانه، و اطلاعات آماری شریک ازطریق فرایند گزارش آسیب‌پذیری امنیتی Android می‌شود. تیم امنیتی آسیب‌پذیری‌های شناسایی‌شده را اولویت‌بندی می‌کند، براساس خطر رده‌بندی شدت را تعیین می‌کند، و اصلاح را تا تکمیل پیگیری می‌کند. ما خط‌مشی‌های شفاف‌سازی و انتشار را ازطریق بولتن‌های امنیتی Android ماهانه هماهنگ می‌کنیم، که با ممیزی‌های امنیتی دوره‌ای دقیق و بررسی‌های جامع معماری تکمیل می‌شود تا از انعطاف‌پذیری بلندمدت پلاتفرم اطمینان حاصل شود.

تمامیت: ارائه نرم‌افزار امن

علاوه‌بر تضمین جداسازی فرایند، پلاتفرم امن باید قبل‌از اجرا، از تمامیت کد مطمئن شود. ما ازطریق روش‌های زیر، تحویل نرم‌افزار را ایمن می‌کنیم:

ارسال نرم‌افزار اصالت‌سنجی‌شده

‫AAOS SDV دو روش نصب ارائه می‌دهد. ابتدا، نرم‌افزار را مستقیماً در پارتیشن‌های فقط خواندنی سیستم، محصول، یا فروشنده نصب می‌کنیم که امضاها را در هر بار راه‌اندازی درستی‌سنجی می‌کند. این کار اجزای اصلی سیستم را ایمن می‌کند.

دوم، ما از بسته‌های Android Pony EXpress (APEX) برای سرویس‌ها استفاده می‌کنیم. هر APEX نرم‌افزار و وابستگی‌های آن را کپسوله می‌کند و بسته را به‌عنوان پارتیشنی با اعتبارسنجی امضای اجباری درنظر می‌گیرد. در AAOS SDV،‏ APEX امضای کد را به‌عنوان قراردادی پیوسته و سخت‌افزاری درنظر می‌گیرد. ‫APEX ازطریق چهار ستون اصلی تضمین می‌کند که اجرای کد مخرب کاهش یابد: 

۱. فضای ذخیره‌سازی تغییرناپذیر

• سازوکار: هسته Android فایل apex_payload.img را مستقیماً به‌عنوان دستگاه ذخیره‌سازی خام بااستفاده از حلقه برگشتی فقط خواندنی حلقه می‌کند و آن را با پرچم سخت‌گیرانه MS_RDONLY نصب می‌کند.
• چرا ایمن‌تر است: این روش هیچ مسیر نوشتاری را برای سیستم‌عامل آشکار نمی‌کند زیرا فایل‌ها در فضای ذخیره‌سازی خودرو ازهم باز نمی‌شوند. حتی اگر مهاجمی امتیازات ریشه را به‌دست آورد، نمی‌تواند کد APEX درحال اجرا را تغییر دهد زیرا لایه سیستم فایل همه دستورات نوشتن را رد می‌کند.

۲. تمامیت رمزنگارانه

• سازوکار: امضای رمزنگاری یک درخت Merkle از کل تصویر سیستم فایل را اعتبارسنجی می‌کند.
• چرا امن‌تر است: هسته از dm-verity برای هر بلوک استفاده می‌کند تا امضای هر بلوک داده ۴ کیلوبایتی را در لحظه تأیید کند. اگر مهاجمی یک بلوک خام را در حافظه فلش تغییر دهد، هسته عدم تطابق درهم‌سازی را تشخیص می‌دهد و بلافاصله اجرا را متوقف می‌کند.

۳. جداسازی سخت‌گیرانه

• سازوکار: این سازوکار قوانین جداسازی فرایند را همان‌گونه که در بخش «جداسازی فرایند» توضیح داده شده است اعمال می‌کند تا جعبه ایمنی ایجاد کند و APEX را به‌عنوان پارتیشن اختصاصی در /apex نصب کند.
• چرا ایمن‌تر است: هر سرویس فهرست داده و کاربر خود را دریافت می‌کند و دسترسی را محدود می‌کند، مگر اینکه هم‌رسانی به‌صورت صریح انجام شود. با ایجاد یک پارتیشن اختصاصی، Android یک فضای نام پیونددهنده اختصاصی ایجاد می‌کند و تضمین می‌کند که فقط کتابخانه‌هایی که به‌طور صریح درمعرض دید قرار گرفته‌اند از دیمون‌های سیستم غیرممتاز قابل‌دسترسی هستند، بنابراین سطح حمله را به حداقل می‌رساند.

۴. بازیابی اتمی

• سازوکار: APEX از طراحی «فعال/پشتیبان» برای فعال کردن برگرداندن‌های بافر دوگانه استفاده می‌کند. ‫APEX که در کارخانه نصب شده است در پارتیشن تغییرناپذیر /system باقی می‌ماند، درحالی‌که به‌روزرسانی‌ها در پارتیشن تغییرپذیر /data قرار می‌گیرند.
• چرا امن‌تر است: اگر به‌روزرسانی ناموفق باشد یا مخرب به‌نظر برسد، apexd daemon آن را درطول راه‌اندازی اولیه به‌عنوان «ناموفق» علامت‌گذاری می‌کند. سیستم بلافاصله پیوندهای نمادین را به پارتیشن /system برمی‌گرداند. این بازیابی اتمی کمک می‌کند تا سیستم در وضعیت خراب باقی نماند.

تاب‌آوری: توسعه ایمن حافظه

بارگیری تأییدشده از سیستم دربرابر تغییرات خارجی محافظت می‌کند، اما انعطاف‌پذیری پلاتفرم به نحوه ساخت کد زیربنایی نیز بستگی دارد. برای مؤلفه‌های جدیدی که برای AAOS SDV توسعه داده شده است، ایمنی حافظه را در اولویت قرار دادیم.

‫Rust به‌عنوان زبان اصلی

‫AAOS SDV سیستم‌های کوچکی را هدف‌یابی می‌کند که الزامات دردسترس بودن سریع دارند؛ این امر مانع از ساختن روی پشته کامل Android می‌شود، بنابراین محدوده خود را به چارچوب بومی محدود کردیم. برای ایجاد زیرساخت موردنیاز برای یک سیستم توزیع‌شده، علاوه بر زیرساخت موجود، چندین مؤلفه توسعه دادیم و Rust را به‌عنوان زبان اصلی انتخاب کردیم. ما همچنین از Rust برای توسعه منطق کسب‌وکار سرویس‌ها استفاده می‌کنیم و به شرکا کمک می‌کنیم نرم‌افزار ایمن بنویسند. طبق طراحی، ‫Rust از ویژگی‌های ایمنی حافظه استفاده می‌کند تا به جلوگیری از انواع رایج آسیب‌پذیری‌های ایمنی حافظه کمک کند و درعین‌حال از توان عملیاتی تیم هنگام نوشتن کد بومی پشتیبانی کند.

اعتماد توزیع‌شده: شبکه و کنترل دسترسی

خودروهای نرم‌افزاری به تعاملات ایمن بین دامنه‌های مجزا نیاز دارند. معماری آماده‌سازی مش AAOS SDV با درستی‌سنجی رمزنگاری نسخه و نویسنده هر نقطه پایانی ارتباطی، این پیچیدگی را برطرف می‌کند.

آماده‌سازی دستگاه و Mesh

«مش AAOS SDV» با ملزم کردن ریاضیاتی هویت شبکه هر مؤلفه به وضعیت اجرای باینری واقعی آن، اصالت‌سنجی را برقرار می‌کند. این مدل اعتماد ضمنی به نرم‌افزار را با درستی‌سنجی ریشه‌دار سخت‌افزاری جایگزین می‌کند.

اصالت‌سنجی Mesh به‌گونه‌ای طراحی شده است که پیوسته و رمزنگارانه باشد. این کار از سناریوهایی که در آن‌ها، برای مثال، سرویسی مثل درگاه خودرو به ماشین مجازی اطلاعات و سرگرمی آسیب‌دیده اعتماد می‌کند فقط به این دلیل که نشانی IP صحیح را دارد جلوگیری می‌کند.

پلاتفرم بااستفاده از پروتکل‌های قرنطینه خودکار و جداسازی سخت‌افزاری ایمن می‌شود. دستگاه‌های همتا در شبکه SDV از اصالت‌سنجی و گواهی مبتنی بر DICE استفاده می‌کنند، همان‌طور که در بخش زیر به‌تفصیل توضیح داده شده است، تا به شناسایی و مهار اجرای کد غیرمجاز یا دستکاری پیکربندی کمک کنند.

«امنیت لایه انتقال» مبتنی بر DICE برای ایمن کردن ارتباط ماشین مجازی به ماشین مجازی

واقعی کردن هویت میزبان

قانون طلایی DICE (موتور ترکیب‌بندی شناسه دستگاه): اگر یک خط کد در میان‌افزار تغییر کند (حتی یک به‌روزرسانی جزئی یا یک بهره‌جویی مخرب)، «شناسه دستگاه ترکیبی» (CDI) مشتق‌شده به‌طور کامل تغییر می‌کند و «کلید نام مستعار» کاملاً متفاوتی تولید می‌شود.

DICE و TLS (امنیت لایه انتقال) با هم ادغام می‌شوند تا چالش اساسی معماری بدون اعتماد را حل کنند: اصالت‌سنجی ماشین و هم‌زمان درستی‌سنجی تمامیت نرم‌افزار آن.

ترکیب شناسایی سخت‌افزارپشتیبان DICE و دست دادن رمزگذاری‌شده TLS به دستگاه گیرنده امکان می‌دهد هم هویت تماس‌گیرنده و هم وضعیت نرم‌افزار دقیق آن را درستی‌سنجی کند.

گواهینامه‌های سنتی فقط داشتن یک راز را اثبات می‌کنند؛ آن‌ها نمی‌توانند دستکاری سفت‌افزار را تشخیص دهند. ‫DICE این مشکل را ازطریق لایه کردن راه‌اندازی اندازه‌گیری‌شده برطرف می‌کند:

• رمز دستگاه یکتا (UDS): یک رمزنگاری تصادفی که درطول تولید ایجاد می‌شود. فقط bootloader مرحله اول می‌تواند به UDS دسترسی داشته باشد؛ این ویژگی برای همه نرم‌افزارهای دیگر و میاناهای خارجی غیرقابل‌دسترس باقی می‌ماند.
• اندازه‌گیری‌های لایه‌ای (شناسه دستگاه ترکیبی): ROM سخت‌افزار زنجیره را با درهم‌سازی UDS با کد دقیق و پیکربندی لایه بعدی میان‌افزار آغاز می‌کند. این کار یک CDI ایجاد می‌کند که سپس با بوت شدن هر لایه بعدی به‌صورت متوالی زنجیر می‌شود.

کنترل‌های دسترسی دقیق بر تعاملات سرویس در مش SDV در AAOS حاکم است. همانند همه نرم‌افزارهای AAOS SDV، این کنترل‌های دسترسی اصالت‌سنجی می‌شوند و تمامیت آن‌ها در سطح دستگاه و در سراسر دستگاه‌های موجود در شبکه ازطریق اصالت‌سنجی مبتنی بر DICE محافظت می‌شود.

کنترل دسترسی لایه‌ای

‫AAOS SDV از استراتژی دفاع در عمق برای فعال کردن به‌روزرسانی‌های پویا خودرو بدون به‌خطر انداختن سازوکارهای دسترسی استفاده می‌کند. این مدل بر دو لایه اعتماد اصلی تکیه دارد:

1. اجازه‌های سطح سرویس: منابع خاصی را که سرویس در ماشین مجازی معین می‌تواند در سراسر شبکه به آن‌ها دسترسی داشته باشد یا آن‌ها را نمایان کند تعریف کنید.
2. اجازه‌های سطح ماشین مجازی: مرزهای ارتباط بین ماشین‌های مجازی را برای همه سرویس‌های میزبانی‌شده در یک ماشین مجازی خاص تعریف می‌کند.

این مدل به «تولیدکنندگان تجهیزات اصلی» امکان می‌دهد بین امنیت و قابلیت به‌روزرسانی تعادل برقرار کنند. برای سرویس‌های غیرحساس به امنیت، خط‌مشی‌های سطح ماشین مجازی با رویکرد آسان‌گیرانه نصب ازطریق به‌روزرسانی‌های سبک APEX را به‌جای استقرار مجدد کامل ماشین مجازی امکان‌پذیر می‌کنند.

برعکس، اجازه‌های مربوط به سیگنال‌های حساس به امنیت باید در هر ماشین مجازی کدبندی سخت شوند. معاوضه این است که معرفی یک سرویس حساس به امنیت به یک ماشین مجازی جدید نیازمند به‌روزرسانی اجازه‌های سطح ماشین مجازی در سراسر سیستم است. این امر مستلزم به‌روزرسانی همه ماشین‌های مجازی در مش است.

نتیجه‌گیری

‫AAOS SDV معماری امنیتی Android را گسترش می‌دهد تا ازطریق رویکرد «امنیت ازطریق طراحی» به الزامات خاص خودرو رسیدگی کند. با بهره‌گیری از مجازی‌سازی برای جداسازی دامنه و اعمال خط‌مشی‌های دسترسی «رد کردن به‌طور پیش‌فرض»، پلاتفرم محیطی انعطاف‌پذیر برای خودروهای نرم‌افزاری ایجاد می‌کند. تمامیت رمزنگاری ازطریق درستی‌سنجی سخت‌افزاری و هم‌زمان کد اجراشده حفظ می‌شود.

این پلاتفرم چرخه‌های عمر امنیتی پیوسته را، از مدیریت آسیب‌پذیری پیش‌کنش‌گرانه گرفته تا درستی‌سنجی هویت ریشه‌دار سخت‌افزاری ازطریق DICE، یکپارچه می‌کند. این دفاع چندلایه به «تولیدکنندگان تجهیزات اصلی» امکان می‌دهد بین قابلیت به‌روزرسانی ویژگی‌های پیشرفته و امنیت قدرتمند لازم برای محیط‌های خودرو مدرن تعادل برقرار کنند. مشخصات فنی و جزئیات پیاده‌سازی در صفحه «نمای کلی AAOS SDV» دردسترس است.