Per sbloccare da remoto i volumi LUKS tramite SSH, come posso verificare l'integrità prima di inviare passphrase?

4

Sebbene questo sia strettamente correlato alla domanda chiusa di recente Cattive cameriere nel server room [closed] , credo che sia più comprensibile.

Vorrei sbloccare i volumi LUKS su server remoti ospitati, usando initramfs con BusyBox e Dropbear come server SSH. Nella risposta alla domanda chiusa citata sopra, paj28 note:

 Remote boot techniques like dropbear are vulnerable to a remote variant of
 the evil maid attack. For example, someone with physical access could tamper
 with the dropbear partition, and have it leak the key on the next reboot.

L'attacco è anche descritto in LUKS sirene di sblocco remoto .

Nell'ambiente initramfs di BusyBox, vorrei verificare l'integrità di un server remoto prima di inviare la passphrase per sbloccare LUKS. Posso verificare l'integrità dei file controllando i checksum sha256 rispetto a un elenco locale. Ma sarebbe in grado di rilevare la modifica di initramfs per acquisire la passphrase?

Posso facilmente ottenere il MAC di eth0 e posso usare traceroute per rilevare i cambiamenti nell'ambiente di rete. Forse posso aggiungere hwinfo a initramfs per confermare l'ambiente hardware. Quali cambiamenti potrebbero non essere rilevati da quei test?

Non sto chiedendo una soluzione, ma se ce n'è una elegante che mi manca, faccelo sapere.

    
posta mirimir 06.12.2013 - 00:44
fonte

2 risposte

3

Non lo fai. Non puoi.

Il meglio che puoi fare è un percorso di avvio affidabile con TPM che fai parte del processo di sblocco delle partizioni. Ma a meno che l'hardware non sia bloccato sulla tua chiave personale di firma (che probabilmente non è), anche questo può essere sovvertito.

Tuttavia, TPM è probabilmente il più vicino che puoi ottenere. Questo non è banale da implementare, ed è improbabile che troverai una soluzione pronta per questo.

    
risposta data 06.12.2013 - 03:17
fonte
0

È possibile utilizzare l'attestazione remota, come previsto da un TPM, utilizzando SRTM .

Garantire un TPM è autentico

Nonostante ciò che dice @tylerl, non è necessario affidarsi alla propria chiave di firma per un TPM per fornire l'attestato. Un TPM originale utilizzerà una chiave di verifica dell'autenticità o EK, che è una chiave masterizzata nel TPM in fase di produzione, con la chiave privata corrispondente che non viene mai rilasciata al pubblico (simile a come funziona PKI per il Web). L'unico modo in cui un TPM falso potrebbe essere presentato (come essere emulato nel software) sarebbe se la chiave dell'autenticità non è segreta. Se il tuo datacenter ha un EK rubato, devi preoccuparti di molto di più. Un TPM non ti proteggerà da questo avversario più di quanto HTTPS ti protegga da una CA canaglia.

avvio misurato

Un TPM fornisce una funzione chiamata avvio misurato , le cui specifiche possono essere trovate all oltre questo sito web . Il nocciolo della questione è che un componente sicuro e di sola lettura del BIOS, chiamato CRTM, avvia una reazione a catena in cui componenti diversi del sistema vengono sottoposti a hash e inviati al TPM. A meno che tutti gli hash non corrispondano a uno stato noto, il TPM rimarrà bloccato o sigillato . L'unico modo in cui può essere mai aperto è quando il sistema si trova in uno stato noto. I dati esatti che sigilla sono arbitrari. Può essere utilizzato per sigillare, ad esempio, le chiavi di crittografia, in modo che il sistema possa essere avviato solo se il sistema non è stato manomesso. Può anche essere utilizzato per memorizzare un valore segreto noto solo a te, in modo tale che l'hardware dannoso non possa prevedere quale sia questo valore e presentarlo all'utente. Solo se lo vedi, sai che il TPM è genuino e il tuo sistema è in uno stato normale. Questa è la base per Anti-EvilMaid .

di Joanna Rutkowska.

Integrità dopo che TPM ha fatto il suo lavoro

Il lavoro del TPM termina quando si avvia il kernel. Garantisce che tutto il resto del sistema, dal BIOS alle ROM opzionali al bootloader alla NVRAM, sia stato misurato, ma dopo aver misurato il kernel, il suo lavoro è terminato. Il kernel è stato misurato, ma il resto del sistema no. Quando arrivi a questo punto, il kernel deve fornire una sorta di misura. Una caratteristica di Linux è l' Architettura di misurazione dell'integrità , o IMA. IMA funziona mantenendo un hash di tutti i file sul sistema in un attributo esteso. Questi hash vengono confrontati verificati utilizzando un hash della radice principale che è memorizzato nel TPM. Il kernel rifiuterà di leggere qualsiasi file senza hash o gli hash di chi non può essere verificato come legittimo. A questo punto, hai eseguito correttamente il boot misurato e ora sei in un ambiente di esecuzione affidabile.

Avvertimenti

  • L'avvio misurato non previene alcuni tipi di attacchi hardware, come gli attacchi DMA. Prevenire è talvolta possibile (ad es. Con DMAR), ma fuori ambito qui
  • Se il tuo avversario è abbastanza potente da mettere le mani sul DK, può creare un TPM falso nel software e non saprai la differenza.
  • Per ottenere una lettura valida dal TPM, il sistema deve essere, almeno inizialmente, non compromesso, oppure è necessario controllare gli hash segnalati rispetto ai valori noti.
  • Alcuni BIOS potrebbero avere un'implementazione errata di avvio misurato. Ad esempio, il CRTM può risiedere nella memoria flash scrivibile e un TPM si basa sul fatto che il CRTM è di sola lettura.
  • Un avversario ben equipaggiato può essere in grado di decapare il TPM e leggere il contenuto all'interno con un microscopio elettronico. Questo è molto difficile, ma fisicamente possibile.
  • Le versioni precedenti di TPM (1.1) erano vulnerabili agli attacchi di reimpostazione della piattaforma . Si dovrebbe usare un TPM più recente (2.0 o almeno 1.2) per evitare questo. In alternativa, l'iTPM integrato di Intel potrebbe funzionare per te.
risposta data 29.11.2017 - 11:12
fonte

Leggi altre domande sui tag