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

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

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

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

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

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

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

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

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

В AAOS SDV используется модель изоляции на основе идентификаторов пользователей Android, чтобы настроить изолированную среду для каждого приложения. Каждый сервис работает в отдельном процессе с уникальным UID для управления правами доступа, каталогами данных и другими ограничениями. Мы используем возможности Portable Operating System Interface (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.
• Почему это безопаснее. При таком способе ОС не получает доступ к пути записи, поскольку файлы не распаковываются в хранилище автомобиля. Даже если злоумышленник получит права root, он не сможет изменить выполняемый код APEX, поскольку уровень файловой системы отклоняет все команды записи.

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

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

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

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

4. Атомное восстановление

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

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

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

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

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

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

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

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

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

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

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

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

Обоснование личности хоста

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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