AAOS SDV - Secure by Design

In Google, crediamo che i nostri prodotti debbano essere sicuri fin dalla progettazione, motivo per cui abbiamo creato Android Automotive Operating System per Software Defined Vehicle (AAOS SDV) su piattaforme esistenti e collaudate sul mercato, sfruttando tecnologie di virtualizzazione come Cuttlefish. Mentre i nostri annunci di rilascio si sono concentrati sulle funzionalità, questo post del blog illustra alcuni dei concetti di sicurezza.

Base: isolamento del dominio

Virtualizzazione per isolare le istanze in co-hosting

L'attuale tendenza di consolidare le unità di controllo elettronico (ECU) in un unico chip riduce l'isolamento eseguendo più domini affiancati.

Sebbene le istanze SDV di AAOS forniscano meccanismi di isolamento interni, spesso è preferibile eseguire i domini logici in modo indipendente. Ad esempio, un quadro strumenti e un sistema di infotainment hanno requisiti diversi. Utilizziamo macchine virtuali per eseguire più istanze in parallelo, garantendo che la condivisione rimanga esplicita e che l'isolamento sia il comportamento predefinito.

Sicurezza Android ereditata

L'SDV AAOS si è evoluto da Microdroid, una versione Android minimalista ottimizzata per le macchine virtuali private (pVM). Questa derivazione fornisce agli ingegneri della piattaforma Android funzionalità di sicurezza consolidate che già conoscono.

Isolamento dei processi e rifiuto per impostazione predefinita

L'SDV AAOS segue il modello di isolamento basato sull'ID utente (UID) di Android per configurare una sandbox per ogni applicazione. Ogni servizio viene eseguito in un processo dedicato con un UID univoco per gestire i diritti di accesso, le directory di dati e altre limitazioni. Utilizziamo le funzionalità POSIX (Portable Operating System Interface) per limitare rigorosamente le operazioni e le abbiniamo a Security-Enhanced Linux (SELinux) per applicare una postura "deny-by-default". Questo approccio limita ogni servizio al minimo indispensabile, il che significa che le configurazioni mancanti bloccano l'accesso anziché creare un sistema eccessivamente permissivo. Applichiamo questa stessa strategia al nostro sistema di autorizzazioni per le comunicazioni, come spiegato più avanti in questo articolo.

Gestione di vulnerabilità comprovata

L'SDV AAOS integra l'infrastruttura di gestione delle vulnerabilità e di risposta alla sicurezza di Android per identificare, valutare, correggere e divulgare i risultati relativi alla sicurezza. Questo ciclo di vita incorpora la scansione automatizzata continua, i test di penetrazione approfonditi annuali e l'intelligence basata sui partner tramite il processo di segnalazione delle vulnerabilità di sicurezza di Android. Il team di sicurezza classifica le vulnerabilità scoperte, assegna valutazioni di gravità in base al rischio e monitora la correzione fino al completamento. Coordiniamo le norme di divulgazione e rilascio tramite i Bollettini sulla sicurezza di Android mensili, integrati da rigorosi controlli di sicurezza periodici e revisioni complete dell'architettura per garantire la resilienza della piattaforma a lungo termine.

Integrità: Proteggi la distribuzione del software

Oltre a garantire l'isolamento dei processi, una piattaforma sicura deve assicurare l'integrità del codice prima dell'esecuzione. Proteggiamo la distribuzione del software attraverso i seguenti approcci:

Distribuzione del software autenticata

AAOS SDV offre due metodi di installazione. Innanzitutto, installiamo il software direttamente su partizioni di sistema, prodotto o fornitore di sola lettura, che convalidano le firme a ogni avvio. In questo modo vengono protetti i componenti di base del sistema.

In secondo luogo, utilizziamo i pacchetti Android Pony EXpress (APEX) per i servizi. Ogni APEX incapsula il software e le relative dipendenze, trattando il pacchetto come una partizione con convalida della firma obbligatoria. In AAOS SDV, APEX tratta la firma del codice come un contratto continuo applicato dall'hardware. APEX garantisce la mitigazione dell'esecuzione di codice dannoso attraverso quattro pilastri fondamentali: 

1. Archiviazione immutabile

