AAOS SDV – безопасность как основа

Мы в Google считаем, что безопасность должна быть заложена в архитектуру наших продуктов. Поэтому мы создали Android Automotive OS для программно-определяемых автомобилей (AAOS SDV) на основе существующих, проверенных рынком платформ, используя технологии виртуализации, такие как Cuttlefish. В объявлениях о выпуске мы рассказывали о функциях, а в этой записи блога мы рассмотрим некоторые концепции безопасности.

Основа: изоляция домена

Виртуализация для изоляции совместно размещенных экземпляров

Современная тенденция к объединению электронных блоков управления (ECU) в один чип снижает изоляцию за счет параллельного запуска нескольких доменов.

Хотя в экземплярах SDV AAOS есть внутренние механизмы изоляции, часто предпочтительнее запускать логические домены независимо. Например, у приборной панели и информационно-развлекательной системы разные требования. Мы используем виртуальные машины для параллельного запуска нескольких экземпляров, чтобы обеспечить явный доступ и изоляцию по умолчанию.

Унаследованная безопасность Android

AAOS SDV – это усовершенствованная версия Microdroid, минималистичной версии Android, оптимизированной для защищенных виртуальных машин (pVM). Благодаря этому инженеры платформы Android могут использовать уже знакомые им функции безопасности.

Изоляция процессов и запрет по умолчанию

В AAOS SDV используется модель изоляции на основе идентификатора пользователя (UID) Android, которая позволяет настроить песочницу для каждого приложения. Каждый сервис запускается в отдельном процессе с уникальным UID для управления правами доступа, каталогами данных и другими ограничениями. Мы используем возможности переносимого интерфейса операционных систем (POSIX), чтобы строго ограничить операции, и сочетаем это с Security-Enhanced Linux (SELinux), чтобы обеспечить запрет по умолчанию. Такой подход ограничивает каждый сервис до абсолютного минимума, то есть отсутствие конфигураций блокирует доступ, а не создает систему с чрезмерными разрешениями. Такой же подход мы применяем и к системе разрешений на отправку сообщений, о которой рассказывается ниже.

Проверенное управление уязвимостями

В AAOS SDV интегрирована развитая инфраструктура реагирования на угрозы безопасности и управления уязвимостями Android, которая позволяет выявлять, сортировать, устранять и раскрывать проблемы безопасности. Этот жизненный цикл включает непрерывное автоматическое сканирование, ежегодное глубокое тестирование на проникновение и сбор информации от партнеров через процесс сообщения об уязвимостях в системе безопасности Android. Команда безопасности сортирует обнаруженные уязвимости, присваивает им уровни серьезности в зависимости от риска и отслеживает устранение до завершения. Мы координируем правила раскрытия информации и выпуска обновлений с помощью ежемесячных бюллетеней по безопасности Android, а также проводим регулярные проверки безопасности и архитектуры, чтобы обеспечить долгосрочную устойчивость платформы.

Целостность: безопасная доставка ПО

Помимо изоляции процессов, безопасная платформа должна обеспечивать целостность кода перед его выполнением. Мы обеспечиваем безопасность доставки ПО следующими способами:

Аутентифицированная доставка ПО

AAOS SDV можно установить двумя способами. Во-первых, мы устанавливаем программное обеспечение непосредственно в системные разделы, разделы продуктов или поставщиков, доступные только для чтения, которые проверяют подписи при каждой загрузке. Это обеспечивает безопасность основных компонентов системы.

Во-вторых, для сервисов мы используем пакеты Android Pony EXpress (APEX). Каждый APEX-файл содержит ПО и его зависимости, а сам пакет рассматривается как раздел с обязательной проверкой подписи. В AAOS SDV APEX рассматривает подписание кода как непрерывный контракт, обеспечиваемый аппаратным обеспечением. APEX защищает от выполнения вредоносного кода с помощью четырех основных принципов: 

1. Неизменяемое хранилище

• Механизм. Ядро Android зацикливает файл apex_payload.img напрямую как необработанное устройство хранения данных, используя обратную связь только для чтения, и монтирует его со строгим флагом MS_RDONLY.
• Почему этот способ безопаснее. Файлы не распаковываются в хранилище автомобиля, поэтому у ОС нет пути записи. Даже если злоумышленник получит права суперпользователя, он не сможет изменить запущенный код APEX, поскольку уровень файловой системы отклоняет все команды записи.

2. Криптографическая целостность

• Механизм. Криптографическая подпись проверяет дерево Меркла всего образа файловой системы.
• Почему это безопаснее. Ядро использует dm-verity для проверки подписи каждого блока данных размером 4 КБ на лету. Если злоумышленник изменит необработанный блок во флеш-памяти, ядро обнаружит несоответствие хеша и немедленно остановит выполнение.

3. Строгая изоляция

• Механизм. Применяются правила изоляции процессов, описанные в разделе "Изоляция процессов". Это позволяет создать песочницу, в которой APEX монтируется как отдельный раздел в /apex.
• Почему это безопаснее. Каждый сервис получает собственный каталог пользователей и данных, что ограничивает доступ, если не включен общий доступ. Создавая отдельный раздел, Android устанавливает выделенное пространство имен компоновщика, гарантируя, что только явно открытые библиотеки будут доступны из непривилегированных системных демонов, тем самым минимизируя направления атак.

4. Atomic Recovery

• Механизм. APEX использует схему "Активный/Резервный", чтобы обеспечить двойную буферизацию откатов. Заводская версия APEX остается в неизменяемом разделе /system, а обновления хранятся в изменяемом разделе /data.
• Почему это безопаснее. Если обновление не удается или кажется вредоносным, демон apexd помечает его как неудачное на ранней стадии загрузки. Система мгновенно меняет символические ссылки обратно на раздел /system. Это позволяет избежать сбоев в работе системы.

