گزینه های توسعه دهنده ایمن

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

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

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

اصطلاحات

علاوه بر اصطلاحات ، این اصطلاحات نیز در این صفحه استفاده می‌شوند:

  • امضای وب JSON (JWS)، تعریف شده در RFC 7515
  • موسسه ملی استاندارد و فناوری (NIST)

طراحی

تولیدکنندگان اصلی تجهیزات (OEM) می‌توانند توسعه‌دهندگان را با توکن‌های امضای وب JSON (JWS) (RFC7515) مجاز کنند. در پیاده‌سازی مرجع، توکن‌های دسترسی توسط تولیدکنندگان اصلی تجهیزات (OEM) صادر شده و توسط برنامه کنترل‌کننده محدودیت مصرف می‌شوند. توکن‌های دسترسی برای مقاومت در برابر حملات بازپخش و توکن‌های جعلی طراحی شده‌اند.

شکل ۱. طراحی

ادغام و پیکربندی

تولیدکنندگان اصلی تجهیزات (OEM) باید محدودیت‌های پیش‌فرض را در اولین بوت مشخص کنند. تولیدکنندگان اصلی تجهیزات (OEM) این کار را با چندین پوشش منبع استاتیک انجام می‌دهند تا پیش‌فرض‌های موجود در چارچوب AOSP را نادیده بگیرند.

محدودیت‌های پیش‌فرض برای کاربر سیستم بدون سر (headless system) را می‌توان با رشته config_defaultFirstUserRestrictions در frameworks/base/core/res/res/values/config.xml پیکربندی کرد، برای مثال:

<!-- User restrictions set when the first user is created.
         Note: Also update appropriate overlay files. -->
    <string-array translatable="false" name="config_defaultFirstUserRestrictions">
        <item>no_debugging_features</item>
        <item>no_install_unknown_sources</item>
        <item>no_install_unknown_sources_globally</item>
    </string-array>

محدودیت‌های پیش‌فرض برای رانندگان، مسافران و مهمانان را می‌توان در frameworks/base/core/res/res/xml/config_user_types.xml پیکربندی کرد. یک تولیدکننده تجهیزات اصلی (OEM) می‌تواند این رشته‌ها را برای تنظیم محدودیت‌های پیش‌فرض برای هر نوع کاربر به ترتیب، همپوشانی کند، به عنوان مثال:

<user-types>
    <full-type name="android.os.usertype.full.SECONDARY" >
        <default-restrictions
            no_debugging_features="true"
            no_install_unknown_sources="true"/>
    </full-type>
    <full-type name="android.os.usertype.full.GUEST" >
        <default-restrictions
            no_debugging_features="true"
            no_install_unknown_sources="true"/>
    </full-type>
</user-types>

کنترل‌کننده ترجیح شماره ساخت

در AAOS، تعامل کاربر با ردیف تنظیمات شماره ساخت (Build Number preferences) در تنظیمات توسط BuildNumberPreferenceController.java واقع در packages/apps/Car/Settings/src/com/android/car/settings/system/BuildNumberPreferenceController.java مدیریت می‌شود.

وقتی محدودیت کاربر no_debugging_features ( UserManager.DISALLOW_DEBUGGING_FEATURES ) تنظیم شده باشد، BuildNumberPreferenceController شمارش معکوس توسعه‌دهنده را در هنگام ساخت ( user ) در هنگام ضربه زدن، سرکوب می‌کند:

@Override
protected boolean handlePreferenceClicked(Preference preference) {
    if (DevelopmentSettingsUtil.isDevelopmentSettingsEnabled(getContext())) {
        return true;
    }

    // Enforce restriction on production (user) builds
    if (Build.IS_USER && mUserManager.hasUserRestriction(UserManager.DISALLOW_DEBUGGING_FEATURES)) {
        showToast(R.string.dev_access_blocked_toast);
        return true;
    }

    mDevHitCountdown--;
    if (mDevHitCountdown == 0) {
        DevelopmentSettingsUtil.setDevelopmentSettingsEnabled(getContext(), true);
        showToast(R.string.show_dev_on);
    }
    return true;
}

استفاده از Build.IS_USER تضمین می‌کند که نسخه‌های عملیاتی، قرنطینه امنیتی را به شدت اجرا می‌کنند، در حالی که تیم‌های مهندسی داخلی در نسخه‌های userdebug همچنان می‌توانند با استفاده از ژست ۷-لمسی برای آزمایش، بدون لغو دستی رابط خط فرمان (CLI)، به گزینه‌های توسعه‌دهنده دسترسی داشته باشند.

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

یک پیاده‌سازی مرجع از کنترلر محدودیت اشکال‌زدایی (DRC) در AOSP در packages/apps/Car/DebuggingRestrictionController ارائه شده است.

DRC به تولیدکنندگان اصلی تجهیزات (OEM) اجازه می‌دهد تا محدودیت no_debugging_features را در خودروهای تولیدی برای تکنسین‌های خدمات مجاز و توسعه‌دهندگان به صورت پویا و موقت لغو کنند. به جای اینکه ابزارهای اشکال‌زدایی به طور دائم باز بمانند یا نیاز به فلش مجدد میان‌افزار باشد، برنامه DRC درون خودرو از کاربر می‌خواهد که با پشتیبان تولیدکننده اصلی تجهیزات (OEM) احراز هویت کند و یک توکن دسترسی امضا شده به صورت رمزنگاری شده را ارسال کند تا adb و گزینه‌های توسعه‌دهنده را برای یک جلسه تشخیصی محدود فعال کند.

پیاده‌سازی مرجع DRC از دو جزء اصلی تشکیل شده است:

  • برنامه کلاینت DRC درون خودرو ( app/ ): یک برنامه سیستمی دارای امتیاز (دارای مجوز MANAGE_USERS ) در واحد اصلی که توسعه‌دهندگان را احراز هویت می‌کند، امضای گواهی X.509، نام میزبان، nonce و انقضای توکن‌های JWS ورودی را اعتبارسنجی می‌کند و به صورت پویا محدودیت no_debugging_features را با استفاده از UserManager تغییر می‌دهد.
  • صادرکننده توکن ابری ( server/ ): یک سرویس وب بک‌اند (قابل استقرار به عنوان توابع ابری فایربیس) که اعتبارنامه‌های توسعه‌دهنده را تأیید می‌کند و توکن‌های دسترسی RS256 JWS امضا شده با رمزنگاری را با یک پنجره انقضای محدود صادر می‌کند.

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

آزمایش

گوگل توصیه می‌کند که تولیدکنندگان اصلی تجهیزات (OEM) با پیاده‌سازی مرجع شروع کنند و از آنجا به توسعه بپردازند.

  1. پس از پیکربندی محدودیت‌ها در فایل‌های پوششی، AAOS را کامپایل کرده و جریان‌های تعریف‌شده را اعتبارسنجی کنید. از برنامه مرجع و سرویس محلی مجهز به JWS برای تأیید تنظیمات دسترسی خود استفاده کنید.
  2. اختیاری: سیستم را برای استفاده از سرویس ابری مجهز به JWS خود پیکربندی کنید. تأیید کنید که جریان مورد انتظار را در سرویس backend خود مشاهده می‌کنید.