10. Freschezza

10. Freschezza

Un verificatore o una parte richiedente potrebbe aver bisogno di conoscere il momento preciso (cioè l'"epoca") in cui un'evidenza o un risultato di attestazione è stato prodotto. Questo è essenziale per decidere se le dichiarazioni incluse possano essere considerate fresche, il che significa che riflettono ancora lo stato più recente dell'attestatore e che qualsiasi risultato di attestazione è stato generato utilizzando la politica di valutazione più recente per evidenze, endorsement e valori di riferimento.

Questa sezione fornisce numerosi dettagli. Tuttavia, non definisce alcun formato di protocollo e le interazioni mostrate sono astratte. Questa sezione è destinata a coloro che creano protocolli e soluzioni per comprendere le opzioni disponibili per garantire la freschezza. Il modo in cui la freschezza viene fornita in un protocollo è una decisione architettonica. La fornitura di freschezza ha un impatto sul numero di round trip necessari in un protocollo; pertanto, deve essere presa molto presto nella progettazione. Decisioni diverse avranno impatti significativi sull'interoperabilità risultante, motivo per cui questa sezione entra in dettagli sufficienti affinché le scelte sulla freschezza siano compatibili tra i protocolli interagenti, come illustrato nella Figura 9.

La freschezza viene valutata in base alla politica di valutazione per evidenze o risultati di attestazione che confronta l'epoca stimata con una soglia di "scadenza" definita localmente per quella politica. Tuttavia, esiste sempre una possibile condizione di gara in cui lo stato dell'attestatore e le politiche di valutazione potrebbero cambiare immediatamente dopo che l'evidenza o il risultato di attestazione è stato generato. L'obiettivo è semplicemente restringere la loro recente validità a qualcosa che il verificatore (per l'evidenza) o la parte richiedente (per il risultato di attestazione) è disposto ad accettare. Una certa flessibilità sul requisito di freschezza è un componente chiave per consentire la memorizzazione nella cache e il riutilizzo sia delle evidenze che dei risultati di attestazione, il che è particolarmente prezioso nei casi in cui il loro calcolo utilizza una parte sostanziale del budget delle risorse (ad esempio, energia nei dispositivi vincolati).

Esistono tre approcci comuni per determinare l'epoca di un'evidenza o di un risultato di attestazione.

10.1. Cronometraggio esplicito utilizzando orologi sincronizzati

Il primo approccio consiste nel fare affidamento su orologi sincronizzati e affidabili e includere un timestamp firmato (vedere [RATS-TUDA]) insieme alle dichiarazioni nell'evidenza o nel risultato di attestazione. I timestamp possono anche essere aggiunti per singola dichiarazione per distinguere il momento della generazione dell'evidenza o del risultato di attestazione dal momento in cui è stata generata una dichiarazione specifica. L'affidabilità dell'orologio può generalmente essere stabilita tramite endorsement e tipicamente richiede dichiarazioni aggiuntive sul meccanismo di sincronizzazione temporale del firmatario.

Tuttavia, un orologio affidabile potrebbe non essere disponibile in alcuni casi d'uso. Ad esempio, in molti TEE oggi, un orologio è disponibile solo all'esterno del TEE; pertanto, non può essere considerato affidabile dal TEE.

10.2. Cronometraggio implicito utilizzando nonce

Un secondo approccio pone l'onere del cronometraggio esclusivamente sul verificatore (per l'evidenza) o sulla parte richiedente (per i risultati di attestazione). Ad esempio, questo approccio potrebbe essere adatto nel caso in cui l'attestatore non disponga di un orologio affidabile o la sincronizzazione temporale sia altrimenti compromessa. In questo approccio, un nonce imprevedibile viene inviato dall'entità di valutazione e il nonce viene quindi firmato e incluso insieme alle dichiarazioni nell'evidenza o nel risultato di attestazione. Dopo aver verificato che i nonce inviati e ricevuti sono gli stessi, l'entità di valutazione sa che le dichiarazioni sono state firmate dopo la generazione del nonce. Ciò consente di associare un'epoca "approssimativa" all'evidenza o al risultato di attestazione. In questo caso, l'epoca è detta approssimativa perché:

• L'epoca si applica all'intero insieme di dichiarazioni invece di un'associazione più granulare, e

• Il tempo tra la creazione delle dichiarazioni e la raccolta delle dichiarazioni è indistinguibile.

10.3. Cronometraggio implicito utilizzando ID di epoca

Un terzo approccio si basa sull'invio periodico di identificatori di epoca (ID) sia al mittente che al destinatario di evidenze o risultati di attestazione da parte di un "distributore di ID di epoca".

Gli ID di epoca sono diversi dai nonce in quanto possono essere utilizzati più di una volta e possono anche essere utilizzati da più di un'entità contemporaneamente. Gli ID di epoca sono diversi dai timestamp in quanto non devono trasmettere informazioni su un punto nel tempo, cioè non sono necessariamente numeri interi che aumentano in modo monotono.

Come l'approccio basato su nonce, ciò consente di associare un'epoca "approssimativa" senza richiedere un orologio affidabile o la sincronizzazione temporale per generare o valutare la freschezza di evidenze o risultati di attestazione. Solo il distributore di ID di epoca richiede l'accesso a un orologio in modo da poter inviare periodicamente nuovi ID di epoca.

L'ID di epoca più recente è incluso nell'evidenza o nei risultati di attestazione prodotti, e l'entità di valutazione può confrontare l'ID di epoca nelle evidenze o nei risultati di attestazione ricevuti con l'ultimo ID di epoca ricevuto dal distributore di ID di epoca per determinare se rientra nell'epoca corrente. Una soluzione effettiva deve anche tenere conto delle condizioni di gara durante la transizione a una nuova epoca, ad esempio utilizzando un contatore firmato dal distributore di ID di epoca come ID di epoca, includendo sia gli ID di epoca correnti che quelli precedenti nei messaggi e/o nei controlli richiedendo nuovi tentativi in caso di ID di epoca non corrispondenti, o bufferizzando i messaggi in arrivo che potrebbero essere associati a un ID di epoca che il destinatario non ha ancora ottenuto.

Più in generale, per evitare che un'entità di valutazione generi falsi negativi (ad esempio, scartando evidenze ritenute obsolete anche se non lo sono), l'entità di valutazione dovrebbe mantenere una "finestra di epoca" costituita dagli ID di epoca ricevuti più di recente. La profondità di tale finestra di epoca è direttamente proporzionale al massimo ritardo di propagazione della rete tra il primo a ricevere l'ID di epoca e l'ultimo a ricevere l'ID di epoca ed è inversamente proporzionale alla durata dell'epoca. L'entità di valutazione deve confrontare l'ID di epoca contenuto nell'evidenza o nel risultato di attestazione ricevuto con gli ID di epoca nella sua finestra di epoca per trovare una corrispondenza adeguata.

Mentre l'approccio basato su nonce richiede tipicamente che l'entità di valutazione mantenga lo stato per ogni nonce generato, l'approccio basato su ID di epoca minimizza lo stato mantenuto in modo da essere indipendente dal numero di attestatori o verificatori da cui si aspetta di ricevere evidenze o risultati di attestazione, purché tutti utilizzino lo stesso distributore di ID di epoca.

10.4. Discussione

Il cronometraggio implicito ed esplicito può essere combinato in meccanismi ibridi. Ad esempio, se esistono orologi all'interno dell'ambiente di attestazione e sono considerati affidabili (a prova di manomissione) ma non sono sincronizzati, può essere utilizzato uno scambio basato su nonce per determinare l'offset temporale (relativo) tra i peer coinvolti, seguito da un numero qualsiasi di scambi basati su timestamp.

È importante notare che i valori effettivi nelle dichiarazioni potrebbero essere stati generati molto prima che le dichiarazioni vengano firmate. In tal caso, è responsabilità del firmatario garantire che i valori siano ancora freschi quando vengono firmati. Ad esempio, i valori generati al momento dell'avvio potrebbero essere stati salvati in un archivio sicuro fino a quando non viene stabilita la connettività di rete al verificatore remoto e viene ottenuto un nonce.

Una discussione più dettagliata con esempi appare nell'Appendice A.

Per una discussione sulla sicurezza degli ID di epoca, vedere la Sezione 12.3.