Utilizzo del TPM con le password SRK / proprietario ben note?

Question

Utilizzo del TPM con le password SRK / proprietario ben note?

#1 da (4 voti)

11

In primo luogo, spiegherò più o meno come intendo utilizzare il TPM:

Sto usando qualcosa chiamato tpm-luks che memorizza una chiave in entrambi i TPM NVRAM e aggiunge la chiave a una dei keylots LUKS. Initramfs decodifica quindi la partizione crittografata con LUKS di root utilizzando la chiave che ottiene dal TPM. Uso anche tpm-luks per seal la chiave in modo che la chiave venga rilasciata dalla NVRAM TPM solo quando i registri PCR TPM si trovano in uno stato dato (ad es. Dopo un bootloader predeterminato, initramfs, linux ecc. sono stati caricati). TrustedGRUB [2] viene utilizzato come bootloader in modo che registri i propri hash sulle PCR TPM.

Ho anche in programma di fare aggiornamenti remoti e incustoditi al sistema di volta in volta (ad esempio aggiornando il kernel che cambierà anche gli hash dei file del kernel, ecc.). Per ovviare a questo problema, tpm-luks fornisce un modo per pre-calcolare gli hash e reseal la chiave usando i nuovi valori prima di riavviare la macchina in modo che la chiave possa essere sbloccata di nuovo con la nuova PCR stato.

Attualmente questo processo richiede che io inserisca la password del proprietario del TPM ogni volta che eseguo un aggiornamento e voglio aggiungere una nuova chiave.

Le mie domande sono:

Va bene usare la password nota di 20 byte di 0 come password proprietario / SRK? tpm-luks ha le opzioni per utilizzare queste password ben note per eseguire queste operazioni in modo che possano essere non interattive. Dato che il sistema è bloccato, presumo che nessuno sarà in grado di sfruttarlo?
In caso contrario, sarebbe possibile mantenere le password sulla partizione di root crittografata? Il sistema è affidabile al momento della decifrazione della partizione di root, quindi dovrebbe essere sicuro memorizzare la password lì (e accedervi in sicurezza)?
Sarebbe meglio mantenere le password in un altro luogo sicuro e inviarle alla macchina se è necessario eseguire tali operazioni? Non sono sicuro che sia più sicuro della seconda opzione sopra.
Esistono altre soluzioni migliori per raggiungere gli obiettivi di cui sopra (memorizzazione non interattiva delle chiavi su NVRAM TPM)?

linux luks tpm

posta mtahmed 18.12.2015 - 22:46

fonte

1 risposta

Leggi altre domande sui tag linux luks tpm

Sofisticato attacco DDOS Come viene calcolata (o stimata) l'entropia disponibile in / dev / random?

score 4 · Answer 1

Is it okay to use the well-known password of 20 bytes of 0s as the owner/SRK passwords? tpm-luks has the options to use those well-known passwords to perform these operations so that they can be non-interactive. Since the system is locked down, I am assuming no one will be able to exploit this?

Se lasci il proprietario e la password come valori predefiniti o noti, stai aprendo la porta per aggirare l'intero processo di avvio sicuro. Questo è più preoccupante nei sistemi embedded fuori sul campo che sono intesi ad essere resistenti alle manomissioni (la manomissione in questo caso fa sì che non funzionino o cadano in una modalità fail-safe funzionalmente limitata).

Se si utilizza un proprietario / password ben noto, chiunque abbia esperienza o conoscenza potrebbe modificare la configurazione dell'immagine / hardware del sistema operativo sottostante, aggiornare i valori PCR TPM e accedere comunque alle chiavi del file system, ignorando le misure di sicurezza / integrità che si stanno inserendo posto.

If not, would it be feasible to keep the passwords on the encrypted root partition? The system is trusted by the time the root partition is decrypted so it should be safe to store the password there (and access it securely)?

Certo, posso vederlo funzionare, anche se, una volta che il sistema è stato avviato e ritenuto "affidabile", sei ancora suscettibile a qualcuno che preleva le chiavi che permetterebbe loro di rimuovere l'unità dal sistema e decrittografarla. Quindi, certo, è sicuro conservarlo lì ... mentre è crittografato, ma il post-boot è un rischio. (Ciò potrebbe in ultima analisi portare a backdoor installati su "sistemi affidabili")

Would it be better to keep the passwords at some other safe location and send them down to the machine if it needs to perform such operations? Not sure if it's any safer than the second option above.

Il TPM è letteralmente il posto migliore in cui archiviare le tue chiavi.

Are there any other better solutions to accomplish the objectives above (non-interactive storage of keys to TPM NVRAM)?

Certo. Sembra che tu stia cercando soluzioni complicate per un singolo problema di strumenti: i tuoi strumenti non ti consentono di automatizzare la proprietà / impostare le password.

Probabilmente controllerò il repository del codice dei pantaloni, lo creerò e lo testeremo, quindi modificherò lo strumento tpm_takeownership per aggiungere un'opzione di richiesta del proprietario / password non interattiva, quindi userai quel binario personalizzato durante il tuo processo di aggiornamento.