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 créé Android Automotive Operating System for Software Defined Vehicle (AAOS SDV) sur des plates-formes éprouvées sur le marché, en tirant parti des technologies de virtualisation comme Cuttlefish. Alors que nos annonces de version se concentraient sur les fonctionnalités, cet article de blog présente certains concepts de sécurité.

Base : isolation de domaine

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

La tendance actuelle à regrouper les unités de contrôle électronique (ECU) en un seul chip 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 interne, 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'info-divertissement ont des exigences distinctes. 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 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 stratégie de refus par défaut. Cette approche limite chaque service au strict minimum requis. Cela 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 éprouvée des failles

AAOS SDV intègre l'infrastructure mature de gestion des failles et de réponse aux problèmes de sécurité d'Android pour identifier, trier, corriger et divulguer les problèmes de sécurité. Ce cycle de vie comprend 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étectées, attribue des niveaux de gravité en fonction des risques et suit les corrections jusqu'à leur achèvement. 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 architecturaux complets pour assurer 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 l'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 les 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.

Deuxièmement, nous utilisons des packages Android Pony EXpress (APEX) pour les services. Chaque APEX encapsule un 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 d'atténuer l'exécution de code malveillant grâce à quatre piliers fondamentaux : 

1. Stockage immuable

• Mécanisme : le noyau Android boucle le fichier apex_payload.img directement 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é ? Aucun chemin d'écriture n'est exposé à l'OS, 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

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

3. Isolation stricte

• Mécanisme : il 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 d'é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

• Mécanisme : APEX utilise une conception "Active/Backup" pour permettre les 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 mutable.
• Pourquoi est-ce plus sécurisé ? Si une mise à jour échoue ou semble malveillante, le daemon apexd la marque comme "échec" lors du démarrage anticipé. 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é 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 privilégié la sécurité de la mémoire.

Rust comme langue principale

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 portée 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 avons 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 aider à prévenir les classes courantes de failles de sécurité de la mémoire, tout en favorisant le débit des équipes lors de l'écriture de code natif.

Confiance distribuée : contrôle de l'accès et du réseau

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 SDV AAOS répond à 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 validation ancrée dans le matériel.

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

L'isolation renforcé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 indiqué dans la section suivante, pour identifier et contenir l'exécution de code non autorisé 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é

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, ce qui génère une clé d'alias totalement 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.

L'association 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 grâce à la couche de démarrage mesurée :

• Secret unique de l'appareil (UDS) : secret cryptographique aléatoire généré lors de la fabrication. Seul le bootloader de première phase peut accéder à l'UDS. Il reste inaccessible à tous les autres logiciels et interfaces externes.
• Mesures par 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 à mesure que chaque couche suivante démarre.

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 les appareils du réseau maillé grâce à l'authentification basée sur DICE.

Contrôle des accès par couches

AAOS SDV emploie 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 principaux niveaux de confiance :

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 dans 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 d'équilibrer la sécurité et la mise à jour. Pour les services non sensibles à la sécurité, les 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 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 à l'échelle 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 automobiles spécifiques 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 règles d'accès "refuser 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 validation à 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 de l'identité ancrée dans le matériel via DICE. Ces défenses multicouches permettent aux OEM d'équilibrer la mise à jour des fonctionnalités avancées avec la sécurité robuste nécessaire aux environnements automobiles modernes. Les spécifications techniques et les informations sur l'implémentation sont disponibles sur la page Présentation de l'AAOS SDV.