AAOS SDV - Secure by Design

In Google riteniamo che i nostri prodotti debbano essere sicuri per progettazione, motivo per cui abbiamo creato il sistema operativo Android Automotive per Software Defined Vehicle (AAOS SDV) su piattaforme esistenti e collaudate sul mercato, sfruttando tecnologie di virtualizzazione come Cuttlefish. Mentre i nostri annunci delle release si concentrano sulle funzionalità, questo post del blog illustra alcuni dei concetti di sicurezza.

Base: isolamento del dominio

Virtualizzazione per isolare le istanze co-ospitate

L'attuale tendenza a consolidare le centraline elettroniche (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, garantendo che la condivisione rimanga esplicita e che l'isolamento sia il comportamento predefinito.

Sicurezza Android ereditata

AAOS SDV si è evoluto da Microdroid, una versione minimalista di Android ottimizzata per le macchine virtuali private (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 di dati e altre limitazioni. Utilizziamo le funzionalità di Portable Operating System Interface (POSIX) per limitare rigorosamente le operazioni e le combiniamo con Security-Enhanced Linux (SELinux) per applicare una postura "deny-by-default". 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 comprovata delle vulnerabilità

AAOS SDV integra l'infrastruttura di gestione delle vulnerabilità e risposta alla sicurezza consolidata di Android per identificare, assegnare priorità, correggere e divulgare i risultati di sicurezza. Questo ciclo di vita incorpora la scansione automatizzata continua, test di penetrazione approfonditi annuali e l'intelligence basata sui partner tramite la procedura di segnalazione delle vulnerabilità di sicurezza di Android. Il team di sicurezza esamina le vulnerabilità rilevate, assegna valutazioni di gravità in base al rischio e monitora la correzione fino al completamento. Coordinare le norme di divulgazione e rilascio tramite i bollettini di sicurezza Android mensili, integrati da rigorosi audit di sicurezza periodici e revisioni architetturali complete per garantire la resilienza a lungo termine della piattaforma.

Integrità: distribuzione del software sicura

Oltre a garantire l'isolamento dei processi, una piattaforma sicura deve garantire l'integrità del codice prima dell'esecuzione. Proteggiamo la distribuzione del software con 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 a livello hardware. APEX garantisce la mitigazione dell'esecuzione di codice dannoso attraverso quattro pilastri fondamentali: 

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:non espone alcun percorso di scrittura al sistema operativo perché i file non vengono decompressi 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 Merkle dell'intera immagine di sistema del file system.
• Perché è più sicuro:il kernel utilizza dm-verity per blocco per verificare la firma di ogni blocco di dati da 4 KB al volo. 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: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 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 in modo esplicito siano accessibili dai daemon di sistema non privilegiati, riducendo così la superficie di attacco.

4. Atomic Recovery

• Il meccanismo:APEX utilizza un design "attivo/di backup" per consentire i rollback a doppio buffer. L'APEX flashato in fabbrica rimane nella partizione /system immutabile, mentre gli aggiornamenti risiedono nella partizione /data modificabile.
• 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 immediatamente i link simbolici con la partizione /system. Questo recupero 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 da come viene creato il codice sottostante. Per i nuovi componenti sviluppati per AAOS SDV, abbiamo dato la priorità alla sicurezza della memoria.

Rust come lingua principale

AAOS SDV ha come target sistemi di piccole dimensioni con requisiti di disponibilità rapidi; ciò impedisce la creazione sull'intero stack Android, 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 sicuri. Per progettazione, Rust sfrutta funzionalità di sicurezza della memoria per contribuire a prevenire classi comuni di vulnerabilità di sicurezza della memoria, supportando al contempo il throughput 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 risolve questa complessità verificando crittograficamente la versione e l'autore di ogni endpoint di comunicazione.

Provisioning di dispositivo e mesh

La mesh SDV di AAOS stabilisce l'autenticazione collegando matematicamente l'identità di rete di ogni componente al suo stato di esecuzione binaria effettivo. Questo modello sostituisce l'attendibilità 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 considera attendibile una VM di infotainment compromessa solo perché ha l'indirizzo IP corretto.

L'isolamento applicato a livello 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 contribuire a identificare e contenere l'esecuzione di codice o la manomissione della configurazione non autorizzate.

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 composto del dispositivo (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 contemporaneamente 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 il suo stato software esatto.

I certificati tradizionali dimostrano solo il possesso di un segreto, 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 di prima fase può accedere all'UDS, che rimane inaccessibile a tutti gli altri software e interfacce esterne.
• Misurazioni a più 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 firmware successivo. Viene creato un CDI, che viene concatenato in sequenza all'avvio di ogni livello successivo.

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

Controllo degli accessi a più livelli

AAOS SDV 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 fiducia principali:

1. Autorizzazioni a livello di servizio:definiscono le risorse specifiche a cui un servizio su una determinata VM può accedere o esporre nel mesh.
2. Autorizzazioni a livello di VM: definisci 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é tramite il redeploy completo delle VM.

Al contrario, le autorizzazioni per gli indicatori 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 requisiti specifici del settore automobilistico tramite un approccio di sicurezza by design. Sfruttando la virtualizzazione per l'isolamento dei domini e applicando criteri di accesso "deny-by-default", la piattaforma crea un ambiente resiliente per i veicoli software-defined. L'integrità crittografica viene mantenuta tramite la verifica al volo del codice eseguito, applicata a livello hardware.

La piattaforma integra cicli di vita della sicurezza continui, che vanno 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 solida sicurezza necessaria per gli ambienti automobilistici moderni. Le specifiche tecniche e i dettagli di implementazione sono disponibili nella pagina Panoramica di AAOS SDV.