Problemi / Vulnerabilità che TPM 2.0 si propone di migliorare / risolvere confrontando con TPM 1.2

7

Ho letto alcuni documenti che confrontano TPM 1.2 e TPM 2.0 (ad esempio, algoritmi più supportati come SHA-2, dimensioni ridotte del codice o persino chiavi simmetriche sembrano aggiunte, ecc.)

Voglio chiedere quali sono gli obiettivi per sviluppare un TPM 2.0 non compatibile? In realtà, in altre parole, quali sono i problemi chiave che TPM 2.0 si propone di risolvere / migliorare confrontando con TPM 1.2? (proprio come TPM 1.2 risolti vulnerabilità in TPM 1.1.)

es. risolvere le vulnerabilità esistenti in TPM 1.2, miglioramenti per prevenire determinati attacchi, supportare più algoritmi per adattarsi a più piattaforme, ecc.

(Un'altra piccola domanda: dopo che il TPM 2.0 è diventato maturo, quale potrebbe essere la tendenza possibile di TPM 1.2, sostituito?)

    
posta Li Dong 23.10.2015 - 10:53
fonte

1 risposta

2

L'UEFI ha creato una piccola presentazione che descrive il motivo per cui dobbiamo raggiungere il TPM 2.0 e dimenticare il 1.2.

Innanzitutto l'algoritmo SHA-1 è considerato non sicuro e, come si suol dire, saltare su SHA-2 non è efficiente a lungo termine. Quindi TPM 2.0 supporta in teoria ogni tipo di algoritmo di hash. Ecco la politica del NIST sulla funzione di hash . SHA-1 non dovrebbe essere usato per usi crittografici. (come dice la foresta, sha-1 è debole solo contro la collisione, l'uso di SHA-1 con HMAC non è molto influenzato)

Considerando la crittografia asimmetrica, la RSA non è tanto obsoleta (pur restando con chiavi di lunghezza decente), ma forse un giorno, il problema della fattorizzazione dei numeri interi non sarà più un problema grazie a Algoritmo di Shor . Abbiamo bisogno di avere qualsiasi tipo di crittografia a chiave pubblica. Quindi ci sono tutti gli algoritmi di crittografia a curva ellittica, gli algoritmi di logaritmi discreti e ovviamente la fattorizzazione di interi. (Apparentemente, le curve ellittiche dovrebbero essere più vulnerabile all'algoritmo di Shor ). Prima del TPM 2.0, l'unica scelta che avevamo era la RSA. Gli algoritmi disponibili dipendono da ciò che il fornitore desidera implementare.

Considerando infine la crittografia simmetrica, con TPM 1.2 abbiamo lo XOR e soprattutto AES. Non c'è alcun attacco noto contro AES, ma avere la scelta è bello. Ci sono alternative a AES come Blowfish. E ci deve essere una sorta di scelte politiche (l'AES è approvata dalla NSA, alcune persone / paesi potrebbero pensare che questo sia un cattivo indicatore: «Se la NSA lo approva, devono sapere come decrittografarlo»)

Dovrebbe essere più facile da usare. Citerò la presentazione UEFI:

Removed the confusing enabled/activated/disabled/deactivated states – It’s either there or not there (ACPI table) – If present, it can be used by firmware even if not exposed to the OS

Infine, TPM 2.0 contiene 3 chiavi di gerarchia permanente (Piattaforma, Memoria, Privacy) contro una sola per TPM 1.2.

La gerarchia Privacy utilizza endorsementAuth e può essere utilizzata per generare EK (chiave di omologazione proprio come in TPM 1.2), e quindi generare facilmente AIK (Chiave di identità dell'attestazione), che può essere utilizzata in < a href="https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation"> Attestazione anonima diretta (autenticazione con una prova a conoscenza zero)

La gerarchia di sicurezza utilizza ownerAuth e viene utilizzata per crittografare / decrittografare i dati.

La gerarchia della piattaforma utilizza PlatformAuth e può essere utilizzata per inizializzare il TPM e abilitare / disabilitare l'uso delle altre gerarchie.

Quindi fondamentalmente, con 3 gerarchie invece di 1, puoi fare la stessa cosa, ma le autorizzazioni sono più intelligenti.

    
risposta data 08.06.2016 - 22:56
fonte

Leggi altre domande sui tag