• Il meccanismo: il kernel Android esegue il loop del file apex_payload.img direttamente come dispositivo di archiviazione non elaborato utilizzando il loopback di sola lettura, montandolo con il flag rigoroso MS_RDONLY.
• Perché questo metodo è più sicuro: non espone alcun percorso di scrittura al sistema operativo perché i file non vengono scompattati nello spazio di archiviazione del veicolo. Anche se un malintenzionato ottiene i privilegi di root, non può modificare il codice APEX in esecuzione perché il livello del file system rifiuta tutti i comandi di scrittura.

2. Integrità crittografica

• Il meccanismo: la firma crittografica convalida un albero di Merkle dell'intera immagine del file system.
• Perché è più sicuro: il kernel utilizza dm-verity per blocco per verificare la firma di ogni data block da 4 KB in tempo reale. Se un malintenzionato modifica un blocco non elaborato nella memoria flash, il kernel rileva la mancata corrispondenza dell'hash e interrompe immediatamente l'esecuzione.

3. Isolamento rigoroso

• Il meccanismo: vengono applicate le regole di isolamento dei processi descritte nella sezione Isolamento dei processi per creare una sandbox, con l'APEX montato come partizione dedicata in /apex.
• Perché è più sicuro: ogni servizio riceve la propria directory di utenti e dati, limitando l'accesso a meno che la condivisione non sia esplicita. Creando una partizione dedicata, Android stabilisce uno spazio dei nomi del linker dedicato, garantendo che solo le librerie esposte esplicitamente siano accessibili dai daemon di sistema non privilegiati, riducendo così al minimo la superficie di attacco.

4. Ripristino atomico

• Il meccanismo: APEX utilizza un design "Attivo/Backup" per consentire i rollback con doppio buffer. L'APEX con flash di fabbrica rimane nella partizione /system immutabile, mentre gli aggiornamenti risiedono nella partizione /data mutabile.
• Perché è più sicuro: se un aggiornamento non va a buon fine o sembra dannoso, il daemon apexd lo contrassegna come "non riuscito" durante la fase iniziale di avvio. Il sistema scambia istantaneamente i link simbolici con la partizione /system. Questo ripristino atomico contribuisce a garantire che il sistema non rimanga in uno stato danneggiato.

Resilienza: sviluppo sicuro della memoria

Il caricamento verificato protegge il sistema da modifiche esterne, ma la resilienza della piattaforma dipende anche dal modo in cui è stato creato il codice sottostante. Per i nuovi componenti sviluppati per l'SDV AAOS, abbiamo dato la priorità alla sicurezza della memoria.

Rust come linguaggio principale

L'SDV AAOS è destinato a sistemi di piccole dimensioni con requisiti di disponibilità rapida. Ciò impedisce la creazione sullo stack Android completo, pertanto abbiamo limitato il nostro ambito al framework nativo. Per creare l'infrastruttura richiesta per un sistema distribuito, abbiamo sviluppato più componenti oltre all'infrastruttura esistente e abbiamo adottato Rust come linguaggio principale. Utilizziamo Rust anche per sviluppare la logica di business dei servizi, aiutando i partner a scrivere software sicuro. Per progettazione, Rust sfrutta le funzionalità di sicurezza della memoria per contribuire a prevenire le classi comuni di vulnerabilità della sicurezza della memoria, supportando al contempo la produttività del team durante la scrittura di codice nativo.

Distributed Trust: Network & Access Control

I veicoli software-defined richiedono interazioni sicure tra domini isolati. L'architettura di provisioning mesh SDV di AAOS affronta questa complessità verificando in modo crittografico la versione e l'autore di ogni endpoint di comunicazione.

Provisioning di dispositivi e mesh

La rete mesh SDV AAOS stabilisce l'autenticazione associando matematicamente l'identità di rete di ogni componente al suo stato di esecuzione binario effettivo. Questo modello sostituisce l'affidabilità implicita del software con la verifica basata sull'hardware.

L'autenticazione mesh è progettata per essere continua e crittografica. In questo modo si evitano scenari in cui, ad esempio, un servizio come un gateway del veicolo si fida di una VM di infotainment compromessa solo perché ha l'indirizzo IP corretto.

