AAOS SDV : sécurité dès la conception

Chez Google, nous pensons que nos produits doivent être sécurisés dès leur conception. C'est pourquoi nous avons créé le système d'exploitation Android Automotive pour les véhicules définis par logiciel (AAOS SDV) sur des plates-formes éprouvées sur le marché, en tirant parti des technologies de virtualisation telles que Cuttlefish. Bien que nos annonces de lancement aient été axées sur les fonctionnalités, cet article de blog présente certains concepts de sécurité.

Fondation : isolation des domaines

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

La tendance actuelle à consolider les unités de commande électronique (ECU) en 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 cluster et un système d'infodivertissement ont des exigences distinctes. Nous utilisons des machines virtuelles pour exécuter plusieurs instances en parallèle, en veillant à ce que le partage reste explicite et que l'isolation soit le comportement par défaut.

Sécurité Android héritée

AAOS SDV est issu de Microdroid, une version Android minimaliste optimisée pour les machines virtuelles de confidentialité (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

AAOS SDV 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 de l'interface de système d'exploitation portable (POSIX) pour limiter strictement les opérations et les associer à Security-Enhanced Linux (SELinux) afin d'appliquer une posture de "refus par défaut". Cette approche limite chaque service au minimum absolu requis, ce qui signifie que les configurations manquantes bloquent l'accès au lieu de créer un système trop permissif. Nous appliquons la même stratégie à notre système d'autorisation de communication, comme expliqué plus loin dans cet article.

Gestion des failles éprouvée

AAOS SDV intègre l'infrastructure de gestion des failles et de réponse à la sécurité mature d'Android pour identifier, trier, corriger et divulguer les résultats de sécurité. Ce cycle de vie comprend une analyse automatisée continue, des tests d'intrusion approfondis annuels et des renseignements basés sur 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 des risques et suit la correction jusqu'à la fin. Nous coordonnons les politiques de divulgation et de publication via les bulletins de sécurité Android mensuels, complétés par des audits de sécurité périodiques rigoureux et des examens architecturaux complets pour garantir la résilience à long terme de la plate-forme.

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

Au-delà de la garantie de 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 le logiciel directement sur des partitions système, produit ou fournisseur en lecture seule, qui valident les signatures à chaque démarrage. Cela sécurise les composants système de base.

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 de signature obligatoire. Dans AAOS SDV, APEX traite la signature de code comme un contrat continu appliqué par le matériel. APEX garantit l'atténuation de l'exécution de code malveillant grâce à quatre piliers principaux :

1. Stockage immuable

• Le mécanisme : le noyau Android boucle directement le fichier apex_payload.img en tant que périphérique de stockage brut à l'aide du rebouclage en lecture seule, en le montant avec l'indicateur strict MS_RDONLY.
• Pourquoi est-ce plus sécurisé ? Cela n'expose aucun chemin d'écriture au système d'exploitation, car les fichiers ne sont pas décompressés sur le stockage du véhicule. Même si un pirate informatique obtient des droits 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

• Le 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 noyau détecte l'incompatibilité de hachage et arrête immédiatement l'exécution.

3. Isolation stricte

• Le mécanisme : cela applique les règles d'isolation des processus décrites dans la section Isolation des processus pour créer un bac à sable, avec l'APEX monté 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 de l'éditeur de liens dédié, ce qui garantit que seules les bibliothèques explicitement exposées sont accessibles à partir des daemons système non privilégiés, ce qui minimise la surface d'attaque.

4. Récupération atomique

• Le mécanisme : APEX utilise une conception "Active/Backup" pour activer les restaurations à double tampon. L'APEX flashé en usine reste sur la partition /system immuable, tandis que les mises à jour résident sur la partition /data mutable.
• Pourquoi est-ce plus sécurisé ? Si une mise à jour échoue ou semble malveillante, le daemon apexd la marque comme "échec" au début du démarrage. Le système rétablit instantanément les liens symboliques vers 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é en mémoire

Le chargement vérifié 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 créé. Pour les nouveaux composants développés pour AAOS SDV, nous avons privilégié la sécurité de la mémoire.

Rust comme langage principal

AAOS SDV cible les petits systèmes avec des exigences de disponibilité rapides. Cela empêche la création sur la pile Android complète. 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 des fonctionnalités de sécurité de la mémoire pour éviter les classes courantes de failles de sécurité de la mémoire, tout en prenant en charge 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 de maillage AAOS SDV 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 le matériel.

L'authentification du réseau maillé 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 appliquée par le matériel 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 décrit dans la section suivante, pour identifier et contenir l'exécution de code non autorisée ou la falsification de configuration.

TLS basé sur DICE pour sécuriser la communication entre les 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 une exploitation malveillante), l'identifiant d'appareil composé (CDI) dérivé change complètement, générant 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 de l'établissement de liaison 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 une couche de démarrage mesurée :

• Le secret d'appareil unique (UDS) : secret cryptographique aléatoire généré lors de la fabrication. Seul le bootloader de première étape peut accéder à l'UDS. Il reste inaccessible à tous les autres logiciels et interfaces externes.
• Mesures en couches (identifiant d'appareil composé) : 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 est ensuite enchaîné de manière séquentielle à chaque démarrage de couche suivante.

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

Contrôle d'accès en couches

AAOS SDV utilise une stratégie de défense en profondeur pour activer les mises à jour dynamiques des véhicules 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éfinissent les ressources spécifiques auxquelles un service sur une VM donnée peut accéder ou exposer sur le maillage.
2. Autorisations au niveau de la VM : définissent 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 d'équilibrer la sécurité et la capacité de mise à jour. Pour les services non sensibles à la sécurité, les stratégies 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 VM.

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

Conclusion

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 tirant parti de la virtualisation pour l'isolation des domaines et en appliquant des stratégies d'accès "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 à une 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 vérification d'identité basée sur le matériel via DICE. Ces défenses multicouches permettent aux OEM d'équilibrer la capacité de mise à jour des fonctionnalités avancées avec la sécurité robuste nécessaire aux environnements automobiles modernes. Les spécifications techniques et les détails d'implémentation sont disponibles sur la page de présentation d'AAOS SDV.