AAOS SDV : conception sécurisée

Chez Google, nous pensons que nos produits doivent être sécurisés dès leur conception. C'est pourquoi nous avons développé Android Automotive Operating System for Software Defined Vehicle (AAOS SDV) sur des plates-formes existantes et éprouvées, en exploitant des technologies de virtualisation telles que Cuttlefish. Alors que nos annonces de lancement se concentraient sur les fonctionnalités, cet article de blog décrit certains des concepts de sécurité.

Base : isolation de domaine

Virtualisation pour isoler les instances co-hébergées

La tendance actuelle consistant à regrouper les unités de contrôle électronique (ECU) sur une seule puce réduit l'isolation en exécutant plusieurs domaines côte à côte.

Bien que les instances AAOS SDV fournissent des mécanismes d'isolation internes, il est souvent préférable d'exécuter les domaines logiques de manière indépendante. Par exemple, un tableau de bord et un système d'infodivertissement ont des exigences différentes. Nous utilisons des machines virtuelles pour exécuter plusieurs instances en parallèle, ce qui garantit que le partage reste explicite et que l'isolation est le comportement par défaut.

Sécurité Android héritée

AAOS SDV est une évolution de Microdroid, une version minimaliste d'Android optimisée pour les machines virtuelles privées (pVM). Cette lignée fournit aux ingénieurs de la plate-forme Android des fonctionnalités de sécurité établies qu'ils connaissent déjà.

Isolation des processus et refus par défaut

Le SDV AAOS suit le modèle d'isolation basé sur l'ID utilisateur (UID) d'Android pour configurer un bac à sable pour chaque application. Chaque service s'exécute dans un processus dédié avec un UID unique pour gérer les droits d'accès, les répertoires de données et d'autres restrictions. Nous utilisons les fonctionnalités POSIX (Portable Operating System Interface) pour limiter strictement les opérations, et nous les associons à SELinux (Security-Enhanced Linux) pour appliquer une stratégie de refus par défaut. Cette approche limite chaque service au strict minimum requis, ce qui signifie que les configurations manquantes bloquent l'accès au lieu de créer un système trop permissif. Nous appliquons cette même stratégie à notre système d'autorisation de communication, comme expliqué plus loin dans cet article.

Gestion des failles éprouvée

L'AAOS SDV intègre l'infrastructure mature de gestion des failles et de réponse de sécurité d'Android pour identifier, trier, corriger et divulguer les résultats de sécurité. Ce cycle de vie intègre une analyse automatisée continue, des tests d'intrusion approfondis annuels et des renseignements fournis par les partenaires via le processus de signalement des failles de sécurité Android. L'équipe de sécurité trie les failles découvertes, attribue des niveaux de gravité en fonction du risque et suit la correction jusqu'à son terme. Nous coordonnons les règles de divulgation et de publication par le biais des bulletins mensuels sur la sécurité d'Android, complétés par des audits de sécurité périodiques rigoureux et des examens complets de l'architecture pour garantir la résilience à long terme de la plate-forme.

Intégrité : livraison sécurisée de logiciels

En plus de garantir l'isolation des processus, une plate-forme sécurisée doit assurer l'intégrité du code avant son exécution. Nous sécurisons la livraison de logiciels grâce aux approches suivantes :

Livraison de logiciels authentifiée

AAOS SDV propose deux méthodes d'installation. Tout d'abord, nous installons les logiciels directement sur des partitions système, produit ou fournisseur en lecture seule, qui valident les signatures à chaque démarrage. Cela permet de sécuriser les composants de base du système.

Ensuite, nous utilisons des packages Android Pony EXpress (APEX) pour les services. Chaque APEX encapsule le logiciel et ses dépendances, en traitant le package comme une partition avec validation obligatoire de la signature. Dans AAOS SDV, APEX traite la signature de code comme un contrat continu appliqué par le matériel. APEX permet de limiter l'exécution de code malveillant grâce à quatre piliers fondamentaux : 

1. Stockage immuable