L'isolamento applicato dall'hardware e i protocolli di quarantena automatizzati proteggono la piattaforma. I dispositivi peer all'interno della mesh SDV utilizzano l'autenticazione e l'attestazione basate su DICE, come descritto nella sezione seguente, per identificare e contenere l'esecuzione di codice non autorizzato o la manomissione della configurazione.

TLS basato su DICE per proteggere la comunicazione tra VM

Radicare l'identità dell'host nella realtà

La regola d'oro di DICE (Device Identifier Composition Engine): se una singola riga di codice nel firmware cambia (anche un aggiornamento minore o un exploit dannoso), il Compound Device Identifier (CDI) derivato cambia completamente, generando una chiave alias completamente diversa.

DICE e TLS (Transport Layer Security) si integrano per risolvere la sfida fondamentale dell'architettura zero trust: l'autenticazione di una macchina e la verifica simultanea dell'integrità del suo software.

La combinazione dell'identificazione basata su hardware di DICE e dell'handshake crittografato di TLS consente a una macchina ricevente di verificare sia l'identità del chiamante sia lo stato esatto del software.

I certificati tradizionali dimostrano solo il possesso di un secret, ma non possono rilevare la manomissione del firmware. DICE risolve questo problema tramite la stratificazione dell'avvio con misurazioni:

• Unique Device Secret (UDS): un secret crittografico casuale generato durante la produzione. Solo il bootloader della prima fase può accedere all'UDS, che rimane inaccessibile a tutti gli altri software e alle interfacce esterne.
• Misurazioni a più livelli (Compound Device Identifier): la ROM hardware avvia la catena eseguendo l'hashing dell'UDS con il codice esatto e la configurazione del livello firmware successivo. In questo modo viene creata una CDI, che poi si concatena in sequenza man mano che viene avviato ogni livello successivo.

Controlli degli accessi rigorosi regolano le interazioni dei servizi all'interno del mesh SDV di AAOS. Come per tutto il software SDV AAOS, questi controlli degli accessi sono autenticati e la loro integrità è protetta a livello di dispositivo e tra i dispositivi della rete mesh tramite l'autenticazione basata su DICE.

Controllo degli accessi a più livelli

L'SDV AAOS utilizza una strategia di difesa in profondità per consentire aggiornamenti dinamici del veicolo senza compromettere i meccanismi di accesso. Questo modello si basa su due livelli di attendibilità principali:

1. Autorizzazioni a livello di servizio: definiscono le risorse specifiche a cui un servizio su una determinata VM può accedere o che può esporre nel mesh.
2. Autorizzazioni a livello di VM: definisci i confini della comunicazione tra VM per tutti i servizi ospitati su una VM specifica.

Questo modello consente agli OEM di bilanciare la sicurezza con l'aggiornabilità. Per i servizi non sensibili alla sicurezza, le policy permissive a livello di VM consentono l'installazione tramite aggiornamenti APEX leggeri anziché il deployment completo della VM.

Al contrario, le autorizzazioni per gli indicatori sensibili alla sicurezza devono essere hardcoded in ogni VM. Il compromesso è che l'introduzione di un servizio sensibile alla sicurezza in una nuova VM richiede l'aggiornamento delle autorizzazioni a livello di VM in tutto il sistema. Ciò richiede un aggiornamento di tutte le VM all'interno del mesh.

Conclusione

AAOS SDV estende l'architettura di sicurezza di Android per soddisfare requisiti specifici del settore automobilistico tramite un approccio secure-by-design. Sfruttando la virtualizzazione per l'isolamento dei domini e applicando policy di accesso "deny-by-default", la piattaforma crea un ambiente resiliente per i veicoli software-defined. L'integrità crittografica viene mantenuta tramite la verifica immediata del codice eseguito, applicata dall'hardware.

La piattaforma integra cicli di vita di sicurezza continui, che vanno dalla gestione proattiva delle vulnerabilità alla verifica dell'identità basata su hardware tramite DICE. Queste difese multilivello consentono agli OEM di bilanciare l'aggiornabilità delle funzionalità avanzate con la solida sicurezza necessaria per i moderni ambienti automobilistici. Le specifiche tecniche e i dettagli di implementazione sono disponibili nella pagina Panoramica di AAOS SDV.