Il "lancio ritardato" / "catena di fiducia dinamica" consente l'attestazione remota?

Does "dynamic chain of trust" support remote attestation?

Quando viene utilizzato un lancio dinamico su un'area della memoria, vengono utilizzati specifici indici PCR nel TPM per registrare lo stato di quel software. Se questi indici PCR sono inclusi nella richiesta di attestazione da parte dello sfidante, allora quel software sarebbe attestato nella risposta. Questi indici PCR sono 17-22, come specificato nel TCG's PCClient in implementazione per le specifiche del BIOS , vedere a pagina 30.

Does it provide way to attest to the code of the trusted module that was launched in this way, to a third party?

L'implementazione Intel del supporto TXT su Linux, dopo l'avvio, ha perso un dettaglio, che si spera possa essere risolto presto. tboot non espone il registro eventi, che mostra quale software è stato esteso a PCR TPM come parte del lancio di TXT. Questo è un requisito per un challeneger remoto per attestare contro PCR di lancio dinamico, quindi al momento il supporto non è completamente lì. È possibile trovare tecnicamente il registro degli eventi, ma non è disponibile in un formato standard TCG, quindi tutti gli strumenti di calcolo comuni attendibili che verrebbero utilizzati per analizzarlo non funzioneranno su ATM.

Sì.

Puoi vedere entrambe le funzioni come due cose separate, ovvero, DRTM (Dynamic Root of Trust for Measurement) è solo un altro modo per estendere i valori della PCR (17-22) (come SRTM) mentre Remote Attestation prenderà qualsiasi PCR che desideri utilizzare (molto simile all'operazione SEAL). Non c'è dipendenza o collegamento reale tra queste funzionalità.

Se vuoi maggiori dettagli sugli aspetti interni di DRTM e Remote Attestation consiglio vivamente di leggere i documenti di progetto di Flicker. Lo sfarfallio utilizza il DRTM per dimostrare a una terza parte che è stato eseguito un particolare D-MLE (Dynamic Measure Launch Environment). Breve storia: link , lunga storia: link .

P.S. Sembra esserci un errore nella lunga storia in cui si dice che SRK (Storage Root Key) è stato creato dal produttore mentre in realtà è creato dal proprietario della piattaforma quando è take ownership . Si spera che non abbiano usato SRK per dimostrare che si tratta di un TPM reale / fisico. Solo l'EK (Chiave di approvazione) può dimostrare che un TPM è autentico.

Non sono sicuro di come potrebbe essere possibile senza un tipo di chiave precondivisa con il servizio remoto o una chiave privata stabilita in modo affidabile che il TPM contiene. Penso che il problema sarebbe che non ci sarebbe stato modo per la terza parte di sapere che era il TPM che eseguiva il codice in contrasto con una variante modificata modificata per l'esecuzione in uno spazio non protetto. Se il TPM disponeva di una chiave privata affidabile della terza parte, sarebbe possibile che la terza parte rilasci una sfida al TPM a cui il TPM poteva rispondere solo all'interno di un processo firmato e attendibile e che avrebbe conseguito l'obiettivo di attestazione remota , ma non vedo come verrà stabilita quella chiave privata affidabile.

Si noti che sto rispondendo esclusivamente alla descrizione del cripto-sistema fornito e alla mia conoscenza generale del TPM. Non ho alcuna conoscenza specifica aggiuntiva su ciò che Trusted Execution supporta, ma ho pensato che lo scopo principale di questo era per DRM e scopi di protezione del codice piuttosto che l'attestazione remota, anche se sarebbe certamente una buona estensione ad esso.

Trovato un documento con maggiori dettagli da CERT. documento CERT su capacità TPM .