Безопасные возможности разработчика

Согласно документу об определении совместимости Android , производители автомобилей должны предоставлять возможность разработки приложений. Однако предоставление возможностей для разработчиков, аналогичных мобильным приложениям, внутри автомобилей делает эти автомобили уязвимыми для атак. Теперь доступ к возможностям для разработчиков может быть ограничен производителем автомобиля с помощью механизма аутентифицированных криптографических токенов. В частности, производитель может:

  • Укажите ограничения по умолчанию перед первой загрузкой.
  • Обеспечьте безопасную авторизацию разработчиков, при желании — с помощью криптовалютных токенов.
  • Изменения ограничений вступают в силу после того, как разработчик пройдет аутентификацию и авторизацию.

На этой странице описывается эталонная реализация, состоящая из приложения для отладки и управления ограничениями, а также конечной точки удаленного эмитента токенов.

Терминология

Помимо раздела «Терминология» , на этой странице используются следующие термины:

  • JSON Web Signature (JWS), определенная в RFC 7515.
  • Национальный институт стандартов и технологий (NIST)

Дизайн

Производители оборудования могут авторизовать разработчиков с помощью токенов JSON Web Signature (JWS) (RFC7515). В эталонной реализации токены доступа выдаются производителями оборудования и используются приложением-контроллером ограничений. Токены доступа разработаны таким образом, чтобы противостоять атакам повторного воспроизведения и подделке токенов.

Рисунок 1. Дизайн

Интеграция и настройка

Производители оборудования должны указывать ограничения по умолчанию при первой загрузке. Они делают это с помощью нескольких статических наложений ресурсов, которые переопределяют значения по умолчанию в рамках AOSP.

Ограничения по умолчанию для пользователя без графического интерфейса можно настроить с помощью строки 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 . Производитель оборудования может использовать эти строки для установки ограничений по умолчанию для каждого типа пользователей, например:

<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 взаимодействие пользователя со строкой настроек «Номер сборки» в разделе «Настройки» обрабатывается файлом 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 по-прежнему смогут получать доступ к параметрам разработчика, используя жест 7 касаний для тестирования, без ручного изменения настроек через интерфейс командной строки (CLI).

Контроллер ограничений отладки

Эталонная реализация контроллера ограничений отладки (DRC) предоставляется в AOSP по адресу packages/apps/Car/DebuggingRestrictionController .

DRC позволяет производителям автомобилей динамически и временно снимать ограничение no_debugging_features в серийных автомобилях для авторизованных сервисных специалистов и разработчиков. Вместо того чтобы оставлять инструменты отладки постоянно открытыми или требовать перепрошивки микропрограммы, встроенное в автомобиль приложение DRC предлагает пользователю пройти аутентификацию в бэкэнде производителя и отправить криптографически подписанный токен доступа для включения adb и параметров разработчика на ограниченный период диагностической сессии.

Эталонная реализация DRC состоит из двух основных компонентов:

  • Встроенное в автомобиль приложение DRC ( app/ ): привилегированное системное приложение (обладающее разрешением MANAGE_USERS ) на головном устройстве, которое аутентифицирует разработчиков, проверяет подпись сертификата X.509, имя хоста, nonce и срок действия входящих токенов JWS, а также динамически переключает ограничение no_debugging_features с помощью UserManager .
  • Cloud Token Issuer ( server/ ): Веб-сервис бэкэнда (развертываемый как Firebase Cloud Functions), который аутентифицирует учетные данные разработчика и выдает криптографически подписанные токены доступа RS256 JWS с ограниченным сроком действия.

Полные инструкции по настройке, инструментам генерации сертификатов и этапам развертывания см. в руководстве по отладке интеграции с контроллером ограничений .

Тестирование

Google рекомендует производителям оборудования начинать с эталонной реализации и постепенно расширять её.

  1. После настройки ограничений в файлах наложения скомпилируйте AAOS и проверьте определенные потоки. Используйте эталонное приложение и локальную службу с поддержкой JWS для проверки настроек доступа.
  2. Необязательно: настройте систему для использования вашего облачного сервиса с поддержкой JWS. Убедитесь, что на вашем бэкэнд-сервисе наблюдается ожидаемый поток данных.