AAOS SDV: segurança incorporada ao design

No Google, acreditamos que nossos produtos devem ser seguros por padrão. Por isso, criamos o Android Automotive Operating System para veículos definidos por software (AAOS SDV) em plataformas comprovadas pelo mercado, aproveitando tecnologias de virtualização como o Cuttlefish. Enquanto nossos anúncios de lançamento se concentraram nos recursos, esta postagem do blog descreve alguns dos conceitos de segurança.

Base: isolamento de domínio

Virtualização para isolar instâncias co-hospedadas

A tendência atual de consolidar unidades de controle eletrônico (ECUs, na sigla em inglês) em um único chip reduz o isolamento ao executar vários domínios lado a lado.

Embora as instâncias de SDV do AAOS forneçam mecanismos de isolamento interno, geralmente é preferível executar domínios lógicos de forma independente. Por exemplo, um cluster e um sistema de infoentretenimento têm requisitos diferentes. Usamos máquinas virtuais para executar várias instâncias em paralelo, garantindo que o compartilhamento permaneça explícito e o isolamento seja o comportamento padrão.

Segurança herdada do Android

O SDV do AAOS evoluiu do Microdroid, uma versão minimalista do Android otimizada para máquinas virtuais de privacidade (pVM). Essa linhagem oferece aos engenheiros da plataforma Android recursos de segurança estabelecidos que eles já conhecem.

Isolamento de processos e negação por padrão

O SDV do AAOS segue o modelo de isolamento baseado em ID do usuário (UID) do Android para configurar um sandbox para cada aplicativo. Cada serviço é executado em um processo dedicado com um UID exclusivo para gerenciar direitos de acesso, diretórios de dados e outras restrições. Usamos os recursos da interface de sistema operacional portátil (POSIX, na sigla em inglês) para limitar estritamente as operações e os combinamos com o Security-Enhanced Linux (SELinux) para aplicar uma postura de "negação por padrão". Essa abordagem restringe cada serviço ao mínimo necessário, o que significa que as configurações ausentes bloqueiam o acesso em vez de criar um sistema excessivamente permissivo. Aplicamos essa mesma estratégia ao nosso sistema de permissão de comunicação, conforme explicado mais adiante neste artigo.

Gestão de vulnerabilidades comprovada

O SDV do AAOS integra a infraestrutura de resposta de segurança e gestão de vulnerabilidades do Android para identificar, triar, corrigir e divulgar descobertas de segurança. Esse ciclo de vida incorpora verificações automatizadas contínuas, testes de penetração anuais detalhados e inteligência orientada por parceiros por meio do processo de denúncia de vulnerabilidades de segurança do Android. A equipe de segurança faz a triagem das vulnerabilidades descobertas, atribui classificações de gravidade com base no risco e acompanha a correção até a conclusão. Coordenamos as políticas de divulgação e lançamento por meio dos Boletins de segurança do Android mensais, complementados por auditorias de segurança periódicas rigorosas e análises arquitetônicas abrangentes para garantir a resiliência da plataforma a longo prazo.

Segurança na entrega de software

Além de garantir o isolamento de processos, uma plataforma segura precisa garantir a integridade do código antes da execução. Protegemos a entrega de software com as seguintes abordagens:

Entrega de software autenticada

O SDV do AAOS oferece dois métodos de instalação. Primeiro, instalamos o software diretamente em partições somente leitura do sistema, do produto ou do fornecedor, que validam as assinaturas em cada inicialização. Isso protege os componentes básicos do sistema.

Em segundo lugar, usamos pacotes Android Pony EXpress (APEX) para serviços. Cada APEX encapsula o software e as dependências dele, tratando o pacote como uma partição com validação de assinatura obrigatória. No SDV do AAOS, o APEX trata a assinatura de código como um contrato contínuo e aplicado por hardware. O APEX garante que a execução de código malicioso seja mitigada por quatro pilares principais: 

1. Armazenamento imutável

