AAOS SDV - Безопасность по умолчанию

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

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

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

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

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

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

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

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

AAOS SDV использует модель изоляции на основе идентификаторов пользователей (UID) 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 в качестве необработанного запоминающего устройства, применяя режим только для чтения (read-only loopback) и монтируя его со строгим флагом 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 использует функции безопасности памяти, чтобы предотвратить распространенные классы уязвимостей, связанных с безопасностью памяти, одновременно поддерживая производительность команды при написании нативного кода .

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

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

Выделение устройств и сети

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

Аутентификация в сетке (mesh authentication) разработана как непрерывная и криптографическая. Это предотвращает ситуации, когда, например, такой сервис, как автомобильный шлюз, доверяет скомпрометированной виртуальной машине информационно-развлекательной системы только потому, что у нее правильный 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 взаимодействие между сервисами регулируется строгим контролем доступа. Как и все программное обеспечение AAOS SDV, эти средства контроля доступа проходят аутентификацию, а их целостность защищается на уровне устройств и между устройствами в сети с помощью аутентификации на основе DICE.

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

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

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

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

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

Заключение

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

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