7.4. Verificatore

7.4. Verificatore

Il verificatore si fida (o più specificamente, la politica di sicurezza del verificatore è scritta in modo da configurare il verificatore per fidarsi) di un produttore o dell'hardware del produttore in modo da poter valutare l'affidabilità dei dispositivi di quel produttore. Tale fiducia è espressa memorizzando una o più ancore di fiducia nell'archivio di ancore di fiducia del verificatore.

In una soluzione tipica, un verificatore arriva a fidarsi di un attestatore indirettamente facendo in modo che un endorser (come un produttore) garantisca la capacità dell'attestatore di generare in modo sicuro evidenza attraverso endorsements (vedere sezione 8.2). Gli endorsements possono descrivere i modi in cui l'attestatore resiste agli attacchi, protegge i segreti e misura gli ambienti di destinazione. Di conseguenza, il materiale chiave dell'endorser viene memorizzato nell'archivio di ancore di fiducia del verificatore in modo che gli endorsements possano essere autenticati e utilizzati nel processo di valutazione del verificatore.

In alcune soluzioni, un verificatore potrebbe essere configurato per fidarsi direttamente di un attestatore facendo in modo che il verificatore possieda il materiale chiave dell'attestatore (piuttosto che quello dell'endorser) nel suo archivio di ancore di fiducia.

Tale fiducia diretta deve prima essere stabilita al momento della configurazione dell'archivio di ancore di fiducia, o verificando con un endorser in quel momento o conducendo un'analisi di sicurezza del dispositivo specifico. Avere l'attestatore direttamente nell'archivio di ancore di fiducia restringe la fiducia del verificatore solo a dispositivi specifici piuttosto che a tutti i dispositivi per cui l'endorser potrebbe garantire, come tutti i dispositivi prodotti dallo stesso produttore nel caso in cui l'endorser sia un produttore.

Tale restringimento è spesso importante poiché il possesso fisico di un dispositivo può anche essere utilizzato per condurre un certo numero di attacchi, e quindi un dispositivo in un ambiente fisicamente sicuro (come i propri locali) può essere considerato fidato, mentre i dispositivi posseduti da altri non lo sarebbero. Questo spesso si traduce in un desiderio di far gestire al proprietario il proprio endorser che endorserebbe solo i dispositivi che si possiedono o di utilizzare attestatori direttamente nell'archivio di ancore di fiducia. Quando ci sono molti attestatori posseduti, l'uso di un endorser consente una migliore scalabilità.

Cioè, un verificatore potrebbe valutare l'affidabilità di un componente dell'applicazione, un componente del sistema operativo o un servizio presupponendo che le informazioni fornite su di esso dal firmware o dal software di livello inferiore siano vere. Un livello più forte di garanzia di sicurezza si ottiene quando le informazioni possono essere garantite dall'hardware o dal codice ROM, specialmente se tale hardware è fisicamente resistente alla manomissione hardware. Nella maggior parte dei casi, i componenti che devono essere garantiti tramite endorsements (perché non viene generata evidenza su di essi) sono denominati "radici di fiducia".

Il produttore avendo organizzato il provisioning di un ambiente di attestazione con materiale chiave con cui firmare l'evidenza, il verificatore viene quindi fornito con qualche modo per verificare la firma sull'evidenza. Questo può essere sotto forma di un'ancora di fiducia appropriata oppure il verificatore può essere fornito con un database di chiavi pubbliche (piuttosto che certificati) o persino elenchi di chiavi simmetriche accuratamente curati e protetti.

La natura di come il verificatore gestisce la convalida delle firme prodotte dall'attestatore è critica per il funzionamento sicuro di un sistema di attestazione remota ma non è oggetto di standardizzazione all'interno di questa architettura.

Un protocollo di trasporto che fornisce autenticazione e protezione dell'integrità può essere utilizzato per trasmettere evidenza che è altrimenti non protetta (ad esempio, non firmata). Il trasporto appropriato di evidenza non protetta (ad esempio, [RATS-UCCS]) si basa sulle seguenti capacità di protezione del protocollo di trasporto:

1. Il materiale chiave utilizzato per autenticare e proteggere l'integrità del canale di trasporto è fidato dal verificatore per parlare a nome degli ambienti di attestazione che hanno raccolto rivendicazioni sugli ambienti di destinazione.

2. Tutta l'evidenza non protetta che viene trasmessa è fornita esclusivamente dall'ambiente di attestazione che ha il materiale chiave che protegge il canale di trasporto.

3. Un ambiente fidato protegge il materiale chiave del canale di trasporto, che può dipendere da altri ambienti di attestazione con protezioni di forza equivalente.

Come illustrato in [RATS-UCCS], un'entità che riceve evidenza non protetta tramite un canale di trasporto fidato assume sempre la responsabilità di garantire l'autenticità e la freschezza dell'evidenza. Se viene generata evidenza protetta, gli ambienti di attestazione dell'attestatore assumono tale responsabilità. Nei casi in cui l'evidenza non protetta viene elaborata da un verificatore, le parti affidanti devono fidarsi che il verificatore sia in grado di gestire l'evidenza in modo da preservare l'autenticità e la freschezza dell'evidenza. Generare e trasmettere evidenza non protetta crea sempre un rischio significativo e i benefici di tale approccio devono essere attentamente valutati rispetto ai potenziali svantaggi.

Vedere la sezione 12 per la discussione sulla forza di sicurezza.