• O mecanismo:o kernel do Android faz um loop do arquivo apex_payload.img diretamente como um dispositivo de armazenamento bruto usando o loopback somente leitura, montando-o com a flag estrita MS_RDONLY.
• Por que é mais seguro:isso não expõe nenhum caminho de gravação ao SO, porque os arquivos não são descompactados no armazenamento do veículo. Mesmo que um invasor consiga privilégios de raiz, ele não poderá modificar o código APEX em execução porque a camada do sistema de arquivos rejeita todos os comandos de gravação.

2. Integridade criptográfica

• O mecanismo:a assinatura criptográfica valida uma árvore de Merkle de toda a imagem do sistema de arquivos.
• Por que é mais seguro:o kernel usa o dm-verity por bloco para verificar a assinatura de cada bloco de dados de 4 KB em tempo real. Se um invasor modificar um bloco bruto na memória flash, o kernel vai detectar a incompatibilidade de hash e interromper a execução imediatamente.

3. Isolamento rígido

• O mecanismo:aplica as regras de isolamento de processos, conforme descrito na seção Isolamento de processos, para criar um sandbox, com o APEX montado como uma partição dedicada em /apex.
• Por que é mais seguro:cada serviço recebe o próprio diretório de usuários e dados, restringindo o acesso, a menos que o compartilhamento seja explícito. Ao criar uma partição dedicada, o Android estabelece um namespace de vinculador dedicado, garantindo que apenas as bibliotecas explicitamente expostas sejam acessíveis por daemons do sistema não privilegiados, minimizando a superfície de ataque.

4. Recuperação atômica

• O mecanismo:o APEX usa um design "Ativo/Backup" para permitir reversões com buffer duplo. O APEX instalado de fábrica permanece na partição /system imutável, enquanto as atualizações ficam na partição /data mutável.
• Por que é mais seguro:se uma atualização falhar ou parecer mal-intencionada, o daemon apexd vai marcá-la como "com falha" durante a inicialização antecipada. O sistema troca instantaneamente os links simbólicos de volta para a partição /system. Essa recuperação atômica ajuda a garantir que o sistema não permaneça em um estado corrompido.

Resiliência: desenvolvimento seguro de memória

O carregamento verificado protege o sistema contra modificações externas, mas a resiliência da plataforma também depende de como o código subjacente é criado. Para novos componentes desenvolvidos para o SDV do AAOS, priorizamos a segurança da memória.

Rust como a linguagem principal

O SDV do AAOS é voltado para sistemas pequenos com requisitos de disponibilidade rápida. Isso impede a criação na pilha completa do Android, então limitamos nosso escopo ao framework nativo. Para criar a infraestrutura necessária para um sistema distribuído, desenvolvemos vários componentes além da infraestrutura atual e adotamos o Rust como a linguagem principal. Também usamos o Rust para desenvolver a lógica de negócios dos serviços, ajudando os parceiros a escrever software seguro. Por padrão, o Rust usa recursos de segurança de memória para ajudar a evitar classes comuns de vulnerabilidades de segurança de memória, além de oferecer suporte à produtividade da equipe ao escrever código nativo.

Confiança distribuída: controle de rede e acesso

Os veículos definidos por software exigem interações seguras entre domínios isolados. A arquitetura de provisionamento de malha do SDV do AAOS resolve essa complexidade verificando criptograficamente a versão e o autor de cada endpoint de comunicação.

Provisionamento de dispositivos e de malha

A malha de SDV do AAOS estabelece a autenticação vinculando matematicamente a identidade de rede de cada componente ao estado de execução binária real. Esse modelo substitui a confiança implícita no software pela verificação baseada em hardware.

A autenticação de malha foi projetada para ser contínua e criptográfica. Isso evita cenários em que, por exemplo, um serviço como um gateway de veículo confia em uma VM de infoentretenimento comprometida só porque ela tem o endereço IP correto.