• Mécanisme : le noyau Android boucle directement le fichier apex_payload.img en tant que périphérique de stockage brut à l'aide du loopback en lecture seule, en l'installant avec l'indicateur strict MS_RDONLY.
• Pourquoi cette méthode est-elle plus sécurisée ? Elle n'expose aucun chemin d'écriture à l'OS, car les fichiers ne sont pas décompressés dans l'espace de stockage du véhicule. Même si un pirate informatique obtient des droits d'accès racine, il ne peut pas modifier le code APEX en cours d'exécution, car la couche du système de fichiers rejette toutes les commandes d'écriture.

2. Intégrité cryptographique

• Mécanisme : la signature cryptographique valide un arbre de Merkle de l'image complète du système de fichiers.
• Pourquoi est-ce plus sécurisé ? Le noyau utilise dm-verity par bloc pour vérifier la signature de chaque bloc de données de 4 Ko à la volée. Si un pirate informatique modifie un bloc brut sur la mémoire flash, le kernel détecte l'incohérence de hachage et interrompt immédiatement l'exécution.

3. Isolation stricte

• Le mécanisme : les règles d'isolation des processus sont appliquées comme décrit dans la section "Isolation des processus" pour créer un bac à sable, avec l'APEX installé en tant que partition dédiée sous /apex.
• Pourquoi est-ce plus sécurisé ? Chaque service reçoit son propre répertoire d'utilisateurs et de données, ce qui limite l'accès, sauf si le partage est explicite. En créant une partition dédiée, Android établit un espace de noms d'éditeur de liens dédié, ce qui garantit que seules les bibliothèques explicitement exposées sont accessibles à partir des démons système non privilégiés, minimisant ainsi la surface d'attaque.

4. Récupération atomique

• Mécanisme : APEX utilise une conception "Active/Backup" pour permettre des rollbacks à double tampon. L'APEX flashé en usine reste sur la partition /system immuable, tandis que les mises à jour résident sur la partition /data modifiable.
• Pourquoi est-ce plus sécurisé ? Si une mise à jour échoue ou semble malveillante, le daemon apexd la marque comme "échouée" au début du démarrage. Le système remplace instantanément les liens symboliques par la partition /system. Cette récupération atomique permet de s'assurer que le système ne reste pas dans un état défectueux.

Résilience : développement sécurisé de la mémoire

Le chargement validé protège le système contre les modifications externes, mais la résilience de la plate-forme dépend également de la façon dont le code sous-jacent est conçu. Pour les nouveaux composants développés pour AAOS SDV, nous avons donné la priorité à la sécurité de la mémoire.

Rust comme langage principal

AAOS SDV cible les petits systèmes avec des exigences de disponibilité rapide. Cela empêche la compilation sur l'intégralité de la pile Android. Nous avons donc limité notre champ d'application au framework natif. Pour créer l'infrastructure requise pour un système distribué, nous avons développé plusieurs composants en plus de l'infrastructure existante et adopté Rust comme langage principal. Nous utilisons également Rust pour développer la logique métier des services, ce qui aide les partenaires à écrire des logiciels sécurisés. Par conception, Rust exploite les fonctionnalités de sécurité de la mémoire pour aider à prévenir les classes courantes de failles de sécurité de la mémoire, tout en favorisant le débit de l'équipe lors de l'écriture de code natif.

Confiance distribuée : contrôle du réseau et des accès

Les véhicules définis par logiciel nécessitent des interactions sécurisées entre des domaines isolés. L'architecture de provisionnement du maillage SDV d'AAOS résout cette complexité en vérifiant de manière cryptographique la version et l'auteur de chaque point de terminaison de communication.

Provisionnement des appareils et du réseau maillé

Le maillage AAOS SDV établit l'authentification en liant mathématiquement l'identité réseau de chaque composant à son état d'exécution binaire réel. Ce modèle remplace la confiance logicielle implicite par une vérification basée sur une racine de confiance matérielle.

L'authentification du maillage est conçue pour être continue et cryptographique. Cela évite les scénarios dans lesquels, par exemple, un service tel qu'une passerelle de véhicule fait confiance à une VM d'infodivertissement compromise simplement parce qu'elle possède la bonne adresse IP.

