A volte cerco un argomento su cui scrivere e mi rendo conto che ce n'è uno che presumo di aver trattato, ma, cercandolo, scopro che non l'ho fatto. Uno di questi argomenti è l'avvio misurato e l'avvio affidabile, a volte indicato in modo fuorviante come "avvio sicuro". Esistono procedure specifiche che utilizzano questi termini con lettere maiuscole (ad es. Avvio protetto), che cercherò di evitare di discutere in questo articolo. Sono più interessato ai processi generici - e a una grave potenziale caduta - che a cercare di entrare nei dettagli delle specifiche. Quello che segue è un estratto (molto modificato) dal mio prossimo libro sulla fiducia nell'informatica e nel cloud per Wiley.
Più risorse Linux
- Comandi Linux cheat sheet
- Cheat sheet sui comandi avanzati di Linux
- Corso online gratuito:Panoramica tecnica RHEL
- Cheat sheet della rete Linux
- Cheat sheet di SELinux
- Cheat sheet dei comandi comuni di Linux
- Cosa sono i container Linux?
- I nostri ultimi articoli su Linux
Per capire quale obiettivo di avvio misurato e avvio attendibile ottenere, guarda lo stack di virtualizzazione di Linux:i componenti che esegui se desideri utilizzare macchine virtuali (VM) su una macchina Linux. Questa descrizione è probabilmente eccessivamente semplificata, ma (come ho notato sopra) non sono interessato alle specifiche ma a ciò che sto cercando di ottenere. Mi concentrerò sui quattro livelli inferiori (a un livello di astrazione piuttosto semplice):CPU/motore di gestione; BIOS/EFI; firmware; e hypervisor, ma considererò anche un livello solo sopra la CPU/motore di gestione, che interpone un Trusted Platform Module (TPM) e alcune istruzioni su come eseguire uno dei due processi (avvio misurato e avvio affidabile ). Una volta che il sistema inizia ad avviarsi, il TPM viene attivato e inizia il suo lavoro. Potrebbero essere utilizzate anche radici di fiducia alternative, come i moduli di sicurezza hardware (HSM), ma nel mio esempio userò i TPM, l'esempio più comune in questo contesto.
In entrambi i casi (avvio affidabile e avvio misurato), il flusso di base inizia con il TPM che esegue una misurazione del livello BIOS/EFI. Questa misurazione comporta il controllo delle istruzioni binarie che devono essere eseguite da questo livello e la creazione di un hash crittografico dell'immagine binaria. L'hash prodotto viene quindi archiviato in uno dei numerosi "slot" del registro di configurazione della piattaforma (PCR) nel TPM. Questi possono essere pensati come pezzi di memoria che possono essere letti in seguito, o dal TPM per i suoi scopi o da entità esterne al TPM, ma che non possono essere modificati una volta che sono stati scritti. Questi pezzi di memoria sono protetti dall'integrità dal momento della loro scrittura iniziale. Ciò garantisce che una volta che un valore viene scritto in una PCR dal TPM, può essere considerato costante per tutta la durata del sistema fino allo spegnimento o al riavvio.
Dopo aver misurato il livello BIOS/EFI, viene misurato il livello successivo (firmware). In questo caso, l'hash risultante viene combinato con l'hash precedente (che era memorizzato nello slot PCR) e quindi anche archiviato in uno slot PCR. Il processo continua fino a quando tutti i livelli coinvolti nel processo non sono stati misurati e i risultati degli hash non sono stati archiviati. Esistono processi (a volte piuttosto complessi) per impostare i valori TPM originali (per semplicità ho saltato alcuni dei passaggi di basso livello del processo) e per consentire modifiche (si spera autorizzate) ai livelli per l'aggiornamento o l'applicazione di patch di sicurezza , Per esempio. Questo processo di "avvio misurato" consente alle entità di interrogare il TPM dopo che il processo è stato completato e di verificare se i valori negli slot PCR corrispondono ai valori previsti, precalcolati con versioni "noto bene" dei vari livelli, ovvero , versioni pre-verificate la cui provenienza e integrità sono già state stabilite.
Esistono vari protocolli per consentire alle parti esterne al sistema per verificare i valori (ad es. tramite una connessione di rete) che il TPM attesta come corretti:il processo di ricezione e verifica di tali valori da un sistema esterno è noto come "attestazione remota".
Questo processo, l'avvio misurato, ti consente di scoprire se le basi del tuo sistema, i livelli più bassi, sono ciò che pensi che siano. Ma cosa succede se non lo sono? Lo stivale misurato (non sorprende, dato il nome) misura ma non esegue altre azioni.
L'alternativa, "avvio affidabile", fa un ulteriore passo avanti. Quando viene eseguito un processo di avvio attendibile, il processo non solo misura ogni valore, ma esegue anche un controllo rispetto a un valore buono noto (e previsto!) allo stesso tempo. Se il controllo fallisce, il processo si interrompe e l'avvio del sistema non riesce. Questo può sembrare un approccio piuttosto estremo per affrontare un sistema, ma a volte è assolutamente quello giusto. Laddove il sistema in esame potrebbe essere stato compromesso, che è una probabile inferenza che puoi trarre dal fallimento di un processo di avvio affidabile, è meglio che non sia affatto disponibile piuttosto che funzioni in base a aspettative errate.
Va tutto bene se sono il proprietario del sistema misurato, ho controllato tutti i vari componenti misurati (e le misurazioni) e sono felice che ciò che viene avviato sia quello che voglio. Ma cosa succede se ad esempio utilizzo un sistema sul cloud o un sistema di proprietà e gestito da qualcun altro? In tal caso, mi affido al provider di servizi cloud (o al proprietario/gestore) per due cose:
- Eseguire correttamente tutte le misurazioni e segnalarmi i risultati corretti
- Costruire qualcosa di cui dovrei fidarmi in primo luogo
Questo è il problema con la nomenclatura "trusted boot" e, peggio ancora, "secure boot". Entrambi implicano che è stata stabilita una proprietà assoluta e oggettiva di un sistema - è "fidato" o "sicuro" - quando chiaramente non è così. Ovviamente, sarebbe ingiusto aspettarsi che i progettisti di tali processi li denominino dopo gli stati di errore - "avvio non affidabile" o "avvio non sicuro" - ma, a meno che io non possa essere assolutamente certo di fidarmi del proprietario del sistema per eseguire il passaggio due del tutto correttamente (e nel mio migliore interesse come utente del sistema, piuttosto che il loro come proprietario), quindi non posso fare affermazioni più forti.
C'è un'enorme tentazione di prendere un sistema che è passato attraverso un processo di avvio affidabile ed etichettarlo come "sistema affidabile" quando il migliore l'affermazione che puoi fare è che i livelli particolari misurati nel processo di avvio misurato e/o attendibile sono stati dichiarati essere quelli che il processo si aspetta siano presenti. Tale processo non dice nulla sull'idoneità dei livelli a fornire assicurazioni di comportamento né sulla correttezza (o idoneità a fornire assicurazioni di comportamento) di eventuali livelli successivi in aggiunta a quelli.
È importante notare che i progettisti di TPM sono abbastanza chiari su ciò che viene affermato e che le affermazioni sulla fiducia dovrebbero essere fatte con attenzione e con parsimonia. Sfortunatamente, tuttavia, le complessità dei sistemi, il basso livello generale di comprensione della fiducia e le complessità del contesto e della fiducia transitiva rendono molto facile per i progettisti e gli implementatori di sistemi fare la cosa sbagliata e presumere che qualsiasi sistema che abbia eseguito con successo un processo di avvio affidabile può essere considerato "fidato". È anche estremamente importante ricordare che i TPM, in quanto radici di fiducia hardware, offrono uno dei migliori meccanismi disponibili per stabilire una catena di fiducia nei sistemi che potresti progettare o implementare e ho intenzione di scrivere presto un articolo su di loro.
- Anche se questo risulta essere molto più difficile di quanto potresti aspettarti!
Questo articolo è stato originariamente pubblicato su Alice, Eve e Bob ed è stato ristampato con il permesso dell'autore.