AAOS SDV - Sicurezza "by design"

In Google, riteniamo che i nostri prodotti debbano essere sicuri "by design", motivo per cui abbiamo creato il sistema operativo Android Automotive per veicoli software-defined (AAOS SDV) su piattaforme esistenti e collaudate sul mercato, sfruttando tecnologie di virtualizzazione come Cuttlefish. Sebbene i nostri annunci di release si siano concentrati sulle funzionalità, questo post del blog illustra alcuni dei concetti di sicurezza.

Fondamenta: isolamento dei domini

Virtualizzazione per isolare le istanze co-hosted

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

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

Sicurezza Android ereditata

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

Isolamento dei processi e rifiuto per impostazione predefinita

AAOS SDV 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 dei dati e altre limitazioni. Utilizziamo le funzionalità dell'interfaccia del sistema operativo portatile (POSIX) per limitare rigorosamente le operazioni e le abbiniamo a Security-Enhanced Linux (SELinux) per applicare una postura di "rifiuto per impostazione predefinita". Questo approccio limita ogni servizio al minimo assoluto richiesto, il che significa che le configurazioni mancanti bloccano l'accesso anziché creare un sistema eccessivamente permissivo. Applichiamo la stessa strategia al nostro sistema di autorizzazioni di comunicazione, come spiegato più avanti in questo articolo.

Gestione delle vulnerabilità collaudata

AAOS SDV integra l'infrastruttura di gestione delle vulnerabilità e di risposta alla sicurezza matura di Android per identificare, classificare, correggere e divulgare i risultati di sicurezza. Questo ciclo di vita include la scansione automatica 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à rilevate, assegna valutazioni di gravità in base al rischio e monitora la correzione fino al completamento. Coordinamo le norme di divulgazione e rilascio tramite i bollettini sulla sicurezza di Android mensili, integrati da rigorosi audit di sicurezza periodici e revisioni complete dell'architettura per garantire la resilienza a lungo termine della piattaforma.

Integrità: distribuzione del software in modo sicuro

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

Distribuzione del software autenticata

AAOS SDV fornisce due metodi di installazione. Innanzitutto, installiamo il software direttamente nelle 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 considera la firma del codice come un contratto continuo e applicato dall'hardware. APEX garantisce che l'esecuzione di codice dannoso venga mitigata tramite quattro pilastri principali: 

1. Archiviazione non modificabile

• 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 MS_RDONLY rigoroso.
• Perché è più sicuro: in questo modo non viene esposto alcun percorso di scrittura al sistema operativo perché i file non vengono decompressi nella memoria del veicolo. Anche se un utente 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 per ogni blocco di dati di 4 KB al volo. Se un utente 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: applica le regole di isolamento dei processi descritte nella sezione Isolamento dei processi per creare una sandbox, con APEX montato come partizione dedicata in /apex.
• Perché è più sicuro: ogni servizio riceve la propria directory utente e directory di 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, assicurando che solo le librerie esposte in modo esplicito siano accessibili dai daemon di sistema senza privilegi, riducendo al minimo la superficie di attacco.

4. Ripristino atomico

• Il meccanismo: APEX utilizza una progettazione "Attivo/Backup" per abilitare i rollback con doppio buffer. L'APEX flashato in fabbrica rimane nella partizione /system non modificabile, mentre gli aggiornamenti risiedono nella partizione /data modificabile.
• Perché è più sicuro: se un aggiornamento non riesce o sembra dannoso, il daemon apexd lo contrassegna come "non riuscito" durante la fase iniziale di avvio. Il sistema scambia immediatamente 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 per la memoria

Il caricamento verificato protegge il sistema da modifiche esterne, ma la resilienza della piattaforma dipende anche dalla modalità di creazione del codice sottostante. Per i nuovi componenti sviluppati per AAOS SDV, abbiamo dato la priorità alla sicurezza della memoria.

Rust come lingua principale

AAOS SDV è destinato a sistemi di piccole dimensioni con requisiti di disponibilità rapidi; ciò impedisce la creazione sull'intero stack Android, quindi 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 lingua principale. Utilizziamo Rust anche per sviluppare la logica di business dei servizi, aiutando i partner a scrivere software sicuri. Per progettazione, Rust sfrutta le funzionalità di sicurezza della memoria per aiutare a prevenire le classi comuni di vulnerabilità di sicurezza della memoria, supportando al contempo la produttività del team durante la scrittura di codice nativo.

Attendibilità distribuita: controllo dell'accesso e della rete

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

Provisioning di dispositivi e mesh

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

L'autenticazione della 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 da VM a VM

Basare l'identità dell'host sulla 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), l'identificatore del dispositivo composto (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: autenticare una macchina verificando al contempo l'integrità del software.

La combinazione dell'identificazione basata sull'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 segreto; non possono rilevare la manomissione del firmware. DICE risolve questo problema tramite la stratificazione dell'avvio misurato:

• Il segreto del dispositivo univoco (UDS): un segreto crittografico casuale generato durante la produzione. Solo il bootloader di primo livello può accedere all'UDS; rimane inaccessibile a tutti gli altri software e interfacce esterne.
• Misure a livelli (l'identificatore del dispositivo composto): la ROM hardware avvia la catena eseguendo l'hashing dell'UDS con il codice esatto e la configurazione del livello del firmware successivo. Viene creato un CDI, che viene concatenato in sequenza all'avvio di ogni livello successivo.

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

Controllo degli accessi a livelli

AAOS SDV utilizza una strategia di difesa in profondità per consentire gli aggiornamenti dinamici dei veicoli 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 esporre nella mesh.
2. Autorizzazioni a livello di VM: definiscono i limiti di 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é ridistribuzioni complete delle VM.

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

Conclusione

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

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