L'isolation matérielle et les protocoles de mise en quarantaine automatisés sécurisent la plate-forme. Les appareils pairs du maillage SDV utilisent l'authentification et l'attestation basées sur DICE, comme indiqué dans la section suivante, pour identifier et contenir l'exécution de code non autorisée ou la falsification de la configuration.

TLS basé sur DICE pour sécuriser les communications entre VM

Ancrer l'identité de l'hôte dans la réalité

La règle d'or de DICE (Device Identifier Composition Engine) : si une seule ligne de code du micrologiciel change (même une mise à jour mineure ou un exploit malveillant), l'identifiant d'appareil composite (CDI) dérivé change entièrement, ce qui génère une clé d'alias complètement différente.

DICE et TLS (Transport Layer Security) s'intègrent pour résoudre le défi fondamental de l'architecture zéro confiance : authentifier une machine tout en vérifiant l'intégrité de son logiciel.

La combinaison de l'identification intégrée au matériel de DICE et du handshake chiffré de TLS permet à une machine réceptrice de vérifier à la fois l'identité de l'appelant et l'état exact de son logiciel.

Les certificats traditionnels ne prouvent que la possession d'un secret. Ils ne peuvent pas détecter la falsification du micrologiciel. DICE résout ce problème via la superposition de démarrage mesuré :

• Le secret d'appareil unique (UDS) : un secret cryptographique aléatoire généré lors de la fabrication. Seul le bootloader de premier niveau peut accéder à l'UDS. Il reste inaccessible à tous les autres logiciels et interfaces externes.
• Mesures multicouches (identifiant d'appareil composite) : la ROM matérielle lance la chaîne en hachant l'UDS avec le code exact et la configuration de la couche de micrologiciel suivante. Cela crée un CDI, qui s'enchaîne ensuite de manière séquentielle au démarrage de chaque couche suivante.

Des contrôles d'accès stricts régissent les interactions entre les services au sein du maillage SDV AAOS. Comme tous les logiciels SDV AAOS, ces contrôles d'accès sont authentifiés, et leur intégrité est protégée au niveau de l'appareil et entre les appareils du réseau maillé grâce à l'authentification basée sur DICE.

Contrôle des accès par couches

Le SDV AAOS utilise une stratégie de défense en profondeur pour permettre des mises à jour dynamiques du véhicule sans compromettre les mécanismes d'accès. Ce modèle repose sur deux couches de confiance principales :

1. Autorisations au niveau du service : définissez les ressources spécifiques auxquelles un service sur une VM donnée peut accéder ou qu'il peut exposer sur le maillage.
2. Autorisations au niveau de la VM : définissez les limites de communication entre les VM pour tous les services hébergés sur une VM spécifique.

Ce modèle permet aux OEM de trouver un équilibre entre sécurité et facilité de mise à jour. Pour les services non sensibles, des règles permissives au niveau de la VM permettent l'installation via des mises à jour APEX légères plutôt que des redéploiements complets de la VM.

À l'inverse, les autorisations pour les signaux sensibles à la sécurité doivent être codées en dur dans chaque VM. En revanche, l'introduction d'un service sensible à la sécurité sur une nouvelle VM nécessite de mettre à jour les autorisations au niveau de la VM à l'échelle du système. Cela nécessite une mise à jour de toutes les VM du maillage.

Conclusion

L'AAOS SDV étend l'architecture de sécurité d'Android pour répondre aux exigences spécifiques de l'automobile grâce à une approche sécurisée dès la conception. En exploitant la virtualisation pour l'isolation des domaines et en appliquant des règles d'accès de type "refus par défaut", la plate-forme établit un environnement résilient pour les véhicules définis par logiciel. L'intégrité cryptographique est maintenue grâce à la vérification à la volée du code exécuté, appliquée par le matériel.

La plate-forme intègre des cycles de vie de sécurité continus, allant de la gestion proactive des failles à la validation de l'identité basée sur le matériel via DICE. Ces défenses multicouches permettent aux OEM de trouver un équilibre entre la facilité de mise à jour des fonctionnalités avancées et la sécurité robuste nécessaire aux environnements automobiles modernes. Les caractéristiques techniques et les détails de l'implémentation sont disponibles sur la page de présentation d'AAOS SDV.