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

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

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

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

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

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

امنیت Android از سازمان بالاتر

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

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

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

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

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

یکپارچگی: تحویل نرم‌افزار امن

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

پایه‌گذاری هویت میزبان در واقعیت

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

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

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

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

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

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

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

«خودروی نرم‌افزارمحور سیستم عامل Android Automotive» از استراتژی دفاع در عمق استفاده می‌کند تا به‌روزرسانی‌های پویای خودرو را بدون به‌خطر انداختن سازوکارهای دسترسی فعال کند. این مدل بر دو لایه اعتماد اصلی تکیه دارد:

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

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

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

نتیجه‌گیری

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

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