AAOS SDV: segurança incorporada ao design

No Google, acreditamos que nossos produtos precisam ter segurança incorporada ao design. Por isso, criamos o Android Automotive Operating System para veículos definidos por software (AAOS SDV, na sigla em inglês) em plataformas comprovadas no mercado, aproveitando tecnologias de virtualização como o Cuttlefish. Embora nossos anúncios de lançamento tenham se concentrado nos recursos, esta postagem do blog descreve alguns dos conceitos de segurança.

Fundamentos: 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 do AAOS SDV ofereç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 distintos. Usamos máquinas virtuais para executar várias instâncias em paralelo, garantindo que o compartilhamento permaneça explícito e que o isolamento seja o comportamento padrão.

Segurança do Android herdada

O AAOS SDV evoluiu do Microdroid, uma versão minimalista do Android otimizada para máquinas virtuais de privacidade (pVMs). 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 AAOS SDV segue o modelo de isolamento baseado no ID de 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 recursos da interface de sistema operacional portátil (POSIX, na sigla em inglês) para limitar estritamente as operações e combiná-las com o Linux com segurança aprimorada (SELinux, na sigla em inglês) para aplicar uma postura de "negação por padrão". Essa abordagem restringe cada serviço ao mínimo absoluto 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ões de comunicação, conforme explicado mais adiante neste artigo.

Gestão de vulnerabilidades comprovada

O AAOS SDV integra a infraestrutura de resposta de segurança e gestão de vulnerabilidades do Android para identificar, priorizar, corrigir e divulgar descobertas de segurança. Esse ciclo de vida incorpora a verificação automatizada contínua, testes de penetração anuais e inteligência orientada por parceiros pelo processo de relatórios de vulnerabilidades de segurança do Android. A equipe de segurança prioriza as 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 pelos boletins de segurança do Android mensais, complementados por auditorias de segurança periódicas rigorosas e revisões 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 pelas seguintes abordagens:

Entrega de software autenticada

O AAOS SDV 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 do 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 AAOS SDV, 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 atenuada 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 MS_RDONLY estrita.
• 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 ganhe 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 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 estrito

• O mecanismo: isso aplica as regras de isolamento de processos descritas 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ário 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 bibliotecas explicitamente expostas sejam acessíveis a daemons de sistema não privilegiados, minimizando assim a superfície de ataque.

4. Recuperação atômica

• O mecanismo:o APEX usa um design "ativo/backup" para ativar reversões com buffer duplo. O APEX com flash de fábrica permanece na partição /system imutável, enquanto as atualizações residem na partição /data mutável.
• Por que é mais seguro: se uma atualização falhar ou parecer mal-intencionada, o daemon apexd a marcará como "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 AAOS SDV, priorizamos a segurança da memória.

Rust como linguagem principal

O AAOS SDV é destinado a sistemas pequenos com requisitos de disponibilidade rápida. Isso impede a criação na pilha completa do Android. Por isso, limitamos nosso escopo à estrutura nativa. 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 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 design, o Rust aproveita recursos de segurança de memória para ajudar a evitar classes comuns de vulnerabilidades de segurança de memória, oferecendo suporte à capacidade de produção da equipe ao escrever código nativo.

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

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

Provisionamento de dispositivos e malha

A malha do AAOS SDV 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 do 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 apenas porque ela tem o endereço IP correto.

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

TLS baseado em DICE para proteger a comunicação de VM para VM

Baseando a identidade do host na realidade

A regra de ouro do DICE (Device Identifier Composition Engine) : se uma única linha de código no firmware mudar (mesmo uma atualização menor ou um exploit malicioso), o identificador de dispositivo composto (CDI, na sigla em inglês) derivado vai mudar completamente, gerando uma chave de alias totalmente diferente.

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

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 só comprovam a posse de um segredo. Eles não podem detectar adulteração de firmware. O DICE resolve isso usando a camada de inicialização medida:

• O segredo exclusivo do dispositivo (UDS, na sigla em inglês) : um segredo criptográfico aleatório gerado durante a fabricação. Somente o bootloader de primeiro estágio pode acessar o UDS. Ele permanece inacessível a todos os outros softwares e interfaces externas.
• Medições em camadas (o identificador de dispositivo composto): a ROM de hardware inicia a cadeia fazendo o hash do UDS com o código exato e a configuração 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 do AAOS SDV. Assim como todo o software do AAOS SDV, esses controles de acesso são autenticados, e a integridade deles é protegida no nível do dispositivo e em todos os dispositivos da malha pela autenticação baseada em DICE.

Controle de acesso em camadas

O AAOS SDV emprega uma estratégia de defesa em profundidade para permitir atualizações dinâmicas de veículos 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 nã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 reimplantar a VM completa.

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 do sistema de 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 AAOS SDV estende a arquitetura de segurança do Android para atender a requisitos automotivos específicos usando uma abordagem de segurança incorporada ao design. Ao aproveitar a virtualização para isolamento de domínio 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 pela verificação em tempo real do código executado, aplicada por hardware.

A plataforma integra ciclos de vida de segurança contínuos, que vão do gerenciamento proativo de vulnerabilidades à verificação de identidade baseada em hardware pelo 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 AAOS SDV.