O isolamento por hardware e os protocolos de quarentena automatizados protegem a plataforma. Os dispositivos de peering na malha do SDV usam autenticação e atestação baseadas em DICE, conforme detalhado na seção a seguir, para ajudar a identificar e conter a execução de código não autorizada ou a adulteração de configuração.

TLS baseado em DICE para proteger a comunicação entre VMs

Fundamentar a identidade do host na realidade

A regra de ouro do DICE (Mecanismo de composição de identificador de dispositivo): se uma única linha de código no firmware mudar (mesmo uma atualização secundária ou uma exploração maliciosa), o identificador de dispositivo composto (CDI) derivado vai mudar completamente, gerando uma chave de alias totalmente diferente.

O DICE e o TLS (Transport Layer Security) se integram para resolver o desafio fundamental da arquitetura de confiança zero: autenticar uma máquina e, ao mesmo tempo, verificar a integridade do software dela.

A combinação da identificação com suporte de hardware do DICE e do handshake criptografado do TLS permite que uma máquina receptora verifique a identidade do autor da chamada e o estado exato do software.

Os certificados tradicionais apenas comprovam a posse de um secret, mas não detectam adulterações de firmware. O DICE resolve isso com a camada de inicialização medida:

• O Unique Device Secret (UDS): um secret criptográfico aleatório gerado durante a fabricação. Somente o carregador de inicialização de primeiro estágio pode acessar o UDS, que permanece inacessível para todos os outros softwares e interfaces externas.
• Medições em camadas (o identificador de dispositivo composto): a ROM do hardware inicia a cadeia gerando um hash do UDS com o código e a configuração exatos da próxima camada de firmware. Isso cria um CDI, que é encadeado sequencialmente à medida que cada camada subsequente é inicializada.

Controles de acesso rigorosos regem as interações de serviço na malha de SDV do AAOS. Como todo o software SDV do AAOS, esses controles de acesso são autenticados, e a integridade deles é protegida no nível do dispositivo e entre os dispositivos na malha pela autenticação baseada em DICE.

Controle de acesso em camadas

O SDV do AAOS usa uma estratégia de defesa em profundidade para permitir atualizações dinâmicas do veículo sem comprometer os mecanismos de acesso. Esse modelo depende de duas camadas de confiança principais:

1. Permissões no nível do serviço:definem os recursos específicos que um serviço em uma determinada VM pode acessar ou expor na malha.
2. Permissões no nível da VM:definem os limites de comunicação entre VMs para todos os serviços hospedados em uma VM específica.

Esse modelo permite que os OEMs equilibrem a segurança com a capacidade de atualização. Para serviços que não são sensíveis à segurança, as políticas permissivas no nível da VM permitem a instalação por atualizações leves do APEX, em vez de reimplantações completas da VM.

Por outro lado, as permissões para indicadores sensíveis à segurança precisam ser codificadas em cada VM. A desvantagem é que a introdução de um serviço sensível à segurança em uma nova VM exige a atualização das permissões no nível da VM em todo o sistema. Isso exige uma atualização de todas as VMs na malha.

Conclusão

O SDV do AAOS estende a arquitetura de segurança do Android para atender a requisitos automotivos específicos usando uma abordagem de segurança por design. Ao usar a virtualização para isolamento de domínios e aplicar políticas de acesso de "negação por padrão", a plataforma estabelece um ambiente resiliente para veículos definidos por software. A integridade criptográfica é mantida por meio da verificação imediata do código executado, aplicada pelo hardware.

A plataforma integra ciclos de vida de segurança contínuos, que vão desde a gestão de vulnerabilidades proativa até a confirmação de identidade baseada em hardware via DICE. Essas defesas em várias camadas permitem que os OEMs equilibrem a capacidade de atualização de recursos avançados com a segurança robusta necessária para ambientes automotivos modernos. As especificações técnicas e os detalhes de implementação estão disponíveis na página de visão geral do SDV do AAOS.