Il supporto TPM è molto rudimentale in questo momento. Avrai bisogno di un bootloader in grado di estendere la catena della fiducia e so solo TrustedGRUB, una versione piuttosto vecchia di GRUB con funzionalità relative al TPM aggiunte.
D'altra parte, credo che il TPM sia tutto un hype relativo a Bitlocker, praticamente fornisce pochissima sicurezza (forse questo è design per soddisfare le agenzie di tre lettere?) poiché la macchina ora ha tutto ciò che serve per l'avvio e decifrare il suo contenuto senza altri segreti, consentendo a un utente malintenzionato che ha rubato la macchina (anche spento) per avviarlo e quindi attaccarlo con DMA o attacchi cold-boot per recuperare le chiavi. Il TPM non protegge da questo. Inoltre, un attacco teorico a cui penso sempre è quello di annusare semplicemente il bus seriale a bassa velocità su cui è collegato il TPM e attendere che trasmetta la chiave di crittografia. Richiede solo alcuni cavi per saldare sulla scheda, molto semplice e non richiede attrezzature costose.
Un'unità flash USB + keyfile / password sarebbe molto più sicura in quanto il materiale necessario per sbloccare la macchina è ora separato da esso, se il computer viene rubato è essenzialmente un mattone inutile, non c'è assolutamente nulla sulla macchina che tiene la chiave.
Ora, per rispondere alle tue domande specifiche.
1) No, alcuni codici non criptati devono essere eseguiti prima che una partizione crittografata possa essere decifrata e montata, quindi il /boot , indipendentemente da dove sia, non dovrebbe essere criptato. Il firmware (BIOS / UEFI) non supporta i file system crittografati. Inoltre, in caso di crittografia del disco, utilizziamo la crittografia simmetrica, quindi non esiste la nozione di chiave pubblica e tutto ciò che il TPM fa è controllare se i dati forniti (hash di ogni componente eseguito fino ad ora e le loro configurazioni, quindi il firmware , la sua configurazione, il bootloader, ecc.) e restituisce un blocco dati se gli hash corrispondono quando il TPM era "sigillato". Questo blocco di dati è la chiave di decodifica.
2) Innanzitutto, GRUB non esegue la crittografia. Il kernel di Linux gestisce il crypto, il che significa tutto prima che il kernel non sia criptato. Infine non c'è modo di richiedere sia una password che un file di chiavi con LUKS, ma puoi cifrare il tuo file di chiavi con qualche programma (GPG?) Che impacchetti nel initrd (non criptato) e chiamalo prima di passare il file di chiavi (decodificato) a LUKS continua l'avvio.
3) Sicuro. LUKS consente di crittografare in modo trasparente un dispositivo a blocchi esponendo la sua versione non crittografata come nodo di dispositivo separato, quindi il sistema utilizza quello invece del dispositivo a blocchi reale che ora contiene dati crittografati. Che si tratti di un dispositivo interno, esterno o di qualche magia voodoo come un file immagine disco da un server NFS montato come dispositivo loop con LUKS in alto, funzionerà altrettanto bene (prestazioni non garantite per l'ultimo però). Sia che tu usi i file di chiavi o le password, non cambia nulla neanche.