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

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

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

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

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

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

امنیت به ارث رسیده از اندروید

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

جداسازی و رد فرآیند به صورت پیش‌فرض

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

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

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

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

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

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

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

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

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

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

۲. یکپارچگی رمزنگاری

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

۳. انزوای شدید

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

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

• مکانیزم: APEX از طراحی "Active/Backup" برای فعال کردن rollback های دابل بافر استفاده می‌کند. APEX که در حالت factory-flash قرار دارد، در پارتیشن immutable/system باقی می‌ماند، در حالی که به‌روزرسانی‌ها در پارتیشن mutable/data قرار دارند.
• چرا امن‌تر است: اگر یک به‌روزرسانی با شکست مواجه شود یا مخرب به نظر برسد، سرویس apexd آن را در هنگام بوت اولیه به عنوان "شکست خورده" علامت‌گذاری می‌کند. سیستم فوراً پیوندهای نمادین را به پارتیشن /system برمی‌گرداند. این بازیابی اتمی به اطمینان از اینکه سیستم در حالت خراب باقی نمی‌ماند، کمک می‌کند.

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

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

زبان اصلی Rust

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

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

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

تأمین دستگاه و مش

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

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

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

TLS مبتنی بر DICE برای ایمن‌سازی ارتباطات ماشین مجازی با ماشین مجازی

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

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

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

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

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

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

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

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

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

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

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

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

نتیجه‌گیری

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

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