No Google, acreditamos que nossos produtos devem ser seguros por design, é por isso que construímos o Android Automotive Operating System for Software Defined Vehicle (AAOS SDV) em plataformas existentes e provas de mercado, aproveitando tecnologias de virtualização como Cuttlefish. Enquanto nossos anúncios de lançamento focaram nas funcionalidades, este post do blog detalha alguns dos conceitos de segurança.
Fundação: Isolamento por Domínio
Virtualização para isolar instâncias co-hospedadas
A tendência atual de consolidar Unidades de Controle Eletrônicas (ECUs) em um único chip reduz a isolamento ao executar múltiplos domínios lado a lado.
Embora as instâncias AAOS SDV forneçam mecanismos internos de isolamento, é geralmente preferível executar domínios lógicos independentemente. Por exemplo, um painel e um sistema de entretenimento têm requisitos distintos. Usamos máquinas virtuais para executar múltiplas instâncias em paralelo, garantindo que a compartilhamento permaneça explícito e o isolamento seja o comportamento padrão.
Segurança Inerente do Android
O AAOS SDV evoluiu de Microdroid, uma versão minimalista do Android otimizada para máquinas virtuais privadas (pVM). Esta linhagem fornece aos engenheiros da plataforma Android recursos de segurança estabelecidos que eles já conhecem.
Isolamento por Processo e Negar por Padrão
O AAOS SDV segue o modelo de isolamento baseado em User ID (UID) do Android para configurar uma sandbox para cada aplicativo. Cada serviço é executado em um processo dedicado com um UID único para gerenciar direitos de acesso, diretórios de dados e outras restrições. Empregamos a Interface Portável do Sistema Operacional (POSIX) para limitar operações estritamente e combinamos isso com o Security-Enhanced Linux (SELinux) para impor uma postura "negar por padrão". Essa abordagem restringe cada serviço ao mínimo absoluto necessário, significando que 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 tarde neste artigo.
Gestão de Vulnerabilidades Provas
O AAOS SDV integra a infraestrutura madura de resposta e gerenciamento de vulnerabilidade da segurança do Android para identificar, triar, corrigir e divulgar descobertas de segurança. Este ciclo de vida incorpora escaneamento contínuo automatizado, testes de penetração anuais em profundidade e inteligência por meio dos parceiros via o processo de relatório de vulnerabilidades de segurança do Android. A equipe de segurança tria as vulnerabilidades descobertas, atribui classificações de gravidade com base no risco e acompanha a correção até a conclusão. Coordenamos a divulgação e as políticas de lançamento através dos boletins mensais Android Security Bulletins, complementados por rigorosos auditores periódicos de segurança e revisões arquiteturais abrangentes para garantir a resiliência da plataforma a longo prazo.
Integridade: Entrega Segura de Software
A além de garantir o isolamento por processo, uma plataforma segura deve assegurar a integridade do código antes da execução. Garantimos a entrega de software seguro através das seguintes abordagens:
Entrega Autenticada de Software
O AAOS SDV fornece dois métodos de instalação. Primeiro, instalamos o software diretamente nas partições do sistema, produto ou fornecedor somente leitura, que validam assinaturas em cada inicialização. Isso garante a segurança dos componentes básicos do sistema.
Em segundo lugar, utilizamos pacotes Android Pony EXpress (APEX) para serviços. Cada APEX encapsula software e suas dependências, tratando o pacote como uma partição com validação de assinatura obrigatória. No AAOS SDV, a APEX trata a assinatura do código como um contrato contínuo e fortemente vinculado ao hardware. A APEX garante que a execução de código malicioso seja mitigada através de quatro pilares fundamentais:
1. Armazenamento Imutável
- O Mecanismo: A kernel do Android lê o arquivo
apex_payload.imgdiretamente como um dispositivo de armazenamento usando a opção read-only loopback, montando-o com a flag estritaMS_RDONLY. - Por que é mais seguro: Isto expõe nenhuma rota de escrita ao sistema operacional porque os arquivos não são descompactados no armazenamento do veículo. Mesmo se um atacante adquirir privilégios
root, eles não podem modificar o código APEX em execução, pois a camada de sistema de arquivos rejeita todas as comandos de escrita.
2. Integridade Criptográfica
- O Mecanismo: A assinatura criptográfica valida uma árvore de Merkle do sistema de arquivos inteiro.
- Por que é mais seguro: O kernel usa verificação por bloco
dm-veritypara verificar a assinatura para cada bloco de 4KB em tempo real. Se um atacante modificar um bloco bruto na memória flash, o kernel detecta a discrepância do hash e interrompe imediatamente a execução.
3. Isolamento Estrito
- O Mecanismo: Isto aplica as regras de isolamento de processos conforme descrito na seção Isolamento de Processos para criar um sandbox, com a APEX montada como uma partição dedicada sob
/apex. - Por que é mais seguro: Cada serviço recebe seu próprio usuário e diretório de dados, limitando o acesso a menos que seja explícito. Ao criar uma partição dedicada, o Android estabelece um namespace do linkador dedicado, garantindo que apenas bibliotecas explicitamente expostas sejam acessíveis para servidores de sistema não privilegiados, minimizando assim a superfície de ataque.
4. Recuperação Atômica
- O Mecanismo: A APEX usa um design "Ativo/Backup" para habilitar deslocamentos de buffer duplos. O APEX flashed na fábrica permanece na partição imutável
/system, enquanto atualizações residem na partição mutável/data. - Por que é mais seguro: Se uma atualização falhar ou parecer maliciosa, o daemon
apexdmarca-a como "falhada" durante a inicialização precoce. O sistema instantaneamente troca links simbólicos de volta para a partição/system. Esta recuperação atômica ajuda a garantir que o sistema não permaneça em um estado quebrado.
Resiliência: Desenvolvimento Seguro da Memória
A carga segura protege o sistema de modificações externas, mas a resiliência do plataforma também depende de como o código subjacente é construído. Para novos componentes desenvolvidos para AAOS SDV, priorizamos a segurança da memória.
Rust como linguagem primária
O AAOS SDV almeja sistemas pequenos com requisitos de disponibilidade rápida; isso impede a construção sobre o stack Android completo, 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 existente e adotamos Rust como linguagem primária. Também usamos Rust para desenvolver a lógica de negócios dos serviços, ajudando parceiros a escrever software seguro. Por design, Rust aproveita recursos de segurança da memória para prevenir classes comuns de vulnerabilidades de segurança da memória, enquanto suporta o throughput das equipes ao escrever código nativo.
Confiabilidade Distribuída: Controle de Rede e Acesso
Veículos definidos por software exigem interações seguras entre domínios isolados. A arquitetura de provisionamento em malha do AAOS SDV aborda essa complexidade criptograficamente verificando a versão e o autor de cada ponto final de comunicação.
Provisionamento de Dispositivo e Malha
A malha AAOS SDV estabelece a autenticação por meio do vinculação matemática da identidade de rede de cada componente ao seu estado de execução binária real. Este modelo substitui a confiança em software implícita por verificação baseada em hardware.
A autenticação na malha é projetada para ser contínua e criptográfica. Isso previne cenários onde, por exemplo, um serviço como uma gateway de veículo confia em uma VM de infotainment comprometida apenas porque ela tem o endereço IP correto.
A isolação e os protocolos de quarentena automatizados protegem a plataforma. Dispositivos pares dentro da malha SDV usam autenticação e atestado baseados em DICE, conforme detalhado na seção seguinte, para ajudar a identificar e conter a execução não autorizada de código ou a manipulação de configurações.
TLS baseado em DICE para proteger comunicações VM-a-VM
Baseando-se na Identidade do Host na Realidade
A Regra Dourada do DICE (Device Identifier Composition Engine): Se uma única linha de código no firmware mudar (mesmo uma atualização menor ou um ataque malicioso), o identificador composto derivado (CDI) muda totalmente, gerando uma chave Alias completamente diferente.
DICE e TLS (Transport Layer Security) se integram para resolver o desafio fundamental da arquitetura zero-trust: autenticar um dispositivo enquanto simultaneamente verifica a integridade do seu software.
A combinação de identificação baseada em hardware do DICE e na troca criptografada do TLS permite que uma máquina receptora verifique tanto a identidade da chamadora quanto o estado exato do seu software.
Certificados tradicionais provam apenas a posse de um segredo; eles não podem detectar manipulação de firmware. O DICE aborda isso por meio de camadas de boot medidas:
- A Chave Secreta Única do Dispositivo (UDS): Um segredo criptográfico aleatório gerado durante a fabricação. Apenas o carregador de inicialização de primeira etapa pode acessar a UDS; ela permanece inacessível para todo outro software e interfaces externas.
- Medidas Camadas (O Identificador Compósito do Dispositivo): O hardware ROM inicia a cadeia criptografando a UDS com o código exato e a configuração da próxima camada de firmware. Isso cria um CDI, que então se encadeia sequencialmente à medida que cada camada subsequente inicializa.
Controles de acesso rigorosos governam interações de serviço dentro da malha AAOS SDV. Assim como todo o software AAOS SDV, esses controles de acesso são autenticados e sua integridade é protegida no nível do dispositivo e entre dispositivos na malha através da autenticação baseada em DICE.
Controle de Acesso Camadas
O AAOS SDV emprega uma estratégia de defesa em profundidade para habilitar atualizações dinâmicas de veículo sem comprometer os mecanismos de acesso. Este modelo se baseia em duas camadas primárias de confiança:
- Permissões do nível de serviço: Definem os recursos específicos que um serviço em uma VM dada pode acessar ou expor na malha.
- Permissões do nível de VM: Definem as fronteiras de comunicação inter-VM para todos os serviços hospedados em uma determinada VM.
Este modelo permite que OEMs equilibrem segurança com atualizabilidade. Para serviços não sensíveis à segurança, políticas permissivas do nível de VM permitem a instalação via atualizações leves APEX ao invés de reimplantações completas da VM.
Por outro lado, as permissões para sinais sensíveis à segurança devem ser codificadas em cada VM. O trade-off é que introduzir um serviço sensível à segurança a uma nova VM requer atualizar o sistema de permissões do nível de VM globalmente. Isso exige uma atualização de todas as VMs dentro da malha.
Conclusão
O AAOS SDV estende a arquitetura de segurança do Android para atender às necessidades específicas dos veículos automotivos por meio de um enfoque
A plataforma integra ciclos de vida de segurança contínuos, que vão da gestão proativa de vulnerabilidades à verificação de identidade baseada em hardware via DICE. Essas defesas multi-níveis permitem que os fabricantes de equipamentos originais balanceiem a atualização de recursos avançados com a segurança robusta necessária para ambientes automotivos modernos. Especificações técnicas e detalhes de implementação estão disponíveis na página AAOS SDV Overview.