Устойчивость: разработка с безопасной работой с памятью

Проверенная загрузка защищает систему от внешних изменений, но устойчивость платформы также зависит от того, как построен базовый код. При разработке новых компонентов для AAOS SDV мы уделяли особое внимание безопасности памяти.

Rust в качестве основного языка

AAOS SDV ориентирована на небольшие системы с требованиями к быстрой доступности. Это не позволяет использовать полный стек Android, поэтому мы ограничились нативным фреймворком. Чтобы создать необходимую инфраструктуру для распределенной системы, мы разработали несколько компонентов в дополнение к существующей инфраструктуре и приняли Rust в качестве основного языка. Мы также используем Rust для разработки бизнес-логики сервисов, помогая партнерам писать безопасное ПО. Rust использует функции безопасности памяти, чтобы предотвращать распространенные уязвимости, связанные с памятью, и при этом поддерживать производительность команды при написании нативного кода.

Распределенное доверие: управление сетью и доступом

Программно-определяемые автомобили требуют безопасного взаимодействия между изолированными доменами. Архитектура инициализации ячеистой сети SDV в AAOS решает эту проблему, криптографически проверяя версию и автора каждой конечной точки связи.

Инициализация устройств и ячеистой сети

Аутентификация в AAOS SDV Mesh выполняется путем математического связывания сетевого идентификатора каждого компонента с его фактическим состоянием двоичного выполнения. В этой модели неявное доверие к программному обеспечению заменяется проверкой на аппаратном уровне.

Аутентификация в ячеистой сети выполняется непрерывно и с использованием криптографии. Это позволяет избежать ситуаций, когда, например, шлюз автомобиля доверяет взломанной виртуальной машине информационно-развлекательной системы только потому, что у нее правильный IP-адрес.

Аппаратная изоляция и автоматические протоколы карантина обеспечивают безопасность платформы. Одноранговые устройства в сети SDV используют аутентификацию и аттестацию на основе DICE, как описано в следующем разделе, чтобы идентифицировать и сдерживать несанкционированное выполнение кода или вмешательство в конфигурацию.

TLS на основе DICE для защиты связи между виртуальными машинами

Привязка личности ведущего к реальности

Золотое правило DICE (Device Identifier Composition Engine). Если в коде встроенного ПО меняется хотя бы одна строка (даже в результате незначительного обновления или вредоносного эксплойта), составной идентификатор устройства (CDI) меняется полностью, генерируя совершенно другой псевдоним ключа.

DICE и TLS (Transport Layer Security) интегрируются, чтобы решить фундаментальную проблему архитектуры нулевого доверия: аутентификацию машины с одновременной проверкой целостности ее программного обеспечения.

Сочетание аппаратной идентификации DICE и зашифрованного рукопожатия TLS позволяет принимающему компьютеру проверить как личность вызывающего абонента, так и точное состояние его программного обеспечения.

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

• Уникальный секрет устройства (UDS). Случайный криптографический секрет, генерируемый во время производства. Доступ к UDS есть только у загрузчика операционной системы первого уровня. Он недоступен для любого другого ПО и внешних интерфейсов.
• Многоуровневые измерения (составной идентификатор устройства). ПЗУ оборудования инициирует цепочку, хешируя UDS с точным кодом и конфигурацией следующего уровня встроенного ПО. Так создается CDI, который затем последовательно связывается по мере загрузки каждого последующего уровня.

Взаимодействие сервисов в сети SDV AAOS регулируется строгими правилами контроля доступа. Как и в случае со всем ПО для SDV на базе AAOS, эти средства контроля доступа проходят аутентификацию, а их целостность защищается на уровне устройства и между устройствами в сети с помощью аутентификации на основе DICE.

Многоуровневый контроль доступа

В AAOS SDV используется стратегия углубленной защиты, которая позволяет динамически обновлять ПО автомобиля, не нарушая механизмы доступа. Эта модель опирается на два основных уровня доверия:

1. Разрешения на уровне сервиса. Определяют, к каким ресурсам сервис на виртуальной машине может получать доступ или предоставлять его в сетке.
2. Разрешения на уровне виртуальной машины. Определяют границы взаимодействия между виртуальными машинами для всех сервисов, размещенных на определенной виртуальной машине.

Эта модель позволяет OEM-производителям найти баланс между безопасностью и возможностью обновления. Для сервисов, не связанных с безопасностью, разрешительные правила на уровне виртуальной машины позволяют выполнять установку с помощью простых обновлений APEX, а не полного повторного развертывания виртуальной машины.

И наоборот, разрешения для сигналов, связанных с безопасностью, должны быть жестко закодированы в каждой виртуальной машине. Однако при добавлении сервиса, связанного с безопасностью, в новую виртуальную машину необходимо обновить разрешения на уровне виртуальной машины во всей системе. Это требует обновления всех виртуальных машин в сети.

Заключение

AAOS SDV расширяет архитектуру безопасности Android, чтобы соответствовать требованиям автомобильной отрасли, используя подход "безопасность по умолчанию". Благодаря виртуализации для изоляции доменов и применению правил доступа "запрещено по умолчанию" платформа создает устойчивую среду для программно-определяемых автомобилей. Криптографическая целостность поддерживается за счет аппаратной проверки выполняемого кода на лету.

Платформа включает непрерывные жизненные циклы безопасности, от упреждающего управления уязвимостями до подтверждения личности на аппаратном уровне с помощью DICE. Такая многоуровневая защита позволяет OEM находить баланс между возможностью обновления продвинутых функций и надежной безопасностью, необходимой для современных автомобилей. Технические характеристики и сведения о реализации доступны на обзорной странице AAOS SDV.