ما در Google معتقدیم که محصولاتمان باید از همان ابتدا ایمن طراحی شوند، به همین دلیل است که «سیستم‌عامل Android Automotive» را برای «خودروهای نرم‌افزارمحور» (AAOS SDV) بر روی پلاتفرم‌های موجود و اثبات‌شده در بازار ساخته‌ایم و از فناوری‌های مجازی‌سازی مانند Cuttlefish بهره می‌بریم. درحالی‌که اعلامیه‌های انتشار ما بر ویژگی‌ها متمرکز بود، این پست وبلاگ برخی‌از مفاهیم امنیتی را شرح می‌دهد.
پایه: جداسازی دامنه
مجازی‌سازی برای جداسازی نمونه‌های میزبانی مشترک
روند فعلی ادغام «واحدهای کنترل الکترونیکی» (ECU) در یک تراشه واحد، با اجرای چندین دامنه در کنار یکدیگر، جداسازی را کاهش می‌دهد.
اگرچه نمونه‌های SDV سیستم‌عامل Android Automotive سازوکارهای جداسازی داخلی ارائه می‌دهند، اغلب ترجیح داده می‌شود که دامنه‌های منطقی به‌طور مستقل اجرا شوند. برای مثال، خوشه و سیستم اطلاعات سرگرمی الزامات متمایزی دارند. ما از ماشین‌های مجازی برای اجرای چندین نمونه به‌طور موازی استفاده می‌کنیم تا مطمئن شویم که هم‌رسانی صریح باقی می‌ماند و جداسازی رفتار پیش‌فرض است.
امنیت Android از سازمان بالاتر
AAOS SDV از Microdroid تکامل یافته است که نسخه مینیمالیستی Android است و برای ماشین‌های مجازی حریم خصوصی (pVM) بهینه‌سازی شده است. این تبار ویژگی‌های امنیتی تثبیت‌شده‌ای را که مهندسان پلاتفرم Android ازقبل با آن‌ها آشنا هستند دراختیارشان قرار می‌دهد.
جداسازی پردازش و رد کردن به‌طور پیش‌فرض
AAOS SDV از مدل جداسازی مبتنی بر شناسه کاربر (UID) Android برای راه‌اندازی جعبه امن برای هر برنامه پیروی می‌کند. هر سرویس در فرایندی اختصاصی با شناسه کاربری منحصربه‌فرد اجرا می‌شود تا حقوق دسترسی، دایرکتوری‌های داده، و سایر محدودیت‌ها را مدیریت کند. ما از قابلیت‌های «رابط سیستم‌عامل قابل‌حمل» (POSIX) برای محدود کردن دقیق عملیات استفاده می‌کنیم و این قابلیت‌ها را با «لینوکس با امنیت بهبودیافته» (SELinux) جفت می‌کنیم تا وضعیت «رد کردن به‌طور پیش‌فرض» را اعمال کنیم. این رویکرد هر سرویس را به حداقل مطلق موردنیاز محدود می‌کند، به این معنی که پیکربندی‌های مفقودشده به‌جای ایجاد سیستمی با مجوزهای بیش‌ازحد، دسترسی را مسدود می‌کنند. همان‌طور که در ادامه این مقاله توضیح داده شده است، ما همین استراتژی را برای سیستم اجازه ارتباطات خود اعمال می‌کنیم.
مدیریت آسیب‌پذیری اثبات‌شده
«خودروی نرم‌افزارمحور سیستم عامل Android Automotive» زیرساخت مدیریت آسیب‌پذیری و پاسخ امنیتی کامل Android را برای شناسایی، اولویت‌بندی، اصلاح، و افشای یافته‌های امنیتی ادغام می‌کند. این چرخه حیات شامل اسکن خودکار مداوم، تست نفوذ عمیق سالانه، و اطلاعات مبتنی بر شریک ازطریق فرایند گزارش آسیب‌پذیری امنیتی Android است. تیم امنیتی آسیب‌پذیری‌های کشف‌شده را اولویت‌بندی می‌کند، رتبه‌بندی شدت را براساس خطر اختصاص می‌دهد، و اصلاح را تا تکمیل پیگیری می‌کند. ما خط‌مشی‌های شفاف‌سازی و انتشار را ازطریق بولتن‌های امنیتی Android ماهانه هماهنگ می‌کنیم و با ممیزی‌های امنیتی دوره‌ای دقیق و بازبینی‌های جامع معماری، انعطاف‌پذیری بلندمدت پلاتفرم را تضمین می‌کنیم.
یکپارچگی: تحویل نرم‌افزار امن
یک پلاتفرم امن، علاوه‌بر تضمین جداسازی پردازش، باید تمامیت کد را قبل‌از اجرا تضمین کند. ما ازطریق رویکردهای زیر، تحویل نرم‌افزار را ایمن می‌کنیم:
تحویل نرم‌افزار اصالت‌سنجی‌شده
«خودروی نرم‌افزارمحور سیستم‌عامل Android Automotive» دو روش نصب ارائه می‌دهد. ابتدا، نرم‌افزار را مستقیماً در بخش‌های فقط خواندنی سیستم، محصول، یا فروشنده نصب می‌کنیم که امضاها را در هر راه‌اندازی تأیید می‌کند. این کار قطعات اصلی سیستم را ایمن می‌کند.
دوم، از بسته‌های 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 برمی‌گرداند. این بازیابی اتمی کمک می‌کند تا سیستم در وضعیت خراب باقی نماند.
تاب‌آوری: توسعه ایمن حافظه
بار کردن درستی‌سنجی‌شده از سیستم دربرابر تغییرات خارجی محافظت می‌کند، اما انعطاف‌پذیری پلاتفرم به نحوه ساخت کد زیربنایی نیز بستگی دارد. برای مؤلفه‌های جدیدی که برای خودروی نرم‌افزارمحور سیستم عامل Android Automotive توسعه داده شده‌اند، ایمنی حافظه را در اولویت قرار دادیم.
Rust به‌عنوان زبان اصلی
AAOS SDV سیستم‌های کوچک با الزامات دردسترس بودن سریع را هدف قرار می‌دهد؛ این امر مانع از ساختن روی پشته کامل Android می‌شود، بنابراین ما دامنه خود را به چارچوب بومی محدود کردیم. برای ایجاد زیرساخت موردنیاز برای یک سیستم توزیع‌شده، علاوه‌بر زیرساخت موجود، چندین مؤلفه را توسعه دادیم و Rust را به‌عنوان زبان اصلی انتخاب کردیم. همچنین از Rust برای توسعه منطق کسب‌وکار سرویس‌ها استفاده می‌کنیم تا به شرکا کمک کنیم نرم‌افزار ایمن بنویسند. Rust به‌طور پیش‌فرض از ویژگی‌های ایمنی حافظه برای کمک به جلوگیری از کلاس‌های رایج آسیب‌پذیری‌های ایمنی حافظه استفاده می‌کند و درعین‌حال از توان عملیاتی تیم هنگام نوشتن کد بومی پشتیبانی می‌کند.
اعتماد توزیع‌شده: کنترل شبکه و دسترسی
خودروهای نرم‌افزارمحور به تعاملات امن بین دامنه‌های مجزا نیاز دارند. معماری تدارک مش خودروی نرم‌افزارمحور سیستم عامل Android Automotive با درستی‌سنجی رمزنگاری‌شده نسخه و نویسنده هر نقطه پایانی ارتباط، این پیچیدگی را برطرف می‌کند.
آماده‌سازی دستگاه و Mesh
AAOS SDV Mesh اصالت‌سنجی را با پیوند ریاضی هویت شبکه هر مؤلفه به وضعیت اجرای دودویی واقعی آن برقرار می‌کند. این مدل اعتماد ضمنی به نرم‌افزار را با درستی‌سنجی مبتنی بر سخت‌افزار جایگزین می‌کند.
اصالت‌سنجی Mesh به‌گونه‌ای طراحی شده است که پیوسته و رمزنگاری‌شده باشد. این کار از سناریوهایی جلوگیری می‌کند که در آن، برای مثال، سرویسی مانند درگاه خودرو به یک ماشین مجازی اطلاعاتی-سرگرمی به‌خطرافتاده اعتماد می‌کند، صرفاً به این دلیل که نشانی IP درستی دارد.
جداسازی سخت‌افزاری و پروتکل‌های قرنطینه خودکار پلاتفرم را ایمن می‌کنند. دستگاه‌های همتا در شبکه توری SDV از اصالت‌سنجی و گواهی مبتنی بر DICE استفاده می‌کنند، همان‌طور که در بخش زیر به‌تفصیل شرح داده شده است، تا به شناسایی و مهار اجرای کد غیرمجاز یا دستکاری پیکربندی کمک کنند.
«امنیت لایه انتقال» مبتنی بر DICE برای ایمن کردن ارتباط ماشین مجازی به ماشین مجازی
پایه‌گذاری هویت میزبان در واقعیت
قانون طلایی DICE (موتور ترکیب شناسه دستگاه): اگر یک خط کد در سفت‌افزار تغییر کند (حتی یک به‌روزرسانی جزئی یا سوءاستفاده مخرب)، «شناسه دستگاه مرکب» (CDI) مشتق‌شده کاملاً تغییر می‌کند و یک «کلید مستعار» کاملاً متفاوت تولید می‌کند.
DICE و TLS (امنیت لایه انتقال) باهم ادغام می‌شوند تا چالش اساسی معماری اعتماد صفر را حل کنند: اصالت‌سنجی کردن دستگاه و هم‌زمان درستی‌سنجی کردن تمامیت نرم‌افزار آن.
ترکیب شناسایی با پشتیبانی سخت‌افزاری DICE و دست‌دهی رمزگذاری‌شده TLS به دستگاه گیرنده امکان می‌دهد هم هویت تماس‌گیرنده و هم وضعیت دقیق نرم‌افزار آن را درستی‌سنجی کند.
گواهینامه‌های سنتی فقط مالکیت یک راز را اثبات می‌کنند؛ آن‌ها نمی‌توانند دستکاری سفت‌افزار را تشخیص دهند. DICE این مشکل را ازطریق لایه‌بندی راه‌اندازی اندازه‌گیری‌شده برطرف می‌کند:
- رمز یکتای دستگاه (UDS): رمز رمزنگاری تصادفی که درطول ساخت ایجاد می‌شود. فقط bootloader مرحله اول می‌تواند به UDS دسترسی داشته باشد؛ این کلید برای همه نرم‌افزارها و میاناهای خارجی دیگر غیرقابل‌دسترس باقی می‌ماند.
- اندازه‌گیری‌های لایه‌ای (شناسه دستگاه مرکب): ROM سخت‌افزار زنجیره را با درهم‌سازی UDS با کد دقیق و پیکربندی لایه میان‌افزار بعدی آغاز می‌کند. این کار یک CDI ایجاد می‌کند که سپس به‌صورت متوالی با بوت شدن هر لایه بعدی زنجیره‌ای می‌شود.
کنترل‌های دسترسی سخت‌گیرانه بر تعاملات سرویس در شبکه SDV سیستم‌عامل Android Automotive نظارت می‌کنند. درست مانند همه نرم‌افزارهای SDV در AAOS، این کنترل‌های دسترسی اصالت‌سنجی می‌شوند و یکپارچگی آن‌ها در سطح دستگاه و در سراسر دستگاه‌های موجود در شبکه ازطریق اصالت‌سنجی مبتنی بر DICE محافظت می‌شود.
کنترل دسترسی لایه‌ای
«خودروی نرم‌افزارمحور سیستم‌عامل Android Automotive» از استراتژی دفاع در عمق استفاده می‌کند تا به‌روزرسانی‌های پویای خودرو را بدون به‌خطر انداختن سازوکارهای دسترسی فعال کند. این مدل بر دو لایه اعتماد اصلی تکیه دارد:
- اجازه‌های سطح سرویس: منابع خاصی را که سرویس در VM مشخصی می‌تواند در سراسر شبکه توری به آن‌ها دسترسی داشته باشد یا آن‌ها را نمایش دهد تعریف می‌کند.
- اجازه‌های سطح ماشین مجازی: مرزهای ارتباطی بین ماشین‌های مجازی را برای همه سرویس‌های میزبانی‌شده در یک ماشین مجازی خاص تعریف کنید.
این مدل به سازندگان تجهیزات اصلی اجازه می‌دهد امنیت را با قابلیت به‌روزرسانی متعادل کنند. برای سرویس‌های غیرحساس به امنیت، خط‌مشی‌های سطح VM مجاز نصب را ازطریق به‌روزرسانی‌های APEX سبک به‌جای استقرار مجدد کامل VM فعال می‌کنند.
برعکس، اجازه‌های سیگنال‌های حساس به امنیت باید در هر VM به‌صورت کدگذاری‌شده باشد. نکته منفی این است که معرفی سرویس حساس به امنیت به VM جدید مستلزم به‌روزرسانی اجازه‌های سطح VM در سراسر سیستم است. این امر مستلزم به‌روزرسانی همه ماشین‌های مجازی در شبکه است.
نتیجه‌گیری
AAOS SDV معماری امنیتی Android را گسترش می‌دهد تا ازطریق رویکرد «امنیت در طراحی» به الزامات خاص خودرویی رسیدگی کند. این پلاتفرم با بهره‌گیری از مجازی‌سازی برای جداسازی دامنه و اجرای خط‌مشی‌های دسترسی «رد کردن به‌طور پیش‌فرض»، محیطی انعطاف‌پذیر برای خودروهای نرم‌افزارمحور ایجاد می‌کند. تمامیت رمزنگاری ازطریق درستی‌سنجی بی‌درنگ کد اجراشده با اعمال سخت‌افزاری حفظ می‌شود.
این پلاتفرم چرخه‌های حیات امنیتی مداوم را ادغام می‌کند، از مدیریت آسیب‌پذیری پیشگیرانه گرفته تا درستی‌سنجی هویت مبتنی بر سخت‌افزار ازطریق DICE. این دفاع‌های چندلایه به سازندگان تجهیزات اصلی امکان می‌دهد تا قابلیت به‌روزرسانی ویژگی‌های پیشرفته را با امنیت قوی لازم برای محیط‌های خودرویی مدرن متعادل کنند. مشخصات فنی و جزئیات پیاده‌سازی در صفحه نمای کلی خودروی نرم‌افزارمحور سیستم عامل Android Automotive دردسترس است.
-
اخبار محصولامروز، دسته بازی‌ها برای Android Auto و خودروهای مجهز به «سیستم‌عامل Android Automotive» با Google توکار رسماً از نسخه بتا به دردسترس عموم ارتقا می‌یابد.
Jan Kleinert • ۳ دقیقه خواندن -
اخبار محصولامروز در «نشست تولیدکنندگان نرم‌افزار Android»، دردسترس بودن گسترده بسیاری از ابزارها و میاناهای برنامه‌سازی کاربردی را اعلام می‌کنیم که برای حذف اصطکاک روزمره و ارائه انعطاف‌پذیری بیشتر به شما برای ساختن برنامه‌های Android عالی طراحی شده‌اند.
Matthew McCullough • زمان خواندن: ۴ دقیقه -
اخبار محصولAndroid Studio Rabbit 2 اکنون پایدار است و برای استفاده در تولید آماده است. این نسخه شامل ویژگی‌های کلیدی برای بهبود توسعه شما است، ازجمله Bring Your Own Agent، ویژگی‌های جدید «شبیه‌ساز واقعیت گسترده»، به‌روزرسانی LeakCanary، ابزار جدید مدیریت مهارت‌های عامل، بازبینی کد با هوش مصنوعی، و موارد دیگر.
Matthew Warner • ۳ دقیقه خواندن
جدیدترین اطلاعات آماری توسعه Android را به‌صورت هفتگی در صندوق ورودی‌تان دریافت کنید.
